Troubleshoot Connecting STM32G031F6P6 through UART in STM32CubeProgrammer

[SKues.1]

I'm trying to load firmware through UART (not SWD/ST-Link) to my STM32G031F6P6 prototype board using STM32CubeProgrammer but can't get it to work (although it works fine through SWD and STM32CubeIDE). Note: BOOT0 and SWDCLK are shared on the same Pin 19 (PA14/15) for this MCU. Am using RS422/485 transceiver (ADM3485EARZ) to go between PC USB/RS4222 (DTECH USB 2.0 to RS422/485 dongle) and MCU UART1. Have verified that serial transceiver works properly after firmware is properly loaded through SWD. Per AN2606 Section 41.1, I tried 2nd Option (nBOOT_SEL is NOT checked, nBOOT1 is checked, and nBOOT0 is checked - set previously using SWD) of Pattern 11 by tying Boot Pin high (VDD), pressing reset, hitting connect on STM32CubeProgrammer v2.10.0, releasing reset. Get "Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again…". Have tried variations over many months and am stumped. How do I know STM32CubeProgrammer is sending 0x7F per AN2606? Does it matter what bootloader version is loaded? How do I find that out? When I connect successfully using ST-Link in STM32Programmer the "Bootloader Version" in the lower right "Target information" section is "-". But AN2606 indicates only v5.3 should work on my 20pin device. Advice appreciated.

Screenshot of User Configuration using ST-Link

Screenshot when trying to connect through UART

[Tesla DeLorean]

Any other pins mentioned in AN2606 active in your design? ie a GPS Receiver that starts chirping at power up?​

[SKues.1]

Actually, yes. I'm using the MCU to monitor and control a power system and it has a lot of A/D inputs to sense current and voltage. USART1 is configured for RX/TX but USART2 (PA2/Pin 9 & PA3/Pin 10) is not used for comm but used instead to sense a voltage and a current. Under normal reset, the voltage on PA2 will be max value (on/full range) and the current sense voltage on PA3 will be minimum value (off/no current). I thought that during boot it would look at USART1 first then USART2. If USART1 had a valid response, then it would ignore USART2. Looking at AN2606 more closely, Fig 52 (below) indicates it looks at USARTx. Which could mean a variety of things. Also, I assume that the I2C pins don't matter as they aren't looked at until after USARTx. They also are being used to sense other signals. Even though I'm pin limited and will eventually need to use the USART2 pins for A/D, I'd like to troubleshoot for future revisions. Do the USART2 pins need to be pulled low (white wire) or can they float (e.g. can I cut their traces)? Thanks.

[Tesla DeLorean]

The main consideration is activity on the UART-RX pins that the device might be monitoring for connectivity. The 0x7F data pattern is not received by a UART, but the bit timing is measured with a TIM to establish a baud rate. Signals on watched UART-RX pins will therefore be problematic as the first contact will establish which the user intends to connect on.

[SKues.1]

Thanks. I've gone back and tested on an older hardware version that has USART2 TX & RX unused (tied to ground) and get similar behavior. My USB dongle appears to indicate there is both a transmit and receive as both RX & TX light up several times before I get the timeout notification from STM32CubeProgrammer. I tried the older "flash_loader_demo_v2.8.0" as well. Whereas before it just timed out, now it quickly responds and says the target hardware is not recognized. Which makes me think I have the physical layer working and its just something to do with proper bootloader config or protocol. Next step is to scope the signals but at best it will confirm that bits are being transmitted. Not sure how to troubleshoot the bootloader and STM32CubeProgrammer at the protocol level. Do most people never re-program firmware in the field and just use ST-Link/SWD in the factory? ST-Link/SWD signals get corrupted and performance degrades with long cable runs (>30cm). RS-422 is more dependable. Or do they write their own bootloader?

[SKues.1]

Follow-up. I have repeated testing with NUCLEO-G071RB with similar results. I can get the target MCU to boot from Flash but STM32CubeProgrammer times out when I try to connect over UART. I check whether I'm booting from Flash or system by loading simple Blink routine. If I press and release NRST and it blinks then I booted from system, if I press and release and it is not blinking it (likely) booted from Flash. Still stumped on why STM32CubeProgrammer will not connect. I suspect it has something to do with PA2's dual BOOT0 and SWCLK functionality. This appears common to all the SMT2G0 (M0+?). It appears that it has caused problems/confusion for others trying to use ST-LINK/SWD. I can get ST-LINK/SWD working but need to load over USART and cannot find any cases in the community of having issues or resolving this.

[SKues.1 · Accepted solution]

Fixed. Got connection between STM32CubeProgrammer and NUCLEO-G071RB using UART. Used FTDI USB/Serial converter with FTDI power set to 5V (vs 3V3) and FTDI VCC connected to NUCLEO 5V (CN7 6). FTDI Gnd connected to NUCLEO Gnd (CN7 8). FTDI TX connected to NUCLEO USART2_RX (PA3, CN10 3). FTDI RX connected to NUCLEO USART2_TX (PA2, CN10 34). Jumper between Boot0 (CN7 7) and Grnd (CN7 9) on NUCLEO to place board in reset. Pulled all USART1 (CN10 12, 14, 35, & 37) on NUCLEO to ground. Option Bytes- (preset with ST-LINK) nBOOT_SEL = UNCHECKED, nBOOT1 = CHECKED, & nBOOT0 = CHECKED.

Not sure why USART2 worked but not USART1. Nucleo User Manual (UM2324) didn't help as Figure 16 Note indicates USART1 is PC4/PC5 (what I was using previously) and Figure 19 note indicates USART1 is PA2/PA3 (although Table 8, Table 13, and Figure 21 indicate it is USART2).

[SKues.1]

Per section 3.5 Boot Modes of the STM32G071 datasheet, "The boot loader is located in System memory. It manages the Flash memory reprogramming through USART on pins PA9/PA10, PC10/PC11 or PA2/PA3..." This is why it worked with PA2/PA3 (USART2) and not with PC4/PC5 (USART1). Was able to get USART1 working using PA9/10 as well as USART3/4 using PC10/11 as described in the datasheet.