I2C fails after upgrading to Arduino v2.0.2 #6674
Comments
|
You have a backtrace... Any information on that with the exeption decoder? |
|
@ivancmz - Based on the compilation errors you have reported, I think that it is is more likely an error of configuration of PlatformIO. Does the exactly same code work fine using Arduino IDE environment? Based on @ivankravets commentaries in the last Arduino Community Meeting of last week, PlatformIO for the Arduino Core 2.0.2 shall be released soon. I guess that as soon as PIO releases the latest version, this issue will be solved. |
SuGlider
added
IDE: PlaformIO
|
Hi, guys, Glad to inform you that the latest version of the ESP32 dev-platform is out with support for Arduino core for ESP32 v.2.0.2. Please update your local development platform. More information at https://piolabs.com/blog/news/platformio-oss-april-2022-updates.html |
|
@ivancmz - Please let me know if with the latest PIO Core version 5.2.5 this issue can be closed. |
VojtechBartoska
added
the
Resolution: Awaiting response
|
I updated platformio yesterday, and all of the libraries I use, now i2c fails to work, where it worked before the updates were applied. Everything compiles and works fine in the Arduino ide. According to my scope the clock line is not running, after using Arduino ide it's operating as expected. |
|
Maybe reinstalling PlatformIO may solve this problem with it... If not, please open an issue at their GitHub. |
|
I make a bet there are left overs from old versions in the Platformio setup. |
|
@i164j9, could you run |
|
i ran the upgrade and pio pkg list: in addition to that i use the MPU6050 library by jeff rowberg Tested with the dev version. Same result when the code executes it hangs in the mpu6050 library in the initialize() and does not go any further than the first line in the method setClockSource() As mentioned earlier it compiles and runs fine with the Arduino ide, I am going to blow away the installation and start fresh to see what happens. blew away the installation of platformio and vscode and still no change maybe i missed something, but nothing changed. still compiles and uploads but no clock output. Arduino IDE(1.8.19, 1.8.13). works |
|
Thanks for the provided information. If the same simple project works with Arduino IDE and does not work with PlatfomIO, we should investigate it on our side. We've just reopened platformio/platform-espressif32#786 . |
|
@ivancmz Are you by any chance using multiple threads (tasks) and concurrently accessing the Wire library from them at the same time? If you could also decode the backtrace you have provided, there is a PR over on platform-espressif32 that may help fix the backtrace decoding within PIO (@ivankravets it would be great to include the fix as it appears PIO monitor is responsible for dropping spaces). |
|
I don't have multiple threads, and I have no backtrace. There is no crash happening. It just halts. It's not hardware I have tested across 5 boards with the same configuration and get the same results. My first thought was hardware, then I thought I hosed my code... Went through and disabled all my new code. Still nothing worked. So I created a new project with new hardware and implemented minimal code to run a gyro (MPU6050, GY-521) and even that didn't work So I pulled the silly scope out and behold the surprise of no clock output, so I moved through 4 brand new boards, and two other development boards with the same result. Then moved on to testing with the Arduino IDE and life was good again. So I started thinking about what I had done. I thought about the updates I applied yesterday, everything worked fine before and now I have failure. So now, the only logical source of the issue is the software update. Only thing that changed that makes any sense to me. |
I'm sorry I haven't been able to work on this. I'm gonna try it today. Is there any way I can backup my PIO Core/configuration and everything before updating so I can go back in case of a problem? |
I've had some issues too over the past week - I2C was working fine, then after some casual auto updates of platform io upgrading, I ended up venturing into a black hole of assuming it was my fault - which is pretty shit when you have years of experience and really want to get to the bottom of what went wrong. I2C code to speak to MPU6050 is definately f*cked.... I2C scanning works, but can't send data to it.... Just freezes on requesting data. Tried different ESP32's and different MPU6050's - Houston, we have a problem. Added some debug out to the libraries, to see where it was going wrong. My test debug log: Key: BT=begin txn WR = write, ET=end txn, RF= request from.... freeze! sda=21, scl=22 MPU6050 init Wire@3ffc13d8, I2C scan sees device as 0x68... Used a scope to test SDA and SCL - they seem okay -- and besides, how can the I2C scan see the device?? Really weird. For anyone else who has similar issues, I found these issues that helped me figure out the resolution: #6674 The bottom line: Upgrade PIO to the latest dev version: pio upgrade --dev Then change platformio.ini platform = [email protected] |
I can confirm this works, providing you add to your platform.ini: I hope it helps others - I have been baffled for a week (not full-time on it, but elapsed) |
|
I can confirm that changing platform.ini Aside from the platform upgrades and such maybe I am mis understanding but it sounds like the issue lies with the MPU6050 library that's being used? I am lacking the experience but slowly learning and maybe one day I'll get gdb to play nice and be able to dive deeper into issues like these. Thank you for the resolution / workaround for this. |
|
@cdluv the problem is probably wrong use of Wire API in the library for MPU6050. I2C works fine, but requires code to be sane. Unfortunately we found out that some libraries out there do not conform to the official API and cause issue on newer Arduino cores. |
I'm using a DFRobot FireBeetle with a Wroom-32U ... that doesn't sound new to me? The library was written by Jeff Rowberg - it's been around for years - any suggestions on what causes this issue, and I'll contribute towards a fix. It worked before, on older hardware. Don't understand what changed. |
It's not the ESP32 that is a problem here, it is the library that implements the MPU6050 interaction.
Can you share a link to the specific library? It is very likely a simple coding bug in the library where it is not checking return codes which may indicate a failure condition. |
|
I debugged the library - the error was when waiting for data to come back.
The library is i2cdev.cpp (v 0.5.0)
This is the line that caused my ESP32 to hang:
Wire.requestFrom(devAddr, (uint8_t)(length * 2)); //
length=words, this wants bytes
For context:
// Arduino v1.0.1+, Wire library
// Adds official support for repeated start condition, yay!
// I2C/TWI subsystem uses internal buffer that breaks with
large data requests
// so if user requests more than BUFFER_LENGTH bytes, we have
to do it in
// smaller chunks instead of all at once
for (uint8_t k = 0; k < length * 2; k += min(length * 2,
BUFFER_LENGTH)) {
Wire.beginTransmission(devAddr);
Wire.write(regAddr);
Wire.endTransmission();
Wire.beginTransmission(devAddr);
Wire.requestFrom(devAddr, (uint8_t)(length * 2)); //
length=words, this wants bytes ************** HANGS HERE *****************
bool msb = true; // starts with MSB, then LSB
for (; Wire.available() && count < length && (timeout == 0
|| millis() - t1 < timeout);) {
if (msb) {
// first byte is bits 15-8 (MSb=15)
data[count] = Wire.read() << 8;
} else {
// second byte is bits 7-0 (LSb=0)
data[count] |= Wire.read();
#ifdef I2CDEV_SERIAL_DEBUG
Serial.print(data[count], HEX);
if (count + 1 < length) Serial.print(" ");
#endif
count++;
}
msb = !msb;
}
Wire.endTransmission();
}
…On Tue, 10 May 2022 at 14:11, Mike Dunston ***@***.***> wrote:
DFRobot FireBeetle with a Wroom-32U ... that doesn't sound new to me?
It's not the ESP32 that is a problem here, it is the library that
implements the MPU6050 interaction.
The library was written by Jeff Rowberg
Can you share a link to the specific library? It is very likely a simple
coding bug in the library where it is not checking return codes which may
indicate a failure condition.
—
Reply to this email directly, view it on GitHub
<#6674 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA534DWO334HPDPYULVW4M3VJJOBPANCNFSM5UZ3FAFQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sure, it's this one: |
|
Try commenting out A better implementation would look closer to: https://github.com/kriswiner/MPU6050/blob/master/MPU6050Library/MPU6050.cpp#L372-L375. This doesn't have a lot of error checking in it but it should also work on the ESP32 correctly. |
|
Awesome! It worked! There were a couple of places which needed fixing
up, but yeah, thanks for highlighting that! I'll push up a PR to fix that
library shortly.
…On Tue, 10 May 2022 at 14:36, Mike Dunston ***@***.***> wrote:
Try commenting out Wire.beginTransmission(devAddr);. It is very likely
hanging due to this invalid usage pattern which is very common across
libraries. The call to Wire.endTransmission(); should also be adjusted to
Wire.endTransmission(false);.
A better implementation would look closer to:
https://github.com/kriswiner/MPU6050/blob/master/MPU6050Library/MPU6050.cpp#L372-L375.
This doesn't have a lot of error checking in it but it should also work on
the ESP32 correctly.
—
Reply to this email directly, view it on GitHub
<#6674 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA534DUPSRPNYCCZ4MTJ2G3VJJQ7JANCNFSM5UZ3FAFQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Great, glad that it was a relatively simple fix. This is just one example of an invalid usage pattern that has been exposed by tightening the validations as part of migrating to ESP-IDF I2C APIs. There are likely going to be more. |
|
The problem is that many libraries have code like the one below, which is invalid. Wire.beginTransmission and Wire.endTransmission should be used only for Wire.write and never for Wire.requestFrom // Invalid Code
Wire.beginTransmission(addr);
Wire.write(reg);
Wire.endTransmission();
Wire.beginTransmission(addr);
Wire.requestFrom(addr, 2);
Wire.read();
Wire.endTransmission();
// Valid Code
Wire.beginTransmission(addr);
Wire.write(reg);
Wire.endTransmission();
Wire.requestFrom(addr, 2);
Wire.read(); |
|
@atanisoft @me-no-dev Sadly there are many bad (wrong) i2c librarys "in the wild" out there. We had to fix some we use for Tasmota too. For some we wondered the ever worked... |
|
@Jason2866 sadly that is the case and we are the first to end up having to deal with it. Somebody eventually had to, if we are to stick to that API and work in multithreaded environment. Hopefully it will all come to pass soon. |
|
Guys, this discussion is way far from the original issue open by @ivancmz. |
@Jason2866 or anyone else - can you help on it? |
Yes, when using setting |
|
I am currently having an issue where I can not compile after upgrading to the latest PlatformIO version of the ESP32 platform. I am also getting While I attempt to compile. Was a solution found other then using the older version of the plugin? |
|
@wgaylord something is not updated, because that code no longer exists here (where you are getting compilation errors) |
|
The |
|
@atanisoft with the latest release it will not error if you disable hal locks. Code referenced above is old. |
Right, it last existed in 2.0.2 which PlatformIO is packaging in their version 4.2.0 (latest tagged release). The only workarounds would be not to disable that flag or override the arduino-esp32 version picked up to 2.0.3 via platformio.ini. |
|
Did update and upgrade: The issue is still there: I've also checked out I2C library and corrected it as indicated by @me-no-dev (and tested it with platform-espressif32 v3.5.0) so this is not the cause either: |
|
I have managed to decode the backtrace: This is the supposed offending code (I2C.cpp:53): Any suggestions? |
|
That is actually the code that is executed after whatever other code did not use Wire properly. In your previous message you see in the logs that Wire was not able to acquire the lock, so naturally was not able to later release it (and that caused the exception+backtrace). What else is using Wire on your code? Maybe missing |
|
That particular function is missing the Wire.endTransmission()... I have added it, and checked all the rest, but still no progress. This is the only class that uses Wire: Testing in v3.5.0 to make sure I haven't broken anything and that last Wire.endTransmission() does make the reads from the RTC fail. |
|
Your read functions are wrong. They need to be: bool I2C::Read(uint8_t slaveId, uint8_t size, uint8_t buffer[]) {
size_t res = Wire.requestFrom(slaveId, size);
if(res == 0)
return false;
for(uint8_t i = 0; i < size && Wire.available(); i++)
buffer[i] = Wire.read();
return res == size;
}
bool I2C::Read(uint8_t slaveId, uint8_t address, uint8_t size, uint8_t buffer[]) {
uint8_t i = 0;
size_t res = 0;
Wire.beginTransmission(slaveId);
Wire.write(address);
if(Wire.endTransmission()==0)
{
res = Wire.requestFrom(slaveId, size);
if(res == 0)
return false;
for(; i < size && Wire.available(); i++)
buffer[i] = Wire.read();
}
return res == size;
} |
Thanks @me-no-dev, I've made the changes and tested it in v3.5.0, it worked fine, so I went back to try v4.2.0, but it keeps failing. On the same line where |
|
huh? the code above is good (with the changes I gave you). There is no reason for this to happen. uhmm... |
Yeah, this whole project is a mess...
I modified some of the classes to do a kind of "lazy initialization", and I2C is now working. So I can confirm that the issue had to do with the I2C being initialized on a ctor. Question remains on why did it work fine until now. I'm seeing now a whole lot of other new issues with WiFi, http server and client.... I'll stick to v3.5.0 for now. Thanks to @me-no-dev and everyone for your time and effort. |
This was the issue!!! I fix the code in few places (not all yet) and works! Best tip ever. |
Board
Custom board ESP32
Device Description
Not relevant
Hardware Configuration
Not relevant
Version
v2.0.2
IDE Name
PlatformIO
Operating System
Windows 10
Flash frequency
40
PSRAM enabled
no
Upload speed
115200
Description
Just upgraded a working project from platform-espressif32 v3.2.1 to 4.2.0 (Arduino v2.0.2) and the fw wont even start. See error below related to I2C lock.
I removed the I2C initialization and calls and the firmware starts working again, so it's confirmed that the issue is on I2C.
I also tryed disabling the locks by adding -DCONFIG_DISABLE_HAL_LOCKS to platformio.ini but now it won't compile:
Sketch
Debug Message
The text was updated successfully, but these errors were encountered: