FAQ
TL;DR: Backing up 2MB from LN882H went from about 14 minutes to 12.5–24.8 seconds, and one tester confirmed, "SmartLife AP seen and pairs in Tuya app." This FAQ is for people flashing LN882H/LN882HKI modules with OpenBeken, restoring Tuya backups, and fixing UART, Wi‑Fi, GPIO, and SSDP issues. [#21609499]
Why it matters: LN882H devices often look simple to flash, but real success depends on correct boot wiring, stable 3.3V power, the right RAM loader, and avoiding reserved GPIOs.
| Tool |
Best use |
OS |
Read/backup speed reported |
Notes |
| SharpLN882HTool |
Flash, erase, backup, restore |
Windows |
24.77s at 921600; 47.52s at 460800 |
Later builds restored full Tuya dumps successfully |
| LN882Loader |
Linux flashing and backup |
Linux |
Earlier full 2MB dumps around 10–14 min |
Reverse-engineered, YMODEM-based |
| Tuya flasher / tyutool_cli |
Vendor flashing |
Windows / Linux extraction |
Read not supported in tyutool_cli |
One user saw: "Don't support read." |
Key insight: The biggest breakthrough was not the firmware itself but the RAMCODE path: once the custom dumper switched to raw binary reads with CRC and stable UART polling, LN882H backup and restore became fast enough to be practical for everyday recovery and migration. [#21608266]
Quick Facts
- Full-flash backup size is 2MB, and one successful custom dumper run finished in 12.5 seconds at 921600 baud after RAMCODE improvements. [#21608190]
- Earlier dump methods were much slower: 2MB in ~14 min 20 s with
LN882H_RAM_BIN.bin, and about 9 min 50 s after changing baud and stub choices. [#21605883]
- A validated speed comparison for SharpLN882HTool v22 showed 184.05 s at 115200, 47.52 s at 460800, and 24.77 s at 921600, with identical SHA-256 hashes across those dumps. [#21609499]
- Safe UART access points identified on a bare LN882HK1-on-PCB board were A2 = TX0, A3 = RX0, A9 = pull low for UART download mode, and B9 = TX1 boot log, often at 921600 baud. [#21593199]
- One reproducible GPIO failure on LN882H was P13 crashing on “Set Output High” in firmware 1.18.42, later linked to flash/QSPI-reserved pins that should not be driven as normal outputs. [#21446468]
1. How do I flash an LN882H or LN882HKI module with OpenBeken step by step using UART and the BOOT pin?
You flash LN882H over UART by grounding one BOOT pin, powering the board at 3.3V, and sending a RAM loader before the firmware. 1. Solder GND, 3.3V, TX, RX, and the BOOT pin. 2. Hold BOOT low, power up, then connect with a flasher tool. 3. Upload the RAM loader, then write OpenBeken to flash at 0x0. The original guide says LN882H flashing is “very similiar to ESP8266,” with BOOT grounded to enter flashing mode.
[#21372895]
2. Where are TX, RX, and boot-mode pins on an LN882HK1 chip mounted directly on the PCB, and how do I identify them safely?
On one directly mounted LN882HK1 board, the reported pins were A2 for TX0, A3 for RX0, A9 for boot-mode entry, and B9 for TX1 boot logs. Safest identification uses labeled pads, board photos, and UART observation before soldering to tiny chip legs. 1. Find GND, 3.3V, and EN first. 2. Check nearby pads against known LN882H pin maps. 3. Confirm with a logic analyzer or boot log on B9 before forcing boot mode.
[#21593199]
3. Why does LN882H flashing fail with a USB-to-UART adapter even when it has a 3.3V output, and how can I troubleshoot power and COM port issues?
LN882H flashing often fails because the adapter is not actually transmitting, the COM port is wrong or busy, or the 3.3V rail is unstable under load. One user fixed repeated failures by replacing a faulty FTDI232 adapter with a CH340G unit; another was told to verify COM6 and check for port-hogging software like Cura. A separate report also found that an AMS1117-based 3.3V source improved flashing stability.
[#21443865]
4. What is YMODEM, and how is it used by LN882H flashing tools and RAM loaders?
“YMODEM” is a serial file-transfer protocol that sends block-based data with acknowledgements and CRC checks, enabling reliable firmware or RAM loader transfer over UART. LN882H tools use YMODEM to upload the temporary RAM loader first, then often use it again to write the actual firmware image. Reverse-engineering in the thread identified YMODEM as the protocol behind the loader flow, and later tool logs showed ACK, EOT, CRC, and packet counters exactly matching that process.
[#21376683]
5. What is SSDP discovery, and why did Alexa or Wemo emulation not work on LN882H until SSDP support was enabled?
Alexa and Wemo emulation did not work because LN882H lacked SSDP support in earlier builds.
“SSDP discovery” is a local-network service discovery protocol that advertises devices over multicast, letting controllers like Alexa find compatible endpoints automatically. In the thread, Wemo emulation showed up in
setup.xml, but Alexa still could not discover it until SSDP and the related networking support were enabled on LN882H. A later post said SSDP had been enabled the previous week.
[#21430384]
6. LN882Loader vs SharpLN882HTool vs Tuya's LN882H flasher — which tool is best for flashing, backup, and restore on Windows or Linux?
SharpLN882HTool became the best all-around choice for Windows once fast dump, erase, and restore worked; LN882Loader stayed strong for Linux; Tuya’s tools were useful for reference but weaker for backup. A tester confirmed SharpLN882HTool erased flash, wrote OpenLN882H, restored a full Tuya dump, and then saw the “SmartLife AP” pair in the Tuya app. Another user also reported tyutool_cli could communicate with the chip but ended with “Don't support read.”
[#21609499]
7. Why is dumping LN882H flash so slow with flash_read or fdump, and how did the custom RAMCODE speed it up?
The old dump path was slow because it read tiny chunks as ASCII hex over UART instead of sending raw bytes. One developer explained that
flash_otp_read 0x0 0x100 returned text like
AE BE 4F 2D 5A, meaning roughly 3 characters per stored byte. The custom RAMCODE changed the method to raw binary blocks plus CRC, which removed the ASCII overhead and made full 2MB reads practical in seconds instead of minutes.
[#21607145]
8. How can I back up the full 2MB flash from an LN882H module and restore that backup later without losing Tuya or OpenBeken data?
You can back up the full 2MB flash, erase the chip, and later restore that exact image to recover Tuya or OpenBeken. 1. Use a tool that reads the full 0x200000 flash range to a file. 2. Save that dump before experimenting. 3. If needed, erase flash and write the saved file back at 0x0. A tester erased an LN882H, reflashed a Tuya dump with SharpLN882HTool, and confirmed the SmartLife AP appeared and paired in the Tuya app.
[#21609499]
9. Which LN882H GPIOs are unsafe to drive as outputs, and why do some pins cause WDT resets or crashes in GPIO Doctor?
Some LN882H pins mapped to the internal flash/QSPI area are unsafe as normal outputs and can trigger crashes or WDT resets. One contributor stated that pins from A13 to B2 should not be used because they are reserved for QSPI, likely internal flash. Real testing also showed repeatable crashes, including P13 on “Set Output High” in version 1.18.42, and later fixes focused on disabling those dangerous pins in HAL.
[#21446533]
10. How do I use GPIO Doctor or manual testing to find the relay, button, LED, and PWM pins on an unknown LN882H device?
Use GPIO Doctor carefully, starting with inputs and low-risk checks, then test outputs one at a time while watching for crashes. 1. Back up flash first. 2. Probe candidate pins as digital input or input-pullup before driving outputs. 3. Map relay, LED, button, and PWM by changing one pin at a time and noting physical responses. This matters on LN882H because some pins can crash the device, yet the same method still helped users identify working relay and PWM pins on unknown boards.
[#21446543]
11. What Wi-Fi settings are actually available in OpenBeken for LN882H besides Power Save, and what else can cause random disconnects on one network but not another?
Beyond Power Save, the thread only names Quick Connect as another practical LN882H Wi‑Fi option in OpenBeken. A developer added that Wi‑Fi behavior mainly comes from the LN882H SDK, not shared OBK code, so stability can change by platform. In the reported disconnect case, likely causes included local RF noise, supply quality, MQTT load, and possibly flash state or calibration, especially because the same device stayed stable for 3 days on a different network.
[#21579867]
12. Why did WPA3 or WPA2/WPA3 connections fail on older LN882H SDK builds, and what changed in the newer Wi-Fi library versions?
Older LN882H builds failed on WPA3 because the Wi‑Fi library rejected association, including repeated reason code 43 errors. That changed after the SDK moved to newer Wi‑Fi libraries, including WiFi Lib 1.5.0, where one tester successfully joined a WPA‑SAE (CCMP) access point and verified fast reconnection after the AP returned. The same tester also said WPA2-only and mixed WPA2/WPA3 then behaved correctly.
[#21615134]
13. How does the faster custom LN882H RAM dumper work, including baud rate, CRC checks, and polling vs interrupt-based UART TX?
The faster dumper uploads a custom RAMCODE, reads flash in fixed binary blocks, appends a 2-byte CRC16 to each block, and transmits over a high UART baud rate. One implementation used 512-byte flash blocks plus CRC and achieved stable dumps at 921600 baud after switching UART TX from interrupt mode to polling mode. The author said polling was not faster by itself, but it was more stable and fixed CRC failures seen at higher baud rates.
[#21610067]
14. What does LN882H RAMCODE do during flashing, and how is it different from the normal bootloader or secondary boot stage?
RAMCODE is a temporary program sent over UART into RAM so the chip can erase, write, dump, and inspect flash using richer commands than the ROM alone provides.
“RAMCODE” is a RAM-resident helper program that runs after UART boot, adds flash commands, and then hands control back or resets after the task finishes. The SDK description in the thread distinguishes it from the normal
bootload stage, which is the secondary boot path from flash to app during standard startup.
[#21605903]
15. How can I build a custom OpenBeken OTA firmware for LN882H with extra drivers like SHT3X enabled, either locally or through GitHub Actions?
You can build it locally or through GitHub Actions by enabling the driver macro for LN882H. The thread’s build steps say to add
#define ENABLE_DRIVER_SHT3X 1 under
#elif PLATFORM_LN882H in
src/obk_config.h, then run
make OpenLN882H locally. If you do not have the toolchain, fork the repository, enable Actions on the fork, commit the config change, and download the finished firmware artifact from the workflow summary.
[#21709798]
Generated by the language model.
Comments
I wrote a flashing tool for Linux. https://github.com/mandl/LN882Loader [Read more]
That's very nice! How did you know the UART protocol details? I didn't research it yet, so I don't know if it's documented, or available somewhere, or did you have to reverse-engineer it? @divadiow... [Read more]
I'll give it a spin. A better, faster, LN882H flash READ option would be cool too if that could be added. [Read more]
He seems to have this in main: #h.readFlash() which resolves to: def readFlash(self): self.ser.write(bytes(b'flash_read 0x0 0x1000\r\n')) msg = self.ser.readline() ... [Read more]
:) https://obrazki.elektroda.pl/7985689700_1735993103_thumb.jpg https://obrazki.elektroda.pl/3756362700_1735993187_thumb.jpg Ubuntu 24.04.1 LTS [Read more]
Try to edit main file to run that mentioned h.readFlash() command and let's see what you'll get? [Read more]
not entirely sure how you mean to achieve that. I went into a GPT hole.. https://obrazki.elektroda.pl/8229946100_1735999555_thumb.jpg looked like it was doing something but it wasn't ... [Read more]
I've checked his code futher and it seems that LN882H is using YMODEM protocol for UART communication: https://en.wikipedia.org/wiki/YMODEM It may be relatively easily to implement it in our flasher... [Read more]
Hello @p.kaczmarek2, all my work is based on reverse engineering. I didn't find any documentation about the protocol. I found a new command for flash dumping ... fdump Regards and happy hacking... [Read more]
cool. will have a play when I am back home. I have Windows laptop and LN882H with me but py script doesn't seem to be playing ball at the moment. I'm curious about what you reverse-engineered. was it... [Read more]
Well, there are at least 3 options, he could have: - captured communication with UART sniffer or separate USB to UART tool or Sigrok etc etc - decompiled flashing tool that runs on PC with IDA pro or... [Read more]
I am looking for help with the Wemo driver for the LN88H. I have started the service and it shows in the setup.xml file but Alexa will not discover it. Wemo support has been successfully discovered... [Read more]
You need SSDP support (alongside startdriver ssdp), and it is not currently enabled on LN. [Read more]
My memory must be failing me, didn't you ask the same question recently? Or maybe I'm wrong... Anyway, SSDP requires IGMP Flag: https://obrazki.elektroda.pl/1104415900_1736026119_thumb.jpg It seems... [Read more]
That was for TR6260 https://github.com/openshwprojects/OpenBK7231T_App/pull/1480 [Read more]
@stefanmandl1 what are the args to dump to file? Added after 17 [minutes]: ah. uncomment h.dumpFlash() https://obrazki.elektroda.pl/9306253800_1736082169_thumb.jpg Added after 3 [hours]... [Read more]
Hello @divadiow, try this for more speed. https://obrazki.elektroda.pl/2291531900_1736094937_thumb.jpg [Read more]
OK, so with the attached, which contains h.changeBaudrate(921600) , the speed is still not 921600, but the 2mb was finished at ~9 mins 50s https://obrazki.elektroda.pl/8987540800_1736230333_thum... [Read more]
out of curiosity I tried the dumper script with what looks like the boot file for LN8825x using this test device. Sadly no joy though I do see mention of fdump in the bin. Feel free to have a look through... [Read more]