Software I2C - Not getting ACK from slave

Hi

I have started to implement a software i2c driver.

I have run the function on several devices on a custom PCB.
Below is the logic output directly from the bus.

Of the 4 devices tested so far, only one of them has returned an ACK. The others are not replying.
All of these slave devices are wired correctly and there is no reason why they should have failed. So at this point im focused on the software as the issue.

You can see that the analyser is correctly picking up whats been sent. 0x55 is the base address with a write bit. The device in particular is a BQ27441.

From the logic output shown, is there anything glaringly obvious as to why im not getting responses from most of the i2c devices?
Each device is on its own bus, so theres noting else that can interfere. not required i know, but i had a load of pins spare and it made routing much better.


PCB Attachment 16380

> All of these slave devices are wired correctly and there is no reason why they should have failed.
And how do you know this?

It might look good compared to your circuit diagram, but have you made an electrical continuity test between the pin on the MCU and the supposed pin on the device?
A dry solder joint, a cracked circuit board track, a bridged track from bad soldering can all mess with you.
Not to mention, you could have a duff device.
How ESD sensitive are all your components?.

How easy is it for you to put the working device into a failed position? Does that tell you anything?

Your trace is pretty and all, but without scales on the graph showing the actual voltage and time base, it's impossible to tell whether you're anywhere near the I²C specs or not.

> So at this point im focused on the software as the issue.
Unless you're in the habit of re-writing s/w for every pin of every device, it's should be fairly safe to assume that if you've managed a handshake from one device on one set of pins, that the same s/w driving another set of pins will do exactly the same thing.

The trace looks good, and the address matches that in the datasheet so I guess it is something physical.

I did something similar to this a while ago, on TI 16-bit DAC. Got as far as reflowing a new part on. 0.5mm pitch, really panful.

Problem was that I was using the wrong device address - opps!

The docs I read had

Code:

---

#define GAUGE_DEVICE_ADDRESS 0xAA

---

Is there a reason you are using the address shifted one bit over?

Or is the graphic wrong about address 55?

Tim S.

Quote:

---

Originally Posted by stahta01

The docs I read had

Code:

---

#define GAUGE_DEVICE_ADDRESS 0xAA

---

Is there a reason you are using the address shifted one bit over?

Or is the graphic wrong about address 55?

Tim S.

---

High 7 bits are the device address, lowest bit indicates if it is a read or write transaction. So commands to device 0x55 will begin with either 0xAA or 0xAB.