i2c Write Issue

[PhilColbert]

Attaching a ms5611 ( GY86 ) to the esp32 on i2c - works perfectly for about 5-10 minutes - some strange values do come in however it seems to work pretty well.

Then loads of

[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 77

Board needs to be reset to start again

Any ideas?

Thanks

[atanisoft]

seems similar to #811 or #741.

[PhilColbert]

Yes, seems so :( Just wondered if anyone had a solution yet !? :)

Seems strange this has only come up now, surely theres a lot of people that use i2c on the esp32 !

[lonerzzz]

@PhilColbert No solution as of yet. @stickbreaker and myself have been working it. The latest code that I submitted increased the timeout, but there appear to be hardware timing issues that need to be adapted in software. At the same time, @stickbreaker is working to add interrupt based handling to better meet the timing needs. So far it is slow going as we are dealing with a chip having a number of hardware defects and a poor interrupt handling design.

I also added code for resetting the I2C subsystem. I have been running this code for weeks with it being able to recover; it is just avoiding the errors in the first place that is more problematic.

[PhilColbert]

Is it possible to try this code that allows reset ? :)

Thanks

[josmunpav]

I am getting an issue with my MCP7940 (RTC) that constantly is saying this annoying message:

[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 6f.

The only "fix" is to be all the time resetting the I2C protocol in order to access to my device. I am only accessing this device about once a second but in my product will be another I2C device using the bus far more often.

Pullup resistors for SDA and SCL lines are 4.7K. Tried with several frequencies up to 400KHz which is the maximum supported by the MCP7940. All behave the same so I am not sure what is the problem.

Any ideas what is going on? Btw I am using multiple core tasks (one for WiFi/web server, another for logic), no Bluetooth

[stickbreaker]

Look thru the code library that you are using. If it uses Wire.endTransmission(false); or Wire.requestFrom(id,length,false); You are probably running into this timeout issue because of a task switch. @lonerzzz and I are attempting to create a solution.

The current Wire() library implements the ReSTART I2C operation by just pausing the I2C operation. If the I2C operation is not resumed within a small fixed window, the I2C hardware explodes with a TimeOut Error. The method I am currently working on queues Wire() operations until a STOP is encountered. Then it executes all of the I2C operations in one continuous sequence. I am hopeful that I will have a ALPHA version available for testing in the next week or two.

It is enough different than the Wire() library standard that I suspect adoption by espressif/Arduino-ESP32 will be difficult. I don't have all I2C devices to test it against. So my Limited subset of compatibly testing may be judged inadequate.
But, I'm having fun building it! 😀

Chuck.

[atanisoft]

@stickbreaker, when you have it ready I can test on a few I2C devices as well (LCDs and OLEDs are what I have now)

[PhilColbert]

Thanks for the work ! I have a few different i2c devices so can test aswell.

[stickbreaker]

@atanisoft @PhilColbert @josmunpav try my fork at stickBreaker:arduino-esp32
It should solve your problems, Or your money Back! 😀

Chuck.

[jlhavens]

I am very appreciative of your efforts on the I2C front, but having tried your library I may be requesting a partial refund. The ESP32 problem I have encountered is simultaneously using I2C and WiFi . In particular, I am using an ADS1115 and BMP280 while accessing the data over the internet. Initially, everything is fine, but after 1-4 hours the I2C stops working correctly--when one I2C device fails the other does too. I tried all kinds of power supply remedies without success, and eventually found other users reporting I2C problems. I tried a couple different 'reset' routines, and they might work a couple times, but eventually that recovery failed, too. The problem remains unresolved.

Anyway, since I had a GY521 on a breadboard I tried your modified library on that. The code I am using is basically from Section 4 ('readings that make sense') of https://olivertechnologydevelopment.wordpress.com/2017/08/17/esp8266-sensor-series-gy-521-imu-part-1 . When I compiled and ran the code I got consistent readings, but they were incorrectly factored. The easiest to understand are the AcX , AcY , AcZ which should add to 1 g (gravitation unit) (like AcX = 0.98 g| AcY = 0.02 g| AcZ = -0.01 g), but mine added up to 0.25 g like (AcX = 0.24 g| AcY = 0.01 g| AcZ = -0.01 g). Using the standard ESP32 core and libraries, I got the correct scaling so I didn't make any effort to trouble-shoot the problem.

I'm not asking you to solve this particular problem. I've made this comment to let you know there are people out here who are appreciative of your efforts and hoping they will solve our problems. This is just one data point that 'might' indicate some issue with writing to the device.

Thanks, Jeff.

[stickbreaker]

@jlhavens are you running under arduino?
this code is designed to give debug output when it fails, in order to see this output, you have to select board as "ESP32 Dev Module" and set the "Core Debug Level:" to "Error"

If you could do this and post a capture of the debug output it would be helpful.

thanks,

Chuck.

[stickbreaker]

@jlhavens Did you notice any difference between the mainBranch Arduino and my code? Did they both fail about the same amount or at the same time?
Reports of any differences would be valuable.
Chuck.

[stickbreaker]

@jlhavens on the timeout: Are you are getting a "Gross Timeout Dead" on the console? I may have been too optimistic on my ISR timeout, I only allow a calculated (bit rate based)+50ms for the I2C transactions to be completed. If this is your Error message it is easy to fix.
But if the timeout is the I2C bit timeout that will be harder. The I2C hardware will only allow upto 13ms before it triggers a hard Timeout. Currently I have if configured to the max.

[jlhavens]

I'm sorry, I should have realized that you are a lot more interested in a report on the results of your efforts to improve stability than what is probably a lesser glitch in the implementation of a particular sensor.

I didn't really allow this to run until the I2C issue occurred. When I didn't get the correct results, I let it run a couple minutes and went on to something else. Sorry. Taking a closer look at the data I see that the raw data (sensor reading) is the same when using both your and the standard libraries. The program both sends the scaling factors, and reads them back later, every loop through. The received scaling_factor values are used to scale the raw data and those are different in the two environments. Since the raw data is the same in both environments but the read back scale factors are different, I would guess that the reading back the scale factors is amiss. This is the code:

Set in loop() -------- setMPU6050scales(MPU_addr, 0b00000000, 0b00010000);

void setMPU6050scales(byte addr, uint8_t Gyro, uint8_t Accl) {
Wire.beginTransmission(addr);
Wire.write(0x1B); // write to register starting at 0x1B
Wire.write(Gyro); // Self Tests Off and set Gyro FS to 250
Wire.write(Accl); // Self Tests Off and set Accl FS to 8g
Wire.endTransmission(true);
}

void getMPU6050scales(byte addr, uint8_t &Gyro, uint8_t &Accl) {
Wire.beginTransmission(addr);
Wire.write(0x1B); // starting with register 0x3B (ACCEL_XOUT_H)
Wire.endTransmission(false);
Wire.requestFrom(addr, 2, true); // request a total of 14 registers
Gyro = (Wire.read()&(bit(3) | bit(4))) >> 3;
Accl = (Wire.read()&(bit(3) | bit(4))) >> 3;
}

Sending Gyro = 0x00 Accl = 0x10
Reading back Gyro = 0x10 Accl = 0x00 in your environment (incorrect scaling)
Reading back Gyro = 0x00 Accl = 0x10 in normal environment (correct results)

Sorry, none of this answers any of your questions.

I will set the system up again with the "Core Debug Level:" to "Error" and see if I can capture an error message. I have output going to the serial monitor and assume that the error output will go there?

I'll let you know how it goes.
Jeff

[jlhavens]

I didn't mention. I got some compiler warning and have cut and pasted them into
CompileWarnings.txt