I bought the ESP32P4 devkit and flashed the hello_world example from IDF v5.4.1 on a Ubuntu 24.04 machine. I did not do any modifications to it, just build and flash. When I wanted to verify whether the example works, I noticed that /dev/ttyACM1 disappeared and did not come back when reconnecting the board.
I noticed that the PC fails to recognize the board. dmesg prints the following output in a loop:
12102.125291] usb 1-2.1: new full-speed USB device number 108 using xhci_hcd
[12102.252563] usb 1-2.1: device descriptor read/64, error -32
[12102.484460] usb 1-2.1: device descriptor read/64, error -32
[12102.716220] usb 1-2.1: new full-speed USB device number 109 using xhci_hcd
[12102.843268] usb 1-2.1: device descriptor read/64, error -32
[12103.077552] usb 1-2.1: device descriptor read/64, error -32
[12103.181679] usb 1-2-port1: attempt power cycle
By holding BOOT1 while pressing RESET1 I can trigger a reenumeration when releasing the RESET1 button, but then the loop continues.
When leaving the board disconnected for a while and reconnecting it,
- the host suddenly enumerates it correctly, the /dev/ttyACM1 device appears, but only for 2 seconds
- Then it is reenumerated successfully a second time
- After 2 seconds, it gets back into the failure loop
When running
esptool.py -p /dev/ttyACM1 -b 115200 erase_flash quickly after successfully enumerating the board, I get:
$ esptool.py -p /dev/ttyACM1 -b 115200 erase_flash
esptool.py v4.8.1
Serial port /dev/ttyACM1
Connecting...
Traceback (most recent call last):
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/bin/esptool.py", line 37, in <module>
esptool._main()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1314, in _main
main()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 803, in main
esp = esp or get_default_connected_device(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/__init__.py", line 1193, in get_default_connected_device
_esp = detect_chip(
^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/cmds.py", line 99, in detect_chip
detect_port.connect(connect_mode, connect_attempts, detecting=True)
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 730, in connect
last_error = self._connect_attempt(reset_strategy, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/loader.py", line 606, in _connect_attempt
reset_strategy() # Reset the chip to bootloader (download mode)
^^^^^^^^^^^^^^^^
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/esptool/reset.py", line 46, in __call__
self.port.open()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/serial/serialposix.py", line 338, in open
self._update_rts_state()
File "/home/rw/.espressif/python_env/idf5.3_py3.12_env/lib/python3.12/site-packages/serial/serialposix.py", line 708, in _update_rts_state
fcntl.ioctl(self.fd, TIOCMBIC, TIOCM_RTS_str)
BrokenPipeError: [Errno 32] Broken pipe
That changes something. The enumeration loop stops. The /dev/ttyACM1 device remains. But yet I cannot talk to the ESP32. The MCU also gets quite warm after a while, but I read that may be normal.
I tried the same with different USB cables and on different Linux computers without luck. Did I brick the board?
Hello,
The board is recoverable. It appears that erasing the flash memory also erases the secondary bootloader and this makes the board constantly reset and the chip to consume more power (but in the safe threshold).
Notice that I forced similar behavior here, I took one ESP32-P4-DevKit from the shop and erased its flash memory via esptool (with command "esptool.py --chip esp32p4 -p COMXX -b 460800 erase_flash") and then observed the same behavior and got similar invalid header responses. I also noticed that while flash is empty the chip heats more compared to when bootloader is present, we will forward that info to espressif, seems like something related to the ROM or bootloader behavior and they should take a look at it.
Overall this is strange behavior but some issues are expected with development samples. We appreciate the feedback and as I wrote we will relay the feedback to Espressif themselves.
First try something different - use your LONGEST USB cable and, even, if possible and if you have USB type A male to type A female also connect it to the regular USB type A - type C cable (as sort of USB extension) or maybe connect some USB hubs. The idea of this is to have cabling with higher resistance between the board and the computer.
Now it should be possible to restore the board via esptool. What to do exactly:
1) Find or download esptool or esptool.py. It can be found in Arduino for ESP32 installations or if you can't find it being on your computer you can install it. It is an important tool for ESP32 chips. You can find more info here (but I am sure there are many guides online on how to install it):
https://docs.espressif.com/projects/esptool/en/latest/esp32/installation.html
2) Download the three binaries we place during production and place them in the folder where the executable for esptool is, the binaries are here at the FTP:
https://ftp.olimex.com/TEMP/ESP32-P4-CAM-binaries/
3) Connect the board in question via the USB and put it in forced bootloader mode - this is done by: press and hold button BOOT1, press and release button RST1, release button BOOT1.
4) Open the terminal and navigate to the folder where the esptool executable is. Run the following command (remember to edit according to the COM port given to the board and the exact name of the executable):
esptool.py --chip esp32p4 -p COMXXX -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 80m --flash_size 2MB 0x2000 bootloader.bin 0x10000 camera_lcd.bin 0x8000 partition-table.bin
5) This should revert the board to original state witch proper secondary bootloader and you will able to program it via the USB without the need to press the buttons.
Again make sure to use your longest USB cable or USB extension cable or USB hub, this will solve the issue with rebooting constantly.
The behavior will return if you erase the board. In that case repeat the steps above to revert to default state.
Keep us updated on how it goes.
Thank You for taking the time to reproduce the problem and for Your suggestion. Highly appreciated. A 1.50m USB extension cable was indeed enough to stop the bus enumeration failure and by the command line posted above I was able to recover the ESP.
Unless I run erase_flash, I can now at least flash new images and work with the board to some extent, but only with the extension cable in between.
Thanks again.