How is the W806 different from the W800/W801, and what OTA update method does the W800 support?
The HLK-W806-Kit-V1.0 tested in the thread appears to be a different target from the HLK-W800/W801 boards: it reportedly has no Wi‑Fi/BT and only 1 MB flash, so the W800 firmware does not flash directly and the effort shifted to trimming the SDK/build to fit [#21081609][#21534154] Later W800 experiments showed the port can boot and run with a heavily reduced build, but only after disabling features such as hostif/rmms, the SDK web server, and iperf to keep the binary size under control [#21534154][#21526615] For OTA, the W800 path is the older HTTP-server-based OTA; in newer builds, OTA can also succeed via `new_tcp_server`, but it is slower and more memory-hungry [#21527634][#21526615]
Well, it can't be helped for now.
I will later try to update sdk to v1.00.10
But for now, do i open a pull request with those changes?
Currently all of the drivers and lfs can be compiled, where previously lfs build was disabled.
Would it be possible to get those changes (drivers, etc, lfs, you mentioned) without broken UART? We have some tutorials mentioning that it's worth to check UART after flashing and now we could confuse people... and how actually that change affected UART?
>>21525698 I will try.
Current SDK is tailored to minilibc, and printf implementation is done in minilibc_port.c.
And to get it to compile i had to cut out most of the code there.
Still, i'll try to port changes from newer sdk, will se if it works.
Added after 2 [minutes]:
Got it to work, just straight copy-pasted from newer sdk.
Are you referring to the Easyflash usage for OBK config? As I said some time ago, I'm not sure about that. On one hand, Easyflash is optimizing flash erase cycles usage, so that could be a good thing... but on the other hand, we don't save config that often so it doesn't matter and I would strongly prefer to have config at fixed address, so flash tools can access it in the future. So for now, don't port OBK config to easy flash. Better focus on new features or platforms. BK7252 or whatever may be possible.
Still, flash vars (channel values save restore) could be actually stored in easyflash, if possible. They are saved often and they could benefit from flash wear optimization.
It depends on how complicated is it. Of course it could, but I would still avoid giving us/you extra work. We still have to fix that Tuya Config partition parse, which currently just reassembles text from binary data which causes Tuya config read failure in some edge cases, and this has higher priority:
https://github.com/openshwprojects/BK7231GUIFlashTool/blob/main/BK7231Flasher/TuyaConfig.cs
Code: C / C++
Log in, to see the code
This is hacky as hell and could be improved with some Tuya code analysis:
I also thought about making a V6 config - where its size is 'dynamic' - like storing multiple ssids (more than 2), dynamically sized initCommandLine, etc.
With easyflash that could be done easily.
That sounds good, as long as it's really reliable and includes flasher update. Of course, flasher would need to support both formats, for the time being... I could help with C# code, if you already have a generic idea how to handle it. Testing in C# is a bit easier for me because I am still very limited when it comes to space, especially after having basements and stuff flooded. I've recently posted a post-flood Smart Switch teardown: https://www.elektroda.pl/rtvforum/topic4116996.html
Would you also take that chance and normalize configs between platforms? So you'd basically do a key-value system? Wouldn't it be prone to memory fragmentation over time, especially if the size of values has high variety?
Added after 3 [minutes]:
I didn't check the EasyFlash code yet, but maybe also GPT could help with C# translation. Not that I need it... but it's sometimes faster than doing by hand and not that bad if used with caution.
>>21525743 It's all concept only for now.
But i did thought about moving all configs to either easyflash, or flashdb.
I chose easyflash only because bl602 and tr6260 already used it by the time i came with that idea.
And there is probably no need to translate everything to c#, dllimports would probably be enough.
Fragmentation might be a problem, if env size is small enough. As it is now, i blindly believe in algorithms already implemented in ef code.
You have mostly convinced me, so I could agree to such change, but we may indeed need to check for fragmentation first.
How hard would it be to run EasyFlash on PC, I guess it has simple ef_port.c or whatever fill that we need to fill in?
We could create some kind of our own early test for EasyFlash and check how it behaves over time. Just a simple C program, no OBK yet, just C + EF.
Then, if we decide to port, we could do more OBK-related test of EasyFlash with OBK simulator. Simulate tens or hundreds of changes and see what happens.
This is exactly why I've added Windows (and later Linux) support to OBK, ability to do such tests really helps with development.
New sdk build: https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/14580099010 Increased stack size to 100k, free heap is about 88k. This leaves about 40-50k for libc heap. Freertos version is now V10.4.1 instead of V7.0.2 (came with new sdk), and using heap_5.
LFS is now available, 0x1B000 length, replaces tuya config section. Easyflash is used for flashvars with possibility of using it for config.
Powersave implemented (currently if it is done in autoexec/init, it won't work, will upload fix later).
Berry enabled by default.
Now for the sad parts.
Worse signal reception, at least for me. I can connect to wifi with release version, but can't with this one. Rssi reports as -70. But it connects to a second, closer ap just fine.
Ota is much slower, and if not done after reboot, there is a high possibility that it will fail (will quickly eat all available heap, which will force a reboot).
>>21526809 Checked that sdk, and it is too different.
Main thing is the structure, everything is organized neatly in esp style.
Uses cmake instead of makefiles.
Decided to test ota some more, and if using new_tcp_server, ota can succeed, even if somehow logs about it's progress aren't printed. But it takes even longer.
@divadiow I see -79dbm on new sdk, did you check current release? Is there anything different in signal strength?
Tuya partition dump attached, but it can't be decoded. Taken from full dump made in web app.
@p.kaczmarek2 Do i open a pull request for SDK? Even with the aforementioned problems?
Attachments:
w800_tuya_partition.bin(108 KB)
You must be logged in to download this attachment.
Hmm, i have HLK-W800 and it's worse for me.
Where old sdk can connect to wifi just fine and no packet loss, new sdk can take several minutes to connect and then many http requests fail.
Connection and OTA is important.... well, @insmod , would it be possible, to port for now LFS to OBK without the low quality WiFi SDK? At least until it's resolved...
Checked tuya W800, sdk is rather outdated, v1.00.01
Updated OBK: https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/14693345412 Extra w800 features are the same as with newer sdk, easyflash for fv, berry, newlib gcc, heap_5, 100k stack size.
But i also disabled a lot of unneeded features, like hostif/rmms (AT? disabling that one freed a lot of memory), web server (sdk one), iperf server.
Binary sizes: +103kb fls, +70kb ota. Still a lot of free flash remains.
@divadiow check how gcc is done it tr6260/ecr6600, and do it the same way in xr sdks. No need to download them from external servers, keep them on github for reliability/faster actions builds. Or perhaps check how i did it in w800 branch, just pulled T sdk and used gcc in that one. Or even use system gcc, like with realteks, ln882 etc.
regarding toolchains, I was curious about why, for example, a 2015 gcc would be kept in place and not updated (by anyone, OpenBeken world, or generally) to the point where breaking changes were introduced and then it became too much work to fix in SDK. Like, if it means the potential for smaller builds, is it a reasonable practice to try to see how far one can update? Is that a good thing to do? If the build succeeds, why would one not do it?
>>21534169 That was my motivation for realteks and beken_freertos_sdk. And it is easy to update gcc when platform arch is arm.
But what to do with andes (tr/ecr) and c-sky (w800)? I did try to find a newer gcc for andes, but failed. For c-sky, there is a build package on github, but i didn't try it. https://github.com/c-sky/toolchain-build
For T/N, updating gcc will make obk crash when reading flash vars, because time_t changed from 32bit to 64bit.
Then there is always a question what libc is used, like with w800 currently minilibc is used, while in my branch gcc is using newlib. And i had to completely replace libc port to make it work.
I once tried to update gh actions from ubuntu-22.04 to ubuntu-latest. Many builds, where gcc is the system one failed, because its changes were incompatible (i think it was gcc 14?).
oh sure. interesting, OK. I should have guessed that a successful build doesn't necessarily mean a 100% working app. I haven't tested those XR809 and XR872 toolchain change builds...
✨ The discussion compares the OpenBeken W800 and W806 boards, focusing on hardware differences, firmware compatibility, and OTA update methods. The W806 board, specifically the Hi-Link HLK-W806-Kit-V1.0, differs from the W800/W801 by lacking Wi-Fi and Bluetooth functionality and having only 1MB flash memory, which complicates flashing OpenBeken firmware designed for W800. Attempts to flash W800 firmware on W806 fail due to flash size and missing factory calibration data for Wi-Fi, making Wi-Fi enablement on W806 impractical. A minimal LED blink demo for W806 was successfully flashed, but full OpenBeken builds exceed the flash size. Efforts to reduce firmware size by disabling features like Tasmota API showed limited success. The W800 supports HTTP server-based OTA updates, but the Web App OTA is missing. Newer SDK versions for W800 introduce features like EasyFlash for flash variable storage, Berry shell, and LFS support, but also cause Wi-Fi signal degradation and slower OTA performance. Toolchain updates and SDK porting challenges were discussed, including GCC versions and libc implementations. Backup methods for W800 firmware are limited, with no known XT804 backup method. The W806 is considered more suitable for non-Wi-Fi applications or UART logging due to hardware limitations. The community is exploring SDK updates, flash size optimization, and configuration storage improvements, including potential EasyFlash integration and dynamic config sizing. Overall, W800 remains the preferred platform for Wi-Fi-enabled OpenBeken applications, while W806 is limited by hardware constraints. Generated by the language model.
TL;DR: For OpenBeken users testing W80x boards, the practical split is simple: W806 has 1 MB flash and "it’s been put to bed" for Wi‑Fi use, while W800/W801 are the boards that actually support usable OpenBeken flashing and OTA today. This FAQ explains chip differences, flashing methods, size limits, and why W806 experiments stalled. [#21386566]
Why it matters: If you are choosing a cheap WinnerMicro dev board for OpenBeken, this thread shows which boards work, which ones waste time, and which update path is realistic.
Board/chip
Flash noted in thread
OpenBeken status
OTA/update status
W800 / HLK-W800-KIT
2 MB class board; builds around 950–976 KB discussed
Works and was flashed successfully
HTTP server OTA works; Web App OTA missing
W801 / HLK-W801-KIT
Treated like W800 for OBK target
Works, but some boards showed weak Wi‑Fi
OTA possible, but weak links hurt reliability
W806 / HLK-W806-KIT
1 MB flash
OBK Wi‑Fi goal not practical
Large OBK images fail during flashing
Key insight: The blocker on W806 was not just image size. The thread concludes that even if the silicon contains RF blocks, missing factory calibration and RO-memory limits make Wi‑Fi OpenBeken on W806 unrealistic, so W800/W801 remain the sensible targets. [#21386566]
Quick Facts
W806 was reported with 1 MB flash, while W800/W801 were treated as the 2 MB variants that OpenBeken targets normally. [#21081609]
A tiny W806 Arduino LED demo was about 90 KB, while W800 OpenBeken full-flash builds discussed were about 900–976 KB, explaining why one flashed and the other did not. [#21081715]
After later size work, one reduced W800 image reached 543.75 KB, yet W806 flashing still ended with a CAN failure during image download. [#21387419]
A new W800 SDK test build reported about 88,312 bytes free heap, versus roughly 29,280 bytes on another tested build, but the newer build also showed weaker Wi‑Fi or slower OTA on some boards. [#21526809]
One Wi‑Fi test used a Windows hotspot only ~60 cm away, yet some new-SDK W800/W801 builds still failed to associate or complete OTA reliably. [#21526809]
1. What are the main differences between WinnerMicro W800, W801, and W806 when trying to run OpenBeken?
W800 and W801 were treated as the practical OpenBeken targets, while W806 was the outlier because it came with only 1 MB flash and no usable Wi‑Fi path for OBK. The thread cites W806 as internally similar to W800/W801, but with smaller flash, and later concludes Wi‑Fi enablement is not realistic on W806. In practice, buy W800 or W801 for OpenBeken work, not W806. [#21386566]
2. Why does OpenBeken fit on W800 but run into flash size problems on W806 with its 1 MB flash?
OpenBeken fits on W800 because that target has enough flash headroom for images around 950–976 KB, while W806 only exposes 1 MB flash. The thread shows W806 accepted tiny test images, but OBK builds stayed near the flash ceiling even after feature cuts. That leaves almost no safe margin for full images, OTA layout, and runtime data. [#21081754]
3. How do you flash OpenBeken onto an HLK-W800-KIT or HLK-W801-KIT, and what OTA update methods are available?
You can flash W800/W801 either by serial tools or by OTA once OpenBeken is already running. 1. Do the first flash with the WinnerMicro upgrade/flashing tool over UART. 2. Boot OpenBeken and connect to its web interface or AP. 3. Use the built-in HTTP server OTA path for later updates. The thread also shows successful OTA on a W800 board and confirms normal release builds still log on TX0. [#21525681]
4. Why is Web App OTA missing on W800 while the older HTTP server based OTA still exists?
Web App OTA is missing on W800 because that platform still uses the older OTA implementation, not the newer Web App OTA flow. The thread states this directly: W800 has HTTP server based OTA in the old style, while Web App OTA was not present. So W800 users still get OTA, but through the legacy HTTP-server path instead of the newer browser workflow. [#21081517]
5. What does a NAK or CAN error during W80x flashing usually mean, and how do you troubleshoot it?
A NAK or CAN during W80x flashing means the transfer failed, not that flash size is proven to be the cause. The thread explicitly says the size explanation was only “a stab in the dark,” and later a reduced 543.75 KB image still failed with CAN. Troubleshoot in three steps: 1. Try another UART baud rate. 2. Verify image size and target board. 3. Test a known-good small binary to separate transport errors from firmware issues. [#21081639]
6. How much firmware size reduction is needed to make OpenBeken practical on W806, and which features save the most space?
The thread never reached a stable target size that made W806 practical, even after major cuts. Disabling Tasmota API barely changed W800 full-flash size, moving from 966,824 to 976,336 bytes in one comparison, so it was not the big win. Later work cut a W800 image to 543.75 KB, but W806 still did not become a usable Wi‑Fi OpenBeken platform. [#21081754]
7. Why did a tiny W806 Arduino blinky sketch flash successfully while a much larger OpenBeken build failed?
The blinky sketch flashed because it was tiny and likely avoided the heavy Wi‑Fi stack and other OpenBeken features. The thread contrasts a roughly 90 KB Arduino test with OBK builds near 900 KB, calling that difference “huge.” A minimal LED demo proves the flasher and basic execution path work, but it does not prove a full Wi‑Fi firmware will fit or run correctly. [#21081741]
8. What is EasyFlash in the OpenBeken W800 discussion, and how could it be used for flash variables or future config storage?
"EasyFlash" is a flash-storage library that manages key-value data in flash, reduces wear from repeated writes, and can support more flexible layouts than a fixed-address config block. In the thread, it was proposed first for frequently updated flash variables, with config storage considered later if flasher support also exists. The main caution was keeping OpenBeken config easy to access and migrate. [#21525723]
9. What is LFS on OpenBeken for W800, and why do logs sometimes show messages like "lfs is absent" or missing autoexec.bat?
"LFS" is a small flash file system that stores scripts and files such as autoexec.bat, letting OpenBeken load startup content from flash instead of hardcoding it. When logs say “lfs is absent” or autoexec.bat is missing, the file system is not initialized yet, not formatted, or simply has no script stored. That is why boot logs can show Berry import errors and failed startup script loads. [#21526809]
10. W800 vs W806 for OpenBeken experiments: which one is actually worth buying for Wi‑Fi firmware work and why?
W800 is worth buying; W806 is not. The thread ends up clear on this: W806 Wi‑Fi enablement was dropped because missing factory RF calibration data and RO-memory limits make it impractical, even if shared silicon blocks exist. One commenter summed it up bluntly: it is easier to buy an HLK-W801-KIT dev board than waste time trying to force W806 into Wi‑Fi use. [#21386566]
11. How do you back up original Tuya firmware from a W800 or W80x board before flashing, and what methods were discussed?
There was no settled, known backup method at the time for W800/W80x before flashing. The thread mentions three avenues: 1. trying to read over UART, 2. exploring CK-Link or cheap CK-Link-compatible debugging hardware, and 3. using a full dump from the web app where available. One participant explicitly said there was no known XT804 backup method they could find. [#21525673]
12. Why do some newer W800 SDK builds show better free heap but worse Wi‑Fi reception, slower OTA, or failed HTTP requests?
The newer SDK changed memory layout and enabled features that raised free heap, but it also changed network behavior enough to hurt radio or socket reliability on some boards. One build reported about 88 KB free heap and used FreeRTOS 10.4.1 plus heap_5, yet testers saw weaker RSSI, slower OTA, and failing HTTP requests. So higher free heap did not guarantee better real-world Wi‑Fi performance. [#21526615]
13. How does switching the W800 toolchain from minilibc to newlib affect UART logging, heap size, and build compatibility?
Switching from minilibc to newlib improved build flexibility and enabled larger feature sets, but it initially broke UART logging until libc-port code was replaced. The thread says most of minilibc_port.c had to be cut to compile, then later copied from a newer SDK to restore logging. On tested builds, free heap stayed around 29,280 bytes on one “berry” image, so the toolchain change did not automatically increase usable heap. [#21525702]
14. What is causing the strange log line "Error:HTTP:Created HTTP SV thread with (stack=2048)" on W800, and is it actually an error?
That line is a mislabeled informational message, not proof of an HTTP failure. The thread shows it appearing on successful boots where the HTTP server thread was created with a 2,048-byte stack, and the same wording had been noticed in earlier XR806 work. Treat it as noisy logging unless it is followed by actual web-server failures. [#21526809]
15. What was learned about trying to enable Wi‑Fi on W806, including RF calibration, RO memory limits, and whether the chip is realistically usable with OpenBeken?
The thread learned that W806 is not a realistic OpenBeken Wi‑Fi target. The strongest explanation was that even if the die still contains Wi‑Fi/Bluetooth hardware, there is no factory RF calibration data, that data cannot simply be written into RO memory, and antenna matching would still remain. That means a no-Wi‑Fi UART-only experiment might boot, but practical wireless OpenBeken on W806 was abandoned. [#21386566]
