Efuse for interrupt on GPIO39 for ESP32-S3-DevKitC-1 WROOM-2
Posted: Fri Jan 26, 2024 2:28 pm
Hello,
I am attempting to use GPIO39 on the ESP32-S3-DevKitC-1 with a WROOM-2 chip as an input for a GPIO interrupt. I have been having trouble doing so successfully, with unexpected interrupt behavior occurring on that pin - different from behavior when switching to another GPIO (GPIO21 for example). Specifically, I noticed the interrupt occurs earlier on GPIO39. I first attributed this to the lack of pull-up and pull-down resistors on this pin, however the device which is sending the interrupt does not specify requiring a pulldown resistor for its interrupt pin.
In note 8 for Table 2-1 of the ESP32-S3 Datasheet, it specifies burning GPIO 39's efuse to disable JTAG. This has led me to believe that the JTAG is the culprit for this, and burning this efuse should resolve the issue. Successfully doing so via the command may or may not disable JTAG, however the same previously observed behavior is still occurring on GPIO39.
Might there be another reason GPIO39's behavior is inconsistent/incompatible with being set as an interrupt? Is there perhaps another efuse I am missing that needs to be burned? Any insight is appreciated.
Thanks,
Brandon
I am attempting to use GPIO39 on the ESP32-S3-DevKitC-1 with a WROOM-2 chip as an input for a GPIO interrupt. I have been having trouble doing so successfully, with unexpected interrupt behavior occurring on that pin - different from behavior when switching to another GPIO (GPIO21 for example). Specifically, I noticed the interrupt occurs earlier on GPIO39. I first attributed this to the lack of pull-up and pull-down resistors on this pin, however the device which is sending the interrupt does not specify requiring a pulldown resistor for its interrupt pin.
In note 8 for Table 2-1 of the ESP32-S3 Datasheet, it specifies burning GPIO 39's efuse to disable JTAG. This has led me to believe that the JTAG is the culprit for this, and burning this efuse should resolve the issue. Successfully doing so via the command
Code: Select all
espefuse.py --port <port> burn_efuse DIS_PAD_JTAGMight there be another reason GPIO39's behavior is inconsistent/incompatible with being set as an interrupt? Is there perhaps another efuse I am missing that needs to be burned? Any insight is appreciated.
Thanks,
Brandon