STM32Cube programmer / ST Flash work with the default UART2 on the USB/ST-Link of the L053 Nucleo but not on actual UART pins

[AVals.1]

I am trying to flash a STM32L053 Nucleo using UART pins and so far,

I pull boot 0 high by adding a jumper across boot 0 and VDD

I power the controller with E5V optin and connecting an external poer supply to the E5v and GND

If I connect the USB to the Nucleo, both the STFlash utility and STM32Cube programmer (I select UART) work fine with the COM port associated with the USB to the default USB port of the Nucleo.

But when I connect them through an FTDI to the UART pins (I have tried both PA9, Pa10 (UART1) for tx, rx and PA2 and PA3 (UART2) for tx, rx along with GND), neither the STFlash or STM32Cube Programmer work (they get no response and timeout).

I have checked the FTDI and UART pins on a general program that receives and prints on UART ports (both UART1 and UART2) on a main program and they work complete;y fine and receive and print data.

So the boot configuration seems correct as it works fine witht the USB connected UART2

and the UART connections through FTDI seem fine as well,

But I end up getting a timeout error and am asked to check the boot configurations and the UART configurations if I try to do both at the same time,

I am very confused, could somebody explain me a solution?

[Tesla DeLorean]

>>I am very confused,

Yeah, and its critical you're able to do this why?

ST-LINK works differently, doesn't use the loader

The ROM based System Loader is VERY sensitive to any noise on ANY of the interface pins it's looking at for signs of signals. If you get any noise/glitching you'd need to reset the STM32 to try again, it's a once and done thing, if it sees signals it can compute into a baud rate, that's what it's using.

You'll need to go over the schematic carefully to see if anything unhelpful is wired or conflicting with the pins you're trying to use, and those the loader is monitoring.

Can you perhaps use a simpler breakout board for this experiment?

You can improve your chances, by reducing the detection window, this would occur by the tool driving the reset via a control pin, and then immediately pushing the 0x7E 8E1 pattern.

[AVals.1]

Thanks for the reply.

I need this to prototype for multiple boards.

As I mentioned I tried using the UART that is on the USB that also serves as connection for ST-Link.

I DID NOT USE THE ST-LINK BUT THE UART OPTION on the come port that has the ST_LINK connection, and it still is working fine.

This happens also on a completely fresh NUcleo whcih has nothing else connected to it except for the E5V power supply, boot 0 pulled high and rx, tx and GND connected via the ftdi.

The boot sequence gives first priority to UART and I have tried the FTDI with both UART1 and UART2 (the default) pins on a Nucleo that is only connected to the UART and boot 0 pin pulled high as well and the result is the same.

[MM..1]

Try cmd line and show result here replace your FTDI COM

STM32_Programmer_CLI.exe -c port=COM3 br=57600 P=EVEN db=8 sb=1 ...

[AVals.1]

Thanks for the reply,

This is what I got as output

> .\STM32_Programmer_CLI.exe -c port=COM8 br=57600 P=EVEN db=8 sb=1 ...                                                                                                -------------------------------------------------------------------                                                                     STM32CubeProgrammer v2.10.0                                                                           -------------------------------------------------------------------                                                                                                                                                                      Serial Port COM8 is successfully opened.                                                                               Port configuration: parity = even, baudrate = 57600, data-bit = 8,                                                                          stop-bit = 1.0, flow-control = off                                                                                                                                                                                        Timeout error occured while waiting for acknowledgement.                                                                                                                                                                                       Timeout error occured while waiting for acknowledgement.                                                               Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...