3 Replies Latest reply on Nov 12, 2013 2:27 PM by userc_2164
      • 1. Re: Debugger stops working on certain libraries...
        Does restarting the Eclipse WICED IDE change the behaviour?

         

        Weve not seen this behaviour reported previously.
        • 2. Re: Debugger stops working on certain libraries...
          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.
          • 3. Re: Debugger stops working on certain libraries...
            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?
            • 4. Re: Debugger stops working on certain libraries...
              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.