Odd. Do you see this behavior on multiple PCBs or only one?

You can even do BLE and WiFi simultaneously if you want. I'm not sure if we still have WiFi Direct functionality, but it'll be of limited use anyway as the C3 can only 2.4GHz WiFi.

No, you have not. ctx is not a sane value (as it comes from the stack and as such is uninitialized) and ctx->om=0 will crash as the processor will try to dereference the ctx pointer, which contains a random address because it's uninitialized, and write 0 there.

Yeah, sorry, especially since 3.3 is not supported anymore, getting it to work is somewhat of an exercise in archeology... you might be better off porting to v4.4 or even v5.

If you can whittle this down to a small example that reproduces this, can you perhaps post an issue on the ESP-IDF Github? This sounds like something that our BT people need to take look at, and that's an easier way to make sure it reaches them.

What chip? Can you post your code? Can you define 'delays' a bit better?

So you're not counting the interrupt delay; you're counting the delay before your task gets scheduled. This depends on a bunch of things: mainly other interrupts scheduled and other tasks running. Is there anything else that your CPU is doing (WiFi, BT, writing to flash, ...)? Also, what chip is thi...

Sounds like the bypass capacitors somehow result in a dead short somehow. Can you measure the voltage over them?

No, sorry. You could try esp-now as an alternative, perhaps that has low enough latency.

So what is your question? The error is exactly as the compiler says: you're using ctxt without initializing it (and then the device_read dereferences it, so even if this compiles, it'll crash the esp32)