Uploading using esptool-ck NOT esptool.py

email · May 24, 2020, 12:46pm

Hi,

I’ve just trying to switch over to platformio, but I’m having an issue that has me completely stumped. I’m running Windows 10.

I’ve always found that code uploaded to ESP8266 D1 minis with esptool.py fail - it seems to upload, but then it endlessly reboots. This has been an issue on the old Arduino IDE too.

However, I have found that using esptool-ck works fine.

Platformio seems to support both, and I’ve added “platform_packages = tool-esptool@1.413” to my platformio.ini file to attempt to use esptool-ck. However, Platformio seems to keep using esptool.py for the upload despite it downloading the esptool-ck package.

Can anyone help? Also, if anyone has any idea as to why esptool.py doesn’t upload correctly I’d be most grateful.

Thanks,

Oliver.

maxgerhardt · May 24, 2020, 1:01pm

Looking at the code

github.com

platformio/platform-espressif8266/blob/develop/builder/main.py#L297


      
                  and re.match(r"\"?((([0-9]{1,3}\.){3}[0-9]{1,3})|[^\\/]+\.local)\"?$",
                               env.get("UPLOAD_PORT", ""))):
              upload_protocol = "espota"
              sys.stderr.write(
                  "Warning! We have just detected `upload_port` as IP address or host "
                  "name of ESP device. `upload_protocol` is switched to `espota`.\n"
                  "Please specify `upload_protocol = espota` in `platformio.ini` "
                  "project configuration file.\n")
          
          
if upload_protocol == "espota":
              if not env.subst("$UPLOAD_PORT"):
                  sys.stderr.write(
                      "Error: Please specify IP address or host name of ESP device "
                      "using `upload_port` for build environment or use "
                      "global `--upload-port` option.\n"
                      "See https://docs.platformio.org/page/platforms/"
                      "espressif8266.html#over-the-air-ota-update\n")
              env.Replace(
                  UPLOADER=join(
                      platform.get_package_dir("framework-arduinoespressif8266") or "",
                      "tools", "espota.py"),

Usage of the esptool seems to have been completely switched out in favor of esptoolpy since 2.1.0 without the possiblity to switch back to the legacy tool.

Conversely, if you set

platform = espressif8266 @ 2.0.4

you get the last version which should have been using esptool, although now you’re also automatically using a much older Arduino-core version etc. So that’s not really desirable.

We have observed a large number of such “bootloop” cases where causes of error are pretty much always that a wrong bootloader with respect to the flash size of the module is given, see e.g. this or this or this.

So let’s rather work towards finding out why your ESP boot-loops. Can you:

use the esptool.py tool to get information about the chip, e.g.

> python "C:\Users\Maxi\.platformio\packages\tool-esptoolpy\esptool.py" -p COM34 flash_id
esptool.py v2.8
Serial port COM34
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 2c:3a:e8:06:XX:XX
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...

open any serial monitor (e.g. miniterm or hterm) at 74880 baud and post the bootloader messages.

email · May 25, 2020, 9:48am

Hi @maxgerhardt,

Thank you very much for your helpful note. Switching to 2.0.4 did indeed solve the problem but as you note this isn’t really a long term fix, so am keen to identify what’s causing it.

As requested (and grateful for your help):

details from esptool:
esptool.py v2.8
Serial port COM4
Connecting…
Detecting chip type… ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 38:2b:78:03:6c:25
Uploading stub…
Running stub…
Stub running…
Manufacturer: 20
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin…

And this is the output from the Serial Monitor that I get:
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v482516e3
~ld
�cl ␃{�o␎$ph
ets Jan 8 2013,rst cause:2, boot mode:(3,6)

Thank you very much for your help.

Oliver.

email · May 25, 2020, 10:25am

Hi,

I think I may have found the offending issue.

I went through my code, and found that one of the libraries that I was calling, a LightwaveRF library that sends radio messages to home automation devices, was causing the boot loops as soon as the set-up command was sent (lw_setup in the setup() routine).

The library I was using is here: GitHub - lawrie/LightwaveRF

I don’t know why this happens only when esptoolpy is used, and not esptool-ck.

The solution may be for me to use a more recent and tested with the ESP8266 → GitHub - roberttidey/LightwaveRF: Arduino Libraries for LightwaveRF 433MHz rx and tx, however if you have any thoughts as to why the upload tools cause the differing behaviour please do let me know!

Oliver.

maxgerhardt · May 25, 2020, 1:05pm

Does this bootloop appear for a standard blinky sketch and no externally connected hardware as well?

maxgerhardt · May 25, 2020, 1:07pm

Also it’s pretty bad that the library does an interrupt-processing in this function

github.com

lawrie/LightwaveRF/blob/master/LightwaveRF.cpp#L163


      
            lw_tx_pin = tx_pin;
            pinMode(lw_tx_pin,OUTPUT);
          }
          
          
/**
            Set things up to receive LightwaveRF 434Mhz messages using the values specified
          **/
          void lw_rx_setup(byte rx_pin, byte interrupt) {
            lw_rx_pin = rx_pin;
            pinMode(lw_rx_pin,INPUT);
            attachInterrupt(interrupt,lw_process_bits,CHANGE);
          }
          
          
/**
            Set things up to transmit and receive LightwaveRF 434Mhz messages using the values specified
          **/
          boolean lw_setup(byte tx_pin, byte rx_pin, byte interrupt) {
            if(tx_pin == rx_pin) {
              return false;
            }

github.com

lawrie/LightwaveRF/blob/master/LightwaveRF.cpp#L36


      
          
          
static const int lw_bit_delay = 560;
          static const byte lw_repeats = 12; // Number of repeats of message sent
          
          
static long lw_num_invalid_packets[4];
          
          
/**
            Pin change interrupt routine that identifies 1 and 0 LightwaveRF bits
            and constructs a message when a valid packet of data is received.
          **/
          void lw_process_bits() { 
            // Don't process bits when a message is already ready
            if (lw_got_message) return;
            
            byte v = digitalRead(lw_rx_pin); // the current value
            unsigned long curr = micros(); // the current time in microseconds
            
            // Calculate pulse duration in 50 microsecond units
            unsigned int dur = (curr-lw_prev)/50;
            lw_prev = curr;

Which is not marked as ICACHE_RAM_ATTR. All interrupt-processing code must be in IRAM for the ESP8266. See How to fix "ISR not in IRAM" - #2 by maxgerhardt

The library is 8 years old and was probably written with an Arduino Uno in mind rather than an ESP8266.

email · May 26, 2020, 6:48pm

Thank you very much for your reply - I think I’ll try and go with a more current library and avoid this issue. In answer to your earlier point, it all works fine - the blinky sketch, and all of my remaining code as long as I don’t use the offending library.