logo elektroda
logo elektroda
X
logo elektroda

AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info

divadiow 2655 60
ADVERTISEMENT
  • #31 21588923
    divadiow
    Level 38  
    with Tuya MDA and open COM port at 9600 baud to XR806 PB14/PB15
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info

    TuyaMCU driver starts and can query dpIDs in fake PID json doc in TMDA
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
  • ADVERTISEMENT
  • #32 21588928
    insmod
    Level 31  
    So now WXU users can utilize their devices to full extent.
    And if OTA works, then XR806 can be said to be feature-complete with OBK, second alongside XR809 and after beken.
  • ADVERTISEMENT
  • #35 21588980
    divadiow
    Level 38  
    _xradios_ef9a1db9f086

    Code: Text
    Log in, to see the code
  • #37 21589052
    divadiow
    Level 38  
    ooh. seems successful loading and checking image but nothing further. doesn't initiate reboot
    Code: Text
    Log in, to see the code


    Added after 2 [minutes]:

    and no sign OTA is staged or whatever on manual reboot. not that I know what OTA should look like on XR boot
  • ADVERTISEMENT
  • #39 21589101
    divadiow
    Level 38  
    HTTP
    Code: Text
    Log in, to see the code


    quick OTA in GUI #1
    Code: Text
    Log in, to see the code


    quick OTA in GUI #2
    Code: Text
    Log in, to see the code
  • #41 21589126
    divadiow
    Level 38  
    HTTP
    Code: Text
    Log in, to see the code


    each hard reset is then just the below, requiring reflash to get past

    Code: Text
    Log in, to see the code


    Added after 7 [minutes]:

    quick OTA _xradios_b624f8e829b4

    Code: Text
    Log in, to see the code
  • Helpful post
    #43 21589159
    divadiow
    Level 38  
    ah. HTTP

    Code: Text
    Log in, to see the code


    Added after 5 [minutes]:

    HTTP again. OTA test to other version. downgrade to previous build. worked

    Code: Text
    Log in, to see the code


    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info

    Added after 3 [hours] 36 [minutes]:

    @MrGenius might be interested in these recent developments
  • Helpful post
    #44 21589465
    insmod
    Level 31  
    Small adjustments.
    Added XR872 OTA and moved obk code to xip.
    Enabled XR809 compression (~235kb flash saved, more is possible in exchange for heap (now ~200k free, was ~64k)). Disabled XR809 OTA (was unable to get http working, even in main (not obk) thread). LFS format works, but OTA flash erase doesn't.
    All XRs are now using XR806 mkimage tool (no need to specify flash offsets - meaning no error).
    https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/15884616221

    If XR872 OTA is verified to be working, i'll open a pull request.
    And can someone verify BK7231 battery driver? I commented out HAL_ADC_Init in Batt_Measure, since it should already be initialized in pins setup.
  • #45 21589617
    p.kaczmarek2
    Moderator Smart Home
    Interesting, I don't know why it's done repeatedly, since ADC is already set up in pins for IOR_BAT_ADC. Maybe you could ask here:
    https://www.elektroda.com/rtvforum/topic3959103.html
    Still, author doesn't seem to log in these days, so probably we can just test it ourselves.
    Probably just need a pot on ADC pin, I may try it in a moment

    Added after 2 [minutes]:

    Just started driver on my PR - shorted A0 to 3V on NodeMCU:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    Doing OTA...

    Added after 3 [minutes]:

    Seem to work the same, at least the ADC aspect:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    First is ADC of nodemcu connected to vdd, second is hanging in air.

    PS: What is the difference between _ALT (new SDK) builds for Beken and old builds?
    Helpful post? Buy me a coffee.
  • #46 21589627
    insmod
    Level 31  
    >>21589617
    _ALT are just built with new sdk,
    I did mention that it has some strange problems, like logging and bl0937. Could be others, undiscovered problems.
    Main thing for new sdk is integrated mbedtls and wpa3. At the cost of binary size of course.
  • #47 21589633
    p.kaczmarek2
    Moderator Smart Home
    It seems that redundant ADC init was present in the battery driver from the start:
    https://github.com/openshwprojects/OpenBK7231...mmit/82e7df25fb1e26932706f4b13eadab65c7b93fdf
    I don't think it was ever needed.

    Added after 1 [minutes]:

    Regarding XR809 OTA - probably the first thing to check would be is it even working in their AT demo (or OTA demo), without OBK at all
    Helpful post? Buy me a coffee.
  • #48 21589652
    divadiow
    Level 38  
    insmod wrote:
    If XR872 OTA is verified to be working, i'll open a pull request.


    _xradios_a4ebd90265b2 boots on 1mb XF16 still.

    2mb XF16 OTA from quick gui:
    Code: Text
    Log in, to see the code


    web app
    Code: Text
    Log in, to see the code


    Added after 11 [minutes]:

    WAIT.
  • #49 21589664
    insmod
    Level 31  
    >>21589652
    Is first one http?
    If so, then situation is the same as on xr809.
    Pls test xr806 rest ota again.

    Also interested what would happen if ota attempted on 1mb device.
  • #50 21589666
    divadiow
    Level 38  
    sorry. that WAS 1mb OTA. Wrong cam. doing 2mb now.

    Added after 6 [minutes]:

    quick gui=
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info


    2mb. _xradios_a4ebd90265b2

    quick/expert gui:
    Code: Text
    Log in, to see the code


    HTTP:
    Code: Text
    Log in, to see the code


    HTTP looks happy then doesn't progress
  • Helpful post
    #53 21592109
    p.kaczmarek2
    Moderator Smart Home
    New camera, original boot log:
    
    button state change: 1 --> 0
    button state change: 0 --> 1
    button state change: 1 --> 0
    button state change: 0 --> 1
    button state change: 1 --> 0
    button state change: 0 --> 1
    button state change: 1 --> 0
    button state change: 0 --> 1
    [bl ERR] main():629, build:20:38:52
    use default flash chip mJedec 0x0
    [FD I]: mode: 0x4, freq: 48000000Hz, drv: 0
    -------------->unknow flash ID 0x1440C8
    
    PasswoPMA: mode select:e
    
    wlan information ===================================================
    firmware:
        version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
        buffer  : 12
    driver:
        version : XR_V02.05
    ====================================================================
    
    PMA: wlan mode:a
    
    platform information ===============================================
    XRADIO Skylark SDK 1.2.0 Oct 17 2024 10:39:50
    
    sram heap space [0x21fc70, 0x25fc00), total size 262032 Bytes
    cpu  clock 240000000 Hz
    HF   clock  40000000 Hz
    
    sdk option:
        XIP           : enable
        INT LF OSC    : enable
    
    mac address:
        efuse         : 18:9e:2d:81:89:ce
        in use        : 38:0a:8d:47:2b:71
    ====================================================================
    
    StartupState:0
    <-500119_192428 rt_res.c:111>res error filenum:-34603499 001E0000
    gpio_grp=0,gpio_bit=21
    led drv init
    check vol
    [mthread]Create task:vbat(stack:2048),prio:3,ret:0 
    XXXX task:vbat
    [ERR] __mci_irq_handler,575 raw_int:100 err!
    [ERR] SDC err, cmd 8,  RTO
    [ERR] sdc 402 abnormal status: RespErr
    [ERR] int err 100
    [ERR] __mci_irq_handler,575 raw_int:100 err!
    [ERR] SDC err, cmd 55,  RTO
    [ERR] sdc 402 abnormal status: RespErr
    [ERR] int err 100
    [ERR] __mci_irq_handler,575 raw_int:100 err!
    [ERR] SDC err, cmd 55,  RTO
    [ERR] sdc 402 abnormal status: RespErr
    [ERR] int err 100
    [ERR] __mci_irq_handler,575 raw_int:100 err!
    [ERR] SDC err, cmd 55,  RTO
    [ERR] sdc 402 abnormal status: RespErr
    [ERR] int err 100
    [ERR] __mci_irq_handler,575 raw_int:100 err!
    [ERR] SDC err, cmd 55,  RTO
    [ERR] sdc 402 abnormal status: RespErr
    [ERR] int err 100
    [FS ERR] fs_ctrl_mount():102, mmc scan fail
    <-500119_192428 rt_sd_dev.c:264>SD File System initialzation failed! errno
    [mthread]Create task:sdcardth(stack:2048),prio:3,ret:0 
    XXXX task:sdcardth
    err cmd:use_fw_rate_policy
    vif=0, rts_threshold = 3000
    ssid is NULL. AP 
    <wifi>lpdtim:10, lplis:10
    [mthread]Create task:wifitask(stack:4096),prio:3,ret:0 
    XXXX task:wifitask
    [XRADIO_INTERNAL_CODEC] AMIC set volume Level-[7]
    [XRADIO_INTERNAL_CODEC] AMIC set volume Gain-[39]
    wifi task run
    rtuid:BATG-062640-SESLP1N,RDRKOI
    en1: CTRL-EVENT-TERMINATING 
    WAR join_status:0
    mean_vol=4200
    
    wlan information ===================================================
    firmware:
        version : R-XR_C10.08.52.64_01.80 Jul  6 2019 20:05:10-P01.46-R
        buffer  : 12
    driver:
        version : XR_V02.05
    ====================================================================
    
    interface name: en1
    Using interface en1 with hwaddr 38:0a:8d:47:2b:71 and ssid "AP-XRADIO"
    [XRADIO_INTERNAL_CODEC] AMIC set volume Gain-[39]
    [XRADIO_INTERNAL_CODEC] LINEIN set volume Level-[1]
    [XRADIO_INTERNAL_CODEC] AUDIO_IN_DEV_ALL set volume Gain-[0]
    [XRADIO_INTERNAL_CODEC] Route(cap): amic Enable
    en1: interface state UNINITIALIZED->ENABLED
    en1: AP-ENABLED 
    en1: AP-DISABLED 
    [net INF] msg <wlan connected>
    [net INF] netif is link up
    [net INF] bring up netif
    [net INF] netif (IPv4) is up
    [net INF] address: 192.168.238.1
    [net INF] gateway: 192.168.238.1
    [net INF] netmask: 255.255.255.0
    WLAN CONNECTED
    err cmd:use_fw_rate_policy
    vif=0, rts_threshold = 3000
    [net INF] msg <network up>
    NETWORK UP
    vif0, AP/GO mode THROTTLE=38
    <L>Cmutex:0
    <L>Cmutex:0x22a0e8
    <L>lwip_socket(PF_INET, UDP, 17) = SKT_0
    en1: interface state ENABLED->DISABLED
    [net INF] msg <wlan disconnected>
    [net INF] netif is link down
    WLAN DISCONNECTED
    <L>Cmutex:0
    <L>Cmutex:0x226f78
    <L>lwip_socket(PF_INET, UDP, 17) = SKT_1
    Using interface en1 with hwaddr 38:0a:8d:47:2b:71 and ssid "BATG062640MXKCF"
    <010701_000000 rtb_av_api.c:872>detect sensor error
    OV9660 get chip id wrong 0xff
    OV9660  Init error!!
    [CAMERA ERR] HAL_CAMERA_Init():373, sensor config fail
    <010701_000001 rtb_av_api.c:1284>HAL_CAMERA_Init error, -1
    <010701_000001 rtb_av_api.c:2024>media not init
    [mthread]Create task:thdImage(stack:2048),prio:3,ret:0 
    XXXX task:thdImage
    [mthread]Create task:RT_REC(stack:2048),prio:3,ret:0 
    XXXX task:RT_REC
    [mthread]Create task:MD_TH(stack:2048),prio:3,ret:0 
    XXXX task:MD_TH
    [mthread]Create task:p2plis(stack:10240),prio:3,ret:0 
    XXXX task:p2plis
    [mthread]Create task:CameraTest(stack:2048),prio:3,ret:0 
    XXXX task:CameraTest
    [mthread]Create task:NetCheck(stack:2048),prio:3,ret:0 
    XXXX task:NetCheck
    set br:-1--1
    en1: interface state DISABLED->ENABLED
    en1: AP-ENABLED 
    [net INF] msg <wlan connected>
    [UMAC WARN] net80211_linkoutput():202, ifnet 0x216a84 not valid for tx!
    [net INF] netif is link up
    [net INF] netif is already up
    WLAN CONNECTED
    err cmd:use_fw_rate_policy
    vif=0, rts_threshold = 3000
    /camera_test.txt does not exist!
    [mthread]vvvthread CameraTest, tid:2184488 EXIT
    lednum:0
    --drvled_flash :(0,1,5,5,1,5,5)
    [mthread]vvvthread NetCheck, tid:2183528 EXIT
    set ircut color
    vif0, AP/GO mode THROTTLE=38
    {0xC8,0x06},
    [mthread]vvvthread thdImage, tid:2184348 EXIT
    <RTW>WiFi ap start ok:BATG062640MXKCF, 0, 11
    wifi task exit
    [mthread]vvvthread wifitask, tid:2184992 EXIT
    
    

    Flash via UART:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    New boot log:
    
    platform information ===============================================
    XRADIO Skylark SDK 1.2.2 Jun 28 2025 11:33:12
    
    sram heap space [0x21ea68, 0x26dc00), total size 323992 Bytes
    cpu  clock 240000000 Hz
    HF   clock  40000000 Hz
    
    sdk option:
        XIP           : enable
        INT LF OSC    : enable
    
    mac address:
        efuse         : 18:9e:2d:81:89:ce
        in use        : 18:9e:2d:81:89:ce
    ====================================================================
    
    user_main
    OpenXR872, version _xradios_44cc3f6b4d65
    Entering initLog()...
    Commands registered!
    initLog() done!
    Warning: Sector header check failed. Format this sector (0x000ef000).
    Info:MAIN:Main_Init_Before_Delay
    Warning: Sector header check failed. Format this sector (0x000f0000).
    Warning: Sector header check failed. Format this sector (0x000f1000).
    Warning: Sector header check failed. Format this sector (0x000f2000).
    Warning: Sector header check failed. Format this sector (0x000f3000).
    Warning: Sector header check failed. Format this sector (0x000f4000).
    Warning: Sector header check failed. Format this sector (0x000f5000).
    Warning: Sector header check failed. Format this sector (0x000f6000).
    Warning: All sector header check failed. Set it to default.
    EasyFlash V4.1.0 is initialize success.
    You can get the latest version on https://github.com/armink/EasyFlash .
    Warn:CFG:CFG_InitAndLoad: Config crc or ident mismatch. Default config will be loaded.
    Info:CFG:CFG_SetDefaultLEDCorrectionTable: setting defaults
    
    Main_Init_Before_Delay done
    
    Main_Init_Delay
    
    Main_Init_Delay done
    Error:CMD:lfs is absent
    Info:GEN:PIN_SetupPins pins have been set up.
    Info:MAIN:Main_Init_Before_Delay done
    Info:MAIN:Main_Init_Delay
    Info:MAIN:Main_Init_Delay done
    Info:MAIN:Main_Init_After_Delay
    Info:MAIN:Using SSID []
    Info:MAIN:Using Pass []
    Info:MQTT:MQTT_RegisterCallback called for bT oxr2D8189CE/ subT oxr2D8189CE/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT xr872s/ subT xr872s/+/set
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/oxr2D8189CE/ subT cmnd/oxr2D8189CE/+
    Info:MQTT:MQTT_RegisterCallback called for bT cmnd/xr872s/ subT cmnd/xr872s/+
    Info:MQTT:MQTT_RegisterCallback called for bT oxr2D8189CE/ subT oxr2D8189CE/+/get
    Info:CMD:CMD_StartScript: started @startup at the beginning
    Error:CMD:LFS_ReadFile: lfs is absent
    Info:CMD:CMD_StartScript: failed to get file autoexec.bat
    Info:MAIN:Main_Init_After_Delay done
    Info:HTTP:TCP server listening
    Info:MAIN:Time 1, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 2, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 3, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 4, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    en1: CTRL-EVENT-TERMINATING 
    WAR join_status:0
    Info:MAIN:Time 5, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    interface name: en1
    Using interface en1 with hwaddr 18:9e:2d:81:89:ce and ssid "AP-XRADIO"
    en1: interface state UNINITIALIZED->ENABLED
    en1: AP-ENABLED 
    en1: AP-DISABLED 
    [net INF] msg <wlan connected>
    [net INF] netif is link up
    [net INF] bring up netif
    [net INF] netif (IPv4) is up
    [net INF] address: 192.168.4.1
    [net INF] gateway: 192.168.4.1
    [net INF] netmask: 255.255.255.0
    [net INF] msg <network up>
    vif0, AP/GO mode THROTTLE=38
    en1: interface state ENABLED->DISABLED
    [net INF] msg <wlan disconnected>
    [net INF] netif is link down
    Using interface en1 with hwaddr 18:9e:2d:81:89:ce and ssid "OpenXR872_2D8189CE"
    en1: interface state DISABLED->ENABLED
    en1: AP-ENABLED 
    [net INF] msg <wlan connected>
    [net INF] netif is link up
    [net INF] netif is already up
    vif0, AP/GO mode THROTTLE=38
    Info:MAIN:Time 6, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Boot complete time reached (5 seconds)
    Info:MAIN:Time 7, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 8, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 9, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 10, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 11, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 12, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 13, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 14, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 15, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 16, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 17, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 18, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    Info:MAIN:Time 19, idle 0/s, free 257312, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 4/20 
    

    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    Paired with WiFi:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    Set IP:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    page is at new IP, seems to work I guess:
    
    Info:HTTP:TCP server listening
    Info:MAIN:Time 1, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 2, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 3, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Time 4, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    [net INF] no need to switch wlan mode 0
    Info:MAIN:Time 5, idle 0/s, free 262272, MQTT 0(0), bWifi 0, secondsWithNoPing -1, socks 2/20 
    Info:MAIN:Registered for wifi changes
    Info:MAIN:Connecting to SSID [MyWiFiSSID]
    [net INF] netif (IPv4) is up
    [net INF] address: 192.168.0.127
    [net INF] gateway: 192.168.0.1
    [net INF] netmask: 255.255.255.0
    [net INF] msg <network up>
    wlan_msg_recv msg type:18
    


    Added after 3 [minutes]:

    LFS seems ok:
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info

    Added after 1 [minutes]:

    Potential reflash via UART seems OK i guess?
    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info
    Or wait, let me power this off and on.... OK, still working.
    Helpful post? Buy me a coffee.
  • #54 21592365
    divadiow
    Level 38  
    p.kaczmarek2 wrote:
    OK, still working


    yes indeed. makes things a lot easier on XF16. Although PB03 grounded is all that's required if it breaks

    AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 - Dev Board Info

    can't remember where I got to with XR806/XR809 attempts to enable PRJCONF_CONSOLE_EN

    ref: https://www.elektroda.com/rtvforum/topic4074636-150.html#21536584, https://github.com/divadiow/OpenXR872/commit/6386115b73e26fd40b3568b86ac8d07d2e0c5f6b

    XR809 didn't seem to be as straight-forward
  • Helpful post
    #55 21592379
    insmod
    Level 31  
    Opened a pull request.
    Additionally implemented BL0937 interrupts, even if there are no devices yet.
    Enabled a bunch of drivers, berry on XR809.
    >>21592365
    If console is enabled on XR806, then
    serial_stop();
    serial_deinit(UART0_ID);

    Will need to be replaced with console_stop() in uart hal.

    Offtopic question:
    I recently noticed that LN882H config is stored directly in flash at specific offset. Why not store it in KV, like flash vars?
  • #56 21592658
    divadiow
    Level 38  
    insmod wrote:
    I recently noticed that LN882H config is stored directly in flash at specific offset. Why not store it in KV, like flash vars?

    I don't know the answer to this of course, but what would a change mean for existing devices OTAing if this was done? Also, what are the advantages?

    Added after 28 [minutes]:

    insmod wrote:
    Opened a pull request.

    Thanks for your continued work on XR. I'm away for a week but did bring a box of modules and boards to maybe test things
  • #57 21595032
    p.kaczmarek2
    Moderator Smart Home
    How's the precise delay on Xradio? For DHT/DS18B20 etc?

    insmod wrote:

    I recently noticed that LN882H config is stored directly in flash at specific offset. Why not store it in KV, like flash vars?

    It the same as on Beken, it was planned to as direct config read/write to the flashing tool at same point. We've also spoke about it at some point, and maybe we could use EasyFlash and integrate it into the flasher.

    We have some issue related to that, tasmota group name is in the middle of our config but user requested support of longer group names, which is problematic with monolitic config format...

    Still, I am not fully convinced, because any config change (migration to EF) at the moment would break config backwards compatibility
    Helpful post? Buy me a coffee.
  • #58 21595062
    insmod
    Level 31  
    >>21595032
    Don't know about delay, just found appropriate looking function and used it (initially it was a function, then i just moved its code to HAL).

    Why would migration to EF break compatibility?
    Just read config via EF, and if read size != sizeof cfg, then read from offset.
  • #59 21595065
    p.kaczmarek2
    Moderator Smart Home
    I'm all for EF except the, as I said, backwards compatibility, i.e. I am worried about some people who try to downgrade OBK to gain stability or possibily lost features. We already have some kind of mysterious instance of that somewhere here in the forum, where some people say that newer LN882H is less stable or something...
    insmod wrote:

    Why would migration to EF break compatibility?

    p.kaczmarek2 wrote:
    would break config backwards compatibility
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT

Topic summary

✨ The discussion centers on the AllWinner/XRadioTech XR806AF2L_Baseboard V1.0 development board and its XR806 Wi-Fi module. Initial issues included the XR806 chip burning out shortly after use, suspected due to 5V supply to the module, though this voltage was considered acceptable. The user shared boot logs showing firmware and driver versions, MAC addresses, and platform details including XR806 SDK v1.2.0. Subsequent attempts with a second board showed similar firmware and stable operation without damage.

Community members provided links to official and third-party SDKs, documentation, and firmware repositories, including updated SDK versions (v1.2.2) and OpenBK7231T_App firmware builds. Efforts focused on resolving bootloader and OTA (Over-The-Air) update failures, with errors related to binary size, flash erase alignment, and TCP client disconnections during OTA. Adjustments to CONFIG_MALLOC_MODE (set to 0 for XR806) resolved some boot issues, enabling successful boot and partial OTA functionality.

Further firmware improvements included enabling deep sleep modes, pin deep sleep, and integration of XR872 OTA support. OTA via HTTP showed progress but intermittent TCP disconnects persisted. The community also discussed redundant ADC initialization in the battery driver and differences between SDK builds (_ALT builds with integrated mbedtls and WPA3 support but larger binary size). Debugging involved detailed crash logs and register dumps.

The XR806 platform was compared to XR809 and XR872, with XR806 showing better stability in some aspects. The discussion included enabling console output, UART handling, and driver support for peripherals like BL0937. Static IP and MAC address usage from efuse were implemented. The conversation concluded with ongoing testing of OTA reliability, driver enhancements, and firmware stability improvements.
Generated by the language model.

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.
ADVERTISEMENT