Problems with flashing the device

mikkelke commented 1 month ago

Hi,

TLDR: I always get Failed to connect to ESP32: No serial data received.

I have tried flashing the device with two CH340G and also from a Raspberry Pie 4. I did not succeed. Power have been supplied from either the CH340G, the Pi or a connected power supply provided 12V and 3A. I setup the serial connection using a baudrate of 115200.

I can view the boot log when i attach to the serial port: and pressing the reset button.

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:6932 load:0x40078000,len:13712 load:0x40080400,len:4260 entry 0x400806e4 ␛[0;32mI (70) boot: Chip Revision: 1␛[0m ␛[0;32mI (70) boot_comm: chip revision: 1, min. bootloader chip revision: 0␛[0m ␛[0;32mI (39) boot: ESP-IDF v4.0.1-193-ge7ac221 2nd stage bootloader␛[0m ␛[0;32mI (39) boot: compile time 02:45:47␛[0m ␛[0;32mI (39) boot: Enabling RNG early entropy source...␛[0m ␛[0;32mI (44) boot: SPI Speed : 40MHz␛[0m ␛[0;32mI (49) boot: SPI Mode : DIO␛[0m ␛[0;32mI (53) boot: SPI Flash Size : 4MB␛[0m ␛[0;32mI (57) boot: Partition Table:␛[0m ␛[0;32mI (60) boot: ## Label Usage Type ST Offset Length␛[0m ␛[0;32mI (68) boot: 0 phy_init RF data 01 01 0000f000 00001000␛[0m ␛[0;32mI (75) boot: 1 otadata OTA data 01 00 00010000 00002000␛[0m ␛[0;32mI (82) boot: 2 nvs WiFi data 01 02 00012000 0000e000␛[0m ␛[0;32mI (90) boot: 3 at_customize unknown 40 00 00020000 000e0000␛[0m ␛[0;32mI (97) boot: 4 ota_0 OTA app 00 10 00100000 00180000␛[0m ␛[0;32mI (105) boot: 5 ota_1 OTA app 00 11 00280000 00180000␛[0m ␛[0;32mI (112) boot: End of partition table␛[0m ␛[0;32mI (117) boot_comm: chip revision: 1, min. application chip revision: 0␛[0m ␛[0;32mI (124) esp_image: segment 0: paddr=0x00100020 vaddr=0x3f400020 size=0x29238 (168504) map␛[0m ␛[0;32mI (193) esp_image: segment 1: paddr=0x00129260 vaddr=0x3ffbdb60 size=0x0396c ( 14700) load␛[0m ␛[0;32mI (199) esp_image: segment 2: paddr=0x0012cbd4 vaddr=0x40080000 size=0x00400 ( 1024) load␛[0m ␛[0;32mI (200) esp_image: segment 3: paddr=0x0012cfdc vaddr=0x40080400 size=0x03034 ( 12340) load␛[0m ␛[0;32mI (214) esp_image: segment 4: paddr=0x00130018 vaddr=0x400d0018 size=0x106950 (1075536) map␛[0m ␛[0;32mI (602) esp_image: segment 5: paddr=0x00236970 vaddr=0x40083434 size=0x195c8 (103880) load␛[0m ␛[0;32mI (646) esp_image: segment 6: paddr=0x0024ff40 vaddr=0x400c0000 size=0x00064 ( 100) load␛[0m ␛[0;32mI (664) boot: Loaded app from partition at offset 0x100000␛[0m ␛[0;32mI (664) boot: Disabling RNG early entropy source...␛[0m BLUFI BLE is not connected yet 2.1.0 max tx power=78,ret=0

Hope someone can help me flash the devices.

ch340g-usb-to-rs232-ttl-auto-converter-adapter-module-for-arduino-1

Mat931 commented 1 month ago

Are you sure you connected the DTR pin correctly? Your adapter appears to have only CTS and RTS, I don't see a DTR pin.

mikkelke commented 1 month ago

I ordered this two today. Hope it will solve my problem. S55bb5dc1d52d44debd4be66e249c881dt FT232RL-FTDI-USB-3 3V-5 5V-to-TTL-Serial-Adapter-Module

Mat931 commented 1 month ago

The red one should work. It's the same I have. It has a DTR pin on the right row.

dtretyakov commented 1 month ago

Previously I had the same issue with "No serial data received". It was caused by bad contact of pin headers with the board holes.

I moved a bit further, but now stuck with another issue. The flashing page has no detailed steps and mentions:

The rest of the flashing process is identical to other ESP32 and ESPHome devices.

I, as a newcomer to ESP32 tooling, discovered the following ways to flash firmware:

ESPHome Web which also seems to be used in Home Assistant ESPHome add-on.
esptool which is used in various tutorials and in the https://github.com/Mat931/esp32-doorbell-bus-interface/issues/3#issuecomment-1937442936.

For firmware flashing I'm using the following CP2102N-based adapter which has required DTR/RTS pins:

The problem is that both tools are hanging in the "Connecting" state during flashing

During that board is powered up and PWR/RX LEDs are permanently on. The adapter has blinking TX/RX LEDs, but I could not see that TX led is lighting up on the board.

Auto flashing mode

The board includes an auto-reset circuit so you don't need to manually ground GPIO0 or press any buttons during flashing

I interpret it as follows: connect jumper wires between the board and adapter and plug adapter into the computer.

Web tool after few attempts displays "Failed to initialize. Try resetting your device or holding the BOOT button while selecting your serial port until it starts preparing the installation."

esptool displays the following:

> esptool --port COM9 erase_flash
esptool.py v4.8.dev4
Serial port COM9
Connecting......................................

A fatal error occurred: Failed to connect to Espressif device: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

Manual flashing mode

The solution for this "Wrong boot mode detected (0x13)" issue is to press the "boot" button before plugging in adapter and when tool attempts "Connecting" release the button.

Since we have the only "Reset" button I tried to use it as a "boot" button. Results are following:

Web tool: after releasing reset button adapter starts blinking only RX LED. It ends up with the same error as in "Auto" mode.

esptool: only after numerous attempts I was able to release "Reset" button on time so both erase_flash and write_flash commands were successful.

> esptool --port COM9 erase_flash
esptool.py v4.8.dev4
Serial port COM9
Connecting.........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.........
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:64:c9:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 14.3s
Hard resetting via RTS pin...

> esptool -p COM9 write_flash 0x0 abb-welcome-demo.factory.bin
esptool.py v4.8.dev4
Serial port COM9
Connecting.........
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting..........
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ec:64:c9:xx:xx:xx
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00000000 to 0x000cdfff...
Compressed 840112 bytes to 529627...
Wrote 840112 bytes (529627 compressed) at 0x00000000 in 48.1 seconds (effective 139.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

After that successful attempt I was not able to reset/flash firmware again. So my susceptions are:

esptool has problems with delays during the Connect attempt. There is an old patch to address related issue: https://github.com/espressif/esptool/issues/741#issuecomment-1326951723
I still have soldering issues for pin heads on the board.

Notes

I soldered pin headers for the second board, but it also has the same issues with Connecting state/Wrong boot mode detected (0x13).

I tried flashing on both Windows/macOS laptops.

So I still have no clue how to find a reliable flashing procedure.

Mat931 commented 1 month ago

The Home Assistant ESPHome add-on typically uses the esptool method, which I recommend. (Select "Plug into the computer running ESPHome Dashboard" when installing) I never used the ESPHome Web method and heard that many people have problems with it.

Depending on the ESP32 model you have it might not work at all with the pre-compiled ESPHome binary the web tool uses, because it requires an ESPHome binary compiled with single-core support.

The TX/RX LEDs on the board are not indicating serial communication (flashing firmware) but rather communication with the ABB welcome bus. When the board is not connected to the bus, it's normal for the RX led to be permanently on.

Your serial adapter might not be able to supply enough current at 3.3V so if flashing still fails you should try connecting external power to the board instead. With external power connected the RX LED should turn off.

The method I recommend for flashing is using the ESPHome dashboard and connecting the ESP to the computer that's running the dashboard.

Hope this helps :)

mikkelke commented 1 month ago

TLDR: Using the red FT232RL flashing was easy and everything works as intended.

First I flashed from my Ubuntu VM on my laptop where i powered the ESP32 model from the Serial Adapter and it flashed as intended, but it did not boot. I got som errors in the log (I did not save them). Then I connected my 12V DC adapter and flashed from the webinterface of my docker hosted ESPHome thru my Windows laptop in Edge. It flashed without any errors and booted up.

I noted that when you access the log on the ESP32 device the Wi-Fi LED does not blink. It trolled me to believe that the device did not work when i installed it since i left the log window open on my computer.

Anyway everything went smooth and the ESP32 module fit perfectly in the installation box behind my ABB intercom device. I'm very happy with the result . A couple of year ago I changed my ABB intercom indoor device to the one with Wi-Fi and was very sad when I found out it did not support API and there where not great way to interact with the system. I event called ABB and asked if they could provide a solution. This device provide the missing features and with the bus module and the Wi-Fi intercom I can control programmatically and by video/voice in the ABB app from my phone.

@Mat931 Thank you for creating and sharing this project!

tsgoff commented 1 week ago

The blue usb serial adapter worked for me.

But somehow I end up in a boot loop:

[19:39:49]rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[19:39:49]configsip: 0, SPIWP:0xee
[19:39:49]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[19:39:49]mode:DIO, clock div:2
[19:39:49]load:0x3f400020,len:43124
[19:39:49]ets Jun  8 2016 00:22:57
[19:39:49]
[19:39:49]rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[19:39:49]configsip: 0, SPIWP:0xee
[19:39:49]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[19:39:49]mode:DIO, clock div:2
[19:39:49]load:0x3f400020,len:43124
[19:39:49]ets Jun  8 2016 00:22:57

is this the correct setting for the new esphome syntax and the correct board?

esphome:
  name: esp32-busch-bus
  friendly_name: "esp32-busch-bus"
  on_boot:
    - lock.template.publish:
        id: front_door
        state: LOCKED
    - binary_sensor.template.publish:
        id: doorbell_indoor
        state: OFF
    - binary_sensor.template.publish:
        id: doorbell_outdoor
        state: OFF  

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_FREERTOS_UNICORE: y

Mat931 commented 1 week ago

Hi @tsgoff

it is hard to find the cause of the issue with the limited information you provided. Here are some ideas / questions:

What is the exact model of ESP32 you used? The LCSC part number is also okay if you ordered from JLCPCB. If you didn't change it, the default is ESP32-SOLO-1 (part number C473005)
How are you powering the board? Is there enough power for the ESP?
What method did you use for flashing the ESP? Could you share some logs?
Does the ESP or any other component on the board get hot when powered?
If you received multiple boards, could you try a different one to rule out a soldering or hardware issue?

Your config snippet looks okay. In the future, please open a new issue on Github instead of replying to a closed one.

tsgoff commented 1 week ago

thank you for your reply.

It is the ESP32-SOLO-1 from your instruction
board is powered over external power supply with 12V (3,3v from serial adapter removed)

i tried ESPHome-Flasher on OSX without success. On a debian 11 it worked with esphome docker run -ti -v /data/esp32-busch-bus:/config --device=/dev/ttyUSB0 esphome/esphome run esp32-busch-bus.yaml it is also working with binary compiled by esphome and esptool.py:


# esptool.py --port /dev/ttyUSB0  write_flash 0x1000 esp32-busch-bus.ota.bin
esptool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting.....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting..........
Detecting chip type... ESP32
Chip is ESP32-S0WD (revision v1.1)
Features: WiFi, BT, Single Core, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 10:06:1c:61:a6:58
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00001000 to 0x000bdfff...
Compressed 773504 bytes to 512765...
Wrote 773504 bytes (512765 compressed) at 0x00001000 in 45.5 seconds (effective 136.0 kbit/s)...
Hash of data verified.

Leaving... Hard resetting via RTS pin...

- parts have normale temprature
- i also switched both boards and cables. verified soldering. I measured the contacts with a continuity meter
- serial adapter is "Hailege CP2102" from the pictures above

power LED is on. wifi LED is off.
When I take a look at 

current config looks like:

esp32: board: esp32dev framework: type: esp-idf sdkconfig_options: CONFIG_FREERTOS_UNICORE: y # Only required if you have a single core ESP32

esphome: name: abb-welcome-demo friendly_name: "ABB Welcome Demo" on_boot:

lock.template.publish: id: front_door state: LOCKED
binary_sensor.template.publish: id: doorbell_indoor state: OFF
binary_sensor.template.publish: id: doorbell_outdoor state: OFF

wifi: networks:

ssid: !secret wifi_ssid password: !secret wifi_password

logger:

api: encryption: key: !secret api_encryption_key

ota:

platform: esphome password: !secret ota_password

remote_transmitter: pin: GPIO26 carrier_duty_percent: 100%

remote_receiver: pin: number: GPIO25 mode: input: True dump: [abbwelcome] filter: 8us tolerance: type: time value: 26us idle: 1500us buffer_size: 15kB memory_blocks: 5 clock_divider: 160 on_abbwelcome: then:

lambda: 'id(doorbell_intercom).publish_state(x.to_string().c_str());'
if: condition: and:
- lambda: 'return (x.get_message_type() == 0x8d);' # unlock door response
- lambda: 'return (x.get_source_address() == 0x4001);' # door address then:
  - lock.template.publish: id: front_door state: UNLOCKING
  - delay: 3s # time how long the door usually stays unlocked
  - lock.template.publish: id: front_door state: LOCKED
if: condition: and:
- lambda: 'return (x.get_message_type() == 0x11);' # doorbell indoor
- lambda: 'return (x.get_source_address() == 0x1001);' # your indoor station address then:
  - binary_sensor.template.publish: id: doorbell_indoor state: ON
  - binary_sensor.template.publish: id: doorbell_indoor state: OFF
if: condition: and:
- lambda: 'return (x.get_message_type() == 0x01);' # doorbell outdoor
- lambda: 'return (x.get_source_address() == 0x2001);' # outdoor station address
- lambda: 'return (x.get_destination_address() == 0x1001);' # your indoor station address then:
  - binary_sensor.template.publish: id: doorbell_outdoor state: ON
  - binary_sensor.template.publish: id: doorbell_outdoor state: OFF

binary_sensor:

platform: template name: Doorbell indoor id: doorbell_indoor icon: mdi:bell filters:
- delayed_off: 1s
platform: template name: Doorbell outdoor id: doorbell_outdoor icon: mdi:bell filters:
- delayed_off: 1s

sensor:

platform: internal_temperature name: "Internal Temperature"

text_sensor:

platform: template name: "Doorbell Intercom" # Receive debug messages id: doorbell_intercom icon: mdi:bell-circle update_interval: never

lock:

platform: template name: "Front Door" id: front_door on_unlock:
- then:
  - lock.template.publish: id: front_door state: LOCKED lock_action:
- then:
  - lock.template.publish: id: front_door state: LOCKED unlock_action:
- then:
  - remote_transmitter.transmit_abbwelcome: source_address: 0x1001 # your indoor station address destination_address: 0x4001 # door address three_byte_address: false # address length of your system message_type: 0x0d # unlock door data: [0xab, 0xcd, 0xef] # door opener secret code, see receiver dump

button:

platform: restart name: "Reboot"
platform: safe_mode name: "Reboot (Safe Mode)"
platform: template name: "Stop Doorbell" on_press:
- remote_transmitter.transmit_abbwelcome: source_address: 0x1001 # your indoor station address destination_address: 0x2001 # outdoor station address three_byte_address: false # address length of your system message_type: 0x02 # end call (stops your doorbell ringtone) data: [0x00]

status_led: pin: GPIO2

Mat931 commented 1 week ago

I think the problem is that you used the ota.bin file with esptool. When flashing via serial you need to use the factory.bin file, the ota one is for updating over wifi. The command should be: esptool.py --port /dev/ttyUSB0 write_flash 0x0 esp32-busch-bus.factory.bin Here is some more info on how to use esptool with ESPHome: https://esphome.io/guides/faq#esphome-esptool

tsgoff commented 1 week ago

thank you!! looks like it is working now!

Mat931 / esp32-doorbell-bus-interface