Electronics - STM32 - Blinking all F3Discovery LEDs at the same time

Christmas is near (only 6 months), so we have to prepare our xmas tree.

What a better option than using our dear STM32F3Discovery board as a Christmas lights?

Let's see this in this tutorial.

(And yes, Santa Claus is watching you, so be kind.)

Shopping list

The Github for this tutorial with full files and code:

• https://github.com/badprog/badprog-electronics-stm32-blinking-all-f3discovery-leds-at-the-same-time

IDE:

• VSCode
• DevContainer extension

Board:

• STM32F3Discovery

First of all

With Ubuntu 24.04 trying to install gcc-arm-none-eabi compiler doesn't work as expected.

Indeed the classic package is shiped without the newlib library for embedded targets.

Meaning that includes like <errno.h> will fail at compile time. 

That's why we have to install the libnewlib-arm-none-eabi package.

But it's been removed from the Ubuntu 24.04 repositories.

The only option is to download it directly from the ARM website.

This is what we do in the Dockerfile.

The second pitfall we have to deal with is with CMake is made to work by default with GCC x86.

So it searches first gcc in the path.

To contourn this situation we have to specify the CMake toolchain file that we want CMake uses instead of its default behaviour.

This is done by using the cmake/arm-none-eabi.cmake file from our project in which we specify each of the arm-none-eabi-xxx tools.

Furthermore, in this same .cmake file, we tell CMake there is no OS used in this device with the CMAKE_SYSTEM_NAME Generic line.

And we ask CMake not to generate a test program to probe the compiler because there is no main() entry point in a bare metal target.

We do that by adding this line in the file: CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY.

Let's code a bit

In order to compile the project, we first need to generate CMakeFiles (instead of Makefiles).

To be sure to generate files in the right folder, go to the firmware/stm32f3discovery directory then type the following in your terminal:

$ cmake -B build \
  -DCMAKE_TOOLCHAIN_FILE=cmake/arm-none-eabi.cmake \
  -DCMAKE_BUILD_TYPE=Debug \
  -G Ninja

The -G Ninja option tells CMake to generate Ninja build files instead of Makefiles.

It should generates the following output:

DCMAKE_BUILD_TYPE=Debug -G Ninja

-- The C compiler identification is GNU 13.3.1

-- The ASM compiler identification is GNU

-- Found assembler: /usr/local/bin/arm-none-eabi-gcc

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Check for working C compiler: /usr/local/bin/arm-none-eabi-gcc - skipped

-- Detecting C compile features

-- Detecting C compile features - done

-- Build type: Debug

-- Configuring done (0.4s)

-- Generating done (0.0s)

-- Build files have been written to: /workspaces/stm32-firmware-blinking-all-leds/firmware/stm32f3discovery/build

 So we can now generate binaries with Ninja:

$ ninja -C build

Generating:

ninja: Entering directory `build/'

[5/5] Linking C executable stm32f3discovery

/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld: warning: stm32f3discovery has a LOAD segment with RWX permissions

Memory region         Used Size  Region Size  %age Used

          CCMRAM:           0 B         8 KB      0.00%

             RAM:        1976 B        40 KB      4.82%

           FLASH:        1152 B       256 KB      0.44%

   text    data     bss     dec     hex filename

   1136      16    1972    3124     c34 /workspaces/stm32-firmware-blinking-all-leds/firmware/stm32f3discovery/build/stm32f3discovery

If everything went OK you should have the following files generated in build/:

• stm32f3discovery
• stm32f3discovery.bin
• stm32f3discovery.hex

If it's the case, let's continue by flashing the firmware on the board:

$ openocd -f interface/stlink.cfg \
        -f target/stm32f3x.cfg \
        -c "program build/stm32f3discovery.bin verify reset exit 0x08000000"

• /usr/share/openocd/scripts/interface/stlink.cfg
• /usr/share/openocd/scripts/target/stm32f3x.cfg

Open On-Chip Debugger 0.12.0

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

Info : clock speed 1000 kHz

Info : STLINK V2J24S0 (API v2) VID:PID 0483:3748

Info : Target voltage: 2.913369

Info : [stm32f3x.cpu] Cortex-M4 r0p1 processor detected

Info : [stm32f3x.cpu] target has 6 breakpoints, 4 watchpoints

Info : starting gdb server for stm32f3x.cpu on 3333

Info : Listening on port 3333 for gdb connections

[stm32f3x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0x01000000 pc: 0x08000408 msp: 0x2000a000

Info : Unable to match requested speed 1000 kHz, using 950 kHz

Info : Unable to match requested speed 1000 kHz, using 950 kHz

[stm32f3x.cpu] halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x08000408 msp: 0x2000a000

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

** Programming Started **

Info : device id = 0x10036422

Info : flash size = 256 KiB

Warn : Adding extra erase range, 0x08000480 .. 0x080007ff

** Programming Finished **

** Verify Started **

** Verified OK **

** Resetting Target **

Info : Unable to match requested speed 1000 kHz, using 950 kHz

Info : Unable to match requested speed 1000 kHz, using 950 kHz

shutdown command invoked