FAQ
TL;DR: Read 0x200000 bytes from an XR806 in PhoenixMC after grounding PB02 at power-on; as one tester put it, "flashing works as expected" once wiring and mode entry are correct. This FAQ helps Windows users back up, restore, and troubleshoot XR806/XR809 flash, boot, and power-mode issues on Tuya-based boards. [#21507996]
Why it matters: A verified flash backup can recover a device after failed OpenXR806 tests and helps research board-specific boot, power, and bootloader differences.
| Item |
XR806 |
XR809 |
| UART download entry pins |
Ground PB02 at power-on |
Ground PB02 + PB03 at power-on |
| Typical read length shown |
0x200000 |
Same process stated |
| Restore method |
Rename .bin to .img, then Update |
Same process stated |
| Main risk discussed |
Boot/power mismatch, flash ID or boot issues |
Same class of risk |
Key insight: The flash procedure itself is straightforward; the hard part is board-specific compatibility. Power mode, crystal setting, UART choice, and bootloader assumptions can decide whether OpenXR806 boots or fails with jedec: 0x0 and no xip section.
Quick Facts
- PhoenixMC readback uses a length of
200000 hex, producing flash_A_0x0_L_0x200000.bin in the program root folder. [#21507996]
- XR806 packages mentioned are 5 mm × 5 mm QFN40 and 4 mm × 4 mm QFN32, depending on feature set. [#21507996]
- One failed-stability case improved only after raising supply to 4.3 V, because the module browned out when starting its AP. [#21746241]
- A factory boot log from one TRV801W showed XR806 SDK v1.2.1, HF clock 40,000,000 Hz, and CPU clock 160,000,000 Hz. [#21745789]
- On a disassembled TRV801W, measured voltages included about 4.1 V on VBAT, 3.3 V on several rails, and about 1.5 V on a pad marked 1V8. [#21746389]
How do I back up the internal flash of an Xradiotech/Allwinner XR806 in Windows using PhoenixMC?
Use PhoenixMC in UART download mode and read out
0x200000 bytes. 1. Wire USB-TTL RX/TX, 3.3 V, and GND, then pull PB02 to GND during power-on. 2. In PhoenixMC, choose a working baud rate and open the Debug menu until the text fields unlock. 3. Set the length box to
200000 and click
Read. PhoenixMC saves the dump as
flash_A_0x0_L_0x200000.bin in its root folder.
[#21507996]
What steps are needed to restore an XR806 flash backup in PhoenixMC after reading it out as a .bin file?
Rename the backup from
.bin to
.img and flash it with PhoenixMC's blue
Update button. If you do not rename it, you can instead change the file filter in the open dialog to
*.*. One user restored original device behavior by re-flashing the factory dump after OpenXR failed to boot, which confirms the write path works when the image matches the board.
[#21507996]
XR806 vs XR809 flashing procedure — what extra pins need to be grounded to enter UART download mode on each chip?
XR806 needs PB02 grounded at power-on, while XR809 needs both PB02 and PB03 grounded. The thread states the rest of the PhoenixMC read and write process is identical between the two chips. That makes pin strapping the main procedural difference when entering the boot ROM download path.
[#21507996]
What is UART download mode on the XR806, and how does pulling PB02 to ground at power-on enable it?
UART download mode is the XR806 boot mode that accepts flash read and write commands over a serial link. Pulling PB02 low during power-on forces that mode, which lets PhoenixMC communicate with the chip, unlock its fields, read flash ID, and dump or restore the internal flash. In the thread, this mode was the required entry point for Windows backup and recovery.
[#21507996]
Where is PB02 located on the Tuya WXU module, and what wiring is needed to connect an XR806 to a USB-TTL adapter for flashing?
On the WXU, PB02 is the third pad up from the bottom on the right side when viewing the module from the top. Wire USB-TTL RX to XR806 TX, USB-TTL TX to XR806 RX, 3.3 V to VBAT, and common ground from USB-TTL and PSU to XR806 GND. The author soldered to breakout pads for most signals and directly to PB02 for mode entry.
[#21507996]
Why does OpenXR806 sometimes boot with errors like "jedec: 0x0", "fdcm_open() failed", and "no xip section" on XR806 devices?
These errors point to a boot-time mismatch in flash access or low-level board configuration. One failing device logged
jedec: 0x0, then
fdcm_open() failed,
read img cfg failed, and
no xip section, while a blank XR806 board booted OpenXR806 1.18.207 normally. The thread linked such failures to board-specific variables like power mode, crystal selection, and bootloader assumptions rather than to PhoenixMC flashing itself.
[#21745789]
How can I troubleshoot an XR806 device like the Salcar TRV801W when OpenXR806 flashes successfully but its AP never appears?
First confirm the factory dump restores the device, then compare UART logs, power mode, and crystal assumptions. In the TRV801W case, the factory image restored normal behavior, but OpenXR still showed no AP and only error logs. Check whether the board uses DCDC or LDO, whether the bootloader matches the board's HOSC setting, and whether logs appear on UART2 instead of UART0. Keeping a verified backup is the safest baseline before each change.
[#21745789]
Which UART on XR806 hardware carries boot logs or Tuya MCU communication — UART0, UART1, or UART2?
UART assignment is board-specific, but this thread showed boot logs on UART2 and suspected Tuya MCU traffic on UART0 in one TRV801W. The tester saw no UART0 boot output, while UART2 printed full startup logs, including SDK and Wi-Fi details. They also suspected UART0 might serve Tuya MCU communication because the line appeared reserved yet mostly idle during observation.
[#21745789]
What is TuyaMCU Debug Assistant, and how was it used in attempts to trigger flashing on XR806 without grounding extra pins?
TuyaMCU Debug Assistant is a serial utility used here to fake Tuya MCU interaction so the app can finish booting before another flash attempt. The tester launched it with a fake PID, let the app boot, closed the COM port, and then retried PhoenixMC without grounding pins. That method still did not push the TRV XR806 into download mode, although an AWOL development-board dump did respond to the command-based approach.
[#21540572]
How should I choose the baud rate in PhoenixMC for XR806 flashing, especially when using long wires or pogo pins?
Start with a conservative baud rate and lower it if the link is unstable. The guide explicitly warns that long wires or pogo pins may require a lower baud, because PhoenixMC must first communicate successfully and unlock its text fields before reading. If the Debug page does not respond reliably, reduce speed before changing anything else.
[#21507996]
What do the boot log lines "INT DCDC" and "INT LDO / EXT PWR" mean on XR806, and how can they hint at power configuration issues?
They indicate which internal power path the firmware expects at boot.
"INT DCDC" is a power-setting status line that reports the chip is configured around its internal DC-DC regulator, while "INT LDO / EXT PWR" reports an LDO or external-power path. In the thread, a factory image showed
INT DCDC : enable, while OpenXR builds that booted elsewhere still showed
INT LDO / EXT PWR: enable. That mismatch became a key clue in failed boots and board-risk discussions.
[#21746224]
Why can flashing factory XR806 dumps from another device be risky, and how can DCDC-vs-LDO firmware differences potentially damage a board?
Cross-flashing is risky because a dump may embed board-specific power assumptions. One tester reported they had already killed a board after flashing another device's backup and linked the failure to a power mode that “eats the Allwinner boards.” Later discussion tied the risk to DCDC-versus-LDO differences seen in boot logs, so a foreign factory dump can do more than fail to boot; it can overstress incompatible hardware.
[#21746179]
What is XTAL or HOSC frequency on XR806 boards, and how can a 24/26/32/40 MHz bootloader mismatch affect booting?
XTAL or HOSC is the board's main crystal frequency, and the bootloader must match it.
"XTAL is the hardware crystal clock source that sets the XR806's high-frequency timing, and bootloaders are built for fixed values such as 24, 26, 32, or 40 MHz." The thread notes the default precompiled bootloader targets 40 MHz, while variants also exist for 24, 26, and 32 MHz. A mismatch can prevent normal boot even when flashing succeeds.
[#21779853]
How do I change OpenXR806 power settings to build a custom DCDC image, including the CONFIG_PWR_INTERNAL_DCDC and VDD_SENSE options?
Use the SDK configuration, not only a superficial patch, to switch the power path. One tester ran
make menuconfig in the SDK root, changed the VDD_SENSE mode, and saved a
.config showing
CONFIG_PWR_INTERNAL_DCDC=y, with internal LDO and external power disabled. That produced a build whose boot log still needed verification, because another test suggested the image might still expose LDO behavior at runtime.
[#21779851]
What is the supported way to modify sdk/OpenXR806/.config in an OpenBK7231T_App pull-request build so custom settings like DCDC mode or CONFIG_BOOTLOADER are actually applied?
The thread does not confirm a supported pull-request method that reliably applies those
.config changes. A tester patched
sdk/OpenXR806/.config from
pre_build.sh, but the resulting builds behaved as if key settings were ignored or only partly honored. Enabling
CONFIG_BOOTLOADER=y also triggered build errors for missing symbols and structure fields, which suggests the PR pipeline and full SDK config flow were not aligned in that experiment.
[#21779892]
Generated by the language model.
