Help with a Midea SmartKit Dongle
dhewg opened this issue · comments
My Midea dehumidifier came with a WiFi dongle, the case reads EU-SK-105.
It has a USB connector, but the data lines are just UART TTL lines to another board. Those are apparently 5V.
It's rather tiny, not that readable and I don't have a nice cam around, but apparently it has a RTL8720C:
If I attach a 3.3V CH341 UART TTL to LOG_TX/RX I can read from and write to it:
== Rtl8710c IoT Platform ==
Chip VID: 5, Ver: 3
ROM Version: v3.0
== Boot Loader ==
Nov 30 2020:20:11:23
Boot Loader <==
== RAM Start ==
Build @ 17:50:15, Dec 2 2022
$8710c>
Initializing WIFI ...
WIFI initialized
count:15, interval:8
init_thread(57), Available heap 0x154c0
#
#
#help
WLAN AT COMMAND SET:
==============================
1. Wlan Scan for Network Access Point
# ATWS
2. Connect to an AES AP
# ATW0=SSID
# ATW1=PASSPHRASE
# ATWC
3. Create an AES AP
# ATW3=SSID
# ATW4=PASSPHRASE
# ATW5=CHANNEL
# ATWA
4. Ping
# ATWI=xxx.xxx.xxx.xxx
(note that the initial prompt reads 8710c)
But I'm not sure how to enter download mode, the flash info ambz2 help reads strapping pin (GPIO 0 / PA00) has to be pulled *to 3.3V*. Since that a current and I try to salvage that thing instead of destroying it.... any idea which contacts I have to short?
Thanks!
First of all, I don't see a 3.3V regulator on this board, nor any transistors required to convert UART to the apparent 5V. It's most likely just misleading silkscreen - DO NOT power it from 5V, you may kill the chip!
I don't know which pin might be A0. You might have a bit of luck by checking the RTL8720CF pinout and seeing where the PCB trace goes from that pin.
Since the device uses default AT firmware, it's totally possible that the A0 pin is just not there at all. Or maybe the firmware has a command to run download mode - the AT command set printed with help is just a small part of the available commands, IIRC.
Ok, thanks, I'll try to trace...
I found a few AT commands, does any of those ring any bell?
unknown command 'AT'
unknown command 'AT?'
[ATSR]: _AT_SYSTEM_RECOVER_OTA_SIGNATURE_
unknown command 'ATSV'
ATSP
[ATSE]: _AT_SYSTEM_EDIT_REGISTER_
[ATSE] Usage: ATSE=REGISTER[VALUE]
unknown command 'ATSY'
unknown command 'ATSU'
unknown command 'ATSO'
[ATSC]: _AT_SYSTEM_CLEAR_OTA_SIGNATURE_
[ATSG]: _AT_SYSTEM_GPIO_TEST_
[ATSG] Usage: ATSG=PINNAME(ex:A0)
Found ATXX in packages/framework-realtek-ambz2/component/common/api/at_cmd/atcmd_sys.c
#ATXX
== Rtl8710c IoT Platform ==
Chip VID: 5, Ver: 3
ROM Version: v3.0
Test Mode: boot_cfg1=0x20
Download Image over UART2[tx=16,rx=15] baud=115200
$ ltchiptool flash info -d /dev/ttyUSB0 ambz2
I: Connecting to 'Realtek AmebaZ2' on /dev/ttyUSB0 @ 115200
I: |-- Success! Chip info: RTL8720CF
I: Reading chip info...
I: Chip: RTL8720CF
I: +---------------------+-------------------+
I: | Name | Value |
I: +---------------------+-------------------+
I: | Chip VID | 5 |
I: | Chip Version | 3 |
I: | ROM Version | v3.0 |
I: | | |
I: | Chip Type | RTL87x0CF |
I: | MAC Address (Wi-Fi) | FF:FF:FF:FF:FF:FF |
I: | MAC Address (BT) | FF:FF:FF:FF:FF:FF |
I: | Boot Debugging | Disabled |
I: | Secure Boot | Disabled |
I: | | |
I: | Flash Type | RTL8720CF |
I: | Flash Mode | SINGLE |
I: +---------------------+-------------------+
I: |-- Finished in 0.834 s
Nice!
Great. Keep in mind that if you flash something that doesn't work, you might never be able to enter flashing mode again, because of no A0 pin.
Good point. It might still be there, but it's all so tiny and I don't have proper tools for that
And with that in mind, just to double check, does this look okay to you? Just to get an OTA ready esphome on there:
esphome:
name: dehumidifier
rtl87xx:
board: generic-rtl8720cf-2mb-992k
logger:
level: VERBOSE
api:
encryption:
key: !secret api_encryption_key
ota:
password: !secret ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
password: !secret wifi_ap_password
captive_portal:
I got a few warnings with that:
.platformio/packages/library-freertos/FreeRTOS/Source/tasks.c:2193:6: warning: implicit declaration of function '__get_IPSR' [-Wimplicit-function-declaration]
...
Linking .pioenvs/dehumidifier/raw_firmware.elf
|-- Image 1: raw_firmware.ota1.elf
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .ram.code_text changed by 4
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .glue_7 changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .glue_7t changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .vfp11_veneer changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .v4_bx changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .iplt changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .system_restore_data changed by 8
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .bss changed by 32
|-- Image 2: raw_firmware.ota2.elf
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .ram.code_text changed by 4
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .glue_7 changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .glue_7t changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .vfp11_veneer changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .v4_bx changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .iplt changed by 2
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .system_restore_data changed by 8
.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: warning: start of section .bss changed by 32
ESPHome doesn't support OTA for RTL8720C. You won't be able to update via OTA yet, however you should be able to flash via UART in most cases - LibreTiny should automatically reboot to download mode when you start flashing.
Note that this is not stable software yet. Rebooting to download mode might not work and you'll have trouble getting the board flashed again.
These linker warnings, however, are usually okay.
Oh okay. Maybe it's a good idea to error out on ota: then?
Is there any mechanism to enter download mode? With esphome's boot loop detection? Spam some key on uart tx upon boot?
ota: can stay, it will do no wrong. Uploading any file won't work anyway.
Download mode should enter automatically when you connect the flasher program. It detects a specific byte sequence.
See: https://docs.libretiny.eu/docs/flashing/tools/adr/?h=auto
Of course it didn't work...
== Rtl8710c IoT Platform ==
Chip VID: 5, Ver: 3
ROM Version: v3.0
== Boot Loader ==
Nov 30 2020:20:11:23
[MISC Err]Sub-Image FST Decrypt Err!
Boot Load Err!
I'll fetch my equipment from the office and try to trace later. Maybe I can find A0, I do have a full flash backup