Posts by pruesch

this is a bug in gdb client. it has been reported multiple times but did not find its way into it.

recent discussion:
https://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 a huge leap, congratulations for that! I really like the results of it!
your interaction with this forum is remarkable and very welcome at our side


hope this Proof of Example can find its way into one of the next stable versions.

Best Regards
Peter

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:

[developer@localhost JLink_Linux_V541g_x86_64]$ sudo strace ./JLinkGDBServer_beta
execve("./JLinkGDBServer_beta", ["./JLinkGDBServer_beta"], [/* 22 vars */]) = 0
brk(0)                                  = 0x1007000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70cbbe5000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70cbbe4000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f70cbbe3000
arch_prctl(ARCH_SET_FS, 0x7f70cbbe4680) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
+++ killed by SIGSEGV (core dumped) +++
[developer@localhost JLink_Linux_V541g_x86_64]$

I tried to LD_PRELOAD=libjlinkarm.so.5 but still the same.

maybe this causes my error:

[developer@localhost JLink_Linux_V541g_x86_64]$ file JLinkGDBServer
JLinkGDBServer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
[developer@localhost JLink_Linux_V541g_x86_64]$ file JLinkGDBServer_beta 
JLinkGDBServer_beta: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), stripped

I'm trying this on CentOS 6.7

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?

maybe setting up some breakpoint register and making a branch to lr?

edit:
I think we got a bit confused here about the lr offsets. the stacked lr is indeed at offset 20(!). but in the current scenario, we are more interested to restore the stacked pc!
and this is at offset 24.

I tried to use the stacked lr

__asm volatile(" tst lr, #4    \n"   );
 __asm volatile(" ite eq        \n"   );
__asm volatile(" mrseq r0, msp \n"   );
 __asm volatile(" mrsne r0, psp \n"   );
__asm volatile(" ldr lr, [r0,#20] \n" ); //use the stacked lr

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:
https://www.element14.com/community/thre…-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:
http://www.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 decision to use segger tools now and in the future

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:

Received symbol: OS_Global (00000000)
ERROR: Received mandatory symbol not found.

these are the parameters to run JLinkGDBServer:

./JLinkGDBServer -if swd -device STM32F429VG -endian little -speed 1000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -strict -timeout 0 -nogui -rtos GDBServer/RTOSPlugin_FreeRTOS.so

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: https://www.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 ?

SEGGER_SYSVIEW_SendSysDesc("I#15=SysTick");
SEGGER_SYSVIEW_SendSysDesc("I#36=ISR_CAN");
SEGGER_SYSVIEW_SendSysDesc("I#77=ISR_Eth");

why is it important for you to keep it in one call?