I was attempting a STM32 firmware update over the I2C interface using some other host MCU. For this, I used the NUCLEO-G071RB; so I referred to the ST's AN4221 and implemented their firmware update flow.
I configured the option bytes using STM32CubeProgrammer so that the STM32 bootloader can be accessed using the BOOT0 pin instead. I had already implemented their UART firmware update flow and I had got it working without any issues. But now our product needs to perform the firmware over I2C instead. So I made the necessary changes so that the host MCU uses the I2C interface instead of UART to communicate with the STM32 bootloader.
As mentioned in their AN2606, I used 0x51 as the slave address for STM32G071RB bootloader. Also instead of using their old UART commands, I switched to their I2C No-Stretch commands (so as to avoid clock stretching while communicating via I2C). I was able to successfully communicate with the STM32 bootloader. I sent the "Get ID" (0x02) command to the bootloader and I received an ACK and was also to fetch the Chip ID (0x460).
Now coming to the issue:
Once I was able to fetch the Chip ID, I sent the "No-Stretch Readout Unprotect" (0x93) command and I received the ACK byte (0x79) for that command. Now I waited for the 2nd ACK (which would be received once the STM32 disables the readout protection and performs mass erase on the entire flash memory).
dfu_status_e wait_for_response (void)
{
uint8_t rcvd_data = BUSY;
while (rcvd_data == BUSY)
{
receive_data(&rcvd_data, 1);
}
if (rcvd_data == ACK)
{
return DFU_OK;
}
else if (rcvd_data == NACK)
{
return DFU_NACK;
}
else
{
return DFU_UNKNOWN;
}
}So I kept polling until I was receiving the BUSY byte (0x76) and waited for the ACK (0x79). But I never received the ACK, the MCU kept receiving the BUSY byte atleast for 40 seconds while in the STM32G071RB datasheet the mass erase time is mentioned to be just 40.1 ms.
So I tried communicating with STM32G071RB using STM32CubeProgrammer (over ST-LINK) but it started throwing this Error: No STM32 target found. I then checked the FAIL.TXT file, it said "The interface firmware FAILED to reset/halt the target MCU". I suspected that the STM32's user application might be corrupted and that might be blocking the ST-LINK SWD pins so I configured the STM32CubeProgrammer (changed the Mode from Normal to Under Reset) so that it can initiate the communication with the STM32 MCU just after it has come out of reset but that didn't work either. It returned the same Error: No STM32 target found. I tried the same thing by manually resetting the MCU as well as forcing the MCU into the system memory (bootloader) whenever it comes out of reset (by tieing the BOOT0 pin high) but even that didn't work. I also tried using the UART interface but none of the things worked.
I found this under the Flash option byte programming section (in STM32G0x1 reference manual). Could it be that I might've corrupted the option bytes, since I was trying to write the RDP bits in the option bytes (by issuing the Readout Unprotect command through the bootloader).
It says that it erases the user option bytes and rewrites it in the next cycle by fetching the previous values from the option registers along with the option change that the user requested. So is it possible that I might've bricked the device by resetting the MCU while it was performing the mass erase and also changing the RDP option (although I waited for atleast 40s before doing so) or is the MCU damaged because of some other reasons? Also if such a scenario can permanently brick the device, then how should we handle this case in production where one can't be sure about power outage during the firmware update?
