In arduino wire implementation everything is done correctly as far as I remember and one can always distinguish between those failures.

In the first two cases i2c is taken to a known state by resetting i2c, in the second case no reset required. At least this is my experience working with i2c. Then I can always distinguish 3 cases - hardware failure, i2c protocol failure or software protocol failure. The state of the i2c driver should be also checked either by looking at the state register or comparing software state variable to the expected state. For instance, before reading I always check is a byte(s) are waiting in the buffer - then there is no delay and I can do other things. Usually the code expects certain state of the I2C when a read is requested. I've put almost same lines in my interrupt-driven code for the pic24 (mini-bully) based ahrs. The lines found by Rz_Ten1 are there for a great reason to be a guard or a last resort. Let me hop on the bandwagon while this thread is still active :) I would like to see this fixed ASAP so we can eliminate this safety concern. Rz_Ten1 has offered to look into it more, but I thought we could coordinate the effort here. What we really need in the code is to know that the compass did not respond so we can do the right thing up higher in the code. While(TWI_MRX = twi_state & x 1000) return 0 wait until twi is ready, become master receiverīoth of those look pretty bad. Rz_Ten1 has a head start looking at the code here:Īfter a quick skimming, these lines in twi.c really stand out:

We can use this new code in the hex generation and possibly in our own distribution of Arduino, until the main Arduino branch adopts it. What we need is someone to write an alternative with the same functionality, with the addition of a timeout and error reporting. When it performs reads it 'blocks' execution of the code. The library at fault is a poorly designed I2C driver. Most SW issues in APM can be quickly reproduced since we literally run the same code 200+ times a second. His compass did not have the ground pin soldered leading to issues during flight and heavy vibration.Įven though HW was the issue, ultimately a software limitation of Arduino caused the APM to lock up. He was able to reproduce it, then narrow it down to a hardware failure. Rz_Ten1 was having some very strange crashes, and a few other users chimed in too once they heard his symptoms.

Arduino wire library internal register