Following the hardware-recovery route in the README, cc2camera build-image refuses my three verified-identical dumps with a strict-validation error. My camera matches the documented affected family, but it had already reached the "no longer works" state before I dumped it, so I'm filing this in case the erase-defect corruption goes deep enough that the config area is unrecoverable by design — or in case this is something that could still be handled.
Camera identification
PCB: EF-S7-V1.0.30B
CPU: Ingenic T23
Flash: HK25Q64DSIG, 64 Mbit / 8 MiB
Board code: 1526
Symptom before dumping: "Camera not connected" (camera did not come up at all; a known-good USB webcam worked fine in the same port, isolating the fault to the camera)
Programmer / chip detection
CH341A (verified VCC ≈ 3.3 V measured at pin 28 before connecting)
SOIC8 test clip via SOP16/8-DIP8 ZIF adapter
NeoProgrammer auto-detected the chip as ZB25VQ64 [3.3V] 64 Mbits, 8 Mbytes
Dump verification
Made three consecutive reads without moving the clip:
cc2-camera-1.bin 8388608 bytes
cc2-camera-2.bin 8388608 bytes
cc2-camera-3.bin 8388608 bytes
All three are byte-for-byte identical (same MD5: 9e83b5869b088345321987513b87b4e1), so I'm confident the clip contact was stable and the reads are trustworthy, not a bad connection.
Command run
cc2camera build-image cc2-camera-1.bin --confirm-read cc2-camera-2.bin --confirm-read cc2-camera-3.bin
Output
cc2camera: error: cc2-camera-1.bin failed strict validation:
- The unit-specific HWCONFIG UOID field does not have the expected 94-byte ASCII structure
- Could not recover exactly one unambiguous CRC-valid serial.cfg payload (found 0)
cc2camera version: 0.8.0
Question
Is this expected for a camera that reached full failure (i.e., the config area may already be too corrupted by the underlying erase defect for any valid serial.cfg to survive), and therefore unrecoverable by design without a --force? Or is there a known cause/workaround for this specific validation failure that I'm missing? Happy to share the raw dump privately if that helps diagnose it — I understand it shouldn't be posted publicly since it contains unit-specific identifiers.
Claude described these "issues"
Following the hardware-recovery route in the README, cc2camera build-image refuses my three verified-identical dumps with a strict-validation error. My camera matches the documented affected family, but it had already reached the "no longer works" state before I dumped it, so I'm filing this in case the erase-defect corruption goes deep enough that the config area is unrecoverable by design — or in case this is something that could still be handled.
Camera identification
PCB: EF-S7-V1.0.30B
CPU: Ingenic T23
Flash: HK25Q64DSIG, 64 Mbit / 8 MiB
Board code: 1526
Symptom before dumping: "Camera not connected" (camera did not come up at all; a known-good USB webcam worked fine in the same port, isolating the fault to the camera)
Programmer / chip detection
CH341A (verified VCC ≈ 3.3 V measured at pin 28 before connecting)
SOIC8 test clip via SOP16/8-DIP8 ZIF adapter
NeoProgrammer auto-detected the chip as ZB25VQ64 [3.3V] 64 Mbits, 8 Mbytes
Dump verification
Made three consecutive reads without moving the clip:
cc2-camera-1.bin 8388608 bytes
cc2-camera-2.bin 8388608 bytes
cc2-camera-3.bin 8388608 bytes
All three are byte-for-byte identical (same MD5: 9e83b5869b088345321987513b87b4e1), so I'm confident the clip contact was stable and the reads are trustworthy, not a bad connection.
Command run
cc2camera build-image cc2-camera-1.bin --confirm-read cc2-camera-2.bin --confirm-read cc2-camera-3.bin
Output
cc2camera: error: cc2-camera-1.bin failed strict validation:
cc2camera version: 0.8.0
Question
Is this expected for a camera that reached full failure (i.e., the config area may already be too corrupted by the underlying erase defect for any valid serial.cfg to survive), and therefore unrecoverable by design without a --force? Or is there a known cause/workaround for this specific validation failure that I'm missing? Happy to share the raw dump privately if that helps diagnose it — I understand it shouldn't be posted publicly since it contains unit-specific identifiers.
Claude described these "issues"