No problem, glad you tracked it down. So basically you had a DualIO FLASH chip versus a Quad IO FLASH chip (aka QSpi for QIO) for Quad-Width SPI and that is how you fixed it.
I took a look at this today, it seems there are a couple of points of confusion, first is when I talk about esptool, I mean the python script from espressif which gets bundled with platformio tools. I strongly recommend you use the supported tools from Espressif for bring-up and if you plan long term support of your module then you should plan for a means of initial programming via this tool since it has all the manufacturer support logic built in.
This script does effectively the same thing as the C port from Christian in esptool-ck but it is not used in the building/flashing of devices from a Linux host. Both have their place and it seems you found that newer modules and their extended header variants are not supported by the older version of the tools and bootloader. Since the esptool-ck has not been updated in years, maybe you should take a look at updating it for Christian.
Second, the old version of platformIO and the version which is used originally by Gus to develop the mavlink firmware used platformIO tools is espressif8266@1.8.0 has LOTS of changes for new clocks, modes, Flash chips, etc.
So an interesting diff I did is between the Python version I used recently and the original 1.8.0 version of platformio tools. The header format is documented here
Here is the header bytes of the original 1.2.2 image as built by @dogmaphobic
$ hexdump -C firmware-1.2.2.bin|head -2
00000000 e9 01 00 20 9c f2 10 40 00 f0 10 40 68 05 00 00 |... ...@...@h...|
00000010 10 10 00 00 50 f5 10 40 1c 4b 00 40 cc 24 00 40 |....P..@.K.@.$.@|
This is (according to docs):
Image header: Magic number (e9), one (1) segment, 00 (QIO SPI FLASH Mode), 20 (high 4 bits) 0=1MB, 2=20Mhz clock, entry address 0x9c f2 10 40
Extended header: 00 Wp pin, f0 10 40 (drive settings for Bootloader), chipID 68 05, min chip rev 00, reserved bytes, etc
I then used the latest version of platformio and the output of the build is the same:
$ hexdump -C mavesp-esp01_1m-1.2.2.bin |head -2
00000000 e9 01 00 20 9c f2 10 40 00 f0 10 40 68 05 00 00 |... ...@...@h...|
00000010 10 10 00 00 50 f5 10 40 1c 4b 00 40 cc 24 00 40 |....P..@.K.@.$.@|
How come? Well, in the platformio.ini file you HAVE to use 1.8 tools to FLASH a 1MB board.
Well, it turns out this is because to flash an esp01_m (1MB module), you must use esptool version bundled with the 1.8 tools which is esptoolpy 1.2.0.1. This is where it gets really interesting because if you diff that version of the script with the latest, you will find the extended and original image header versions have augmented meanings! See the ESPTool doc for details.
So what did we learn? Newer versions of the module can now have:
- 32, 64MB SPI FLASH
- More FLASH Quad/Dual (QIO/DIO) IO options
- More clock speeds
- Support for ESP32 variants
And the most important logic in the newer version of the script detects the type of device by the date codes in the ROM bootloader! This means newer modules or variants will need the new esptool script to flash them properly!
There is also some really neat save/restore params, and probe/detect and reset logic as well as auto-baud support for the bootloader. Whats more all of these options are available from the command line for flashing variants of the module you may find.
I saw your post on porting PX4 Firmware to Teensy, that is very cool. I did something similar in the past for STM32F7 before it was mainline, I also have a port to SAME70 but have since moved to my own firmware design since the bottom level is MAVLink anyhow. Seems the reason you want this esptool port in your design is so that you can use the FirmwareHelper plugin in QGC to flash the ESP firmware.
Not really needed FYI since you can HTTP to the device as an AP and then just flash from the webpage 