I2C+KSDK+PE+Interrupt Problem

[matheuspinto]

Hi ,

I tried to get help from the community for the problem indicated in this thread:

https://community.freescale.com/thread/372948

Unfortunately I got no answer. Thus, now I will use an example of a simple program without RTOS.

Attached are two projects. One of them works properly and the other don't. To both, I'm using the FRDM-KL25Z with KDS 3.0 + KSDK + PE.

The goal of the project is communication with the accelerometer, built into the board, through the I2C. For the test, its used the RGB LED in the board, where the light (blue, green or red) corresponding to the axis rises when it is in parallel with the vertical.

The project that works fine is the "i2c_sdk_test". In this project, the module " i2c_gen_driver" implement an i2c driver, that uses the KSDK. The writing functions are " i2c_MasterRead" and " i2c_MasterWrite". Their codes can be seen in Figures below.

As can be seen, after every read or write by KSDK API, is made a pooling that verifies if the bus is not busy.

In the other project, the "i2c_sdk_test_with_flag" I want to warning the writing/reading functions when the bus is not busy, with a flag in I2C ISR. For this, I created a global flag in the file "i2c_gen_driver.c" as shown in the figure below.

The ISR code, within " i2c_gen_driver.c" is divided into two parts, as seen in the figure below: a test for the direction of communication; and another that verifies if the I2C communication came to an end, by setting the flag.

Now, after every read or write by KSDK API is evaluated if the flag was set, before proceeding. As shown in the figure below.

Unfortunately, the code doesn’t work as expected, the RGB LED don’t light properly.

I thought that KSDK API, "I2C_DRV_MasterGetReceiveStatus " and "I2C_DRV_MasterGetSendStatus", was returning an incorrect value status within the ISR.

Then as shown in the figure below, I added a code after the flag test in reading and writing functions to see if the bus was not busy, in fact.

So in debug it was confirmed what I thought, as shown in Figure below. The flag is set in the ISR indicating that the bus is not busy, however when the program return to the write/read function, the status function indicates that the bus is busy.

The "I2C_DRV_MasterGetReceiveStatus" and "I2C_DRV_MasterGetSendStatus" functions don’t work properly within ISRs?

Original Attachment has been moved to: i2c_sdk_test_with_flag.rar

Original Attachment has been moved to: i2c_sdk_test.rar

[Jorge_Gonzalez]

Hello Matheus Pinto:

I analyzed your issue and I think there is a bug in the driver or maybe a misunderstanding of the same, but I will report it to the developers.

The driver sets the master->status to kStatus_I2C_Success immediately after sending the slave address, so when you are checking the Send or Receive status in the interrupt context and receive a SUCCESS, not all data has been actually sent or received.

As workaround you could use this code in your ISR:

//the ISR from i2c interrupts
void I2C0_IRQHandler(void)
{
    uint32_t bytesRemaining;
    i2c_status_t i2cReturn;
  I2C_DRV_IRQHandler(FSL_I2C_0);
  // Check if the I2C transfer is completed
  if(i2c_0_MasterState.i2cIdle)
  {
      i2c_handler.i2cTransactionFinished = true;
  }
}

Or you could simply poll the flag i2c_0_MasterState.i2cIdle in your application instead of your flag i2c_handler.i2cTransactionFinished.

I hope this helps.

Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[matheuspinto]

Thanks Jorge Gonzales,

That works! But, I like to know if "I2C_DRV_MasterGetReceiveStatus " and "I2C_DRV_MasterGetSendStatus" are really bugged, to not use them again!

Im doing this driver to use RTOS, so the flag i2c_handler.i2cTransactionFinished is in fact a semaphore! Thats why I dont poll the flag i2c_0_MasterState.i2cIdle.