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).

[Tesla DeLorean]

Problem generally here is that ST has started to differentiate between a power cycle and a pin level reset, and you have an ST-LINK which might interject or interfere with the boot loaders choice of interface.

S​ome parts appear to need 2x 0x7F data bytes. Would suggest engaging with a local FAE

[marbel]

Hi and thanks for the comment

I don't think that the part needs a double 0x7F sequence. I have captured the communication with a logic analyzer when it does work and an answer of 0x79 is produced right after the first 0x7F.

One cant help but wonder what is being done by the MCU in this state were it is not running from flash or SRAM and apparently is not entering the bootloader correctly.

[Sebastiaan]

Hi @marbel​ , @BAlve​ ,

I have a very similar issue with STM32G474 (which I'm trying to upgrade via a STM32F413), both nucleo boards.

I've tried both USART1 and SPI1 as programming interface. It seems to me like:

• STM32F4 (the host) cannot sufficiently/properly control the BOOT0 pin, in fact I'm manually attaching boot0 to 3V3 or GND on the target nucleo board to ensure correct entry
• Even if a first upload went fine (the rest of the upgrade process is all working fine), whatever I try, I can never get a second upload to work, except for when I power cycle the target nucleo board. The second upload always fails on just getting the sync pattern.

Did you make any progress or find a root cause?

It's clear to me that the target at least does not enter application mode when boot0 is high, but on the other hand it seems like it's either booting from SRAM, or it has seen some activity on another interface apart from the used USART1 / SPI1. And it's hard to conclude on what the source could be.

Best regards,

Sebastiaan