Setting up Debugging with Code::Blocks  [SOLVED]

Post Reply
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Setting up Debugging with Code::Blocks

Post by Pete9008 »

I've got Code::Blocks installed and compiling the stm32_sine code but I'm struggling to figure out how to get it to work with the stlink adaptor for debugging and downloading code. Can anyone offer any advice?

BTW - I'm running it on Linux
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks  [SOLVED]

Post by Pete9008 »

OK, I think this is working so I'm going to document what I've done (well what I can remember of it anyway!). Apologies if it is already documented somewhere else but I couldn't find it.

Note this is all on Linux Mint using a ST-Link debug interface.

Install:
  • gcc arm toolchain - 'sudo apt-get install gcc-arm-none-eabi'
  • gcc arm library - 'sudo apt-get install libnewlib-arm-none-eabi'
  • stlink-tools - (if using the ST-LINK or compatible debug tool) - You might have success with 'sudo apt-get install stlink-tools', I didn't and had to do 'git clone https://github.com/stlink-org/stlink', 'cd stlink/', 'cmake .', 'make', 'sudo make install' and finally a 'ldconfig' to get the library path registered (this last step might get the apt-get install to work too).
  • debug server - 'openocd - 'sudo apt-get install openocd'
  • Code::Blocks - I installed from the Linux Mint software manager but I'm sure it can be done through apt-get too.
To check stlink run 'st-flash read dummy.bin 0 0xFFFF' and check you get sensible results and the bin file

To run openocd - 'openocd -f board/st_nucleo_f103rb.cfg', check it finds the hardware. This needs to be running in a command shell whenever trying to debug. Note - this config suits the Nucleo-64 eval board that I'm using. OpenInverter hardware may need a different config file/s.

Get the stm32-sine source and compile as per the readme instructions in it.

To program the processor - 'st-flash write stm32_foc.bin 0x08000000' Note - I'm bypassing the bootloader for now and so use 0x08000000. For standard code that is using the bootloader is should be 0x08001000 as otherwise the bootloader will be overwritten. Either way this and the contents of stm32_sine.ld should match!

To set up Code::Blocks:
  • Open Code::Blocks and open the sinus.cbp file in the stm32-sine directory
  • In Settings, Compiler select GNU GCC Compiler for ARM at the top
  • In the same window go to Toolchain executables and for:
    C compiler click the '..', browse to /usr and select the arm-none-eabi-gcc file
    C++ compiler click the '..', browse to /usr and select the arm-none-eabi-g++ file
    Linker click the '..', browse to /usr and select the arm-none-eabi-gcc file (I did this for both static and dynamic - no idea if that's right or whether the static should be arm-none-eabi-ar? anyone know?)
    Change the debugger to GDB/CDB debugger : Default
  • In Settings, Debugger, under default change the Executable path to /usr/bin/gdb-multiarch. (you may need to do 'sudo apt-get install gdb-multiarch' if it's not there)
  • Optional - change the '-0s' to '-0g -g' in the Makefile to change optimisation to suit debugging and enable debug output
The Code::Blocks build functions should now work to build the stm32-sine project (make sure you select the right Build target in the dropdown in the top tool bar).

If the board, with stm32-sine on it, is connected to the ST-LINK and openocd is running you should be able to hit the Debug/Continue button to start debugging.

There is probably a better/simpler way to do the above. If anyone knows what it is please add the details. In particular it would be nice to have Code::Blocks automatically start openocd and download the rebuilt code to the board before starting debugging.

Edit - I take that back, it already rebuilds when needed and downloads the code automatically (I assume this must be the load commands that johu has already set up on the CodeBlocks project :)

Edit2 - The only way I can find to start openocd from CodeBlocks is to add it to Tools. Click Tools, Configure tools. Click Add, give it a name of 'Start OpenOCD' set the Executable to 'openocd -f board/st_nucleo_f103rb.cfg' (or whatever .cfg suits tour board), set the Working directory to '${PROJECTDIR}' and select the 'Launch tool visible detached' radio button. Then click OK. If you want to be able to stop openocd add another with the executable set to 'pkill openocd' (not really needed but the flashing light on the ST-Link while openocd is running gets on my nerves).

EDIT3 - The above is intended to allow debugging of just the processor hardware on the bench. I would strongly recommend that you do NOT debug with HV or a motor connected. Hitting a breakpoint at the wrong moment could cause all sorts of problems and you do not want a motor to be spinning when that happens!

Edit Jul23 - Just installed on an up to date version of Linux and found the following has changed:
  • libnewlib-arm-none-eabi is now installed as part of gcc-arm-none-eabi so doesn't need doing as a separate step.
  • 'sudo apt-get install stlink-tools' now works fine.
  • The compiler and linker paths are now /usr/bin (probably should have been before and it was my error in taking notes!)
  • Codeblocks now works fine with no crashes to date (and the version available in the Linux Mint software manager is up to date).
  • Note - the below post re. openocd setup is still recommended.
  • When setting up openocd in CodeBlocks PROJECTDIR has changed to PROJECT_DIR
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks

Post by Pete9008 »

Few final tweaks to get Code::Blocks set up the way I'm used to:

First the debug control shortcut keys seem to be different to every other debugger I've used. If the codeblocks-contrib pligin is installed they can be changed to the more normal F5, F9, F10 and F11 (run, breakpoint, step over and step in to).

Second, I prefer the debugger to run to main and then stop when it starts up. This can be done by going to Project, Properies, Debugger. Select the target you want to change and change the 'Additional GDB commands' from 'load, r' to 'load, break main, r'.

Finally, I like to be able to hover over a variable in the debugger and see the value rather than the definition. To enable this got to Settings, Debugger, Default and check the box for 'Evaluate Expression under cursor'

The only thing I can't find in CodeBlocks is SVG file support to allow viewing the processors peripheral registers. There is a plugin but from comments it appears to need a custom CodeBlocks build and to not be that stable. There is a memory window which can bus used to do the same it's just much harder work to interpret the data.

With all that done it makes a pretty good IDE for embedded code, probably not quite up to Eclipse standards but much easier to set up and use!

EDIT - I would not recommend point 2 above (break on main). It works but only once, if you try to terminate and restart the debug session it locks up and you have to unplug and replug the ST-Link USB lead :(

EDIT2 - The above is intended to allow debugging of just the processor hardware on the bench. I would strongly recommend that you do NOT debug with HV or a motor connected. Hitting a breakpoint at the wrong moment could cause all sorts of problems and you do not want a motor to be spinning when that happens!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks

Post by Pete9008 »

While CodeBlock works fine for debugging I really wouldn't recommend using it for editing code.

On Linux at least it starts to crash as soon as the autocomplete starts working. In half an hour I've had half a dozen crashes with half of those needing a PC reboot before CodeBlocks will restart!

Hopefully it's a bit more stable on Windows?

I can feel a 'Setting up Debugging with Eclipse' thread coming on :(

Edit - Disabling the symbol browser seems to help with the crashes (Settings, Editor, Code Completion (on the left), Symbols browser and check 'Disable symbols browser')

EDIT2 - The above is intended to allow debugging of just the processor hardware on the bench. I would strongly recommend that you do NOT debug with HV or a motor connected. Hitting a breakpoint at the wrong moment could cause all sorts of problems and you do not want a motor to be spinning when that happens!
User avatar
johu
Site Admin
Posts: 5682
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Setting up Debugging with Code::Blocks

Post by johu »

I'm running CodeBlocks 20.03 on Linux just fine. Code completion sometimes fails to parse some files though...
I do think Eclipse is generally more modern but also awfully convoluted. Thats why I never made the switch
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks

Post by Pete9008 »

Since turning off the symbol browser its been fine.

Agree on Eclipse, its a very heavy application. Now codeblocks seems stable I'll stick with it :)
User avatar
Jack Bauer
Posts: 3563
Joined: Wed Dec 12, 2018 5:24 pm
Location: Ireland
Has thanked: 1 time
Been thanked: 87 times
Contact:

Re: Setting up Debugging with Code::Blocks

Post by Jack Bauer »

Really appreciate this thanks. Last device i did this kind of thing with was a PIC16F877 :)
I'm going to need a hacksaw
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks

Post by Pete9008 »

Jack Bauer wrote: Tue Sep 06, 2022 8:27 am Really appreciate this thanks. Last device i did this kind of thing with was a PIC16F877 :)
Glad it's of use :)

I remember the F877, weren't Microchip one of the first to introduce low cost on chip debug?

I learnt to code on an 8051. No debugger, but we did have an emulator, a shoebox sized box of electronics that would plug into the target hardware in place of the processor via a ribbon cable and special plug. No in source code debug but you could set breakpoints in the assembler and look at memory locations (having looked up variable locations in the linker map file). All slow work but still a lot easier than the 10min process to erase the EPROM chip in the UV eraser box and reprogram it in the Stag programmer!

Compared to that the PIC debug system seemed fantastic! Compared to today's tools though it was incredibly basic!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Setting up Debugging with Code::Blocks

Post by Pete9008 »

Just found a bug with the above while trying to use it with a Bluepill board. These don't have a hardware reset connection to the debug probe so need a modified board config file. Not found a standard one that quite fits so the easiest way seems to be to add a new one and point the openocd command to it, the contents need to be:

Code: Select all

# This is intended for SWD connection to a single STM32F103RBT6 chip without hardware reset.

source [find interface/stlink-v2-1.cfg]

transport select hla_swd

source [find target/stm32f1x.cfg]

reset_config none
I've dropped it in the project directory which makes it easy to have a single tools command but still allows the project to define what the target processor is so the CodeBlocks tool setup looks like this:
CodeBlocks_openocd.png
Edit Jul23 -
When setting up openocd in newer versions of CodeBlocks PROJECTDIR has changed to PROJECT_DIR.
Also name used above for config file is not very sensible (it implies a stm32f1 processor while I'm using this for an f4 processor too), now use the name openocd.cfg so it's appropriate to any processor.
Post Reply