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.
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
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).
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
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?