ESP does not start after reflashing

[reshet86]

When flashing I strictly followed the instructions, I flashed through esphome via pc. Flashing is successful, but after flashing nothing happens when power is applied, wifi does not start and there is a feeling that esp itself also does not start, no light indications.

I'm attaching the firmware file just in case:

esphome:
  name: doorbell
  friendly_name: doorbell

# Configure the board; the G6L-WIFI uses a single-core ESP32.
esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: True

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Enable Home Assistant API
  ap:
    ssid: "Doorbell Fallback Hotspot"
    password: "rsqngkkOdckU"

api:
  encryption:
    key: "XJfTOaup1QicggZjjAb1HXuv8u+nsw1bP7v6lfQWxDI="
  # Custom services to control the chime chip.
  services:
    - service: play_tune
      variables:
        tune: int
        volume: int
        mode: int
      then:
        - remote_transmitter.transmit_szy8039b:
            tune: !lambda 'return tune;'
            volume: !lambda 'return volume;'
            mode: !lambda 'return mode;'
    - service: stop_playing
      then:
        - remote_transmitter.transmit_szy8039b:
            command: STOP

# Enable over-the-air updates.
ota:
  - platform: esphome
    password: "929fb13313e60f116dcff864ed05f1c3"
#    safe_mode: True

# Enable logging
logger:
  level: DEBUG

# Import the external component.
external_components:
  - source: github://pauln/esphome-linp-doorbell-g04
    components: [ linptech_g6l ]
    
# Add remote protocols for buttons and chime chip.
linptech_g6l:

# Remote receiver to listen for the button presses.
remote_receiver:
  pin: GPIO26
  # You can remove the dumper once you know the IDs, if desired.
  dump: linptech_g6l
  filter: 20us
  idle: 900us

# Remote transmitter for talking to the chime chip.
# You'll get a warning about GPIO15 being a strapping pin,
# but it's safe to ignore.
remote_transmitter:
  pin: GPIO15
  carrier_duty_percent: 100%
  
# LED outputs.
output:
  # Вы получите предупреждение о том, что GPIO4 является обвязывающим контактом, но его можно проигнорировать.
  - id: blue_led
    platform: gpio
    pin: GPIO4
  # If you choose to use the orange LEDs for the status LED (see below),
  # you might not want to use them for anything else, in which case you can
  # leave this bit out.
  - id: orange_led
    platform: gpio
    pin: GPIO13

# Use the orange LEDs as the status LED, if desired.
#status_led:
#  pin:
#    number: GPIO13

# Set up lights for the LEDs, with blinking effects similar to the original.
light:
  - platform: binary
    name: blue light
    output: blue_led
    id: blue_light
    effects:
      - strobe:
          name: blink
          colors:
            - state: true
              duration: 333ms
            - state: false
              duration: 333ms

  - platform: binary
    name: orange light
    output: orange_led
    id: orange_light
    effects:
      - strobe:
          name: blink
          colors:
            - state: true
              duration: 333ms
            - state: false
              duration: 333ms
    

binary_sensor:
  # The physical buttons on the receiver can be used for whatever you like.
  - platform: gpio
    pin:
      number: GPIO36
      inverted: true
    name: "left button"
    on_press:
      - light.toggle: blue_light
  - platform: gpio
    pin:
      number: GPIO39
      inverted: true
    name: "right button"
    on_press:
      - light.toggle: orange_light
      
  # For each doorbell button you want to listen for, add a block like this:
  - platform: remote_receiver
    name: Doorbell A
    linptech_g6l:
      # Put the ID found from the dumper here.
      address: 0x123456
    filters:
      # The buttons' transmission is repeated; 0.2s is long enough to debounce.
      # A longer delay can be used to filter out actual repeat presses.
      delayed_off: 0.2s
    on_press:
      then:
        # If you want a hardcoded chime (which works without a HA connection),
        # use the SZY8039B transmitter.
        # - Tune is from 1-40 (see datasheet)
        # - Volume is from 1-8
        # - Mode is from 1-4; since the LEDs are connected only to the ESP32,
        #   modes 1/2/4 play music and mode 3 doesn't (which isn't much use).
        - remote_transmitter.transmit_szy8039b:
            tune: 1
            volume: 1
            mode: 1
        # Send an event to Home Assistant with custom parameters, if desired.
        - homeassistant.event:
            event: esphome.button_pressed
            data:
              type: Doorbell
              button: A
        # Blink the LEDs, if desired.  Use any effect you've defined.
        - light.turn_on:
            id: blue_light
            effect: blink
        - delay: 5s
        - light.turn_off: blue_light
      
  # Additional buttons can be configured as desired.
  - platform: remote_receiver
    name: Doorbell B
    linptech_g6l:
      address: 0xABCDEF
    filters:
      delayed_off: 0.2s
    on_press:
      then:
        - remote_transmitter.transmit_szy8039b:
            tune: 2
            volume: 1
            mode: 1
        - homeassistant.event:
            event: esphome.button_pressed
            data:
              type: Doorbell
              button: B
        - light.turn_on:
            id: orange_light
            effect: blink
        - delay: 5s
        - light.turn_off: orange_light


# Remote restart (via API), if desired.
switch:
  - platform: restart
    name: "Doorbell Restart"

[szymucha94]

Perhaps new units have secure boot enabled? In which case you should revert to backup image which hopefully you made before flashing.
After frying my tuya-variant doorbell I ordered same g6l-e(mi) one, so if you don't have backup you may be able to use mine.
Also check uart output in putty/screen. Maybe the reason is printed there. And do check the packaging of your doorbell if product number is linp-doorbell-g04. Maybe even newer revision came out.

[szymucha94]

One more thing... can you take a picture of just the ESP32? Is that WROOM-32D?

[reshet86]

The microcontroller is truly an ESP-WROOM-32D. Unfortunately, I didn’t make a backup of the original firmware, I was in too much of a hurry, so if you could share, I’d be grateful. The output of the uart after the firmware does not provide any data, so I can’t see the error there either. I took the latest firmware intended for "linp-doorbell-g04".

[pauln]

@reshet86 If your second photo is from after you've flashed it, it looks as though you may still have IO0 shorted to the corner pin (your black wires seem to be touching each other). Although they don't appear to be connected to ground, it's possible that being connected to each other is causing the ESP32 to boot in an unexpected mode (or not boot at all) - please check that they're not connected (to ground, each other or anything else) when you apply power, and see if that allows it to boot.

[reshet86]

@pauln Yes, indeed, I shorted the angular contact and IO0 contact to the GND contact for firmware. Because I didn't understand the instructions in your manual correctly. Today I will try to flash again, but this time I will short-circuit IO0 and GND for flashing. (I removed the lower right contact and IO0 contact after the firmware so that ESP would start, but this did not bring results)

[reshet86]

After re-flashing, in which I shorted the bottom right pin to ground, the flashing was successful. I was able to connect the uart terminal - rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

[szymucha94]

That means you still have short on gpio0. Purpose of connecting gpio0 to gpio2 and then to gnd is to force esp to go into flash mode, which it currently is in.
Remove all cables you soldered there and check with multimeter if there is continuity between gpio0 and gnd. If they're not connected to each other try to boot normally by plugging device into power socket.

[reshet86]

Removed all the jumpers, tested the contacts with a multimeter. The contacts marked in red are closed. When trying to supply power to the board nothing happened, ESP did not start.

[szymucha94]

Are you using flux? :)
Try to put flux on uart headers and gpio0/2, fix the solder joints with soldering iron and clean leftovers with IPA.
If there is still short then inspect these areas under microscope/with magnifying glass. Maybe you mistakenly damaged coating of nearby traces and they caught some solder.
Btw. @pauln do you know what is the purpose of shorting gpio2? Isn't gpio0 enough to go into download mode?

[szymucha94]

Absolutely wild ride with this thing.
First of all, NEVER use 230V to power it up for flashing. I killed two doorbells this way (CBU-Tuya one and G6L-E). In Tuya's case 47 Ohm (rated at 1W) resistor exploded with the MCU, rendering this thing e-waste. In case of g6l-e only the resistor exploded. At first I thought that the board is dead so I desoldered the MCU for fun with gas soldering iron without a tip.
MCU powered off just an UART bridge 3.3V source turned out to be still alive and attempting to boot. It's funny how it survived exploding resistor and unprofessional desoldering with excessive heat :D

Soldered it back, inspected what's left of the resistor and powered it off single 18650 cell discharged to 3.5V. I was successful at saving the original firmware and flashing esphome, capturing the address and re-flashing it with new address. Gonna use it with dedicated 3.3V PSU which I strongly recommend to every user of this doorbell base.
@pauln I tried to add esphome's internal_temperature sensor to the config but the build failed on linking .efl:
/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pioenvs/g6l-emi/src/esphome/components/api/api_connection.o:(.literal._ZN7esphome3api13APIConnection17send_sensor_stateEPNS_6sensor6SensorEf+0x8): undefined reference to esphome::sensor::Sensor::has_state() const' (and so on)
Is it possible for you to cover this in the future? Would be good to know the temperature of MCU. Also thanks for this program, works very well!

[reshet86]

I washed the board from flux and rang it with a multimeter. I did not find any damage to the tracks or contact pads; the contacts that were closed remained closed. Apparently something went wrong somewhere and I damaged either the board or the chip itself. I see only two options: 1. Buy a new doorbell and try to flash it again; 2. Try to re-solder the esp32 chip and try to flash a new chip.

[szymucha94]

Remember that the top cover of esp32 is connected to ground. It's very easy to bridge any of it's gpios with it.

[pauln]

@szymucha94 That sounds like a wild ride, indeed! As noted in the flashing instructions, powering it off an isolated 3.3v supply is much better from a safety perspective anyway; I'm glad that your only casualties were one doorbell and a resistor on a second. As I noted in the readme, I use a 3.3v regulator (either with a USB cable soldered to it, or using a readily available USB port on a small breakout board so that any matching USB cable can be used) to power these units, rather than trying to reseal the original case (or build a new one) in a manner such that I'd be comfortable plugging it back into the mains. A dedicated 3.3v power supply is definitely also a fine option.

As for the internal temperature sensor, the issue you noted above looks to be in core ESPHome rather than anything provided by this repository. I don't currently have a doorbell unit at hand that I can experiment with, but I might be able to have a play over the weekend to see if I can help you get it working - assuming that these cut-down single-core ESP32s actually have a usable temperature sensor.

It's amazing just how many revisions of these doorbells they seem to have made - that "busy" pad you've circled isn't there on all revisions of the g04, but it's good to know that it's connected to GPIO2 for anyone who has that revision. (To answer your question about GPIO2, it must be either floating or low to enter flashing mode; I don't recall whether I found that it was being pulled high by something else or whether I just figured that if you're already soldering wires, you may as well tack one on to GPIO2 so that you can make sure it's pulled low...)

@reshet86, if GPIO0 and GPIO2 (the corner pads) are shorted to ground, it'll be booting into flashing mode every time - so yes, without a serial connection to see the "waiting for download" message it'll look dead as it won't connect to wifi or do anything else.
Unless you've accidentally left a tiny short from the corner pads (GPIO0 and GPIO2) to the metal cover on the ESP32 as @szymucha94 mentioned, I'm not sure how you'd have ended up with those pads remaining connected to ground after desoldering the wires. I agree with the suggestion to use flux to help clean up the solder pads.

[szymucha94]

@pauln I got four xiaomi devices running this single core esp32, all have internal temperature sensors :P All having same esp32 section config in yaml, for example air purifier using esphome-miot:

# Required configuration for the weird single core ESP-WROOM-32D module
esp32:
  board: esp32doit-devkit-v1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y
    advanced:
      ignore_efuse_mac_crc: true

sensor definition:

sensor:
  - platform: internal_temperature
    name: "MCU Temperature"

[szymucha94]

Right... as always it was a matter of cleaning build files. It just works, no need to change anything :)