What ESP32 board are you using? It sounds like perhaps the power supply circuit, necessary for converting an outside voltage to 3.3v for the EPS32, has a problem.

The ESP32 uses 3.3v, not 5v. So, 'something' must be doing the voltage conversion. If this is a custom board, make sure you have the ...

EVERY interrupt I have tried has the exact same latency... so if I do a GPIO interrupt, MCPWM interrupt, or TIMER0 interrupt, the latency of any of these from the time they trigger to the time the highint5 (or NMI) is entered is ~225ns. So, I don't think the hardware itself (MUX routing) is causing ...

I am using a logic analyzer to capture the data. I have one input connected to our trigger signal which is going to a ESP32-S3 GPIO pin, and I have code in the highInt5 ISR (no register saves before hand) that toggles a GPIO pin using the specific assembly instruction that the ESP32-S3 has. I have ...

No fighting from me. C has its place and certainly compilers are better, but to assume that a compiler can outwit a human who does this sort of work for a living is a bit foolish. I have spent more time than most people here in these forums have been alive disassembling compiled code to re-create it ...

Check xtensa_vectors.S to see what interrupt handlers do on Xtensa-FreeRTOS.


Thanks. I am aware of this. What I want to know is what the ROM code is doing though, as that is what calls these high level routines. Application code only generates elf files containing the main code and other than ...

extern "C" void new_xt_highint5(void* arg);



I will try this.

::edit::
OK, this routine seems that this is just testing and installing the interrupt handler into a vector table? Espressif told me that the vector table was ROM based (created at compile time). I guess this is not true ...

I have recently run across this exact same issue with a ESP32C3. Code that compiles and works perfectly on the ESP8266 does not work on the ESP32C3 (maybe other ESP32 versions?)

if (tcpClient.availableForWrite() > 0) {
tcpClient.write(sendbuf, sendlength);
}

This skips the write because the ...

FWIW, the GPIO latency is a function of the bus they're on. If you need faster GPIO, we do support dedicated GPIO on most newer chips (S2 and up, iirc):
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/dedic_gpio.html



Thanks. I would also like to know if ...

Is there going to be some concrete information about the GPIO latency on these parts? I would hope that Espressif could figure out how to do single cycle GPIO by now. Taking hundreds of nanoseconds (with a sub-5ns clock) just to change a pin state is a huge limitation that none of their competitors ...

I have this same problem as well!

int i = tcpClient.availableForWrite();

This always returns with i equal to 0. This code works perfectly when compiled for the ESP8266.