SparkFun Forums

[SodaAnt]

I'm working on a project using an LPC1768 running at 100MHz interfaced to various sensors and an LCD for output. I've completed development of the code and have been running the hardware for days at a time to root out any issues that only appear after running for long periods (e.g. memory fragmentation, stack underflow, etc.) I start the code running on the board under the Rowley CrossWorks debugger so I can periodically break into the debugger to examine data structures, set breakpoints, single step the code, etc.

When I do this, everything runs fine for a day or so, and then the debugger seems to loose its ability to single step code and stop at breakpoints. Most other debugger functionality continues to work normally: I can examine memory and registers, look at data structures, etc. If I set in breakpoints in code that's known to execute (based on hardware behavior), they are never taken, although the processor continues to execute code in the sections where breakpoints have been set.

A similar thing happens when I try to single-step the code. Invoking any of the single step commands (Step Into, Step Over, Run to Cursor) cause the processor to start free running from that point rather than stepping one C statement (or one assembly instruction in Disassembly mode).

This behavior is consistently reproducible: simply run the board under the debugger for more than 1-2 days and it will sooner or later loose the ability to stop at breakpoints or single step code. Needless to say, this is impacting my ability to debug issues that only occur after the system has been running for long periods.

Has anyone seen this behavior? Any idea of what may be happening or workarounds to fix the problem? I've reported this to Rowley tech support, but haven't received a response yet.

Software: Windows XP SP3, Rowley CrossWorks for ARM 2.0.5
Hardware: LPC1768 @ 100 MHz, Segger J-Link

[paul_l_curtis]

I'm not sure whether the J-Link supports "attach debugging" without resetting the part. The CrossConnect will connect to a running target to enable after-the-fact debugging without reset.

You can disconnect the JTAG interface (physically) and close CrossWorks. Leave your board for a while. Then load up CrossWorks, load up the project the board is actually running. Then...

1. Connect JTAG probe physically

2. Connect the JTAG interface at the user interface level by double clicking in the Targets window. [Note: this could be when a reset happens on the J-Link, and defeats this scheme]

3. Choose Target > Attach Debugger. This will attach the debugger to the running target over JTAG.

4. Choose Debug > Break.

The processor will now be stopped and you should be able to single step.

Note that the heap uses a simple best-fit algorithm. If you wish to have a real-time heap that performs better wrt fragmentation, then please contact me to get our implementation of a binary buddy heap for CrossWorks.

Regards,

-- Paul Curtis

[SodaAnt]

Paul,

Thanks for the reply. The "Attach Debugging" command works with the J-Link and it resolves my issues with loosing the ability to use breakpoints and single-stepping. Now that I have a workaround (thanks!), any idea why single-stepping and breakpoints stopped working in the first place? This is repeatable every time, so it's not a one-time glitch.

[paul_l_curtis]

Paul,

Thanks for the reply. The "Attach Debugging" command works with the J-Link and it resolves my issues with loosing the ability to use breakpoints and single-stepping. Now that I have a workaround (thanks!), any idea why single-stepping and breakpoints stopped working in the first place? This is repeatable every time, so it's not a one-time glitch.

Could be something to do with timer wrap or something in CrossStudio. Who knows? I don't think I've ever run CrossStudio on a PC connected to a target over a couple of days. I've had CrossStudio running for a day or so, but I usually turn of my PC at the end of the day.

[evarobotics]

I've used crossworks extensively with ARM on Atmels and Luminary chips - but never for more than a few hours at a time.

On the Atmel SAM7's they only had 2 hardware breakpoints (from memory ) and I remember crossworks always had trouble managing them. It would show breakpoints in the debugger but if you had previously used two within that debugging session then it would not reallocate them. From memory it got worse and worse until a full reboot was required.

Sorry - no solution but maybe it helps if you know we share your pain.

[paul_l_curtis]

... It would show breakpoints in the debugger but if you had previously used two within that debugging session then it would not reallocate them. From memory it got worse and worse until a full reboot was required.

And how long has that bug been corrected for? An no, it never required a full reboot. It would require you to disconnect and reconnect, but no PC reboot was ever required.

[funkbird]

I'm working on a project using an LPC1768 running at 100MHz interfaced to various sensors and an LCD for output. I've completed development of the code and have been running the hardware for days at a time to root out any issues that only appear after running for long periods (e.g. memory fragmentation, stack underflow, etc.) I start the code running on the board under the Rowley CrossWorks debugger so I can periodically break into the debugger to examine data structures, set breakpoints, single step the code, etc.

When I do this, everything runs fine for a day or so, and then the debugger seems to loose its ability to single step code and stop at breakpoints. Most other debugger functionality continues to work normally: I can examine memory and registers, look at data structures, etc. If I set in breakpoints in code that's known to execute (based on hardware behavior), they are never taken, although the processor continues to execute code in the sections where breakpoints have been set.

A similar thing happens when I try to single-step the code. Invoking any of the single step commands (Step Into, Step Over, Run to Cursor) cause the processor to start free running from that point rather than stepping one C statement (or one assembly instruction in Disassembly mode).

This behavior is consistently reproducible: simply run the board under the debugger for more than 1-2 days and it will sooner or later loose the ability to stop at breakpoints or single step code. Needless to say, this is impacting my ability to debug issues that only occur after the system has been running for long periods.

Has anyone seen this behavior? Any idea of what may be happening or workarounds to fix the problem? I've reported this to Rowley tech support, but haven't received a response yet.

Software: Windows XP SP3, Rowley CrossWorks for ARM 2.0.5
Hardware: LPC1768 @ 100 MHz, Segger J-Link

Hi all,

Here is my reply a few years after the original post, since I was having a quite similar problem. I am confident my solution will save a few people some headaches when googling for it and finding this thread (like I did).


In my setup, the connection loss occurred not after 1-2 days but after a few seconds. When I single stepped, the connection loss often occurred right after 2 or 3 steps (e.g. F11 key). If the problem occurred, most variables in the watch windows often interestingly jumped to values with all 0xAA, or sometimes, just breakpoints were ignored. I could find no log entries on my system indicating what was wrong.

My setup: I used a J-Link EDU USB Debugger with CrossWorks 2.0.7 on an LPC2368 eval board on a regular PC (Pentium 4 running at 3 GHz).

To solve the problem, I just put a NEC PCI-to-USB host controller (i.e. a PCI Card with a separate USB controller and a few USB connectors) into my system, and connected the J-Link EDU directly to this card. The card has no other USB devices connected to it. My USB mouse and other USB hardware remain connected to the USB sockets that belong to the main board of the PC.

This solved the problem completely, it never happened again.

My problem was most likely a defective USB setup of some sort, or a problem with some of the other USB devices that I use. I did not enquire further.

You can get such a PCI-to-USB controller for under 10 EUR at your favourite auction site!

Hope this helps....

Philipp