Disable USB during ROM boot?

[simpkins]

On the esp32s3 chip, is it possible to completely disable USB functionality during ROM boot, so that the USB pull-up on GPIO 19/20 is not enabled until after the application starts and initializes the TinyUSB driver?

I would like to implement a USB HID device with a custom descriptor, and I would like the device to avoid being enumerated until the application starts and initializes the TinyUSB stack. With the default behavior, it shows up as the Espressif USB Serial/JTAG device first, then once the application boots it re-enumerates with the custom HID descriptor. This behavior ends up causing problems with some hubs that only support HID devices, and reset the device power if a non-HID device is connected (some KVM switches do this).

I have tried burning the DIS_USB_SERIAL_JTAG and DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE eFuses, but these do not appear to fully disable USB during ROM boot. The device appears to still enable the data line pull-up, but does not respond to USB setup requests. This causes hosts to report errors before the application starts and initializes the TinyUSB driver. e.g., when plugging in to a linux host:

Code: Select all

[Sun Sep  4 14:34:22 2022] usb 3-9.2.1: new full-speed USB device number 79 using xhci_hcd
[Sun Sep  4 14:34:22 2022] usb 3-9.2.1: device descriptor read/64, error -32
[Sun Sep  4 14:34:22 2022] usb 3-9.2.1: device descriptor read/64, error -32
[Sun Sep  4 14:34:22 2022] usb 3-9.2.1: new full-speed USB device number 80 using xhci_hcd
[Sun Sep  4 14:34:22 2022] usb 3-9.2.1: device descriptor read/64, error -32
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: device descriptor read/64, error -32
[Sun Sep  4 14:34:23 2022] usb 3-9.2-port1: attempt power cycle
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: new full-speed USB device number 81 using xhci_hcd
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: New USB device found, idVendor=6666, idProduct=1234, bcdDevice= 0.01
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: Product: HID Example
[Sun Sep  4 14:34:23 2022] usb 3-9.2.1: SerialNumber: f412fa420800
[Sun Sep  4 14:34:23 2022] input: HID Example as /devices/pci0000:00/0000:00:14.0/usb3/3-9/3-9.2/3-9.2.1/3-9.2.1:1.0/0003:6666:1234.0410/input/input981
[Sun Sep  4 14:34:24 2022] hid-generic 0003:6666:1234.0410: input,hidraw4: USB HID v1.11 Keyboard [HID Example] on usb-0000:00:14.0-9.2.1/input0

I have not yet tried burning the DIS_USB or USB_PHY_SEL fuses. The documentation is not particularly clear to me about whether these will help, since USB OTG is configured to use the external phy by default. I figured I would ask here before potentially bricking a board.

In the sdkconfig I have the console configured to only go to the UART, and have disabled the secondary console. I haven't 100% confirmed that the pull-up is enabled by the ROM boot rather than early in the application bootloader, but I don't see anything in the bootloader that appears like it would change the USB state.

I am specifically using the Unexpected Maker FeatherS3 board: https://esp32s3.com/feathers3.html
This is using the internal USB phy.

[simpkins]

Burning the USB_PHY_SEL eFuse appears to be what is needed here. With this fuse enabled, the board does not pull-up the USB data line until USB is activated by the application.

[yohnsee]

Burning the USB_PHY_SEL eFuse appears to be what is needed here. With this fuse enabled, the board does not pull-up the USB data line until USB is activated by the application.

Dear simpkins,
I recently got started with ESP32-S3 programming, and there is one issue I can't get my head around. I created a custom board using ESP32-S3-WROOM-1U, and tried to carefully chose which pins to use as GPIO and leave out the strapping pins and other special pins. But as my research showed no restrictions using the GPIO19 and GPIO20 (USB data lines), I included them. But after soldering the board together I noticed, that these two pins behave problematic for my application. GPIO20 has ~175ms high state after reset, then it works as I request in program (output pin with low state as start). GPIO19 is the same, only difference is that it only has ~110us glitch according to my scope. Burning the above mentioned fuse did not help my case, so I would like to ask, if I am doing something wrong, or do I need to burn other fuses as well?
I am programming in Arduino IDE, I usually upload my first sketch through UART, after that I use OTA programming.