RE: TWI Clock Line Causing Bad Writes

Seth — Wed, 12 Nov 2014 17:19:09 GMT

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

RE: TWI Clock Line Causing Bad Writes

RK — Wed, 12 Nov 2014 00:40:41 GMT

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.