Electronic – Why does the I2C write get NAK’d

i2cpicreverse-engineeringtiming

I am trying to interface to an existing device, for which I do not have documentation. The device exposes a 5v I²C interface with several IC's on the bus. I have used a logic analyzer to capture the traffic, and do not understand why my writes are not being accepted.

Working system:

Unknown microcontroller  ==| connector |==+== PIC 12F509 with internal oscillator
                                          |== 24C16WI 2k EEPROM
                                          \== Logic analyzer

The first communication with the device is to send a write request to address 0x49, but when I attempt to do the same, I do not receive a response. There are obvious timing differences in my request versus theirs, but I am not sure if they are significant. Communication with the 24C16WI is successful, but I can get no response from the PIC.

Working request (baud rate 36kHz) (Saleae capture):

My request (baud rate 31kHz) (Saleae capture):

Assuming that the difference does not rely upon a signal other than the I²C lines, are the timing differences in the signal significant? If they are significant, how can I generate the required timing using an Atmel SAMD21J18?

What am I missing?

Best Answer

Summary: I suspect that the new I²C timing is not close enough to the original, and at least one "abnormal" I²C sequence is shown on the "working trace", which may be difficult for you to reproduce.

Details:

Assuming that the difference does not rely upon a signal other than the I²C lines [...]
What am I missing?

The logic analyser captures are very helpful, thanks. Along with the other info, I think we have a good "suspect".

There are obvious timing differences in my request versus theirs, but I am not sure if they are significant.

I bet the timing differences are significant, especially since:

Communication with the 24C16WI is successful

So using your own I²C Master, you can communicate with the standard I²C device (that EEPROM). As you said, the problem is trying to get a response from the PIC, and as you pointed out in a later comment, that PIC does not have a built-in I2C module:

I read through the slave device's (PIC12F509) datasheet but did not see a hardware I2C implementation. I can only assume they are bit-banging.

Yes! I've seen other PIC devices (without an internal I²C module) programmed as I²C Slaves, which had significant timing restrictions on their I²C behaviour.

I do note that there is a longer delay in the start sequence

Exactly. I haven't measured using the Saleae software, but "by eye" there is approximately 0.8 ms delay between the I²C Start condition and the first toggle of the SCL signal on the working trace, and no such delay on the failing trace.

That delay is not typical I²C behaviour, but I suspect it is necessary for the (unknown) PIC firmware to recognise the I²C Start condition (e.g. perhaps it has to wake from sleep, using the PIC GPIO "wake on change" feature, when the SDA signal changes as part of the I²C Start condition).

If I was in your situation, I would start with a hypothesis that all of the original I²C timing is important (not only the SCL clock speed, where you are already similar to the original speed) and try to duplicate the original timing and behaviour completely. After all, that original sequence does work :-)

There are other unusual parts to the "working" I²C transaction:

In the address byte, there seems to be a small delay between the clock for bit 8 and the clock for the (9th) ACK/NACK bit. Again, that delay (which doesn't exist in your "failing" trace) might be required by the PIC firmware.
In the next byte, I see only 8 clock pulses not the expected 9 pulses, which explains the Saleae software's comment about "Missing ACK/NACK". Again, this (abnormal) I²C behaviour might be required to match the expectations of the PIC firmware, but is likely to be difficult or impossible to reproduce, using "normal" I²C driver / library code, as this would typically generate all 9 normal clock pulses.

I am unsure how to produce that with the Atmel ASF I2C driver.

I haven't used that driver. You can investigate whether you can insert a delay after sending the I²C Start condition, before sending the device address. That is separate from the "Missing ACK/NACK" clock pulse (which might need to be missing!) when the Master transmitted the second byte in the "working trace".

Therefore you may be unable to use that driver "as is", and instead may need to write your own low-level ("driver") code, which gives you more control. If all else fails to give you the necessary amount of timing and clock pulse control, you might need to bit-bang the Master's SDA and SCL signals yourself for some or all of the I²C protocol sequences you need.

Related Solutions

Electronic – Strange I2C Behaviour

It looks to me that you're ORing terms that you need to be ANDing. I2C_ON is 0xFFFF, so the register is going to be all 1's.

Take a look at the i2c.h file for PIC24:

#define I2C_ON                      0xFFFF /*I2C module enabled */

No matter what else you put in the configuration word, they're all going to be 1. Many settings you need (general call off, 7-bit address, etc.) need their corresponding bits to be zero.

Here's how I init the I2C peripheral on a dsPIC33 (essentially the same peripheral and same library calls):

OpenI2C1(I2C1_ON & I2C1_IDLE_CON & I2C1_7BIT_ADD & I2C1_STR_EN & I2C1_SLW_DIS & I2C1_GCALL_DIS & I2C1_SM_EN & I2C1_IPMI_DIS, clk);

Also bear in mind that the clock argument should be unsigned int - not 4.2 :)

(When in doubt, don't use the library call and manually set the SFR bits yourself.)

Electronic – I2C read/write failure under heavy interrupt load

This is a software issue, you are spending too much time servicing interrupts & your I2C routine is not able to handle it (so that's two things which are not right). I have been through several similar situations.

First: You need to do as little as possible in the interrupts, only read & store the data, don't do any processing that you could do outside the ISR, maths can take a LOT of CPU cycles and the CPU cannot do anything else while in that interrupt.

Second: Investigate DMA to automate things, so your interrupts become almost a background automated process.

Third: If I2C is important, put THAT in an interrupt too, but make sure you work out the priorities!

Fourth: Work out why your I2C routine is failing, I2C itself can stand up to very intermittent timings, pauses & waits etc. so your routine may need modifying to allow this.

Fifth: See if you can "chain" interrupts, you may find you can service the ADC reads more efficiently, or put the ADC in a different mode where it does more work for you before interrupting (EG wait for all readings to be available, then read all in one hit, rather than 8 separate interrupts for 8 separate ADC channel reads).

Sixth: Use an oscilloscope or logic analyser, and spare IO pins on the board, to trace how much time you're spending in each bit of code, to see if you can speed it up. (Set pin high when you enter a function/ISR, set it low again on exit).

Seventh: Decide if you really need to read the ADC so much, will going slower make things worse? It's counter-intuitive but sometimes running slower actually gives nicer results, doing the work of averaging the signal for you and cutting down on spikes/transients which could cause problems or require extra processing to remove. We improved a motor control PID routine by simply running it 1/4 the speed, freeing up a load of CPU time in the process.

Best Answer

Related Solutions

Electronic – Strange I2C Behaviour

Electronic – I2C read/write failure under heavy interrupt load

Related Topic