Dear All,
I have been having problem with an LED driver controlled by I2C. It seems I am able to read from it but it will not pull the acknowledge bit low if I try to write. If someone has some experience in this and can help, I would really appreciate it. I've attached a picture of "read" working and "write" not working.

 

When having trouble with I2C I do just as you do: look at the ACK in detail. Other then getting NAK for the write everything looks perfect.

The only spitball I have to throw is the Address pin ADR: is it nailed to ground for the 0x70 address?

 

Ernie,
Thanks for the fast reply. To answer your question, the address pin is grounded. I even wrote code that would address every single possibility with a breakpoint when there was an acknowledge. The only one that works is the 0x71 address (read address). The write address is not acknowledged.
I have only thought of one thing, and that is I never connected up the LED's to the driver. It may not want to get a write signal unless it detects voltage on those sixteen pins, although I highly doubt it.
Thanks for the thought.

 

I hooked up both banks of LED's and behavior has not changed. I have tried to spread out the time and tighten it up on the clock and nothing changes. It is just odd that the read address will acknowledge but the write address does not. Another interesting thing is that the read acknowledges the first for the address, but not after it tells me its state. It also does not send back the correct code for that state.

 

One more thing. I decided to swap chips again. Turns out it doesn't help either. I also tried two different addresses with the same result. Only the "read" address sends me back an acknowledge. Any other thoughts would be helpful.

 

I hooked up both banks of LED's and behavior has not changed. I have tried to spread out the time and tighten it up on the clock and nothing changes. It is just odd that the read address will acknowledge but the write address does not. Another interesting thing is that the read acknowledges the first for the address, but not after it tells me its state. It also does not send back the correct code for that state.

During a read cycle for the status byte it's the master that ACKs, not the slave. Sure, first the slave ACKs it's address but the 2nd byte is the master ACKs the reception. Some slaves look for a NACK to know it's to stop sending data. If you forget to NAK the last byte then the slave can get stuck even after a STOP is issued.

However, with your write problem I am sorry I have no idea even what direction to tell you to look at. The only shotgun to try is hitting it with every possible write address and see if any respond, and if these addresses make any sense.