Code won't run without pressing reset button

[IPrin.1]

My code runs without issue when the STM Nucleo is connected to the laptop, but if I try to run it without connection to PC, I have to press the reset button before the code will run.

I am using STM32CubeIDE and cannot find a solution relevant to that environment.

I can of course create a hardware solution to this but I would rather achieve a solution programmatically if possible.

[waclawek.jan]

Which Nucleo? What code? What is the expected behaviour, and how do you know that "code won't run"?

> if I try to run it without connection to PC

Is the problem that the code does not start as expected after powerup? How are you powering the Nucleo?

Try with simple blinky. Still problem?

JW

[IPrin.1]

Thanks for getting back to me, and apologies for not including more information. I have created a new simple blinking LED project which behaves in the same way as my original project code, ie; requires a reset after power up to behave as expected. As such I assume it is an issue with the configuration of CubeIDE maybe?

I am using Nucleo-F746zGT6, I have attached a photo of my setup along with a zip of my simple project exported. I'm supplying <12V on Vin.

Cheers.

[IPrin.1]

..

[C. Mart]

Did you try building with the release configuration and not debug? I'm only guessing, but in debug it maybe waits for you to press "play" on the debugger which obviously won't happen if you're not connected to STM32CubeIDE via USB

[IPrin.1]

I have tried in both debug mode and release version but behaviour remains the same.

[waclawek.jan]

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_ETH_Init();
 MX_USART3_UART_Init();
 MX_USB_OTG_FS_PCD_Init();

This is not *simple*.

JW

[IPrin.1]

Having returned to work after a few days off site I have tried a number of boards to rule out a hardware issue. I have 4 boards, all the same format, all with the same boot loader code. 2 function as expected without needing a reset on power up, and 2 will not work until physically reset.

Has anybody any experience of this differing behaviour between apparently identical boards?

Thanks

[Ulysses HERNIOSUS]

Hi,

I would suspect an effect coming from the ST-Link not being properly powered/starting up. What is the setting of JP1? I would also experiment with closing SB107 or opening SB111 (Putting ST-Link into reset state / decoupling F7 reset from ST-Link).

BR, Ulysses

[IPrin.1]

Thanks for getting back to me.

JP1 is open

Manually closing briefly SB107 after power up makes the board function

Opening SB111 prevented the programmer from resetting the micro-controller.

Adding a short delay at the start of main() has fixed the startup issue so I will continue with this rather than modifying the boards.

Thanks to everyone who gave constructive responses, much appreciated.

Ian

[SAlvi.1]

Please, explain your solution, did you use HAL_Delay(), a for() ?, where exactly did you put it?, at the very beginning of main()? After HAL_Init()? At the startup file? . Please I'm having the same issue with 3 Nucleo 144 STM32F446ZE. Thank you for your time.

[Tesla DeLorean]

Suggest at the VERY BEGINNING, with simple delay

volatile int i = 100000000;

while(i--);

Not clear what or how this worked, the OP lacked specifics. So perhaps TRY some things, and see if you have the same problem or a different one.

[waclawek.jan]

> Adding a short delay at the start of main() has fixed the startup issue

How?

JW

[Piranha]

Answers are in my post in there:

https://community.st.com/s/question/0D53W00001t46n6SAA/stm32f767zi-on-external-power-supply-is-stuck-until-reset-button-is-pressed