Generic RTL8710BX doesn't start after a reboot #24
Comments
|
And if I make major modifications in the yaml configuration file the device won't start at all after an OTA update. |
|
That's weird. Did you compile the yaml with the correct board specified? If you do not, it may overwrite wrong parts of the flash during an update. |
|
I'm using "generic-rtl8710bx-4mb-980k", which I'd say is the correct one. The same firmware.uf2 is working fine when flashed over UART using ltchiptool. |
|
Could you do a flash dump right after doing OTA upgrade? (an upgrade after which it fails to boot, even after reset) And if you can, share the uf2 file you used for that specific update as well. Note: it may contain your WiFi password, so use a dummy YAML if you consider that sensitive. |
|
Here are the dump file dump_ezviz_libretuya_2.zip and the firmware file firmware.zip. And something I should have checked and sent from the beginning, the logs of the device after a "breaking" OTA. |
|
That's interesting. It seems like it starts, but crashes while trying to enable wifi. Does it start after a power cycle? You can change the loglevel to |
|
Adding "loglevel" breaks the linking process. |
|
I've added a dummy reset reason function, so it should compile with the latest commit. |
|
Adding loglevel seemed to have stopped somewhat the Hard Fault errors, but I did manage to replicate a couple of times. Case 1 - The yaml file is the same as in my previous post. The change was adding _ loglevel: verbose_. Case 2 - To the above yaml I've added the status_led. This seems to cause Hard Fault even after flashing it over UART. status_led:
pin:
number: D2
inverted: true |
|
Hmm I should've suggested that from the start: This should print the source file name and line number, next to each HardFault error, so that you'll exactly see what's going wrong. For ESPHome, place the .ini line in |
|
Hi @kuba2k2, I've checked the files with a hex editor, and it looks like the firmware.uf2 is corrupted and this causes the boot failure (below start-up log).
|
|
Where do you see that uf2 is corrupted? Each 512 byte block has a 32 byte header, 256 bytes of actual data, and then some amount of "extension tags". Unless you mean that the data or tags themselves are corrupted, it looks perfectly valid to me. If you configure the exception decoder, it will tell you what is causing the crash. |
|
The content is corrupted. The text has some of the characters replaced by special characters. Also at the bottom is my SSID and WPA2 key which normally appear correctly but, in the firmware.uf2 I've posted, contain special characters.
I did set up the decoder, but the above log is all i get. esphome:
name: plug-ezviz
platformio_options:
monitor_speed: 115200
monitor_filters: rtl_hard_fault_decoder
|
|
At 0xF4320 the extension tags begin. This means that the rest of your ssid is in the next UF2 block. Scroll down to 0xF4420 and your ssid should be there. |
|
I know it continues on the next line, but it should say SunnyDay.
|
|
Oh I see now ... sorry 😁 |
|
Im not able to get more out of Here's platformio.ini. plug-eezviz.yaml substitutions:
devicename: plug_ezviz
friendly_name: PLUG-EZVIZ
device_description: EZVIZ TT1 Smart Plug CS-T31-16B-EU
current_res: "0.00221" # Random value. Requires power monitoring calibration
voltage_div: "955" # Random value. Requires power monitoring calibration
esphome:
name: plug-ezviz
platformio_options:
monitor_speed: 115200
monitor_filters: rtl_hard_fault_decoder
libretuya:
board: generic-rtl8710bx-4mb-980k
framework:
version: latest
loglevel: verbose
lt_config:
LT_LOGGER: 1
LT_LOGLEVEL: LT_LEVEL_VERBOSE
LT_LOGGER_TIMESTAMP: 1
LT_LOGGER_CALLER: 1
LT_LOGGER_TASK: 1
LT_LOGGER_COLOR: 1
LT_LOG_HEAP: 1
sdk_silent: true
gpio_recover: true
# Enable logging
logger:
level: VERBOSE
# Enable Home Assistant API
api:
reboot_timeout: 1h
encryption:
key: e3OB6WUqYiEKNoBNbY/RkJnixIDTZCkCqhHqLLI2N1c=
ota:
password: a84b93a735d24a1c5efe59139871e307
web_server:
port: 80
auth:
username: xxxxx
password: xxxxxxxxxxxxxxx
include_internal: true
wifi:
ssid: "SunnyDay"
password: "xxxxxxxx"
# Enable fallback hotspot in case wifi connection fails
ap:
ssid: "${friendly_name} Fallback"
password: "xxxxxxxxxx"
captive_portal:
text_sensor:
- platform: wifi_info
ip_address:
name: ${friendly_name} IP Address
ssid:
name: ${friendly_name} Connected SSID
bssid:
name: ${friendly_name} Connected BSSID
mac_address:
name: ${friendly_name} MAC Wifi Address
button:
- platform: restart
name: ${friendly_name} Restart
sensor:
- platform: wifi_signal
name: ${friendly_name} Wifi Signal
update_interval: 60s
id: ${devicename}_wifi_signal
binary_sensor:
- platform: gpio
device_class: power
pin:
number: D9
mode: INPUT_PULLUP
inverted: true
name: ${friendly_name} Power Button
- platform: gpio
device_class: power
pin:
number: D11
mode: INPUT_PULLUP
inverted: true
name: ${friendly_name} Reset Button
status_led:
pin:
number: D1
inverted: true
light:
- platform: binary
name: "Test Light"
output: light_output
output:
- id: light_output
platform: gpio
pin: D0 |
|
At the risk of sounding crazy or stupid😁, I've checked again the dump from the last OTA update, and I definitely see corrupted characters.
|
|
Would you mind trying this repo/branch? I'll make a PR today, but have no means to test it in RTL chips (only Beken). |
|
@mihsu81 okay, I see the corrupted characters. I'll look into the dumps you posted later today. About the exception decoder: it's showing you a warning that firmware.elf doesn't exist. I don't know why but Esphome uses a different build folder name... Like .pioenvs instead of .pio. I'll have to fix this somehow, but for now you can put the firmware.elf that Esphome compiled, into the path that PIO monitor shows it expects. @dbuezas honestly I don't think it's caused by network issues. I see it happens when using OTA2 mostly, so there may be some problems with UF2 binpatching. That would explain the corrupted characters. |
Thanks @dbuezas. I've tried it but the compilation fails. |
@kuba2k2 thank you for the tips with getting |
|
Right, sorry for that. You need to copy the |
|
Using firmware.ota2.elf renamed to firmware.elf. |
|
Yeah, so now it will tell you what causes the crash. This one actually looks like some kind of corruption - PC (program counter) at 0xfa204, meaning way below the actual flash chip, yet way above the ROM. I see you've edited the last firmware.uf2 you posted, to remove the wifi credentials. If you do so, in the future please leave the first 32 bytes of each block intact - otherwise it's more difficult to analyze it. |
Does this one work? |
|
Yes. But your flash dumps seem to be corrupted in some way - they should have exactly Please, compile a firmware file (using
Then, upload the same file (firmware.uf2) over OTA - without using If the board doesn't stop booting (meaning that the last OTA upload used OTA1), upload with OTA again, using the exact same Post both files here - It is very important that you always upload the same file during this (somewhat complex) procedure, so that I can analyze exactly what's wrong and what corruption in the binaries causes the board to stop working. TL;DR: upload the same file until the board stops booting, using UART in the first run and only OTA later. Should take 2 or 3 uploads, not more, not less. |
|
Okay, actually, hold up with that for a minute @mihsu81 ... sorry for the confusion. Seems like I found a bug in the implementation, that produces same results for me as your corrupted firmware. I'll work on it and let you know. |
|
@mihsu81 I found the bug. I've written a technical explanation on Discord, but will post it here as well, for future reference. You can now update LT ( |
|
Thanks a lot @kuba2k2. I can confirm ltchiptool v1.6.0 fixes the OTA update issue. |
|
That's weird, since I added another function to reset the chip few days ago. But that's a story for another issue I think. I'm glad that OTA upload works now 👍 |
Hi @kuba2k2,
The Generic RTL8710BX (mentioned in my previous support requests) doesn't start after sending a restart command or after an OTA firmware upgrade. https://docs.libretuya.ml/boards/generic-rtl8710bx-4mb-980k/
If I unplug it and plug it again it starts up.
The text was updated successfully, but these errors were encountered: