KSDK 1.2 I2C driver debugging issue

[rinipatel]

Hello,

I'm running the I2C driver example located at  Freescale\KSDK_1.2.0\examples\<board_name>\driver_examples\i2c\i2c_blocking\

In my setup, TWR-KL43Z board is acting as master and FRDM-KL27 board as slave. (pin connections as per the KSDK Demo User's Guide).

Now in master side code, I've bypassed the i2c_driver APIs and instead am directly using the i2c_hal platform library functions. fsl_os_abstraction layer is not used at all.

There is a strange issue I'm facing with this approach. While debugging step wise(KSDK 1.2 with OpenSDA debugger), slave board is receiving data alright and transmits back the character received. But when I run the code as a whole, every time transmission seems to fail.

I've tried using different baud rates and inserting "nop"s where OSA_TimeDelay was in original demo. But facing the same issue. What could be the cause??

Thanks

Rini

[bobpaddock]

The I2C hardware in the KL43/KL27 family is broken.  Sadly Freescale/NXP has yet to issue an errata.

When Repeated Start is issued the device outputs the device address again.
Some down stream devices don't care and other cases they do strange things with this in appropriate data byte.

If Repeated Start is not used at all there is no issue.  Sadly RS is required by many devices.

See this thread for details: Double Buffered I2C Difficulties (eg. KL27)

Could someone at NXP actually address this issue with an errata and better yet fix the problem?

[rinipatel]

Hello Bob,

Thanks for the input. Here is a very good article which gives a temporary work around for I2C Repeated Start issue.  It's for KL25, don't know whether the issue is similar to that in KL27/KL43 or not.

https://mcuoneclipse.com/2012/12/05/kl25z-and-i2c-missing-repeated-start-condition/

Hope it's relevant.

[bobpaddock]

The KL27 Repeated Start problem is yet a different problem.

This one is unique to the 43/27 family.

[Alice_Yang]

Hello Rini,

1) Have you test the demo(not change to HAL function) , how about it ?

I just test the demo under KSDK1.3 on FRDM-KL27 and FRDM-KL43 board , it can work well.

If the demo under KSDK1.2 can not work well ,please use the latest version of KSDK1.3.

2)If the demo can work well , while you juse  want use the HAL drivers , you can refer to the demo how to use the HAL

functions , and you can also show  the code you have changed .

Hope it helps

Alice

[rinipatel]

Hello Alice,

Thanks for replying.

1) Yes, the original demo (with I2C driver functions) is working perfectly well.

2) But when I remove driver layer and directly use HAL, the slave(KL27) receives data only in step debugging mode. I'm attaching the code changes that I've made on master side (KL43) code. Slave side code is unchanged. Please have a look and let me know if it is a timing issue??

Attached: modified main.c, fsl_i2c_irq.c from KSDK1.2 demo.

Regards,

Rini

[rinipatel · Accepted solution]

This issue is solved by correcting the sequence to wait for the I2Cx interrupt.

In my code, I was writing the byte in I2Cx_D and then directly checking in wait() whether interrupt was pending or not, assuming that transmission is completed and I2Cx_S_IICIF flag is cleared by ISR. But in this case, wait() exits even when I2Cx_S_IICIF is never set and transmission is still going on.

So by checking first whether I2Cx_S_IICIF is set and then clearing it out was the required sequence to get it going.

Thanks

[Alice_Yang]

Hi Rini,

Why do you use the HAL driver , i have a quick look at your code ,

you almost copy the code under the function " I2C_DRV_MasterSendDataBlocking()".

I don't know what is value do this.

And if you do not want send data by block , you can refer to the demo noBlocking:i2c_non_blocking

And i test your project on my side, it can not work , i recommend you directly use the driver function ,

and there is  demo code can refer to , while for the HAL functions , there is no demo , we should check

each code of functions .

BR

Alice

[rinipatel]

Hi Alice,

My intention behind using HAL driver was to remove fsl_os_abstraction layer. In our application, we don't want to use LPTMR timer, which is initialized in OSA_Init and used by OSA_TimeDelay, OSA_TimeGetMsec etc.

And since the same HAL code is used from inside the I2C_DRV_MasterSendDataBlocking(), it should work that was my assumption.

Also upon close inspection, i2c_blocking and i2c_non_blocking code are same, only timeout values differ. So I don't know where the direct HAL interface fails to communicate.

Regards,

Rini