2021-09-21 10:21 AM
Hello community,
I face the following problem on my NUCLEO F746ZG board :
I want to power up my nucleo from an external source for my application, I have done as the Nucleo-144 manual suggests:
Now The application does not start unless I press the reset button on the board, so if I power the board up, the microcontroller does not even turn on an user LED unless I also press the RST button.
The firmware runs fine without having to press the reset button only if I power up the usb port of the ST-Link (no debugging needed, just a powered usb)
I have tried to pull up the reset pin on the SWDIO connector and this solution works but not always, depends on the firmware it seems, if I have a bootloader or the boot address is modified it does not work!
Has anybody experienced this kind of behavior? Is there a workaround?
Matteo
Solved! Go to Solution.
2021-09-21 10:54 AM
Try a newer version of the ST-LINK firmware, or disconnect the ST-LINK driven NRST from the F7, should be a solder-bridge or zero-ohm you can remove.
2021-09-21 10:54 AM
Try a newer version of the ST-LINK firmware, or disconnect the ST-LINK driven NRST from the F7, should be a solder-bridge or zero-ohm you can remove.
2021-09-22 02:31 PM
Thank you, your suggestion works better than pulling up the RST, a jumper was installed on that solder bridge, but ultimately I had to add also a 1s delay before peripheral initialization to make everything run fine all the time!
2022-10-06 06:54 AM
Hello,
I have the same problem. If I understood correctlu I should remove the 0 Ohm resistor from SB111 (NRST-RST bridge). When I do that the power supply current limit of 300 mA geth hit and I wonder if the board really needs more current or I've done something wrong?
Thank you!
2023-11-21 07:45 AM
I nearly in the same case, but with F439ZI.
I have more than 20x nucleo-F439ZI set with E5V, No JP1 with the same identical program.
On an average of 1 board out of 3, I have the behavior explained above. (and not for the others). I first try with different firmware of STLINK and compare results. The 33M25 works fine, the 39M25 does not work at all, the 40M27 (last one at this mail writing is not predictable. It works from time to time)
If i press the reset button or use the stlink debugger, all work fine. If i do not press, the board seems to boot as some leds react as the program said, but the UART6 refuse to receive data.
2023-11-21 09:30 AM
The NUCLEO's ST-LINK provides an HSE clock, make sure your code isn't dependent on that if the ST-LINK is not powered. See MCO / SB112
Remove the SWDIO/SWCLK connectivity via CN4 jumpers.
In your problematic case, check what NRST is doing. If the ST-LINK (unpowered) is interfering with this check NRST / SB111
Instrument Hard Fault and Error Handler subroutines, or any where your code dies silently in a while(1). Do so in a way that lets you understand if it gets stuck in those, and why.
2023-11-22 03:53 AM
First thank you M.Guru DeLorean, you put me in the right track.
As you mentioned, the HSE is generated by the STLINK.
My code is dependent of HSE but the STLINK is supplied by E5V through U3, so it is supplied anyway and should generate the clock. For testing, i switch the code to HSI and it works. So i confirm that it is a clock sequencing problem.
Nevertheless i made some tests to dig a bit more without modifying any SB straps (factory default board)
I supplied the board only by E5V and made two separated tests:
1) I maintain the reset button while powering on, then release it after two second, the main processor does not work well from time to time. This mean that we need a sequencing startup for the boot up to be reliable.
2) I let the system boot up, then press reset button, It works every time. The reset button is directly resetting the main proc but is only an information for the STlink. With point 1, it means for me that the problem is power sequencing between STLINK and the main proc. The STLink shall start first, then the processor.
I concentrate on the power sequencing in an hardware point of view, and I asked myself why it is working in debug mode and not while the using only E5V with this sequencing in mind.
Powered from E5V only, I notice two power paths from E5V that run in parallel (Through U6 = main proc, and through U3 = stlink), so both stlink, and main processor start at the same time.
Powered from USB (=power by U5V), i notice the same two paths but with one huge addition. The U4 component (ST890CDR) which will turned on the power by applying U5V to U6 path) for the main processor on STLINK command. So, this mean that the power is sequenced. (First the Stlink will boot up, then when stlink will command the power on the main processor (U4.3 pin) then the processor will start).
Conclusion:
On E5V supplied only, both processors start at the same time. So depending on power supplied rise time, bulk capacitor tolerances, both processors may not start in the same order. And so HSE clock may not be generated properly for the main processor. This is a board design mistake. For board next revision, i would suggest ST to move U4 between JP3 and U6, and a jumper on U4.3 to ground in case STlink is not used. Like this the sequencing will be always good whatever the input (U5V or E5V or even Vin).
For user who have the same problem, and do not want to loose the possibility to use Stlink when ever it pleases, i suggest to switch on HSI, or supplied the board through the USB STlink port (and not E5V), or mount an HSE crystal as mentioned inside the board manual.
Regards
Elmout