I’m trying to use esptool to download a backup of the tidbyt firmware for restore purposes. However, when trying to run esptool.py flash_id i’m getting wrong boot mode error. Does anyone know how to get the tidbyt into download mode ? I tried momentarily pressing the reset button and also holding the button on startup.
I understand I might be required to open up the unit and manually trigger download mode with a pin short somewhere.
It would be great if Tidbyt open-sourced the firmware code or at least provided downloadable firmware binaries.
Here is how to do it people. It’s the standard esp32 “short pin IO0 to GND” during flash. I just soldered a little wire to IO0 of the esp32, then pressed the other end of the wire to the esp32 metal case (GND). I haven’t flashed new firmware to it yet but I have used the following command to download the firmware stored in flash : esptool.py -p /dev/cu.usbserial-110 read_flash 0x0 0x800000 fw-backup-8M.bin
Woah, really surprised this was necessary. We use esptool.py all the time during development here, and even use it in the factory to probe and test the device, so it should “just work”.
On the board itself, IO0 is connected to an auto-programming circuit that detects when DTR/RTS are asserted by the USB-UART chip (pretty standard setup for any ESP32 device). So here’s what I get when running esptool.py flash_id on a random Tidbyt:
esptool.py v3.3
Serial port /dev/cu.usbserial-320
Connecting.........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: <redacted>
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4017
Detected flash size: 8MB
Hard resetting via RTS pin...
Perhaps this is a driver issue?
All my other esp32 dev boards flash normally like you describ. This one is actually a factory second so maybe that’s why. I’ll try to run esptool on my Factory first tidbyt and see if it behaves the same.
I did see the trace going from the pin 0 to over to the pull up and then a transistor and serial chip. But yeah, weird. It’s ok, I just drill a second hole in the back plate and put in another button :
So the “factory first” unit I have does work with esptool as expected, while the “factory second” unit does not.
I understand I might be required to open up the unit and manually trigger download mode with a pin short somewhere.
it should “just work”.
This is what I see plugging into USB-C without opening up the unit…
➜ ~ esptool.py flash_id
esptool.py v4.2.1
Found 3 serial ports
Serial port /dev/cu.wlan-debug
/dev/cu.wlan-debug failed to connect: Could not open /dev/cu.wlan-debug, the port doesn't exist
Serial port /dev/cu.usbserial-10
Connecting......................................
/dev/cu.usbserial-10 failed to connect: Failed to connect to Espressif device: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
Serial port /dev/cu.Bluetooth-Incoming-Port
Connecting......................................
/dev/cu.Bluetooth-Incoming-Port failed to connect: Failed to connect to Espressif device: No serial data received.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
A fatal error occurred: Could not connect to an Espressif device on any of the 3 available serial ports.
Triggering the manual download mode via pin 0 (as described above) is how I fixed this particular error.
I’ve got an email into support, as my unit also reports ‘Wrong boot mode detected (0x13)!’.
I really don’t think cracking the case and soldering a wire to short a pin should be required to flash a new firmware when the company says they support flashing your own firmware.
Hey hey folks! I want to give a huge shout out to @rohan at Tidbyt for his amazing support. It turns out that I had to use a USB A-to-C cable to get the proper modes to download firmware. Once I did that, I had no problems dumping the flash contents.
No need to open the device at all, it Just Worked.
Thanks @anoldguy! It could be an issue with the particular cable, or we may have a revision with a hardware bug in USB C-C communication. I’m going to investigate further.
Our production line uses esptool.py on Linux and USB A-to-C cables, so we know for sure that that should work on all Tidbyts that make it through QC.
I’ve tried all different combinations and my factory first always works and my factory second always requires manual boot pin. (shrug) 