esp 4.2 fails to run on a recent debian system due to a build failure in gevent. Is there a fix or workaround for this? src/gevent/_greenlet_primitives.c:216:12: fatal error: longintrepr.h: No such file or directory Isrc/gevent -Isrc/gevent/libev -Isrc/gevent/resolver -I. -I/home/ico/.espressif/pyth...

Hello, We are developing software using a esp32 mesh network. The default network uses a tree topology where the main goal seems to be to reduce the depth of the tree. It seems this can lead to sub-optimal network performance in our tests. For example, consider the following minimal tree: a / \ b c ...

This was confirmed a bug and will be solved in the next version: https://github.com/espressif/esp-idf/issues/9156

I also created a github issue for this: https://github.com/espressif/esp-idf/issues/9156

I was able to pinpoint the problem to idf commit 2373f115fc6db20a0159ccab11e1db0feb4c0bfa by bisection.

We have a few hundred devices in the field that, for historical reasons, run different versions of boot loaders - some of these are configured for 40M, others for 80M SPI flash speed. The SPI flash speed of our current application is set to 40m. We recently upgraded ESP IDF from 4.2 to 4.3 to make u...

@ESP_Dazz: The workaround of moving the ISR to another core has proven solid over the last few days, but I believe the underlying problem still persists in idf, even the latest versions. Problem is that I can not reduce the problem, and given that I'm good with the workaround I'm not sure if I can/w...

The overnight test showed no more occurrences of the problem in the last 17 hours, so I consider the workaround sufficient for production. Conclusions so far: - There is likely a bug in idf causing spurious I2C read corruption when used in conjunction with other peripherals, including at least CAN -...

Status update: I probably need to wait for another 24 hours test to be sure, but from the looks of it doing the `i2c_driver_install()` from a thread pinned to core 1 solved my problem. If this is the case, I guess the original IDFGH-3307 has not actually been solved, and moving the ISR to another co...

We upgraded idf to v4.3.1, and after running for about one hour we unfortunately still see this happen two times. The problem is that I have not yet figured out how to consistently trigger this, and the very low frequency of occurrences makes it a /very/ slow operation to minimize and pinpoint the p...

Thanks for the blazing fast reply! The issues you pointed to all seem to be much older then idf 4.2, so I'd expect these to be fixed in this version already. Still, I'll try if I can get our app to run on the latest v4.3 though to see if this changes the behavior. I'll report back with results later...