ChibiOS OpenOCD support

[saraben]

Mabl,
I finally had some time to try your suggestions.
I am not sure how I had GDB DSF set. It is only recent as it is only recently I noticed the Chibios tab didn't work.
I am not a fan of Eclipse, this morning I have lost my black background edit windows for no apparent reason. This is more than a cosmetic issue for me.
Eclipse has tried to be everything to everyone and in the effort become so complex it is hard to setup reliabily.
Regarding your configuration for GDB.
I found.
Setting a full path for the file command is necessary for STD GDB but not GDB DSF
Setting Load image causes some intermittent start up issues especially with GDB DSF. Without it the results were more consistent. I thought the file ... command was a replacement for this.
I set Reset and delay 3 sec in the startup screen which appears to produce more consistent results at start.

I have attached two files (one archive) with the same test sequence but the two different GDB setting in Eclipse.
Both have some issues you will see if you follow the sequence.
However neither are 100% repeatable which is why I documented the test sequence.

Note the extra steps required to get DSF to start relatively reliably (At the end of the file).
Note also that using DSF the Resume Pause now results in stopping at idle_thread (without breakpoints).
This also results at stopping at a set breakpoint after the first Resume stops at chSchGoSleepS. It is not possible to step when it stops at chSchGoSleepS.
With the STD GDB it always stopped at chSchGoSleepS.
I tried several Power cycles of the hardware and JTAG and these aspects appear consistent.

The DSF operation, while it keeps changing thread numbers, at least it displays the names correctly. The STD operation was confusing at times even with 4 threads.

By Thread 1, do you mean the threads labelled Thread [3] in the attachments, the blinker thread. Why is this special, it is just the first thread created in main?

I haven't used gdb from the command line for over five years. Perhaps I should relearn. Or try one of the other IDEs you have been looking at.

I hope this helps.
Regards saraben.

[mabl]

Hi saraben,

thanks again for this extensive report. I will go through it within the next days. It seems to me that threads and IDEs don't play well together. I'm yet to find a trouble free experience. Maybe IDEs also expose some bugs in the openocd rtos core which are not seen on my light command line usage.

In any case, there is also good news: ChibiOS/RT is now officially supported by OpenOCD master.

[mabl]

I had no idea it could be used for embedded.

Giovanni

I head a meta debug session (debugging the debug stuff) with the qt-creator guys today. Naturally , their focus lies not on embedded work. A lot of improvements have been introduced today and will also be released with qt-designer 2.6 within the coming weeks. I will write a guide on how to set it all up. I think it is a great alternative to Eclipse - and it is fast as hell.

About threading support: I'm convinced there are still bugs hiding in the openocd code base. I'll try to hunt them down, but it is hard since I don't know how it should actually look like.

Best,
MaBl

[gmb42]

I'm sorry to report that I just can't get the latest version of openocd (14e12c3969fef1a4649de1db0b0fac47e5295708 with chibi support) to work at all with gdb.

I'm using chibios r4763 and an STM32F4 discovery board on Ubuntu 12.04.

Using gdb 7.3.1.20120613-cvs (as built by summon-arm-toolchain) I get a segfault in openocd. I start openocd with the board/stm32f4discovery.cfg config file and the output is:

Code: Select all

pen On-Chip Debugger 0.7.0-dev-00046-g14e12c3 (2012-10-16-21:09)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Starting gdb gives:

Code: Select all

GNU gdb (GNU Tools for ARM Embedded Processors) 7.3.1.20120613-cvs
Copyright (C) 2011 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-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/graham/Software/Projects/MAX31855-TEST/build/max31855.elf...done.
(gdb) tar rem :3333
Remote debugging using :3333
0x00000000 in ?? ()
Remote connection closed
(gdb) 

And openocd shows:

Code: Select all

Info : accepting 'gdb' connection from 3333
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
*** glibc detected *** src/openocd: free(): invalid next size (fast): 0x08a64588 ***

If I try the latest linaro 7.4.1 gdb I get an error from gdb:

Code: Select all

GNU gdb (Linaro GDB) 7.4-2012.06
Copyright (C) 2012 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".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/graham/Software/Projects/MAX31855-TEST/build/max31855.elf...done.
(gdb) tar rem :3333
Remote debugging using :3333
Remote 'g' packet reply is too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb) 

And the corresponding output from openocd:

Code: Select all

Info : accepting 'gdb' connection from 3333
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Info : dropped 'gdb' connection

Am I doing something wrong? Can I provide more info to help?

[Badger]

Try using the pre-built toolchain from arm, that works for me although I'm on an OpenOCD from yesterday, might be a few changes behind the most up to date one. I had some problems (albeit different to yours!) before switching to it.

[gmb42]

In fact that was the toolchain I was using, not sat. The arm toolchain provides gdb 7.31 that causes openocd to segfault.

[mabl]

Since all code is now upstream, my repository is not needed anymore. I've also been told another method to activate RTOS support which replaces the old method of changing configuration files. I've updated the wiki entry.

[mabl]

Hi Giovanni,

I've inquired at GDB how to stop the backtrace.

Code: Select all

04:11:14 PM - mabl00: I'm wondering, how does gdb know that a backtrace stops?
05:12:17 PM - brobecke: mabl00: the simplest stop is detecting a frame that corresponds to the "main" subprogram, usually called 'main'.
05:12:25 PM - brobecke: See for instance 'set breakpoint past-main'.
05:12:34 PM - brobecke: Past that, it's target-specific knowledge.
05:16:33 PM - mabl00: hi brobecke: Ok, so i have an ARM m7 target with a custom operating system (ChibiOS)
05:17:40 PM - mabl00: And the backtrace will give be bogus after the function which does the jump to my thread
05:18:15 PM - mabl00: So i guess i have to prepare my memory/registers in a special way before doing the jump, right?
05:18:16 PM - brobecke: ah, yes, known problem. GDB doesn't detect pthread-type functions that create new threads.
05:18:41 PM - mabl00: brobecke: ok, so I cannot do anything against it?
05:19:36 PM - brobecke: IIRC, if you can get the return address to be NULL, the backtrace will automatically stop.
05:19:40 PM - brobecke: I think...
05:20:25 PM - mabl00: hmm, i tried setting the lr register to 0 before the jump, but it did not help
05:20:43 PM - mabl00: (to my shame I have to admit, my knowledge is not that huge in this area..)
05:20:55 PM - brobecke: you might be out of luck, I'm not sure, and I don't have the time to look deeper at the moment.
05:21:23 PM - brobecke: The best approach, imo, is to submit a patch that recognizes pthread_create et all as "main".
05:22:08 PM - jankratochvil: The proper way is to provide CFI (=unwind information in .eh_frame/.debug_frame) with underined return address; but ARM has specifically its own non-DWARF format of CFI which I do not know.
05:22:50 PM - brobecke: of course, but not all platforms have CFI. I think both can coexist and having a fallback would be nice.
05:23:12 PM - jankratochvil: NULL return address does not specifically have to stop the unwind, it depends on the target, address 0 is a valid code address.
05:23:17 PM - brobecke: besides, there might be some frames that are considered past-main before the pthread code.
05:23:54 PM - brobecke: jankratochvil: ok, but didn't we have a discussion were we decided that no real code would ever run at 0 and thus use that to stop the backtrace?
05:24:18 PM - brobecke: maybe we made it platform-specific as you say. I don't remember exactly.
05:24:22 PM - palves: pthread_create isn't usually a thread's entry point. some other target-specific function is.
05:25:56 PM - jankratochvil: I do not remember the address 0 discussion, address 0 can cause a trap and its signal handler will have 0 as its return address.
05:25:59 PM - palves: pthread_create (..., start_routine) -> spawns thread, and sets it up to start at some target specific function, that ultimatelly calls start_routine.
05:27:18 PM - palves: yeah. calling through a NULL function pointer should be able to unwind correctly, if the stack is okay.
05:30:41 PM - palves: arm's prologue based unwinder does stops the unwinding with "if (cache->prev_sp == 0) return;"
05:35:09 PM - mabl00: thx palves and all. So I just need to figure out how to manipulate my previous stack pointer

So I guess the latter solution is the thing I'm looking for. Now, the previous stackpointer is saved on the stack, right? But since we just started the thread, it is somewhere *before our thread start*. Am I right in assuming, that we can only implement correct unwinding in gdb if we reserve stack space for the 0? (btw. is there any *good* article how the stack looks like on m7 processors if you call functions?)

[Giovanni]

What we could do is to hack the thread trampoline code to appear to be called from main, probably is is sufficient to make the LR register point to the main function, you may test this by loading the register at the start of _port_thread_start().

Giovanni

[Giovanni]

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));
}

Please verify if it makes any difference, this code enforces the creation of a frame for _port_thread_start().

BTW, is there a version of OCD compiled for windows including the threading code?

Giovanni