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?
Doesn't play well with others maybe? Or requires 10-bit addressing?
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...
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.
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.
Write bit must be 0 to write....
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 .
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...
Yep! Sorry, a long day of digital debugging makes my brain melt.
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?
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.
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.
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.
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?
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).
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.
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.
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!).
...
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.
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.
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!