Debugger stops working on certain libraries...

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

I am writing an application under the snip  folder, and I have been slowly losing debugging capabilities (cannot single step, inspect variables, etc.) as the application grows larger. Are there certain memory limitations after which the debugger stops working? (I am using the BCM943362WCD4_EVB under Windows and the Netx-Duo stack).

Thanks

0 Likes
4 Replies
Anonymous
Not applicable
Does restarting the Eclipse WICED IDE change the behaviour?

Weve not seen this behaviour reported previously.
0 Likes
Anonymous
Not applicable
Does restarting the Eclipse WICED IDE change the behaviour?

Weve not seen this behaviour reported previously.

No. I can debug until I get to my application module, and then all debugging context disappears. Breakpoints work, but when I get there I cannot inspect any variable, not even the processor register settings. Its as if the communication with the host debugger has been broken, and I am wondering if it has anything to do with the stack size or memory usage.
0 Likes
Anonymous
Not applicable
No. I can debug until I get to my application module, and then all debugging context disappears. Breakpoints work, but when I get there I cannot inspect any variable, not even the processor register settings. Its as if the communication with the host debugger has been broken, and I am wondering if it has anything to do with the stack size or memory usage.

Found a couple of clues:

1. If you reduce the app thread stack size from the default 6144 to 4096, things start working again...

2. When the stack is 6144, the debugger stops working as soon as you create the thread, and before you start the application.

Maybe certain memory locations used by the debugger are overwritten?
0 Likes
Anonymous
Not applicable
The Debugger does not use up memory on the device. It only observes and controls the CPU and allows inspection of memory.

Some of the things that may cause this type of thing:

* Too many breakpoints - There are only a restricted number of hardware breakpoints available. (This number is processor dependent) If you insert too many, the debugger will not step to the next line, also the debugger may fail to start.

* Overwritten RTOS thread-structures or overwritten stacks - The debugger reads the lists of thread structures to determine what threads are currently running, then reads the stack of each to get the stack trace. If any of these are corrupted then the debugger may behave erratically.  These can be corrupted by blown stacks, buffer overruns, bad pointer dereferencing etc.

Can you reproduce this in a WICED example app? e.g. by adding a huge amount of pointless code?

Please try debugging with the GDB command-line debugger by doing:

./make <your_target_string>  download debug

Please also try the following:

1) ToolsOpenOCDWin32openocd-all-brcm-libftdi.exe -f ./Tools/OpenOCD/BCM9WCD1EVAL1.cfg -f ./Tools/OpenOCD/stm32f2x.cfg -f ./Tools/OpenOCD/stm32f2x_gdb_jtag.cfg

( This will stall waiting for a debugger to attach)

( Assuming you are using a STM32F2xx )

2) Now run your debug session in eclipse. You should see information being printed in the OpenOCD window.

    The information may help identify the problem. Please send us the output from OpenOCD.  Then re-run, adding option  -d3  and send that information too.
0 Likes