ChibiOS OpenOCD support

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
mabl
Posts: 417
Joined: Tue Dec 21, 2010 10:19 am
Been thanked: 1 time

Re: ChibiOS OpenOCD support

Post by mabl »

Ok, I've created a new branch on github called chibios. It contains the latest version from oocd master with a big rewrite of the rtos gdb part. It has two patches applied on top:

  • ChibiOS support as proposed in my gerrit post
  • Patch to enable rtos support by default for all ST STM32 targets. This patch will not be included in oocd. I'm rather looking into enabling rtos differently in the future.

I'd be glad to get feedback. I have positive review by oocd but I only like to have the patch included once I sort out all issues with it.
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ChibiOS OpenOCD support

Post by Giovanni »

What is the problem, has the patch been refused?

Giovanni
mabl
Posts: 417
Joined: Tue Dec 21, 2010 10:19 am
Been thanked: 1 time

Re: ChibiOS OpenOCD support

Post by mabl »

No, actually it got a +1 rating :mrgreen:

The thing is that a lot of work has been done in the main oocd repository which was not included in my old branch. So I've included all that work now and want to check that it is still working for everyone.

Once I get this feedback I'll ask oocd to have my code included, I guess this would happen within a day or two.

What is still missing is the FPU detection. I'm not yet sure how to tackle that one best....
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ChibiOS OpenOCD support

Post by Giovanni »

I'll look into adding it into the structure, it is not so easy because it requires another interface between port layer and kernel, but if there is no other way then it is OK.

Giovanni
mabl
Posts: 417
Joined: Tue Dec 21, 2010 10:19 am
Been thanked: 1 time

Re: ChibiOS OpenOCD support

Post by mabl »

Giovanni,

i think there is an other way. Give me two or three days. I'll have an answer then
mabl
Posts: 417
Joined: Tue Dec 21, 2010 10:19 am
Been thanked: 1 time

Re: ChibiOS OpenOCD support

Post by mabl »

Giovanni, is it save to determine the FPU status by just looking at the CONTROL register as indicated by the FPCA bit? Or do I have to look at the stacking information in FPCCR register?
feanor
Posts: 15
Joined: Sat Sep 29, 2012 9:31 am

Re: ChibiOS OpenOCD support

Post by feanor »

With Option "USE_FPU = no" the threaded debugging works. Thanks for your help.
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: ChibiOS OpenOCD support

Post by Giovanni »

mabl wrote:Giovanni, is it save to determine the FPU status by just looking at the CONTROL register as indicated by the FPCA bit? Or do I have to look at the stacking information in FPCCR register?


The FPCA value can change during runtime so it is not safe, better look at the coprocessor enable fields in SCB_CPACR (CP10 and CP11).

The startup file sets them as follow when the FPU is enabled:

Code: Select all

  SCB_CPACR |= 0x00F00000;

You should verify that that mask is different from zero, something like:

Code: Select all

if (SCB_CPACR & 0x00F00000) {
  /* FPU enabled.*/
}


I don't know OpenOCD internals but SCB_CPACR is mapped in memory so you should have access to it from your code.

Giovanni
mabl
Posts: 417
Joined: Tue Dec 21, 2010 10:19 am
Been thanked: 1 time

Re: ChibiOS OpenOCD support

Post by mabl »

Ok, I have FPU detection working now. :D Tomorrow I will look into correct stack reconstruction.
saraben
Posts: 40
Joined: Thu Sep 20, 2012 12:37 am

Re: ChibiOS OpenOCD support

Post by saraben »

Mabl,
I had some time today so tried your openOCD code, along with trying to sort out some Eclipse/GitHub issues so I could install a new copy of 5.... properly.

Apart from some finger trouble I have it working but I think there are still some problems.
Version Open On-Chip Debugger 0.7.0-dev-g4e00135 (2012-10-10-11:00).
Compiled this morning (0:00 UTC), just a coincidence.

The following is the Debug window. Note the numbers at the end of each thread listing except main. Perhaps they relate to your stack issues.

Code: Select all

Dev_1_OCD_dev [Program]   
   /home/chris/bin/oocd/bin/openocd   
Dev_1 [GDB Hardware Debugging]   
   ch.elf   
      Thread [4] 536877952 (shell :  : WTQUEUE) (Suspended : Container)   
         chSchGoSleepS() at chschd.c:122 0x8001664   
         chSchGoSleepTimeoutS() at chschd.c:195 0x8001768   
         qwait() at chqueues.c:69 0x8003c40   
         chIQReadTimeout() at chqueues.c:232 0x8003e6c   
         read() at serial.c:63 0x800574e   
         shellGetLine() at shell.c:261 0x80134c6   
         shell_thread() at shell.c:155 0x801328a   
         _port_thread_start() at chcore_v7m.c:255 0x8000d32   
         chSchGoSleepS() at chschd.c:121 0x8001664   
         0xaa52432a   
      Thread [3] 536877640 (blinker :  : SLEEPING) (Suspended : Container)   
         chSchGoSleepS() at chschd.c:122 0x8001664   
         chSchGoSleepTimeoutS() at chschd.c:190 0x800174e   
         chThdSleep() at chthreads.c:290 0x8001cee   
         Thread1() at main.c:351 0x8015bb6   
         _port_thread_start() at chcore_v7m.c:255 0x8000d32   
         chSchGoSleepS() at chschd.c:121 0x8001664   
         0x200022d4   
      Thread [2] 536873472 (idle :  : CURRENT) (Suspended : Container)   
         _idle_thread() at chsys.c:61 0x8000ee8   
         _port_thread_start() at chcore_v7m.c:255 0x8000d32   
         chSchGoSleepS() at chschd.c:121 0x8001664   
         0x20000b28   
      Thread [1] 536873664 (main :  : WTOREVT) (Suspended : User Request)   
         0x8000ee8   
         chSchGoSleepTimeoutS() at chschd.c:190 0x800174e   
         chEvtWaitOneTimeout() at chevents.c:451 0x80033c8   
         main() at main.c:657 0x8015f26   
   gdb   

The following is my openOCD console log. Note one range of problem addresses is the same range as at the end of the first thread above.

Code: Select all

openOCD console
--------------------
Open On-Chip Debugger 0.7.0-dev-g4e00135 (2012-10-10-11:00)
Licensed under GNU GPL v2
For bug reports, read
   http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08000ee8 psp: 0x20000ab0
cortex_m3 interrupt mask auto
background polling: on
TAP: stm32f1x.cpu (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x08000ee8 psp: 0x20000ab0
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : accepting 'gdb' connection from 3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
Warn : acknowledgment received, but no packet pending
Auto-detected RTOS: ChibiOS
Info : Successfully loaded memory map of ChibiOS/RT target running version 2.5.1
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0xaa52432b
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0x55555556
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0xaa52432b
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0x55555556
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0xaa52432b
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0x55555556
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000050, MEM_AP_TAR 0xaa52432b


It is run on an STM32F103RB so no FPU and some of those addresses do look abnormal.
It was run with an Olimux usb JTAG. Note I do not normally run the JTAG at 500k, just tried it to see if it made any difference.

I hope that this helps.
Regards saraben
Post Reply