logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

Exploring A9 Minicam Variation: XF16 PB380EA6341 MCU, T25S80 SPI Flash, XR872, Skylark SDK

divadiow 36576 299
ADVERTISEMENT
Report a violation of the law
Reply | New topic
  • #121 21530504
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    today's arrival - another XF16 A9 - same PCB as before, the same 1mb flash chip markings on recent A9 above - CF TJ25Q08M
    PCB with electronic components and a lithium-polymer battery on a blue background. Printed circuit board with electronic components, micro USB socket, ribbon connector, and microphone.

    familiar flash ID C74014. Neo detection name from my own import.xml
    Screenshot of memory programmer software showing detected GD25Q80_CLONE chip at 3.3V.

    dumps https://github.com/openshwprojects/FlashDumps...mits/f4149235555af79af280bf61abb642e41ac55f0d
    HxD says UART and SPI identical

    boot log
    Code: Text
    Log in, to see the code


    SP0828 cam seen in log and printed on ribbon

    Product label on a white box with a barcode, IP camera description, and manufacturer details. A9 camera packaging and YsxLite app instruction manual on a blue surface.
  • ADVERTISEMENT
  • #122 21530531
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I've got 3 today, all the same version as you:
    Three disassembled IP cameras with exposed electronics and Li-Po batteries.
    Three disassembled camera modules with visible PCBs and lenses, along with housing parts and batteries on a white surface.
    Close-up of a camera circuit board with visible lens, T25S80 flash memory chip, and connectors.
    Camera module with lens, circuit board, and connectors shown in close-up.
    Close-up of a camera circuit board with lens, T25S80 flash chip, and a lit blue LED.
    Backup of all 3 firmwares:
    https://github.com/openshwprojects/FlashDumps/commit/f736f4afcd1c96a4c7dc85d377540d048f37bf59

    Well, it seems it's hard for me to get another version. Maybe we should try something. For example... take offsets from here:
    Screenshot of a firmware configuration utility, showing details of six binary sections with addresses, sizes, and attributes.
    and enter them to OpenXR872\project\image_cfg\image.cfg

    Also, would that camera boot from 1MB flash but non-factory one? I mean, take another 1MB flash chip from a laptop or something, flash OBK to it, will it boot?
    Helpful post? Buy me a coffee.
  • #123 21530534
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    Also, would that camera boot from 1MB flash but non-factory one? I mean, take another 1MB flash chip from a laptop or something, flash OBK to it, will it boot?


    worth a try maybe. might have a 1mb on an ESP somewhere.

    Also, I think it's correct that freq: 96000000Hz is only seen in boot log for XR872 and not on factory A9 XF16 boot logs, which appear to be freq: 48000000Hz. I don't see how this relates to flash size, but what might the significance of that be?

    Added after 1 [minutes]:

    https://github.com/openshwprojects/OpenXR872/...ee15e07d/project/common/framework/psram.c#L92
  • #124 21530540
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Ok I can't do the same format as in factory firmware, unless I turn off some things
    Screenshot showing a diff of the image.cfg configuration file, highlighting changes in flash_offs values across several sections.
    Screenshot of a console error message showing bin file overlap during firmware image generation.

    Added after 3 [minutes]:

    Wait, why our image cfg has OTA at offset 1024?

    A fragment of a JSON configuration file with the OTA section highlighted, showing address 1024K and size 4K.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #125 21530544
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    oh. that sounds problematic if BL is checking there..?
  • #126 21530548
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I don't know, I would expect at least an error message on UART.

    I am trying to enter partition table as in backup, but after moving app_xipapp_xip.bin futher down in flash, I got this:
    Code: text Expand Select all Copy to clipboard
    
err: bin 4 and bin 5 were overlaped!
Overlapped size: 6708 Byte(7kB)
bin 4 name:wlan_fw.bin    begin: 0x000CA800    end: 0x000D2A34
bin 5 name:wlan_sdd_40M.bin    begin: 0x000D1000

We've rearranged bin files and generated new cfg file 'image_auto_cal.cfg', the new one is recommended.
Generate image file failed

    Spoiler:

    Code: text Expand Select all Copy to clipboard
    
{
    "magic": "AWIH",
    "version": "0.4",
    "OTA": {
        "addr": "1024K",
        "size": "4K"
    },
    "image": { "max_size": "880K" },
    "count": 6,
    "section": [
        {
            "id": "0xa5ff5a00",
            "bin": "boot_40M.bin",
            "cert": "null",
            "flash_offs": "0K",
            "sram_offs": "0x00268000",
            "ep": "0x00268101",
            "attr": "0x1"
        },
        {
            "id": "0xa5fe5a01",
            "bin": "app.bin",
            "cert": "null",
            "flash_offs": "32K",
            "sram_offs": "0x00201000",
            "ep": "0x00201101",
            "attr": "0x1"
        },
        {
            "id": "0xa5fd5a02",
            "bin": "app_xip.bin",
            "cert": "null",
            "flash_offs": "144K",
            "sram_offs": "0xffffffff",
            "ep": "0xffffffff",
            "attr": "0x2"
        },
        {
            "id": "0xa5fa5a05",
            "bin": "wlan_bl.bin",
            "cert": "null",
            "flash_offs": "806.5K",
            "sram_offs": "0xffffffff",
            "ep": "0xffffffff",
            "attr": "0x1"
        },
        {
            "id": "0xa5f95a06",
            "bin": "wlan_fw.bin",
            "cert": "null",
            "flash_offs": "810K",
            "sram_offs": "0xffffffff",
            "ep": "0xffffffff",
            "attr": "0x1"
        },
        {
            "id": "0xa5f85a07",
            "bin": "wlan_sdd_40M.bin",
            "cert": "null",
            "flash_offs": "836K",
            "sram_offs": "0xffffffff",
            "ep": "0xffffffff",
            "attr": "0x1"
        },
        {}
    ]
}


    I will give up with offsets for now, and I will give you build without OTA to check.

    Added after 8 [minutes]:

    Attaching two builds, second with OTA section removed:
    Screenshot of a code editor showing differences in a configuration file.
    Comparison of two binary files in a hex editor, highlighting byte-level differences.
    Attachments:
    • to_ota_or_not_to.zip (886.5 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #127 21530564
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    ota was the problem.

    to be clear, xr_system_noOTA.img boots on 1mb flash

    Code: Text
    Log in, to see the code
  • #128 21530633
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    That's a very good news! So soon I can make XR872/XF16 flashing guide. Is there anything else we should do first?

    I've pushed config fix to main app:
    https://github.com/openshwprojects/OpenBK7231...mmit/0274993d7fc077c4f160556c932c98428e7c3cc1
    Helpful post? Buy me a coffee.
  • #129 21530699
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    not sure what should come first tbh, I guess all the pins? How would it work? Configure the most number of pins for XR872 and then see which control pins on XF16?

    Screenshot of a device configuration panel with multiple error fields and dropdown menus.

    RSSI. Powersave, ADC/battery, loads of things I guess.

    Also do you build for 2mb+ with OTA, assuming most XR871s are larger, but provide a no-OTA XF16 1mb version too?

    OpenXR872 device control panel with configuration, restart, and web app launch buttons.

    curiously, there's an XF16 A9 here with 2mb chip https://community.home-assistant.io/t/popular...mini-wi-fi-camera-the-ha-challenge/230108/247
  • ADVERTISEMENT
  • #130 21530761
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I've been also wondering whether this driver matches the camera we have:
    https://github.com/search?q=repo%3Aopenshwprojects%2FOpenXR872%20camera&type=code
    https://github.com/openshwprojects/OpenXR872/...76418953/project/common/cmd/cmd_camera.c#L153
    Are those pins matching our board?
    Code: C / C++
    Log in, to see the code


    Do these sensors match?
    Code: C / C++
    Log in, to see the code


    Added after 52 [seconds]:

    divadiow wrote:


    curiously, there's an XF16 A9 here with 2mb chip https://community.home-assistant.io/t/popular...mini-wi-fi-camera-the-ha-challenge/230108/247

    probably older version when they kept OTA, later they have removed OTA and reduced flash size?
    Helpful post? Buy me a coffee.
  • #131 21530856
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    probably older version when they kept OTA, later they have removed OTA and reduced flash size?

    I guess so.

    Quote:
    Do these sensors match?


    hmm. I have GC0329C, SP0828 and I need to check 3rd XF16 again. Maybe GC0328c driver works for GC0329C. @insmod mentioned some GC0x drivers here https://www.elektroda.com/rtvforum/topic4118348.html#21526110 maybe he knows more since then

    Added after 5 [minutes]:

    https://github.com/search?q=drv_gc0329.h&type=code
  • #132 21530863
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    do we have GC0329C or GC0328c datasheet?
    Helpful post? Buy me a coffee.
  • #133 21530893
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    nope. only GC0308
  • #134 21530904
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    What about pins? Did you try to check them?


    Hm, this is the sample for camera, it's called jpeg:
    Code: text Expand Select all Copy to clipboard
    
tester@DESKTOP-7SD9MUK:/mnt/w/GIT/OpenXR872/project/example/jpeg/gcc$ make image

    Compilation error in terminal with multiple references to undefined function `__wrap_memset`.
    This doesn't look hard to fix

    Added after 1 [minutes]:

    I added to main.c:
    Code: C / C++
    Log in, to see the code

    only those errors remain:
    Code: text Expand Select all Copy to clipboard
    
../../../../lib/libchip.a(hal_spi.o): In function `HAL_SPI_Close':
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_spi.c:929: undefined reference to `HAL_DMA_Stop'
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_spi.c:930: undefined reference to `HAL_DMA_Stop'
../../../../lib/libchip.a(hal_spi.o): In function `HAL_SPI_Receive':
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_spi.c:1029: undefined reference to `HAL_DMA_Stop'
../../../../lib/libchip.a(hal_spi.o): In function `HAL_SPI_Transmit':
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_spi.c:1109: undefined reference to `HAL_DMA_Stop'
../../../../lib/libchip.a(hal_dcache.o): In function `HAL_Dcache_IsCacheable':
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_dcache.c:58: undefined reference to `__XIP_BASE'
/mnt/w/GIT/xr872_sdk/src/driver/chip/hal_dcache.c:58: undefined reference to `__XIP_END'
../../../../lib/librom.a(rom_core.o):(.ram_table+0x138): undefined reference to `__XIP_BASE'
../../../../lib/librom.a(rom_core.o):(.ram_table+0x13c): undefined reference to `__XIP_END'
../../../../lib/xradio_v2/libwlan.a(wlan.o): In function `wlan_ap_sta_info':
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan.c:452: undefined reference to `wpa_ctrl_request'
../../../../lib/xradio_v2/libwlan.a(wlan_ctrl.o): In function `wlan_start':
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:300: undefined reference to `wpas_start'
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:306: undefined reference to `hostapd_start'
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:314: undefined reference to `wpa_ctrl_open'
../../../../lib/xradio_v2/libwlan.a(wlan_ctrl.o): In function `wlan_stop':
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:329: undefined reference to `wpas_stop'
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:335: undefined reference to `hostapd_stop'
/home/xieqihai/IOT/sdk/git/wlan/src/net/wlan/wlan_ctrl.c:341: undefined reference to `wpa_ctrl_close'
collect2: error: ld returned 1 exit status
make: *** [../../../../project/project.mk:327: jpeg.axf] Error 1


    Added after 1 [minutes]:

    I can see HAL_DMA_Stop in code, why would it be missing https://github.com/search?q=repo%3Aopenshwprojects%2FOpenXR872%20HAL_DMA_Stop&type=code

    Added after 1 [minutes]:

    _XIP_BASE is undefined probably because of the lack of _XIP_BASE

    Fragments of two code files showing the definitions and assignments of XIP addresses in C and linker script.

    Added after 5 [minutes]:

    Ok another idea. I don't have that much time for playing, but maybe I could just put camera calls in OBK project?
    Code: C / C++
    Log in, to see the code

    Well, it actually compiled with test call to HAL_GC0328C_Suspend - no linker errors.
    Helpful post? Buy me a coffee.
  • #135 21530909
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    What about pins? Did you try to check them?


    I'm not sure what to trace and to where. With no datasheet for either XF16 or the GC0329...
  • #136 21530910
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Ah, we don't actually know the GPIO pinout of XF16?
    Helpful post? Buy me a coffee.
  • #137 21530911
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    p.kaczmarek2 wrote:
    Ah, we don't actually know the GPIO pinout of XF16?

    no! only XR872

    Added after 1 [minutes]:

    I've tried quite a lot to :(
  • ADVERTISEMENT
  • #138 21530912
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Camera compiled in OBK project:
    Code: C / C++
    Log in, to see the code

    It requires SD card by default so will most likely crash
    Attachments:
    • notsure.zip (397.87 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #139 21530919
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    Code: Text
    Log in, to see the code
  • #140 21530928
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Not sure if I recompiled, but here is without SD check:
    Code: C / C++
    Log in, to see the code

    updated attachment
    Attachments:
    • notsure3.zip (397.56 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #141 21530933
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    Code: Text
    Log in, to see the code
  • #142 21530934
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Wait I will add better printfs:

    Screenshot showing a C source code snippet implementing a memory allocation function for a camera.

    Added after 6 [minutes]:

    It probably fails here:
    Code: C / C++
    Log in, to see the code

    I don't see any external PSRAM chips so it probably uses heap path. So it fails to alloc JPEG_SRAM_SIZE bytes.
    JPEG_SRAM_SIZE can have different values:
    https://github.com/search?q=repo%3Aopenshwprojects%2FOpenXR872%20JPEG_SRAM_SIZE&type=code
    In my sample I used:
    Code: C / C++
    Log in, to see the code

    180kB, but here they use 100kB:
    https://github.com/openshwprojects/OpenXR872/...f76418953/project/common/cmd/cmd_camera.c#L67
    Let's try with 100kB


    Better logging file attached:
    Attachments:
    • notsure4.zip (397.62 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #143 21530938
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    Code: Text
    Log in, to see the code
  • #144 21530951
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Better use camera cmd demo...
    Code: C / C++
    Log in, to see the code
    Attachments:
    • notsure5.zip (450.23 KB) You must be logged in to download this attachment.
    Helpful post? Buy me a coffee.
  • #145 21530956
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    Code: Text
    Log in, to see the code
  • #146 21530962
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Well the alloced buffer is obviously to small for target size. I didn't check that, I just trusted the size from the camera sample and it's obviously too small.

    Ok I attached one camera, I will give it few more tries on my side

    Added after 12 [minutes]:

    Im confused.
    Code: text Expand Select all Copy to clipboard
    
size 460800
[cmd ERR] camera_mem_create():167, aadr exceeded

    for 640 x 480 this code needs 460 800 RAM, but XR872 is said to have 416KB SRAM. It supports external PSRAM, but it's not present in A9 cameras. So, how do they take 640x480 image there?

    Added after 4 [minutes]:

    Code: text Expand Select all Copy to clipboard
    
__CONFIG_JPEG: Required option. Enables the JPEG module and must be enabled.

__CONFIG_JPEG_SHAR_SRAM_64K: Optional. Configures the amount of memory to allocate for JPEG usage. This option must be enabled when the image height exceeds 576 or the width exceeds 720.

__CONFIG_PSRAM: Optional. Enables PSRAM in the project. Must be enabled if the project uses PSRAM functionality.

__CONFIG_PSRAM_CHIP_OPI32: Optional. Configures the type of PSRAM.


    Added after 28 [minutes]:

    Code: text Expand Select all Copy to clipboard
    el! @ 5255 sec
Will call my_camera_init_exec
Will call camera_mem_create
camera_mem_create will malloc
heap exhausted, incr 122888, 0x258674 >= 0x257c00
camera_mem_create: malloc fail 122880
Will call HAL_CAMERA_Init
[HAL WRN] I2C wait semaphore failed, i2c ID 0
GC0328C sccb read error
GC0328C Init error!!
[CAMERA ERR] HAL_CAMERA_Init():362, sensor config fail
[cmd ERR] my_camera_init_exec():199,  init fail
Will call my_camera_cap_one_image_exec
Will call HAL_CAMERA_CaptureImage
[CAMERA ERR] HAL_CAMERA_CaptureImage():437, not init
[cmd ERR] my_camera_cap_one_image_exec():216, cap one image failed
Will call my_camera_deinit_exec
[CAMERA ERR] HAL_CAMERA_DeInit():386, not init
Hello wordsald! @ 9322 sec
Hello wordsald! @ 10322 sec


    Added after 31 [minutes]:

    Had to do SPI recover, interestingly enough NeoProgrammer detected:
    Code: text Expand Select all Copy to clipboard
    
SPI ID: 5E3214
---------------------------------------------------------------------------
Currently selected:  ZB25WD80 [3.3V] 8 Mbits, 1 Mbytes


    Added after 11 [minutes]:

    Tried second I2C:
    Code: text Expand Select all Copy to clipboard
    
[HAL WRN] I2C wait semaphore failed, i2c ID 1
                                  
                                              GC0328C sccb read error
          
                                                                      GC0328C In
it error!!
                                                                     
    Helpful post? Buy me a coffee.
  • #148 21531035
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I was hoping that they just used SDK setup, but no. We need to trace pins. Maybe it's not the same type of the camera, but maybe it is and requires extra power signal. We need more information.


    For memory, it looks like we don't need YUV buffer (yuv_buf). It's used only in JPEG_MOD_OFFLINE. And in online, it will create JPEG on the fly. So it will fit to memory. This check in cmd_camera.c is incorrect in online mode:
    Code: C / C++
    Log in, to see the code

    yuv_buf could be totally removed.

    We need to find GPIO of the camera. Is XR871 GPIO matching XR872:?
    Helpful post? Buy me a coffee.
  • #149 21531043
    divadiow
    Level 38  
    Posts: 5027
    Help: 438
    Rate: 891
    hmm. no, it seems...


    Pinout diagram of the XR871GT integrated circuit in LQFP package. Pinout diagram of the XR871ET integrated circuit in a QFN52 package.

    Top view of the XR872ET chip pinout diagram from XRAD Tech with labeled pins. Pinout diagram of the XR872AT microcontroller with labeled pins.
  • #150 21531055
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Well, XTAL (oscillator) pin positions seems to match, so why do you think that XR872 pinout does not match XF16? Pin 52 (antenna) also seem to match.
    Helpful post? Buy me a coffee.
Reply | New topic
Report a violation of the law

Topic summary

✨ The discussion focuses on a variation of the A9 mini Wi-Fi camera featuring the XF16 PB380EA6341 MCU, an 8Mbit SPI flash chip labeled T25S80 (likely from ChipSourceTek), and the XR872 SoC running the Skylark SDK. Attempts to read and dump the flash firmware using tools like Flashrom, NeoProgrammer, and ASProgrammer faced challenges due to unrecognized SPI IDs and unreliable read/write operations, especially when the flash chip was in-circuit. Desoldering the flash chip improved read/write reliability. The firmware strings indicate the use of an RTOS and the iLnkP2P protocol for communication. The XR872 SDK (version 2.0 and later 1.2.x) was explored for building and flashing demo applications, including a "hello world" example, which successfully booted on the hardware after flashing via UART using PhoenixMC. Flashing custom firmware requires careful handling of flash erase and protection bits, with some users experiencing verification errors and random write failures. The flash layout includes an AWIH header and OTA partitions, with OTA updates compressed by XZ, raising concerns about fitting OTA images into the 1MB flash. Hardware details such as the presence of a pull-up resistor on the flash hold pin and UART pin configurations (PB02/PB03) were examined. The community also discussed the compatibility of different flash chip sizes (1MB vs 2MB) and the impact on firmware booting and flashing. Some users successfully transplanted firmware to larger flash chips (2MB) to run custom firmware like OpenXR872 (OBK). The discussion includes references to related projects for video stream capture without flashing (cam-reverse) and the challenges of flashing and booting custom firmware on these devices. Overall, the thread provides detailed technical insights into hardware probing, firmware extraction, SDK usage, flashing procedures, and troubleshooting for the XF16-based A9 mini camera variant with XR872 SoC.
Generated by the language model.
Today's popular

FAQ

TL;DR: With 1MB stock flash, many XF16 A9 cameras can be dumped and restored over UART, and one contributor confirmed "OpenXR872 ... boots on 1mb flash" only after fixing the image layout. This FAQ helps XR872/XF16 camera owners back up firmware, understand AWIH partitions, fix PhoenixMC/UART issues, and avoid bad SPI-flash writes. [#21530564]

Why it matters: XF16 A9 cameras look identical externally, but small changes in flash size, OTA layout, console settings, and sensor wiring decide whether firmware boots, flashes, or bricks.

Method What works best Main strengths Main failure mode
PhoenixMC over UART Read/write on XF16/XR872 without opening some A9 units No desoldering; can restore stock dumps Custom builds may lose UART flashing after power cycle if console support is wrong
CH341A + SOIC8 clip Quick first dump attempts Cheap; widely available In-circuit reads often return bad IDs like 1313 or 8E8029
CH341A with desoldered flash Most reliable SPI backup/restore Stable verification; works with replacement chips Some flash chips still fail erase/write unless decoupling is added
Bus Pirate Usually poor choice here Can talk SPI/UART Backfeeds power and often fails chip detection

Key insight: The hardest XF16 problems were not caused by the XR872 core. They came from image layout, OTA header placement, console enablement, and fragile SPI flash behavior on specific 1MB chips.

Quick Facts

  • XF16 boot logs repeatedly report 240000000 Hz CPU, 40000000 Hz HF clock, and XRADIO Skylark SDK builds such as 1.2.0 Jun 20 2024 10:58:31 or 1.2.2 test builds, which makes the platform easy to fingerprint from UART alone. [#21219273]
  • The stock A9 XF16 camera flash is commonly 8 Mbit / 1 MB with IDs such as C74014 or 5E3214, while test replacements that booted OpenXR872 included 2 MB and even 64 Mbit chips. [#21522966]
  • UART flashing can work through the camera’s USB path on some XF16 A9 boards because RX/TX are routed through the USB connector traces; contributors built simple USB-TTL adapters from NodeMCU or CH340 hardware to exploit that. [#21528571]
  • The stock firmware exposes a local AP at 192.168.238.1/24, while OpenXR872 test builds used 192.168.51.1/24 or 192.168.4.1/24, so IP range alone can reveal whether you are in factory or custom firmware. [#21219273]
  • Confirmed XF16 camera-connector tracing mapped SDA/SCL to PA18/PA17, PCLK to PA08, MCLK to PA09, HSYNC to PA10, VSYNC to PA11, and DVP data lines across PA00–PA07. [#21732686]

How can I dump and restore firmware on an XF16 A9 minicam with a T25S80 or C74014 SPI flash chip using a CH341A, clip, or PhoenixMC over UART?

You can dump and restore XF16 firmware either over SPI or over UART. 1. For SPI, clip or desolder the 8-pin flash, then read it with a CH341A in NeoProgrammer, ASProgrammer, or EasyFlasher. 2. For UART, connect through the XF16 USB-routed RX/TX path and use PhoenixMC to read or flash without opening some cameras. 3. Always verify the dump and keep at least one known-good stock backup before testing OpenXR872. One contributor confirmed they clipped directly onto the flash and did not need reset mode first. [#21278253]

Why do some XF16 A9 cameras report strange SPI flash IDs like 1313, 8E8029, C74014, or 5E3214 when reading the flash in-circuit?

Those odd IDs usually mean the in-circuit SPI read is unstable, not that the chip is truly changing identity. The thread showed 1313, 8E8029, and then stable C74014 on the same 1MB camera, while a desoldered read later became consistent and verified correctly. Shared power rails, leakage from the rest of the board, bad clip contact, and marginal CH341A supply decoupling all caused false IDs. A clean off-board read or UART dump was much more trustworthy than an in-circuit first pass. [#21522287]

What is the AWIH header in XR872/XF16 firmware dumps, and how can it help identify image sections like boot, app, app_xip, and wlan_fw?

"AWIH is a firmware image header that marks XR/XF system images, stores image metadata, and helps separate boot, app, XIP, and WLAN sections." In this thread, contributors matched AWIH-tagged section IDs such as 0xa5ff5a00, 0xa5fe5a01, 0xa5fd5a02, 0xa5fa5a05, and 0xa5f95a06 to boot_40M.bin, app.bin, app_xip.bin, wlan_bl.bin, and wlan_fw.bin. Searching a dump for those little-endian markers was enough to start slicing it for Ghidra or manual comparison. [#21589985]

What is iLnkP2P on these A9 and PTZ cameras, and how is it related to the YSX/YSXLite apps and cam-reverse tools?

"iLnkP2P is a peer-to-peer camera transport protocol that carries control and media traffic, identifies devices with UIDs, and lets mobile apps reach cameras through local AP mode or relay servers." These XF16 and PTZ cameras logged IpcP2pStart, device rtuid, and p2pID, then worked with YSX or YSXLite. The same protocol is what cam-reverse and related reversing notes target, including video extraction and CGI-style control. Multiple posts linked the protocol directly to the apps and to the reverse-engineering workflow. [#21353025]

Why did OpenXR872 boot on a 2MB flash chip but initially fail on the stock 1MB flash chip in the XF16 A9 camera?

It failed because the early image layout still assumed space beyond the stock 1MB boundary. The same OpenXR872 image booted when the original dump was transplanted to a 2MB flash chip, but not on the original 1MB flash. That exposed a layout problem rather than a CPU or sensor problem. The boot logs showed image max size is invalid and missing XIP section errors on the 1MB setup, while the 2MB chip could tolerate the oversized placement. [#21525075]

How was the 1MB XF16 boot issue solved by changing the OpenXR872 image configuration and OTA header placement?

The fix was to shrink the effective image layout for 1MB flash and move the OTA header out of the failing location. First, contributors rebuilt with max_size around 880K. Later they proved that a no-OTA image booted on 1MB stock flash, then refined the layout so the OTA header sat at 1020K with 4K size instead of the breaking 1024K arrangement. After that, 1MB XF16 boards booted OpenXR872 normally. As one post put it, “ota was the problem.” [#21530564]

Why does UART flashing through PhoenixMC stop working on some OpenXR872 builds after a power cycle, and how was PRJCONF_CONSOLE_EN involved in fixing it?

UART flashing stopped because the custom build no longer exposed the console command path that PhoenixMC uses after reboot. The breakthrough was enabling #define PRJCONF_CONSOLE_EN 1, which restored the upgrade command path and made Open comm OK ! survive fresh power cycles on 1MB XF16 boards. Before that fix, some builds could still be reflashed only until RAM state was lost, which made the problem look random. After the console option was re-enabled, PhoenixMC download-mode entry became reliable again. [#21536774]

CH341A vs Bus Pirate vs PhoenixMC over UART — which works best for reading and flashing XF16/XR872 camera firmware, and what problems should I expect with each?

PhoenixMC over UART is the best day-to-day method on XF16 once stock firmware or a console-enabled OpenXR872 build is present. CH341A is best for first-rescue backups, off-board writes, and recovery when UART entry is gone. Bus Pirate was the worst performer here: users reported non-detection, backfeeding power, and brief LED power-up when clipped in. CH341A also had pitfalls, especially with sensitive 1MB chips, but it still worked reliably after desoldering or after adding extra capacitance. [#21352083]

How do I enter XR872/XF16 download mode over UART without grounding PB02 or PB03, and what commands does PhoenixMC actually send?

You do it by speaking the stock console protocol, not by forcing strap pins low. PhoenixMC sends the text command upgrade, then repeated U sync bytes; a receptive firmware answers with OK and a BROM response. Later reversing tied that behavior to the XR command handler where cmd_upgrade_exec() reboots with PRCM_CPUA_BOOT_FROM_SYS_UPDATE. That is why stock firmware and console-enabled OpenXR872 can enter download mode over UART without grounding PB02 or PB03 at all. [#21534886]

What does the XRADIO Skylark SDK boot log tell me about an XF16 camera, including CPU clock, flash mode, sensor detection, and network behavior?

The boot log gives you the board fingerprint in one place. It exposes flash mode like [FD I]: mode: 0x4, CPU at 240000000 Hz, HF clock at 40000000 Hz, SDK build date, MAC addresses, sensor probe results such as detect sp0828, and AP behavior such as 192.168.238.1 on stock firmware. It also shows whether the camera starts in AP mode, tries STA mode, fails SD mount, or enters iLnkP2P. For XF16 debugging, the UART log is the fastest way to identify variant, sensor, and failure stage. [#21219273]

How can I build XR872 SDK demos under WSL, and which toolchain and 32-bit libraries are needed to compile hello_demo or jpeg examples successfully?

Builds under WSL worked after installing the older ARM GCC toolchain plus missing 32-bit runtime libraries. The thread used gcc-arm-embedded 4.9-2015-q2-update, then fixed execution errors by installing libc6-i386, lib32z1, and lib32stdc++6. Without those, WSL reported missing loader errors even when the path was correct. Once the 32-bit compatibility packages were installed, make lib and example builds such as hello_demo started compiling normally. [#21522159]

Why do some SPI flash chips like TJ25Q08M, T25S80, or 25QH32CHIG fail erase/write verification in NeoProgrammer or EasyFlasher unless extra capacitance or special handling is used?

These chips appear unusually sensitive to supply stability during SPI writes. The thread documented random verify errors, partial writes, and false erases on desoldered chips until extra capacitance was added directly on the CH341A setup; after that, the same chip verified cleanly. One test with a 25QH32CHIG failed repeatedly, then passed once a capacitor was added across the supply. Some users also had to experiment with protection-register handling, but the strongest repeated fix was better decoupling on the programmer side. [#21709832]

How can I trace the 18-pin FFC camera connector on an XF16 A9 board to map SDA, SCL, DVP data pins, MCLK, HSYNC, VSYNC, and PCLK to XR872 GPIOs?

The cleanest method is continuity tracing plus a pin-toggle test firmware. On the confirmed XF16 A9 mapping, pin 2 is SDA on PA18, pin 3 is SCL on PA17, pin 13 is MCLK on PA09, pin 12 is HSYNC on PA10, pin 11 is VSYNC on PA11, pin 15 is PCLK on PA08, and DVP data runs from PA00–PA07. Contributors validated the map with an 18-pin FFC walker that pulsed each GPIO while a multimeter watched the connector. [#21732686]

Which camera sensors seem to be supported or referenced in XF16/XR872 firmware strings, and how can I start adapting drivers for parts like SP0828, GC0328C, GC0329, or HI0704?

The firmware strings reference many sensors, including ov9660, ov7740, sp2518, gc0310, gc0328, gc0329, hi0704, hi0708, and sp0828. Start by reusing initialization tables and SCCB/I2C setup from the closest supported driver, then confirm the actual sensor with ribbon markings or UART detection logs. For XF16 A9 specifically, sp0828 was repeatedly detected in stock logs, while separate posts confirmed useful initialization arrays existed for hi704-class parts. That makes driver adaptation a sensor-data problem more than a core XR872 problem. [#21547719]

How can I split or parse a stock XF16 firmware dump into PhoenixMC-style partitions for reverse engineering in Ghidra, and where does mkimage fit into that process?

Use the AWIH section markers and the XR image config as your map, then reverse from there. Search the dump for little-endian IDs like 005affa5, 015afea5, 025afda5, 055afaa5, and 065af9a5 to locate boot, app, app_xip, wlan_bl, and wlan_fw boundaries. The SDK’s mkimage.exe is the packer that assembles those partitions into one AWIH image, so it is the right binary to study if you want PhoenixMC-style slicing for Ghidra. The thread specifically identified mkimage.exe as the image-creation step. [#21587062]
Generated by the language model.
ADVERTISEMENT