IMX500 sensor state machine fails ("failed to load loader firmware") during sustained streaming, despite correct power sequencing

Reproduce the failure with the supplied rpicam-hello command and inspect the imx500 streaming path, especially imx500_transition_to_standby_wo_network and imx500_start_streaming, alongside the videobuf2 warnings. Compare logs across the initial stream and a later firmware reload; done means sustained streaming no longer reaches the loader-firmware failure or leaves buffers active.

Environment

• Board: Raspberry Pi 4 Model B Rev 1.5, 8GB RAM
• Camera: Raspberry Pi AI Camera (IMX500)
• RP2040 bridge firmware: ver. 15 (dmesg: rp2040_gbdg_probe() found dev ID ..., fw ver. 15)
• OS: Raspberry Pi OS
• Kernel: reproduced on both 6.18.39+rpt-rpi-v8 and 6.18.34+rpt-rpi-v8
• rpicam-apps with imx500 post-processing (imx500-all package)

Command used

rpicam-hello -t 0s --post-process-file /usr/share/rpi-camera-assets/imx500_mobilenet_ssd.json --viewfinder-width 1920 --viewfinder-height 1080 --framerate 30

Symptom

After a variable amount of running time (observed anywhere from ~2m30s to ~46 minutes across repeated runs, and ~7 minutes at reduced load of 1280x720@15fps), the stream fails with:

ERROR V4L2 v4l2_videodevice.cpp:1787 /dev/video0[10:cap]: Failed to queue buffer X: Resource temporarily unavailable
ERROR RPISTREAM rpi_stream.cpp:267 Failed to queue buffer for Unicam Image
ERROR: Device timeout detected, attempting a restart!!!

This then loops indefinitely, cycling through buffers 0-3 with the same error.

dmesg at time of failure

unicam fe801000.csi: stream on failed in subdev
imx500 10-001a: DD_REF_STS register did not update
imx500 10-001a: imx500_transition_to_standby_wo_network: failed to load loader firmware
imx500 10-001a: imx500_start_streaming failed to transition from program empty state

Followed by a kernel WARNING/backtrace:

WARNING: CPU: 2 PID: xxxx at drivers/media/common/videobuf2/videobuf2-core.c:2222 __vb2_queue_cancel+0x244/0x2e0 [videobuf2_common]
...
videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state
videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state
videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active state

What has been ruled out

• Cabling (reseated, confirmed good)
• Power supply — vcgencmd get_throttled = 0x0 at time of failure (checked live, in a parallel terminal, at the exact moment the error occurred)
• Thermal — ~56°C at failure, no throttling
• SD card health — no mmc/fs errors in dmesg, plenty of free space
• CMA memory — dtoverlay=vc4-kms-v3d,cma-512, plenty free
• Reinstalling imx500-firmware/imx500-all packages — no change
• Kernel version — downgraded from 6.18.39 to 6.18.34, same failure (~13 min in)
• Load/resolution — reduced to 1280x720@15fps, still failed (~7 min in)
• A full physical power-cycle (unplug 30s+) temporarily clears the issue — a basic rpicam-hello -t 10000 (no post-processing) then runs cleanly — but the failure recurs after resuming the object-detection post-processing pipeline.

This points to the sensor's internal state machine (as flagged by a Raspberry Pi engineer on the forum) failing during a firmware reload cycle mid-stream, not at initial power-up — the RP2040-mediated loader firmware transfer appears to fail specifically during these later reload attempts rather than the very first one.

Raspberry Pi forum thread with the same symptom family: https://forums.raspberrypi.com/viewtopic.php?t=399493

Happy to provide additional logs (full dmesg, rpicam-hello --verbose output, camera-bug-report output) if useful.