Extra Ack in STM32G0 I2C ST bootloader response

[siddheshnaik]

We are testing the STM32G0 native ROM bootloader over I2C using the Get Memory Checksum command (0xA1 / 0x5E).

According to the protocol described in the ST AN4221 application note, after sending the memory address and size, the bootloader should return an ACK if they are valid. The CRC calculation then starts, during which the bootloader may return BUSY (0x76). Once the calculation is complete, the bootloader should directly return the 4-byte CRC result followed by its checksum.

However, in our implementation, after the size ACK and waiting for the CRC computation, we are observing an additional ACK (0x79) before the CRC result.

Our current sequence is:

Command → ACK → Address → ACK → Size → ACK → CRC calculation → ACK → CRC result

Based on the sequence described in AN4221, we expected:

Command → ACK → Address → ACK → Size → ACK → CRC calculation/BUSY → CRC result

Could you please confirm whether this additional ACK (0x79) after the CRC computation is expected behavior of the STM32G0 ROM bootloader, or whether our I2C read/transaction sequence needs to be handled differently?

A screenshot of the relevant section from the official ST AN4221 application note is attached for reference.

[mƎALLEm]

Hello ​@siddheshnaik and welcome to the ST community,

I’ll escalate your case internally for analysis. It may take a while to have an answer/feedback.

Internal ticket for follow-up CDM0066377 (not accessible by the community users).

[siddheshnaik]

Hello ​@mƎALLEm 

I kindly request you to escalate this matter and provide me with an update at the earliest possible convenience.

I appreciate your efforts and support. Thank you!

[mƎALLEm]

Ok but this may take a while to have an answer as there are plainly of customers per day to handle per day. So please don’t be pushy.

Meanwhile you didn't provide the exact part number you are using. Could be provide it?

Thank you for your understanding.