This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

software reset which allows remap

Hi

Target : AT91R40008
Bootloader : own
Main : will be someone else's

What is the best s/w only way to 'unmap' ?

I need main to be able to drop into my bootloader which starts by remapping stuff, and I want the bootloader to assume that SRAM is at 0x300000 (in case main has screwed up the remapped ones) for remapping purposes, just as it has to during a genuine powerup.

But if I just jump directly from main to my (flash boot) reset vector, it can't use 0x300000 because it's been mapped already.

I could maybe force a watchdog reset which would apparently do this job, but is there a cleaner way ?

  • I really think that the watchdog reset is among the most clean ways to get back to a boot loader. A reset is the only way that the boot loader can know the state of the processor.

  • ok, but what if I also want to distinguish between a watchdog reset and a s/w initiated reset ?

    Is there really no other way to 'reset' from assembler ? It might be very simple - am new to this processor.

  • To my knowledge, there are no other internally trigged reset, unless you can possibly abuse a brownout reset.

    Create a variable that isn't cleared on reset. Fill it with a magic value when you manually request a watchdog reset.

    At startup, check if it was a watchdog reset or a normal reset. If a watchdog reset, check your variable for a magic value. After the check, clear the variable so a "real" watchdog reset doesn't get falsely detected as a forced watchdog reset.

  • most modern derivatives have a "reset reason" SFR.
    As far as I recall ALL SILabs do and most newer NXPs do.

    Erik

    PS read the datasheet, there is more to it than just reading a bit.

  • Yes, the processor has a reset reason register (RSIR - Reset Source Identification Regiseter). But that wasn't his question. His question was how he can differentiate between an intentional watchdog reset and an unintentional one. Hence, my suggestion to first check the reset reason register if it was a watchdog reset, and then check the "magic" variable to see if the watchdog reset was intentional.