STM32CubeProgramer not connecting to STM32G491CEU6

[BGheb.1]

I'm trying to program a STM32G491CEU6 by using BOOT0 and NRST but I'm not able to connect unless I power cycle the MCU while BOOT0 is pulled HIGH. What I'm trying to achieve is:

Provide Power

Set BOOT0 pin HIGH

Pulse the nRST pin LOW

Program MCU

What is causing the connectivity issue? Is it a matter of timing issue or is it my FLASH_OPTRs not configured correctly unless the MCU is power cycled.

Below is my nRST pulse

[TDK · Accepted solution]

If you reconfigure SWD pins, the programmer can't connect unless it's under reset. Also, if the chip resets very quickly after turn-on due to user code the programmer will also have trouble.

[BGheb.1]

Hi TDK, thank you for the response.

The MCU is reset by another MCU so that pulse comes after the MCU is fully on and the feature is there so it can be programmed while the system is powered. I also have the option of holding the nRST pin LOW.

My SWD pins are configured as GPIOs, but how come I'm able to connect after power cycling? I've also tried to connect while the MCU is under reset and I had no luck. Here is what I tried

1. Provide Power
2. Set BOOT0 pin HIGH
3. Set nRST pin LOW
4. Connect (failed)

1. Provide Power
2. Set nRST pin LOW
3. Set BOOT0 pin HIGH
4. Connect (failed)

Is there something that has to be configured in software that allows me to connect to the MCU under reset? Thanks for the help!

[TDK]

NRST shouldn't be held low. If the programmer has access to the NRST pin, you can select mode "under reset". Otherwise, you can click connect, release the NRST pin manually, and it will connect. Or just boot to system memory mode and connect that way.

[BGheb.1]

Hi TDK I finally managed to figure out the issue that was preventing my MCU from connecting.

In my circuit, PA12 was floating when I was trying to connect and for some reason, the MCU did not like that. I was able to enter the bootloader after adding a pull up on the pin.

On the bootloader app note AN2606

"It is recommended to keep the RX pins of unused bootloader interfaces (USART_RX, SPI_MOSI, CAN_RX and USB D+/D- lines if present) at a known (low or high) level at the startup of the bootloader (detection phase). Leaving these pins floating during the detection phase might lead to activating unused interfaces."

Thank you for the help!