I2C problems with ITG-3200 Gyro
I2C problems with ITG-3200 Gyro
by veltrop
Tue Nov 23, 2010 1:18 pm
I recently put an ITG-3200 gyro on the Roboard i2c and am having problems with it.
The ITG-3200 is a great gyro sensor, available here: http://robosavvy.com/store/product_info.php/products_id/941
Occasionally I get errors:
i2c0master_StartN() : "I2C0 module doesn't respond"
Then have to unplug it and plug it back in to make it work.
i2c0master_WriteN() : "receive no ACK after transmitting"
Can recover from this error by restarting the i2c in the software.
i2c0master_WriteN: "arbitration loss for I2C bus"
After receiving this error, sometimes I can restart in software and recover, but sometimes I get "I2C0 module doesn't respond" after.
The device is powered by 3.3v, and there are 10k pullups to 3.3v on the SDA and SCL lines. It makes no difference if other devices are plugged into the bus or not. I have tried 1.8k, 4.7k, 8.2k pullups also. There's a 1uf capacitor on the output of the 3.3v regulator. I don't have any problems with my other i2c devices. It doesn't help to lower the baud rate or change i2c speed modes. And it doesn't make any difference at what rate I probe the registers on the ITG-3200. Sometimes the device will run for more than 30 minutes or even an hour before problems, sometimes only seconds, but it always eventually dies.
After reading a thread here:
http://forum.sparkfun.com/viewtopic.php?f=14&t=24600
It seems like the problem could be fixed in code, but in the RoBoIO level. After peeking in the driver code there do indeed seem to be some suspicious workarounds, bugs and tweaks in the RoBoIO/Roboard/VorteX86 i2c implementation.
But I've just spent 3 days debugging this and can't dive in any deeper right now.
Any help?
The ITG-3200 is a great gyro sensor, available here: http://robosavvy.com/store/product_info.php/products_id/941
Occasionally I get errors:
i2c0master_StartN() : "I2C0 module doesn't respond"
Then have to unplug it and plug it back in to make it work.
i2c0master_WriteN() : "receive no ACK after transmitting"
Can recover from this error by restarting the i2c in the software.
i2c0master_WriteN: "arbitration loss for I2C bus"
After receiving this error, sometimes I can restart in software and recover, but sometimes I get "I2C0 module doesn't respond" after.
The device is powered by 3.3v, and there are 10k pullups to 3.3v on the SDA and SCL lines. It makes no difference if other devices are plugged into the bus or not. I have tried 1.8k, 4.7k, 8.2k pullups also. There's a 1uf capacitor on the output of the 3.3v regulator. I don't have any problems with my other i2c devices. It doesn't help to lower the baud rate or change i2c speed modes. And it doesn't make any difference at what rate I probe the registers on the ITG-3200. Sometimes the device will run for more than 30 minutes or even an hour before problems, sometimes only seconds, but it always eventually dies.
After reading a thread here:
http://forum.sparkfun.com/viewtopic.php?f=14&t=24600
It seems like the problem could be fixed in code, but in the RoBoIO level. After peeking in the driver code there do indeed seem to be some suspicious workarounds, bugs and tweaks in the RoBoIO/Roboard/VorteX86 i2c implementation.
But I've just spent 3 days debugging this and can't dive in any deeper right now.
Any help?
by veltrop
Wed Nov 24, 2010 9:59 am
I removed the 1uf capacitor and things have much improved. Strange, most i2c devices recommend one on the +v.
Unfortunately, the values from the HMC6343 IMU unit float around a little bit more without the capacitor; +/- 0.3 as opposed to +/- 0.1.
The bus "doesn't respond" after 260 minutes in the first test, had to cycle power of i2c device.
Next test failed after 7 minutes with "arbitration loss" but was able to recover by restarting software.
Next test failed after 350 minutes, "doesn't respond", had to power cycle i2c device.
Current test has been running over an hour with no problems yet.
So it looks good enough to use. I would like more stability though, and losing the precision on the other sensor is too bad.
Unfortunately, the values from the HMC6343 IMU unit float around a little bit more without the capacitor; +/- 0.3 as opposed to +/- 0.1.
The bus "doesn't respond" after 260 minutes in the first test, had to cycle power of i2c device.
Next test failed after 7 minutes with "arbitration loss" but was able to recover by restarting software.
Next test failed after 350 minutes, "doesn't respond", had to power cycle i2c device.
Current test has been running over an hour with no problems yet.
So it looks good enough to use. I would like more stability though, and losing the precision on the other sensor is too bad.
by roboard
Thu Nov 25, 2010 11:55 am
Hi,
when RoBoard's I2C fails to respond, you can call i2c_Close() and then i2c_Initialize() to reset RoBoard's H/W I2C module.
We are also trying ITG-3200 in our lab (for a new 9-axis RoBoard sensor), but not meet your issues. It is possible that your ITG-3200 board's I2C bus or power supply is not very stable; for this issue, you may try a much slower I2C speed (such as 1Kbps or 10Kbps) to see whether the ITG-3200 board works normally.
when RoBoard's I2C fails to respond, you can call i2c_Close() and then i2c_Initialize() to reset RoBoard's H/W I2C module.
We are also trying ITG-3200 in our lab (for a new 9-axis RoBoard sensor), but not meet your issues. It is possible that your ITG-3200 board's I2C bus or power supply is not very stable; for this issue, you may try a much slower I2C speed (such as 1Kbps or 10Kbps) to see whether the ITG-3200 board works normally.