Plan B: Flashing Sonoff devices using FTDI & wires - Success!!

OK, so the SonOTA stuff didn't work, time for Plan B - use FTDI USB-Serial adapter and some wires to connect the ESP8266 to the Mac and have at it...

To make sure everything happened cleanly, I thought I'd follow the instructions (blimey).

Removed current Arduino IDE install, and re-installed 1.8.5, the latest. Then I installed the Espressiv 2.4.0 board code, as per instructions. I compiled the sonoff code, minor glitch when the MQTT buffer was apparently too small. This was due to some old libs from my previous attempts - I hadn't deleted everything Arduino because I wanted to able to do some of the things I'd been doing previous to this escapade. I just deleted the old (differently named!) versions of ArduinoJSON and PubSubClient. Things then compiled ok. All good so far...

At this point I had to connect the board via the FTDI adapter. I used a breadboard for this, and reckoned I could avoid soldering the pins onto the board by using male/female jumper wires, pushed together through the holes in the board. Excellent.

L-R: FTDI Adapter, Breadboard connections, Sonoff board

View of jumper wires pressed through board - fingers crossed


The hard bit now started... You have to hold down the GPIO0 short switch (the plastic filler beside the jumper wires in the picture above) while connecting the power, then release it to tell the chip to go into flash mode. Tricky, because lazy me had to hold the jumper wire pins firmly against the contacts to ensure a good one, whilst triggering the upload with the other hand.

Using the Arduino facility for uploading almost worked, at one point it got to 94% before blowing out. Grr. Then the stupid USB-Serial FTDI port kept disappearing... WTF. It was visible as a device in System Report->Hardware->USB. In fact, sometimes there were two of them!! Not good...

In the meantime I'd started to use Expressif's Python-based esptool.py instead of Arduino IDE. This is easier in some respects, but the Tasmota guide suggested using it to erase_flash, reset_flash and write_flash, so I put those 3 commands into a single file to save typing whilst holding onto contacts. Then I split them incorrectly into 3 separate files - mistake with vi :-). So File 2 managed a complete write_flash, then File 3 erased it again! Bummer...

Meanwhile, the USB failure was becoming extremely annoying, basically having to restart the Mac after every attempt and it seemed to be getting worse. I eventually found some people on StackExchange who were reporting similar problems, which they'd solved by tidying up the USBSerial drivers in /Libraries/Extensions and /System/Libraries/Extensions. For what it's worth, I

  • Removed /S/L/E/FTDIUSBSerial.kext, rebooted
    • No joy...
  • Removed /L/E/usbserial.kext
    • Joy! seems to have resolved the problem; adapter can now be plugged in/removed with exactly the required effect
Time to do something more concrete with the connections to make it simpler. I soldered some connection pins into the holes on the PCBs - easier said than done, of course, cocking up one set of pins in the process. I also reviewed the female jumper wire connections - one, which had been very slack and I'd tried to tighten, broke, so I used some new ones. >Sigh<

Now I'm getting the same error consistently...


Macintosh-Gouk:esptool-master john$ ~/flashtasmota
esptool.py v2.3-dev
Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 timeout=0.100 data=b'\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU'
TRACE +0.000 Write 46 bytes: b'\xc0\x00\x08$\x00\x00\x00\x00\x00\x07\x07\x12 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU\xc0'
TRACE +0.011 Read 1 bytes: b'\xc0'
TRACE +0.000 Read 61 bytes: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.001 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.013 Read 1 bytes: b'\x08'
TRACE +0.001 Read 33 bytes: b'\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0\xc0\x01\x08\x02\x00\x07\x07\x12 \x00\x00\xc0'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.001 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'
TRACE +0.000 Full packet: b'\x01\x08\x02\x00\x07\x07\x12 \x00\x00'

Detecting chip type...TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=b'x\x00\x00`'
TRACE +0.000 Write 14 bytes: b'\xc0\x00\n\x04\x00\x00\x00\x00\x00x\x00\x00`\xc0'
TRACE +0.013 Read 1 bytes: b'\xc0'
TRACE +0.001 Read 11 bytes: b'\x01\n\x02\x00\x00 \x06\x00\x00\x00\xc0'
TRACE +0.005 Full packet: b'\x01\n\x02\x00\x00 \x06\x00\x00\x00'
 ESP8266
TRACE +0.000 command op=0x0a data len=4 wait_response=1 timeout=3.000 data=b'\\\x00\xf0?'
TRACE +0.000 Write 14 bytes: b'\xc0\x00\n\x04\x00\x00\x00\x00\x00\\\x00\xf0?\xc0'
TRACE +0.010 Read 1 bytes: b'\xc0'
TRACE +0.001 Read 23 bytes: b'\x01\n\x02\x00\x00 \x06\x00\x01\x05\xc0\xc0\x01\n\x02\x00\x00 \x06\x00\x01\x05\xc0'
TRACE +0.001 Full packet: b'\x01\n\x02\x00\x00 \x06\x00\x01\x05'

A fatal error occurred: Failed to read register address 3ff0005c (result was 0105)

This is the trace output, which shows that I am actually getting connected to the chip and it's just not responding correctly to the prompting. This is true of both boards, so WTF. I'm beginning to lose the will to live, or at least, keep on with this!

 Right. Cup of tea. This has to be possible... After all nothing has changed (really!!). Chip can't be broken. Not both. Not in such a smart way! Look at Python code in esptool.py, delve into the SLIP comms protocol so I can see a few of the commands and responses coming and going in the trace above. Note that it's possible to specify the chip with the "--chip" argument, let's try that using the tool interactively, asking for the MAC ID as a simple thing. Result!!
Macintosh-Gouk:esptool-master john$ python3 ./esptool.py --port /dev/cu.usbserial-A9M9DV3R --chip esp8266 read_mac
esptool.py v2.3-dev
Connecting...
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
MAC: 5c:cf:7f:57:c5:24

Hard resetting...

 Noting that it's uploading the "compatibility stub", some code that bridges the gap between the ESP12 and ESP32. This is cool. Let's run the remaining commands...
Macintosh-Gouk:esptool-master john$ python3 ./esptool.py --port /dev/cu.usbserial-A9M9DV3R --chip esp8266 erase_region 0x0F4000 0x008000
esptool.py v2.3-dev
Connecting....
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Erasing region (may be slow depending on size)...
Erase completed successfully in 0.4 seconds.

Hard resetting...

 Lovely...
Macintosh-Gouk:esptool-master john$ python3 ./esptool.py --port /dev/cu.usbserial-A9M9DV3R --chip esp8266 erase_flash
esptool.py v2.3-dev
Connecting........__
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.2s

Hard resetting...

 And now the piece de resistance...
Macintosh-Gouk:esptool-master john$ python3 ./esptool.py --port /dev/cu.usbserial-A9M9DV3R --chip esp8266 write_flash -fs 1MB -fm dout 0x0 ~/Documents/Arduino/SonoffDownload/sonoff.bin
esptool.py v2.3-dev
Connecting....
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Compressed 495808 bytes to 341889...
Wrote 495808 bytes (341889 compressed) at 0x00000000 in 30.3 seconds (effective 130.8 kbit/s)...
Hash of data verified.

Leaving...

Hard resetting...

 OK! Time for some taiji.

Comments

Post a Comment

Popular posts from this blog

Replacing Coffee Machine Pump (Dualit Espressivo)

Image
My 5 year old Dualit Espressivo broke on Saturday - disaster!! I was in the throes of making a coffee when the pump stopped, so no steamed microfoamed milk... Off with the back, check of voltages etc., taking extreme care because 240V + H2O is a Bad Thing. I located what seemed to be the pump, and there were volts on the terminals. Hmm. It’s an Ulka EP5FM according to the label. Google... Many people offering to sell me one, but the guys at ulka-ceme.co.uk aka Scintilla Pumps are the UK distributors. They sell a whole range of this type of pump, and the documentation shows that the crucial points are voltage/power, pressure (15 bar) and duty cycle (2m on/1m off). I can buy one online but I call them... they’re about 15 miles away, and are happy to sell me a replacement. We reckon it’s worth a lunch trip, so bowl over and it’s only £16 direct, vs £19.60 mail order. Done. The expensive part was lunch - £50!! Planning to skip dinner though... New pump fitted - looks like the old
Read more

Multiple SHT30 sensors on a single I2C bus with Sonoff-Tasmota

Image
I have a hankering to measure the input and output temperatures of my condensing boiler, in order to determine if it's likely to be actually condensing at any time. I have lots of SHT30 sensors, which attach handily to NodeMCU units. However, running 2 separate rigs, one each for input and output, means that temperature measurements will not be synchronised, which doesn't account for the action of the boiler and its heat output rate of change. It appears that the SHT30 has two I2C addresses (0x44 and 0x45), which are available on the Wemos D1 knock-offs that I have. So I started out by modifying one to use a different bus from the standard one - this is easily done by bridging a link with solder. I then used 2 NodeMCUs running together to check that the newly addressed device is actually detected and works. It does. Pair of NodeMCU/SHT30 setups in action Close-up of SHT30 devices -RH(44) has soldered address link (circled) So, let's see what we can do, eh? I
Read more

NodeMCU + Tasmota code + SHT30

Image
That was cool. Let's try something a bit "easier" - a NodeMCU module, which is easy to connect and upload to, in conjunction with a new sensor, the SHT30 that does humidity and temperature over an I2C interface. This is prompted by this article , which doesn't really say how to do any of this... Obligatory not very illustrative pic - bits are labelled pretty much! Oh yeah, had to solder the header pins onto the SHT30 - piece of cake now :-p. Compiled the latest Tasmota code (using the ESP 2.4.0 API + libs, which significantly improves the WiFi performance) in the Arduino IDE, it's already uploaded while I've been writing this. Gosh. And that was probably a bit rash! Re-compiled and uploaded, now I've edited the user_config.h file to include my Wifi details and a few other useful things. I'm hoping the code uses mDNS, because that's really handy. Hmm, that didn't seem to work - using the Serial Monitor indicates it's still us
Read more