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.
Try to reduce the JTAG clock speed. See also here: http://www.keil.com/support/docs/3177.htm
Thanks for your response. I had a go at changing the JTAG clock speed with different clock speeds but I still get the same error message.
Have you tried to select JTAG as communication method? Is the Device ID correctly shown in the ULINK configuration dialog?
I have tried the JTAG configuration and it comes up with "No JTAG Devices Found". Using SW it shows 0x2BA01477 in the IDCODE and ARM CoreSight SW-DP as the Device Name. I am not sure how to check if this is the correct IDCODE. The STM32Fxxxx reference sheet has 0x4BA00477 (ARM Cortex-M3 r2p0 ID Code) in the IDCODE data register details, I assume this could change between revisions.
From the manual: http://www.keil.com/support/man/docs/ulink2/ulink2_errors.htm
Could not stop Cortex-M device The debugger tries to stop the target. This attempt can be made after initializing the connection, or while resetting the target, or through a stop/step command while debugging. In some cases, the target's debug block not functioning properly raises this error.
It looks like the debug block of the device is disabled somehow. Can you try with a different device? Have you programmed something into that device? Some devices have a feature to disable debugging (basically this is a device lock function).
CRP enabled...?
It isn't just copy-protection that can break the JTAG interface.
One thing with debugging is that it is good if debugged applications always has an initial delay before actually starting to play with the hardware.
In case a downloaded application configures the clocking incorrectly and hangs the processor it can also kill the JTAG interface. With an initial delay, you get a window after reset where the JTAG interface can get in contact with the processor and block the program from reaching the invalid code.
try unchecking options for target>Uililties>settings>Reset and run. (keep the clock speed low)
That will leave the chip in its 'native state' and ulink will connect unless you have a hardware error. whether this allow you to see the effects of 'step into' (once) should deternine the course of action
Erik
(keep the clock speed low) refer to the JTAG clock, 1MHz should be good
Thanks to everyone that has posted a response. I'm sorry I have been unable to reply to anything for a few days. Here are a few replies for some of the questions people have asked:
"Can you try with a different device? Have you programmed something into that device?"
The device I am using has previously been programmed with code for the application I am developing. This code essentially works, there are a couple of bugs though which is what I am trying to figure out. I have erased the device before trying to debug the code but this makes no difference. I am trying to get my hands on a device that hasn't previously been programmed.
"In case a downloaded application configures the clocking incorrectly.."
As above: the application code has already been programmed to the board and does run, it's just that it wont debug. Someone else that used to work on this application has managed to debug the code before but I am no longer in contact with him which is why I am stuck trying to get this to work.
"try unchecking options for target>Uililties>settings>Reset and run (keep the clock speed low) refer to the JTAG clock, 1MHz should be good"
This has already been tried without success, the 1MHz JTAG clock speed is the default. I have tried slower speeds (with Reset and run checked and unchecked) which made no difference.
"CRP enabled..."
Not as far as I am aware but I am very new to embedded systems development. I am hoping when I get a device that hasn't been previously programmed it will give me a better insight into what is happening.
I know this post is quite old now but I have found a resolution for my problem. It turns out the ulink2 was faulty, when I managed to get hold of a different ulink2 and tried that I managed to get the debug working. Thanks to everyone for their help.
Actually I've seen this behaviour a few times on NXP devices using uLink, and have been able to erase and re-program them with LPCXpresso, after which the uLink works fine.
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.
so it may be that the uLink was not faulty, but the timing was simply marginal.
a simple fix is to code a delay in your startup code long enough to guarantee that uLink can stop the CPU before it crashes.
regards
Phil.
Thanks Phil, I will remember this if the problem repeats itself.
I remembered a bit more now, I was generating an exception which was not handled causing the default handler to be called, this is simply a branch back to itself which seems to hang the bus. I modified the default handler to have a small loop with nop instructions instead of a branch back to itself so that the debugger can gain access.
since then I haven't needed to use the LPCXpresso .
Good post you guys! Thanks for the info. I'm sure I'll need it in the future.
Bradford