Page 12 of 18
Re: ChibiOS OpenOCD support
Posted: Tue Oct 23, 2012 7:53 pm
by Freddie Chopin
Giovanni wrote:BTW, is there a version of OCD compiled for windows including the threading code?
Not yet (; I usually provide dev binaries every two-months, and 0.6.1 was published just two weeks ago.
If you think that ChibiOS/RT support in OpenOCD is stable enough I could do a binary earlier.
4\/3!!
Re: ChibiOS OpenOCD support
Posted: Tue Oct 23, 2012 8:16 pm
by Giovanni
Thanks, I am waiting for that but it is Mabl that should confirm.
I have a question for you Freddie, how much effort would require the support in OpenOCD of PowerPC devices like the ST/Freescale SPC56x/MPC56xx? and mainly, where to start?
Giovanni
Re: ChibiOS OpenOCD support
Posted: Tue Oct 23, 2012 9:08 pm
by Freddie Chopin
Giovanni wrote:I have a question for you Freddie, how much effort would require the support in OpenOCD of PowerPC devices like the ST/Freescale SPC56x/MPC56xx? and mainly, where to start?
You should ask on openocd-devel list. If these have debug protocols like some other - already supported - ARM then support is just adding flash drivers. Probably those devices are not that similar to ARM, so I guess it would be more complicated... If the specs are available it can be done, if these are only available with NDA or not available at all (proprietary debug interfaces) than it would be almost impossible (only reverse engineering).
Anyway - don't confuse me with OpenOCD developers, I'm just helping with parts that I'm capable of, PC software and protocols like that are a little above my knowledge level (;
There are some posts about PowerPC on the list, but these are from last year - opinion is that it's doable.
4\/3!!
Re: ChibiOS OpenOCD support
Posted: Tue Oct 23, 2012 9:14 pm
by Giovanni
Thanks for the suggestion, I will post there, first I'll ask about those specs.
Giovanni
Re: ChibiOS OpenOCD support
Posted: Wed Oct 24, 2012 10:29 am
by mabl
Giovanni wrote:Mabl,
Could you try the following change?
Code: Select all
void _port_thread_start(void) {
register tfunc_t thread asm("r1");
register void *param asm("r0");
chSysUnlock();
asm volatile ("mov r0, r5 \n\t"
"mov r1, r4" : : : "r0", "r1");
chThdExit(thread(param));
}
Hi Giovanni,
I changed this code, but it did not help:
(gdb) bt
#0 _idle_thread (p=0x0) at Externals/ChibiOS/os/kernel/src/chsys.c:61
#1 0x08000eba in _port_thread_start () at Externals/ChibiOS/os/ports/GCC/ARMCMx/chcore_v7m.c:259
#2 0x0800180a in chSchGoSleepS (newstate=32 ' ') at Externals/ChibiOS/os/kernel/src/chschd.c:121
#3 0x20002aa0 in vtlist ()
#4 0x20002aa0 in vtlist ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
You should see the same error with your non-rtos openocd.
Freddie Chopin wrote:Giovanni wrote:BTW, is there a version of OCD compiled for windows including the threading code?
Not yet (; I usually provide dev binaries every two-months, and 0.6.1 was published just two weeks ago.
If you think that ChibiOS/RT support in OpenOCD is stable enough I could do a binary earlier.
It should be quite stable. I think there are still bug in the openocd rtos code itself - especially things like stepping in threads and stuff. I'm also not sure if this patch is currently needed for stlink:
http://openocd.zylin.com/#/c/923/
Re: ChibiOS OpenOCD support
Posted: Wed Oct 24, 2012 6:09 pm
by mabl
qtcreator has received lots of improvements recently, to support embedded programming and openocd with threads.
Most recent one:
https://codereview.qt-project.org/#change,38108And pics or it did not happen:
- qtc_working_threads.gif (228.04 KiB) Viewed 6025 times
Re: ChibiOS OpenOCD support
Posted: Wed Oct 24, 2012 8:25 pm
by Giovanni
mabl wrote:You should see the same error with your non-rtos openocd.
Good point.
Re: ChibiOS OpenOCD support
Posted: Wed Oct 24, 2012 10:12 pm
by gmb42
@mabl
I saw in your screenshot you have an openocd.cfg file, presumably this makes the command line for openocd simpler.
Currently I use a command line of:
Code: Select all
openocd -f board/stm32f4discovery.cfg -c "stm32f4x.cpu configure -rtos ChibiOS;"
but I can't work out how to push those arguments into an openocd.cfg file. Do you have any idea?
Re: ChibiOS OpenOCD support
Posted: Thu Oct 25, 2012 7:41 pm
by mabl
Hi gmb42,
typically I create a openocd.cfg file for my targets like this
Code: Select all
telnet_port 4444
gdb_port 3333
source [find interface/olimex-arm-usb-ocd-h.cfg]
# GDB can also flash my flash!
gdb_memory_map enable
gdb_flash_program enable
source [find target/stm32f4x.cfg]
Probably you can replace the two source by one single source to board/stm32f4discovery.cfg. This config has the advantage that you also easily enable flashing from gdb via the "load" command.
You can then call openocd via
Code: Select all
openocd -f openocd.cfg -c "stm32f4x.cpu configure -rtos auto;"
I hope this helps?
Re: ChibiOS OpenOCD support
Posted: Thu Oct 25, 2012 8:13 pm
by gmb42
Thanks for that, although I was really wanting to push the -c ... stuff into the cfg file. The stm32f4discovery.cfg already allows the flashing etc.
FYI, if I use "-rtos auto" then openocd crashes. I get the following bt:
Code: Select all
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7e271df in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0xb7e2a825 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0xb7e6439a in ?? () from /lib/i386-linux-gnu/libc.so.6
#4 0xb7e6eee2 in ?? () from /lib/i386-linux-gnu/libc.so.6
#5 0x080783fa in rtos_try_next (target=0x81f47e8) at rtos.c:482
#6 0x080786c0 in rtos_qsymbol (connection=0x81efa70, packet=0x81b3f20 <gdb_packet_buffer.8867> "qSymbol::696e69745f7461736b", packet_size=27)
at rtos.c:204
#7 0x08078a8e in rtos_thread_packet (connection=0x81efa70, packet=0x81b3f20 <gdb_packet_buffer.8867> "qSymbol::696e69745f7461736b",
packet_size=27) at rtos.c:310
#8 0x08073d05 in gdb_input_inner (connection=0x81efa70) at gdb_server.c:2066
#9 gdb_input (connection=0x81efa70) at gdb_server.c:2244
#10 0x0807615f in server_loop (command_context=0x81cc008) at server.c:462
#11 0x0804b9f8 in openocd_thread (cmd_ctx=0x81cc008, argv=0xbffff084, argc=5) at openocd.c:295
#12 openocd_main (argc=5, argv=0xbffff084) at openocd.c:328
#13 0x0804b265 in main (argc=5, argv=0xbffff084) at main.c:41
The code at 482 in rtos_try_next (rtos.c) is:
Code: Select all
481 if (os->symbols) {
482 free(os->symbols);
483 os->symbols = NULL;
484 }
This is with openocd master @ 4a5dc09