Anonymous
Not applicable
Nov 07, 2013
06:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 07, 2013
06:53 AM
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
Labels
- Labels:
-
Debug
- Tags:
- application
- bcm943362wcd4_evb
- capabilities
- debugger
- debugging
- folder
- grows
- inspect
- larger
- libraries
- limitations
- losing
- memory
- netx-duo
- single
- slowly
- snip
- stack
- step
- stops
- variables
- windows
- working
- writing
4 Replies
Anonymous
Not applicable
Nov 11, 2013
08:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 11, 2013
08:37 PM
Does restarting the Eclipse WICED IDE change the behaviour?Weve not seen this behaviour reported previously.
Anonymous
Not applicable
Nov 12, 2013
07:46 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 12, 2013
07:46 AM
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.
Anonymous
Not applicable
Nov 12, 2013
08:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 12, 2013
08:31 AM
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?
Anonymous
Not applicable
Nov 12, 2013
02:27 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nov 12, 2013
02:27 PM
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 debugPlease 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.