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

Debugger Influence on SRAM on Reset

I am porting legacy code from an LPC2103 to a
LPC1765 and have encountered an issue for which I
cannot find any documentation for (from Keil or NXP).

It seems the previous developer used SRAM on the
2103 to 'store' conditional flags to determine if
a watchdog reset occurred. When a watchdog reset
occurred by their design (ie: they wanted to
invoke a watchdog reset) a bit flag was set in a
variable declared within SRAM so that when the
application restarted the code would know to do
certain processes (Their design - not mine).

With the LPC1765 however the condition of the
SRAM after a BX to main within the ResetHandler shows
that SRAM is being reset to zeroes. I also removed both the ULINK and Keil debugger to see if they had a influence in this event - they do not seem to be the cause of this.

It has always been my understanding that after any reset the state of RAM is to be considered indeterminate.

Can you provide some information on how the debugger and/or ULINK handles the reset sequence (specifically SRAM) so that I can correct this problem accordingly.

Thank you.

0