ESP8266 DIO mysteries SOLVED

tmpC35BSo – ESP8266 – it turns out that some of the newer WEMOS boards require DIO mode for programming the FLASH chips – they just either will not program or will appear to but then not run if you use QIO programming mode (a flag used when flashing).

At long last I have some answers – read on!

I read this interesting little article – take a look…

You will see that if the FLASH is programmed in DIO mode, in theory at least, we should be able to get GPIO9 and GPIO10 back as general ports!!

So the first question here is… can we program ANY ESP12 in DIO mode? Or just some and why the difference?

Well, it is down to the FLASH chips – if you look at what SEEMS to be an ESP12 on the Chinese rip-off WEMOS boards, they do indeed say WEMOS so we are not looking at ESP12s but custom sub-assemblies – looks like they found a cheaper FLASH chip.

So armed with a “WEMOS” board (the ones with an OLED on them) that requires DIO programming mode, I went off to have a look at my EASYGPIO code which I’ve been using for years with the Espressif SDK. Sure enough,  GPIO9 and 10 ARE supported – no different to other pins.

I quickly added in tests for my ESP8266 code to set GPIO9/10 to outputs – and select on or off depending on a parameter.

Interestingly on power up these both appear to be outputs – because my test LED lit up quite brightly – but they could be just decent pull-ups.  Never mind, GPIO10 SURE ENOUGH turns on and off. That’s a winner – but only in DIO mode flashing.

I then focussed on GPIO9. Well, it DOES turn on and off – no doubt about it…  however, the mere act of programming GPIO9 as an output and setting it to 0, ensures that the ESP8266 reliably REBOOTS after a few seconds.

I then set GPIO9 as an input and monitored it – the default state being 1.  No problem there but taking it physically to ground – resulted in the board locking up. This is all at odds with the article I linked to further up suggesting GPIO9 and 10 were both available as general purpose GPIO.

That set me off on another search which came back with this informative discussion..

It turns out that although GPIO9 is not needed for DIO mode it is still connected to the flash – so that’s a NON-starter – we don’t want to go poking around under that metal can.

So – DIO mode gives us one extra GPIO pin (10) in reality.

But can any old ESP8266 board be programmed this way?

That would be no. On test, a standard board appeared to program but then it’s little blue light came on and it was dead. Thankfully reprogramming in QIO mode brought it back to life.

So now we know! I wonder which mode the genuine WEMOS boards use?

The Upshot

As a result of this – in my ESP8266 code which you can find in the menu on the right, I have added a new command, simple for now, {dio10:x] where x is 0 or 1. This makes GPIO10 (SD3) available but only in those boards which bring the pin out – and which use the DIO mode. I would not like to think what would happen if you use it on a QIO programmed board. This applies only to my software version 2.2.17 onwards. Still – that’s one more pin than most of us had until now. I did check to see if writing 0 to GPIO10 made the FLASH read-only – it does not – but I can’t guarantee that other boards will behave identically – if you must try to use GPIO10 in DIO mode – it is on your head Smile


14 thoughts on “ESP8266 DIO mysteries SOLVED

  1. I don’t claim to understand what is happening but I now have success by uploading using the parameter “dout” instead of dio or qio

  2. I struggled programming various Sonoff devices using just a USB FTDI adapter. I had to also supply an external 3.3v power supply to the Vcc pin (with common ground) for the flashing process to work as my laptop did not provide sufficient current via the USB cable on its own. This took me ages to find out as it wasn’t a well documented issue elsewhere online and I didn’t need auxiliary power when programming Wemos and NodeMCU clones, just the Sonoffs

    1. Thanks for that info Darren. I’ll try that, but strangely I can blow Arendst firmware to this Sonoff without hitch using just USB FTDI.

      1. Ahh… my suggestion probably won’t resolve your issue then as one would assume that if there’s enough 3v3 juice to flash one lot of firmware, it could manage any firmware. It also confirms that you’re following the correct flashing procedure (so not the usual newbie error of not getting the ESP into flash mode correctly).

        My issue is probably just my Dell laptop not having enough USB ‘oomph’ for the job and this would explain why Google doesn’t reveal any/many others with my problem.

  3. Is it just me but..
    I have tried blowing the roms to a new Sonoff S20 using several different upload techniques. I have tried qio and dio. The upload seems to go ok but there is no serial response from the device. I can successfully upload to Wemos, NodeMcu, bare ESP8266 etc. Any thoughts?

  4. Pete,

    No wonder if driving GPIO9 low resets the ESP8266: it is most of the time connected to the SPI Flash /HOLD input that puts the DO pin in Z-state when low… The ESP8266 then just can’t get access to the Flash any more and the watchdog just resets the chip.

    As for GPIO10, it is usually connected to the /WP (Write Protect) input, so even if it does not reboot the chip like GPIO9, there is a chance that if you drive it low, you can no longer write to the chip…

    It means that even if they are made available on the module, these pins are only meant to drive an external SPI Flash chip, unless these are not connected internally like it is supposed to be for ESP12-D modules, see my comment on HaD:

    “The SPI Flash chips have 8 pins: VCC, GND, CLK, /CS, DI, DO, /HOLD and /WP. The first 3 pins are obvious, the 5 remaining ones have different functions depending on their operating mode.

    In Standard SPI mode, /CS pin enables and disables device operation, /WP pin prevents the status register from being written, thus from 4KB sector to the entire memory array can be hardware protected. /HOLDl pin is used to pause the device and put the DO output pin in Z-state. DI is MOSI and used to write instructions, address or data to the device, while DO is MISO and used to read data or status from the device

    In DOUT mode, this is the same as standard SPI, but DI becomes IO0 and DO becomes IO1, and are used as 2-bit output pins to read data or status from the device. Please note that the single pin DI is still used as MOSI to write instructions, address or data to the device.

    In DIO mode, this is the same as DOUT, but DI (as IO0) and DO (as IO1) are also used to write addresses and data to the device. Please note that the single pin DI is still used as MOSI to write instructions.

    In QOUT mode,, this is the same as standard SPI, but the /WP pin becomes IO2 and the /HOLD pin becomes IO3, and DI (as IO0), DO (as IO1), /WP (as IO2) and /HOLD (as IO3) are used as 4-bit output pins to read data or status from the device. Please note that the single pin DI is still used as MOSI to write instructions, address or data to the device.

    In QIO mode, this is the same as QUOT mode, but DI (as IO0), DO (as IO1), /WP (as IO2) and /HOLD (as IO3) are also used to write addresses and data to the device. Please note that the single pin DI is still used as MOSI to write instructions.

    In terms of performance, QIO > QOUT > DIO > DOUT > SPI, bit not all SPI Flash chips support all the modes.

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

    OTOH, DIO/DOUT modes free the GPIO 9 and 10 for other uses, unless they are tied to the /WP and /HOLD SPI FLash chip input pins inside the module…

    In Pete’s case, the WEMOS manufacturer is to blame: they chose a different ESP12 module.This pin diagram from AI-Thinker seems to indicate that GPIO9 and GPIO10 can only be used on ESP12-D (Dual?), not on ESP12E or ESP12-Q (Quad?):

    And of course, GPIO 9 & 10 are not available on ESP12-S, and ESP12-F is just the same as ESP12-E but with better PCB antenna.”

  5. I’m confused about which boards are which here. Can you take pictures of the WeMos and the WeMos knock-off?

    Any difference between the different revisions of the real WeMos boards?

    1. My understanding (and it may not be 100% true in all cases) is that the genuine Wemos boards have rounded edges whereas many of the clones are square edged to all sides. I’m just basing this information on having bought loads and the slightly more expensive ones having round edges!

      I’ve only had problems with one clone board – the microUSB port came away from the board after only a few uses. This doesn’t concern me too much as it was just one cheap board out of several dozen I’ve bought over the last 2 years. The Wemos/Wemos clones as they are my preferred ESP8266 board due to being nice and small, having, built in microUSB for easy programming/power supply and enough pins broken out to be very versatile indeed. I find the twin (and more recently the triple) base boards really useful too (I’m not sure if the triple boards are genuine WeMos items).

    2. No because I don’t think I have any genuine ones – I just get the cheap ones from AliExpress which SOME say are knock-offs. In response to the response below – mine with the OLED does have rounded corners.

      Squonk below seems to have filled in the missing blanks – so despite what you may see elsewhere on the web it would appear that you need to forget about GPIO9 – and use GPIO10 AT YOUR PERIL. bearing in mind it’s possible connection to the write protect pin – and of course don’t even think of even that if you did not explicitly program the board in DIO mode.

      For myself…. hopes of extra GPIO have now subsided – I’ll stick with my Nano-based i2c peripheral for more IO…. which leads me onto this morning’s challenge, finding out why I can’t see an INA219 on the bus.

Comments are closed.