Critical problem with I2C and DMA on the latest STM32U5

[TDJ]

I experience a strange problem with I2C, DMA and the latest STM32U575ZI-Q, not seen on L4 and H7 MCUs.
After a successful data transfer from SMBus target (slave) to controller (host) the last PEC byte stays in RXDR registry. On the next transfer in the same direction this last PEC byte is read by DMA and placed in the allocated memory buffer as the first received byte. Interestingly, I2C interface does not seem to use this byte calculating PEC CRC so PEC error is not triggered at the end of the second transfer, just bytes in the receive buffer are offset by one. Explicitly reading RXDR register before transfer does not help. This may be a show stopper. I found no workaround and this problem may practically prevent the use of SMBus with DMA on STM32U5.

I have not seen this problem on other MPUs, however, they have other I2C issues I have described recently - see: 

Missing STOP condition problem

I2C, Incorrect PEC byte value after RESTART condition - hardware bug suspected

I2C master jams, unable to clear STOPF flag - probable hardware bug

Probably there is a good reason why CubeMX does not allow for SMBus configuration with DMA.

[Foued_KH]

Hello @TDJ 

The SMBus protocol requires that data transfers be initiated by the master device and that each transfer be followed by an acknowledge signal from the slave device. This means that the timing of the data transfer is critical and any delay or interruption could cause the transfer to fail.

DMA transfers, on the other hand, are initiated by the DMA controller and do not involve the CPU. This means that the timing of the transfer is not under the control of the I2C master device, which could cause issues with the SMBus protocol.

Foued

[TDJ]

@Foued_KH SMBus requires clock stretching enabled so unless TIMEOUT A or B is enabled as well, there is no risk of timeout. When I2C RX is configured for DMA, transfer is initiated by I2C, not DMA because bytes are first received by I2C as they arrive and only then are transferred by DMA to a memory buffer, not the other way around, as your response may suggest. For more details please refer to document RM0456, section 65.4.17 and SMBus 3.2 specification, appendix B.2.

Here is more info. As the first byte GPDMA reads the last PEC byte received during the previous transfer before I2C CR2.START bit is set. I observe this problem on new STM32U575ZI-Q MCU only.

printf(i2c_pe->RXDR); // read RXDR during RXNE event and before DMA start
memset(buffer, 0, byteCount); // clear buffer
HAL_DMA_Start_IT(dma_rx, (uint32_t)&i2c_pe->RXDR, (uint32_t)buffer, byteCount);
printf(buffer[0]); // read buffer, buffer already contains non-zero value present in RXDR!
SET_BIT(i2c_pe->CR2, I2C_CR2_START);  // set start bit

Thank you for your willingness to help. I am well aware that probably 90% questions posted here just require basics explained, but this is not such case. This is probably level 3 support question. Please escalate since everything suggest that the problem described is caused by a hardware bug not found in other modern STM32 MCUs. I am willing to provide ST with full repro, but not publicly here since the source code is highly proprietary.

Please remove the other duplicate post and add "I2C" tag to this one.

[Diane POMABIA]

Hello @TDJ 

Can we go private? I need more details before I open the internal ticket.

Regards

Diane

[TDJ · Accepted solution]

@Diane POMABIA I managed to solve this problem. I2C on STM32U5 seems to be revised and there is at least one subtle differences. This was not documented, but previously I2C with DMA could receive a message without the trailing PEC byte. If data length specified during HAL_DMA_Start_IT() did not include PEC, RXNE event fired, in ISR RXDR register could be read and everything was fine. On STM32U5, when DMA is enabled, all the bytes, including PEC, must be transferred by DMA, which is actually consistent with RM0456, section 37.4.17 which states:
"Only the data (including PEC) are transferred with DMA".