Wire library bug - Crosstalk between peripherals

I have run into a real strange bug (feature?) in the wire library. Right now, I'm still in the process of trying to define what exactly I'm running into, but I curious if anyone else has run into this.

I have running a 'radar' setup with a couple of pwm channels sweeping a servo and a VL53L0x sensor controlled by I2C on pins 20 and 21. In separate sketches, I send serial data out to a processing sketch or I send data to a SSD1131 OLED display through SPI. Both sketches share the sweep and sensor routines.

The sketch with the OLED display, which is connected up to the SPI port, will run for hours on end (the radar has a 12 s sweep cycle). At sometime (when it is not being watched) the DUE locks up and the display goes blank. The lockup CANNOT be cleared with the reset button, you have to power cycle the unit. Can an intermittent I2C connection cause a lockup? (The sensor rotates back and forth. I have tried to play with the sensor wiring to trigger this fault but have not been successful). Cound this be a buffer overflow problem that doesn't occur with one incident but is the result of multiple misses?

The second manifestation of the bug is stranger but starts to leave a trail. The other sketch sends the sensor data out the serial port into Processing. Being lazy, I leave the OLED display connected to the SPI port even though this sketch doesn't use it at all (This could be part of the problem). After about thirty minutes of running, the normally blank OLED comes to life with trash on the screen... and the system locks up. As the OLED display library is not even loaded in this sketch, some issue with the TWI subsystem is spilling over to the
SPI port, causing it to spit out random garbage.

While the radar is running, The VL53L0x is set for continuous mode. It pulls its GPIO line low when data is ready to be read. The DUE read the signal and triggers an interrupt. An ISR reads the sensor data, updates servo position, sends the data out the serial port, and resets the sensor interrupt. Rinse and repeat. I put in a diagnostic LED that lights when the ISR is entered and is extinguished in the main program loop. I have yet to see the case where the unit is locked and the LED is lit, but I am not excluding it.

Something else to mention is that the VL53L0x data output is asynchronous. You specify a timing budget and the sensor takes the budget as a mere guideline. The time between successive data reads varies depending upon whether an object is in range (longer) or out of range (shorter). In both sketches, the diagnostic LED blinks showing that I'm exiting the ISR with time to spare. While cycling, the VL530L0x I2C traffic consists of two byte read and a single byte write. The read/write routines do not have error checking incorporated, it may be needed in this case.

Again, right now I'm just trying to define the problem.

Let's start with that I doubt the library has a major bug like that. But I'm not that familiar with the Due.

Couple of notes, if a "lock up" can only be reset by a power cycle the problem isn't in the Arduino but in the screen. Might have entered a incorrect mode when the bug happened.

If the SPI isn't initialized the SPI pins are just floating. So yeah, they can just pick up all sorts of random noise.

And all that radar stuff isn't really something for an interrupt.

xuthus:
An ISR reads the sensor data, updates servo position, sends the data out the serial port, and resets the sensor interrupt.

Is A LOT for a ISR and I think you can just do it in loop :slight_smile: