[iMX8X] lpi2c Sometime loose a byte when the RXFIFO is full

[ykrons]

Hello,

I'm working with a Toradex iMX8DX Colibri board and I have recently done some improvements to the lpi2c i2c driver.

Initially, the driver only supports reading frames smaller than 256 bytes and I have modified the driver to support any length.

The driver is working pretty well but it appears that sometime it is missing one byte.

All the bytes are properly handled at lower level: I can see good signal quality and the last byte of a frame is properly signaled with a NACK.

The RX FIFO size is of 16 words and the driver set RXWATER to 8 to avoid filling the FIFO. But in rare case, it seems there is a delay before the interrupt routine is triggered and when the driver read data, the FIFO is full. Usually data are read properly, but sometime one byte is missing between the chunk read from the full FIFO and the chunk read during the next interrupt.

As long as the frames are smaller than 256 bytes (only one read command written in the TX FIFO), no error is detected. It only appears for bigger frames (two or more read command written in the TX FIFO).

My questions:

* Is there know cases where one byte can not reach the RXFIFO? I'm expecting that the i2c bus is stalled when the FIFO is full according to Reference Manual and so no data lost.

* Is there know issue with the lpi2c module that can explain this behavior?

Find attached my patch of the current driver version.

Kind regards

[Dhruvit]

Hi @ykrons,

There is no known error of lpi2c as you mentioned.

Could you please provide me with more information related to the issue?

• Is there any particular case/scenario in which, you are facing this one-byte-related error?
• Could you please confirm if that 1 byte that is missing is lost or if you are receiving that byte in the next data transfer?

Thank you.
Best Regards,
Dhruvit.

[ykrons]

Hi @Dhruvit ,

To reproduce the error, I'm reading in loop a big i2c command response.

The read frame size is of 2069 bytes, split in chunk of 256 bytes.

The occurrence rate is maybe 1/10000 but can vary. I have not identified what can increase or reduce it.

About the missing byte, it is lost. There are other bytes in the FIFO but not the one just after the previous data when the next ISR is triggered 

For example:

If I spy the i2c bus I can see "0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20" (all bytes are there)

and in parallel in the driver I have::

* Write Read command in the TXFIFO and set RXWATER to 7

* ISR called with "0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10" in the FIFO.

* Set RXWATER set to 7

* ISR called with "0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19" in the FIFO. Here byte 0x11 is missing at the beginning of the FIFO but was visible on i2c bus

* Set RXWATER to 7 to get remaining bytes as we are expecting to get 20 bytes

* ISR is never called because there is only 7 bytes in the FIFO  "0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20"

I have never seen it when I'm issuing a single read command and it seems to only appear when I'm queuing read commands in the TXFIFO to read more than 256 bytes. I'm only queuing a read command when more than 128 bytes of the previous read has been completed, so at worst there is one read command in the TXFIFO and one being processed.

Regards

[Dhruvit]

Hi @ykrons,

Could you please provide me with the steps which you followed to set the RXWATER?

The RXWATER[16:17] is a 2-bit field in the MFCR register.
The Receive Data Flag will be set whenever the number of words in the receive FIFO is greater than the RXWATER value.
The API "lpi2c_imx_set_rx_watermark", either sets RXWATER to 2, or 0.
Kindly refer to section "15.7.3.1.15 Master FIFO Control Register (MFCR)" in i.MX8X Applications Processor Reference Manual.

Thank you.
Best regards,
Dhruvit.

[ykrons]

Hello @Dhruvit,

I was also a bit surprised by those high values for the RXFIFO buffer size and so for RXWATER.

I have asked the question here: https://community.nxp.com/t5/i-MX-Processors/iMX8X-lpi2c-FIFO-buffer-sizes/m-p/1509522#M194117 and it seems another NXP support person was not so surprised.

So I have just supposed I'm missing some knowledge do understand some internal magic of the lpi2c block where we can extend the FIFO size ...

Regards

[Dhruvit]

Hi @ykrons,

The PARAM register contains parameter values that are implemented in the module.

The MTXFIFO[3:0] and MRXFIFO[8:11] parameters are read-only parameters in the PARAM register,
whose values are generally fixed at 2. which results in RXFIFO/TXFIFO size of 4 words.

And that is calculated in the driver in the below part of the code.

lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
lpi2c_imx->rxfifosize = 1 << ((temp >>  & 0x0f);

One can also use DMA if one wants to transfer more than 256 bytes of data.

Can you please specify the BSP that you are using?

Thanks & Regards,
Dhruvit.

[ykrons]

Hello,

Sorry for the delay.

Is there already an i2c driver available that is using DMA tranfer?

We are using Toradex BSP 5 based on Yocto Dunfell.

Not sure what is the NXP BSP used.

Here are the refs:
meta-freescale = HEAD:3cb29cff92568ea835ef070490f185349d712837
meta-freescale-3rdparty = HEAD:c52f64973cd4043a5e8be1c7e29bb9690eb4c3e5
meta-freescale-distro = HEAD:5d882cdf079b3bde0bd9869ce3ca3db411acbf3b

Kind regards

[Dhruvit]

Hi @ykrons 

I hope you are doing well.

i2c-imx-lpi2c.c driver supports DMA transfer after the commit (f962f411ef638a6f57d4255223467cffabb1787a) in if-5.15.52-2.1.0 Linux version :

"Add eDMA receive and send mode support.

Support to read and write data larger than 256 bytes in one frame."

Please upgrade to the latest Kernel version or try applying the patch from nxp-imx github.

Thanks & Regards

Dhruvit Vasavada