Possible bug? bootloader hook from example seems to have bricked USB OTG device capability
Posted: Fri Oct 13, 2023 10:53 am
So I'm developing a usb device using an esp32-s3, and after getting a prototype working I decided to copy the bootloader hooks which changed registers into the project from this example which disable the pullup on D+ at boot time to prevent the wrong descriptor getting retrieved (Example code from https://github.com/espressif/esp-iot-so ... ot_hooks.c)
void bootloader_before_init(void) {
// Disable D+ pullup, to prevent the USB host from retrieving USB-Serial-JTAG's descriptor.
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_PAD_PULL_OVERRIDE);
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_DP_PULLUP);
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_USB_PAD_ENABLE);
}
After doing this the usb OTG device does nothing (no usb activity), so I removed the hook and reflashed after powering off (and holding reset down for a few seconds).
Still nothing from the USB (can't even start the bootloader, can still connect over UART), so I tried reversing the bootloader hook in case it had been persisted in some way.
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_PAD_PULL_OVERRIDE);
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_DP_PULLUP);
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_USB_PAD_ENABLE);
Still nothing, so did a full erase, power off and compiled and flashed the usb_hid example still nothing. To be absoluetly sure I backedup from an untouched working board (usb example ran and bootloader worked over USB OTG) the firmware and flashed to the faulty board overwriting all the flash.
esptool.py --baud 115200 --port COM8 read_flash 0x0 0x800000 fw-backup-8M.bin
esptool.py --baud 115200 --port COM16 write_flash 0x0 fw-backup-8M.bin
Still nothing on the USB OTG, on the board that had the bootloader run on.
Thinking it was a faulty board, I then tried the same bootloader hook with register changes on the good board that I just confirmed worked, exactly the same thing happened and despite trying everything once I'd run the hook just once, (despite erase, reflash, power off, etc.) the USB OTG was just not showing any activity on the PC (usb trace showed nothing when it was plugged in with a standard usb example or trying to enter download mode). Checked the fuses just in case before and after no changes.
Really confused as the register changes in the hook seems to have had some permanenet effect that persists after reflashing/power off and has therefore bricked the USB OTG Device functionality, don't understand how this is possible (as fuses are untouched)? Is this the case, and this is some kind of rather severe bug that can brick USB OTG device functionality or is there something else going on that I've missed?
This is the boards I've been using: https://github.com/Freenove/Freenove_ES ... ROOM_Board
Thanks,
void bootloader_before_init(void) {
// Disable D+ pullup, to prevent the USB host from retrieving USB-Serial-JTAG's descriptor.
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_PAD_PULL_OVERRIDE);
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_DP_PULLUP);
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_USB_PAD_ENABLE);
}
After doing this the usb OTG device does nothing (no usb activity), so I removed the hook and reflashed after powering off (and holding reset down for a few seconds).
Still nothing from the USB (can't even start the bootloader, can still connect over UART), so I tried reversing the bootloader hook in case it had been persisted in some way.
SET_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_PAD_PULL_OVERRIDE);
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_DP_PULLUP);
CLEAR_PERI_REG_MASK(USB_SERIAL_JTAG_CONF0_REG, USB_SERIAL_JTAG_USB_PAD_ENABLE);
Still nothing, so did a full erase, power off and compiled and flashed the usb_hid example still nothing. To be absoluetly sure I backedup from an untouched working board (usb example ran and bootloader worked over USB OTG) the firmware and flashed to the faulty board overwriting all the flash.
esptool.py --baud 115200 --port COM8 read_flash 0x0 0x800000 fw-backup-8M.bin
esptool.py --baud 115200 --port COM16 write_flash 0x0 fw-backup-8M.bin
Still nothing on the USB OTG, on the board that had the bootloader run on.
Thinking it was a faulty board, I then tried the same bootloader hook with register changes on the good board that I just confirmed worked, exactly the same thing happened and despite trying everything once I'd run the hook just once, (despite erase, reflash, power off, etc.) the USB OTG was just not showing any activity on the PC (usb trace showed nothing when it was plugged in with a standard usb example or trying to enter download mode). Checked the fuses just in case before and after no changes.
Really confused as the register changes in the hook seems to have had some permanenet effect that persists after reflashing/power off and has therefore bricked the USB OTG Device functionality, don't understand how this is possible (as fuses are untouched)? Is this the case, and this is some kind of rather severe bug that can brick USB OTG device functionality or is there something else going on that I've missed?
This is the boards I've been using: https://github.com/Freenove/Freenove_ES ... ROOM_Board
Thanks,