BlackPlastic Design · Fault investigation
A Pocket Cinema Camera 6K Pro that accepts exactly three video-pipeline reconfigurations and then hangs permanently. The count is fixed, the timing is predictable, and a power cycle resets it. Here is everything established so far, everything eliminated, and the measurements that would settle it.
From a cold boot, on a clean and complete firmware install, with the camera fully assembled — change the recording resolution repeatedly: M
| 1st change | ~1 second |
| 2nd change | ~2 seconds |
| 3rd change | hangs permanently |
Identical after a power cycle. The progression is arithmetic and repeatable, not intermittent — which is unusual enough to be the most useful thing about this fault.
A marginal rail or an unstable clock produces random behaviour. It does not produce a clean 1, 2, dead progression. This is resource exhaustion, not intermittency. I
| Test | Result | Conclusion |
|---|---|---|
| Wait 60 s between changes | Unchanged — still 1, 2, dead | No time-based reclaim. A hard count. |
| Cycle two low resolutions | Still exactly 3 | Not memory. A byte budget would scale with buffer size. |
| Drive changes over Bluetooth instead of the touchscreen | Same 3, same hang | Control layer eliminated. Menu, touch, BLE stack all irrelevant. |
| Power cycle | Budget resets to 3 | State is held until the block is reset. |
A fixed count of roughly three, not scaling with size and never reclaimed, points at a small pool of discrete hardware resources — DMA channels or descriptors, IPC mailboxes, partial-reconfiguration regions, or clock domains. Claimed on configure, never released. I
The camera is not dead. Monitored from a host across the freeze: M
So the kernel, the USB device controller and the MTP responder are all still running. This is a hung task, not a system crash. The blocked shutdown is consistent with the shutdown sequence waiting on that task to release, rather than being a second fault. I
| Works normally | Fails |
|---|---|
| Menus, touchscreen | Resolution change (3 then hang) |
| Audio, real-time VU metering | Codec change |
| Settings persistence | Record start |
| Media enumeration — 300 clips read | Playback — crashes during init |
| Bluetooth, built-in ND, lens iris | Sensor configuration |
| USB in both firmware modes | Frame guides, crosshair on LCD |
The split is clean. Everything in the left column is native to the
application processor. Everything in the right column requires the video pipeline
to reconfigure. Recovered firmware symbols show the application side communicates
with the video subsystem across an inter-processor boundary
(IPCReadTask, IPCWriteTask), and this is exactly the
split that predicts. I
Every resolution except 4K renders as repeated tiles. 4K gives one correct full-screen image. M
| Setting | Display |
|---|---|
| 4K | One correct full image |
| 5.7K | Three tiles across the top, one wide across the bottom |
| 3.7K anamorphic | Three tiles |
Repeated content is structural, not corruption — the same pixels can only appear twice if the thing writing the frame and the thing reading it disagree about its layout. Corruption gives noise and dropouts, never repeats.
Which side is stuck is not yet established. A stuck consumer is implausible — this is a native 6K camera with a documented 6K default, so nothing should power up holding 4K. The better candidate is that the sensor is stuck in one readout mode, and 4K happens to be the mode it holds. That requires nothing to default oddly, and it explains why the pipeline looks healthy: it is healthy, and being fed the wrong geometry. I
At 4K the image is close to normal but strobing — brief on, longer off. With the lens capped it produces clean black that still strobes. M
That separates two things. Colour corruption is content-dependent — present on real image data, absent on black — consistent with bit errors upstream. The strobing is content-independent, so it is frame delivery, not pixel data. Something acquires lock briefly, delivers a frame or two, drops, and re-acquires.
A duty-cycled display looks dim. "Dim image", "flickering image" and "intermittent corruption" are not three symptoms here — they are one mechanism seen three ways. Do not chase exposure or gain.
A complete, verified 7.9 install was performed with the camera fully assembled over a direct USB port. The install succeeded; the camera re-enumerated in normal firmware; every symptom persisted unchanged. M
That eliminates, in one test:
A second, independent argument reaches the same place: these firmware versions shipped to thousands of cameras. If they behaved like this generally, it would be common knowledge. The firmware is known-good; this camera's response to it is not.
| Candidate | How |
|---|---|
| Update transfer / USB | Packet capture: 100.1% of payload delivered, zero USB errors. The reported failure is a host timeout, not a truncated write. |
| Power supply | 11.74 V system rail measured, battery charges at 8.14 V, DC/battery sub-board bench-tested standalone. |
| Settings storage | Settings survive a full power-down and unplug. |
| Media path | 300 clips enumerate correctly. |
| PS-GTR transceivers | The LCD is driven via DisplayPort over PS-GTR through an eDP-to-DSI bridge. A working display proves that domain. |
| Memory exhaustion | Budget is exactly 3 at every resolution. A byte budget would scale. |
| Control layer | Same failure over Bluetooth as on the touchscreen. |
Recorded because a discarded hypothesis is worth as much to the next engineer as a confirmed one, and because the reasoning behind each was wrong in an instructive way.
Recorded as repeatable, and for a fortnight the strongest single pointer at the sensor board. It did not reproduce. The actual variable was a USB hub in the host path. With the hub removed, updates complete with everything connected. Any conclusion built on that correlation is void.
A stride mismatch produces clean N × N tiling. The observed 5.7K layout is asymmetric — three across the top, one wide across the bottom — which a stride error cannot produce.
It is exactly what random data does. Expected longest run is 1 + log256(N), which for 112 MB is 4. No finding.
One mechanism accounts for the whole symptom set: a marginal high-speed receive link that acquires lock briefly, delivers a frame or two, drops, and re-acquires — and whose failure to complete cleanly means resources are claimed and never released. I
That single cause produces missing frames, bit errors in the frames that do arrive, apparent dimness, a pipeline that never reconfigures, three operations before deadlock, record hanging, playback dying during init, and non-deterministic boot.
It has not been confirmed. The alternative — that the sensor is simply not accepting mode changes over its control bus, and everything downstream is healthy — fits the geometry evidence at least as well.
Ordered by value per unit of effort.
| # | Test | Discriminates |
|---|---|---|
| 1 | Field of view across resolutions. Fixed scene, note framing, change resolution, power cycle, compare. | On a healthy 6K Pro, 4K DCI is a crop of 6K — framing must visibly change. If framing never moves, the sensor is not changing mode at all. Free. |
| 2 | Instrument, then trigger. Probe MGTAVCC 0.900 V, MGTAVTT 1.200 V, MGTVCCAUX 1.800 V and a clock output, then perform changes 1, 2, 3. | A progressive sag, or a clock stopping at the freeze, names the fault. Nothing moving eliminates power and clocking together. |
| 3 | Precision resistors MGTRREF ball K8 and MGTAVTTRCAL ball K7, ~100 Ω. | A drifted termination reference gives exactly this class of marginal link. |
| 4 | Sensor control bus through power-on. Logic analyser; watch when traffic starts relative to boot. | Traffic before the fabric could be configured means PS hard I²C. Traffic only later means the bus is in the PL — and a PL fault then explains everything at once. |
| 5 | Mixed-operation budget. Cold boot, then one resolution change, one codec change, one more of either. | Hanging on the third regardless of which operations proves a single shared resource pool. |
The flex to the tilting monitor is creased and abraded through to copper by an unfinished steel chassis edge, with six conductors exposed and cracking visible under magnification on at least two. Boot appears to require the monitor attached, which places that cable in the boot-critical path and offers a mechanism for the non-deterministic boot. It is an assembly defect, not wear, and it needs replacing rather than repairing — cracked, work-hardened copper on a differential pair passes a DC continuity test and is still electrically wrong. M
If you have a working Pocket 6K Pro and a meter, three numbers would be worth more to this investigation than any amount of further reasoning:
MGTAVCC, MGTAVTT, MGTVCCAUX measured under loadEvery rail figure quoted here is a datasheet nominal. Not one is a measurement from a camera known to work.