I2C_MasterTransferBlocking hangs waiting on kI2C_TransferCompleteFlag

cancel
Showing results for 
Search instead for 
Did you mean: 

I2C_MasterTransferBlocking hangs waiting on kI2C_TransferCompleteFlag

Jump to solution
80 Views
steve32768
Contributor I

I'm using MCUXpresso SDK version 2.8.0 with the MK64FX512VLL12. I'm working with 3 I2C buses (I2C0, I2C1, and I2C2).

I'm having an issue where I2C_MasterTransferBlocking() hangs in an infinite loop waiting on the kI2C_TransferCompleteFlag:

/* Wait until the data register is ready for transmit. */
while (0U == (base->S & (uint8_t)kI2C_TransferCompleteFlag))
{
}


The hang doesn't occur on I2C0 or I2C1. However, I2C2 is shared with another master. Transfers work on that bus until the other master performs a transfer. The next time I call I2C_MasterTransferBlocking(), this results in an infinite loop waiting on kI2C_TransferCompleteFlag near the very top of the function.

It appears the other master's transfer results in the I2C2_S:TCF flag being cleared, so I'm not surprised to see the loop above hang infinitely. In fact, the K64 reference manual says this about I2Cx_S:TCF:

"TCF - Transfer Complete Flag: Acknowledges a byte transfer; TCF is set on the completion of a byte transfer. This bit is valid only during or immediately following a transfer to or from the I2C module. TCF is cleared by reading the I2C data register in receive mode or by writing to the I2C data register in transmit mode."

I can work around the issue by replacing the existing loop with:

while (base->S & (uint8_t)kI2C_BusBusyFlag)
{
}


So to my question(s):

  • Why is I2C_MasterTransferBlocking() waiting for the TCF flag before performing a transfer when the reference manual advises that TCF is only valid after a transfer?
  • Does my workaround (waiting for kI2C_BusBusyFlag==0) look reasonable?
  • Is this a bug in the fsl_i2c.c that should be addressed by NXP?
0 Kudos
1 Solution
68 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @steve32768,

  • Why is I2C_MasterTransferBlocking() waiting for the TCF flag before performing a transfer when the reference manual advises that TCF is only valid after a transfer?

Since you're using the blocking function, the API will wait until the transfer ends to continue in the code. The TCF 

  • Does my workaround (waiting for kI2C_BusBusyFlag==0) look reasonable?

Yes, the SDK is not enabled to work as Multimaster so checking the busy flag before a transfer to see if there's any pending transfer in the bus is a good approach.

  • Is this a bug in the fsl_i2c.c that should be addressed by NXP?
The SDK only provides the typical use cases for the module. A multi-master I2C bus is a custom application and therefore not implemented. I do appreciate you taking the time to bring this to our attention, I will forward this to the development team so they can analyze this improvement opportunity.
 

Best Regards,

Alexis Andalon

View solution in original post

0 Kudos
2 Replies
69 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @steve32768,

  • Why is I2C_MasterTransferBlocking() waiting for the TCF flag before performing a transfer when the reference manual advises that TCF is only valid after a transfer?

Since you're using the blocking function, the API will wait until the transfer ends to continue in the code. The TCF 

  • Does my workaround (waiting for kI2C_BusBusyFlag==0) look reasonable?

Yes, the SDK is not enabled to work as Multimaster so checking the busy flag before a transfer to see if there's any pending transfer in the bus is a good approach.

  • Is this a bug in the fsl_i2c.c that should be addressed by NXP?
The SDK only provides the typical use cases for the module. A multi-master I2C bus is a custom application and therefore not implemented. I do appreciate you taking the time to bring this to our attention, I will forward this to the development team so they can analyze this improvement opportunity.
 

Best Regards,

Alexis Andalon

View solution in original post

0 Kudos
39 Views
steve32768
Contributor I

Thanks for the response. I'll go ahead with my workaround as described.

0 Kudos