Nice, just make sure that XR872 image can still work on 1MB flash. XF16 cameras have it.
Helpful post? Buy me a coffee.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
divadiow wrote:MQTT connected but HA discovery not resulting in any new devices being added
p.kaczmarek2 wrote:
Image is created that way:E:projectIOTtoolsxr-mkimageRelease>mkimage.exe
so you would want mkimage source
mac address:
efuse : 18:9e:2d:xx:xx:xx
in use : f8:15:49:xx:xx:xx
XF16_tracings_WIP.jpg
(5.51 MB)
You must be logged in to download this attachment.
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.
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]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]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]image max size is invalid and missing XIP section errors on the 1MB setup, while the 2MB chip could tolerate the oversized placement. [#21525075]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]#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]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][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]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]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]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]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]