AT91SAM7X security bit

I need to ensure the security bit is set, so I have a check in my
startup code. However, when it executes I get a watchdog timeout -
it seems to work because subsequently it passes the check. Here's my
code:

during initialization:
if (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_SECURITY)) { //check that
flash security bit is set
AT91C_BASE_MC->MC_FMR = (FMCN_1_0_US << 16) |
AT91C_MC_FWS_1FWS; //setup flash mode register (1.0us)
while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY)); //wait for
flash to become ready
setSecurityBit(); //call to RAM routine
AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PROCRST
| AT91C_RSTC_PERRST; //reset the processor and the peripherals
}
and the setSecurityBit() function:
__attribute__ ((long_call, section(".ramcode"))) void setSecurityBit() {
AT91C_BASE_MC->MC_FCR = (0x5A << 24) |
AT91C_MC_FCMD_SET_SECURITY; //program security bit
while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY)); //wait for
flash write to complete
}

My MCLK is 47.92MHz and FMCN_1_0_US is #defined as 48.

Any clues?
Thanks, Nick

Start a New Thread

That appears to be equivalent to what I do on the 7S part except I
disable all interrupts before starting the programming operation.

Do you have any interrupts enabled that might be firing during the
programming operation?

Cliff

--- In A..., Nick Howes wrote:
>
> I need to ensure the security bit is set, so I have a check in my
> startup code. However, when it executes I get a watchdog timeout -
> it seems to work because subsequently it passes the check. Here's my
> code:
>
> during initialization:
> if (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_SECURITY)) { //check that
> flash security bit is set
> AT91C_BASE_MC->MC_FMR = (FMCN_1_0_US << 16) |
> AT91C_MC_FWS_1FWS; //setup flash mode register (1.0us)
> while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY)); //wait for
> flash to become ready
> setSecurityBit(); //call to RAM routine
> AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PROCRST
> | AT91C_RSTC_PERRST; //reset the processor and the peripherals
> }
> and the setSecurityBit() function:
> __attribute__ ((long_call, section(".ramcode"))) void setSecurityBit() {
> AT91C_BASE_MC->MC_FCR = (0x5A << 24) |
> AT91C_MC_FCMD_SET_SECURITY; //program security bit
> while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY)); //wait for
> flash write to complete
> }
>
> My MCLK is 47.92MHz and FMCN_1_0_US is #defined as 48.
>
> Any clues?
> Thanks, Nick
>

Start a New Thread

--- In A..., "techguy2000" wrote:
>
> That appears to be equivalent to what I do on the 7S part except I
> disable all interrupts before starting the programming operation.
>
> Do you have any interrupts enabled that might be firing during the
> programming operation?
Hi Cliff,

I don't have any interrupts enabled.

Thanks for the info. I guess I need to figure out what is actually happening when it goes off
in the weeds. As I said: it seems to program the security bit correctly, but then doesn't return
as expected and I get a watchdog timeout.

- Nick
Start a New Thread

--- In A..., "Nick Howes" wrote:
>
> --- In A..., "techguy2000" wrote:
> >
> > That appears to be equivalent to what I do on the 7S part except I
> > disable all interrupts before starting the programming operation.
> >
> > Do you have any interrupts enabled that might be firing during the
> > programming operation?
> Hi Cliff,
>
> I don't have any interrupts enabled.
>
> Thanks for the info. I guess I need to figure out what is actually
happening when it goes off
> in the weeds. As I said: it seems to program the security bit
correctly, but then doesn't return
> as expected and I get a watchdog timeout.
>
> - Nick

The only other thing I can think of is to make sure that the
attributes declaring the function to be in RAM are really causing it
to be in RAM and that you're actually running it from there.
Programming the bit and then running into the weeds sure makes it
sound like the RAM routine is really in FLASH.

I'm assuming you've tried commenting out the line that starts the
programming operation and everything works fine except the security
bit doesn't get programmed.

Cliff

Start a New Thread

--- In A..., "techguy2000" wrote:

> The only other thing I can think of is to make sure that the
> attributes declaring the function to be in RAM are really causing it
> to be in RAM and that you're actually running it from there.
> Programming the bit and then running into the weeds sure makes it
> sound like the RAM routine is really in FLASH.
>
> I'm assuming you've tried commenting out the line that starts the
> programming operation and everything works fine except the security
> bit doesn't get programmed.

Yes.

It looks like I'm getting a PABT. I was messing with the loader script, so maybe I broke
something there. I'll investigate.

Thanks, Nick
Start a New Thread

Just testing new Email client/rules, please ignore

B rgds
Kris
Start a New Thread

If you find anything, I'd love to hear about it. I have the same
issue. It is in the flash page write routine so it is definitely
running from flash and only resets on the first write when it notices
the security bit isn't set.

Since it only happens once and it is in the factory, it's just a
nuisance, but I hate these little mystery anomalies.

>
> Yes.
>
> It looks like I'm getting a PABT. I was messing with the loader
script, so maybe I broke
> something there. I'll investigate.
>
> Thanks, Nick
>

Start a New Thread

I meant to say it is definitely running from RAM.
> If you find anything, I'd love to hear about it. I have the same
> issue. It is in the flash page write routine so it is definitely
> running from flash and only resets on the first write when it notices
> the security bit isn't set.
>
> Since it only happens once and it is in the factory, it's just a
> nuisance, but I hate these little mystery anomalies.
>
> >
> > Yes.
> >
> > It looks like I'm getting a PABT. I was messing with the loader
> script, so maybe I broke
> > something there. I'll investigate.
> >
> > Thanks, Nick
>
Start a New Thread

--- In A..., "jellybean10025" wrote:
>
> > If you find anything, I'd love to hear about it.

My code simply does a reset when it returns. I found that moving the reset command to the
RAM code works around the PABT:

__attribute__ ((long_call, section(".ramcode"))) void setSecurityBit() {
AT91C_BASE_MC->MC_FCR = (0x5A << 24) | AT91C_MC_FCMD_SET_SECURITY;
while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));
AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PROCRST |
AT91C_RSTC_PERRST;
}
I really don't have a clue as to why the PABT occurs. My other flash programming routines all
work fine.
Start a New Thread

I have an answer for that one. Put something like this in the code:

while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP);

Then it will wait for the command to complete before it starts reading
commands from flash again.

But this line hangs for me. I wonder if I'm checking the wrong bits.
> My code simply does a reset when it returns. I found that moving
the reset command to the
> RAM code works around the PABT:
>
> __attribute__ ((long_call, section(".ramcode"))) void setSecurityBit() {
> AT91C_BASE_MC->MC_FCR = (0x5A << 24) | AT91C_MC_FCMD_SET_SECURITY;
> while (!(AT91C_BASE_MC->MC_FSR & AT91C_MC_FRDY));
> AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PROCRST |
> AT91C_RSTC_PERRST;
> }
> I really don't have a clue as to why the PABT occurs. My other
flash programming routines all
> work fine.
>

Start a New Thread