Flashing HC 2019 Code

Hackitt and BodgittThis entry is now incorporated into the main Home Control blog entry. This is for the people who’ve been trying out my software (or thinking of trying it out) on the ridiculously cheap (£1.40) but very reliable, powerful and comprehensive ESP12 WIFI processor board and those who’ve gone ahead and gotten some boards we made – all referenced in earlier blogs. For the latest on how to FLASH the chips see this blog update.

Essentially the assumption here is that you have an ESP-12F-based )(or variation such as ESP-12E) board of some description and that GPIO0 is used as a programming button (held to ground to program etc) – and also as a web setup button.

Home Control 2017

Let me explain the difference between programming and setup. GPIO0 is set up permanently by Espressif as the pin to hold LOW before and during power-up to put the board into programming mode to replace the firmware (which may or may not exist on purchase… could be that AT-Command firmware, LUA or something else). Web setup is just something myour software does – it’s not the only software to do so. It may use GPIO2 or more likely GPIO0 AFTER power-up to put the unit into a mode where it acts as an access point, allowing setup for, for example SSID and password.

Note: These blog entries will never all be up to date – too many of them – the WORD manual that comes with the ESP-GO source code on BitBucket is the most up to date available.

All other I/O pins are available for one use or another including GPIO16 – take note of other blogs describing wiring and power unless you’re using something like a node-mcu board which just plugs into USB. The software works alongside Node-Red – again described in the home control blog – what’s new here is that OTA now works and you don’t need a development environment to program up the code which  I developed with lots of help from others, using the unofficial Development Kit in Windows, as you can just use the latest ROMS. The software will react to MQTT commands and also commands coming into the serial line at 115k baud (serial commands are the same as MQTT payloads but no topic required).

tech.scargill.net - home controlI worked with Richard Burton to get RBOOT working with ESP-GO – it is his software which allows for OTA (remote updating) when developing, in my case, in C on the ESP8266.

With OTA working (including from an external location) I thought I might try taking the ROMS and blowing a chip from them rather than from the editing system – that way others can benefit. Note the main rom is now called rom.bin not romx.bin – location is the same however at 0x2000.

flashing

Well, I went to get the NODEMCU flasher which was always good – so after a couple of blind alleys – I got to this link..

As you can see, with the flasher, the RBOOT rom loads at 0x00000 and ESP-GO main code runs at 0x02000. Unlike me, make sure BOTH ROMs are ticked on the left.. as the first one is so short it shows little or no sign of activity. I found I could flash at 468kbaud, you may or may not wish to play safe at 115k baud.  You may also note there is an additional file needed above – in SDK 2.0 and above, on first installation this is needed. See THIS blog entry for up to date information.

So – you blow the software onto the ESP8266 board (here is the link to the NodeMCU – no guarantees as it isn’t mine), now what?

A reminder – what will ESP-GO do?

  • Turn outputs on and off with optional timeouts
  • Read inputs
  • Handle RGB Serial LEDs (up to 300 of them assuming you have enough 5v power)
  • Handle PWM 12v LEDs (assuming you have a 12v source and driver hardware such as Mosfets)
  • Act as a LED clock (and a nice one too) with 60 serial LEDs.
  • a TON of other things including handling DS18B20, DHT11, DHT22, talking to Nextion displays (see the Serial Nextion blog), talk to various I2c devices and displays, talk to some SPI displays and WAY more – all in the Home Control blog. Add to that the power of Node-Red and you have the basis for a very good and reliable complete home control system.

But first the unit needs to be setup. After programming and then resetting or power-cycling the ESP12 (suggest hooking a LED and resistor to GPIO13 and down to ground) – the light will start flashing – within a second or so – hold GPIO0 (or GPIO2 depending on defaults in the current ROMS – see power-up messages coming out of the serial at 115k baud)  to ground for say 10 seconds and let go (DON’T press for the first 100ms of turning on – JUST after turning on or resetting will do – if you come in early (and if the current pin in use is GPIO0)  it will go into programming mode – of course if you don’t program it, no harm done – just reset and try again).

NOW you can access the board with your mobile phone WIFI as “hack-Setup” and once connected use the phone browser to go to 192.168.4.1/wifi/wifi.tpl and you get that nice setup on the right above which needs at least one router SSID and password, two if you have them available (second is a backup) – the address of an MQTT broker and username and password and that’s really all that is essential to start off.

Once everything is up and running , the LED on GPIO13 should be flashing very briefly (i.e. off most of the time) – a variation you can setup by commands uses an RGB LED to give more meaningful use (yellow power up, green working, orange working on it, red dead – throw in the bin etc).

You can now talk to the board via MQTT… or the serial port at 11500 baud (you could use my serial terminal.

If using the serial, fire {debug} at it – if using MQTT – then assuming you’ve given it the name “fred” then the same command would be – topic:  fred/toesp and the payload would be {out4;1} or {out4:0} to flick GPIO4 on or off (or if your board is mis-labelled as some are – GPIO5).   The Home Control blog entry goes into the rest of this in detail.

Note that if you DON’T set up an MQTT broker, the unit will try to connect to MQTT and eventually reset and start again. This is deliberate. You MUST setup an SSID, an MQTT broker and once running you should use the ESPLOGIN mode or similar to send the time to the unit shortly after power up then every 12 hours or so. Again this is detailed in the home control blog… it’s quite simple.

The rest is up to you.  I use this with my Node-Red software and I have a node for setting up the time and date on the boards…  it is called node-red-contrib-esplogin

Node-Red controls - Peter Scargill

That log-in node incidentally is available here.

That’s it for now… I’m quite chuffed the OTA now works. This of course is directly relevant to the Nextion WIFI Display project.

You can get the three BIN files from:

roms.webutu/rboot.bin

roms.webutu.com/rom.bin

roms.webutu.com/esp_init_data_default.bin

IMPORTANT NOTE: If you choose to use ROMS rather than compiling code, you will need to keep up with the BITBUCKET repository changes as these ROMS will be updated when I make changes – for example it is now standard to use GPIO0 as an input only with GPIO16 being used as an output. There is also a DOC file in the Home Control blog and that is the only up to date guide to the ever increasing instruction set. Here is the project itself. https://bitbucket.org/scargill/esp-go/src/master/

No longer showing passwords in the web setup page so you must put those in every time you use the setup page – otherwise you end up with blank passwords – which you might want. Added several new commands like cpu_clock so you can double the clock speed  – documented… ROM updated. DEFAULT pin for web updating is generally GPIO0 but on power up you’ll see serial messages which TELL you which pin to use. You can change this to GPIO14.

Update 24/07/2016:  See the changes in blog above, rendering some of the comments below obsolete.

Update 11/07/2017: Code updated to version 2.1.0 to work with the new release of the Espressif SDK version 2.1.0 – this is no longer compatible with the ESP-01 or other boards with less than 4MB of FLASH.

Update 01/10/2017: Code updated to version 2.2.14 – fixed some SSD1306 sillies – added great new commands, updated manual.  Also, some new WEMOS boards seem to need a slightly different programming method. If boards persistently refuse to operate – even after programming – check out the mode- there is a QIO mode – and a DIO mode. The default is QIO – however some WEMOS boards need DIO – check out this entry.

Update July 2018:  ESP-GO software updated to version 2.3.20

Facebooktwitterpinterestlinkedin

287 thoughts on “Flashing HC 2019 Code

  1. Pete, I am having trouble flashing a sonnoff basic. I have already done a few (about a year ago) and I thought there was an example of the esptool and NODEMCU screens with the filenames and addresses for the 1M ESP8266 somewhere on your excellent blog but I can no longer find it. I have managed to flash the Tasmoto firmware so the hardware is set up OK, but when I try flashing romx.bin (or rom.bin) I just get the 78600 bps stuff and no other response.

    I have tried rboot at 0x0000, romx at 0x2000 and 0x1000, esp_init . . at 0xFC000 and 0X7C000 and with or without blank.bin at 0x7E000 and 0xFE000 (I thinkj I have tried all configurations). Can you help, please? (I have set the flash size to 1MByte)

    1. Hi there Pete

      As I’ve mentioned elsewhere I no longer attempt to support the Sonoff units as they have 1M of Flash and I want to use that while retaining OTA. You are better off in this case with the Tasmoto software.

  2. I’m about to look at doing another update because I’ve realised there is no-where to store what a particular unit DOES – and after a while one is prone to forget.. so I’m going to try to introduce another text field for the purpose. All down to how much of that 4K block I have left.

  3. Flashing to Wemos D1 mini V2 of HC2017(2.2.09) Does not work. The erasing of the flash and after that the flashing with NodeMCU firmware programmer of the ROM seem to run OK.
    When I set baudrate to 76800 I get following message(csum err ):

    ets Jan 8 2013,rst cause:2, boot mode:(3,6)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0xef
    load 0x00000000, len 0, room 8
    tail 0
    chksum 0xef
    csum 0xef
    csum err
    ets_main.c

    No more bytes after ets_main.c!

    A correct starting ROM gives this:

    ets Jan 8 2013,rst cause:2, boot mode:(3,7)

    load 0x40100000, len 1344, room 16
    tail 0
    chksum 0x9c
    load 0x3ffe8000, len 660, room 8
    tail 12
    chksum 0xbe
    csum 0xbe

    A difference can be seen, but why?
    Anyone seen this and tried to use Wemos D1 miniV2 for HC2017?

    1. Leo – I’m programming Wemos boards on a daily basis. Did you read the post about the programming method? Some of those boards (and no others I’ve seen) require a slightly different programming setup.

        1. I will have a look to it. I already had it in the back of my mind that I need another programming mode. Lately I was rereading Theo Arends’ Tasmota again after a long time I used his FW in a few Sonoff units and found out he is now using DOUT as programming mode. Would be nice to study what is the difference between the modes and why you have to use different ones. Google will be my best friend.

          1. You really DO need to look at it if you’re going to use those Wemos boards – several others have commented around the web about this – please do try to avoid statments like “Flashing to Wemos D1 mini V2 of HC2017(2.2.09) Does not work.” indicating to those who don’t know any better that there could be an issue with that software. After many, many programmed chips you’ll see in that article I wrote that I finally came across the odd board that would not program – all Wemos – though why I don’t know – as the Wemos boards from China are often not genuine, for all I know, the chips might not be genuine). If you are interested in the various programming modes – check this out – https://www.esp32.com/viewtopic.php?t=1250

            1. You are right I have to be more carefull how to write down when there is a problem. I did write a comment, because I suspected I would not be the only one with this kind of problem(in fact I always assume that is the case). Google will sometime crawl this article and probably help people after me. The reference to that article for ESP32 will people make aware of the issues of flash mode. In my case I already suspected not to have got a genuine Wemos when I unpacked them and then the optimal flash QIO might not be available for that board.

            1. I found out a difference between flashing the latest rom.bin and otaupdate when I flash I get 2.2.09 when otaupdate 2.2.08. I read something lately about servers and scripts synchronizing. There seems to be a little hitch in that area?

              1. I read the .doc file and found the right url. I had to update all ota_host url’s. Now on 2.2.10!

  4. WELL! Things never stay the same do they – the company I used to store ROMS for OTA have no free support (free account) and their nice redirection fails to keep up to date – must be cached… SO I’ve put my own redirection in – please note – the OTA address reverts to roms.scargill.net as originally – now redirecting to a ridiculous page name – but it all works – and that’s the main thing!

    Just done updates to handle the latest NANO peripheral which involves waiting for up to two Dallas chips on I2c – transparent to the user – see the NANO PERIPHERAL blog for more info on that. Just updated to version 2.2.02 of the ESP code dated August 2017.

  5. Hi Pete,
    Have I found a bug?
    Command {out4:1;out4?} responds with ON but so does {out4:0;out4?}.
    A multimeter connected to GPIO4 (mislabelled as GPIO5) confirms pin state changes correctly from 0 to 3.3V.
    Tried this on a standard ESP12F and also two Wemos D1 Mini boards.

    1. Indeed you have found a bug, Dermot – thanks for that and it has now been corrected and the version updated.

  6. Hi Pete, thanks for the reply, you may be right in saying its an overkill, im still learning and experimenting as i go. I’ll do the update and continue playing.
    Thanks again.

  7. hi Pete, I have another question around the mist command; im playing with Node-Red to monitor the status of the gpio pin using an inject node with a payload of {out0?} (repeat interval every second) and debug the return message from the esp, that all works fine. When I send a mist command to the esp (either using mqtt or serially) the gpio state is always off regardless of of actual state i.e. relay is activated and deactivated or pulsed (remember I’m using the invert on the grio pins 0 and 2 as my relays are active low) according to the mist command {mist:0,5,10,10} but checking the status of the gpio pin for both relay on and relay off, still reports the gpio0 as off! is the correct, does the mist command somehow bypass normal query commands? Im not a programmer so can’t make use of functions within Node-Red (at the moment but hopefully over time I will teach myself how to do this) so im using Boolean logic within flows to take action based of the result of the relay status (gpio pin status); Im getting false readings because of the issue mention above. Does your code tell the esp to publish the state of gpio pins (gpio is output) when it receives a command to change state? this would simplify my flow and not have to poll for the gpio state change but simply monitor an mqtt message from the esp. correct me if I am wrong, the esp reports on a regular interval the state of sensor information, temp/humidity etc. can this be selectively extended to gpio pins on a port by port bases i.e through an additional command to add a programmable reporting interval for selected gpio state.
    I guess i could feed the output back into another gpio pin set as input, will this trigger a mqtt publish message from the esp because of the gpio pin state change? on the esp-01 this method would be very limiting and would only allow a single relay to be controlled…

    by the way, reasoning for checking gpio pin state is to ensure as much as possible that the water is off at the end of the mist cycle and not stuck on… “trust but verify”. Im also issuing the {out0:0} command as the “off” message within BigTimer although this doesn’t work if using a manual override into BigTimer, the mist command keeps running to its conclusion, only way I have found to cancel the mist command is to issue a reset command as the “off” message instead.

    1. By the look of it – what you are doing is way overkill. Even if you were to monitor the state of the pins – if there was a fault you could not know whether the reported state was true or not. When you set a pin high (which might be 1 or 0 depending on the state of the invert system) you will get a response of ON.

      So – {out0:6,1} sets the output for one minute – the STATE of that output depends on the invert status… but the RESPONSE to {out0?} will be ON if you are within that minute – regardless of the INVERT status.

      In terms of confidence, I have a watering system which runs all year, part of which we are absent – thousands of miles away. The only time it has failed was when idiot pulled the water pipe out – you can never account for that.

      As for the mister, because it turns on and off, it never occurred to me to ensure that the checks actually reflected the state of the output, similarly in the event of a reboot, the output will not maintain it’s MIST state but will be OFF (sensibly).

      So – if you would care to update – I have altered all of the outputs – which when in MIST mode now show ON or GAP accordingly – and OFF when done.

      I trust that meets with your approval.

  8. I’ve built a new programming device with most soldered wires. Still get the same problem when doing otaupdates. That could be power or internet connection. 3.3V has been supported by 2 times 470uF and very short wires, the an. reg. is AMS1117 and voltage is very near to 3.3. I have no scope so I cannot check for noise which drops the 3.3V. But the only trouble is with OTA. Your clock is no problem(separate 5V!) with all the high frequency switching. PWM working perfectly. According to datasheet max. current during writing is ~170 mA, the regulator is nicely WARM(<50degr or so). What is wrong with AMS1117? Do I need to use heavier stuff? Do you use high freq. filtering with low resistance/ind. capacitors? I doubt it is the problem and also not your software. But I really have doubts about the OTA/bootloader procedure. It works a few times without problem and then I get a suite of failed ota, I reloaded the rboot.bin and data_default file from your site to be sure using the latest. I find one complaint on Richard Burton's site ( https://richard.burtons.org/2015/05/23/rboot-tutorial-for-esp8266-ota-updates/ ) about the same problem, but that is not really ended into a conclusion what went wrong in there. The remark of piersfinlayson about limiting some mem alloc did helped for him, appparantly knowing the problem, but that goes over my head and I don't know where they are talking about. You might recognize what it means! When I Google for E:M 5856 I find this happened to someone else, but no conclusion in your HC2016 blog about that.
    Interesting to say I never had issues with esptool.py erase_flash and NodeMCU flasher after that, so serial is very much OK(nothing to do with ota, but still writing to flash as is done with ota). The only other problem is internet connection and data integrity during the downloading although very very unlikely. I download files for years and years and NEVER had ONE file which was corrupted because of data transmission interruptions.
    I can be patient, but these problems are nerve wrecking.

  9. I was away for the day but am glad you take my problems seriously. I have a question: can try to otaupdate when there is no change in firmware 1.7.8. Still no problems with you then I will dig deeper with complete different supply. I use those 5/3.3v combination which you see delivered on a lot of breadboards fitting over the edge of the BB. I also wil start producing a soldered programming board. What I see on my breadboards is very regular interruptions of signals(my test leds blink shortly) not always critical, but during programming this might be fatal. There is also the verify command in the esptool.py that I will investigate. I really hate to leave the project, a lot of knowledge down the drain. So I will pursuit things a bit more now I know I am the unlucky person.

    1. A note – and this is just my view – I would never use a switched supply directly to an ESP8266. I tend to use boards with 3v3 analog regulators on them and feed those from a switched mode power supply. Some of the supplies coming out of China have very poor regulation and don’t forget that although the average consumption of an ESP is not high, they have a tendency to need more current on startup and when sending info… so make sure you have a good margin. Comments in here over time suggest that for those people who do have issues, power tends to be the major culprit. There should be no interruptions to signals. If you are getting that, then you need to resolve the cause before considering problems with software etc.

      The ESP code I developed with help from others has been tested over time and works – rock-solidly, come access point failure, power failure and more. One of my installations is in Spain where I did most of my testing – up a mountain with atrocious electricity reliability and stability. If the ESPs and software can stand up to that (the Raspberry Pi running all of this is on battery backup) in my absence for months at a time, I think it is fair to say that the problems most likely are elsewhere.

Comments are closed.