{"action":"created","issue":{"url":"https://api.github.com/repos/espressif/esp-idf/issues/1503","repository_url":"https://api.github.com/repos/espressif/esp-idf","labels_url":"https://api.github.com/repos/espressif/esp-idf/issues/1503/labels{/name}","comments_url":"https://api.github.com/repos/espressif/esp-idf/issues/1503/comments","events_url":"https://api.github.com/repos/espressif/esp-idf/issues/1503/events","html_url":"https://github.com/espressif/esp-idf/issues/1503","id":288459513,"number":1503,"title":"[TW#17765] I2C crashing - watchdog timeout (master & v3.0 branch)","user":{"login":"DavidAntliff","id":11261038,"avatar_url":"https://avatars1.githubusercontent.com/u/11261038?v=4","gravatar_id":"","url":"https://api.github.com/users/DavidAntliff","html_url":"https://github.com/DavidAntliff","followers_url":"https://api.github.com/users/DavidAntliff/followers","following_url":"https://api.github.com/users/DavidAntliff/following{/other_user}","gists_url":"https://api.github.com/users/DavidAntliff/gists{/gist_id}","starred_url":"https://api.github.com/users/DavidAntliff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DavidAntliff/subscriptions","organizations_url":"https://api.github.com/users/DavidAntliff/orgs","repos_url":"https://api.github.com/users/DavidAntliff/repos","events_url":"https://api.github.com/users/DavidAntliff/events{/privacy}","received_events_url":"https://api.github.com/users/DavidAntliff/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":54,"created_at":"2018-01-15T01:42:40Z","updated_at":"2018-02-19T15:18:13Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I have a project that has three I2C slave devices on a single bus (running at 100kHz). For some time I was developing with ESP-IDF 2.1.1 and everything was working pretty well, except for a weird problem where the I2C master would freeze up after a few minutes. I did some research and it looks like this is a problem with the I2C master hardware state machine which has been addressed in more recent commits of ESP-IDF. So to make use of this fix I migrated my project to use master (595688a32ad653d8e6cb1c7682b813f96125853e). I had to make a few changes (remove references to FreeRTOS heap measurement commands, add `nvs_flash_init()` before initialising WiFi) but then everything seemed to work well. The slave devices are all being polled correctly and everything seems happy.\r\n\r\nThe project is here: https://github.com/DavidAntliff/esp32-poolmon/tree/ESP-IDF_master\r\n\r\nI came back a little while later and the application is crashing over and over with the following console output shortly after boot:\r\n\r\n```\r\nGuru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)\r\nRegister dump:\r\nPC      : 0x400859f3  PS      : 0x00060034  A0      : 0x80084685  A1      : 0x3ffb0590  \r\n0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037\r\n\r\nA2      : 0x00000001  A3      : 0x00000000  A4      : 0x3ffb05b0  A5      : 0x00000002  \r\nA6      : 0x3ffbc970  A7      : 0x00060021  A8      : 0x800859f3  A9      : 0x3ffb0570  \r\nA10     : 0x00000000  A11     : 0x00000000  A12     : 0x00000002  A13     : 0x3ffbadc0  \r\nA14     : 0x00000000  A15     : 0x400849fc  SAR     : 0x00000012  EXCCAUSE: 0x00000005  \r\n0x400849fc: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023\r\n\r\nEXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  \r\n\r\nBacktrace: 0x400859f3:0x3ffb0590 0x40084682:0x3ffb05b0 0x40084a89:0x3ffb05e0 0x40082ba5:0x3ffb0610 0x4000bfed:0x00000000\r\n0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037\r\n\r\n0x40084682: i2c_master_cmd_begin_static at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023\r\n\r\n0x40084a89: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023\r\n\r\n0x40082ba5: _xt_lowint1 at /Users/david/esp32/esp-idf-master/components/freertos/./xtensa_vectors.S:1105\r\n\r\nRebooting...\r\n```\r\n\r\nA software or on-board reset does not stop this endless reset behaviour, however removing power for a short period of time does \"fix\" the issue. It is strange that a brief ESP32 reset does not clear it. (EDIT: but a long reset press does).\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/espressif/esp-idf/issues/comments/366723108","html_url":"https://github.com/espressif/esp-idf/issues/1503#issuecomment-366723108","issue_url":"https://api.github.com/repos/espressif/esp-idf/issues/1503","id":366723108,"user":{"login":"luisonoff","id":10898530,"avatar_url":"https://avatars0.githubusercontent.com/u/10898530?v=4","gravatar_id":"","url":"https://api.github.com/users/luisonoff","html_url":"https://github.com/luisonoff","followers_url":"https://api.github.com/users/luisonoff/followers","following_url":"https://api.github.com/users/luisonoff/following{/other_user}","gists_url":"https://api.github.com/users/luisonoff/gists{/gist_id}","starred_url":"https://api.github.com/users/luisonoff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/luisonoff/subscriptions","organizations_url":"https://api.github.com/users/luisonoff/orgs","repos_url":"https://api.github.com/users/luisonoff/repos","events_url":"https://api.github.com/users/luisonoff/events{/privacy}","received_events_url":"https://api.github.com/users/luisonoff/received_events","type":"User","site_admin":false},"created_at":"2018-02-19T15:18:13Z","updated_at":"2018-02-19T15:18:13Z","author_association":"NONE","body":"I have also recently faced this problem, and I agree with @DavidAntliff that there is something wrong in i2c driver not being fully tolerant to errors in transmissions.\r\n\r\nIn my case, it was due to not using external pullups, so I was just using the internal ones, with just one peripheral and 5cm cables in a breadboard. I was seeing random communication errors, and at some point, the wdt interrupt timeout error would appear. Once this error appeared, ESP32 was stuck in a reboot loop. I had to unpower the ESP32, or make a long push on the reset button, in order to work again. When touching the cables with my fingers, this happened a lot more and earlier, that's how I realized I needed external pullups.\r\n\r\nOnce I put external pullups (4.7K), all communication errors and wdt interrupt errors are gone. But I understand there is something wrong with the driver, and there is the risk of entering this error state. Maybe if there is a lot of external EMI? Or maybe if some connection is a bit loose? Or in case the i2c pad of the wrover module I am using disconnects from my pcb and catches EMI noise... I dont know...  \r\n\r\nThis scares me because my product has internal battery and there is no power switch, nor a reset button... and the battery and pcb is inside a housing, not accesible to the user...  So if this happens, I am in a big trouble, and the product will have to be shipped back to me in order to open it and unpower it. Right now I am looking for a solution and I may add a way of resetting ESP32 from another MCU, my product has ESP32+nRF52.\r\n\r\nThis should be addressed looking for the real cause and fixing it, in order to make i2c driver fully tolerant to communication errors.\r\n\r\nI have seen some people at the forum reporting that some gpio interrupts are happening more times than expected, could this be related? \r\nMaybe the EMI noise + extra interrupts triggering are overflowing the interrupt handler or taking too much time? \r\n\r\n"}}
{"actor":{"display_login":"luisonoff"}}