I2C bus strange behavior

msiriwardena · 2012-07-18 08:41

I am trying to read the I2C pressure sensor [MS4515DO].The sensor is connected to P28&29.
I am able to read the out-put from the sensor.The issue is the readings I get depends in the order how I power up the propeller.

If connect the USB to the prop board("SpinStudio") and then switch on the power to the board - The readings I observe is from 223 - 255.If I reset using
the reset button it still reads 223-255.
When I turn off the power to the "SpinStudio" board the readings observed is 32 - 62.

I can repeat this as many times with the same result.

Attached are 1. Code use to read the -pressure sensor - > MS4515DO
2.MS4515 Data sheet
3.The I2C Object

Mike Green · 2012-07-18 09:06

This looks like some kind of problem with timing or I2C bus loading. If you look at the MS4515DO datasheet, you'll see that you can read from 1 to 4 bytes. If you read 1 byte, you get an 8-bit value. If you read 2 or more bytes, the first byte contains the most significant 6 bits of a 14 bit value. Maybe the MS4515DO isn't seeing the ACK bit properly. Try using the Spin I2C driver (Basic_I2C_Driver). If that works, you might need to slow down the pasm_I2C_Driver a little. There's a constant parameter you can change that will do this. Look at the comments in the source code.

If it's a bus loading problem, you may need to add pullups to SCL and SDA. Try 4.7K first.

msiriwardena · 2012-07-18 11:09

Mike,
Thank you for your quick reply.
I am sorry I forgot to mention that I already had pull-ups on both SCl&SDA as suggested in the data sheet.
I also tried using the attached code too - with the same results.I will try changing the timing to slow down the pasm code.

photomankc · 2012-07-18 12:52

Does your device stretch the clock? The datasheet does not say directly but calls out that you "**wait** for acknowledge" but I know the vast majority of I2C drivers for propeller run the bus directly rather than as open collector so if the slave wants to stretch the clock you'll never know it and you'll just go on stomping over the top of it. I noticed it when I was debugging another device on a scope that worked every now and then and other times went to la-la land for one transaction. Showed up as missing clock pulses where the device was holding the clock low while I was skipping along blasting clocks out over the top of it. Really hard to diagnose this stuff without getting eyes on it somehow.

The SPIN I2C though should be slow enough to make that almost a moot issue unless it takes the thing ages to ACK.... so hmmm.

I altered the pasm_i2c_driver to run open collector, and always check that SCL has indeed been pulled back up to 1 before calling it an ACK/NAK for devices that stretch the clock.

msiriwardena · 2012-07-18 16:22

Mike/photomankc,

I just received a " Easy I2C - protocol Analyzer" and I ran it through.

I have attached the reports - They look good to me - but I am no expert so please look at them
and let me know if there is any problems.

photomankc · 2012-07-18 17:36

Well according to the datasheet, the reading you are getting when unpowered makes the most sense. %000111111 ($1F) indicates that the unit is saying the readings are good since the first two bits you get are status and 00 = good but unchanging data of all 1's always makes me think there is something up. The readings that come back with %11011111 ($DF) is puzzeling. The datasheet calls out that the first two bits mean %00 = good and %10 = stale. There is no %11 status response called out. The trailing data has zeros so the slave is doing something on the bus we know this but not sure it's anything valid. You'd need to reassemble the full word and see if it makes any sense to what the sensor should be saying.

Wait though.... looking at the data sheet, don't you first have to do a |START|RD_ADDR|STOP| to tell the device to sample? Then you can read the measurement in one of 3 ways? You then have to start a second transaction |START|RD_ADDR|DATA+ACK|DATA+NAK|STOP| to get the reading. Am I reading that wrong?

msiriwardena · 2012-07-18 18:03

photomankc,
The data I sent from the I2C protocol analyzer - do change,the problem was it was sampling so fast and it would take many pages to catch them.I tried to cacth them
as you would notice in one or two of the captured results.I can display the reading changes using PST as the pressure is increased/decreasd.So the slave I2C does function but the readings are 31 to 63 and 233 to 255
depending on how power was applied as explained in the first posting.

photomankc · 2012-07-18 19:11

Without more info I can't tell why it's doing that. There has to some reason why it setting the status bits to %11XXXXXX when powered one way and %00XXXXXX the other but I can't tell why.

Your I2C communication looks right from the capture. Is it the "Low Power" version? (ends in L)? If it's not low power then I take it that it should be continually converting within the 500uS response time.

Check the voltages supplying the chip in both power conditions? Otherwise I don't know. Seems to be reasonable data either way if you mask out the status bits.

msiriwardena · 2012-07-18 19:27

photomankc,

Thank you very much for all the help.

I2C bus strange behavior

Comments