MPC5xxx inconsistencies in I2C peripheral documentation and driver example code

[qwertyu]

I am trying to implement an MPC5xxx I2C driver for usage in multiple projects based on the available documentation of the I2C peripheral in the MPC5xxx reference manuals and the I2C driver code from NXP which I found here:

https://community.nxp.com/docs/DOC-330972

However, I have found some inconsistencies in the available documentation (see attachment of the MPC5607B Reference Manual as an example) and the I2C driver code regarding the STOP signal generation via MSSL bit and the handling of the interrupt flag IBIF.

1. The MPC5607B Reference Manual states on page 455 for the MSSL bit: "A STOP signal
   should be generated only if the IBIF flag is set." However, the flow-chart for an I2C interrupt routine (Figure 22-14 on page 468) clearly shows that the STOP signal should be generated after the IBIF bit is cleared. This sequence is shown both for master transmitter and master receiver mode. Which sequence is the correct one? Or does it even matter in what sequence the IBIF bit and the STOP signal are handled?
2. The I2C driver code from NXP contains a function called "I2C_0_Callback" that seems to implement the above mentioned flow-chart for an I2C interrupt routine. However, there is one main difference with regard to the handling of the IBIF bit. In the flow-chart the IBIF bit is always cleared at the beginning of the handler function while in the driver code it is always cleared at the end of the handler function. In my understanding the driver code will not always behave correctly that way. An I2C data transfer (either transmit or receive) could be started by accessing IBDR, but "I2C_0_Callback" could get interrupted by some other function with higher priority, the I2C data transfer could complete before "I2C_0_Callback" is executed again and finally reaches the point of clearing the IBIF bit. That way, an I2C data transfer would be completed but the IBIF would also have been cleared which leads to a situation where the calling function is stuck on waiting for IBIF to be set (polling mode) or consecutive interrupts will not occur anymore (interrupt mode). Which handling of the IBIF bit is the correct one?
3. I have also found other inconsistencies in the I2C DMA flow-charts of multiple MPC57xx reference manuals but I think that the first two points need to be clarified first before addressing them.

[PetrS]

Hi,

1) the meaning is STOP should be generated after transfer is done, i.e. after IBIF flag set. But it is not needed to have IBIF set when MSSL is going to be cleared

2) assuming interrupt nesting and the situation you mentioned, it makes sense to clear IBIF at the beginning of routine. 

BR, Petr

[qwertyu]

Hello Petr,

thank you for the clarification. To my understanding both answers mean that I should always follow the description of the flow-chart for the I2C interrupt routine in the reference manual.

The third point that I had is mainly related to reading the last data byte in master receiver mode. According to the flow-chart for the I2C interrupt routine a STOP signal needs to be generated first before reading the last data byte. However, multiple MPC57xx reference manuals have a separate flow-chart for DMA mode master receive (e. g. Figure 44-15 in MPC5748G Reference Manual) where the last data byte is read before MSSL is cleared for generating the STOP signal. I have found during some extensive tests that I get very rarely unexpected values in the last data byte if I read it before generating the STOP signal. But I do not really understand why the STOP signal is needed before reading the last data byte when the I2C communication itself has already been halted (i. e. IBIF has been set previously before reading the last data byte).

[PetrS]

Hi,

In master receive mode, reading IBDR register initiates next byte data receiving (clocks are generated) and will return the last byte received. Thus if no other byte is requested STOP should be issued first and then IBDR read to get the last byte.

Seems the Figure 44-15 is not completely correct. First STOP should be generated, then last byte should be read.

BR, Petr

[qwertyu]

Hello Petr,

I tried to prevent that reading IBDR (after the last data byte reception) initiates the next data byte receiving via setting TXRX bit to 1 before reading IBDR.

I do not want to generate a STOP condition in my I2C driver after every single usage of master receiver mode because some I2C slave devices require or at least support longer linked sequences where multiples transitions between master transmitter and master receiver mode via repeated START conditions need to be executed.

Setting TXRX=1 to prevent another reception works most of the time but as I said I get very rarely wrong data byte values when using this method. It was only possible to gather this information with lots of devices (>1000) deployed for over eight months in the field now.

So it seems that there is no other way available than to use the STOP condition at the end of operation in master receiver mode which limits the general applicability of the I2C hardware of MPC5xxx devices in my opinion.

Can you confirm this identified behavior of the I2C hardware?