Hi Matthias, I opened an issue in Github. Simon Cao answered very quickly that it is a known bug. Which is already fixed internally. He posted the right code and I will do so here if anybody else encounters the same problem. You just have to replace the given function: static bool s_i2c_read_command...

Hi Matthias, I am out :D I tried it with the function you provided... nothing. Still blocks within read part, getting resetted by task watchdog and afterwards blocked in i2c_new_master_bus ... what am I missing? LOG is set to "VERBOSE", check of i2c log is set, but there are no significant log messa...

Hi Matthias,

thanks for the hint! But unfortunately, even with "uint8_t data[1]" both read functions block until watchdog reset.
Do you use the 5.2 release branch or the 5.2 developer branch?

Greetings
Christoph

Hi All! Consider following situation: main task creates legacy i2c driver, initializes and uses it from time to time. A second task is responsible to accept and to answer TCP connect requests. On thing to do within the TCP task is to do a full OTA update. During update an i2c connected LCD display s...

Hi All! I tried out the IDF 5.2 branch as to the new I2C driver implementation. Unfortunately, I cant get it to work to read data from devices in master mode. Writing data to devices works like a charm. Using reading functions (i2c_master_receive or i2c_master_transmit_receive) leads to a hang and a...

Hi all, I use v4.2 of IDF and I call "esp_restart()" at the end of my OTA process. I expect reset reason "SW_CPU_RESET" after reboot, but I get "RTCWDT_BROWN_OUT_RESET". Brownout detection is enabled and does not fire all the time, the system is running. No drop is detected nor seen on the Vdd line....

Hi all, does anybody encountered the following strange I2C behaviour? I started to write a small i2c programm controlling a simple 4-line LCD display. Using the typical i2c bus speed of 100kHz leads to an extremly slow i2c communication. The complete master write cycle (using the IDF example "i2c_ma...

Hi folks, just one question to better understand wifi events. Receiving events with reasons greater or equal to 200 (in the docs is written that these are ESP-IDF "private" reasons, as far as I undestand), do these events really mean a DISCONNECT? Or is it just an information about bad wifi conditio...

Thanks, I already expected an answer like this. Will have a closer look into power supply measures.

Greetings,
Chris

Hi all, from time to time I get a core dump with the following content: espcoredump.py v0.3-dev =============================================================== ==================== ESP32 CORE DUMP START ==================== ================== CURRENT THREAD REGISTERS =================== pc 0x4012212...