Kernel panic on i2c_new_master_bus (IDFGH-11838) #12929
Comments
github-actions
bot
changed the title
|
|
I get this error when building. I may be wrong but I think in terms of actual structure data they are the same? error: either all initializer clauses should be designated or none of them should be
45 | .flags.enable_internal_pullup = 1,
| EDIT: Made it look prettier: i2c_master_bus_config_t display_bus_config = {
.i2c_port = -1, // -1 means auto selecting
.sda_io_num = static_cast<gpio_num_t>(SDA),
.scl_io_num = static_cast<gpio_num_t>(SCL),
.clk_source = I2C_CLK_SRC_DEFAULT, // Default clock source
.glitch_ignore_cnt = 7, // Filtering glitches
.intr_priority = 0, // 0 = default
.trans_queue_depth = 2, // Maximum number of asynchronous transactions
.flags = {1},
}; |
|
I am having exactly the same problem with I had this all working using the now-deprecated I2C API and am trying to port to the new I2C API. I'm getting the panic at the line where I call esp_err_t Point::switchInit(void)
{
i2c_master_bus_config_t i2c_mst_config {};
i2c_mst_config.clk_source = I2C_CLK_SRC_DEFAULT;
i2c_mst_config.i2c_port = _i2cPort; // this variable is const set to I2C_NUM_0
i2c_mst_config.sda_io_num = static_cast<gpio_num_t>(pinSda); // pinSda is const set to 21
i2c_mst_config.scl_io_num = static_cast<gpio_num_t>(pinScl); // pinScl is const set to 22
i2c_mst_config.glitch_ignore_cnt = 7;
i2c_mst_config.flags.enable_internal_pullup = false;
return i2c_new_master_bus(&i2c_mst_config, &_i2cBusHandle); // _i2cBusHandle is a static member of the Point class
}Here is the panic: Running a backtrace analysis, I get this (line Point.cpp:48 is where the function call is made): Perhaps the library call has an issue in a C++ build environment? |
|
Hello @mbratch If you are using esp32. I guess you didn't set enable_internal_pullup to true or no external pull-up. Yes, ESP32 has a very weird behavior, it will fail in a very incomprehensible way if no any pull-ups on pins when initialize the bus. So, please modify your enable_internal_pullup to true please. |
@mythbuster5 I have sufficient external pull-ups in my system design. As I mentioned in my post it has been working fine for quite some time with the old i2c API. Setting internal pullups to true will cause it to fail because the resistance of the internal pullups is quite high. My design requires the external values I use. There is a problem with the new API in some circumstances as is seen by several different reports. I can capture other stack traces if that will help. This problem is reproducible. |
I doubt this is the cause since pull up is set to true on my various tests and the same issue persists. |
|
I want to get more clue @babagreensheep @mbratch So I want to know this issue it's not related any transaction?
|
There are other users in #12103 with the same problem symptoms you might also want to ask these details of. Their additional input could prove helpful.
Correct. As shown in my stack trace
I only use external pull-ups in this design. The internal pull-up values in the ESP32 are quite a bit higher than those recommended for I2C bus designs operating at 100-400Khz. The ESP-IDF I2C documentation also strongly recommends external pull-ups for higher speed bus selection. I designed my system a few years ago and the hardware design hasn't changed. The I2C has worked flawlessly since I started using ESP-IDF ver 4.3 and up through 5.2.0 using the prior I2C API. When I changed to the newest I2C API, I have this problem.
True for me. I only have ESP32.
True for me. I'll add that I am not using BLE. I am using wifi, but I am initializing i2c well before wifi is initialized and enabled. When I have some time over the next couple of days I will capture additional stack traces to see if there's any variation at all. |
|
I am now running ESP-IDF 5.2.1, but the exact same issue still exists. I wasn't expecting it to go away, but just wanted to state the scenario. I turned on I2C debug logging in the sdkconfig and let the device reboot a few times. Each time, the following error was displayed with exactly the same stack trace. So it's not timing dependent, but deterministic. There are only two additional log messages from i2c debug. With the corresponding translation: I was hoping there would be a little more debug that might help, but not the case. |
Yes - based on the stack trace.
Yes.
Think so? My report has this info.
Yes. Thanks so much for looking into this it's been bugging me for really long. |
|
I've done a little digging on this and the wdt occurs in this call in i2c_ll_enable_intr_mask(hal->dev, I2C_LL_MASTER_EVENT_INTR); |
|
Craziest thing.... my setup is now working. The problem is, I don't know why. I had just updated to 5.2.1 using the Windows offline installer and reconfigured the vscode plugin to use the new version. My most recent debugging attempts on this issue were using that. I had added some debug statements into But then I noticed things started working. Honestly, I don't recall if I got some successes at the tail end of debug, or only after the refresh. So why is it working?
So here we are. I'm running ESP-IDF 5.2.1 and the new I2C API appears to be working fine on my ESP32 at this point. I am just uncomfortable when things just start working as if by magic. :p I think this does prove that there's nothing intrinsically wrong with an ESP32 that would prevent the API from working. Nor is the problem related to pull-up resistors in my case. It may have to do with configuration or ensuring use of the latest version of ESP-IDF and the associated API on the ESP32. All speculative. |
|
@mbratch @babagreensheep Thanks guys. I found a very different behavior of I'm trying to delete The changes can be: |
|
@mythbuster5 thanks for the update. Great find! Very much appreciate you digging into it. I will try the change. Since my system seems to be working already (probably a tenuous situation -- luck of the draw), it may be difficult to confirm the positive effect in my case, but I can verify whether it works reliably with the change. |
|
Is it possible to get any update on your side? @babagreensheep |
|
@mythbuster5 Sorry give me some time to test this and I'll let you know! I should add that the issue has been intermittent on my end so I'll need to run a number of tests to confirm. |
|
@babagreensheep Thanks. If we can confirm this is the root cause, this issues can be solved quickly~ |
|
@mythbuster5 I applied the fix you provided. Now it no longer fails at i2c_new_master_bus, but the task watchdog gets triggered by i2c_master_probe, even if xfer_timeout_ms is set to zero. |
|
@ceribus Thanks, ESP32 is always the special, let me test. |
|
@ceribus Try this. Find function Sorry for the inconvenience, esp32 really has a different behavior compared with others, I'm also collection issues and fix them as soon as possible. Glad to hear from you soon, Thanks. |
|
@mythbuster5 Thanks for the quick reply. It actually fixes the error, but EDIT: I tried it again to compare the behavior of the esp32 against the esp32c3, probing for 3 different addresses that are not connected. On the esp32c3 it returns |
|
@ceribus That is very strange, because it works good on my side. Can you provide the picture of ESP32 probe logic analyzer and let me see what happens on data line. (PS, the expected behavior is address+nack if device not connected.) For timeout, did you check the xfer_timeout_ms parameter? And could you please check pull-ups on board. (you can also set .flag.enable_internal_pullup = true to have a try) Analyzer picture is very important for me to go head, but now I haven't got one. If any clue you can provide, that is very thankful.~~ EDIT: And you said you are on v5.2.1, can you show me your latest commit? |
|
@ceribus I reproduced issue on my ESP32 without any pull-up connected. So I guess your I2C pins are not given by proper pull-ups. |
|
@mythbuster5 You're right, I forgot to enable internal pullups. It works when they're enabled. |
|
@ceribus writing a command with probe or i2c_master_transmit? Yeah.. I wanna see on logic analyzer. And your usage code maybe? ~ |
|
@ceribus I guess it fails here https://github.com/espressif/esp-idf/blob/v5.2.1/components/driver/i2c/i2c_master.c#L512 Could you please help me check what happens here? (because I haven't reproduced then..) I'm going to enhance logic here. If my guess is correct, you calls |
|
@mythbuster5 You're right, it fails in i2c_master.c:512.. EDIT: I tried with and without probing first, but that doesn't seem to make a difference. |
|
Fine @ceribus thanks for giving the new clue, the timeout will only happen in one situation on v5.2.1. That is something wrong on SCL/SDA bus, the hardware triggers a timeout interrupt or arbitration interrupt https://github.com/espressif/esp-idf/blob/v5.2.1/components/driver/i2c/i2c_master.c#L580. You might need to check the timeout value you gave and what happened on bus. |
|
@mythbuster5 I attached the logic analyzer to the bus and it seems that the driver fails with With the old i2c driver I avoided this issue by calling |
|
@ceribus So |
espressif-bot
added
Status: Done
…_probe issue, and probe might failed. Fixed I2C cannot return err code when nack detected Closes espressif#13213, Closes espressif#12929, Closes espressif#13398,
Answers checklist.
IDF version.
v5.3-dev-1196-gece73357ca
Espressif SoC revision.
ESP32-D0WD-V3 (revision v3.1)
Operating System used.
Linux
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
custom kit
Power Supply used.
USB
What is the expected behavior?
I2C master bus is installed created when running
i2c_new_master_bus().What is the actual behavior?
I am getting a
Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0).error when attempting to runi2c_new_master_bus().This function was working perfectly for a while, but suddenly crashed after I recompiled the code for a different change.
Steps to reproduce.
This seems to be triggered purely by a call to
i2c_new_master_bus(). No other code is running at the time as I am unit testing.Called from the following function (which never actually gets called).
Debug Logs.
More Information.
No response
The text was updated successfully, but these errors were encountered: