ESP32-S3 GPIO 39~42 (JTAG) during early boot stages

[Chipset68]

I encounter an issue with my ESP32-S3 (Espressif DEVKIT-C1-v1.0 N8R2) for an application developed under Arduino IDE (v2.3.2)
Despite I selected "JTAG Adapter : Disabled" in the IDE menu, it seems that these pins (in particular pin 39 and 40) still behave as a JTAG adapter during the early stages of the boot process, before my own application gets started and take control of these pins as plain GPIO.

Issue is that I have hardwired these pins to some H-bridge to control some motor, and therefore, until my application takes control, the motor spin for some short time (during hard reset) or a long time (during upload of an sketch).

I was aware that these pins have the dual role JTAG/GPIO, but since my project requires a lot of GPIO, I did not have the choice but ot use them, and was expecting the "JTAG Adapter : Disabled" will avoid this sort of issue.

On top, now everything is on a PCB, I'd rather avoid to cut some trace and solder an ugly wire bridge of some sort, if avoidable.

I'm pretty sure I'm not the first one to have this type of issue, therefore searched online, but still confused...

From what I read, it seems that the JTAG feature can be totally disabled via eFuses...

I wonder if someone can help me with the 2 below question :
- Will disabling JTAG from eFuse have the expected effect (GPIO39~GPIO42 "quiet" from 1st stages of boot) ?
- How, practically, burn these efuses ? (i read into "espefuse.py" stuff online, but I cannot find it anywhere in the Arduino install folders)

Of course, if someone happen to know other solutions, I'm absolutely interested in them !

Apologies for the newbie topic above.

[Chipset68]

Any chance to guide me on this issue ? Thanks !

[Chipset68]

Hi All,

I finally resolved to try and burn EFUSE_DIS_PAD_JTAG to 1 (default is 0), and no more chit-chat on the pin 39 and 40 during boot, meaning my H-Bridge stays gently off , which was the target. Of course, I will not be able to use these pins for JTAG later on, which anyway I do not know how to use (getting espefuse.py to run was already a bit of a challenge at my skill level, anyway!).

[fjahol]

Hi @Chipset68 ,

Apologies I know this is quite an outdated question but we are having the exact same issue for a university project. We've fully designed and manufactured a PCB and we've discovered this same noise on pins 39 and 40. For most other projects I would never be too concerned with a bit of a noise but the project involves a printhead and when these pins are held high for too long this completely fries the nozzles on the printhead so this quite a big issue for our project. We were able to initially mitigate for this issue by just making sure to have the printhead connector disconnected every time code is uploaded but for some reason (and this happens only occasionally) the JTAG interferes with these pins during booting up the device and leaves the printhead damaged. Burning the JTAG efuse as you suggest sounds like the perfect option to fix this for us and means we can demonstrate our project without having to worry about the printhead frying. The issue is that our project is due very soon and as burning efuses are permanent I am concerned about causing any irreversible issues on the PCB as we will be unable to reorder at this stage. So i guess what I am asking, by disabling JTAG with the efuses this doesn't affect any other functionality of the ESP32S3 chip? All GPIO pins work as intended and there is no issue flashing new firmware? The other thing is our PCB doesn't have a USB to serial chip so we do all our programming over USB OTG. I know these functions have nothing to do with JTAG but just wanting to be overly cautious at this point in the project and I am struggling to find much documentation or other peoples experiences of burning efuses online, so wanting to double check there aren't other consequences that I am aware of! Thanks!

[kev_rm]

I am also experiencing this and I don't think it is limited to boot, it also seems to high during flashing (the entire time of the flash).

This is definitely a bit unsafe IMHO. I don't think this is fixed by the efuse either....

Are there known-safe GPIOs that stay low during boot and flash (and can be used in PWM mode ?