ChibiOS OpenOCD support

[Freddie Chopin]

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!!

[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

[Freddie Chopin]

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!!

[Giovanni]

Thanks for the suggestion, I will post there, first I'll ask about those specs.

Giovanni

[mabl]

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.

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/

[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,38108

And pics or it did not happen:

qtc_working_threads.gif (228.04 KiB) Viewed 6023 times

[Giovanni]

You should see the same error with your non-rtos openocd.

Good point.

[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?

[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?

[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