IntervalTimer causes I2C from Wire library to fail

[rtcollins14]

Sorry that I am unable to post code, I just can't find enough information to be able to understand the current issue. I am using a Teensy 3.2.
I am calling for an interrupt ever 500ms to modify an LED array. in between the modifications, I am reading 30 sensors via I2C using the Wire library. The sensors read perfectly when the interrupt is off, but the clock line is pulled high and the data line is pulled low after a few seconds when the interrupt is enabled.
Based on what I saw on the o-scope when reading data, it looks like the data drops out mid-read of the sensor due to the interrupt being triggered.
I read that the Teensy 2.0 uses the Wire library as an interrupt, while the 3.0+ do not; is that correct? If that's the case, then I can see why the LED updates would happen mid-read. If there is any documentation regarding the Wire library pertaining to the Teensy 3.2, I would love to read through that. Also, I did try the i2c_t3 library and got the same results.

Thank you

 

[tonton81]

Not saying this is a solution or not, based on just test you could try to modify the NVIC register of Wire to be higher priority than interval timer, it worked for me using SPI interrrupts, stopped Wire from crashing

NVIC_SET_PRIORITY(IRQ_I2C0,x);

“x” being the priority of I2C0, 0 being highest, 255 being lowest
you can try that and see if it helps

 

[defragster]

If your loop() is running not doing much else an elapsedMillis variable could be used - at least as a test to not use the interrupt. It is possible the interrupt is doing too much - taking too long in preparing the data change? Or doing something interacting with the running code - like changing the data in use or an outside function call. It won't be as demandingly clocklike - but also won't interfere with an update in progress or the i2c I/O.

elapsedMillis foo;

setup() {
  // set initial LED values
  foo=0;
}

loop(){
  // do stuff
[B]  if ( foo > 500 ) {
    // update LED data
    foo=0;  // alternative is: foo -= 500;
  }
[/B]}

If you were adventurous the BOLD code could be made a function() you could call anytime - between i2c calls if desired so the timing would not be delayed too much.

 

[PaulStoffregen]

This might be a bug in the Wire library. Or it might be something wrong in your code. I do not know.

But I can tell you with certainty that no investigation will happen until you post a small but complete program which demonstrates the problem. Info about the sensors would also be needed. Ideally a test program would read just 1 sensor 30 times. I do have a small budget to buy sensors & other hardware where there is a chance it will lead to finding and fixing any bug in Wire or other widely used libs. But that work can't even begin without a test program.

 

[Frank B]

I am calling for an interrupt ever 500ms to modify an LED array. in between the modifications, I am reading 30 sensors via I2C using the Wire library.

perhaps 500ms are not enough time to read all the sensors? i2c is not that fast when using the default speed. depends on your code and the amount of data..
what happens if you increase the interval to 1 sec? or, maybe, it's a bug in your code. most likely.