NUCLEO64 NRST not enough for entering bootloader, only power cycle!

[BAlve]

Hi, I could not find anywhere some issue similar to mine. Neither something on the documentation that explains this....

I have an application that it is supposed to load the firmware to the uC, using USART. I can signal via software the BOOT0 and NRST pins, but at this point, I have phisically connected BOOT0 to VDD. And then i press the RESET button.

I can verify that the uC did not boot on normal operation, so I would expect it booted in Bootloader. However, when I send the 0x7F byte to the uC I don't get any response.

Everything works as expected though, if instead of pressing the RESET button, I physically remove the USB cable and plug it again (USB is used only for power).

[waclawek.jan]

Do you have something connected to NRST?

JW

[gregstm]

Sounds a bit similar to the problem I had (and still have) with the STM32L433 chip. I download a program via the Bootloader, but a reset won't start the downloaded program - I have to cycle the power. I asked the question several years ago - https://community.st.com/s/question/0D50X00009XkbIQSAZ/stm32l433-boot0-pin-state-ignored-after-loading-program

[BAlve]

Sorry for the late reply, I had to continue development on the firmware itself, now I'm getting back to the flashing issue.... No, there wasn't anything connected to the NRST pin, I have connected an osciloscope to verify the level of the pin, but everything appears to be fine...

The weird thing is that it does not boot on normal operation, neither boots on bootloader...

[Tesla DeLorean]

I think the L4 is one of those parts that boots into the ROM and then it transfers control. And the option bytes get read from memory on power up, and not reset. Presumably to fend off glitching attacks.

The system loader is also going to be sensitive to noise on any of the interfaces it is waiting for interaction on, see AN2606, it connects TIM to the USART RX pins to measure the 0x7F pattern, so if you have a GPS receiver or whatever start churning out data independent of the BOOT0 pin being HIGH, the loader could well assume the GPS USART RX is the one you're trying to talk on.

As the Knight says, pick wisely...

[Uwe Bonnes]

Is evt BOOT0 remapped via the option bits?

[BAlve]

I don't think the NUCLEO-F103RB has this possibility... at least I could not find it on PM0075

[BAlve]

The only other thing I have connected to the board is another UART interface (3), but even when I disconnect it, the problem continues....

[Tesla DeLorean]

I haven't dissected the board design, if you trap the condition in the debugger you can perhaps inspect where and what the ROM code is doing.

The ST-LINK VCP presumably connects to the chip.

[marbel]

Hi

I have also run into this and I am getting really confused here.

I have one STM32G4 hold the reset, Boo0 and the USART2 pins of a second STM32G4 and the only way for me to be able to get the first MCU to force the second into bootloader mode. The only thing that appear to make this happen is to apply power to the second MCU. After that the first mcu, if rebooted. cannot change the boot mode of the second even tough it holds the control for both boot0 and nrst.

The ref manual states:

The values on both BOOT0 pin (coming from the pin or the option bit) and nBOOT1 bit are
latched on the 4th edge of the internal startup clock source after reset release. It is up to the
user to set nBOOT1 and BOOT0 to select the required boot mode

Now that does not appear to be true. Or it atleast should be clairified to "after poweron/coldboot reset release"

// Martin