i2c arbitration error...help!
Shawn Ransford
New Member Posts: 20 ✭
Hey all,
I am finishing a project for a client that utilizes i2c. I am using the mraa c++ library, but do not believe the library is at fault...I think it is the kernel i2c-dev code. After about 45 minutes of where I successfully write/read to my devices (5 sensors), I get this error in syslog...
kernel: [ 2941.297575] i2c_designware 808622C1:01: i2c_dw_handle_tx_abort: lost arbitration
I have tried rewriting the code in just about every way possible. Some Googling makes me think it is the kernel driver...and that is about the last "correction" I have left to attempt. I did get the latest mraa code and recompile in hopes it might help, but there were very little i2c changes since v1.0. I would share my code, but it is something higher level for sure. if I spin my wheels a little longer, I will write a simple routine to demonstrate. I am hoping someone else has run into this issue and has a fix.
My next thought is to compile the kernel driver... which has undergone some revisions. I assume I am not the first guy to use i2c on their up board for more than just a simple test. I need to continually request/read from these sensors without failure. All thoughts or help would be greatly appreciated!
Edit: Looks like this guy likely had the same problem...and never got a response...not good!
https://up-community.org/forum/public-upboardhw/1032-i2c-communication-stops-after-a-certain-time
I am finishing a project for a client that utilizes i2c. I am using the mraa c++ library, but do not believe the library is at fault...I think it is the kernel i2c-dev code. After about 45 minutes of where I successfully write/read to my devices (5 sensors), I get this error in syslog...
kernel: [ 2941.297575] i2c_designware 808622C1:01: i2c_dw_handle_tx_abort: lost arbitration
I have tried rewriting the code in just about every way possible. Some Googling makes me think it is the kernel driver...and that is about the last "correction" I have left to attempt. I did get the latest mraa code and recompile in hopes it might help, but there were very little i2c changes since v1.0. I would share my code, but it is something higher level for sure. if I spin my wheels a little longer, I will write a simple routine to demonstrate. I am hoping someone else has run into this issue and has a fix.
My next thought is to compile the kernel driver... which has undergone some revisions. I assume I am not the first guy to use i2c on their up board for more than just a simple test. I need to continually request/read from these sensors without failure. All thoughts or help would be greatly appreciated!
Edit: Looks like this guy likely had the same problem...and never got a response...not good!
https://up-community.org/forum/public-upboardhw/1032-i2c-communication-stops-after-a-certain-time
Comments
-
I think I found a workaround! I disabled the option in the bios for PMIC ACPI. I have now been running without i2c failure all day
-
Well, It died again overnight. Lasted much longer, but I am still in need of a fix! Looks like it lasted a mere 8 hours after my last recompile. If it could at least go 24 hrs, then I could schedule a midnight reboot as a "fix" and patch later.
Any chance Ubuntu is a better or at least more widely used choice? -
Installed Ubuntu yesterday...same issue! Shouldn't surprise me though...same kernel, etc.
-
Are you using long wires to connect your I2C device?
Is it in an electrically noisy environment? -
No wires...board is directly attached using pi header. Each of the devices are isolated as well.
I just found a series of settings in the bios...that I swear were not there last time I looked. Would the bios have been updated at some point automatically? It has definitely changed. Regardless, I am adjusting those settings to see if they make a difference. First is i2c bus speed...went down to 100hz and I have now been running almost 10 hours...hadn't gotten that far before (the device can support up to 400hz, but worth a try). Any other bios settings of interest? Any other devices that could create a conflict on the kernel side?
Thanks for the quick response! All thoughts are greatly appreciated. -
Can you send us a script to replicate the issue?
-
It looks like I might have a workaround. I changed the speed on the bus to 100hz...and it has been running for over a day :cheer:
