STM32F4 + eclipse ChibiOS plugin + option bytes fun!

[mrflibble]

Yesterday I was trying out the ChibiOS/RT plugin in eclipse, but no dice. The tab does show up in the views, but no content. Okay, no doubt because it cannot read memory/registers/whatever for some reason or other.

So while trying out all sorts of thing with openocd, I managed to mess up my STM32F4 discovery board and couldn't flash it anymore.

What did still work was pull BOOT0 high and then program. So I muck about some more. Oh cool, now I can and sometimes cannot program it, no matter what BOOT0 is set to! At that point I thought maybe I had inadvertently fucked it up royally. Tried openocd (several versions), st-link, nope.

Then *sigh* reboot to windoze, install ST's ST-link/V2 thingy. Okay, now I can at least program it again with BOOT0 pulled high. It did behave a little funky though, which in hindsight probably was watchdog related.

Still no 30 Watt lightbulbs, so screw it, time for something else. Some sleep + a fresh round of googling later I found out that I had managed to bork the option bytes in flash. So not only had I turned on protection for some flash sectors (old news, I could fix that in openocd), but also BOR settings, watchdog timer settings etc. Soooo, using ST-link/V2 set them back to default and all is well again.

So now I am back to where I was yesterday. ChibiOS/RT plugin installed and all that, but no data. I do get openocd to detect the plugin. Well, probably not the plugin, but the ch_debug symbol in the binary... At any rate, this is the openocd output:

Code: [Select]

Open On-Chip Debugger 0.8.0-dev-00319-g94d64cc (2014-01-19-12:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.897578
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : accepting 'gdb' connection from 3333
Halting target on gdb-attach
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x08002058 psp: 0x20000e78
Warn : acknowledgment received, but no packet pending
Info : Auto-detected RTOS: ChibiOS
Info : Successfully loaded memory map of ChibiOS/RT target running version 2.6.0

It's a fresh git clone from yesterday.

As init commands on gdb startup I have:

Code: [Select]

set arch i386:x86_64
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
file /full/path/ch.elf

The "set arch" is intended to prevent "Remote 'g' packet reply is too long" but unfortunately it still throws that error.

It does seem to be memory map related because the Embsys Registers plugin doesn't show any meaningful data either... Hopefully someone has been through some of the same and knows a fix?

For now I've had enough of this sidetrack for now, I've got mosfets to blow up.

PS: oh yeah, before I forget ... does anyone know how to set the option bytes through openocd? It looks like this is not possible in the current version, but I'd love to be wrong.

[mrflibble]

By way of sanity check I did a memory read of GPIOD, with two different versions of arm-none-eabi-gdb against the recent version of openocd.

Code: [Select]

arm-none-eabi-gdb  --eval-command='target extended localhost:3333'

(gdb) monitor mdw 0x40020c10
0x40020c10: 0000f020

And toggling the bits on the port does indeed show the correct changes on that memory address. So at least that is working. Just not from eclipse. grrrr. 

[andyturk]

You're telling gdb it's running on Intel? Yikes.

I thought they fixed the problem in openocd with the number of FP registers (that's the remote 'g' packet issue). At least, I used to have to patch that locally and don't any more.

[andyturk]

PS: oh yeah, before I forget ... does anyone know how to set the option bytes through openocd? It looks like this is not possible in the current version, but I'd love to be wrong.

I haven't tried it, but it should be possible with openocd's mww (memory write word) command. Just figure out which bytes/words to punch in the registers and write some jimtcl to do it on command.

When I've bricked a board, I usually just fire up my Windoze VM and run ST's official app to erase the chip.

[mrflibble]

You're telling gdb it's running on Intel? Yikes.

Yes, no, sortof.

I only tried that set arch i386:x86_64 as a crazy last ditch effort. Unsuprisingly it didn't work. Normally arch is just set to "arm".

I thought they fixed the problem in openocd with the number of FP registers (that's the remote 'g' packet issue). At least, I used to have to patch that locally and don't any more.

I think I found the patch to which you refer. And as you say this is not required anymore. When I checked the current git checkout against that patch I could see that it was already in mainstream source.

Code: [Select]

--- a/src/target/armv7m.c
+++ b/src/target/armv7m.c
@@ -267,7 +267,7 @@ int armv7m_get_gdb_reg_list(struct target *target, struct reg **reg_list[], int
        struct armv7m_common *armv7m = target_to_armv7m(target);
        int i;
 
-       *reg_list_size = 26;
+       *reg_list_size = 17;
        *reg_list = malloc(sizeof(struct reg *) * (*reg_list_size));
... etc. That's the one you mean I take it?

At any rate, with a regular unpatched openocd checkout I get that remote 'g' packet error message. Alternatively I tried using an XML file with register description like this: https://github.com/elliottt/stm32f4/blob/master/stm32f4/support/gdb-tdesc-cortexm-fpa.xml

But that didn't help either. So I'm a bit stumped as to why I'm still getting that error...

I haven't tried it, but it should be possible with openocd's mww (memory write word) command. Just figure out which bytes/words to punch in the registers and write some jimtcl to do it on command.

Thanks, that's worth a try.

When I've bricked a board, I usually just fire up my Windoze VM and run ST's official app to erase the chip.

Yup, that's pretty much what I ended up doing, minus the VM and plus the actual reboot. Didn't want to take any chances...

[HackedFridgeMagnet]

Just casting out a few ideas.

Don't know if this will help but you can start openocd in sort of 'verbose-debug' using I think a trailing '-d 1' on the command. It spits out a huge quantity of text.

Also is your .cfg file correct? Does it match your linker address wise.

I think the debugger needs to be attached before you will get any sense out of EmbSys anyway.

I used Juno and the latest CDT though not the Chibi/os plugin.

[andyturk]

But that didn't help either. So I'm a bit stumped as to why I'm still getting that error...

I think it's this kind of issue that keep people buying those $5K/seat development systems. ;-)

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.

[dannyf]

It is a perfect example of how expensive those free tools can be.

If your livelihood depends on making deadline, do you think you can afford to use tools like this?

[mrflibble]

But that didn't help either. So I'm a bit stumped as to why I'm still getting that error...

I think it's this kind of issue that keep people buying those $5K/seat development systems. ;-)

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.

Heh. For $5k I still have a few more hours I can flush to stay within budget.

Open On-Chip Debugger 0.8.0-dev-00328-g0b26376 (2014-01-21-11:15)

Compiler is CodeSourcery lite 2013.11-24 , with these flags:

arm-none-eabi-gcc -c -mcpu=cortex-m4 -O0 -ggdb -fomit-frame-pointer -falign-functions=16 -Wall -Wextra -Wstrict-prototypes -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../ChibiOS_2.6.0/os/ports/common/ARMCMx/CMSIS/include -I../ChibiOS_2.6.0/os/ports/common/ARMCMx -I../ChibiOS_2.6.0/os/ports/GCC/ARMCMx -I../ChibiOS_2.6.0/os/ports/GCC/ARMCMx/STM32F4xx -I../ChibiOS_2.6.0/os/kernel/include -I../ChibiOS_2.6.0/test -I../ChibiOS_2.6.0/os/hal/include -I../ChibiOS_2.6.0/os/hal/platforms/STM32F4xx -I../ChibiOS_2.6.0/os/hal/platforms/STM32 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/GPIOv2 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/I2Cv1 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/OTGv1 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/RTCv2 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/SPIv1 -I../ChibiOS_2.6.0/os/hal/platforms/STM32/USARTv1 -I../ChibiOS_2.6.0/boards/ST_STM32F4_DISCOVERY -I../ChibiOS_2.6.0/os/various/devices_lib/accel -I../ChibiOS_2.6.0/os/various main.c -o main.o

I installed a recent eclipse just to be sure it's not that, so I now use 4.3 Kepleromgwhatnamewillwethinkofnextmommycanweusenumbersagain.

Also is your .cfg file correct? Does it match your linker address wise.

Code: [Select]

source [find interface/stlink-v2.cfg]
source [find target/stm32f4x_stlink.cfg]

reset_config srst_only srst_nogate

$_TARGETNAME configure -event gdb-attach { echo "Halting target on gdb-attach" ; halt }
stm32f4x.cpu configure -rtos auto


If your livelihood depends on making deadline, do you think you can afford to use tools like this?

Yes. I can count. On a good day I can count real well.

I get what you're saying, but I've experienced far too many paid-for pieces of shit to think that paid-for is a reliable indicator of quality. Every now and then you encounter something that doesn't work as required, be it paid software or "free" software. Shit happens.

[dannyf]

The fact that both are buggy doesn't mean they are equally buggy.

[mrflibble]

The fact that both are buggy doesn't mean they are equally buggy.

At any rate, I'm game for a paid-for vs open sauce suckage comparison in general chat. But not in a thread where I'd like to get shit fixed.

[andyturk]

Compiler is CodeSourcery lite 2013.11-24 ...

Meh.

That's a GCC toolchain with proprietary crap thrown in so you'll get hooked and upgrade to their paid version. Why not go with pure play open source?

https://launchpad.net/gcc-arm-embedded

Also, since you're using ChibiOS, here's a few Makefile rules I add to my projects that may help:

Code: [Select]

build/.gdbinit : $(SHARE)/gdbinit
@cp $(SHARE)/gdbinit build/.gdbinit

flashit : $(OUTFILES) build/.gdbinit
openocd -f $(SHARE)/openocd.cfg \
-c "init" \
-c "reset halt" \
-c "flash write_image erase build/ch.elf" \
-c "reset init" \
-c "resume" \
-c "shutdown"

reset : $(OUTFILES)
openocd -f $(SHARE)/openocd.cfg -c init -c "reset init" -c "resume" -c shutdown

If you add those rules and "make flashit" from the command line, it should put the code on your disco board. And if that works, you know openocd is doing the right thing.

[mrflibble]

Compiler is CodeSourcery lite 2013.11-24 ...

Meh.

That's a GCC toolchain with proprietary crap thrown in so you'll get hooked and upgrade to their paid version. Why not go with pure play open source?

https://launchpad.net/gcc-arm-embedded

Only so many hours in the day. But I'll give that one a go.

Also, since you're using ChibiOS, here's a few Makefile rules I add to my projects that may help:

Thanks! Any particulars I'll need for that gdbinit?

[andyturk]

Thanks! Any particulars I'll need for that gdbinit?

You could probably live without it. I use the .gdbinit feature to create a command within gdb to fire up openocd. Usually, I just launch gdb (from within emacs, if you must know) and then type "oocd" at gdb's prompt to get going. Of course, that's only for a debugging session. Flashing the board happens from the command line (or an emacs compilation) and doesn't actually require gdb for anything.

The shell commands are for a unix environment (mine is OS X).

gdbinit

Code: [Select]

define oocd
  shell openocd -f ../../share/openocd.cfg >/tmp/oocd.log 2>&1 &
  target remote :3333
  monitor reset halt
end

document oocd
  Creates an Open OCD child process with output redirected to /tmp
end

../../share/openocd.cfg (basically a clone of openocd's stm32f4discovery.cfg)

Code: [Select]

# This is baracus v1 board with a single STM32F407VGT6 chip.

source [find interface/stlink-v2.cfg]
source [find target/stm32f4x_stlink.cfg]

# use hardware reset, connect under reset
reset_config srst_only srst_nogate


[andersm]

At any rate, with a regular unpatched openocd checkout I get that remote 'g' packet error message. Alternatively I tried using an XML file with register description like this: https://github.com/elliottt/stm32f4/blob/master/stm32f4/support/gdb-tdesc-cortexm-fpa.xml

Try using the name "org.gnu.gdb.arm.core" for the first feature. I've successfully used an otherwise similar XML with a Cortex-M3, I don't think the GDB version I used then had a separate M-profile target.

[mrflibble]

At any rate, with a regular unpatched openocd checkout I get that remote 'g' packet error message. Alternatively I tried using an XML file with register description like this: https://github.com/elliottt/stm32f4/blob/master/stm32f4/support/gdb-tdesc-cortexm-fpa.xml

Try using the name "org.gnu.gdb.arm.core" for the first feature. I've successfully used an otherwise similar XML with a Cortex-M3, I don't think the GDB version I used then had a separate M-profile target.

Thanks for the suggestion. Unfortunately no workey:

Error: gdb requested a non-existing register

[dannyf]

I'm game for a paid-for vs open sauce suckage comparison

That's not necessary: your experience here is quite convincing, I think.

[mrflibble]

I'm game for a paid-for vs open sauce suckage comparison

That's not necessary: your experience here is quite convincing, I think.

Quite. I am also an armchair psychologist easily amused by people that reach conclusions by extrapolating a single data point. Or should that interpolating? Well, it's polating something, that's for sure. For all you know I could be wildly incompetent and the tools are just absolutely peachy.

[dannyf]

people that reach conclusions by extrapolating a single data point.

Those people invented bayesian update.

Their opposite are people who are terrified to make decisions unless they have perfect information. Last I heard, they are not very well paid nor respected.

[andersm]

I'll take having to spend a couple of hours getting to know your tools over expensive, dongle- or otherwise-protected, closed and inevitably unsupported tools any day of the year.

[mrflibble]

people that reach conclusions by extrapolating a single data point.

Those people invented bayesian update.

Their opposite are people who are terrified to make decisions unless they have perfect information. Last I heard, they are not very well paid nor respected.

I would give you a book recommendation on the subject of reasoning under uncertainty. But I'm not entirely sure I would get the title right without walking all the way over to my bookcase. The uncertainty ... it paralyzes me!

moving along ... *presses compile button*

[andersm]

Thanks for the suggestion. Unfortunately no workey

Looking closer, there was another difference: the status register was named "cpsr" instead of "xpsr", but I don't know if that's important or not.

[mrflibble]

Progress! I can now get threads, timers + tracebuffers in the ChibiOS/RT tab.

[andyturk]

That's not necessary: your experience here is quite convincing, I think.

For a professional project, the most expensive thing is time. So if you save significant time using the proprietary tools (and paying for them), that's totally fine. Speaking only for myself, I've wasted much more time screwing around with half-assed IDEs over the years than I've spent dealing with emacs (my IDE) and GCC. So I'm more comfortable (and faster) just going right to the source and building the toolchain if necessary.

[dannyf]

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.

Also a big fan of CoIDE too.