TWI Clock Line Causing Bad Writes

[Seth]

I'm using the nrf51822 TWI library. I've tried both twi hardware and software master library files and see the same behavior when using both (as a side note an explanation of the difference would be helpful.) I have 3 I2C chips wired to the NRF51822 all with distinct addresses that are wired according to their datasheets. I am reading the SCL/SDA lines with a logic analyzer and I am occasionally seeing an issue that causes bad writes. I've included a screenshot of the analyzer output.

This shows 2 one-byte writes, the first one to address 30 is correct. The device has write address 0x30, I am writing to register 0x33, and the value being written is 0x32. However, the next write should be a write to device address 0x30, register 0x30 with value 0x95, however that is not what is happening. It looks to me like the clock line is very briefly going low at the same time as the data line goes low (where I circled in red). As far as I can see with the resolution of the analyzer, the high-to-low edge on SCL and SDA occur at the same time.

(if you right click on the image and download it, you can see the details more clearly)

This issue does not always occur at one place. Sometimes I don't see it, and when I do it's not always on the same write. I've tried putting in long delays between each write to make sure that the slave has finished the write, but that didn't make any difference. I also have seen it on more than one of the three slave devices. Finally, I will also mention that the SCL and SDA lines both have 10K pullup resistors to the NRF51822's VCC rail.

I'm not very experienced using I2C so I've hit a wall debugging this. It doesn't seem like a code issue on the NRF51822, which leads me to think that it might be a wiring issue, but there isn't much I could change other than maybe the pull-up resistor values.

Any help or suggestions will be greatly appreciated!

[RK]

I can't answer the question but I can make a couple of observations. I also by the way had problems when I added a TWI device in parallel with the NRF6530 (dot matrix + joystick) to find that what worked on two separate TWIs failed when I tried to use one .. I didn't however stick the analyser on it at the time.

I agree that low pulse is strange. Measuring using pixels it seems to me the overall length of the SCL high is correct for a start pulse but something is momentarily pulling it down around the point SDA goes low.

If you ignore what the Saleae is decoding after that point however, assuming that that pulse has confused the decoder library (note it's missing a start blob for one), the rest of the trace actually seems correct. Count the next 8 SCL pulses looking at SDA and that's 00110000, then there's a very slight gap but SDA stays low and an ACK is clocked in. Following similarly along the next one is 00110000 + ACK and then 10010101 + ACK which is what you're trying to send. Finally data goes high, then low and high again with SCL high for a stop, also correct.

In each case the 8 clock pulses for data are equally-spaced which seems to indicate the nrf51822 is doing the right thing, the clock pulse for ACK is slightly delayed, that's ok, and something, I assume a device, is holding SDA low for an ACK, so it looks to me like the device you're talking to is not confused by that blip (if it even sees it) and continues to respond correctly.

If the devices really were seeing 0x18 as the address, unless you happened to have such a device, then none of them would respond, SDA would float high at the end of the first sequence and you'd get a NAK and an error in the TWI library (I assume, I don't use the TWI library, I wrote my own).

So are you getting errors in the library from NAK's, what are your devices actually doing, are they malfunctioning, or are you just looking at the decoded traces from the Saleae and not seeing what you expect there? I agree that pulse is bizarre and shouldn't be there, and that is certainly putting the Saleae decoder out of sync with the data for that transaction, but eyeballing the rest of the trace especially where the ACKs really are, it looks like the devices are responding properly.

[Seth]

Thanks RK, you are completely right that the issue was with the Saleae analyzer. I found on their forums that others had had a similar issue, and that is was just noise resulting from too high of a sample rate. The expected ACK's are what tipped me off in then (although it did create quite a headache for a while there.)

Thanks! Seth