Critical issue with I2C and DMA on new 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.

Sorry for duplicate post, it does not seem to be possible to remove the other one with incorrect labels.

[TDJ]

Here is more info. GPDMA reads byte from the previous transfer before I2C CR2.START bit is set. I observe this problem on the new STM32U5 MCU only.

printf(i2c_pe->RXDR); // read RXDR
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 the value present in RXDR!
SET_BIT(i2c_pe->CR2, I2C_CR2_START);  // set start bit

[TDJ · Accepted solution]

See the solution here: Solved: Re: Critical problem with I2C and DMA on the lates... - STMicroelectronics Community