STM32G030K6T6 fails to respond to bootloader I2C, revised

[FrankNatoli]

Have STM32G030K6T6 system that in bootloader mode fails to respond to I2C.
Am asserting BOOT0 pin 25, negating NRST pin 6, wait 500ms, asserting NRST pin 6, wait three seconds, then attempt to send MCU erase packet to I2C1 device address 0x56 but get NACK
DSLogic Analyzer shows good I2C write to 0x56 but NACK in response, see attached screenshot.
Was originally writing to 0x57, which was correct for earlier implementation for STM32H7B3I, but TDK noted that the correct address for STM32G030K6T6 is 0x56, and that succeeded, i.e., erasing flash and writing flash, exactly once.
Second and all subsequent times attempted, 0x56 is NACK-ed.
Could original "success" have corrupted MCU bootloader code?

[FrankNatoli]

See attached screenshot.

[Tesla DeLorean]

Prior thread  https://community.st.com/t5/other-tools-mcu/stm32g030k6t6-fails-to-respond-to-bootloader-i2c/td-p/586647

>>Could original "success" have corrupted MCU bootloader code?

No, but depending on how the device boots and the state of the Flash, it could try to execute your code rather than the loader. Erase the user firmware, and see if the original behaviour returns after a power cycle.

[FrankNatoli]

"Erase the user firmware, and see if the original behaviour returns after a power cycle."
I don't think that's possible.
The board with the STM32G030K6T6 does not have a J-tag or STM programming connectors.
The only way to erase/program the user firmware is via MCU bootloader, which appears non-functional after one time success.
Have revised the master code to repeat attempts to write to 0x56, but every attempt is NACK-ed and throws HAL_I2C_ErrorCallback.

[TDK]

Only possibility I can see is if your user code changed option bytes to ignore the BOOT0 pin.

Otherwise, system bootloader is in ROM, can't change that, and the startup sequence is similarly hard coded.

[Tesla DeLorean]

>>The board with the STM32G030K6T6 does not have a J-tag or STM programming connectors.

That sounds like that will be a joy to work with/on. Could you have not had something out the side of the board or as a break-off piece?

[FrankNatoli]

The EE quit.
The EE's boss is now doing the EE.
He told me he may be able to jury rig a J-tag connection.
Background:
The mother board has two STM32H7B3I, a MAIN and a FrontPanelController [slave via I2C].
The code I wrote for MAIN can reliably burn the FPC flash via I2C, programmatically controlling the FPC reset and bootloader inputs.
Once in a while, I screw something up, have IAR/Segger running on FPC when starting a boot sequence from MAIN, and that makes FPC very unhappy.
I can no longer get FPC to accept I2C bootloader until I use the FPC J-tag to rewrite the flash, then all OK again.
Thus, it seems the STM32H7B3I can get into a confused state where I2C bootloader is non-functional.
With the FPC J-tag, I could always "fix" the problem.
With the STM32G030K6T6, no J-tag, I cannot "fix" the problem, and thus am stuck [until the EE manager gives me a J-tag].
Does anyone else have any experience with an STM32xxx getting into I2C bootloader confusion?
And how does J-tag rewrite the MCU firmware flash [presumably not via I2C bootloader]?

[TDK]

> Thus, it seems the STM32H7B3I can get into a confused state where I2C bootloader is non-functional.

The OP is about the STM32G030K6T6. Is this happening on your STM32H7B3I as well? (But recoverable via SWD/JTAG?) Seems like something more fundamental is happening here.

Perhaps something else is talking to the STM32 on bootloader pins. The bootloader will respond to the first peripheral that sends a signal, whether that be UART, I2C, SPI, USB, etc.

JTAG and SWD write the flash in the same manner, but are able to "steal focus" from whatever else is running.

> The EE quit.
> The EE's boss is now doing the EE.

Hilarious. Sounds like you're doing the EE now, though.

[Tesla DeLorean]

The JTAG/SWD is an extension of the classic scan-chain methods, ie daisy chain of secondary port on flip-flops throughout the design to shift in/out content during test. On the ARM core this facilitates access to the registers and run-state, you can basically make the core run code, or load/store on memory. The tools move flashing code, and data into RAM, execute it to write content to Flash memory.

[FrankNatoli]

"Is this happening on your STM32H7B3I as well? (But recoverable via SWD/JTAG?)"
Yes, but only when I botch something, e.g., leave Segger running on the secondary STM32H7B3I then simultaneously try to reboot the MCU and send bootloader messages.
"Perhaps something else is talking to the STM32 on bootloader pins."
That is a reasonable suspicion, but I have a DSL logic analyzer on the I2C1 clock and data going into the STM32G030K6T6 and it clearly shows only the I2C data from the master STM32H7B3I.