ChibiOS Free Embedded RTOS

ChibiOS Web Boards
https://forum.chibios.org/

Trouble with RTOS support in GDB/OpenOCD

https://forum.chibios.org/viewtopic.php?t=1496

Page 1 of 1

Trouble with RTOS support in GDB/OpenOCD

Posted: Tue Nov 05, 2013 8:52 am
by genosensor
I've enabled RTOS support in GDB/OpenOCD with the openocd.cfg command:

Code: Select all

$_TARGETNAME configure -rtos auto

When I load up the application, the openocd log shows

Code: Select all

Info : Successfully loaded memory map of ChibiOS/RT target running version 2.6.1
Error: ChibiOS registry integrity check failed, NULL pointer
Info : Only showing current execution because of a broken ChibiOS thread registry.

This is OK, as ChiBiOS has not yet initialized itself.

However, after running to a later breakpoint, where two threads plus the idle thread exist,
when I issue the GDB command:

Code: Select all

(gdb) info thread
[New Thread 536872976]
[New Thread 536873672]
  Id   Target Id         Frame 
  3    Thread 536873672 (No Name :  : WTQUEUE) Remote 'g' packet reply is too long: 00000000000000000000000000000000414700080000000055555555ac0b00205555555555555555555555555555555500000000ac0b002000000000bf1300080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

At this point, the 'g' packet reply errors recur on every interaction with the target until gdb is exited.

I'm running:
gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision 202601] (GNU Tools for ARM Embedded Processors)
GNU gdb (GDB) 7.6.50.20131105-cvs
Open On-Chip Debugger 0.8.0-dev-00257-ga3c0f05 (2013-11-04-17:42)

Does anyone have this working?

Re: Trouble with RTOS support in GDB/OpenOCD

Posted: Tue Nov 05, 2013 9:09 am
by Giovanni
I haven't tested it for a while. The registry list is accessible only after executing chSysInit().

Giovanni

Re: Trouble with RTOS support in GDB/OpenOCD

Posted: Tue Nov 05, 2013 8:57 pm
by genosensor
Understood.

Could someone who has RTOS support working (or has had in working in the past) please provide the
versions of gcc, gdb and openocd that worked for them.

Also, the openocd configuration during build (what args were passed to configure before make?)
The openocd build configuration in my case was:

Code: Select all

./configure --enable-stlink --enable-arm-jtag-ew --enable-ft2232_libftdi

Next, the exact commands used to bring up the debugging session.

In my (non-working) case:

The file ./openocd.cfg:

Code: Select all

source ../stm32l-discovery/stm32l-discovery.cfg
$_TARGETNAME configure -rtos auto

gdb starts with the command:

Code: Select all

/cortex/bin/gdb  -x  start.gdb  binaryElfFile

where the start.gdb script is:

Code: Select all

target extended-remote :3333
set remote hardware-breakpoint-limit 6
set remote hardware-watchpoint-limit 4
load
monitor reset halt
tbreak chSysInit
continue
finish


The combined output from openocd and gdb is:

Code: Select all

brent@zardoz:~/git/charger/firmware/zev$ openocd &
[2] 19597
Open On-Chip Debugger 0.8.0-dev-00257-ga3c0f05 (2013-11-04-17:42)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.893909
brent@zardoz:~/git/charger/firmware/zev$ Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000aa0 msp: 0x20000400
STM32L: Enabling HSI
receiving debug messages from current target enabled
background polling: on
TAP: stm32lx.cpu (enabled)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000aa0 msp: 0x20000400
/cortex/bin/gdb -x ../stm32l-discovery/start.gdb build/zev.elf
GNU gdb (GDB) 7.6.50.20131105-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/zev.elf...done.
Info : accepting 'gdb' connection from 3333
Info : STM32L flash size is 128kb, base address is 0x8000000
Warn : acknowledgment received, but no packet pending
ResetHandler () at /home/brent/chibios/os/ports/GCC/ARMCMx/crt0.c:274
274     asm volatile ("cpsid   i");
Info : Auto-detected RTOS: ChibiOS
Error: Memory signature identifier does not contain magic bytes.
Error: Reading the memory signature of ChibiOS/RT failed
Loading section startup, size 0xf4 lma 0x8000000
Loading section .text, size 0x5674 lma 0x8000100
Loading section .data, size 0x10 lma 0x8005778
Info : Padding image section 0 with 12 bytes
Info : Padding image section 1 with 4 bytes
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20000400
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20000400
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (1097). Workaround: increase "set remotetimeout" in GDB
Start address 0x8000aa0, load size 22392
Transfer rate: 12 KB/sec, 5598 bytes/write.
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000aa0 msp: 0x20000400
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000aa0 msp: 0x20000400
Temporary breakpoint 1 at 0x8000eb6: file /home/brent/chibios/os/kernel/src/chsys.c, line 90.
Note: automatically using hardware breakpoints for read-only addresses.
Info : Successfully loaded memory map of ChibiOS/RT target running version 2.6.1
Error: ChibiOS registry integrity check failed, NULL pointer
Info : Only showing current execution because of a broken ChibiOS thread registry.

Temporary breakpoint 1, chSysInit () at /home/brent/chibios/os/kernel/src/chsys.c:90
90     port_init();
main () at main.c:51
51     debugPrintInit(debugOutput);
(gdb) info thread
[New Thread 536872976]
  Id   Target Id         Frame 
  2    Thread 536872976 (No Name :  : READY) Remote 'g' packet reply is too long: 00000000000000000000000000000000910e00080000000055555555555555555555555555555555555555555555555500000000d008002000000000510d00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)


In if I run the above without enabling the "$_TARGETNAME configure -rtos auto" command in my openocd.cfg,
everything works fine. If I delay running "$_TARGETNAME configure -rtos auto" until after chSysInit() has
finished, I get no extra threading info (but the system remains usable)

This might well be a regression in openocd or gdb. I'm just hoping we can help find it.
Thanks!

Re: Trouble with RTOS support in GDB/OpenOCD

Posted: Thu Jan 23, 2014 5:42 pm
by alan5
HI,
I was wondering if you got any further with this? I've been attempting to use openOCD to get to the bottom of some race condition I am seeing but I am running into this "Remote 'g' packet reply is too long".

Configured with:

Code: Select all

sudo ./configure --enable-maintainer-mode --enable-stlink --prefix=/home/fyp/fyp/openocd/bin


I'm using a STM32L152RCT6 and found I had to hardcode the flash size in tcl/target/stm32lx_stlink.cfg as it was being detected as a measly 12 kb.

I run it with:

Code: Select all

sudo openocd -f "scripts/board/stm32ldiscovery.cfg" -c "stm32lx.cpu configure -rtos auto"


My output after running and connecting with gdb and loading is:

Code: Select all

Open On-Chip Debugger 0.8.0-dev-00328-g0b26376-dirty (2014-01-23-15:38)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.877745
Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : STM32L flash size is 256kb, base address is 0x8000000
Warn : acknowledgment received, but no packet pending
Info : Auto-detected RTOS: ChibiOS
Info : Successfully loaded memory map of ChibiOS/RT target running version 2.6.2
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000450 msp: 0x20000400
STM32L: Enabling HSI
Info : STM32L flash size is 256kb, base address is 0x8000000
flash 'stm32lx' found at 0x08000000
Info : Padding image section 0 with 12 bytes
Info : Padding image section 1 with 4 bytes
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20000400
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20000400
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2115). Workaround: increase "set remotetimeout" in GDB


after running, "info threads" gives the following, though thread 1 appears to behave itself if I specify "info thread 1"

Code: Select all

(gdb) info threads
  Id   Target Id         Frame 
  3    Thread 536876000 (irqSignalHandlerThread :  : WTSEM) Remote 'g' packet reply is too long: 000000000000000000000000000000003147000800000000555555555555555555555555555555555555555555555555000000003816002000000000530e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000



So openOCD is giving me some keep_alive() warnings, and increasing remotetimeout doesn't appear to help.
Then there is the "Remote 'g' packet reply is too long" error from GDB itself.
I've seen some suggested fixes online, but there doesn't seem to be a lot of agreement on which one works
All times are UTC+01:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited