Bug on WIRE.H library from Arduino

Projects Programming
21

SurferTim:
With a little testing, I think I found your bug. If either the SCK or SDA lines are held LOW by the slave, the I2C bus will crash the Arduino. Is that what you think may be happening? Do you have an o-scope to test with?

edit: If the SDA or SCK lines are resistive (I used a 1K resistor to ground) the arduino doesn't crash, but the I2C bus freezes.

The slave is allowed to hold SCL low. It is called clock stretching. That how the slave can slow down the master.
A misbehaving slave that asserts this improperly can cause problems.

Just like a misbehaving slave that asserts SDA when it's not supposed can also cause issues.
I have an i2c LCD module that only supports i2c writes. If you attempt to read from it, it seems to ignore the read/write bit/address and asserts SDA low on the end of a read which screws up the STOP and hangs the AVR wire library.

The only way to resolve something like this will be with a logic analyzer.

One thing that is also needed to know is what value resistors are being used on the SDA and SCL lines.
If external resistors are not being used, then all bets are off since the internal pullups inside the AVR are simply not strong enough and all kinds of odd things and issues can happen.

--- bill

22

I didnt try with MEGA, I dont have one. I just tried with UNO and NANO.

@bperrybap it's not a hardware problem, as I already said, I tried to run this code if other arduino (bought from another seller) and another MPU6050 (also from another more expensive seller) and the problem remains. I just tried right now to run the code in another computer cause a guy in another forum said it could be a problem with my USB port. I tried with another computer, installed ARDUINO IDE in it (WINDOWS 10) and after 40 seconds arduine froze.

Sometimes it takes almost 3 to 4 minutes to freeze, but it eventually will freeze. I dont have logic analyzer and even if I had I have no idea how to operate it. I just would like you to try the code in your arduino nano/uno and check the freezing.

I have no idea @bperrybap if I need to indeed use STOP, the code I provided in the top of this thread is a really simple code which is used as demonstration to use with MPU6050 by many people.

23

Did you try to run the code in your OP without the MPU6050 connected? Does it crash in that configuration also?

24

Before each call to endTransmission() and requestFrom(), you can add a call to the below function. If it returns false, do not attempt to do call to one of those.

Note that this only prevents the code from hanging; it does not solve the possible cause of your problems.

/*
  checks the I2C bus
  this function checks the SCL and SDA lines; if e.g. a device on the bus is not powered, some wire functions will cause the Arduino to hang
  returns true if bus OK, else false
*/
bool checkBus()
{
  // if both lines are low, assume the device has no power
  if (digitalRead(SCL) == LOW || digitalRead(SDA) == LOW)
  {
    Serial.println("Bus error");
    return false;
  }

  return true;
}

The Serial.println is only for demo.

25

Just out of curiosity, did you ever try any of the example sketches provided in the playground,like the short example sketch?
http://playground.arduino.cc/Main/MPU-6050

26

sterretje,
that checkBus() function would not show an issue if pullups were not on the bus on an AVR based system since the Wire library turns on the internal pullups. And while the internal pullups may appear to "work" in many cases, they are completely inadequate and hence also fail or create strange issues in many scenarios when in use with actual slave devices.

batata004,
You simply don't have enough information to be able to definitively say: "There is clearly a bug here".
At this point all that is known is that there is some kind of issue when that code is run in your environment.

It is very likely to be a hardware or h/w configuration problem, or at least likely to be an issue outside the Wire library and AVR 2wire h/w.
There are a lot of potential issues here, especially since there can be 3v and 5v level issues involved.

In your OP, all you said was to hook up power/gnd/SDA/SCL signals.
You have not fully described your actual h/w configuration enough to allow some one else to replicate your exact environment.

Many people have been asking for details & photos about your h/w but you have yet to provide the requested information.
See post #14

We still don't know something as basic as are i2c pullups being used on the bus and what value resistors are being used.

Hopefully this isn't a case of simply not using pullups on the bus.

I've seen cases where improper (missing or too weak) pullups can create a hung i2c bus.

And then there is a question of how any 5v to 3v mapping is being done.

Misbehaving slaves can also confuse the wire code & AVR 2wire h/w.
I have seen this and can demonstrate it,
I have an i2c lcd device that can lock up the Wire library if you attempt to read from it.
But the slave is incorrectly handling the i2c bus signals.
It treats the ACK/NACK as if a write were being done which confuses the Wire library and two wire h/w.

With misbehaving slaves it becomes a question of
how much robustness should be expected when bus signals are being improperly driven?
Ideally the Wire code probably shouldn't ever lock up, but there is only so much you can do and some of these conditions are extremely difficult to test since it requires intentionally stomping on the i2c signals in strange ways.

--- bill

27

It would be nice if any of you could run my code and say that it also hangs. I am not making any stupid error... the default codes from the MPU6050 library also has a bug and I reported it here http://www.i2cdevlib.com/forums/topic/488-serious-bug-with-jeff-rowber-library-to-use-with-mpu6050/ but nobody still replied. This is clearly a bug cause when I went to the MPU6050 library and setted a timeout the bug went away.

28

batata004:
It would be nice if any of you could run my code and say that it also hangs. I am not making any stupid error... the default codes from the MPU6050 library also has a bug and I reported it here Serious bug with jeff rowber library to use with MPU6050 - MPU-6050 6-axis accelerometer/gyroscope (InvenSense) - I2Cdevlib Forums but nobody still replied. This is clearly a bug cause when I went to the MPU6050 library and setted a timeout the bug went away.

Just wow.
You want us to run your code and yet you have never provided the details of your environment to allow others to replicate it.
I'm out...

--- bill

29

You are running an Arduino Uno without level shifter to an MPU-6050 ? That is outside the specifications of the ATmega328P microcontroller (used in Arduino Uno and Nano). If you powered a module with voltage regulator with 3.3V, then it is even worse. We have a good reason to keep asking what your hardware, wiring, sketch, and so on, is. We have seen lots of these problems before on this forum.
I'm out as well...

30

I ran your code last night for about 10 minutes against the DS3231 (I don't have a MPU6050) without any hangs.

the default codes from the MPU6050 library also has a bug
[/code]
Why? Did it not compile?

I'm not much of a C++ programmer, but I had a look at the M{PU6050 and I2Cdev code and it makes sense to me. As far as I know, the readTimeout value can be omitted because there is a default value specified in I2Cdev.h

        static int8_t readBytes(uint8_t devAddr, uint8_t regAddr, uint8_t length, uint8_t *data, uint16_t timeout=I2Cdev::readTimeout);