STM32F4 + eclipse ChibiOS plugin + option bytes fun!

[HackedFridgeMagnet]

source [find interface/stlink-v2.cfg]

# Work-area size (RAM size) = 48kB for STM32F103RC device
set WORKAREASIZE 0xC000

source [find target/stm32f1x_stlink.cfg]

was my .cfg file, when I hadn't changed this from 20k and the debugger didn't work as expected.

[andersm]

expensive, dongle- or otherwise-protected, closed and inevitably unsupported tools any day of the year.

Die-hard Keil / IAR fan here. None of those issues.

At work we have compilers by both IAR and Microchip that are no longer supported. Due to regulatory reasons we can't throw them away, but they're a huge pain as their dongle drivers don't work on modern Windows. Once the old machines kept around just for those pieces of crap die or have to be taken offline when Microsoft stops shipping security updates for XP, we're kind of screwed.

[mrflibble]

was my .cfg file, when I hadn't changed this from 20k and the debugger didn't work as expected.

In what way "didn't work as expected"? Exploding during flashing, or something subtle?

[HackedFridgeMagnet]

From memory the debugger was landing on the wrong line in breakpoints.

But thinking again, I hadn't realised at this time that sometimes I needed to depower the St Link or I would get the issue of breaking on the wrong line of code.

I was moving up from 20k ram to 48k ram, but it was definitely happy to run and break, my code was probably not much over 20k, but I didn't get it going properly until sometime after I had changed the .cfg file.

This may be a red herring, but on the other hand it may have effected me.

Don't know if these are any help but these are what I used to setup build / debug using eclipse/cdt/open debugger

http://hertaville.com/2012/05/28/gcc-arm-toolchain-stm32f0discovery/

http://thehackerworkshop.com/?tag=eclipse

[mrflibble]

Are you using "the right" gdb release? I'm using 7.4.1 with a reasonably fresh openocd and it works fine on OS X.

Incidentally, currently testing things with gdb from gcc-arm-none-eabi-4_8-2013q4 release:

GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs

Is there a magic range of gdb versions I should be using?

[mrflibble]

From memory the debugger was landing on the wrong line in breakpoints.

But thinking again, I hadn't realised at this time that sometimes I needed to depower the St Link or I would get the issue of breaking on the wrong line of code.

That sounds a bit strange, almost like what you get when you don't reset init after flashing.

At any rate, breakpoints etc etc work fine, and have been working fine for ages with all the versions of openocd/gdb/eclipse I've used. The main issue is chibios threads, and having them show up in the debug view. I can debug it the regular boring single threaded way and everything works fine. If I want to see the other threads, then I have to provide the symbols so openocd detects them (notably ch_debug symbol). I can do that just fine with a symbol-file .../ch.elf command. BUT! the downside of that is that for some reason this messes up the register list. Which then in turn results in the g packet problems. When I do an "info threads" after the symbol-file I do see the threads with proper symbols, BUT the g packet errors aka wrong register list messes things up.

So basically the question is how do I tell openocd about the symbol list without triggering whatever it is that results in changing the register list.

[mrflibble]

Something that's relatively easy to reproduce:

get chibios 2.6.2 (latest stable)


cd ChibiOS_2.6.2/demos/ARMCM4-STM32F407-DISCOVERY-G++
make
arm-none-eabi-gdb -ex "target extend localhost:3333" -ex "monitor reset halt" -ex "set remote hardware-breakpoint-limit 6" -ex "set remote hardware-watchpoint-limit 4" -ex "load build/ch.elf" -ex "monitor reset halt" -ex "tbreak main.cpp:167" -ex "continue" -ex "info threads"

(gdb) info threads
  Id   Target Id         Frame
* 1    Remote target     0x08000638 in ?? ()


No problemo. Flashes and runs. Just no symbols for openocd to play with.

arm-none-eabi-gdb -ex "target extend localhost:3333" -ex "monitor reset halt" -ex "set remote hardware-breakpoint-limit 6" -ex "set remote hardware-watchpoint-limit 4" -ex "file build/ch.elf" -ex "monitor reset halt" -ex "tbreak main.cpp:167" -ex "continue" -ex "info threads"


*URGLE*

  2    Thread 536873216 (No Name :  : READY) Remote 'g' packet reply is too long: 00000000000000000000000000000000310600080000000000000000000000000000000000000000000000000000000000000000c009002000000000a10500080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Openocd does have the RTOS symbols now, but it looks like the stubs in ch.elf mess up the register list. Any ideas as to what I'm doing wrong here?

Versions:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs
Open On-Chip Debugger 0.8.0-dev-00328-g0b26376 (2014-01-21-11:15)

[andyturk]

  2    Thread 536873216 (No Name :  : READY) Remote 'g' packet reply is too long: 00000000000000000000000000000000310600080000000000000000000000000000000000000000000000000000000000000000c009002000000000a10500080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Are you actually setting the name of the thread? If not, try that and see if it makes a difference.

Those thread extensions seem pretty fresh in the grand scheme of things. Wouldn't surprise me if there were gotchas.

It could also be that the "Remote 'g' packet reply" error is sort of a catch all any time the byte stream gets hosed. I.e., there was a known hosing due to FP registers that's been fixed. Maybe you've discovered a second hosing?

[mrflibble]

  2    Thread 536873216 (No Name :  : READY) Remote 'g' packet reply is too long: 00000000000000000000000000000000310600080000000000000000000000000000000000000000000000000000000000000000c009002000000000a10500080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Are you actually setting the name of the thread? If not, try that and see if it makes a difference.

In the above example I'm not doing any naming, since it's a fresh 2.6.2 download. But in my own code I do set the thread names, and then I do see them (in the location where it now says "No Name"), but for the rest the results are exactly the same.

Those thread extensions seem pretty fresh in the grand scheme of things. Wouldn't surprise me if there were gotchas.

It could also be that the "Remote 'g' packet reply" error is sort of a catch all any time the byte stream gets hosed. I.e., there was a known hosing due to FP registers that's been fixed. Maybe you've discovered a second hosing?

Well, it obviously is FP register related, I just don't know how to fix it. If you check that large 000000000....3106000...... packet, you'll see that it is 17x 32-bit registers for the usual regs, and then 8x 96-bit + 1x 32-bit for the FP registers. But the curious thing is, that in the fault state ... when I do monitor reg I still get the correct registers. But the moment I do info threads ... booom! g packet reply too long.

Maybe the current version has a fun regression? Given that you are using chibios, I take it you also debug it with thread support? Or do you just view it as a single thread? Because the latter works just fine, it's viewing threads to makes it go tits up. If you can succesfully do an info threads on your setup, could you tell me the exact git revision?

Mmmh, or maybe this is the ever popular 32-bit vs 64 bit issue. I read about a similar issue (now fixed) that got triggered on 32-bit, and accidentally worked on 64-bit. And the problem is on a 32-bit box, so worth checking it on 64-bit.

[mrflibble]

Mmmh, or maybe this is the ever popular 32-bit vs 64 bit issue. I read about a similar issue (now fixed) that got triggered on 32-bit, and accidentally worked on 64-bit. And the problem is on a 32-bit box, so worth checking it on 64-bit.

Just tested on different 64-bit box. Nope, same result.

[andyturk]

Maybe the current version has a fun regression? Given that you are using chibios, I take it you also debug it with thread support? Or do you just view it as a single thread? Because the latter works just fine, it's viewing threads to makes it go tits up. If you can succesfully do an info threads on your setup, could you tell me the exact git revision?

I've never used the thread support in gdb. In fact, when I just tried it a minute ago, "info threads" only shows me the current thread (usually idle), and says nothing about the other five. I don't get a g packet error though.

I'm using a local fork of openocd that branched off at 215c41c0174e94ab00b36a7d56a054cdd7f30dd0.

This particular build is using ChibiOS 2.7.0 unstable

[mrflibble]

Maybe the current version has a fun regression? Given that you are using chibios, I take it you also debug it with thread support? Or do you just view it as a single thread? Because the latter works just fine, it's viewing threads to makes it go tits up. If you can succesfully do an info threads on your setup, could you tell me the exact git revision?

I've never used the thread support in gdb. In fact, when I just tried it a minute ago, "info threads" only shows me the current thread (usually idle), and says nothing about the other five. I don't get a g packet error though.

I'm using a local fork of openocd that branched off at 215c41c0174e94ab00b36a7d56a054cdd7f30dd0.

This particular build is using ChibiOS 2.7.0 unstable

Thanks!

The behavior you describe above is normal as per default. I get the same when I am not mucking about with thread support. Two things are required to enable threads in openocd:

In your openocd config file: stm32f4x.cpu configure -rtos ChibiOS

In gdb, preferably before you connect to target: symbol-file build/ch.elf

[andyturk]

Thanks!

The behavior you describe above is normal as per default. I get the same when I am not mucking about with thread support. Two things are required to enable threads in openocd:

In your openocd config file: stm32f4x.cpu configure -rtos ChibiOS

In gdb, preferably before you connect to target: symbol-file build/ch.elf

Ah. Well, when I do the stm32f4x.configure, I get the packet reply error, same as you.

[mrflibble]

Right, as I suspected it was that after you provide the rtos symbols to openocd, it does it's RTOS detection thing. And when it does that it also changes the register map. And oh yeah, doesn't notify gdb of this happy occasion. Now in theory you should be able to tell gdb yourself with tdesc file target.xml, but so far I haven't had any luck with that approach. Okay, so if I cannot get gdb to pickup a working new register map, maybe I can get openocd to just stick with the old layout.

Quick & dirty patch:

Code: [Select]

--- src/rtos/rtos_chibios_stackings.c.orig 2014-01-21 10:52:18.000000000 +0100
+++ src/rtos/rtos_chibios_stackings.c 2014-01-23 21:16:14.000000000 +0100
@@ -27,6 +27,8 @@
 
 #include "rtos.h"
 
+//#define CHIBIOS_WORKAROUND
+
 static const struct stack_register_offset rtos_chibios_arm_v7m_stack_offsets[] = {
  { -1,   32 }, /* r0   */
  { -1,   32 }, /* r1   */
@@ -44,6 +46,8 @@
  { -2,   32 }, /* sp   */
  { -1,   32 }, /* lr   */
  { 0x20, 32 }, /* pc   */
+#ifdef CHIBIOS_WORKAROUND
+#else
  { -1,   96 }, /* FPA1 */
  { -1,   96 }, /* FPA2 */
  { -1,   96 }, /* FPA3 */
@@ -53,13 +57,18 @@
  { -1,   96 }, /* FPA7 */
  { -1,   96 }, /* FPA8 */
  { -1,   32 }, /* FPS  */
+#endif
  { -1,   32 }, /* xPSR */
 };
 
 const struct rtos_register_stacking rtos_chibios_arm_v7m_stacking = {
  0x24, /* stack_registers_size */
  -1, /* stack_growth_direction */
+#ifdef CHIBIOS_WORKAROUND
+ 17, /* num_output_registers */
+#else
  26, /* num_output_registers */
+#endif
  0, /* stack_alignment */
  rtos_chibios_arm_v7m_stack_offsets /* register_offsets */
 };

Not pretty, but it'll do until they sort out thread support a bit more properly. That or until I find out that it is well supported all along and I'm just doing it wrong. Either way, seems to work so far.

[ntfreak]

mrflibble,

Seems that indeed you have found a regression, I will look into it and push a patch to our review server.
The cause is when xml register support was added to OpenOCD the rtos has not been updated to suit.

Cheers
Spen

[mrflibble]

Seems that indeed you have found a regression, I will look into it and push a patch to our review server.
The cause is when xml register support was added to OpenOCD the rtos has not been updated to suit.

That seems to fit with what I noticed while tracing this problem. Anyways, good to know you're looking into it. If you need an extra test victim for this particular case just let me know where to grab the patched version. If not, I'll just wait until a random point in the future and test an svn checkout.

Thanks.

[ntfreak]

If you fancy testing the change on our review server (gerrit) is here - http://openocd.zylin.com/2054/
You will however need to build from src to test.

Spen

[mrflibble]

Just built it and did a quick test. It detects the RTOS symbols, and doesn't do crazy things to the register map. And I do get the threads listed in eclipse. So far so good. Thanks for the quick fix!

I still don't see the thread names in the eclipse debug view though, but so far I've never managed to get that working together with openocd + chibios. When I do info threads in the console it does show the correct thread names. Do you by any chance happen to know what that might be related to? Or more importantly, how to fix that?

Edit: To clarify, I mean this debug view:


I do get the multiple threads and the stack. But unlike the above screenshot, I do not get the thread names like "shell" and "http" in this example. And as said, if I run info threads from the console I do get the thread list with correct names in them. But it would be nice to also have that info in the debug view.

[ntfreak]

I tend to use gdb on the cmd line.

Not sure if it help but there is some info on the ChibiOS wiki - http://www.chibios.org/dokuwiki/doku.php?id=chibios:community:setup:openocd_chibios
It does mention that versions of eclipse before Juno do not display names correctly.

Perhaps its also worth posting to the support thread - http://forum.chibios.org/phpbb/viewtopic.php?f=3&p=6608

Spen