Skip to content

build-image fails strict validation (HWCONFIG UOID / serial.cfg) on a fully bricked EF-S7-V1.0.30B camera #21

Description

@Sixth49

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"

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions