SPI flash mode mystery
Posted: Tue May 16, 2017 3:21 amHi,
I have been playing with the ESP8266 for a bit (custom pcb), but my latest batch of esp-12f modules seem to be slightly different (oh, the perils of BangGood) - they've gone from AI-THINKER on the shielding to DOIT. I unfortunately wasted many hours adding capacitors and pullups to try to understand why the core was giving me a crc fail at startup after flashing a nodemcu image for testing. It was then that I discovered the (hidden, why!?) --flash_mode flag to esptool.py, and I was finally able to write an image that booted. (: The mystery is: why does the flash mode makes a difference in this case? (I've never had to specify it before.) I'm actually surprised that the first-stage bootloader cannot/does not query the flash part to determine the channel width...
The flash part is identified as {0xc8, 0x4016}, or GIGADEVICE_GD25Q32. This part should be capable of QIO. My expertise with SPI thus far has been limited to SI/SO pins - never QIO, so I am looking to fill in any knowledge gaps.
Fundamental knowledge questions:
- when I specify --flash_mode, does that affect the flashing process, or simply set a flag within the (offset 0 from base of SPI flash) configuration structure that is read by the stage 1 bootloader? (I am guessing only the latter, as the time to write is the same @ 37s). I was hoping that it would be the former and that would validate that QIO was working because I am able to write/read back the flash from programming mode.
- if the flash part supports QIO, is there any explanation for this failure other than the SPI flash signals IO2/IO3 not being connected correctly? I haven't tried popping the shielding off to verify the signal paths, and I haven't gone to the trouble of hooking ESP8266 pin 9-14 [SPI] up to a logic analyzer.
I'm guessing that the manufacturer goofed on these modules and failed to properly connect the 2 signals necessary for quad-spi-io, which is disturbing, but hopefully not the end of the world for my purposes. We'll see how much the slower flash accesses affect my application - I haven't benchmarked it yet.
Slightly more info:
When I use esptool.py v1.2 [esp-open-sdk/xtensa-lx106-elf/bin/esptool.py] to flash with no flash_mode argument, the binary results in checksum error. With "--flash_mode dio", it's okay. The first few bytes of flash starting at 0x0 are different, and I've come to understand esptool.py is most likely not writing the binary unmolested (eg, it's setting flags).
nodemcu binary: e903 0000 0462 1040 0000 1040 7c67 0000
written with DIO: e903 0240 0462 1040 0000 1040 7c67 0000
written no flags: e903 0040 0462 1040 0000 1040 7c67 0000
cheers,
Greg
I have been playing with the ESP8266 for a bit (custom pcb), but my latest batch of esp-12f modules seem to be slightly different (oh, the perils of BangGood) - they've gone from AI-THINKER on the shielding to DOIT. I unfortunately wasted many hours adding capacitors and pullups to try to understand why the core was giving me a crc fail at startup after flashing a nodemcu image for testing. It was then that I discovered the (hidden, why!?) --flash_mode flag to esptool.py, and I was finally able to write an image that booted. (: The mystery is: why does the flash mode makes a difference in this case? (I've never had to specify it before.) I'm actually surprised that the first-stage bootloader cannot/does not query the flash part to determine the channel width...
The flash part is identified as {0xc8, 0x4016}, or GIGADEVICE_GD25Q32. This part should be capable of QIO. My expertise with SPI thus far has been limited to SI/SO pins - never QIO, so I am looking to fill in any knowledge gaps.
Fundamental knowledge questions:
- when I specify --flash_mode, does that affect the flashing process, or simply set a flag within the (offset 0 from base of SPI flash) configuration structure that is read by the stage 1 bootloader? (I am guessing only the latter, as the time to write is the same @ 37s). I was hoping that it would be the former and that would validate that QIO was working because I am able to write/read back the flash from programming mode.
- if the flash part supports QIO, is there any explanation for this failure other than the SPI flash signals IO2/IO3 not being connected correctly? I haven't tried popping the shielding off to verify the signal paths, and I haven't gone to the trouble of hooking ESP8266 pin 9-14 [SPI] up to a logic analyzer.
I'm guessing that the manufacturer goofed on these modules and failed to properly connect the 2 signals necessary for quad-spi-io, which is disturbing, but hopefully not the end of the world for my purposes. We'll see how much the slower flash accesses affect my application - I haven't benchmarked it yet.
Slightly more info:
When I use esptool.py v1.2 [esp-open-sdk/xtensa-lx106-elf/bin/esptool.py] to flash with no flash_mode argument, the binary results in checksum error. With "--flash_mode dio", it's okay. The first few bytes of flash starting at 0x0 are different, and I've come to understand esptool.py is most likely not writing the binary unmolested (eg, it's setting flags).
nodemcu binary: e903 0000 0462 1040 0000 1040 7c67 0000
written with DIO: e903 0240 0462 1040 0000 1040 7c67 0000
written no flags: e903 0040 0462 1040 0000 1040 7c67 0000
cheers,
Greg