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]
Summary generated by AI based on the discussion content.
