I am using Due with MPU6050, and Wire with I2Cdev library. All works ok, but after a while, Arduino crashes. With an oscilloscope, I have tested that SDA is low and SCL is high when crashes occurrs. Then, I done a software reset, and with this lines in setup function all works again until the new crash:
pinMode(21, OUTPUT);
for (int i = 0; i < 8; i++) {
digitalWrite(21, HIGH);
delayMicroseconds(3);
digitalWrite(21, LOW);
delayMicroseconds(3);
}
pinMode(21, INPUT);
You may test your DUE with another peripheral module like: BMP180 (Barometric Temperature and Pressure Sensor) . It works fine with my DUE. To isolate faulty part, it is always a good idea to test the system with an alternative healthy part. The sketch (collected from net and compiled) is attached.
The DUE I2C interface (Sam3x8e) is somehow different from the one of an AVR chip. It expects you to set the stop bit in the control register before you send the next to last byte if you read several bytes, or at the same time you send the Start if you read only one byte. If you don't set the stop bit properly, the DUE will send an ACK instead of NACK on the last read.
You can try to write entirely the program sequence needed without any blocking code using TWI registers. For safety, you can consider having a reset line from the Master (DUE) to the sensor in case a reading can't be performed after a certain timeout.
I have only a short experience with this interface but I found it extremely sensitive to EMI, e.g. I did tests between two DUE (One in Master mode, the other one in Slave mode) and I had to use a very short jumper between grounds to make this work (no builtin glitch filtering). Workaround suggestion from dougcl :
If you have long I2C wires, and are not planning on interfacing more than one Due to your I2C bus, add a 200pF cap to ground on both SDA and SCL. This will take care of the glitches coming into your Due. Also consider 10 or 20 ohm series resistors between the Due and the bus. This will attenuate the glitches leaving your Due.
Furthermore, arbitration of the bus is performed internally by hardware and puts the TWI in slave mode automatically if the bus arbitration is lost. I wonder if this could be an issue too in case arbitration sets itself even though you are not using multi master mode.
Another issue is the recurring question of pull ups, SDA/SCL have builtin pull ups of 1K, and SDA1/SCL1 don't have any pull ups. You may want to use SDA1/SCL1 with 2K2 pull ups instead of SDA/SCL. Note that TWI0 is for SDA1/SCL1 and TWI1 for SDA/SCL.
Whence ATmega32A and ATmega328P have built-in features like: "Noise Suppression Circuitry Rejects Spikes on (TWI) Bus Lines" thence how could be that the SAM3X8E does not have it!
Having followed your post, I have gone through the detailed and summary data sheets of SAM3X, unfortunately I have not found any record of spike/glitch suppression in TWI bus.
However, I have successfully operated the BMP180 sensor on TWI bus using 18-inch long bus and GND wires without any additional filter circuitry; although the bus was originally designed for I2C (Inter-inter-circuit) operation.