Using eclipse to flash/debug

[theseankelly]

Hey -- I was hoping someone could help me get setup with Eclipse configuration for openocd flashing/debugging. I'm on a windows PC and unfortunately at the moment I don't have a PC that's capable of running the bitcraze VM so I can't use that (nor can I go look at the eclipse config in the VM).

I have open-ocd all set up and working properly: I can 'make flash' over SWD and I can connect up and step through the code in eclipse, but the steps I need to take to get there are pretty cumbersome. My workflow goes like this:

1) make a code change
2) <terminal> make CLOAD=1 DEBUG=1
3) make flash (successfully flashes over openOCD)
4) for some reason, this step blows away the STM32 bootloader, so
5) cd ..\crazyflie2-stm-bootloader
6) make flash
7) crazyflie boots up
8) jump over to eclipse, start debugging (currently configured to reset, break on main, and NOT load an image)
9) hit the reset button on the debug board
10) hit my breakpoint at main

I'd really like to just build and then use eclipse to load the firmware. I haven't been able to get the "load image" option to work right, though -- is there an image offset required? I've tried 0x4000 and 0x80004000 (from the makefile) but those don't work either. I've done this plenty of times for other chips so I don't know why I'm having so much trouble with it.

Also, I think I've asked this before but never chased it down -- any ideas why 'make flash' destroys the STM bootloader?

Thanks
Sean

[tobias]

You definitely found an improvement topic. At one point I also tried getting the eclipse debugging working smooth but got frustrated and gave up. Since then I've been doing it similar to you. The GNU ARM Eclipse plugin have made it a bit simpler though and I don't have to start a OpenOCD session before starting the debug (the plugin does it instead). I have also created make targets (as in the VM) which does the flashing so I don't have to switch to a terminal to flash. However it can be simplified even more and most irritating is the removal of the bootloader.

The issue with the bootloader is that we couldn't get the debugging working with it still in place. Either the linker file or GDB is configured wrong and doesn't understand where the firmware is located. So instead we flash to the beginning of the flash when debugging (lazy workaround I guess). Would be great to find a fix, so if you have any ideas.

Loading firmware through GDB I never managed to do though but haven't really put time into investigating why it doesn't work.

[theseankelly]

I'll poke around a little bit. I know the gdb flasher defaults to auto-erase mode when flashing, and I suspect it's also auto-erasing the bootloader even though the firmware target is at an offset.

[arnaud]

We have had the problem for a long time with openocd too. Basically this is not working (all from console with "make flash"):
1- Flasing the bootloader
2- Flashing the firmware in bootloader mode

But, surprisingly this is working:
1- Flashing the firmware in bootloader mode
2- Flashing the bootloader

So, somehow, flashing the firmware alter the bootloader, damages the bootloader. But from my experience GDB works: if you "make openocd" and then connect a gdb to it (from the console). Then after modifying the firmware loading the new firmware with gdb works! Maybe eclipse is adding some magic commands on top of that though.

/Arnaud