stm32-cmake: Nucleo STM32F103RB being bricked, blinky example not running

Hi, I’m trying to use your toolchain for STM32F103RB development, while I’m constantly having this issue. I was trying with my own application first, but I decided to try with your blinky example. I’ve removed F4 and L0 targets, and left only F1 with change to F103 device. I’m configuring CMake with simple cmake -DCMAKE_MODULE_PATH=…/cmake …/blinky I’m generating hex file using extra target: ADD_CUSTOM_TARGET(${TARGET}.hex DEPENDS ${TARGET} COMMAND ${CMAKE_OBJCOPY} -Oihex ${FILENAME} ${FILENAME}.hex) After running make blinky.hex I get successful build and the artifacts. After flashing nucleo with generated binary, nucleo is no longer visible by flasher application. I need to switch to Windows and use ST’s official app and flash with reset button pressed. This helps to nucleo being visible, but flashing hex file with official flasher also do not the app to start blink led. Previosly I was using TrueStudio configuration and everything was working fine. Can you help?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 16

Most upvoted comments

Maybe the MCU actually goes to sleep with __WFI() wich is not the case with your other toolchain https://github.com/ObKo/stm32-cmake/blob/293cef4a83accdb9038506156484d4b27c7c704b/examples/blinky/blinky.c#L57

The sleep could explain the connection loss. Please just replace the __WFI with an empty while(1); loop and try again.

atsju on Apr 26, 2022

Please confirm you use this board : Nucleo-F103RB ?

Yes, I’m using this board exactly. To the community: if anyone reading this had chance to use this project with the same or similar Nucleo board, please let me know. Also if anyone own this board, I would be grateful for checking blinky example.

The user manual states

User LD2: the green LED is a user LED connected to ARDUINO® signal D13 corresponding to STM32 I/O PA5 (pin 21) or PB13 (pin 34) depending on the STM32 target

In this case the arduino signal is not what you want but the STM32 pin name. In case of Nucleo-F103RB it’s PA5. You should update the code accordingly. Unfortunately I cannot test for you because I do not own this board.

Thanks for further advice, I will correct this.

You might also consider using a debugger like Ozone. ST has an arrangement so that segger tools can be used with ST-link on eval boards. Here you will find how to convert the ST-link to a segger probe. This might help you in the futur to understand where and why the code stops working.

Yes, I guess I have no choice. I anything comes to your mind, please let me know.

I have one extra idea - I have also Nucleo board with STM32H7, so I will try how my environment builds binary for that board. If it will be incorrect too, it could be some environment issue…

Zataras on Aug 18, 2021