7 years, 5 months ago.

Troubles with I2C on FRDM-K64F

Has anyone had any luck using the I2C interfaces on the FRDM-K64F?

I have written several drivers that work great on the FRDM-KL25Z that simply are not working on the K64F.

Oddly enough, the K64F_eCompass example application seems to be working just fine. I have tried using both I2C0 and I2C1, to no avail.

Yes, I am aware K64F errata regarding the swapping of the SDA and SCL lines on D14 and D15.

Thanks, Cam

Can you share with us examples which don't work so we can test them?
There is known problem with i2c, also exists in other Freescale targets. You can test your examples which work great on KL25Z, change to different freq and you might see the same troubles than with k64f.
As I recall, ecompass for K64F sets i2c freq to 400kHz, which seems to be properly working with k64f. any help solving this i2c issue is appreciated.

Regards, 0xc0170

posted by Martin Kojtal 28 Apr 2014

My application is based on the Honeywell HIH6130 temperature sensor library from Spiridion. This application works on the KL05Z and KL25Z. The only change I make for the K64 is to flip my jumpers on D14 and D15 and remove the pull up resistor.



posted by Cameron Haegle 29 Apr 2014

It would seem that I have uncovered the resolution. Once I set the I2C frequency to 400kHz, all seems to work just fine.


posted by Cameron Haegle 29 Apr 2014

4 Answers

7 years, 4 months ago.

Hello Cameron Haegle,

I fixed hopefully this i2c issue. It will be added in the next mbed library revision (84). Thanks for reporting.


Hello again Martin,

I will have to check it out this evening and will post my results.

Thanks, Cameron

posted by Cameron Haegle 14 May 2014

it's only in mbed-src I believe at the moment. The rev 84 of mbed lib has not been built yet ;)

posted by Martin Kojtal 14 May 2014

My apologies for not responding sooner on this issue.

Unfortunately, I am still unable to successfully communicate with I2C devices in regular (100kHz) mode. If I explicitly set the frequency to 400kHz, all is well.

I am using rev 84 of mbed.


posted by Cameron Haegle 21 May 2014

Cameron, I was testing on board acc/magnetometer with various speeds, did not see any problem. Can you point me to an example which I can run on my desk. CAn you look at the on board sensor, if that one is failing as well?

posted by Martin Kojtal 21 May 2014


The K64F_eCompass example, from Jim Carver (http://mbed.org/users/JimCarver/code/K64F_eCompass/) easily demonstrates the issue for me.

Running it as written (wi/ freq set to 400kHz), all seems well. Edit FXOS8700Q/FXOS8700Q.cpp, commenting the call to frequency(), communication fails.


posted by Cameron Haegle 22 May 2014

@Cameron, I can see it still doesn't work in the online IDE. It does offline but only if you set optimization level to 0 for mbed library.... Hope I will spot the bug

posted by Martin Kojtal 23 May 2014

Ok fixed.. You can test it, add mbed-src (fix those undefined symbols in ENET (I will fix that soon), and i2c_stop, there's that magical timeout, increase the top value from 100 to 200). It should work now :-)

I was testing it with optimization level 0, so code was slower and therefore it was running smoothly with various freq.. Still don't lkike there that software timeout, something to look at.

posted by Martin Kojtal 23 May 2014
7 years, 4 months ago.

Hi Cameron/Martin,

I have the same problem with my FREEDOM K64F rev. B board: when I compile and load a program perfectly working on a FRDM-K25Z board (MPU9150-DMP library by Shundo Kishi, https://mbed.org/users/syundo0730/code/MPU6050-DMP/) the I2C interface doesn't work (no signals coming out of SDA and SCL pins.

In my case, however, the I2C port doesn't work even if I set the SCL frequency to 400 kHz as suggested by Cameron; I use mbed library rev.83.

However the I2C works when I load the demo programs for the on board accelerometer/magnetometer.

I will try to solve this issue by myself but any hint will be appreciated.


import mbed-src, remove mbed lib, build (there's one bug regarding ethernet, remove that reference to undefined symbol, if you are not using ethernet) and you should be good to go.

I can give you a hint, what I discovered : enable open drain for i2c pins

Regards, 0xc0170

posted by Martin Kojtal 15 May 2014

Hello Francesco,

What pins are you using for SDA/SCL?

Assuming that you are using the Arduino 'standard' pins of D14 and D15, you need to keep in mind that these two lines are reversed. See FSL errata: http://cache.freescale.com/files/32bit/doc/errata/FRDMK64F_ERRATA.pdf.

Using mbed-src (rev. 190), my testing has shown that setting the frequency to 100kHz continues to NOT work. Setting the clock to 400KHz, still, looks to be working just fine.


posted by Cameron Haegle 15 May 2014

Dear Martin/Cameron, thank you for your answers!

@Martin: I was able to import mbed-src, disable references to undefined ethernet symbols, compile the code and upload the generated bin to my board; reading the source code of the i2c library I can guess that the SCL/SDA pins are both programmed as open-drain by default.

However testing my application I observe that the SCL/SDA signals are generated only at first launch of the program; if I reset my mbed board both signals disappear and do not appear again until I disconnect and reconnect the power supply to the MPU-9150. It seems like the processor looses the bus control.

@Cameron: I have received my FRDM-K64F board in the past days and it is a Rev.B board on which the error on the I2C pins is declared as resolved as confirmed viewing them on an oscilloscope The (strange) behaviour of my I2C doesn't change if I modify the SCL frequency; in both cases the signals on I2C lines appear only at first reset after powering the MPU-9150.

I will continue to investigate; thanks again for your answers.


posted by Francesco Adamo 15 May 2014
7 years, 4 months ago.

Hi All

I have worked with I2C on all the Kinetis KL and K boards (mainly with the accelerometers) and run the I2C bus with continuous traffic (back-to-back reads) so that the data is sampled at about 400 Hz.

It was very easy to lock up the I2C bus by resetting the board, whereby the accelerometer holds the SCL line low, causing a dead-lock state.

The following report explains how the driver can be easily modified to automatically recover from such a state: https://community.freescale.com/message/398627#398627



Hi Mark,

using an oscilloscope I just verified that the dead-lock problem of my I2C is due to the phenomena you reported; however, almost in my case, the line that the MPU-9150 holds down is SDA, not SCL.

I will try to implement the workaroud you propose in the mbed I2C library; luckily I am at the prototype stage of my project and I can consider also a hardware workaround, that is to add a small MOSFET that powers down the MPU-9150 when I press the reset button.

Thank you very much for your contribution.



posted by Francesco Adamo 15 May 2014
7 years, 4 months ago.

I recall seeing this library a while back. https://mbed.org/users/frankvnk/code/KL25Z_I2C_busreset/

Could probably be modified to use mbed SDK objects and work on all FRDM boards.

Hi Sam,

thanks for your comment!

I just imported your function in my program and it works very well!

I added two calls to I2C_busreset(), one prior to the inizialization phase of MPU-9150 and the other immediately after its completion; now I obtain a regular behaviour (the I2C bus doesn't lock anymore).

The only residue problem with the porting of the program on the K64F is that the DMP doesn't generate the periodic interrupt that signals new data availability.

Thanks again for your contribution.



posted by Francesco Adamo 15 May 2014

I'll have a look at reworking the I2C busreset code (one little problem : i only have the KL25Z board to test) as i wanted to add the busreset to a library i am currently creating and since i want to keep the code generic, i was even thinking of trying to create a single I2C busreset lib for all mbed devices (is this feasible? - or shouldn't we add a busreset function to the mbed i2c api instead?). As for the i2c api, another idea popped up : add user definable retries when NACK is received?

The library i am currently working on is for a RGB ambient light sensor (ISL29125). Even though the lib is ready, i am running into i2c failures (KL25Z board) when combined with the sensor interrupt mode (still have to find out if the sensor or KL25Z is causing the issue).

posted by Frank Vannieuwkerke 15 May 2014

Assigned to Cameron Haegle 7 years, 4 months ago.

This means that the question has been accepted and is being worked on.