libretiny-eu
Support for RTL8710CM?
Is there support for RTL8710CM yet? I have a couple of devices (Tapo L920 LED controllers) using this chip and would love to be able to flash them with libretuya/esphome.
Not really, unless you either know C/C++ well and are comfortable working in crappy vendor SDKs, or can buy me more time :smile:
I've successfully compiled and ran the PinScan example (amazingly helpful, btw!) and flashed libretiny-esphome on a RTL8710CM with your recent changes.
Everything I was able to test seems to work using the generic-rtl8720cf-2mb-992k board (with the exception of esphome OTAs, but it doesn't look like OTAs are implemented for any of the libretiny-supported RTL MCUs at the moment). The boards I'm playing with (TP-Link EP25/KP125 Smart Plugs) are extremely simple though so outside of WiFi & GPIOs there isn't much. Only minor issue is I cannot seem to read the onboard BL0937 (see: HLW8012). I might have it configured incorrectly, though; I need follow the traces again and/or try interfacing directly instead of using esphome.
It seems compiling a project with PlatformIO and/or libretiny doesn't pull in the AT command CLI from the SDK. Is there a configuration option and/or flag I've glossed over that enables it? This would allow use of the built-in OTA functionality. I had to flash the flash.bin image directly onto the SPI flash because the EP25s refuse to go into UART download mode (even after flashing a libretiny-built project).
RTL8720C only has very draft support. Some people (incl. me) have reported ESPHome to work, but not stable.
OTA is implemented for Beken and RTL8710B - only RTLC doesn't support it at present.
The AT CLI is a default "demo" application of the SDK - it isn't (and won't be) available in LibreTiny. The built-in OTA functionality is very basic and also will not be supported. Instead, UF2 OTA will be implemented (at some point...), just like on Beken and the other Realtek. This is a universal and safe format that we're using for everything in LibreTiny.
Download mode hasn't been documented yet (as in: very draft support), but can be activated by pulling PA0 and PA13 to 3.3V, and resetting the chip/power cycling while doing that. It takes a few attempts to do so, but gets easy after you get it.
Note: after you first flash LT, download mode can be entered automatically (or by sending ping\n on UART2). That's not tested well enough, and from my attempts writing has been failing sometimes in this mode.
As for the BL0937, see https://upk.libretiny.eu/ - find a plug with power monitoring, generate a YAML for it, and see which pins usually need the invert: true flag.
Thanks for the information!
Yes, I realized support for the RTL8720C family is in the very early stages. Just figured I'd report my findings.
That makes sense regarding the AT CLI. Since the stock TP-Link EP25 had it I assumed it was standard and always built w/ the RTL MCUs. Their firmware must be based off the "demo" (which makes sense, I guess).
A quick perusal through their stock firmware revealed that there seems to be a way to trigger the SDK-included OTA function remotely. It may be possible replace the stock firmware on these smart plugs wirelessly without opening them up! 😎
I'll poke around some more with download mode. I've tried ping\n on UART2 but I wasn't aware of the PA0/PA13 combination. These EP25 plugs are hard enough to get open so anything that makes re-flashing easier will be helpful.
Eventually OTA will be supported.
Have you dumped the original firmware prior to flashing? If yes, you can always mess with it by just flashing it back.
I've got a couple of tp-link KP115 Kasa Smart Wi-Fi Plug (slim energy monitoring) which appear to contain RTL8710CF modules (12-pin pcb mounted through hole on the main board)
I'm keen to test these out with libretiny if someone has some pointers for how I get started?
As indicated in this thread (and in LibreTiny docs -> boards, chips, features) RTL8720C is not yet fully supported. Thus, the documentation pages are also not fully written.
Kinda why I was asking here ;-)
I'm an out of practice embedded C/C++ developer who is willing to have a play with it, but thought rather than re-doing work that's already been done I'd ask the question.
I was playing with a Tuya WBR3-laden ME81H (thermostat for a heater). I see above documentation that I found from this page during my trials: https://developer.tuya.com/en/docs/iot/burn-and-authorize-wbr-series-modules?id=Ka78imt8pf85p#title-7-Method%202%3A%20Separated%20solutions%20for%20flashing%20and%20authorization
After fixing up ltchiptool to support Linux (https://github.com/libretiny-eu/ltchiptool/pull/13), I was able to dump the OEM Flash and ROM, and to burn a build of ESPHome/generic-rtl8720cf-2mb-992k to the module. Booting this image however is troublesome; I run into a bootloader verification failure, and so booting halts:
INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[19:48:39]
[19:48:39]== Rtl8710c IoT Platform ==
[19:48:39]Chip VID: 5, Ver: 3
[19:48:39]ROM Version: v3.0
[19:48:39]
[19:48:39]== Boot Loader ==
[19:48:39]Dec 5 2019:14:02:18
[19:48:39]
[19:48:39]fwx SELE[fffffffe]
[19:48:39]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:39]fw2 USE, return sn 1
[19:48:40]
[19:48:40]== Rtl8710c IoT Platform ==
[19:48:40]Chip VID: 5, Ver: 3
[19:48:40]ROM Version: v3.0
[19:48:40]
[19:48:40]== Boot Loader ==
[19:48:40]Dec 5 2019:14:02:18
[19:48:40]
[19:48:40]fwx SELE[fffffffe]
[19:48:40]fw SELE Bitidx 1, fw1 valid 0, sn 0, fw2 valid 1, sn 1
[19:48:40]fw2 USE, return sn 1
[19:48:40][MISC Err]Hash Result Incorrect!
[19:48:40]Boot Load Err!
Comparing the dumped images, it seems the initial (and trailing?) portions of Flash are the same; I see "hash" related strings at the same offsets (I have not poked with Ghidra yet, lacking the time currently).
I wonder if using the Tuya "RTL8720CF chip burning tool" would program the correct hash, or if this has been reversed yet?
Download and run the RTL8720CF chip burning tool."
Anyway, it seems I'm at a dead end with this board, and support is in progress, so kudos for everything so far and in the works. In the mean time, I've ordered an ESP32-C3-12F module to replace this unit (which seems to operate fine without the Tuya module installed, in case anyone needed to know).
As such, let me know if there's anything I can test or help reverse to support the Tuya WBR3/RTL8720CF.
@nmschulte I can look into this if you post the OEM firmware dump - it contains the hash keys, so that I can check if they are the same as used in LT.
I can look into this if you post the OEM firmware dump
This firmware uses OTA1 address of 0x10000, while the board you've chosen has it at 0xC000 - it's incompatible with WBR3.
As you've noticed, support is in progress. The WBR3 board (with correct offsets) is available in feature/realtek-update branch of LibreTiny. If you checkout that branch (I believe you can use version: dev under framework: and then add source: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to use board: wbr3.
That being said, when RTL8720CF support rolls out, it will automatically adjust flash addresses to match the chosen board code (same will be done for RTL8710BN shortly).
The WBR3 board (with correct offsets) is available in
feature/realtek-update
You rock. I'll give it a whirl.
You rock. I'll give it a whirl.
Success!
INFO Successfully uploaded program.
INFO Starting log output from /dev/ttyACM1 with baud rate 115200
[12:10:22]
[12:10:22]Boot Loader <==
[12:10:22]
[12:10:22]== RAM Start ==
[12:10:22]I [ 0.000] LibreTiny v1.4.1+sha.d41d328 on wbr3, compiled at Nov 2 2023 11:53:56, GCC 10.3.1 (-Os)
[12:10:33]Interface 0 IP address : 192.168.1.176[I][wifi:560]: WiFi Connected!
[12:10:33][D][wifi:569]: Disabling AP...
[12:10:33][C][ota:097]: Over-The-Air Updates:
[12:10:33][C][ota:098]: Address: thermostat.local:8892
[12:10:33][C][api:025]: Setting up Home Assistant API server...
[12:10:33][I][app:062]: setup() finished successfully!
[12:10:33][I][app:102]: ESPHome version 2023.11.0-dev compiled on Nov 2 2023, 11:51:43
[12:10:33][C][lt.component:013]: LibreTiny:
[12:10:33][C][lt.component:014]: Version: v1.4.1+sha.d41d328 on wbr3, compiled at Nov 2 2023 11:51:25, GCC 10.3.1 (-Os)
[12:10:33][C][lt.component:015]: Loglevel: 3
[12:15:22][I][ota:117]: Boot seems successful, resetting boot loop counter.
[12:15:22][D][lt.preferences:104]: Saving 1 preferences to flash...
[12:15:22][D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
WiFi shortly there-after disassociated but subsequently reconnected:
[12:15:48]wifi link err:001f0002
[12:15:48]dissconn reason code: 4
[12:15:48]receive deassoc
[12:15:48]handshake done, connected stage, recv deauth/deassoc
[12:15:52]Interface 0 IP address : 192.168.1.176[W][component:214]: Component wifi took a long time for an operation (4.33 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.
[12:15:52][I][wifi:560]: WiFi Connected!
[12:15:52][D][wifi:569]: Disabling AP...
[12:15:52][W][component:214]: Component wifi took a long time for an operation (0.06 s).
[12:15:52][W][component:215]: Components should block for at most 20-30ms.
And later, after another (minutes after) diss-/re-assoc; perhaps this is expected, as I'm unfamiliar w/ ESPHome and didn't do anything but let the code run:
[12:25:33][E][api:128]: No client connected to API. Rebooting...
[12:25:33][I][app:127]: Forcing a reboot...
[12:25:33]trace task is needed to print trace log
[12:25:33]hci_uart_deinit: deinit c}ll twice
[12:25:33]
[12:25:33]== Rtl8710c IoT Platform ==
[12:25:33]Chip VID: 5, Ver: 3
[12:25:33]ROM Version: v3.0
[12:25:33]Test Mode: boot_cfg1=0x20
[12:25:33]Download Image over UART2[tx=16,rx=15] baud=115200
If you checkout that branch (I believe you can use
version: devunderframework:and then addsource: https://github.com/libretiny-eu/libretiny#feature/realtek-update, or something similar) you'll be able to useboard: wbr3.
Initially, I hacked my way through this, unaware that I could specify these things in the device YAML; I platformio install'd the libretiny branch, and then manually ran generate_components.py and patched ltchiptool. But, to use this mechanism, one must specify like so in the device YAML, to have PlatformIO/ESPHome automatically pull the correct version:
rtl87xx:
board: wbr3
framework:
version: 0.0.0
source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updates
Mainly, version needs to be a proper semver, and cannot match something listed in ARDUINO_VERSIONS, otherwise this error arises:
Framework version needs to be explicitly specified when custom source is used.
It seems the trend is to use a version: 0.0.0 spec in this kind of scenario.
I guess ltchiptool could be installed in the same way w/ platformio install https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update (or perhaps pip install git+https://github.com/libretiny-eu/ltchiptool.git#feature/flasher-update); I still manually patched whichever instance is in use.
Also, it seems the firmware insists on outputting to UART2 (LOG_TX / LOG_RX), messages from WiFi driver:
[Driver]: ....
As well, I can't seem to configure ESPHome to output on the other exposed UART (TXD / RXD; 13 and 14 I believe). This is stumping me.
After modifying libretiny to define PIN_SERIAL0_RX and PIN_SERIAL0_TX, I now have a Tuya Climate device working seemingly well on the WBR3. Kudos!
UART2 is the default port for log messages, same applies for Tuya firmware. Why did you need to change it, and how did you try to do so?
Setting LT_UART_DEFAULT_PORT to 0 or 1 should redirect all UART output to that port. If you need to get rid of the WiFi messages specifically, try using LT_UART_SILENT_ALL.
PS I notice that PIN_SERIAL0_RX_0 is defined instead; this is because WBR3 has two GPIOs which can be used as Serial0 pins. i assume that your issue is that Serial0 is not defined because of the additional _0 suffix. This has been fixed on feature/i2c-spi branch already, and thus will be available on the master branch at some point.
UART2 is the default port for log messages, same applies for Tuya firmware. Why did you need to change it, and how did you try to do so?
I didn't need to change the logging UART. Though, because I was unable to use the other UARTS (HW_UART1 and HW_UART2, because the hardcoded checks against PIN_SERIALn_RX/..._TX, which seem to default to -1/255), I did try disabling the logging and connect this UART (HW_UART2) to the Tuya comm interface ... but because the WBR3 firmware/driver outputs to/configures it regardless, this failed (ME81H seems to require 9600 baud, as well).
Then, I noticed in the debug output that the UART0 and UART1 RX/TX pins were outputting as -1/255 (due to falling into SoftwareSerial) and so discovered the issue that feature/i2c-spi purportedly resolves; I couldn't find any uses of PINS_SERIALn_..., and so just jammed in PIN_SERIAL0_... with 13 and 14, and then ESPHome/LT picked up the Tuya uart: YAML and configured the correct UART for Tuya comms (UART0; WBR3 TXD/RXD pins).
diff --git a/boards/variants/wbr3.h b/boards/variants/wbr3.h
index 40f6595..d40a1d5 100644
--- a/boards/variants/wbr3.h
+++ b/boards/variants/wbr3.h
@@ -28,8 +28,10 @@
// ------------
#define PIN_SERIAL0_RX_0 12u // PIN_A12
#define PIN_SERIAL0_RX_1 13u // PIN_A13
+#define PIN_SERIAL0_RX 13u // PIN_A13
#define PIN_SERIAL0_TX_0 11u // PIN_A11
#define PIN_SERIAL0_TX_1 14u // PIN_A14
+#define PIN_SERIAL0_TX 14u // PIN_A14
#define PIN_SERIAL1_CTS 4u // PIN_A4
#define PIN_SERIAL1_RX_0 2u // PIN_A2
#define PIN_SERIAL1_RX_1 0u // PIN_A0
Setting LT_UART_DEFAULT_PORT to 0 or 1 should redirect all UART output to that port. If you need to get rid of the WiFi messages specifically, try using LT_UART_SILENT_ALL.
The build is already proceeding w/ these defines, yet the WiFi output still persists. This is not an issue though as it's on the logging UART:
-DLT_UART_SILENT_ALL=1, -DLT_UART_SILENT_ENABLED=1
Hi @nmschulte just wondering how stable is LT running on the thermostat since?
Admittedly I haven't yet put it into production, only had it running for about a day trial during the above. It dropped WiFi a few times, but re-authed each time. Seemed to have no issues then; I'm just going to put it into service and see how it fares ... soon-ish (maybe a week or two) I should be able to install it and give better feedback.
Have the branches merged yet? I assume not; am hesitant to alter my dev. environment until then.
It dropped WiFi a few times, but re-authed each time.
How frequent did that happen and does it stay offline for too long before reconnecting?
How frequent did that happen and does it stay offline for too long before reconnecting?
I only noticed less than a handful of times, and it basically immediately reconnected each time. I wasn't sure the cause. Admittedly, I didn't pay it much mind; the overnight test, showed no issues with the temperature history displayed in HASS.
Hello,
I just saw a new tuya module to control a pellet stove today. It is based on WBR1
I tried to flash ESPHome. I used generic-rtl8720cf-2mb-992k to compile ESPHOME. It work fine and I can flash, but I have the same HASH Result incorrect as for the WBR3 above in this issue.
I presume it's the same problem of offset as WBR3. Unfortunately, I think I'm unable to make the same commit as you made for WBR3 but i I can provide some informations about the module to help in development of this lib
Here is the OEM Dump
Flash : ltchiptool_ambz2_2023-12-11_13-15-16.bin.zip
Rom : ltchiptool_ambz2_2023-12-11_19-39-16_rom.bin.zip
You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.
instructions what should be added to your ESPHome YAML.
I shared what I found to work here (it has specifics): https://github.com/libretiny-eu/libretiny/issues/44#issuecomment-1791694851
I still had to do the serial modification; the spi-i2c branch didn't seem to have what I needed, but maybe my config was wrong or I misunderstand somehow.
Also, I haven't put my device in to service yet; still waiting ... but I'm confident it will work fine.
You can use the dev branch. In my post about offsets there are instructions what should be added to your ESPHome YAML.
Sorry, I didn't realize that the instructions for WBR3 would maybe work with WBR1 as I don't see WBR1 in your commit in feature/realtek-update.
I'll test with board: WBR3 tonight and report back here.
I can confirm that the WBR1 boot fine with WBR3 config from the dev branch after flashing. Offset seems identicals
For the moment, this board is a spare part for me, so do not hesitate if you need any tests that can help to push support for RTL8710Cx forward