logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
3D printer for home or business?
3D printer for home or business? Here are the perfect 3D printers to start with »
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Tuya XR806 RT-WT501 flashed with OpenXR806 via phoenixMC, no AP or logs?

mkrum001 591 42
Best answers

How can I troubleshoot an XR806-based RT-WT501 that flashes OpenXR806 but does not start an AP or output any serial logs?

Your RT-WT501 likely needs the INT DCDC OpenXR806 build instead of the current INT LDO build, because some XR806 boards use an internal DCDC power setup that the existing image does not handle [#21886202][#21886226] A DCDC build was later provided as an untested variant, and a matching XR806DCDC branch was created after confirming both power modes boot on WXU [#21886509][#21886514] Also check both UARTs: the original firmware may print boot logs on LOG_TX, while OpenXR806 output is on UART0TX [#21886509] Before reflashing further, make a firmware and KV backup so you can restore the device if needed [#21885180]
Generated by the language model.
ADVERTISEMENT
Treść została przetłumaczona polish » english Zobacz oryginalną wersję tematu
Report a violation of the law
Reply | New topic
  • ADVERTISEMENT
  • #32 21887456
    insmod
    Level 31  
    >>21887439
    My build was default bootloader + DCDC app
  • ADVERTISEMENT
  • #34 21887676
    mkrum001
    Level 2  
    With this version, when power up the board log says:
    Code: Bash
    Log in, to see the code
  • #35 21887725
    divadiow
    Level 38  
    I don't quite understand what's going on with your log capturing.

    Presumably no AP still?

    Added after 1 [minutes]:

    Minicom set to 8N1, no flow control?
  • #36 21887786
    insmod
    Level 31  
    Next thing to try is to reduce flash frequency
  • ADVERTISEMENT
  • #37 21887826
    divadiow
    Level 38  
    I think you might be right. Analysis of the dump shows the BL is the same as SDK but the app flash speed is not 96Mhz.

    Bootloader: FLASHC, FAST read, 48 MHz
    App image 1: FLASHC, QUAD_O read, 64 MHz
    App image 2: FLASHC, QUAD_O read, 64 MHz

    I've also been watching 64Mhz scroll past in the log out while working on something else with this dump for the last few hours :D

    Code: Text
    Log in, to see the code

    and maybe this relates to the 
    AF2E
    variation marked on this chip. Different flash speed. hmm

    Added after 3 [minutes]:

    these XR806s are variant troublemakers!

    Added after 58 [minutes]:

    @mkrum001 please try the attached.

    Code: Text
    Log in, to see the code
    Attachments:
    • OpenBK7231T_App_2093_merge_8ea945a3e005_OpenXR806_DCDC.zip (1.09 MB) You must be logged in to download this attachment.
  • ADVERTISEMENT
  • #38 21887972
    mkrum001
    Level 2  
    With the latest one:
    Code: Bash
    Log in, to see the code

    minicom settings
    Tuya XR806 RT-WT501 flashed with OpenXR806 via phoenixMC, no AP or logs?

    Tuya XR806 RT-WT501 flashed with OpenXR806 via phoenixMC, no AP or logs?
  • #39 21888221
    divadiow
    Level 38  
    right OK.

    are you flashing on your first device still? does second device remain stock Tuya?

    If yes, does your first device boot up OK and output log as normal if the Tuya dump is flashed to it?

    Added after 8 [minutes]:

    it'd be interesting to get the BROM and flashID too but that Linux CLI program doesn't seem to have any commands to get that. Do you have access to a Windows machine to run PhoenixMC.exe on?

    Added after 31 [minutes]:

    please try this build
    Attachments:
    • OpenBK7231T_App_2093_merge_1097252ec965_OpenXR806_DCDC.zip (1.09 MB) You must be logged in to download this attachment.
  • #40 21888294
    mkrum001
    Level 2  
    I'm flashing the first device. Dump from the 2nd one is working fine on the first device - I have shared logs from it already.

    And with the last one we have progress!


    Tuya XR806 RT-WT501 flashed with OpenXR806 via phoenixMC, no AP or logs?
  • Helpful post
    #41 21888303
    divadiow
    Level 38  
    woohoo!

    yes. that was with the change from QUAD_O to DIO here https://github.com/openshwprojects/OpenXR806/commit/7fd929f31d22f9f0198c3fdd7673d745614e7621

    inspired by this post where the user has an AF2E type chip https://bbs.aw-ol.com/topic/6865/xr806%E5%9B%...%E5%8A%A8%E5%BC%82%E5%B8%B8/7?_=1776795080517

    BUT analysis of your original dump seems to suggest it was built as QUAD_O, like the builds that were failing for you.

    I've turned my attention to the role of the jedec ID matching and the flash-type config: https://github.com/openshwprojects/OpenXR806/...nclude/driver/chip/flashchip/flash_chip_cfg.h

    we see this AF2E variant thread has a full boot log available https://www.elektroda.com/rtvforum/topic4064188.html#21148718 where the jedec ID is 
    0x1540c8


    the SDK used to build OpenXR806 doesn't match for 
    0x1540c8
    so default settings are used. If you could still find a way to confirm your flash ID, that would be good. I could task GPT with making a Python script to do the job if not.

    Added after 27 [minutes]:

    in the dump from your device at offset 
    0x16E3C
    , the 32-byte FlashChipCfg-shaped block for 
    0x1540C8
    decodes to:

    mJedec = 0x1540C8
    mSize = 0x200000 = 2 MB
    mMaxFreq = 80 MHz
    mMaxReadFreq = 80 MHz
    mEraseSizeSupport = 0x19002
    mReadSupport = 0x007F
    mReadStatusSupport = 0x0003 = SR1 + SR2
    mWriteStatusSupport = 0x03 = SR1 + SR2
    mPageProgramSupport = 0x01
    mSuspendSupport = 0x01
    mSuspend_Latency = 30
    mResume_Latency = 200

    when compared to SDK default:
    FieldWatering 0x1540C8 profileCurrent SDK default fallback
    JEDEC0x1540C80x000000
    Size2 MB128 MB
    Max freq80 MHzunlimited / no cap
    Max read freq80 MHzunlimited / no cap
    Erase support0x19002same effective set
    Read support0x007Fsame effective set
    Read status regsSR1 + SR2 only (0x3)SR1 + SR2 + SR3 (0x7)
    Write status regsSR1 + SR2 only (0x3)SR1 + SR2 + SR3 (0x7)
    Page programnormal page programsame
    Suspend supportyesyes
    Suspend latency3030
    Resume latency200200
  • #42 21888333
    mkrum001
    Level 2  
    I will work on getting the information. Unfortunately in the next few days I will have limited time to do it, but I will.
  • #43 21888339
    divadiow
    Level 38  
    OK no worries. I think it's proven from dump now that support for that ID was present. I might have to buy one of these or similar with AF2E to test more thoroughly.
Reply | New topic
Report a violation of the law
Today's popular

FAQ

TL;DR: For XR806 users: a flash can reach 100% and still not boot. The key thread conclusion is: "your device will require the INT DCDC power type". If an RT-WT501 shows no AP and no serial output after flashing OpenXR806_1.18.287, first capture the factory boot log, back up flash, and test the correct power-type build instead of assuming the flash failed. [#21886202]

Why it matters: This thread shows that a successful phoenixMC write does not prove the firmware matches the board’s power architecture.

OpenXR806 / board case What the thread shows Practical result
INT LDO Described as the current OpenXR806 type May stay silent on some XR806 boards
INT DCDC Suggested for this RT-WT501 Best candidate for battery-powered RT-WT501
EXT PWR Mentioned as a broader class with many implementations Harder to support with one generic build

Key insight: The missing AP and missing UART logs point more strongly to a power-configuration mismatch inside the XR806 startup path than to a simple USB-to-TTL power shortage. The factory firmware boots, connects to Wi‑Fi, and reaches MQTT, so the board itself is alive.

Quick Facts

  • The OpenXR806 flash session completed with 13 blocks, a final 64 kB rest-data stage, OTA data handling, and Upgrade OK! at 100%. [#21885119]
  • The original firmware was dumped with phoenixMC -c /dev/ttyUSB0 -b 921600 -D read -A 0x00000000 -L 0x00200000, which reads 0x00200000 bytes from address 0x00000000. [#21885576]
  • The factory boot log reports XR806 SDK v1.2.1, CPU clock 160000000 Hz, HF clock 40000000 Hz, and INT DCDC : select. [#21885581]
  • The device is battery-powered: it uses 4xAA cells, board markings indicate 3.3 V, and the internal valve is 3 V. [#21885167]
  • In the factory log, the unit obtained IP 192.168.52.236, gateway 192.168.52.1, then connected toward Tuya MQTT at port 8883. [#21885633]

How can I troubleshoot an XR806-based Tuya RT-WT501 that flashes successfully with phoenixMC and OpenXR806 but shows no AP and no serial boot logs?

Start by assuming a board-variant mismatch, not a bad flash. 1. Back up the original flash and any remaining data first. 2. Capture the earliest factory boot log and identify the power type. 3. Test an OpenXR806 build that matches that power type, especially INT DCDC for this board. The write reached 100%, but the thread conclusion was that this RT-WT501 likely needs an INT DCDC build, not the current INT LDO build. [#21886202]

Why would OpenXR806_1.18.287 flash with "Upgrade OK!" on an XR806AF2E device and still fail to boot or print anything in minicom?

Because Upgrade OK! only confirms the image was written and verified, not that the runtime power configuration matches the board. In this case, phoenixMC erased, wrote, read, and verified 13 blocks plus OTA data, yet the device still produced no AP and no logs after flashing OpenXR806_1.18.287.img. That points to a startup mismatch after reset, not a transport error during flashing. [#21885119]

What is the difference between INT LDO, INT DCDC, and EXT PWR power types on XR806 devices?

They are XR806 power-init variants that determine how the chip and board supply internal rails at boot. INT LDO is the current OpenXR806 type, INT DCDC is a different internal regulator mode, and EXT PWR covers boards using external rails such as fixed 1.8 V, switchable 1.8 V or 2.5 V, external LDO, buck, or PMIC-controlled power. The thread notes that EXT PWR is broad and harder to support with one generic image. [#21885767]

How do I dump the original firmware from an XR806 board with phoenixMC before experimenting with OpenXR806?

Use phoenixMC in read mode and save a full flash-range backup before any new write. The working example in the thread was phoenixMC -c /dev/ttyUSB0 -b 921600 -D read -A 0x00000000 -L 0x00200000. That reads from address 0x00000000 for 0x00200000 bytes, giving you a recovery image to reflash later if OpenXR806 does not boot. [#21885576]

What does DCDC mean in the context of XR806 modules, and why can it affect whether OpenXR806 boots?

"DCDC" is a power-conversion mode that regulates board voltage using a switching converter, not a simple linear regulator, and its startup settings must match the hardware design. It matters because the thread identified XR806 boards whose factory log reveals INT DCDC : select, while the current OpenXR806 build is INT LDO. If firmware initializes the wrong power mode, the board can stay completely silent after reset. [#21885581]

Why is capturing the full factory boot log important before building or flashing OpenXR806 on a Tuya XR806 device?

Because the earliest boot lines reveal the board’s power setup and help choose the right build. The thread explicitly says the factory boot log gives away the DCDC or LDO type, and later notes that the shared user log missed the very beginning where the power information appears. Without those first lines, you can misclassify the board and flash the wrong image. [#21885767]

Which UART pads should I probe on an XR806 board when there is no output on the expected serial port after flashing?

Probe both the expected UART pads and the board’s RX and TX pads directly. The thread recommendation was to try RX and TX pads for log output when nothing appears on the first assumed serial port. That matters here because the reflashed RT-WT501 showed no logs on any tested port, so verifying the actual debug pins is part of the fault isolation. [#21885767]

How do I capture the earliest XR806 boot messages with minicom and a USB-to-TTL adapter under Ubuntu?

Open the terminal session before you power the target, then power-cycle the board and watch from reset. 1. Start minicom first. 2. Connect the USB-to-TTL adapter to the UART pads. 3. Plug in or repower the device so the adapter is already listening at first boot. The user followed that sequence under Ubuntu by starting minicom and then plugging in the USB-to-TTL device, but the thread still notes the very first power-info lines may have been missed. [#21886178]

What clues in an XR806 factory boot log reveal whether the board uses an INT DCDC or INT LDO power configuration?

Look for the platform-information section, where the firmware prints the selected power mode explicitly. In the shared factory log, that block lists XR806 SDK v1.2.1, then shows INT DCDC : select alongside other options such as XIP : enable and SIP flash : enable. That single line is the clearest indicator that this board boots with an internal DCDC configuration. [#21885581]

OpenXR806 INT LDO vs INT DCDC builds: which one should be used for a battery-powered Tuya RT-WT501 water valve?

Use an INT DCDC build for this RT-WT501. The thread’s working conclusion is direct: the device likely requires INT DCDC rather than the current INT LDO OpenXR806 build. That fits the factory log, which reports INT DCDC : select, and the hardware context, which is a 4xAA battery water valve rather than a typical 5 V XR806 dev board. [#21886202]

Why might a 4xAA Tuya water valve with an XR806 need a different OpenXR806 build than a typical 5 V dev board?

Because its power path differs from a common 5 V development board. The user states the valve runs from 4xAA batteries, the board has 3.3 V labels, and the valve itself is 3 V. Another participant also notes that a DCDC-capable Tuya image had already caused trouble on a 5 V XR806 dev board. Those details support using a build tailored to the battery-powered regulator setup. [#21885167]

What is a bootlog on XR806 hardware, and what information should I look for in it when diagnosing failed OpenXR806 boots?

"Bootlog" is the serial startup log that prints from reset, exposing early bootloader, platform, and network initialization details before the main application settles. On XR806, look for the first power-mode lines, SDK version, CPU and HF clocks, flash information, and whether Wi‑Fi starts. In this thread, the decisive clue was the platform block showing INT DCDC : select. [#21885581]

How can I back up KV or OTA-related data from an XR806 device so I have a recovery path if OpenXR806 does not work?

Make a full dump before further flashing, and also preserve any surviving KV or OTA areas from the first device. The thread advice was explicit: get a backup first so you have a way back, and even the partially modified device might still keep its KV intact. That gives you both a complete reflash image and a better chance of restoring device-specific data later. [#21885180]

What does it mean when the XR806 factory firmware log shows successful Wi-Fi and MQTT activity but OpenXR806 shows no output at all?

It means the hardware and original firmware are functional, while the replacement image is failing much earlier in startup. The factory log shows association, DHCP, IP 192.168.52.236, and MQTT progress to mqtt state change 5 -> 6, which is far beyond basic boot. When OpenXR806 shows no serial text at all on the same board, the strongest thread diagnosis is an incompatible power-type build. [#21885633]

Why isn’t the issue likely to be USB-to-TTL power alone, and how does XR806 firmware control of onboard DCDC circuitry affect startup?

Because the thread points to firmware-controlled board power, not just adapter current. The direct answer given was that the XR806 is managing the onboard DCDC converters, and the current build does not do that in the right way for this board. So even if the USB-to-TTL adapter is present, the wrong startup power configuration can prevent any boot log or AP from appearing. [#21886226]
Generated by the language model.
ADVERTISEMENT