Reset Behavior

--- In A..., "jellybean10025" wrote:
>
> Then I think you need to be looking elsewhere as Eric is suggesting.
>
> The code I posted absolutely works. It is in thousands of our
> production units and we do software updates frequently.
>
> There must be something else going on here.

Thanks for the info. You (and Eric) are probably right. I wish I could find it!

The workaround (jumping to the reset vector in flash) does seem to work reliably, so I guess
we could go with that.

Thanks to everyone for your suggestions!

- Nick
Start a New Thread

I have been thinking about your problem for a couple of hours without
finding the reason.

But something is disturbing me.
According to the documentation, as soon as you assert

AT91C_BASE_RSTC->RSTC_RCR = ((0xA5 << 24)
| AT91C_RSTC_PERRST
| AT91C_RSTC_EXTRST
| AT91C_RSTC_PROCRST);

the ARM is in Reset state and you should not be able to execute

while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP);

or even

((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash
(0x00100000)

That's why I am thinking that your problem could be in the initialization
sequence, which should be at address 0x0000000 in flash ....

Eric.

-----Mensagem original-----
De: A... [mailto:A...] Em nome de Nick
Howes
Enviada em: mardi 27 janvier 2009 21:20
Para: A...
Assunto: [AT91SAM] Re: Reset Behavior

--- In AT91SAM@yahoogroups .com,
"jellybean10025" wrote:
>
> Then I think you need to be looking elsewhere as Eric is suggesting.
>
> The code I posted absolutely works. It is in thousands of our
> production units and we do software updates frequently.
>
> There must be something else going on here.

Thanks for the info. You (and Eric) are probably right. I wish I could find
it!

The workaround (jumping to the reset vector in flash) does seem to work
reliably, so I guess
we could go with that.

Thanks to everyone for your suggestions!

- Nick Start a New Thread

Hi Eric,

The "workaround" code is:

AT91C_BASE_RSTC->RSTC_RCR = (0xA5 << 24) | AT91C_RSTC_PERRST |
AT91C_RSTC_EXTRST; //reset the peripherals and remap
while ((AT91C_BASE_RSTC->RSTC_RSR) & AT91C_RSTC_SRCMP); //wait for reset to complete
((void(*)(void))0x00100000)(); //transfer control to reset vector in Flash

Note that I'm not trying to reset the processor, just the peripherals.

That said, I'm starting to think that this working is probably a fluke and that there must be
something not quite right in my crt0.s code and/or "LowLevelInit" code. I'm hoping to get a
block of time to look at it again tomorrow.

- Nick
Start a New Thread

Well, I checked my startup code against the latest from Atmel (at91lib-1.4-at91sam7xc-ek).
There were a few minor differences, so I changed my code to match, and it made no
difference. At this point, I have to get on with other stuff - the workaround seems reliable
and that's what we're going with. I wish I understood what was happening.

Start a New Thread

--- In A..., Nick Howes wrote:
>
> I'm trying to figure out the reset behavior of my AT91SAM7XC256 :

I'm embarrassed to say that (perhaps unsurprisingly) this turned out to be a bug in my code. Thanks for everyone's help and sorry for the waste of bandwidth.

Start a New Thread

> I'm embarrassed to say that (perhaps unsurprisingly) this turned out to be a bug in my code. Thanks for everyone's help and sorry for the waste of bandwidth.

Now that I've read this whole thread, I'm curious where the bug did
lie. And how did you find it? Just curious.
Start a New Thread

> Now that I've read this whole thread, I'm curious where the bug did
> lie. And how did you find it? Just curious.

Hi Matt,

Part of my reset handler checks to see what type of reset occurred,
and part of this code examines certain RAM locations. Originally,
these RAM locations were defined as a separate memory in the ld
script. At some point, the ld script was rewritten and these RAM
locations became just another section in the RAM - this meant that
their absolute addresses could change from build to build. This led
to the wrong type of reset being detected, bad assumptions about the
memory state being made, and the code going off in the weeds.

Like most bugs, it seems embarrassingly simple - so obvious in
hindsight. I eventually found it just by thinking about the problem
after it had reared it's ugly head again - one of those eureka moments.
- Nick
Start a New Thread