I2C and MPL115A2

[risototh]

Hi folks,

i have one little problem. I would like to communicate with MPL115A2 sensor over I2C, but it is impossible to get data from it for me... Now i have a scope attached on I2C and probably i found where is the problem, but i don't know how to solve it.
I need to send/receive somtething like this (according to AN3785 from Freescale):
[Start], 0x60+[W], 0x12, 0x01,[Stop]
[Restart], 0x60+[W], 0x00
[Start], 0x60+[R], 0xMSB Pressure, 0xLSB Pressure, [Stop]

I call something like this:
#define ADR_PRESSURE         0x60
unsigned char wbuff_1[] = {ADR_PRESSURE, 0x12, 0x01};
unsigned char wbuff_2[] = {ADR_PRESSURE, 0x00};
unsigned char IIC_IO_read[] = {16, ADR_PRESSURE|0x01, TASK_PRVY_START};
fnWrite(IICPort, wbuff_1, sizeof(wbuff_1));
fnWrite(IICPort, wbuff_2, sizeof(wbuff_2));
fnRead(IICPort, IIC_IO_read, 0);

The problem (i mean) is between the two writes. According to the application note, there is one stop bit between the two writes (bold red one). But how i can make this stop bit? I looked at the scope, i found the start bit of the second write command, but no stop bit on the end of the first one. Can you help me with this? Or if you have some experience with communication with this sensor i uTasker, can you share the code snippet?

Thanks a lot and Marry Christmas.

EDIT: Subject name

[mark]

Hi

I am not familiar with the MPL115A2 or whether it has a special requirement in relation to the stop bit of the first transfer.
However, the driver will send a repeated start between each transmissions/receptions if these are written/read without any delays between them.

A "repeated start" is generally the same as a STOP followed by a START but is a little more effecient since the STOP is not needed.
It may be that the STOP condition is something that the MPL115A2 must have and a repeated start is not suitable at that location.

To test this, do the following:
1) Send the first data alone - this will cause a START, address, data, STOP sequence to be sent.
2) After a pause (allowing the first transfer to complete) send the following (you could also pause between the second write and read to be absolutely sure).

If the behavior of the MPL115A2 is then different it proves that this details is important.

It is possible to specify the task to be woken when an I²C transfer has completed (specified when the I²C port is opened), which is not usually used (left as 0). This allows a task to be woken when the transfer has terminated (I think after the stop condition but am not absolutely sure) and so may be a simple method of adding the delay. If not, use a timer of - say 100ms - to be sure that there is a space between transmissions to allow the stop condition to be completed each time. Once you know whether it is the solution you can optimise to get minimum pauses between the transferes.

Regards

Mark

[risototh]

Thanks Mark,

i tried your advice to wait some ms to complete the write and to send the stop bit. Unfortunately, same result.
Now, i don't know what to do next. The data send (and sniffed by a scope) are correct, but the sensor did not reply anything... I replaced the sensor with another one = same result...

Has someone tried to communicate with this sensor? Are there any hidden blackholes?

[risototh]

Ok, finaly, i have some results.

The datasheet from Freescale is more than horrible...
First, the address is 0x60, yes, but as 7-bit number ommiting LSB (W/R) bit... Therefore, in 8-bit the address is 0xC0!!!
Next, the app note explains the R/W procedure as simple process without delays... Bullshit. I must wait between the first two writes approx 5 ms to get a valid result from the device!

That's all folks. I'm very disapointed of the datashit.
Thank for watching, and thanks also to http://188.65.57.204/showthread.php?s=5501d8932bfa9a12653b4eb4f56fd48c&t=15445

[mark]

Hi

When communicating with I²C devices the first check to do is to see whether it is acknowledging the address (pulling the SDA line low during the 9^th clock). There is always a possibility of address interpretation difficulties so this can usually be cleared up quite quickly.

Some I²C devices support hold communication when reading from sensors that require some time to get the result ready. This involves them holding the SLC line low after acknowledging their address - this puts the master into a wait state - and releasing it once th eresult can be returned (eg. after 5ms if that is the tim ethat it takes). This means that the master simply reads the value and the transfer completes when the slave is ready, removing any need of adding polling or timing at the master side since the read just completes when the result is ready. Check carefully whether the device possibly supports this.

Regards

Mark