Page 9 of 18
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 2:01 pm
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.
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 2:33 pm
by Giovanni
What is the problem, has the patch been refused?
Giovanni
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 3:19 pm
by mabl
No, actually it got a +1 rating
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....
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 3:29 pm
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
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 3:32 pm
by mabl
Giovanni,
i think there is an other way. Give me two or three days. I'll have an answer then
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 4:33 pm
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?
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 5:24 pm
by feanor
With Option "USE_FPU = no" the threaded debugging works. Thanks for your help.
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 5:48 pm
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:
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
Re: ChibiOS OpenOCD support
Posted: Tue Oct 09, 2012 9:42 pm
by mabl
Ok, I have FPU detection working now.
Tomorrow I will look into correct stack reconstruction.
Re: ChibiOS OpenOCD support
Posted: Wed Oct 10, 2012 8:06 am
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