Wemos D1 does not boot after Blynk.air firmware update failed

Long story short, I have a simple weather station with a BME-280 and a GY-49 wired to a Wemos D1 Mini and all power up by a 18650 battery, see schematic.

I decided to try the new Blynk Edgent to be able to easily update the firmware and all worked great. I successfully update the esp a couple of times until yesterday, when I tried another update but it failed with the error “firmware mismatch” or something similar - unfortunately I deleted the shipment without thinking.

At this point you’d think that there is nothing wrong, just make another shipment with the firmware to update.

The issue is that after this fact the Wemos seemed to not connect to Blynk anymore, so I removed it from the weather station and when I connected to the computer I noticed that in the serial monitor it prints this:

09:21:18.830 → ets Jan 8 2013,rst cause:2, boot mode:(7,7)
09:21:18.830 →
09:21:18.830 → waiting for host

By searching on google it seems like the GPIO15 is pulled high, which prevents the esp to boot.

I’ve no idea what to do and if the Wemos is recoverable. If I manually short the GPIO15 to GDN it seems to boot correctly, but it’s a bad idea. I tried a pulldown with a 1k resistor but it didn’t work.

The code:

#define BLYNK_TEMPLATE_ID "My_template"
#define BLYNK_DEVICE_NAME "My_device"

#define BLYNK_FIRMWARE_VERSION        "1.0.5"

#define BLYNK_PRINT Serial
// #define BLYNK_DEBUG
// #define APP_DEBUG
#define USE_WEMOS_D1_MINI

#include "BlynkEdgent.h"

// Pins:
#define voltageAnalogPin A0
// Virtual pins:
// V0 = Temperature
// V1 = Humidity
// V2 = Pressure
// V3 = Luminosity
// V4 = Battery Voltage
// V5 = Battery Raw Voltage (analogRead)
// V6 = Dew point

// GY-49
#include <Wire.h>
#include <Max44009.h>
// BME280
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>

bool statusBME;
bool statusGY;

Max44009 myLux(0x4A);
Adafruit_BME280 bme;

BlynkTimer timer;

float dewPointFormula(float temp, float humidity){
  float dewPoint;
  dewPoint = (237.3*(log(humidity/100) + ((17.27*temp)/(237.3+temp)))) / (17.27-(log(humidity/100)-((17.27*temp)/(237.3+temp))));
  return dewPoint;
}

void SendData(){
  if(statusBME){
    float temperature = bme.readTemperature();
    float humidity = bme.readHumidity();
    float pressure = (bme.readPressure() / 100.0F)+30.77;
    float dewPoint = dewPointFormula(temperature, humidity);

    Blynk.virtualWrite(V0, temperature);
    Blynk.virtualWrite(V1, humidity);
    Blynk.virtualWrite(V2, pressure);
    Blynk.virtualWrite(V6, dewPoint);    
  }

  if(statusGY){
    float illuminance = myLux.getLux();
    if(illuminance >= 0){
      Blynk.virtualWrite(V3, illuminance);
    }
    else{
      String desc = "GY49 error: " + String(illuminance);
      Blynk.logEvent("error_on_data_reading", desc);
    }
  }

  float rawVoltage = analogRead(voltageAnalogPin);
  float voltage = (rawVoltage/1024)*5.1 ;

  if(voltage < 3.65){
    Blynk.logEvent("battery_voltage_low");
  }

  Blynk.virtualWrite(V5, rawVoltage);
  Blynk.virtualWrite(V4, voltage);

  ESP.deepSleep(300e6);
}

void setup()
{
  // Serial.begin(115200);
  BlynkEdgent.begin();

  // If the timer interval is too low ( < ~10 seconds) blynk does not have the time to start the firmware update before the esp goes in deep sleep
  timer.setInterval(10000L, SendData);

  Wire.begin();
  Wire.setClock(100000);
  delay(150);

  statusBME = bme.begin(0x76);
  statusGY = myLux.isConnected();

  if(!statusBME){
    Blynk.logEvent("sensor_offline", "BME280");
  }
  if(!statusGY){
    Blynk.logEvent("sensor_offline", "GY49");
  }
}

void loop() {
  BlynkEdgent.run();
  timer.run();
}

Have you tried re-flashing the sketch to the Wemos via USB?
If so, what happens when you do this?

As for what caused the problem, is it possible that you compiled the latest shipment with a different device type selected in the IDE - an ESP32 board for example?

Pete.

Thank you Pete for the fast reply.

Have you tried re-flashing the sketch to the Wemos via USB?
If so, what happens when you do this?

Yes, and since the Wemos does not boot it does not connect.

I also tried to update the firmware with esptool but I got the same error.

Executable segment sizes:
ICACHE : 32768           - flash instruction cache 
IROM   : 231724          - code in flash         (default or ICACHE_FLASH_ATTR) 
IRAM   : 26793   / 32768 - code in IRAM          (IRAM_ATTR, ISRs...) 
DATA   : 1496  )         - initialized variables (global, static) in RAM/HEAP 
RODATA : 876   ) / 81920 - constants             (global, static) in RAM/HEAP 
BSS    : 25608 )         - zeroed variables      (global, static) in RAM/HEAP 
Sketch uses 260889 bytes (24%) of program storage space. Maximum is 1044464 bytes.
Global variables use 27980 bytes (34%) of dynamic memory, leaving 53940 bytes for local variables. Maximum is 81920 bytes.
esptool.py v3.0
Serial port COM4
Connecting........_____....._____....._____....._____....._____....._____....._____
Traceback (most recent call last):
  File "C:\Users\Lorenzo\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\3.0.2/tools/upload.py", line 66, in <module>
    esptool.main(cmdline)
  File "C:/Users/Lorenzo/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool\esptool.py", line 3552, in main
    esp.connect(args.before, args.connect_attempts)
  File "C:/Users/Lorenzo/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/3.0.2/tools/esptool\esptool.py", line 529, in connect
    raise FatalError('Failed to connect to %s: %s' % (self.CHIP_NAME, last_error))
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header

As for what caused the problem, is it possible that you compiled the latest shipment with a different device type selected in the IDE - an ESP32 board for example?

I doubt unless in some ways the IDE changed the board on its own.

Have you tried rebooting your PC and/or using a different USB cable?

Pete.

Yes, I also tried different ports. With other Wemos D1 mini boards I don’t have any issue.

I also tried to pull down the GPIO0 pin but the result is the same.

I’m guessing that the Wemos has gone faulty, and that the Blynk.Air update is just a coincidence.
If the device was running okay and one of the internal pull-up/down resistors has failed then the next firmware update would fail, regardless of how it was delivered.

If you take a look at this post:

You’ll see which pins need to be pulled up/down to place the board into programming or run mode. As you can see, it’s not just GPIO15.

Pete.

You’ll see which pins need to be pulled up/down to place the board into programming or run mode. As you can see, it’s not just GPIO15.

I know, I already checked all the other GPIO and they all seem to behave correctly except GPIO15, which has a voltage of ~0.6V on boot.
As I said if I manually short it to GDN the Wemos boot up correctly and I’m able to upload the sketch.

I’m guessing that the Wemos has gone faulty, and that the Blynk.Air update is just a coincidence.
If the device was running okay and one of the internal pull-up/down resistors has failed then the next firmware update would fail, regardless of how it was delivered.

It seems the more plausible explanation. Thank you for your time.