MCU not boooting after flashing

[mur]

Hi,

I'm using an STM32F334 in a Nucleo development board. I have flashed the device both with STM32 ST-Link utility and after finishing, I connect the development board to an external supply and the MCU does not start running unless the RST button is pressed. Then I wonder, for a series manufacturing system where the user will not be hittting reset, how should that be programmed? Or is any external hardware handling the RST pin?

Thanks.

[TDK]

How do you know it's not running? As opposed to being stuck somewhere in the code?

BOOT0 needs pulled down, then the chip will boot into user flash on powerup or reset, provided you're not doing things to option bytes.

[waclawek.jan]

Isn't there a demo binary with which the board comes preprogrammed (basically blinky) in the Cube package or in the binaries on ST webpage?

JW

[mur]

I don't know whether is stuck, but what could be the reason for the code to always get stuck if the reset is not performed and run properly after the reset?

How could I test for realising what is actually happening?​

[mur]

Hi jw, i dont really follow your idea. I want to clarify that I already have developed a working program which I've been using for a long time now in the development board. So the program has been validated and has not giving issues when I was programming using the debug button from the IDE.

[Tesla DeLorean · Accepted solution]

What version of firmware is on the ST-LINK? Perhaps try updating that.

Assuming BOOT0 is low, as it is a NUCLEO board, I'm going to guess that the code probably IS running, and is either dying in the Error_Handler() or HardFault_Handler() while(1) loops.

Check your code doesn't have any timing dependencies on external hardware/signals, instrument your code so you can tell if it is alive and how far and where it got into the firmware.

[mur]

This actually triggered a flag. I was able to use HAL_GPIO_TogglePin() to switch on an LED, and doing so inside void Error_Handler(void) confirmed that the issue is because the system reaches the infinite loop there.

Then what I did was to add an infinite loop to track back until the LED was not turned on anymore, eventually discovering that MX_CAN_Init(); was causing this issue. Thanks for the support.