Reset Behavior

I'm trying to figure out the reset behavior of my AT91SAM7XC256 :

One of the features of our product is that the firmware can be
upgraded. We have a firmware programmer routine that runs out of RAM
and programs the flash from data received over a comms link. It all
works fine if we cycle power at the end. But, if we try to reset the
device programmatically, via:
AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24) | AT91C_RSTC_PROCRST |
AT91C_RSTC_PERRST );
it usually goes off in the weeds.

We use the same reset technique in other code in the product and it
always works fine. It only seems to fail after new code has been
written to the flash.

I suspected a remap problem (we do remap the vectors to RAM), but
AT91C_RSTC_PERRST is supposed to clear remap (and other tests seem to
eliminate it as the culprit).

I've wasted a lot of time trying to figure this out and I've gotten
nowhere. Does anyone have any insight as to what might be happening?

thanks, Nick

Start a New Thread

Nick Howes schrieb:

> We use the same reset technique in other code in the product and it
> always works fine. It only seems to fail after new code has been
> written to the flash.

Maybe the Flash isn't reset and still in programming mode ?

--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

Start a New Thread

"42Bastian" d...@sciopta.com wrote:
> Maybe the Flash isn't reset and still in programming mode ?

That sounds hopeful, but as far as I know, for the AT91SAM7X, once
the programming is complete and FRDY in MC_FSR goes high, the flash
is ready for use. Maybe I'm missing something?

thanks, Nick

Start a New Thread

I should have also said that if I load the same code as is already in
the device, it resets OK. Also, if the code only has minor changes,
it also usually resets OK. Both of these made me suspect a reset
vector problem, but I can't see how.

Start a New Thread

Nick Howes schrieb:
> I should have also said that if I load the same code as is already in
> the device, it resets OK. Also, if the code only has minor changes,
> it also usually resets OK. Both of these made me suspect a reset
> vector problem, but I can't see how.

I not sure if your chip allows un-doing remap, if so: Did you try
undoing it before reset ?

BTW: Why not just start the new code w/o reset ?
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...

Start a New Thread

"42Bastian" d...@sciopta.com wrote:

> I not sure if your chip allows un-doing remap, if so: Did you try
> undoing it before reset ?

The documentation says:
"Writing PERRST at 1 resets all the embedded peripherals,
including the memory system, and, in particular, the Remap Command."

The documentation also says that remap can be toggled via:
AT91C_BASE_MC->MC_RCR = AT91C_MC_RCB;
I tried that to no avail.
> BTW: Why not just start the new code w/o reset ?
Mainly because I want to ensure that I'm starting in a known state.
But maybe I should try it and see what happens.
At this point, I also want to understand what the chip is actually
doing.
thanks, Nick
Start a New Thread

Hello 42Bastian,
I saw that you were making posts on the AT91SAM group, and I had a look at your company. Please can you explain in few sentences what is your company best at, and what are the main products. It looks to be a big company. For example, do you also make the hardware products, or only software? What are the software main points? Also, if you do not make hardware, then do you recommend the hardware for the job to run your software? Where are the your products used often and what are the stand out points?
Thank you and with regards,
Maziar Tasbihi

--- On Mon, 1/26/09, 42Bastian wrote:
From: 42Bastian
Subject: Re: [AT91SAM] Re: Reset Behavior
To: A...
Date: Monday, January 26, 2009, 10:27 AM

Nick Howes schrieb:

> I should have also said that if I load the same code as is already in

> the device, it resets OK. Also, if the code only has minor changes,

> it also usually resets OK. Both of these made me suspect a reset

> vector problem, but I can't see how.

I not sure if your chip allows un-doing remap, if so: Did you try

undoing it before reset ?

BTW: Why not just start the new code w/o reset ?

--

42Bastian

Note: SPAM-only account, direct mail to bs42@... Start a New Thread

This code works every time for me:

/////////////////////////////////////////////////////////////////
// Flash has been written now, so no calls except to RAM resident
/////////////////////////////////////////////////////////////////

pRSTC->RSTC_RCR = 0xA5000000 | C_RSTC_PROCRST | C_RSTC_PERRST |
C_RSTC_EXTRST;
while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
continue;

--- In A..., Nick Howes wrote:
>
> I should have also said that if I load the same code as is already in
> the device, it resets OK. Also, if the code only has minor changes,
> it also usually resets OK. Both of these made me suspect a reset
> vector problem, but I can't see how.
>

Start a New Thread

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

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

Well yeah, that makes perfect sense - I need to wait for the reset process to complete so that
it doesn't use the wrong vectors. It's quite obvious now that I know the answer!

Thank you very much!

- Nick
Start a New Thread

--- In A..., "Nick Howes" wrote:
>
> --- In A..., "jellybean10025" wrote:
>
> > while ((pRSTC->RSTC_RSR) & C_RSTC_SRCMP)
>
> Well yeah, that makes perfect sense - I need to wait for the reset process to
> complete so that it doesn't use the wrong vectors.

Well it seemed like this was the answer, but it hasn't solved my problem. :(

- Nick
Start a New Thread