[BUG] OAK-D Lite: device crashes with RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE on CAM_C init in depthai v3 (3.7.1 & 3.8.0) — works fine on 2.32.0

[kadirakkaya]

Describe the bug

Any v3 pipeline that includes CAM_C (right OV7251 mono camera) crashes the device ~1.6 s after pipeline start. The device drops off the USB bus (kernel logs a USB disconnect), re-enumerates as the bootloader, and depthai retrieves a crash dump. We collected 21+ crash dumps over one day — every single one reports RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE.

Isolation matrix (each cell = separate run, v3.8.0 unless noted):

Pipeline	Result
RGB only (CAM_A, Camera node)	✅ works (30 frames, ~27 fps)
CAM_B mono only	✅ works (30/30 frames)
CAM_C mono only	❌ 0 frames, device crash (reproduced 3×)
CAM_B + CAM_C (no StereoDepth)	❌ crash
CAM_B + CAM_C + StereoDepth	❌ crash
Same on depthai 3.7.1 (CAM_C mono only)	❌ crash
depthai 2.32.0 CAM_C mono only (MonoCamera node)	✅ 30/30 frames
depthai 2.32.0 full StereoDepth pipeline	✅ 20 depth frames, sane values (median ~0.7 m)

Ruled out before pinning to 2.32.0:

• Power: vcgencmd get_throttled = 0x0 before/after crash; usb_max_current_enable=1; no under-voltage kernel messages.
• USB link speed: crashes identically at SUPER and HIGH (three different cables, two different host ports).
• Calibration: readCalibration() succeeds; EEPROM v7, board DM9095, intrinsics/extrinsics sane.
• Host state: persists across host reboots and full power cycles.

One more data point that may help: the same unit passed a full v3.8.0 StereoDepth test two days earlier (Jul 14), then became deterministically crashing (Jul 16). We also observe the unit negotiates SUPER in only one USB-C plug orientation (the other orientation falls back to HIGH), so a marginal SS lane/contact is possible — but v2.32 drives all three cameras flawlessly under identical conditions, so the v3 firmware turns whatever CAM_C init hiccup it hits into a fatal heap error instead of recovering.

Minimal reproduction (v3 API)

import time
import depthai as dai

device = dai.Device()
print("USB:", device.getUsbSpeed())
with dai.Pipeline(device) as pipeline:
    cam = pipeline.create(dai.node.Camera).build(dai.CameraBoardSocket.CAM_C)
    q = cam.requestOutput((640, 400)).createOutputQueue()
    pipeline.start()
    t0 = time.monotonic(); n = 0
    while time.monotonic() - t0 < 10 and n < 30:
        if q.tryGet() is not None: n += 1
        time.sleep(0.01)
    print("frames:", n)   # 0 on 3.7.1/3.8.0 (device crashes); 30 on CAM_B

Swapping CAM_C → CAM_B makes it pass. The identical test via the 2.x API (MonoCamera node, depthai 2.32.0) passes on CAM_C.

Expected behavior

CAM_C streams like CAM_B, or at minimum the firmware fails gracefully instead of a fatal heap error + device reset.

Attachments

Crash dump attached (from ~/.cache/depthai/crashdumps/, includes crash_reports.json with RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE). More dumps available on request — all 21 are identical.

Setup

• Device: OAK-D Lite AF (RVC2), EEPROM board DM9095, purchased 2026-07-13 (order #26326)
• depthai: 3.8.0 and 3.7.1 (crash) / 2.32.0.0 (works)
• Host: Raspberry Pi 5, Debian 12 (bookworm) arm64, kernel 6.12.93+rpt-rpi-2712, Python 3.11.2
• Connection: direct USB3 (tested SUPER and HIGH, 3 cables, 2 ports — identical result)

[aljazkonec1]

Hi @kadirakkaya,

Sorry for the late reply. We were trying to see if we could replicate your issue with no luck. Could you submit an RMA request on our website and our support team will help you get a new device.

Thanks,
Aljaz