STM32F4 + eclipse ChibiOS plugin + option bytes fun!  - Page 1
Forum section: electronics / general

author: mrflibble
author_rank: Super Contributor
timestamp: January 20, 2014, 03:27:07 pm
content: 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, whichin hindsightprobably 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:Open On-Chip Debugger 0.8.0-dev-00319-g94d64cc (2014-01-19-12:45)Licensed under GNU GPL v2For bug reports, readhttp://openocd.sourceforge.net/doc/doxygen/bugs.htmlsrst_only separate srst_nogate srst_open_drain connect_deassert_srstInfo : This adapter doesn't support configurable speedInfo : STLINK v2 JTAG v17 API v2 SWIM v0 VID 0x0483 PID 0x3748Info : using stlink api v2Info : Target voltage: 2.897578Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpointsInfo : accepting 'gdb' connection from 3333Halting target on gdb-attachtarget state: haltedtarget halted due to debug-request, current mode: ThreadxPSR: 0x41000000 pc: 0x08002058 psp: 0x20000e78Warn : acknowledgment received, but no packet pendingInfo : Auto-detected RTOS: ChibiOSInfo : Successfully loaded memory map of ChibiOS/RT target running version 2.6.0It's a fresh git clone from yesterday.As init commands on gdb startup I have:Code:set arch i386:x86_64set remote memory-write-packet-size 1024set remote memory-write-packet-size fixedset remote memory-read-packet-size 1024set remote memory-read-packet-size fixedfile /full/path/ch.elfThe "set arch" isintendedto 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 20, 2014, 03:44:41 pm
content: 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:arm-none-eabi-gdb --eval-command='target extended localhost:3333'(gdb) monitor mdw 0x40020c100x40020c10: 0000f020And 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 20, 2014, 08:16:54 pm
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 20, 2014, 08:30:09 pm
content: Quote from: mrflibble on January 20, 2014, 03:27:07 pmI 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 12:02:46 am
content: Quote from: andyturk on January 20, 2014, 08:16:54 pmYes, no, sortof.I only tried thatset arch i386:x86_64as a crazy last ditch effort. Unsuprisingly it didn't work. Normally arch is just set to "arm".QuoteI 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:--- 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[], intstruct 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.xmlBut that didn't help either. So I'm a bit stumped as to why I'm still getting that error...Quote from: andyturk on January 20, 2014, 08:30:09 pmThanks, that's worth a try.QuoteYup, that's pretty much what I ended up doing, minus the VM and plus the actual reboot. Didn't want to take any chances...

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: January 21, 2014, 01:12:05 am
content: 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 21, 2014, 02:14:26 am
content: Quote from: mrflibble on January 21, 2014, 12:02:46 amI 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 21, 2014, 02:26:01 am
content: 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?

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 05:11:11 pm
content: Quote from: andyturk on January 21, 2014, 02:14:26 amHeh. 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.oI installed a recent eclipse just to be sure it's not that, so I now use 4.3 Kepleromgwhatnamewillwethinkofnextmommycanweusenumbersagain.Quote from: HackedFridgeMagnet on January 21, 2014, 01:12:05 amCode: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 autoQuote from: dannyf on January 21, 2014, 02:26:01 amYes. 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 21, 2014, 05:43:57 pm
content: The fact that both are buggy doesn't mean they are equally buggy.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 05:48:38 pm
content: Quote from: dannyf on January 21, 2014, 05:43:57 pmAt 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.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 21, 2014, 05:58:46 pm
content: Quote from: mrflibble on January 21, 2014, 05:11:11 pmMeh.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-embeddedAlso, since you're using ChibiOS, here's a few Makefile rules I add to my projects that may help:Code:build/.gdbinit : $(SHARE)/gdbinit@cp $(SHARE)/gdbinit build/.gdbinitflashit : $(OUTFILES) build/.gdbinitopenocd -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 shutdownIf 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 06:08:34 pm
content: Quote from: andyturk on January 21, 2014, 05:58:46 pmOnly so many hours in the day. But I'll give that one a go.QuoteThanks! Any particulars I'll need for that gdbinit?

author: andyturk
author_rank: Frequent Contributor
timestamp: January 21, 2014, 06:24:29 pm
content: Quote from: mrflibble on January 21, 2014, 06:08:34 pmYou 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).gdbinitCode:define oocdshell openocd -f ../../share/openocd.cfg >/tmp/oocd.log 2>&1 &target remote :3333monitor reset haltenddocument oocdCreates an Open OCD child process with output redirected to /tmpend../../share/openocd.cfg (basically a clone of openocd's stm32f4discovery.cfg)Code:# 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 resetreset_config srst_only srst_nogate

author: andersm
author_rank: Super Contributor
timestamp: January 21, 2014, 07:42:42 pm
content: Quote from: mrflibble on January 21, 2014, 12:02:46 amTry 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 08:29:40 pm
content: Quote from: andersm on January 21, 2014, 07:42:42 pmThanks for the suggestion. Unfortunately no workey:Error: gdb requested a non-existing register

author: dannyf
author_rank: Super Contributor
timestamp: January 21, 2014, 08:35:47 pm
content: QuoteThat's not necessary: your experience here is quite convincing, I think.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 08:49:17 pm
content: Quote from: dannyf on January 21, 2014, 08:35:47 pmQuite. 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 21, 2014, 08:56:15 pm
content: QuoteThose 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.

author: andersm
author_rank: Super Contributor
timestamp: January 21, 2014, 09:00:42 pm
content: 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 09:05:11 pm
content: Quote from: dannyf on January 21, 2014, 08:56:15 pmI 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*

author: andersm
author_rank: Super Contributor
timestamp: January 21, 2014, 09:19:33 pm
content: Quote from: mrflibble on January 21, 2014, 08:29:40 pmLooking 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 21, 2014, 09:29:10 pm
content: Progress! I can now get threads, timers + tracebuffers in the ChibiOS/RT tab.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 21, 2014, 09:54:12 pm
content: Quote from: dannyf on January 21, 2014, 08:35:47 pmFor 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 21, 2014, 09:57:24 pm
content: QuoteDie-hard Keil / IAR fan here. None of those issues.Also a big fan of CoIDE too.

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: January 22, 2014, 05:48:07 am
content: Quotewas my .cfg file, when I hadn't changed this from 20k and the debugger didn't work as expected.

author: andersm
author_rank: Super Contributor
timestamp: January 22, 2014, 07:34:50 am
content: Quote from: dannyf on January 21, 2014, 09:57:24 pmAt 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 22, 2014, 08:50:31 am
content: Quote from: HackedFridgeMagnet on January 22, 2014, 05:48:07 amIn what way "didn't work as expected"? Exploding during flashing, or something subtle?

author: HackedFridgeMagnet
author_rank: Super Contributor
timestamp: January 22, 2014, 11:02:11 am
content: 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 debuggerhttp://hertaville.com/2012/05/28/gcc-arm-toolchain-stm32f0discovery/http://thehackerworkshop.com/?tag=eclipse

author: mrflibble
author_rank: Super Contributor
timestamp: January 22, 2014, 03:46:50 pm
content: Quote from: andyturk on January 21, 2014, 02:14:26 amIncidentally, 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-cvsIs there a magic range of gdb versions I should be using?

author: mrflibble
author_rank: Super Contributor
timestamp: January 22, 2014, 04:12:12 pm
content: Quote from: HackedFridgeMagnet on January 22, 2014, 11:02:11 amThat 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 asymbol-file .../ch.elfcommand. 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 22, 2014, 08:47:52 pm
content: Something that's relatively easy to reproduce:getchibios 2.6.2(latest stable)cd ChibiOS_2.6.2/demos/ARMCM4-STM32F407-DISCOVERY-G++makearm-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 threadsId 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: 00000000000000000000000000000000310600080000000000000000000000000000000000000000000000000000000000000000c009002000000000a10500080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000Openocddoeshave 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-cvsOpen On-Chip Debugger 0.8.0-dev-00328-g0b26376 (2014-01-21-11:15)

author: andyturk
author_rank: Frequent Contributor
timestamp: January 23, 2014, 12:50:34 am
content: Quote from: mrflibble on January 22, 2014, 08:47:52 pmAre 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?

author: mrflibble
author_rank: Super Contributor
timestamp: January 23, 2014, 10:00:44 am
content: Quote from: andyturk on January 23, 2014, 12:50:34 amIn 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.QuoteWell, it obviouslyisFP 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 domonitor regI still get the correct registers. But the moment I doinfo 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 aninfo threadson 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.

author: mrflibble
author_rank: Super Contributor
timestamp: January 23, 2014, 11:19:14 am
content: Quote from: mrflibble on January 23, 2014, 10:00:44 amJust tested on different 64-bit box. Nope, same result.

author: andyturk
author_rank: Frequent Contributor
timestamp: January 23, 2014, 03:02:47 pm
content: Quote from: mrflibble on January 23, 2014, 10:00:44 amI'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

author: mrflibble
author_rank: Super Contributor
timestamp: January 23, 2014, 03:27:15 pm
content: Quote from: andyturk on January 23, 2014, 03:02:47 pmThanks!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 ChibiOSIn gdb, preferably before you connect to target:symbol-file build/ch.elf

author: andyturk
author_rank: Frequent Contributor
timestamp: January 23, 2014, 04:56:17 pm
content: Quote from: mrflibble on January 23, 2014, 03:27:15 pmAh. Well, when I do the stm32f4x.configure, I get the packet reply error, same as you.

author: mrflibble
author_rank: Super Contributor
timestamp: January 23, 2014, 09:24:55 pm
content: 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 withtdesc 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:--- src/rtos/rtos_chibios_stackings.c.orig2014-01-21 10:52:18.000000000 +0100+++ src/rtos/rtos_chibios_stackings.c2014-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 */+#else26,/* num_output_registers */+#endif0,/* 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.

author: ntfreak
author_rank: Contributor
timestamp: March 17, 2014, 01:48:37 pm
content: 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.CheersSpen

author: mrflibble
author_rank: Super Contributor
timestamp: March 17, 2014, 04:47:09 pm
content: Quote from: ntfreak on March 17, 2014, 01:48:37 pmThat 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.

author: ntfreak
author_rank: Contributor
timestamp: March 17, 2014, 05:03:37 pm
content: 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

author: mrflibble
author_rank: Super Contributor
timestamp: March 17, 2014, 06:05:00 pm
content: 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 doinfo threadsin 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:Idoget 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 runinfo threadsfrom 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.

author: ntfreak
author_rank: Contributor
timestamp: March 18, 2014, 01:20:58 pm
content: 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_chibiosIt 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=6608Spen