Nucleo STM32F103RB being bricked, blinky example not running

[Zataras]

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_MODULEPATH=../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?

[atsju]

Hi @Zataras, it will be very difficult to reproduce without more information (especially the stm32-cmake version). It would really help if you share a public git repo with the modifications you explained. I would like to mention that starting from stm32-cmake example as you did is very good because it minimizes "unknown" code to check and you already tested the "good flasher with bad hex" which is great also.

I would recommend you fork this repo (if it's not already done), do the modifications you explained in text and then share the sha of the commit you want to debug. This way anybody will be able to build with exact same configuration.

[Zataras]

Hi @atsju, Thank you for response. That is good point, I will prepare public fork customized and share link here.

[Zataras]

@atsju, I've prepared more details. I've built binary from commit 1a1e23ad095c4c0b1869fe12672a73483f55b597 of my fork. In default opt directory I got V1.8.3 / 20-October-2020 of STM32CubeF1. I'm using cmake version 3.20.1. Some more info printed by CMake: -- No STM32_TARGET_TRIPLET specified, using default: arm-none-eabi -- The C compiler identification is GNU 10.2.1 -- The ASM compiler identification is GNU -- Found assembler: /opt/gcc-arm/bin/arm-none-eabi-gcc

My commit introduces buildHex.py script by which I invoked cmake and the build. Issue persist when building with your toolchain, but I got also some old hex generated from TrueStudio and it is still working fine.

[atsju]

@Zataras I had a quick look to https://github.com/ObKo/stm32-cmake/commit/1a1e23ad095c4c0b1869fe12672a73483f55b597 but haven't seen anything obvious. the code is supposed to work on eval board for STM32F100RBand you use the board for STM32F103RB I suppose ? Can you please confirm what HW target you are using ? (i.e. which nucleo or discovery you are using)

Did you notice that the LED is not on same pin on both boards ? you will need to modify blinky.c and change LED from pin C9 to D13.

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.

It's unrelated I think but just to confirm and understand better :

• what is your "flasher application"?
• what do you call "ST's official app"?

[atsju]

This issue has been closed because of innactivity

[Zataras]

Hi @atsju,

Sorry for leaving this without reply for long time. I'm available again now and you were right - I did not changed the LED pin. Now I've tried building with correct pin number, but as we could expect that was not the main issue here.

The biggest issue here is that the board becomes unresponsive after flashing built program. I've noticed that generated elf file does not fit the F103RB flash size. The only way to flash it I've found is converting to hex. Is this good clue?

You can see my changes to v2.1 on my branch here https://github.com/Zataras/stm32-cmake/tree/F103RB_blinky/examples/blinky

And responding to other questions - for flashing from linux I use

Package: stlink-gui Version: 1.6.0+ds-1 Priority: optional Section: universe/electronics Source: stlink Origin: Ubuntu Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com Original-Maintainer: Luca Boccassi bluca@debian.org Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 184 kB Depends: libstlink1 (= 1.6.0+ds-1), stlink-tools (= 1.6.0+ds-1), libc6 (>= 2.14), libglib2.0-0 (>= 2.37.3), libgtk-3-0 (>= 3.0.0), libusb-1.0-0 (>= 2:1.0.22) Homepage: https://github.com/texane/stlink Download-Size: 47,4 kB APT-Manual-Installed: yes APT-Sources: http://ftp.agh.edu.pl/ubuntu focal/universe amd64 Packages Description: OpenSource ST-Link tools replacement. Flashing tools for STMicroelectronics STM32VL and STM32L. The transport layers STLINKv1 and STLINKv2 are supported. . This package contains a GUI tool for stlink.

And on Windows I use ST-LINK Utility v4.6.0 to debrick the board.

Can you help again please?

[atsju]

The biggest issue here is that the board becomes unresponsive after flashing built program. I've noticed that generated elf file does not fit the F103RB flash size. The only way to flash it I've found is converting to hex. Is this good clue?

Yes I think so but this depends only of the flashing tool supports the format or not.

You can see my changes to v2.1 on my branch here https://github.com/Zataras/stm32-cmake/tree/F103RB_blinky/examples/blinky

you forgot at least one thing: #define LED_PORT_CLK_ENABLE __HAL_RCC_GPIOD_CLK_ENABLE I did not look into details.

And responding to other questions - for flashing from linux I use

And on Windows I use ST-LINK Utility v4.6.0 to debrick the board.

Stlink utility is tagged NRND (not recommended for new designs). I do not develop on linux but I would recommend you switch to stm32cubeprog which is the new recommended tool and it is supported for linux and Windows.

[Zataras]

The biggest issue here is that the board becomes unresponsive after flashing built program. I've noticed that generated elf file does not fit the F103RB flash size. The only way to flash it I've found is converting to hex. Is this good clue?

Yes I think so but this depends only of the flashing tool supports the format or not.

I think the oversized elf file was a problem here.

You can see my changes to v2.1 on my branch here https://github.com/Zataras/stm32-cmake/tree/F103RB_blinky/examples/blinky

you forgot at least one thing: #define LED_PORT_CLK_ENABLE __HAL_RCC_GPIOD_CLK_ENABLE I did not look into details.

I will check that, thanks.

And responding to other questions - for flashing from linux I use

And on Windows I use ST-LINK Utility v4.6.0 to debrick the board.

Stlink utility is tagged NRND (not recommended for new designs). I do not develop on linux but I would recommend you switch to stm32cubeprog which is the new recommended tool and it is supported for linux and Windows.

Thanks very much, that might help

[Zataras]

@atsju, unfortunately, issue still persists. I've updated code as you advice, also changed flashing software. I attach the log from flasher, which shows that it lost connection to target after flashing. Firstly I've erased the chip, than flashed with elf file. Do you understand what is happening here? ErasingAndFlashing.txt

[atsju]

I had a look at your code.

Please confirm you use this board : Nucleo-F103RB ?

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.

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.

[Zataras]

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]

Hi again @atsju ,

I'm back trying to resolve old issues. Now, after carefully modified blinky example it is working. However I still got an issue, that after flashing this program I'm loosing connection to board. It must be related to SWD pins. Should I configure them anyhow? This is about F103RB board.

[atsju]

What do you mean by

loosing connection to board

You are unable to reprogram it ? The COM port disapears ? The ST-Link disapears ?

Are you able to recover the board and to reflash it ?

[Zataras]

I mean I got connection to ST-Link, but ST-Link looses connection to target microcontroller. I am using external ST-Link V2 as I got original one damaged. I was not able to connect under reset, the only way to unbrick was to put BOOT0 pin hight. Then I could connect to target, erase chip and reprogramm it. Uploading binary build with other toolchain is not affecting SWD but when flashed again one compiled with stm32-cmake it blocked SWD again.

[atsju]

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.

[Zataras]

Thank you very much, it was the root cause! Finally blinky example is working fine on my board :) Why not remove __WFI() call from your examples if it can cause problems?