CODEWITHSUNDEEP
embeddedstm32keil
goodman
goodman

Reputation: 127

"Could not stop Cortex-M device" error when attempting to debug STM32F205ZG

I am having trouble running the debugger on a STM32F205ZG using µVision4 and the ULINK2. I keep getting the error message "Could not stop Cortex-M device! Please check the JTAG cable." I am using the SW port. Any help with this would be greatly appreciated.

Upvotes: 2

Views: 6141

Answers (4)

Simon Schüpbach
Simon Schüpbach

Reputation: 2683

Just an other issue with this message:

We have the same error message, but the problem was the wrong state of the RESET line.

Upvotes: 0

Maxwell Weru
Maxwell Weru

Reputation: 463

I had this problem on LPC4337. I tried all the solutions people are talking about but the only one that worked for me was using a lower processor clock so that JTAG/SWD interface can match/catch up with the processor before it is gone too far into executing user code. In my case I set JTAG/SWD clock in Keil uVision 5 to 10MHz and the changes the processor clock divisors to give 36MHz. With these settings, it never missed to capture on reset when I begin a debug session.

This happens for ULink2 but ULINK Pro and ULINK Pro-D support a JTAG/SWD <= 50MHz. See this link for more comparisons: ulink comparisons

Upvotes: 0

freewave
freewave

Reputation: 33

I've seen the same problem with my NXP uC.

The problem was that the code loaded in flash was faulty and was placing the CPU into a busy loop branching back to the same address, this prevented the debugger accessing the bus.

the uLink worked if I put the device into ISP mode as it never got to the user code.

it seems that uLink takes too long to halt the device after reset, the spec tells you this somewhere, so by the time uLink tries to halt the CPU it is too late as it cannot access the bus and locks up.

Upvotes: 2

user0118999881999119725 3
user0118999881999119725 3

Reputation: 338

In my own experience I have usually seen this error when either the ULINK2 is disconnected and reconnected while in the middle of a debug session or if you have some external hardware, outside of the control of the debugger, that is acting on your processor.

If the ULINK2 was disconnected mid-debug, then usually cycling power to your device will fix the problem.

If you have something like a watchdog timer that is trying to reset the processor while you are in the middle of debugging, then you will have to disable the watchdog before you can start a debug session.

Upvotes: 2

Related Questions