logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Backup & Restore of Xradiotech/Allwinner XR806/XR809 Flash in Windows: Guide & Demonstration

divadiow 3576 27
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • Here I will demonstrate how the internal flash of the Xradiotech/Allwinner XR806 (and XR809 - see note at bottom) can be read to file in Windows. Although there is not yet an OpenXR806 cloud-free alternative firmware to use on devices that have the XR806 at heart, flash firmware backups are useful in development and research and for general backup purposes.

    One Tuya module seen in the wild based on XR806 is the WXU (T103C-HL). Also available as WXU-IPEX - datasheets attached.

    To date on Elektroda XR806 has been spotted in:
    Avatto TRV16-WIFI radiator valve
    Avatto SWT60 Smart Watering Timer
    Allwinner development board

    Also: QOTO QT-08W Solar Power Smart Water Valve

    XR806 uses 5mm x 5mm QFN40 package and 4mm x 4mm QFN32 packages for different feature lists.

    Pin layout diagram of the XR806 chip by Xradiotech Pin diagram for XR806 BM2I Diagram of XRADIO XR806 chip with pin labels.


    Table showing GPIO multiplexing for XR806Bxxx.



    To get into UART download mode PB02 needs to be pulled to ground at power-on.

    on the WXU PB02 is the 3rd pad up from the bottom on the right-hand side of the module as you look at the top

    Schematic of an integrated circuit with GPIO and UART connections.

    or from the bottom:
    Diagram of electronic circuit pins with labels.

    and again from the top with WXU shown mounted on PCB from TRV16, which I will also use to demonstrate flash backup
    Electronic module with pin labels.

    Soldering can be performed direct to WXU contacts or, in the case of this WXU on PCB from TRV16, I have chosen to solder to the breakout pads instead for all but PB02.

    Electronic module with markings and QR code Printed circuit board with labels and connectors.

    Electronic module with wires on a blue mat. Green PCB with attached colored wires against a keyboard background.

    USB-TTL RX -> XR806 TX
    USB-TTL TX -> XR806 RX
    3.3V -> XR806 VBAT
    USB-TTL GND -> PSU GND -> XR806 GND

    Flash writing and reading is performed in the PhoenixMC program, available from https://github.com/openshwprojects/FlashTools/tree/main/XRadioTech-AllWinner

    Main text areas are in Chinese, so here are some translations to aid navigation

    PhoenixMC software interface for firmware updates.
    Graphical user interface for a flash memory operation application. Screenshot of software settings window for firmware programming.

    Connect XR806 as above and power on. Set appropriate baud on the main page (this may need to be lower if your wires are too long or you're using pogo pins), open the Debug menu. It should communicate with the XR806 and unlock the text fields. Change the length box text to 200000 and click Read.

    Animated read image
    Flash operation application window with various options and settings.

    Flash backup will be saved to file called flash_A_0x0_L_0x200000.bin in the PhoenixMC root folder
    Properties window of the binary file flash_A_0x0_L_0x200000.bin in Windows.

    In this mode you can also read the flash ID. eg:
    Dialog window with a warning from the phoenixMC program, showing BROM version and flash ID.

    which looks to be Winbond W25Q16JV or W25Q16DV in my case.

    To restore a backup simply rename your backup file extension from .bin to .img (or change the filtering in the open dialog box to *.*) and flash back with the blue Update button. eg:

    Screenshot of PhoenixMC software showing binary file details.



    This process is identical for the XR809 except for the need to ground both PB02 and PB03. Original XR809-specific guide: https://www.elektroda.com/rtvforum/topic3806769.html



    Your backup may contain your wifi credentials so backup should be done prior to pairing device with cloud platforms or pair/unpair with test AP. Please share your backup files for analysis and archive in the collection https://github.com/openshwprojects/FlashDumps/tree/main/IoT

    Alternatively, PM me the file and I'll happily flash/pair to test AP/unpair and take new backup.

    Cool? Ranking DIY
    From Display to Complete System: How the Solution Team Creates Value at Unisystem [ad]
    About Author
    divadiow
    Level 37  
    Offline 
    divadiow wrote 4322 posts with rating 763, helped 375 times. Live in city Bristol. Been with us since 2023 year.
  • ADVERTISEMENT
  • Helpful post
    #2 21540487
    p.kaczmarek2
    Moderator Smart Home  
    With our recent research and development, it seems increasingly likely that it's also possible to flash XR chips without grounding extra pins, as long as the firmware is built with command line enabled (at least "reboot" and "upgrade" commands must be handled. We need to test it in OpenXR. What do you think?

    Related discussion: https://www.elektroda.com/rtvforum/topic4074636-150.html#21534886
    Helpful post? Buy me a coffee.
  • #3 21540572
    divadiow
    Level 37  
    we need more real XR806 backups to test. The TRV XR806 one we have does not appear to support it but it is trying to do TuyaMCU comms on the flashing UART, so maybe theyre getting in the way. If you use Tuya MCU Debug Assistant with fake pid so the app finishes booting, then close com port and try PhoenixMC again it still doesn't go into download mode. But yeh, need more backups.

    The AWOL dev board dump does work.
    Screenshot of a flash programming software window with settings, bin file name, and Open comm OK! message highlighted.

    Added after 9 [minutes]:

    divadiow wrote:
    but it is trying to do TuyaMCU comms on the flashing UART, so maybe theyre getting in the way

    or maybe it accepts command on other UART (RX1/TX1), where log out is, but then how do you switch to flashing the other uart when it's in download mode? two usb-ttls and you choose both in PhoenixMC at the same time and expect one to fail? hmm. I could try that I guess
  • #4 21745789
    jmkrzyszt
    Level 9  
    Hi,
    Thank you @divadiow for your instructions, I was able to dump factory firmware of my XR806 based Salcar TRV801W thermostatic radiator head. BTW, I've already open a pull request with that firmware image against your FlashDumps git repository.

    Then I flashed a recent version of OpenXR and it apparently didn't boot -- its AP didn't appear. I successfully re-flashed the device with the dumped factory firmware image and original functions were restored, so flashing works as expected, I believe.

    I tried to capture boot messages from UART0 but nothing appeared. Some messages appear only on UART2, which suggests the factory bootloader either doesn't display anything, or uses UART2. Here are the messages from UART2:
    Code: Text
    Log in, to see the code
    Note: Tuya MCU was not powered up, so no communication with it was reported.

    I suspect UART0 is used for communication with Tuya MCU, though I was not able to capture any traffic -- it looked like idle.

    After re-flashing the device with OpenXR806-1.18.207.img, I can observe the following error messages displayed on boot:
    Code: Text
    Log in, to see the code

    Does that tell anything meaningful about the reason of boot failure?

    Should I rather open a new topic for that story?
  • ADVERTISEMENT
  • #6 21745828
    jmkrzyszt
    Level 9  
    >>21745815
    Boot log from 1.18.128 looks almost the same as 1.18.207, there is only one difference, last number in one line before the last, which is now 0x2200d0.

    Added after 34 [minutes]:

    For those who may want to play with TRV801W:
    Probe tips touching PCB of TRV501W electronic thermostat
    Red probe is UART0 TX, black probe -- UART0 RX. A pad beside the black probe with a red wire soldered to it is PB02 (connect to GND for flashing).
    4 pads at the bootom edge belong to UART2 (there is a red wire connected to its Vdd pad). Behind the probes there are 5 pads (with a black wire hanging of pad 4 -- GND) described as if that was an UART.  I thought that might be UART0 but that occurred not the case, maybe those are connected somehow to Tuya MCU. The 5th, rightmost pad is described as RST and it apparently resets the Tuya MCU, not the XR806. For XR806 reset, a pad connected to its CHIP_PWD pin can be found at ca. half of the distance between the probes and the Vdd wire, there is a bank of resistors/capacitors there, one is missing, and that's the pad closer to the chip.
  • #7 21745901
    divadiow
    Level 37  
    Hmm. It's been a while since I flashed an XR806, I'll try when home later. I have an XR806 dev board and also, obviously, the WXU from probably the same TRV. I never did put the WXU back into the TRV to complete testing and create a template plus autoexec :(

    Added after 4 [hours] 51 [minutes]:

    flashed 1.18.207 to blank XR806. initial boot:

    Code: Text
    Log in, to see the code
  • #8 21746168
    jmkrzyszt
    Level 9  
    before proceeding>>21745901
    @divadiow could you please try with the factory firmware that I added to the FlashDumps repo? Maybe results from booting it on your module can shed more light on the issue with my device.

    Wait, there were some notes about some old firmware versions potentially burning devices, before you proceed please double check versions reported in the boot log dump I attached previously.
  • ADVERTISEMENT
  • #9 21746179
    divadiow
    Level 37  
    Yep, I added that note. I was just about to post that I killed a board with the other dump there. It must be coded for that DC mode that eats the Allwinner boards.

    I could maybe try on 3.3v WXU instead of 5v board. Maybe @insmod is able to say how these backups can be safely flashed for analysis

    Added after 2 [minutes]:

    https://www.elektroda.com/rtvforum/topic4109971.html

    What that post doesn't mention is that I had flashed the backup and that that was the cause of dead board. I just didn't think it relevant at the time (!)

    Added after 7 [minutes]:

    Xref
    https://www.elektroda.com/rtvforum/topic4074636-210.html#21587395
  • #10 21746224
    jmkrzyszt
    Level 9  
    jmkrzyszt wrote:
    Code: Text
    Log in, to see the code

    So for me it looks like my device's factory firmware, despite being built with SDK v1.2.1, is using DCDC, and that can be dangerous to other devices.
  • #11 21746241
    divadiow
    Level 37  
    interesting. This is the device I have from which WXU came from. It shows LDO used in this boot log of factory app post #7

    https://www.elektroda.com/rtvforum/topic4118139.html

    Added after 15 [minutes]:

    I have flashed OpenXR806_1.18.207.img to the WXU but I needed to bump voltage up to 4.3v for it to not brownout when starting AP
  • #12 21746332
    jmkrzyszt
    Level 9  
    divadiow wrote:
    This is the device I have from which WXU came from.

    There is no separate WiFi module in my device, everything except an external LED dispaly is located on one and the same PCB, can be seen on the picture I posted. So my device may be very different from yours, I think.
  • #13 21746350
    divadiow
    Level 37  
    jmkrzyszt wrote:
    So my device may be very different from yours, I think.

    yes indeed.

    do you know what your XR806 is fed with voltage-wise if powered normally as if unopened?
  • Helpful post
    #14 21746389
    jmkrzyszt
    Level 9  
    >>21746350
    I'm able to power up the device from batteries even when disassembled, however, I would be afraid of touching XR806 chip pins with a probe. Those are so tiny, so close one to another, so I can't be sure not to short-circuit adjacent pins. If the chip is so sensitive to even slightly excessive voltages and can be burned if exceeded then I'd rather avoid that and stick with Tuya Local integration.
    However, there are a few pads on the board that, if their description looks promising, I can try if connected directly to one of the interesting pins of the chip and if so then measure voltage. The chip has 9 pins named VDD_* and one VBAT, which of those are interesting to you?

    Added after 2 [hours] 2 [minutes]:

    With some used batteries inserted, ~4.1V appeared on pads marked VBAT and VBAT1, one on each side of the board, apparently connected together, and that's the highest voltage that can be measured on any pad. Other than that, there are a few pads with 3.3V, one marked 3V3, another marked M_3V3. located close to the XR806, and 3 more that belong to UART pad banks, one of the not identified UART, marked VDD_3V3, the other 2 of UART1 and UART2, both marked VDD. There is a pin marked 1V8, close to the XR806, with ~1.5V, and one close to a LED display connector, marked TPLED, with ~1,15V. Other than that, there is a voltage of ~2.6V at a couple of TPn pads, and 0V on other TPn pads.
    Interestingly, 3.3V is delivered only after the device is mounted on a thermostatic valve and calibrated, which steps are apparently served by the Tuya MCU itslef, with no help of the XR806. Before that is done, there is ~0,4V on those pins.
    Calibration needs to be repeated after reset from the NRST pad of the unidentified UART pad bank.
    Also, there is a 20F capacitor on the board that provides limited power when batteries are removed. ~0.5V can be detected in VBAT pads, ~0,2 on M_3V3 and UART1/UART2 VDD, 0.05V on V3V and VDD_V3V.
    I think no more than 3.3V is delivered to the XR806, unless also raw, unstable voltage directly from batteries.
  • ADVERTISEMENT
  • #15 21751713
    divadiow
    Level 37  
    You could build a DCDC version of OpenXR806 to see if that works. I don't know if that's a good idea or not.
  • #16 21752137
    jmkrzyszt
    Level 9  
    >>21751713
    I guess you mean you don't know if that's safe for the device, don't you?
  • #17 21752144
    divadiow
    Level 37  
    Pretty much yes. But if yours is DCDC now it sounds like it'd be ok. Depends on whether you want to take any risks I guess.

    Or wait until someone who knows more chimes in
  • #19 21779294
    divadiow
    Level 37  
    I think that's all I'd do, toggle LDO off/DCDC on, see what works.

    Added after 2 [minutes]:

    but I don't want to be leading you down a path if it means killing the chip. I just know what I'd fiddle with ... :)

    Added after 6 [minutes]:

    I took a mini gamble on your DCDC dump and the Avatto SWT60 on the WXU module @4.8v - neither boot, so, that's that experiment done

    Added after 6 [hours] 55 [minutes]:

    your PR does boot however

    Code: Text
    Log in, to see the code
  • #20 21779428
    jmkrzyszt
    Level 9  
    Assuming my attempt to configure a custom DCDC image was successful, I can see no difference when trying to boot it on my device, compared to the default OpenXR806 image. Boot log looks exactly the same as before. There must be something else that still doesn't work with my device.
  • #21 21779432
    divadiow
    Level 37  
    divadiow wrote:
    your PR does boot however

    but this booting for me and that is still says INT LDO: Enable kinda looks like the patch wasn't quite right and it's still LDO
  • Helpful post
    #22 21779435
    jmkrzyszt
    Level 9  
    Looking at a boot log from successful boot on another device, provided by @divadiow (thank you!) I can still see
    Code: Text
    Log in, to see the code
    and not
    Code: Text
    Log in, to see the code
    like when booting my factory image on that device.  Then, I have to find out what else needs to be modified.

    Added after 1 [minutes]:

    Yeah, my commets crossed with @divadiow
  • #23 21779436
    divadiow
    Level 37  
    :):)

    I need to work out a module-safe way to test out DCDC dumps and OBK builds. I'll see what I can achieve with datasheets and AI.
  • #24 21779845
    jmkrzyszt
    Level 9  
    I tried to enable debug messages on boot (see still the same pull request https://github.com/openshwprojects/OpenBK7231T_App/pull/1893 for details) in hope I get more information that can help me to understand why the boot fails. Unfortunately, my attempts occurred not effective -- still only error messages already seen before were logged on boot. Maybe those messages come from the bootloader which is not rebuilt by default. I requested rebuild of the bootloader but that didn't work -- an unresolved symbol and two non-existent fields of a structure were found during build. All those should be available if building with CONFIG_BOOTLOADER which I enabled in sdk/OpenXR806/.config file. Maybe that file is not used in OpenBK builds.
  • #25 21779851
    divadiow
    Level 37  
    im just messing with the SDK. if we run make menuconfig in the SDK root we can set the VDD_SENSE mode

    XR806 SDK configuration screen with Projects Selected (NEW) highlighted

    XR806 SDK configuration window with Use internal DCDC selected

    then the saved config looks like this in the .config file when we grep CONFIG_PWR .config

    Code: Text
    Log in, to see the code
  • #27 21779870
    divadiow
    Level 37  
    to change xtal. 32M selected

    Code: Text
    Log in, to see the code
  • #28 21779892
    jmkrzyszt
    Level 9  
    insmod wrote:
    What is you XTAL frequency?
    When factory image is booting, the following is shown:
    Code: Text
    Log in, to see the code


    Added after 8 [minutes]:

    As I wrote before, it looks like if my changes to sdk/OpenXR806/.config, applied via patching that file from pre_build.sh, were not used in next steps of the build process. What should I do to modify the OpenXR806 .config so my changes are actually used in OpenBK_App pull request build? IOW, is there a supported way of introducing such changes for the purpose of custom builds?

    Added after 36 [minutes]:

    OTOH, a build with build bootloader enabled failed, so apparently there was an attempt to build the bootloader, then the CONFIG_BOOTLOADER=y setting from the sdk/OpenXR806/.config file was taken into account. But then, it failed on missing symbols / structure fields enabled with that setting, so again it behave like if that setting was not set.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

The discussion focuses on methods to backup and restore the internal flash memory of Xradiotech/Allwinner XR806 and XR809 chips using Windows. These chips are found in various IoT devices such as the Tuya-based WXU (T103C-HL) module, Avatto TRV16-WIFI radiator valve, Avatto SWT60 Smart Watering Timer, Allwinner development boards, and the QOTO QT-08W Solar Power Smart Water Valve. The XR806 chip is available in 5mm x 5mm QFN40 and 4mm x 4mm QFN32 packages, supporting different feature sets. Recent research suggests that flashing XR chips may be possible without grounding additional pins if the firmware includes command line support for commands like "reboot" and "upgrade," which could simplify firmware upgrades and backups. This approach is under consideration for implementation in OpenXR firmware.
Summary generated by the language model.
Today's popular
ADVERTISEMENT