Why my MCU doesn't work when powerup? It only starts code if I do a reset!

[Luis Ber]

Hello,

I have a problem that I don't know to solve and any help will be appreciated very much.

I'm working with STM32L476RCT, and BOOT0 is configured to 0 to boot from flash. The NRST state is also correct.

My problem is when I program the mcu, the code seems to not start. The execution only starts if I do a hardware reset in NRST pin. It also doesn't work when I power up from power off. The code only works if I force a hardware reset (NRST = 0).

I'm sure that is a problem of the firmware because I have tested the MCU with other code and it works properly. I'm working with Eclipse Workbench.

Any tip or indication will be a big help to me.

Thank you very much,

Luis

[Tesla DeLorean]

If BOOT0 is pulled low, it probably is running your code.

Are there things on the board that may power up slower, or take time to start?

Consider a POR circuit if you have multiple power rails.

Make sure you've instrumented any Error_Handler() or HardFault_Handler() type routines where it could go into a while(1) and silently die.

Check for timeouts with external crystal, pll, or whatever is being used as the primary clock source.

[waclawek.jan]

What is connected to the NRST pin?

JW

[Tesla DeLorean]

If it is driven high (ie by a push-pull driver) then the part won't reset properly.

[Alex R]

What IDE or programmer are you using to program the processor?

Some programmers are configured by default to just run to main() right after programming, and therefore, stop execution at main(), which appears to match your description.

[Luis Ber]

I'm using System Workbench for STM32 that is based on Eclipse. I don't know if it is configured to stop execution at main(). Where can I see this configuration?

However, it's important to notice that with other codes (and in the same IDE, programmer and board), the MCU works properly, code execution starts when it is power up). And also I want to remark, that when I debugging the code is executed also fine.

Thank you very much!

[turboscrew]

It's a breakpoint setting command in the debug startup script.

[turboscrew]

Do you have some kind of boot loader? When you load the code with IDE, it starts from the beginning of the loaded image. Using reset makes it jump to the reset vector and so does starting the system without IDE. Well, at least that happens with Eclipse and its derivatives.

However, some time consuming HW start-up sounds more probable here.

[Luis Ber]

I'm using the startup file generated by the Cube software. (startup_stm32l476xx.s) amd the linker that also is generated by Cube (STM32L476RCTx_FLASH.ld). Certainly, I don't know where is the problem. It's important to remark that with other project codes the MCU starts code good (when it is power up and after reset). But with my current project, only starts execution after reset.

I have compared the startup and linker files, but they are the same. I don't know if it is a building configuration, of a configuration file, but I'm sure that is a firmware problem and not a hardware one, because with other projects it is working.

I don't know if it is important, but I have to say that I'm using FreeRTOS. But, I think that this is not involved in the problem.

Thank you very much!

[seejohnleung]

Hi sir,

Did you manage to solve the problem?

Thanks!

[turboscrew]

What happens when you first start debugging? It doesn't stop at the beginning of main? Does it run? Is there a (temporary) breakpoint at the beginning of main?

[BrokenICry]

Have you ever found a solution to this ??

I have the same problem right now with cubeIDE, using the F401RE chip.

[ls_andre]

Try writing a one second delay loop before the "SystemClock_Config();" statement.

Probably you are going to configure the PLL before the external oscillator has fully woken up.

This would lead the code to fall into the Error_Handler() loop.

[pvish.13]

This worked out for me. I was worried as all my custom boards started having this issue.

[ZMikl]

I have same issue with F303-re nucleo and have manage to fix it by updating ST-Link to Debug+MassStorage+VCP. After update code startup at power-up.

[FValm.1]

Same issue here and I followed the tip by @Is_andre to solve the problem. But in my case I needed 2 seconds to wait before the "SystemClock_Config();" statement!

[Yas Yasin]

Hi all

I had the same problem and finally I figured out the BOOT0 pin was not pulled low.

Thanks