Why am I getting a "Cannot stop CPU" error message?
This error message is displayed when the debugger is unable to make the ARM stop running and enter debug mode typically after carrying out a reset. This error message could be caused by the following:
- Unreliable JTAG/SWD Connection — Try reducing the JTAG/SWD clock frequency or reducing the target interface's cable lengths as much as possible.
- Incorrect support package — Make sure you are using a CPU/board support package intended for your part.
- Incorrectly connected reset signals — Typically the nSRST signal should be connected to the target's core reset signal, it should not be connected to the JTAG TAP reset (TRST) signal.
- Invalid code has been executed — This may be caused by your program not being loaded correctly, a problem with the target's memory or a bug in your program. You can check the download and memory by verifying the download.
Comments
7 comments
The only way I have been able to get past the message on an stm32 is to use the boot pins to startup in the rom bootloader, at which time the debugger starts working and I can with a bit more stumbling erase the problematic code and force good code into the system.
...or you can just leave STARTUP_FROM_RESET undefined (default state) which means it won't run user code to nuke the JTAG connection.
True, but if the failing program was compiled to startup from reset then a little more brutish force is needed to recover :)
I by default startup from reset as my board does in its startup some things that other members of the troupe find useful for debugging their attached hardware, even when the rest of my app has bugs. The number of times I have been stopped by things like "Cannot stop CPU" are far fewer than I used to get "why doesn't the board do anything when I plug it in". Having more bread boards to share around would be the best of both worlds.
...or just put a 5s delay in instead of the infinite loop...
I get this problem to happen if I do a bunch of consecutive writes to flash or EEPROM memory space, notably on an STM32L152xx and I am using ST's peripheral library.
After some investigating, I'm lead to believe it's a data alignment issue. I reran the same routine, but the addresses are always 4-bytes apart, even if the data size is less than that.
I also found that some STM32 parts don't have EEPROM, but flash under an EEPROM emulator (http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00165693.pdf ). I'm not sure if this applies to my part though.
Nothing here helped in my case. I'm using a solution/project/code generated by STM32CubeMX. I am designing for a low power solution. In the STM32CubeMX designer, there is an option for the code generator to set all free pins as analog to optimize the power consumption. When that option is checked, the debugger fails and one has to power cycle the board. Most likely because the debug pins are reassigned by this option. It drove me crazy trying to find it. But now I am wiser. I believe this was also messing with my I2C outputs too. Because now they work and so does the debugger when I turn off that option.
Please sign in to leave a comment.