Using RIOT and bluepill

Hi everyone, I’m trying to implement the vl53l0x driver on RIOT. To have a simple working scenario I’m trying to flash an example using stlinkV2 and the bluepill (STM32F103xx) and I can’t make the ‘flash’ and ‘debug’ targets work. Can someone give me a hint on how to make it work?

“make QUIET=0 BOARD=bluepill-128kib all” works fine.

Also when wanting to blink a led, the build says… …/gcc-arm-none-eabi-9-2019-q4-major/bin/…/lib/gcc/arm-none-eabi/9.2.1/…/…/…/…/arm-none-eabi/bin/ld: …/riot/examples/hello-world/bin/bluepill-128kib/stm32_vectors/vectors_f1.o: in function dummy_handler': ...riot/cpu/stm32/vectors/vectors_f1.c:27: multiple definition of dummy_handler’; …/riot/examples/hello-world/bin/bluepill-128kib/stm32_vectors/STM32F103xB.o:…/riot/cpu/stm32/vectors/STM32F103xB.c:14: first defined here …gcc-arm-none-eabi-9-2019-q4-major/bin/…/lib/gcc/arm-none-eabi/9.2.1/…/…/…/…/arm-none-eabi/bin/ld: …/riot/examples/hello-world/bin/bluepill-128kib/stm32_vectors/vectors_f1.o:…/riot/cpu/stm32/vectors/vectors_f1.c:87: multiple definition of `vector_cpu’; …riot/examples/hello-world/bin/bluepill-128kib/stm32_vectors/STM32F103xB.o:/…/riot/cpu/stm32/vectors/STM32F103xB.c:57: first defined here

I know my stlink works as “st-flash --reset write bin/bluepill/tests_xtimer_msg_receive_timeout.bin 0x08000000” works fine.

Thanks for your help! :slight_smile:


did you connect the reset pin of your blue pill to the debugger? Without a physical reset signal flashing won't work. For more details consult the doc [1]

Also, if you happen to own a cheap ST-Link v2 clone rather than an official one: I was told that the reset pin of them is often broken. You can manually press the reset button instead: Hold it down until you see the OpenOCD output and release it then.

Regarding the "dummy_handler": We should rename the dummy_handler in the ISR vectors to avoid symbol name collisions like that. Feel free to open an issue to track this. For now, just rename your function, e.g. to "my_handler".

Kind regards, Marian


Hi Javier,

The build issue caused by the multiple definition of dummy_handler is probably due to the fact that you first build a very recent version of RIOT and then went back to a branch based on an old version.

The latest master contains changes in stm32 to automatically generate the vectors file (here it’s STM32F103xB.c). If you checkout an older version, the generated file is still there because it’s ignored by git. So you end up with 2 files defining the same isr functions (STM32F103xB.c and vectors_f1.c) and these 2 files are automatically built by the build system.

I suggest that you either remove cpu/stm32/vectors/STM32F103xB.c or rebase your branch (probably the branch with your driver code?) on top of latest master.