ESP8266 SPIFFS Upload Failed: A Suspect USB-to-Serial Adapter

In March 2016 I bought an Olimex MOD-WIFI-ESP8266-DEV. It was a tiny red board built around the ESP8266EX, with 2 MB of SPI flash, a PCB antenna and enough exposed pins to make a breadboard feel briefly important.

The attraction of the ESP8266 was that it was more than a Wi-Fi modem. What I called “the main coolness” at the time was that, instead of driving it entirely through AT commands, I could run an entire application on the chip itself using the ESP8266 Arduino core, Sming, JavaScript tooling then known as Smart.js, or NodeMCU. The ESP8266 itself could be bought for less than £2, which did not hurt. I chose the Arduino toolchain.

The Bad

I installed the ESP8266 board package, added the then-current SPIFFS data-upload tool and cloned the Arduino core repository for its examples.

HelloServer worked like a charm: it compiled and flashed without complaint. The more substantial FSBrowser example also compiled, and the program itself uploaded correctly. The trouble began when I tried to send its SPIFFS image with Tools → ESP8266 Sketch Data Upload.

The upload stopped at apparently random points with errors like these:

Uploading 1028096 bytes from to flash at 0x00100000
............warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
warning: espcomm_send_command: wrong direction/command: 0x01 0x03, expected 0x01 0x04
error: espcomm_upload_mem failed
SPIFFS Upload failed!

Uploading 1028096 bytes from to flash at 0x00100000
............warning: espcomm_send_command: didn't receive command response
warning: espcomm_send_command(FLASH_DOWNLOAD_DATA) failed
warning: espcomm_send_command: wrong direction/command: 0x01 0x03, expected 0x01 0x04
error: espcomm_upload_mem failed
SPIFFS Upload failed!

The address itself did not appear to be the problem. Using esptool, now maintained by Espressif, I could write an ordinary program image to the same region of flash.

That suggested the failure depended on the data rather than the destination.

A suspicious pattern

I inspected the image produced by mkspiffs and noticed long runs of 0xFF bytes. As a deliberately destructive experiment, I replaced those runs with 0xAA and tried again.

The upload completed.

This was not a filesystem repair, nor even a remotely respectable workaround: changing the image contents could invalidate it. It did, however, show that the serial path behaved differently for particular byte patterns. The little blue adapter had begun to look less innocent.

Windows 10 identified the adapter as an FT232R USB UART, and its main chip carried FTDI markings. The date code looked suspicious, and contemporary reports said that FTDI’s Windows driver behaved differently when it detected non-genuine FT232 devices.

Taken together, that made the adapter very likely counterfeit; FTDI does warn that counterfeit FT232 devices exist, and the symptoms matched the reports I was reading at the time. What I could prove directly was narrower but still useful: this adapter-and-driver combination failed on transfers containing particular data patterns, while another serial path did not.

The Good

After ordering a few slightly more expensive replacement adapters, which I hoped were genuine, I started thinking about what I could use while waiting for them to arrive. An Arduino Uno was nearby. It did not provide 3.3 V logic, and I knew using it this way was not recommended. But I couldn’t wait.

So I pressed the Uno into service as a USB-to-serial bridge.

I tied the Uno’s reset pin to ground, holding the ATmega328P in reset so that its I/O pins stayed in a high-impedance state and the microcontroller was effectively disconnected from the UART path. Then I connected the two boards like this:

• Arduino Uno GND to Olimex ESP8266 GND
• Arduino Uno pin 1 (TX) to Olimex pad 3, ESP8266 GPIO1 / U0TXD
• Arduino Uno pin 0 (RX) to Olimex pad 4, ESP8266 GPIO3 / U0RXD

The matching labels look wrong at first sight. They are labelled from the ATmega328P’s point of view; with that processor held in reset, the Uno’s onboard USB interface uses the paths in the opposite direction. The arrangement is visible in the official Uno schematic.

It worked. Both the program and the SPIFFS image uploaded successfully.

That result strongly implicated the original USB-to-serial adapter. It was also satisfying in the particular way that only replacing a purpose-built device with an entire development board can be.

The Ugly

I would not wire it this way today. It worked in the moment, but it was the kind of bench-side improvisation that deserves a raised eyebrow afterward. The Arduino Uno uses 5 V logic, while the ESP8266 is a 3.3 V device; Olimex recommends a 3.3 V USB-to-serial connection and a suitable 3.3 V supply. It was a useful rescue, not a wiring recommendation.