STM32F429 lockup

[chichkinei]

Posted on May 25, 2014 at 04:25

My STM32F429 seems to be stuck in a lockup state. When I start the debugger in TrueSTUDIO, it halts in startup_stm32f429.s at the second instruction in the Reset_Handler. I'm unable to step through the code at all. I tried stepping through the with the stlink utility, but I get a message at the bottom saying either ''halted'' or ''lockup''. All of the registers read as 0x(null). How do I get out of this lockup state?

#lockup

[os_kopernika]

Posted on May 26, 2014 at 02:16

1. I do not know Atollic.

2. ''Lockup'' is the name of the state a uC enters when it cannot recover. Because ARMv7M is really good at recovering from all messy scenarios but when you provoke it to do something really fatal (like for example if you tell it a HardFault IRQ is located under nonexistent address) then there is really not much it can do when it needs it. So it enters lockup state. ''How do I get out of this lockup state?'' The point is the state is named ''lockup'' because you cannot get out of this state. It is an unrecoverable state. If it enters lockup  state instantly at reset then most likely

• you didn't provide a valid reset routine address (that is pointed by 0x4) or
• the address itself is valid but the reset routine starts from junk and
  • HardFault address (that is under 0xC) to report it is not valid or
• the first op-code of reset routine accesses stack and you forgot to provide a valid SP location (that is under 0x0)
• etc.

Many ways to enter lockup state. The fastest way to leave it is to RTFRM.

[jj2]

Posted on May 26, 2014 at 09:45

Believe poster, ''Brutte'' makes good points.

Beyond that - unstated is the history of your board/MCU - had it ever worked?  If so - is it not likely that you entered some invalid code - or have otherwise confounded the normal start-up mechanism?  Our group always uses ''real/external'' pull-up Rs on SWD/JTAG lines - often inadequate signal levels may cause/contribute to such a condition... Should the board be custom/new - any/everything is possible - you have entered the world of, ''maximum randomness'' and everything is suspect.  Systematic check/analysis - pin by pin (starting w/power) is then required... Our group never builds just one prototype.  Again - unstated - is whether this is famed, ''single board anomaly.''  ''One-off'' fixes are not especially enjoyable - nor beneficial to the community...

[chichkinei]

Posted on May 27, 2014 at 01:17

Ok, I somehow managed to fix the MCU. I tried putting while(1); as the first line in main() and the debugger went to main as it was supposed to. I removed the while(1); and it went back into a lockup. Then I started moving the while(1); further into the code and re-flashing until I eventually got it to the end of main() (where I already had a while(1);) and it still worked fine. I have no idea how this fixed the problem. Just before doing all this I set the flash readout protection to level 1 and then back to level 0 where it was originally; I don't know if this had any effect.

I'm not sure what you wanted me to check out in the ref. manual; unless you were just suggesting that I don't try out new code willy-nilly without thinking about the consequences. (ie. don't get a lockup in the first place) Yes, the board was working fine before. I believe the lockup may have been caused by some crude SDRAM code I was working on, which may or may not have caused a bus contention.

[chichkinei]

Posted on May 27, 2014 at 01:18

double post... bloody forum software