I'm using 'SDK_25_06_00_MIMXRT1060-EVKC' to develop an I2C device read/write operation.
I found the code in LPI2C_MasterTransferEDMA(), when commandCount != 0, a TCD for sending commands needs to be constructed. The following code snippet is used:
uint32_t maxTxFifo = (handle->base->PARAM & LPI2C_PARAM_MTXFIFO_MASK) >> LPI2C_PARAM_MTXFIFO_SHIFT;
uint32_t minCommandCount = MIN(commandCount, maxTxFifo);
According to the application manual, the FIFO size is 2^MRXFIFO. The calculation of maxTxFifo is inaccurate.
After digging into the SDK source code, it was found that when using I2C + eDMA to read from a peripheral, three linked TCDs are used. The first one is for sending commands, but the process is somewhat overly complex:
- First, the number of FIFOs is determined (for RT1061, the size is 4, which is the method used in the step above, and the calculation is also incorrect)
- Data of FIFO size is sent via DMA
- Any remaining data beyond the FIFO size is supplemented into the I2C transmit data FIFO one by one using I2C interrupts
- After the command DMA transfer is completed, the DMA hardware immediately loads the second TCD to transmit to base->MDER, allowing the DMA to switch to receive mode. At this time, there is a few amount of data inside the transmit FIFO waiting for transmitted to the I2C bus
- The third TCD (for actual data reception) is automatically loaded and starts waiting for the I2C module to receive data. At this time, there is a few amount of data inside the transmit FIFO
- ...
I modified the code in `LPI2C_MasterTransferEDMA()` to eliminate the method of using the I2C module interrupts to supplement data. Instead, all command data is sent entirely via DMA. Even if the command length exceeds the FIFO size, it is still fully possible to achieve a complete "one-shot" DMA read from the peripheral.
If the method of using I2C interrupts to supplement data is employed, the command portion doesn’t actually require DMA. It would be better to manually fill the FIFO and then activate the I2C TxReady interrupt. This part of the operation seems somewhat like using DMA just for the sake of using DMA.
Hi @phantomgz ,
Thanks for your sharing!
This does appear to be an SDK bug. I've reported it to our internal team for verification. Thanks again!
Best regards,
Gavin