Hello again Martin,

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

Thanks, Cameron

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

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.

-Cameron

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?

Martin,

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.

-Cameron

@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

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.

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

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.

-Cameron

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.

Regards.

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.

Regards

Francesco

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.

Regards

Francesco

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