ESP32C3 wakeup from deepsleep and quickly capture data pulses on a GPIO

[thamesview]

Hi,

I'm designing an RFID decoder and it all works well in the standard run mode. As this is aimed to be a battery powered device, I'd like to get the MCU to wake up from deepsleep (when it detects the first pulse on the RFID GPIO1) and then in an interrupt routine take measurements as to the timing of the RFID pulses. The transmission lasts 120ms and is similar to how infrared receiver devices work.

Due to the bootloader taking 100ms or so to jump to the main firmware code, when the code gets to execute in the main firmware, all of the RFID transmission is already completed and the data completely missed.

To work around this, I'm thinking of modifying the bootloader to set an interrupt routine in the bootloader code, however I can't find much documentation on how to configure a GPIO an input and set up an interrupt routine in the bootloader code so that it gets called while the bootloader is running.

Are there any examples on how this can implemented in the esp-idf bootloader code for ESP32C3?

Thanks!

[thamesview]

nb. I've also tried to implement the gpio isr config in esp_wake_stub() but if the code loops in esp_wake_stub() for anything longer that a few instructions, the MCU hangs up.

[MicroController]

Guess this won't work.
You can look into using an ESP with an ULP, like the ESP32, ESP32-S3, or ESP32-C6.
But first check out using light sleep instead of deep sleep on the C3. And see if you can receive the "pulses" via hardware (UART?).

[ESP-Marius]

Should be possible to achieve this in the wake-up stub. I suggest not complicating it with interrupts etc, simply polling for the gpio in the stub sounds like it should be sufficient? It is not like your CPU will be doing anything else while in the stub anyways.

Not sure what you mean by "hang-up", but there is no reason why you cannot run the stub for a long time, just make sure it follows the usual requirement (code in RTC RAM etc). If it runs for too long you might need to feed the WDT though if you see it triggering and reseting the chip.