Discussion of QIO DIO QOUT DOUT flash modes?

[cnlohr]

I finally have a custom single-layer design working for my ESP32. Something sent me for one big loop for quite some time, though. When I tried flashing it the same I did the normal boards, it would go off into reboot-mania constantly crashing and rebooting, always sending something to the effect of:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0xfc0008ff,len:834623

Which had me stumped for a good long time before I randomly tried switching flash mode to QOUT to which it immediately booted and performed expertly.

What decides what boot modes should be used?

What is the difference between the D/Q boot modes?

Does the D boot mode mean we can use GPIO9+10 like on the ESP8285?

[ESP_Angus]

That's a new one by me, I hadn't seen failing to boot in DIO mode before!

All the SPI Flash manufacturers call the following things by slightly different names. I'm going to use Gigadevice's command names in this post because they map well to the Espressif names. However your SPI Flash chip's datasheet may use different names. The command hex codes should be the same, though.

Not all chips support all of these modes. The datasheet is the best source to know what supports what.

• DIO - SPI host uses the "Dual I/O Fast Read" command (BBh). Two SPI pins are used to write the flash address part of the command, and to read flash data out. Therefore these phases need half the clock cycles compared to standard SPI.
• DOUT - SPI host uses the "Dual Output Fast Read" command (3Bh). Two SPI pins are used to read flash data out. Slightly slower than DIO, because the address is written via the single MOSI data pin.
• QIO - SPI host uses the "Quad I/O Fast Read" command (EBh). Four SPI pins are used to write the flash address part of the command, and to read flash data out. Therefore these phases need a quarter the clock cycles compared to standard SPI.
• QOUT - SPI host uses the "Quad Output Fast Read" command (6Bh). Four SPI pins are used to read the flash data out. Slightly slower than QIO, because the address is written via the single MOSI data pin.

In terms of performance: QIO > QOUT > DIO > DOUT. I'm fairly sure the flash cache issues 32 byte reads each time, so QOUT or QIO are substantially faster than DIO or DOUT.

However, because the command itself (and the read status command) are sent using standard SPI, doubling the SPI clock speed is a bigger speed boost than switching from DOUT to QIO.

ESP-IDF defaults to DIO because some flash chips use a mode bit to enable QIO & QOUT support, and this can vary between manufacturers. The chips used in ESP-WROOM modules do not enable QIO correctly without an additional command. A modification is pending in esp-idf which will use the Flash ID to determine which initialisation sequence should be used to enable QIO or QOUT mode.

What flash chip do you have? I'm guessing it's a chip which only supports DOUT/QOUT in its command set, not QIO/DIO.

If using DIO/DOUT mode, GPIOs 9 & 10 are available for other uses. However note that if they are wired to the SPI flash chip (as they are in WROOM, for example) then the SPI flash chip may use them for other pin functions. Consult the SPI flash chip data sheet to be sure.

[kutysam]

Hi there,

I've an issue with my chip too. It is an esp8266 | ESP-01 chip

I managed to flash nodemcu onto it and it booted up fine.
But when I flashed arduino ide program onto it, it crashed constantly.
Other ESP-01 chips worked well.

After changing the mode to DOUT, it worked for this 'faulty' chip.

Any idea how can i see which modes the chip support?

Thank you.

[ESP_Angus]

This forum is for ESP32. For ESP8266 support, try bbs.espressif.com or other sites.

After changing the mode to DOUT, it worked for this 'faulty' chip.

Any idea how can i see which modes the chip support?

There are two factors for which SPI flash modes work, but they don't depend on the ESP8266/ESP32 chip (the ESP8266/ESP32 chip itself will support all modes):

• The PCB or module design (in this case the ESP-01 design, by whoever did this.) It may not have the QIO/QOUT pads routed to the flash chip. Or maybe one is not soldered properly.
• The flash chip model. You can find this with "esptool.py flash_id" and then looking up the hex ID, or by reading the SPI flash chip. Not all SPI flash chips support all modes, the SPI flash datasheet explains the commands it supports.

[8785ben]

Hello
Any update with this ?
I'm trying the ESP-WROOM32 and the first stage bootloader does not read the flash correctly in QIO mode and keeps resetting. QOUT mode works fine as well as DOUT and DIO.
Second stage bootloader works well with QIO and all other modes.
I guess there is a bug or limitation in the first stage bootloader and it cannot be corrected since it is in the internal ROM of the ESP32 but I would like to confirm. Second stage bootloader (esp-idf) works now well with GigaDevice GD25Q32C.

First boolader configured in QIO mode with esptool:

Code: Select all

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QIO, clock div:1
load:0x3fff0018,len:4
load:0xffffffff,len:-1

ets Jun  8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QIO, clock div:1
load:0x3fff0018,len:4
load:0xffffffff,len:-1

ets Jun  8 2016 00:22:57
...keeps resetting

First bootloader configured in QOUT with esptool:

Code: Select all

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:QOUT, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:8032
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:15492
entry 0x40079344

I (30) boot: ESP-IDF v3.1-dev-531-g5d4c4b19 2nd stage bootloader
I (30) boot: compile time 22:34:50
I (30) boot: Enabling RNG early entropy source...
D (36) qio_mode: Probing for QIO mode enable...
D (41) qio_mode: Raw SPI flash chip id 0x1640c8
D (45) qio_mode: Manufacturer ID 0xc8 chip ID 0x4016
I (50) qio_mode: Enabling default flash chip QIO
D (56) qio_mode: Initial flash chip status 0x2
D (60) qio_mode: QIO mode already enabled in flash
D (65) qio_mode: Enabling QIO mode...
D (69) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff)
D (76) boot: magic e9
D (78) boot: segments 04
D (80) boot: spi_mode 01
D (83) boot: spi_speed 0f
D (86) boot: spi_size 02
I (88) boot: SPI Speed      : 80MHz
I (93) boot: SPI Mode       : QIO
I (97) boot: SPI Flash Size : 4MB
D (101) bootloader_flash: mmu set paddr=00000000 count=1
D (106) boot: mapped partition table 0x8000 at 0x3f408000
D (111) flash_parts: partition table verified, 3 entries
I (117) boot: Partition Table:
I (120) boot: ## Label            Usage          Type ST Offset   Length
D (128) boot: load partition table entry 0x3f408000
D (133) boot: type=1 subtype=2
I (136) boot:  0 nvs              WiFi data        01 02 00009000 00006000
D (143) boot: load partition table entry 0x3f408020
D (148) boot: type=1 subtype=1
I (152) boot:  1 phy_init         RF data          01 01 0000f000 00001000
D (159) boot: load partition table entry 0x3f408040
D (164) boot: type=0 subtype=0
I (167) boot:  2 factory          factory app      00 00 00010000 00100000
I (175) boot: End of partition table
D (179) boot: Trying partition index -1 offs 0x10000 size 0x100000
D (185) esp_image: reading image header @ 0x10000
...proceeds normally

[WiFive]

I guess there is a bug or limitation in the first stage bootloader and it cannot be corrected since it is in the internal ROM of the ESP32 but I would like to confirm.

Yes I believe that is correct the rom bootloader has limited support for flash cmd/reg settings to switch to qio mode so may only work with certain flash chips.