Author Topic: I2C & multiple chips not working (Read 5733 times)

Christopher · « **on:** February 12, 2015, 06:33:54 pm »

I have a very strange problem here. Let me go through it with you.

I have a processor talking I2C through an isolator (ADUM1250) to three chips.

A DAC, and ADC and an IO expander. The DAC and IO expander work OK, I can access the registers fine. The ADC (Linear LTC2990) does not like me.

I am confident my timing/i2c routine is OK because I have used this chip on its own in the same system.

All chips have an OK VCC on each side, adequate decoupling, all i2c connections are connected and I have 3k pullups on the isolated side.

The LTC2990 is set to address 0x9E. The signals look OK on the scope. The clock speed does not change my result.

Loging analyser output:
Write (byte) to register 0x01. Chip responds with ACK
Write 0x06. Respond with 0x00 and NO ack?!

Why would it respond with all 0s and NO ack?!?!?

Changing the address to 0x9c results in no ACK on the first write and all FF data.

Any smart ideas?

katzohki · « **Reply #1 on:** February 12, 2015, 07:01:55 pm »

Doesn't play well with others maybe? Or requires 10-bit addressing?

Gixy · « **Reply #2 on:** February 12, 2015, 07:06:19 pm »

Hmm,
0x9E is an 8 bits address. Usally, addresses are expressed in 7 bits form, the 8th bit being R/W bit. In your case the address should be 0x4F. But this depends of your software interface...

Christopher · « **Reply #3 on:** February 12, 2015, 07:08:13 pm »

Quote from: katzohki on February 12, 2015, 07:01:55 pm

Doesn't play well with others maybe? Or requires 10-bit addressing?

I have a second board with the same chip and software (no isolator though) with an i2c temp sensor which works fine. All chips have different addresses and are 7 bit addressed.

Quote from: Gixy on February 12, 2015, 07:06:19 pm

Hmm,
0x9E is an 8 bits address. Usally, addresses are expressed in 7 bits form, the 8th bit being R/W bit. In your case the address should be 0x4F. But this depends of your software interface...

I am using 0x9E as my read address and 0x9F as my write address, with the 8th bit being R/W.

Gixy · « **Reply #4 on:** February 12, 2015, 07:12:53 pm »

Write bit must be 0 to write....

Christopher · « **Reply #5 on:** February 12, 2015, 07:14:38 pm »

Sorry. I don't have my code here but I am sure that the write bit is cleared when I am writing, it's only when I am reading I set this bit .

Gixy · « **Reply #6 on:** February 12, 2015, 07:17:09 pm »

Quote from: Christopher on February 12, 2015, 07:14:38 pm

Sorry. I don't have my code here but I am sure that the write bit is 0 when I am writing, it's only when I am reading I set this bit to 0.

You mean you set it to 1 to read...

Christopher · « **Reply #7 on:** February 12, 2015, 07:17:48 pm »

Yep! Sorry, a long day of digital debugging makes my brain melt.

Gixy · « **Reply #8 on:** February 12, 2015, 07:28:38 pm »

You're trying to set mode to 6. The device is not supposed to answer to this command by anything else than ACK or NAK. Are you really sure of your software?

Christopher · « **Reply #9 on:** February 12, 2015, 07:41:22 pm »

Write 0b01011111 to register 0x01 (control register). Replies with ACK

wait 10ms

Write 0xFF to register 0x00 (trigger conversion). Replies with ACK

wait 100ms

Read from register 0x06. Replys with 0x00 and Replies with a missing ACK

wait 10ms

Read from register 0x07. Replys with 0x00 and Replies with a missing ACK

As I said, I know the software works as I have used the same routines with another board.

retrolefty · « **Reply #10 on:** February 12, 2015, 07:44:13 pm »

Could be the classic 7 bit Vs 8 bit I2C addressing convention. For example if you use the standard Arduino I2C library provided (I forget it's name at the moment) you call all I2C library functions using using the devices 7 bit address which is the 8 bit address shifted right one bit (you don't provide the R/W bit) as the library function appends that bit when actually communicating with the I2C device(s).

So it's possible (but not diffidently of course) just a software problem or misuse on you micro/software side rather then the I2C device.

Christopher · « **Reply #11 on:** February 12, 2015, 07:46:15 pm »

I have written my bitbang i2c routines to talk using an 8 bit address byte, with the last bit used as a r/w bit which I toggle myself. I can see the data on the logic analyser as per my last post.

This is on an arm micro.

nuno · « **Reply #12 on:** February 12, 2015, 08:04:44 pm »

One of the sides of the I2C isolator is I2C compatible but not I2C compliant, maybe it's the problem. Can you test with only the ADC without the isolator?

Christopher · « **Reply #13 on:** February 12, 2015, 08:12:08 pm »

I will gather some scope captures tomorrow morning.

I am following the procedure in the datasheet OK and this works with a test board (Just the LTC2990 ADC).

nuno · « **Reply #14 on:** February 12, 2015, 08:22:38 pm »

By the way, what processor you're using? If it is a RasPi, there's a known bug in the I2C master hw that causes problems with slaves that do clock stretching.

Gixy · « **Reply #15 on:** February 12, 2015, 08:35:38 pm »

Refering to datasheet, your protocol doesn't seem correct. To read the register 0x06, you must send again the address after sending the command: see fig. 7 of the datasheet. And again, you cannot have data read without first an ACK from the device. Waiting from scope captures.

Christopher · « **Reply #16 on:** February 12, 2015, 08:37:46 pm »

I am using an ARM microcontroller with software bitbashed i2c (I couldn't get the hardware module working in time for our client demo).

LTC2990 or any of the other chips I am using do not implement clock stretching. Thanks for all the small bits of advice to check, even little tidbits like this I might have overlooked are really helpful.

I will post scope captures tomorrow mid-morning (unless I have fixed the prob. Which I doubt!).

AndreasF · « **Reply #17 on:** February 13, 2015, 09:51:57 am »

Quote from: Christopher on February 12, 2015, 07:41:22 pm

...
Write 0xFF to register 0x00 (trigger conversion). Replies with ACK
...

maybe this is a typo, but the datasheet says control register 0x02 is the trigger register. Register 0x00 is a read-only status register.

Ice-Tea · « **Reply #18 on:** February 13, 2015, 10:56:35 am »

Fault finding 101: simplify your circuit, check again.

In this case, attach your devices directly on the bus, without isolator. If it still doesn't work, the iso is not the culprit and you can leave that out of the equation.

Christopher · « **Reply #19 on:** February 13, 2015, 01:54:40 pm »

I figured out half of my problem...

The circuit works with the isolator shorted.. So it's the isolator

Looking closer there are no pullups on SDA of the input to the Isolator! So I can write on the bus fine which was why my DAC was working!


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: I2C & multiple chips not working (Read 5733 times)

Share me