FAQ
TL;DR: After about 10 minutes on normal 5V USB-C, one XR806AF2L board released “magic smoke,” but a second board booted, dumped flash twice, and later ran OpenBeken once XR806-specific settings were fixed. This FAQ is for XR806/XR872 tinkerers who need a fast map of hardware risks, flashing, XIP, EasyFlash/LFS, UART, and OTA failure modes. [#21466664]
Why it matters: This thread turns scattered bench notes into a practical troubleshooting guide for bringing unstable XR806/XR872 boards from first boot to repeatable reflashing and OTA tests.
| Platform |
Boot status in thread |
Notable working feature |
Main blocker seen |
| XR806 |
Booted with OpenBeken after config fix |
UART, Berry start, HTTP OTA later worked |
Early bin too big, malloc mode, OTA edge cases |
| XR809 |
Partial support discussed |
Deep sleep noted on XR809 |
OTA less stable than XR806 |
| XR872 |
Booted and HTTP OTA verified |
Static IP and HTTP OTA worked |
Quick/REST OTA crashes in some tests |
Key insight: The turning point was not just image size. XR806 became usable when the build matched XR806-specific memory behavior, especially CONFIG_MALLOC_MODE=0, and later OTA stability improved when the workflow switched toward HTTP images and the XR mkimage path.
Quick Facts
- The XR806 baseboard boot log reported CPU 160000000 Hz, HF clock 40000000 Hz, heap 126976 bytes, and XR806 SDK v1.2.0 on the original board firmware. [#21466260]
- A photographed flash part was identified as Winbond W25Q16JV, labeled “16Mbit SPI/QUAD”, matching the linked Winbond part family used for code storage. [#21466260]
- The first clearly successful XR806 OpenBeken boot used XR806 SDK v1.2.2, firmware R0-XR_C07.08.52.67_ULP_R_02.132, and showed heap size 185260 bytes. [#21588899]
- XR872 logs showed a larger platform profile: CPU 240000000 Hz, HF clock 40000000 Hz, and 323992 bytes SRAM heap, which helps explain why XR872 OTA tests progressed farther than XR806 in several runs. [#21590200]
Why did one AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 board let out magic smoke after about 10 minutes on normal 5V USB-C power, and what parts should be checked first?
The exact cause was not proven, but the failed board ran for about 10 minutes and then the XR806 chip itself was reported as the burnt part. Check the USB-C area first, then trace 5V into the module supply path and inspect the LDO, USB-UART section, and any solder debris. The thread also raised a concrete fault path: a short between 5V and D+ or D-. That makes connector wiring and bridge soldering the fastest first inspection points.
[#21466570]
How can I identify whether an XR806 dev board failure was caused by the XR806 chip itself, the USB-to-UART converter, the LDO, or a USB-C wiring fault?
Start by isolating which section still works. 1. Check whether the USB-UART still enumerates and produces serial traffic. 2. Measure whether the LDO outputs the expected rail while USB-C is at 5V. 3. Inspect whether the XR806 package shows visible damage or heats immediately. In this case, the board owner stated plainly, “XR806 chip,” after the failure, which ruled out a simple USB-UART-only fault. If serial and regulation survive but the SoC does not boot, the XR806 is the prime suspect.
[#21466370]
What flash chip is fitted on the XR806AF2L baseboard, and how do I verify whether it uses a Winbond W25Q16JV or another SPI NOR part?
The photographed board was linked to a Winbond W25Q16JV-class device, described as a 16Mbit SPI/Quad flash. Verify it by reading the package top-mark, comparing it with the Winbond part page, and checking whether your dump size and flash tool settings match a 2 MB device. The boot log itself showed
mJedec 0x0, so visual chip ID and successful full-chip erase or dump are more reliable than that early console line on this board.
[#21466260]
How do I dump and reflash firmware on the XR806AF2L baseboard using the available AWOL_XR806AF2L_BaseboardV1.0_Dev_Board.bin image and UART tools?
Use UART flashing and a full erase before writing the image. 1. Dump the original flash first; the owner got two dumps before the first board failed. 2. Use the shared
AWOL_XR806AF2L_BaseboardV1.0_Dev_Board.bin from the linked dump repository. 3. Full-erase the chip, then flash the image and confirm boot over serial. Later testing also showed “2mb” full erase was the normal recovery path during XR806 experiments, so matching flash size matters.
[#21466260]
What is XIP on XR806 and XR872, and why did moving OpenBeken code to XIP matter during the boot and OTA tests?
“XIP” is execute-in-place firmware layout that runs code directly from flash, reducing SRAM pressure while changing image layout and boot behavior. It mattered because one developer explicitly moved OpenBeken code to XIP during XR806 bring-up, and later booted builds reported
XIP : enable in platform information. That change aligned with progress from “no output” and oversized-image failures toward real boot logs, working services, and later HTTP OTA success on XR806 and XR872.
[#21588030]
What is EasyFlash in the XR806/OpenBeken workflow, and how is it different from LFS when the logs say "lfs is absent" or sector headers need formatting?
EasyFlash is the persistent key-value/config storage layer used by the firmware, while LFS is the lightweight file system used for script files like
autoexec.bat. The logs show EasyFlash can initialize successfully even when LFS is missing. On XR806, boot logs reported “EasyFlash V4.1.0 is initialize success,” while also printing “lfs is absent” and sector-header formatting warnings. In short: EasyFlash stores config and survives early bring-up better; LFS is optional but needed for file-based scripts.
[#21588899]
Why did OpenBeken initially fail to boot on XR806 with errors like "bin too big" and later start working after CONFIG_MALLOC_MODE was set to 0?
XR806 needed a different memory mode than XR809 and XR872. Early XR806 tests failed with
bin too big errors such as
0x201000 + 0x339d0 > 230000, then later booted after the developer identified
CONFIG_MALLOC_MODE=0 as mandatory on XR806. He stated that directly: “On XR806 it must be set to 0.” That changed the platform from no usable boot to a working OpenBeken image, although he also warned it may limit free-heap reporting and fragmentation visibility.
[#21588905]
Which OpenBeken build first booted successfully on XR806, and what changed compared with the earlier failing test images?
The first clearly successful XR806 build in the thread was
OpenXR806__xradios_21ccaf291737.img. It booted on June 25, 2025, reported XR806 SDK v1.2.2, driver
XR_V02.06.10, and heap size
185260. Earlier images either produced
bin too big errors or no serial output at all. The effective changes were the XR806 memory fix, newer SDK path, and later build adjustments around partitions and XIP-related image layout.
[#21588899]
How do XR806, XR809, and XR872 compare for OpenBeken support, especially for UART, Berry, OTA, heap usage, and overall feature completeness?
XR806 reached working UART, Berry startup, TuyaMCU tests, and later HTTP OTA, but needed XR806-specific memory settings. XR809 was discussed as working with deep sleep and Berry enabled later, yet OTA remained weaker; one tester said XR809 crashed immediately where XR806 at least loaded OTA images. XR872 showed the strongest headroom, with 240 MHz CPU, about 324 KB SRAM heap, and eventually verified HTTP OTA plus static IP work. In this thread, XR872 looked most comfortable, XR806 most educational, and XR809 the most OTA-fragile.
[#21592051]
Why was HTTP OTA eventually working on XR806 and XR872 while REST or quick-GUI OTA kept failing with alignment errors, image check failures, or crashes?
HTTP OTA worked because later builds and tools matched the image format and flash layout better, while quick-GUI and REST paths often hit edge cases. XR806 showed erase-alignment errors, MD5-init failures, heap corruption, and image-check failures in earlier OTA attempts. XR872 also crashed in quick-GUI paths before later HTTP tests rebooted into the new image correctly. A major stabilizer was the switch to the XR806 mkimage tool for all XR platforms, which removed manual flash-offset mistakes.
[#21589465]
What steps should I follow to troubleshoot XR806 or XR872 OTA problems when the logs show flash erase alignment errors, MD5 init failures, or usage faults?
Follow a strict log-first process. 1. Confirm the image path and OTA method; retry with HTTP OTA before quick-GUI or REST. 2. Check the exact failure text, especially 4 KB alignment errors, MD5 init failures, and whether the image fully loaded before reboot. 3. Full-erase, reflash a known-good base image, then retest with an
_ota.img generated by the newer XR mkimage workflow. If the log shows
addr ... is not 4K alignment, stop and fix packaging first. That is a format problem, not a Wi-Fi problem.
[#21589126]
How can I use Tuya MDA and PB14/PB15 on XR806 to test the TuyaMCU driver and query dpIDs from a fake PID JSON document?
Connect Tuya MDA at 9600 baud to XR806 pins PB14 and PB15, then start the TuyaMCU driver inside the OpenBeken test build. The thread confirmed that exact setup worked: with Tuya MDA on PB14/PB15, the driver started and could query dpIDs from a fake PID JSON document inside TMDA. That makes it a practical bench test before wiring a real Tuya MCU product, because you can validate serial framing and datapoint parsing first.
[#21588923]
What do the _ALT OpenBK7231T/OpenBeken builds mean, and how does the new SDK differ from the old one for features like mbedtls, WPA3, logging, and BL0937 behavior?
_ALT means the image was built with the newer SDK. The developer summarized the tradeoff clearly: the new SDK brings integrated mbedtls and WPA3, but it increases binary size and showed “strange problems” such as logging issues and BL0937 quirks. So
_ALT is not just a naming variant; it flags a different platform base with newer security features and some compatibility risk. Use it when you need the newer stack, not as a drop-in stability upgrade.
[#21589627]
How good is precise delay support on XRadio chips for sensors like DHT and DS18B20, and what HAL function is being used for microsecond timing?
Precise delay support was not benchmarked in the thread, so the only solid answer is that microsecond timing exists but remains unverified for DHT or DS18B20 accuracy. The developer said he “found appropriate looking function and used it,” then moved that code into HAL. Elsewhere in the XR work, he named
HAL_Wakeup_SetTimer_mS for wake timing, but that is millisecond wake scheduling, not proof of sensor-grade microsecond precision. Treat XR delay support as experimental until a scope or sensor test confirms it.
[#21595062]
How can I make the XR806 access point IP and DHCP client range match the standard OpenBeken defaults, as in the OpenXR806 pull request?
Use the OpenXR806 change that aligned the XR806 AP IP and DHCP scope with normal OpenBeken defaults, then rebuild or flash that merged version. The thread ended with a dedicated pull request for exactly this behavior, followed by a “merged” confirmation on March 14, 2026. If you want XR806 to behave like standard OBK during first-boot AP mode, that merged patch is the reference implementation rather than an ad-hoc local edit.
[#21862317]
Generated by the language model.
