I2C USB 8451 ADS1100 read result incorrect

[Ivy Wu]

Hi,

I have connected ADS1100 (http://www.ti.com/lit/ds/symlink/ads1100.pdf) to measure the temperature sensor output voltage of LMP91000 (http://www.ti.com/lit/ds/symlink/lmp91000.pdf). In LMP91000, I have write 0x7 to switch the MODECN to TIA ON mode in order to measure the 'Temperature Sensor' appeared on pin 'VOUT' only.

1. Attached 'write to MODECN of LMP91000.vi' seems correct.

Then, I change the slave address to 0x49 of ADS1100 to measure the output code for the temperature voltage. There is one register named 'configuration register' which has a default data 0X8C. There is a two-byte 'output register' which is the output code of ADS1100.

2.Attached 'ADS1100 Read.vi' seems correct, but the read out data is incorrect, I think

The 1st byte on SDA line is the address and R/~W bit which is correct;

The 2nd byte on SDA line is the output upper byte. Here comes the problem——

there should be 9 clocks appeared on SCL line during the 2nd byte.But, I have 8 clocks during this byte. I cann 't find the ACK signal.

The 3rd byte on SDA line is the output lower byte. Here is another problem——

there should be an ACK (0) on the 9th clock, on the contrary, the ACK is 1...

The 4th byte returned the configuration register data, which should be 0x8C, but I cann't explain the wrong data appeared on the SDA line...

I have to set up the values every time I run the vi.

LMP91000 address: 0x48 MODECN register address: 0x12 MODECN register data :0x7

ADS1100 address:0x49 Numer of bytes to read:3

I/O voltage level:3.3V

Pull up resistor :10 K

I have searched on this forum to see if someone else have already solved this problem, but I did not get it.

Any suggestions or answers to these quesitions are greatly appreciated. Thanks a lot!

Sincerely,

Ivy

[Ivy Wu]

More attachments... Thanks!

Sincerely

Ivy

[NarayananK]

Hi Ivy,

We have had similar experiences in loss of clock signals, this may be (again not very sure) due to drive current of the 8451 or the sink at the device end.

We have tried different values of pull up resistors and found varying results. Refer this post

http://forums.ni.com/t5/LabVIEW/I2C-Write-Read-Error/m-p/1021112#M455240

Could suggest to change the pull up resistor in order to adjust the drive current of SDA and SCL lines.

This is a bit crude method, however, it worked in our case.

All the best.

[GPIB_Guru]

What results are you getting? Is the USB-8451 returning the wrong value? Looking at your scope captures, I am actually not seeing any errors. You may consider slightly stronger pull-ups, but 10k shoud work. I often like 4.7k, but your edges looks clean enough. There are a few glitches in them that may make you go stronger. (note, in your VIs, you are closing the device reference, but you may consider closing the configuration reference as well)

Interpreting the two scope captures, I see:

write to MODECN register.JPG
100100000 = x48 Read Ack
000100100 = x12 Ack
000001110 = x7 Ack

ADS1100 Read waveforms.JPG
100100110 = x49 Write Ack
111110100 = xFA Ack
100110110 = x9B Ack
100011001 = x8C NAK

Note that that Read Waveforms just *looks* off. It appears that your slave may be doing a clock stretch before the ACK bit can be set. If you examine the waveform, you see:

Start

9 pulses (address)

8 pulses (data portion of the xFA)

<delay>

9 pulses (first pulse is the ACK for xFA, the next 8 pulses are for the data portion of x9B)

<delay>

9 pulses (first pulse is the ACK for x9B, the next 8 pulses are for the data portion of x8C)

<delay>

1 pules (NAK for x8C)

Stop

[Ivy Wu]

Hi NaruF1,

Thanks for your reply. I will discuss your suggestion with my mentor and see if the result will be correct.

Sincerely

Ivy

[Ivy Wu]

HI, GPIB Guru,

At first, thank you very much for your detailed explainations.

1.

...

 Interpreting the two scope captures, I see:

write to MODECN register.JPG
100100000 = x48 Read Ack
000100100 = x12 Ack
000001110 = x7 Ack

ADS1100 Read waveforms.JPG
100100110 = x49 Write Ack
111110100 = xFA Ack
100110110 = x9B Ack
100011001 = x8C NAK

...

Yes, I have realized that from the second output byte, there seems one clock delay for each byte, which can explain your interpretation above. But according to the ADS1100's datasheet, when the last byte (the configuration register which is 0x8C) is read out, the SDA line should pulled down to 0 to gives an ACK signal, not a high NACK signal.

I have also attached the 'reading diagram from ADS1100'.

2.

...

It appears that your slave may be doing a clock stretch before the ACK bit can be set.

...

I found in datsheets of both ADS1100 and LMP91000 that they both operates in Standard mode (100Khz). Actually, I have slowed down the clock rate and didn't find any changes on the read waveform. If I didn't follow your idea, please let me know. Thanks again for your kind reply.

Sincerely

Ivy

[Ivy Wu]

HI, GPIB Guru,

I have considered about the 'Clock Stretching' phenomenon you've mentioned in your last post, and I think I have got your idea. Thanks a lot for reminding me.

Also, please help me with my another quesition on the last 'NACK' of the 4th byte output. Really appreciate your help.

...

(note, in your VIs, you are closing the device reference, but you may consider closing the configuration reference as well)

...

Do you have any example having 'closing the configuraion reference'?  Thanks!

Sincerely

Ivy

[GPIB_Guru]

If the master is reading from the slave, the master is the one to do the ACK/NAK. Since you asked for 3 bytes, the I2C protocol is to ACK the first two and NAK the last one to indicate to the slave that it is done reading.

If the master is writing to the slave, the slave is the one to do the ACK/NAK and typically it is supposed to ACK every byte.

Note: That picture is incorrect per I2C. The master is required to NAK the last byte of a read.