Solved with short but non-zero blocking timeout!

After further digging, the issue seems to be contention on accessing the mutex object by multiple readers at the same time. It is fixed by adding a very short but non-zero blocking timeout to aquire the ReadAccess lock. I used `std::shared_timed ...

My goal is to be able to write C++ code that uses scoped lock objects like this:

if (auto dbAccess = MyConfigDbManager::getInstance().getReadAccess()) // get scoped read lock
{
// Got a read lock. Do something with the protected object, i.e.
dbAccess->doSomething();
// when this block ends and ...

I did end up going with a partition of type "TEST" for a small recovery firmware. It is working quite well.

BTW, I just stumbled upon this component which allows for compressed OTA updates. It would have been very useful to know about it before:
https://components.espressif.com/components ...

I was just asking myself a very similar question and found this post. It's a shame so many questions go unanswered for years on this forum. What did you end up doing?

Yes, the default behavior seems drastic and doesn't align with many devices on the market. The difference is this is a FACTORY ...

Finally, this commit increases the limit of sockets. It was trivial to back-port to my old IDF 4.4.8

espressif/esp-idf@48295d3
https://github.com/espressif/esp-idf/commit/48295d31ca90d693356b632750630efd2f1b34eb


I increased LWIP_MAX_SOCKETS to 32, but my HTTP server still failed when I opened 6 ...

I am also interested in running unit tests on a host machine (via GitLab CI).

Ideally, it would automatically use the same unit tests that I have written for my components in /components/mycmp/test/test_mycmp.c, just
like the Unit Test App does .
And if some tests are not appropriate for running ...

Not sure if relevant or helpful, but I previously found that JTAG was unusable when the EMAC is enabled, even though they don't share any pins. I never figured out why, but configured my project with macros to disable EMAC when I need to debug with JTAG.

My guess is that the pin is initialized to Hi-Z (floating) at power-on-reset. Then it takes some time for the CPU to start running your code and set the level high.
You could try adding an external pull-up resistor to 3.3V so it goes high when the pin is hi-Z / floating.

Yep! And some ESP32 variants also have PSRAM / SPI RAM inside the same chip package.

If you can recover after reflashing the code, then it is NOT the same issue as covered in this thread/topic.
You should start a new topic.