I2C read/write failure under heavy interrupt load

Question

In my system, I am using I2C and I realize under heavy interrupt load (from other sources), I2C communication is easily disrupted. Is this expected behavior for I2C? I would have expected despite interrupt load, it would still be ok since I2C is not exactly a time critical interface, clock is provided with data.

Update:

The processor is STM32. The interrupts are due to ADC, I cannot disable interrupts during the read events therefore I must find a solution where I can make the i2c communication more stable. The STM32 is master and the slave is another device (accelerometer).

Update2:

When I connect a logic analyzer to the clock with a small flying cable, the problem disappears. Interestingly, there is no interrupt load, read write works well, when there is interrupt load, they don't. However, if I attach the probe to the clock, read write works under interrupt load as well. I think, there is a capacitance issue somewhere.

Answer 1

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.

Answer 2

A bus slave that's busy with other things has the ability to clock stretch to buy time until it's able to carry on its end of the communication. It does this by not immediately sending the ACK / NACK clock pulse, keeping the communication in an intermediate state until it's ready to answer.

Clock stretching is the appropriate way to deal with this sort of situation. A device that doesn't stretch and does other bad things (bus hang / restart, NACKs a valid address or command, etc.) can be problematic, and puts extra burden on the master to keep things sorted out (it has to repeat commands, keep track of NACKs, etc.)

Answer 3

Depending on the capabilities of the STM32 (I have never used one), you could try one of the following approaches. If you can provide more detail about what you are trying to do, and have a convincing argument about why each interrupt is necessary in the form you have it now, then a more specific answer may be thought of. Specifically in your case, though, I2C is slow enough for this to not be a problem with well written interrupt routines.

• Interrupts for anything can usually be disabled. There are at most one or two Non-Maskable Interrupts in any usual controller, one of which is reset. If you don't need interrupt driven control of something (ADC or I2C, in your case), then turn that peripheral code into one that doesn't use interrupts, and then disable interrupts.

• Interrupt handlers should not be long. Try to do as little as possible from the interrupt vector itself. The extreme minimalistic approach to interrupts is to simply set a flag from within the interrupt handler routine and have, say, the main loop do all the heavy lifting from there on in. What your specific application and firmware architecture requires may not be as simple as that, but it really is worthwhile to put in the effort to see how much really has to be done from within the interrupts.

• If you have peripheral DMA, use that instead of interrupting at each byte. Typically, it would be easier to put the ADC on DMA as opposed to I2C, but different chips have different implementations. I would not be surprised if there was a clean way to hive off an I2C exchange to the DMA as well. DMA allows you to reduce the number of interrupts and leaves your processor core free from having to deal with every single block of data.

• Try to identify the specific instances where you're seeing data corruption, and the mechanism by which the data corruption is happening. This is much harder to do, but with creative use of a modern oscilloscope / logic analyzer you may be able to see some of the problems. Specifically, make sure the problem has to do with timing and not memory (which is a possibility with a combination of terrible code and a liberal compiler)

EDIT : Some specific notes regarding this instance of the problem, from your comments on the question :

• Having 80% CPU used to read the ADC is usually not a worthwhile thing to do. Gathering data is useless if you can't act on it or even save the data.
• Even if you are somehow gathering (usefully) a huge amount of data, ADC interrupts should not be so long as to completely suppress the I2C peripheral for a time long enough to make it lose data. I2C runs at, at most, 100/400KHz. You'd need a really, really long interrupt to interrupt for long enough to make it look like something more serious than clock jitter on I2C.

Answer 4

In a given system, there could be noise entering the clock and data buses. The fact that your logic anlayser removes the problem shows this. For practical and quickest implementation, just follow the cue given by your observation. On an i2c bus with 400kbits/sec implementation, based on similar observation, I connected 2M paralleled with 12pf to ground from clock and data points and found that the problem is solved. This removes/filters noise outside the band of interest required for the specific i2c communication. Please try and advise.