Search Results

this is a bug in gdb client. it has been reported multiple times but did not find its way into it. recent discussion: bugs.launchpad.net/gcc-arm-embedded/+bug/1566054

would it make sense to use this kind of stack unwinding also for normal interrupts? I would like to see in the unwound call stack where I will resume execution when I return from the ISR. did you think about that before? to clarify my thoughts, take a look at the attached picture. it shows the callstack before and after stepping out of the ISR. best regards

Hi Arne, I tested the binary you supplied. It's perfect! For a test, I hardcoded the SIGFPE (#8 ) Signal which is shown in the debugger view in eclipse. perfect! after the excpetion, the pc points at the exact instruction which caused it. perfect! it is do be discussed what amount of exception identification can be done on the target / gdb server. I find your suggestion with different "bkpt #X && bx lr" combinations great. during the last weeks, you winded up the quality of embedded debugging by…

Hi Arne, thank you very much for your effort! I'm very impressed how fast our conversation lead to this :) and you even built a linux binary! great! I will try it soon. would it be possible to have the gdb server evaluate the core's fault register the determine which kind of fault occurred and set the immediate value dynamically to display it in the debug view? best regards Peter unfortunately, I'm having some trouble getting the GDBServer running: Difference-File (11 lines) I tried to LD_PRELOA…

ooookayy... it seems like I used the wrong offset to get the stacked lr from the stack frame. I was confused because the this hardfault handler uses offset 5 as lr... if I take the lr pc with an offset of 24 bytes, and write it to the lr, the call stack is even more beautiful once the breakpoint instruction is hit. see the attached screenshot. how can I make the debug view focused on that lr address? like manipulating the pc and trigger another breakpoint after one instruction, is that possible?…

I tried to use the stacked lr C Source Code (5 lines) but this did not produce good results. for now, I'm getting the best results when I write the actual msp/psp to the sp. what is your impression?

I'm not 100% sure what you mean. should write the stacked sp into lr ? or write the current msp/psp into lr ?

Hi, I wrote a short article about it and how far I got: element14.com/community/thread…-debugging-of-hard-faults I haven't tried your debugging solutions for a long time. maybe I should try again.

nice, thanks for your fast answer. please be aware that this problem also exists with 5.41g (beta)!

now I have the same problem. using the launchpad gcc arm none eabi toolchain. just upgraded and facing this problem. for me, it seems like the gdb 7.10 won't stop on a bkpt instruction. It somehow leads to an endless loop of halt and run at the gdb server side and renders it unresponsive. choosing a different gdb version seems to fix the problem.

Hi, might it be possible to integrate the ability to get a stack unwinding when a fault triggers? someone has done it before, in a java based gdb extension: codeconfidence.com/freertos-tools.shtml

yes, eclipse, even the mars.2 release, is far from perfect. I noticed that the full call stacks appear again if you switch the perspective to c/c++ and back to debug. what issues did you experience? were you able to find workarounds for some of them? I'm really happy that you decided to implement thread awareness into your gdb server. It's also very nice that you support OSX and Linux! Your competitors don't seem to understand that need :) This confirms our conviction to have made the right deci…

yes, we are using Linux (more specific CentOS 6.7) thank you very much for your super fast reply and the patched library! the plugin works now! I 'm back to the usual eclipse trouble when it comes to displaying the call stacks of various threads :(

Hi Arne, please see my edited post above BR strings like "pxCurrentTCB" and other symbols are not part of the RTOSPlugin_FreeRTOS.so but contained in the windows dll. maybe there is something missing :)

could you please print what symbol the rtos plugin is missing? edit: I'm using the FreeRTOS plugin, but embOS symbols are requested: C Source Code (2 lines) these are the parameters to run JLinkGDBServer: C Source Code (1 line)

Hi, if you print to the sysviewer terminal like this SEGGER_SYSVIEW_Print("this is a text\n"); the displayed text is not centered in the line which some how looks odd. maybe the trailing "\n" should be removed before the text is displayed in the sysviewer terminal. see the attached screenshot for more details.

The new beta of JLinkGDBServer just got released with the support for Thread Awareness: Quote: “- GDBServer: Implemented support for thread debugging with RTOS by using a plug-in ” The manual says there is a plugin needed:Quote: “RTOS plug-ins for embOS and FreeRTOS are available from our website: segger.com/jlink-software.html. ” my problem: I cant't find the plugin on the stated website. where to get it ? thank you very much!

Hi, in the SystemView Documentation you suggest: Quote: “To get the best results INCLUDE_xTaskGetIdleTaskHandle INCLUDE_pxTaskGetStackStart should be defined as 1 in FreeRTOSConfig.h. ” INCLUDE_pxTaskGetStackStart does not exist in FreeRTOS and you also don't seem to use it in your systemview code for the target. BUT you do use the symbol "INCLUDE_uxTaskGetStackHighWaterMark" which is probably important to note as recommended in the documentation.

Hi Johannes, thanks for the hint. It looks aceptable but one thing worth mentioning: SEGGER_SYSVIEW_Start() can not be called before the FreeRTOS scheduler is started. otherwise assertions will trigger because the "syscall from isr with too high priority" will be matched.

why don't you split it up in multiple calls ? C Source Code (3 lines) why is it important for you to keep it in one call?