i2c Write Issue #834
Comments
|
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 ! |
|
@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. |
|
Is it possible to try this code that allows reset ? :) Thanks |
|
I am getting an issue with my MCP7940 (RTC) that constantly is saying this annoying message:
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 |
|
Look thru the code library that you are using. If it uses The current It is enough different than the Chuck. |
|
@stickbreaker, when you have it ready I can test on a few I2C devices as well (LCDs and OLEDs are what I have now) |
|
Thanks for the work ! I have a few different i2c devices so can test aswell. |
|
@atanisoft @PhilColbert @josmunpav try my fork at stickBreaker:arduino-esp32 Chuck. |
|
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. |
|
@jlhavens are you running under arduino? If you could do this and post a capture of the debug output it would be helpful. thanks, Chuck. |
|
@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? |
|
@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. |
|
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) { void getMPU6050scales(byte addr, uint8_t &Gyro, uint8_t &Accl) { Sending Gyro = 0x00 Accl = 0x10 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. |
|
I didn't mention. I got some compiler warning and have cut and pasted them into |
|
In order to test on a target I knew had a history of failing, I compiled the software known to run for a while (usually a couple hours) on my real target using your library. It crashed after a few seconds. The setup has an HM10 on HardwareSerial(2) , BMP280, ADS1115, and a DS18B20. The DS18B20 and (BMP280 and ADS1115) are each running in separate tasks pinned to core 1. The DS18B20 runs alone just fine with WIFI. Each task takes new reading at about 1 second intervals. It is reading the sensors and sending results over WIFI on a page that calls for an update every second--so the WiFi is regularly getting hit. The data that I got seemed to be fairly correct, but a few fliers. The software sends the data to the serial port only when a WiFi update is requested. I sends a '.' to serial every time the data updates whether it is sent out on WiFI or not. I typically got 1-10 readings before an error was thrown. If the WIFI isn't calling for data, it seemed to go without error for quite a few data updates-- a long row of dots. I didn't run this to failure with the WiFi not calling for data, but it went about 20 minutes without error while I was writing this message. I've sent a chunk of output in It shows the output and Gross Timeout Error is seen frequently. Every once in a while it has some data (1-10 readings at 1 second intervals) that looks like this I included so much data in case there is something to see when it first threw the error compared to the subsequent error cycle. Hope this is helpful. Jeff |
|
@jlhavens that top line:
is saying that the xTaskTick was 2492 when the ISR was started, and xEventGroupGetBits() returned at As a fix increase the timeout for the ISR at line 1592 in esp32-hal-i2c.c Chuck. |
|
@jlhavens Those compiler warning are all my fault, This code is dirty. Before we release it they will all be fixed. Chuck. |
|
@jlhavens error = 6, is timeout DumpInts [01] shows the txEmpty IRQ (0x0002) fired once (0x0001), and moved two bytes (0x0002) into the fifo. I think increasing the Gross Timeout would eliminate this cascade. Chuck. |
|
@jlhavens Looking at the code, The ISR was in it's exit stage but yielded when it called Definitely, a O/S task switch issue. Increasing that Gross TimeOut should resolve it. in a reply to: #844 I said this:
But, based on your error Report, the Yield happened during the xEventGroupGetBits(). Not after it. So commenting out the following yields would not have any effect. I'll have to look a the xEventGroup timeout, maybe loop again? I don't know how to release/return to the ISR. I would expect the ISR to have higher priority than the Main Loop(i2cProcessQueue)? Chuck. |
|
@jlhavens @lonerzzz @me-no-dev More Research, changed conclusion. Page. 311 of FreeRTO_Reference_Manual_V9.0.0.pdf So, the Bits were Never set. So, the TimeOut is guaranteed. I'm going to recode the exit to test Chuck. |
|
@jlhavens attached is a modified esp32-hal-i2c.c that may work around this issue. Can you please try it. It looks like your code explodes with out any delay. ReCreating failures is always the hardest Part. Chuck. |
@jlhavens in [espressif#834 of espressif/arduino-esp32](espressif#834) is encountering some issues that could be related to a FreeRTOS Timer Daemon message Queue Full. This change is a trial work around
|
I did the esp32_hal_i2c.c substitution and this is the resulting output Error_output2.txt I also modified the program to strip out the DS18B20 and BMP280, so that only the ADS1115 was being read and reported by WiFi. At the start I got errors similar to the ones from the previous program. I recompiled with the new hal and have attached the output. Error_output3.txt. Once it got past the first error, it ran fine for an hour with the WiFI asking for updates every second. I initially had a 25 ms delay before the first ADS1115 read but tried to remove it. When I did that, I got continuous reboots. It turned out that I needed at least a 2 ms delay before the very first read, but after that none was required. While writing this it occurred to me to have a longer delay might prevent the error at start-up. With a 5 second delay before the first ADS1115 read I don't get the startup error in the ADS1115 only code. Output looked like this. Jeff |
|
@jlhavens The first 3 lines show timeOut's but they don't show the ISR got a fail when it tried to set the progress bits. the Last 3 lines are what I was expecting, Those are all on the exit path. 1&2 in ISR, 3 the timeout back in i2cProcessQueue() How are you communicating with the OneWire Devices? I Know that protocol is very time sensitive. Are you disabling interrupts to get accurate timing? I think the WiFi is being piggy. While it is initing, it is not allowing other processes any time. I do not know how to prove this 'theory' but it feels correct. If you allow the 5 second delay at boot, then start your sensor scans (including the OneWire devices) how does is respond? How fast are you polling the ads1115? All I can see from # 3 is 12 cycles that EventGroups failed. between the two period(.) markers It does not show how many completed without errors. Even those 12 should have correctly return/written data from/to the ads1115. is output4 what you expect? Halfway down # 25 has two periods? I chose to use EventGroups to synchronize the hand off of queue data to the ISR and accept it back when the ISR had completed. The Timeouts were caused when the ISR was not able to hand the batten back to If EventGroup are not stable, I'll have to think of something else. Chuck. |
|
I left the system that is only reading the ADS1115 and sending to WiFi running overnight and it ran without error (about 10 hours). That is a good result. Using the standard library I wouldn't have expected it to go that long error free, but I didn't previous have this exact program running so no absolute conclusion can be drawn. Replies: If you allow the 5 second delay at boot, then start your sensor scans (including the OneWire devices) how does is respond?--> Have not yet done that, but I can. How fast are you polling the ads1115?--> About once every second I am taking 20 consecutive reading and then averaging them. There is a built in 8 ms delay in the Adafruit library that waits for the conversion to complete. I set a timer and the read cycle is taking about 180ms. All I can see from # 3 is 12 cycles that EventGroups failed. between the two period(.) markers is output4 what you expect? Halfway down # 25 has two periods? --> yes, output is as expected. Two periods together just indicate that two readings were taken between WiFi updates. I will go back to the code that read all the sensors and see what the 50ms delay does. I think I will then try the bmp280/WiFi combination to see how well that works. Jeff |
|
Chuck, I added a 5 sec delay before the first reading in the system with I2C and OneWire (ADS1115,BMP280,DS18B20). It ran for somewhat longer, but failed after about 20 readings. The output is here. I then took the same code and stripped out the BMP280 calls. That gave error free startup and it ran for about 15 minutes without errors. I stopped it to continue other tests. So the ADS1115 and DS18B20 were both running error free. I realized that in my code I was starting the tasks to read the sensors before I started the WiFi, Like this: void setup(void){ WiFi.begin(ssid, password); // attempt to connect to Wifi network: I considered that the WiFi startup was the resource hog causing problems at the beginning, so I moved the xTaskCreatePinnedToCore call to after the WiFi.begin and wait for the WiFi.status change. After that edit, the program started error free without the 5 second delay (or any delay) before the first A2D conversion. It has run for 20 minutes without any errors. Jeff |
|
Chuck, I moved on to the BMP280 sensor. I set up a program like that ADS1115 that reads the data in a separate task and then when the WiFi calls for an update it sends the data both to WiFi and serial. I set it to read the bmp280 in both a separate task and in-line. In the task, it reads the device and assigns the result to a variable that's used when data is called for. In-line it simply reads the device while it is generating the output and sends it -- like Serial.print( (bmp.readTemperature()*(9.0/5.0))+32); I used the BackTrace on the output (two different times) and got Error_output_BMP280_3_decode.txt. It is pointing to esp32-hal-i2c.c I have continued to pursue this and have found that inserting a 25ms delay before the data is read in the task gave me 20 minutes run time without any errors. When I only read the data in-line it also ran for 20 minutes without error. If I only read the data in the task (without the 25ms delay) it ran for 20 minutes without error. In a retest, I read both in-line and in-task without the 25ms delay and in 10 minutes I got an error. I'll try to setup something for a longer test tonight. Jeff |
|
Hi, Thanks |
|
@rrobinet are you using my fork stickbreaker/arduino-esp32 or the official fork (this one)? If you are not using my fork, try it. My fork is a revision to implement I2C reliably. Chuck. |
|
Thanks Chuck, |
|
@stickbreaker |
|
I use M5Stack(ESP32) with built-in MPU9250 and have the same problem with i2c when start WiFi.begin() [E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 77 So, when your version will be incorporated in the official set?)) Please! |
|
@stickbreaker Hi Chuck, I pulled down the latest core for ardunio yesterday and the latest files you have from your forked branch for the4 wire and i2c files. After compiling I started getting busy timeout error again. Comparing what I had before (I kept a copy) I noticed that in the wire reset method that i2cFreeQueue(i2c) was missing. You had previsouly informed Phil and I in this thread that we should have that. I put it back in and I haven't been getting those timeout errors now. I have been getting exception due to heap corruption for another reason and upon reboot I immediately get the busy timeout errors. But I expect that this is due to the state of the SDA line when it is soft rebooted. Only way to clear is to do a hard reset (ie power off/on). Just thought you would want to know |
|
@ifrew did you download the the 'Release 1' zip or did you grab the whole fork? They are the same, I'm just curious. I walked back through the change history of I'll check my dev code when I get home. My dev code barely compiles right now. I am playing with slave mode ISR and it is kicking my ass. Chuck. |
|
just back from vacation....I downloaded the latest fork but then just copied the 4 files across. |
|
@ifrew are you still having problems? Chuck. |
|
Unfortunately yes. But I think as discussed earlier its the mpu i2c interface of the 9250. I'm looking at alternate mpus. It's a pity though that it fails on the esp32 due to its 2 core architecture. Runs fine on the esp2866. Still waiting for idf 3.0 to release so the ardunio core can be updated. lots of heap issues still. |
|
Hi stickbreaker. Just to let you know, this fix works like a charm for me. I'm using MMA8453 accelerometer controlling it by i2c and it was incurring in the same problem before your pack. I'm running and testing it for over 1 month without problems. Thank you for the fix! I wonder if you think to merge this in the official release soon. |
|
@nemerdaud I have had a pullrequest in since Nov 2017. Out of my hands. Chuck. |
|
@stickbreaker Just wanted to thank you for your work here! |
|
@valki2 Glad to hear it is working for you. Over on my fork there is an open issue that lists compatible devices. If you can add your successes that would be nice. Chuck. |
|
@stickbreaker HI Chuck! Still everything is working pretty stable - but i get crashes every some days. I am using your latest patches and i am not sure if the the cause for the instability comes from i2c. Could you make a guess based on this log? (the sketch is outputting "vpsat.... " etc and upon init the first task is the i2c scan.) `vp_sat: 856.694 vp_part: 551.677 ahum_int: 3.320 lastcheck: 0 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [D][WiFiGeneric.cpp:293] _eventCallback(): Event: 2 - STA_START |
|
@valki2 those errors show the i2c comms took longer than the configured timeout, But, it also says the time out was zero? By default it is configured to 50ms. So something has changed it to zero. Do you have any calls to Which version are you using? Chuck. |
|
@stickbreaker Thanks for you answer chuck - I highly appreciate that :) I double checked my sketch and all its includes - I have no known calls to Wire.setTimeOut... even more: when I do a recursive grep -r 'Wire.setTimeOut(' there seems no call at all to that function in my whole Arduino folder :) I am using the master branch of espressif (last checkout around 20. april) in addition to your relevant 5 files from your master branch 0.2.2: Arduino\hardware\espressif\esp32\cores\esp32\esp32-hal-i2c.c I double checked that too - eg. Wire.h contains "#define STICKBREAKER V0.2.2" :) So what can I do to hunt down the reason for that zeroed timeout? Or should I try to set it to 50ms and give that a shot? :) |
|
@me-no-dev Initial add of @stickbreaker i2c (13dcfe5) Looks like your changes have been added to the main repo... is that correct? |
|
@valki2 yep, Now to see how many problem it causes. #if ARDUHAL_LOG_LEVEL >= ARDUHAL_LOG_LEVEL_DEBUG
uint32_t expected =(totalBytes*10*1000)/i2cGetFrequency(i2c);
if((tAfter-tBefore)>(expected+1)) { //used some of the timeout Period
// expected can be zero due to small packets
log_d("used TimeoutRecovery: expected=%ums, actual=%ums, configured=%ums ",expected,(tAfter-tBefore),timeOutMillis);
i2cDumpI2c(i2c);
i2cDumpInts(i2c->num);
}
#endifUsually the only reason this happens is if the ISR is delayed by some higher priority task(WiFi) or the Slave is doing clock stretching. chuck. |
|
Hi Chuck!
unfortunately, the current state of arduinos github is not working anymore - I reverted back to yours :-)
Using the official files results in:
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 70
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 70
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 70
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 76
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 76
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
[E][esp32-hal-i2c.c:161] i2cWrite(): Busy Timeout! Addr: 20
[W][esp32-hal-i2c.c:280] i2cRead(): Busy Timeout! Addr: 20
While your repo is working quite good, I still have some errors every hour or so and a "freeze" of the whole ESP32 (unfortunately without any log... it just stops):
Typical error each hour or so:
[E][esp32-hal-i2c.c:1136] i2cProcQueue(): TimeoutRecovery: expected=0ms, actual=2ms
[E][esp32-hal-i2c.c:620] i2cDumpI2c(): i2c=0x3ffc1170
[E][esp32-hal-i2c.c:621] i2cDumpI2c(): dev=0x60013000 date=0x16042000
[E][esp32-hal-i2c.c:623] i2cDumpI2c(): lock=0x3ffcd990
[E][esp32-hal-i2c.c:625] i2cDumpI2c(): num=0
[E][esp32-hal-i2c.c:626] i2cDumpI2c(): mode=1
[E][esp32-hal-i2c.c:627] i2cDumpI2c(): stage=3
[E][esp32-hal-i2c.c:628] i2cDumpI2c(): error=1
[E][esp32-hal-i2c.c:629] i2cDumpI2c(): event=0x3ffcda14 bits=10
[E][esp32-hal-i2c.c:630] i2cDumpI2c(): intr_handle=0x3ffcda44
[E][esp32-hal-i2c.c:631] i2cDumpI2c(): dq=0x3ffcef98
[E][esp32-hal-i2c.c:632] i2cDumpI2c(): queueCount=1
[E][esp32-hal-i2c.c:633] i2cDumpI2c(): queuePos=0
[E][esp32-hal-i2c.c:634] i2cDumpI2c(): byteCnt=9
[E][esp32-hal-i2c.c:593] i2cDumpDqData(): [0] ed R STOP buf@=0x3ffc3ac8, len=8, pos=8, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:609] i2cDumpDqData(): 0x0000: f...}..- 66 e0 00 81 7d 00 87 2d
[E][esp32-hal-i2c.c:948] i2cDumpInts(): 0 row count INTR TX RX
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [01] 0x0001 0x0002 0x0001 0x0000 0x00b7c743
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x00b7c743
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [03] 0x0009 0x0040 0x0000 0x0000 0x00b7c744
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [04] 0x0001 0x0080 0x0000 0x0008 0x00b7c744
While I have seen this type here just once in the last week:
[E][esp32-hal-i2c.c:1182] i2cProcQueue(): Gross Timeout Dead start=0x79004f, end=0x790081, =50, max=50 error=1
[E][esp32-hal-i2c.c:620] i2cDumpI2c(): i2c=0x3ffc1170
[E][esp32-hal-i2c.c:621] i2cDumpI2c(): dev=0x60013000 date=0x16042000
[E][esp32-hal-i2c.c:623] i2cDumpI2c(): lock=0x3ffcddfc
[E][esp32-hal-i2c.c:625] i2cDumpI2c(): num=0
[E][esp32-hal-i2c.c:626] i2cDumpI2c(): mode=1
[E][esp32-hal-i2c.c:627] i2cDumpI2c(): stage=3
[E][esp32-hal-i2c.c:628] i2cDumpI2c(): error=1
[E][esp32-hal-i2c.c:629] i2cDumpI2c(): event=0x3ffce6a0 bits=0
[E][esp32-hal-i2c.c:630] i2cDumpI2c(): intr_handle=0x3ffce6d0
[E][esp32-hal-i2c.c:631] i2cDumpI2c(): dq=0x3ffdfb14
[E][esp32-hal-i2c.c:632] i2cDumpI2c(): queueCount=1
[E][esp32-hal-i2c.c:633] i2cDumpI2c(): queuePos=0
[E][esp32-hal-i2c.c:634] i2cDumpI2c(): byteCnt=1
[E][esp32-hal-i2c.c:593] i2cDumpDqData(): [0] 41 R STOP buf@=0x3ffc3ac8, len=1, pos=0, eventH=0x0 bits=0
[E][esp32-hal-i2c.c:609] i2cDumpDqData(): 0x0000: ^ 5e
[E][esp32-hal-i2c.c:948] i2cDumpInts(): 0 row count INTR TX RX
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [01] 0x0001 0x0002 0x0001 0x0000 0x0079004f
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [02] 0x0001 0x0200 0x0000 0x0000 0x0079004f
[E][esp32-hal-i2c.c:951] i2cDumpInts(): [03] 0x0001 0x0040 0x0000 0x0000 0x0079004f
[I][esp32-hal-i2c.c:971] i2cProcQueue(): Bus busy, reinit
I just bought an ocilloscope to check if the "electronic part" is looking good on the i2c bus... - I really want to get it 100% stable (as I am dry aging beef with the esp32) - changing the microchip to some different type is the last option :)
kind regards
Valki
|
|
@valki2 are you sure you are using the current core?
These errors are not part of the current core, me-no-dev merged a modified version of my changes last week, and these error messages do not exist in the current core. Those timeout Recovery messages are just debug status. I have just propose a pr #1574 to remove this confusing message. The Gross Time is an actual problematic error:
This one is showing that you were doing a What device is at 0x20? Also try increasing the timeout from 50ms. Jump clear up to 500ms. Just put Chuck. |
|
I got a similar issue since last update of arduino-esp32, while using u8g2 OLED library, raised an issue here: |
|
Sorry @stickbreaker for my late answer... had to get some hardware (ocilloscope, logic analyzer) and learn first steps there :) First finding: the i2c figures look "good" in the means of proper squares and no sharky figures. So as an absolute electronic noob I tend to rule out capacitive or resistance problems on the bus. For the logic analyizer: woa lots of info there what needs some time to understand everything. but I see a good number of NAKs what may be good to take a closer look at. But again: just started playing there. For the core: Yes - but of course I made a stupid mistake and forgot to compile it after checking out git... - no get.py executed on the first run :) lots of: [I][esp32-hal-i2c.c:971] i2cProcQueue(): Bus busy, reinit As my sketch is somehow in a "productive environment" (read: there is beef in the fridge g) I reverted to your branch and I will build up a second test area where I can play without stopping the productive esp32. for your questions - 0x20 is a mcp23017 port expander... |
|
@valki2 I use MCP23008, MCP23017 neither of them can stretch SCL, so, based on the errors received (busBusy, timeout) something else is hanging the hardware bus. The MCP's don't NAK. I know of no circumstance that they could generate a NAK. Well, unless they were not present on the bus. But, that is hardly their fault. I'm currently working a 'injection' spurious interrupt problem. But I don't see that issue in your debug messages. Chuck. |
|
@stickbreaker I thought I basically understood what happens on the i2c bus - well until playing a day with the logic analyzer. :) 2 solutions: I am getting wrong readings or there is a lot of communication going on to unknown adresses... I am going to invest some time there now! |
|
Btw - when using the latest official repo, I get: Backtrace: 0x400d8422:0x3ffd2bc0 0x400d84ff:0x3ffd2c00 0x400d68f4:0x3ffd2c30 0x400d3326:0x3ffd2c60 0x400d41bd:0x3ffd2c80 0x400d43f3:0x3ffd2ca0 0x4011fec3:0x3ffd2cc0 Decoding stack results |
|
@valki2 That loadProhibited Error is saying that memory pointer was pointing at an invalid location. Usually zero. I would look in your code for a memory overwrite. Something is hosing one of the i2c control structures. probably the dq pointer. Chuck. |
|
Thanks @stickbreaker - it seems I had an inconsistency of my repo after all those tests. I cleared and reinstalled the esp32 environment (latest official repo) and now it looks way better :) Still some [I]nfo messages popping up but now I will let it run to see if there are still locks of the i2c bus.... after all it seems that your improvements have found their way into the code :) Example serial output (debugging level): Devices on the bus: Example communication on the i2c bus:
|
|
@valki2 Ok,
I never see the SHT11. Do you have pullups on each branch? I use 50k on each branch and 3.3k on the master branch. This results in 2.2k if all branches are active at the same time or 3.1k if only one branch is active at a time. I wish your i2c capture had information on bus state. Your debug show bus busy events, but nothing in the capture. I've have another update in the works to remove the 'eject'. My code handles the problem, the debug output is just annoying. I recommend removing to debug log calls. At the top of
The bus busy info, is the only one I am interested in. Chuck. |
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
The text was updated successfully, but these errors were encountered: