STM32F769NI: UARTs do not connect in bootloader mode

[gps]

Hi,

I am asking for some sound technical help on the STM32F769NI Bootloader

I am using an STM32F769NI MCU and wish to update the firmware using STs' Bootloader mode via the UART.

I am running into problems that none of the UARTs on Pins PA9/PA10, PB10/PB11 and PC10/PC11 are working.

I switch the MCU to bootloader mode by connecting the BOOT0 pin to VDD and issuing a hardware reset via the reset pin.

Once the reset is complete, I put BOOT0 pin back to normal (pulled down to ground). (Even tried keeping it tied to VDD)

The MCU switches to the bootloader mode. I can confirm this because I do not see the LEDs blinking on PJ5 and PJ13 which did when in the app mode.

Now I use STM32CubeProgrammer to connect to the MCU via UART, selected COM port, various Baud Rates (default to 9600 or 115200, but I have tried all options from 1200 to 115200), Parity as Even

I see in the logs that a byte 0x7F is sent, but then it says no response from the target.

I even tried using the ST Flasher tool, but no luck there as well.

If I try to connect via USB, I can successfully upload the new firmware, but I want UART to function because the bootloader does not depend on external crystal when UART is used as opposed to USB.

I have spent quite a lot of time debugging most of the options, using all possible ST tools, reading AN2606 thoroughly, Verifying option bytes, Debugging UART ports and dongles to make sure they actually work.

Can someone provide me insight into why the UART is not working in the bootloader mode.

I even tried the same on our custom boards, STM32F769 Discovery and STM32F779 Eval, and none of them worked.

I even tried same tools and USB dongles with STM32F072RB Discovery, STM32F746ZG Nucleo and it works on those boards but not on STM32F769.

Thanks in advance.

[Tesla DeLorean]

>>Can someone provide me insight into why the UART is not working in the bootloader mode.

If there are signals on any of the interfaces it is watching it probably switches to those. It is a once-and-done thing.

Would need to tear into the loader code to understand what it is doing, or what might be happening.

[TDK]

> Once the reset is complete, I put BOOT0 pin back to normal (pulled down to ground).

> The MCU switches to the bootloader mode. I can confirm this because I do not see the LEDs blinking on PJ5 and PJ13 which did when in the app mode.

This is hardly proof the chip is in bootloader mode. It could also be in your program stuck in a loop somewhere. If BOOT0 was pulled down during reset, it's likely running user code. I suggest attaching a debugger to find out.

Edit: I think I misunderstood this. BOOT0 high, then reset, then BOOT0 low should put it in bootloader mode. Agreed.

As clive1 says, ensure no other devices are attached the any of the pins the bootloader checks. This includes USB, I2C, SPI, etc...

[gps]

As I said, USB interface is connected in the schematic and when I use the USB interface, I can see the MCU appear as STM32 Bootloader Device and I can successfully program the new firmware.

However, I want to use UART as they are more reliable because the bootloader does not calculate external crystal frequency in the case of UART. I have been facing a lot of issues with USB earlier with a 25MHz crystal where the MCU would not enter the bootloader mode reliably. 30% of the time it fails to even enumerate correctly.

I finally solved that problem by using an 8MHz crystal to lower the margin and errors while calculating the HSE frequency by the bootloader. This is even mentioned in the AN2606 with latest Rev43 released in June 2020.

Coming back to UART, as per TDKs' and Clive1's comment, what does it mean that no other devices should be attached to other interfaces.

If that means that other peripherals capable of bootloading should not be wired to anything in the schematic? That is ofcourse not possible as there will be lot of other components connected to the SPI, I2C or other UART instances in the design.

What I agree is that the other interfaces should not be driven while in bootloader mode. That also means, the lines should be pulled to a certain known logic level to avoid creating unknown sequence which the bootloader can misinterpret.

In my design, I am sure none of the other interfaces are activated when the bootloader is running. I do have USB interface hooked up, but if I remove the cable, it should not enumerate and should not be seen by bootloader as an available interface to listen to.

To my surprise, the issue exists on 3 different boards. A custom design, F769 Discovery and F779 Eval.

Can anyone guide me how to debug the bootloader? I assume it is not possible unless I have source code for the bootloader.

[gps]

Attaching portion of the schematic with USB connectivity and PA9/PA10 for UART being hardwired on board while testing.

DNI - Do Not Insert. R100 is not mounted on the board.