"Cannot stop CPU" error message

Follow

Comments

7 comments

  • Avatar
    Andy Heilveil

    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.

  • Avatar
    Paul Curtis

    ...or you can just leave STARTUP_FROM_RESET undefined (default state) which means it won't run user code to nuke the JTAG connection.

  • Avatar
    Andy Heilveil

    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.

  • Avatar
    Paul Curtis

    ...or just put a 5s delay in instead of the infinite loop...

  • Avatar
    Shotaro Kikugawa

    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.

  • Avatar
    Shotaro Kikugawa

    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.

  • Avatar
    strawbot

    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.