Support for RTL8710CM? #44
Comments
|
anything we can do to push support forward? idk what's missing/required :( |
|
Not really, unless you either know C/C++ well and are comfortable working in crappy vendor SDKs, or can buy me more time 😄 |
|
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 It seems compiling a project with PlatformIO and/or libretiny doesn't pull in the |
|
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 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 |
|
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 |
|
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 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?
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 |
|
|
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 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). |
You rock. I'll give it a whirl. |
Success! WiFi shortly there-after disassociated but subsequently reconnected: 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: |
Initially, I hacked my way through this, unaware that I could specify these things in the device YAML; I rtl87xx:
board: wbr3
framework:
version: 0.0.0
source: https://github.com/libretiny-eu/libretiny.git#feature/realtek-updatesMainly,
It seems the trend is to use a I guess |
|
Also, it seems the firmware insists on outputting to UART2 (LOG_TX / LOG_RX), messages from WiFi 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 |
|
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? PS I notice that |
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 Then, I noticed in the debug output that the UART0 and UART1 RX/TX pins were outputting as 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
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: |
|
Hi @nmschulte just wondering how stable is LT running on the thermostat since? |
|
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 |
|
Sorry if I sound stupid here but I can’t get esphome to see wbr3 as a valid board type. Can someone give brief instructions on how they got the necessary version of esphome installed? thanks. |
Hello, Here is my code in yaml I had the same problem as you before put |
|
WBR1 and WBR3 (and all Tuya RTL8720CF boards) are identical except for the pinouts, so they will run fine. Generic rtl8720cf has a different offset, since it's meant for BW15 board (which has a separate definition too). |
|
@rtorrente That worked :-) I was able to compile esphome firmware without issue. send error: expected ACK; got b'\x15' for block 16 Anyone seen this before or know the reason? |
|
How are you guys writing the firmware to the modules? Are you using ltchiptool or something else? |
Yes,
|
|
What board are you flashing? RTL8710CM or RTL8720CF? |
|
I have a TP-Link Tapo P100 smart plug which has a RTL8720CF. Tried board:generic-rtl8720cf-2mb-992k, got the "Hash result incorrect" message on boot. Then I tried board: WBR3 with the following: The device can boot and connect to WiFi. But I can't switch the relay on. I tried all GPIO from 0 to 23. None of them switch on the relay or the LED indicator. Any thoughts? |
https://www.youtube.com/watch?v=P8cm8HFuG6s Though it looks like it may differ by specific model, though I expect the GPIO is the same (no idea why they'd change it): https://www.youtube.com/watch?v=99iAK1JeAeo |
|
Did you make it work with ESPhome? What is your gpio configuration for the relay, LED, and button? |
How can you use pinscan? I want to find the correct pin in a TP-Link Tapo P100 smart plug which has a RTL8720CF. |
Ensure you have PlatformIO installed. Review the Quick Start Guide if you haven't used PlatformIO directly before. Clone the PinScan repo. Edit You should then be able to build by running Be careful what pins you manipulate arbitrarily, though. Don't have the device plugged into the mains when manipulating it. Power the 3.3v rail only (as you would when flashing). There may be pin configurations that damage/break the device; I'd highly recommend tracing the PCB traces as much as possible before switching random pins to As an aside, how difficult was it to get into the TP-Link Tapo P100? The TP-Link EP25/KP125 Smart Plugs were an absolute pain to open without causing visible damage. Maybe with practice you could do it. They seem like great plugs that are well-built. With libretiny, Esphome seems to run great. I'm waiting on OTA support before I can really start using them, though. |
I successfully flashed the PinScan example. (I need to use the board= wbr3 and feature/realtek-update branch though. Otherwise, it boots with a hash error). However, by using the PinScan tool, I still cannot find the GPIO of the relay or the status LED. Very weird. The TP-Link Tapo P100 is also very hard to open. |
I'm glad you got it flashed. It definitely took some fiddling to figure out the pinout and PinScan over telnet was a bit finicky. Two things to keep in mind:
|
Did you ever resolve this? I am seeing the same problem. And this is the topic was the only result googling for it. |
|
Hello,
Unfortunately, I can't find this chip layout at: But it is RTL8720CF. I will patiently wait for updates. Thank you for all your work. |
|
Just wanted to share that after traveling down miles of rabbit-holes, I came to the unusual discovery that RTL8710CF (which I want to point out is slightly different chip ID from the OP's RTL8710CM, and also different from RTL8720CF that was discussed later -- if there's no meaningful difference in the hardware, apologies for the noise) can actually be compiled & successfully flashed with the following ESPHome yaml snippet: rtl87xx:
board: wbr3
family: rtl8720c
framework:
version: 0.0.0
source: https://github.com/libretiny-eu/libretiny#feature/realtek-updateFWIW, my RTL8710CF was found inside a Kasa HS200(US) hardware v5 (e.g. the smaller one compared to some of the earlier HS200's, I haven't opened one of those yet to see what's inside). Initially, having read this and other issues plus the LibreTiny documentation discussing the Ameba chip nomenclature, I didn't actually realize I had an RTL8710CF and not an RTL8720CF or RTL8710CM. |
|
Oh, interesting. Thank you for the heads-up, @k-w-1! I guess I can re-add the M515EGWT blinds I once bought (with a wbr3 chipset) into my queue :) (pointing the other threads here accordingly) |
|
The RTL8710/8720/CM/CF chips are similar and compatible. The difference between 8710 and 8720 is Bluetooth support in 8720. The difference between CN and CF is memory, CF having built-in flash memory, CM having built-in PSRAM. Keep in mind that while ESPHome works on these chips, certain features are not supported and the firmware might be unstable. A notable example of such features is OTA updating. |
|
Thank you very much for the detailed information, @kuba2k2! |
This is very timely news indeed, since I have just popped open my Kasa EP10 smart plug and discovered it has an RTL8710CF in it! |
|
Has anyone found a proper pinout for such a chip/board yet? |
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.
The text was updated successfully, but these errors were encountered: