rpicam: IMX283 Camera frontend timeout detected on Raspberry Pi 5

[Dion4cen]

Describe the bug

We are encountering a "Camera frontend has timed out" error when attempting to capture an image using an IMX283 sensor on a Raspberry Pi 5 using rpicam-still.
The application starts, configures the streams (first for preview resolution, then for full capture resolution), but then fails with the frontend timeout error immediately after switching to the high-resolution capture mode. It attempts to restart and fails again. You can find the error logs in the attached screenshot.

Steps to reproduce the behaviour

1. Connect the IMX283 sensor to the Raspberry Pi 5.
2. We found that the timeout error frequently occurs when the viewfinder (preview) resolution is lower than the capture resolution.
3. However, if we set the viewfinder to the sensor's maximum resolution (5472x3648), capturing at any resolution works perfectly.

Here is the command to reproduce the failure (Low Res Preview -> Medium Res Capture):
rpicam-still -t 5000 --viewfiner-width 1824 --viewfinder-height 1216 --width 2736 --height 1824 -o imx283_test.jpg

Below is the matrix of our testing results.
✔ = Success / ✖ = Timeout Error

Preview Resolution	Capture Resolution	Result
1824x1216	1824x1216	✔
	2736x1824	✖
	5472x3648	✖
2736x1824	1824x1216	✔
	2736x1824	✖
	5472x3648	✖
5472x3648	1824x1216	✔
	2736x1824	✔
	5472x3648	✔

Device (s)

Raspberry Pi 5

System

cat /etc/rpi-issue

Raspberry Pi reference 2025-10-01
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7dadcf1fc5ce1648ab09409ab978831690c9a955, stage4

vcgencmd version

2025/05/08 15:13:17
Copyright (c) 2012 Broadcom
version 69471177 (release) (embedded)

uname -a

Linux raspberrypi 6.12.47+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux

Logs

Please see it above

Additional context

We attempted to troubleshoot the issue at the driver level and found a workaround related to Runtime Power Management (Runtime PM).
We observed that setting the autosuspend delay to 0 fixes the timeout error.
Specifically, modifying the driver code as follows:
pm_runtime_set_autosuspend_delay(imx283->dev, 0);
Results after modification:
With this change, we can successfully capture high-resolution images (e.g., 5472x3648) even when the preview is running at a lower resolution (e.g., 1824x1216). The "Camera frontend has timed out" error no longer appears.

Request for advice:
This suggests that the issue might be related to the sensor powering down (or failing to resume correctly) during the brief gap when reconfiguring the stream for the new resolution.
We would appreciate any insights on whether this is a valid fix or if it hides an underlying driver state machine issue.

[6by9]

imx283 is not a sensor we directly provide full support for. A third party upstreamed the driver, and other third parties are making modules.

I suspect that the mode tables don't have a reset at the start, and that one or more set a register to a non-default value, and the other modes don't set it back to the default. Your removing the suspend delay will do a reset on the sensor between each mode.

Could you verify that each mode works in isolation using rpicam-hello -t 0 --viewfinder-mode W:H:12? If so then we can do a diff between the mode tables.

[Dion4cen]

Thanks for the insight. I have followed your request to test each mode in isolation using rpicam-hello.

I can confirm that all three resolutions work perfectly when running independently with rpicam-hello -t 0 --viewfinder-mode <width>:<height>:12.

Here are the specific tests I ran, and all of them were successful (preview displayed normally, no timeouts):

• rpicam-hello -t 0 --viewfinder-mode 1824:1216:12 (OK)
• rpicam-hello -t 0 --viewfinder-mode 2736:1824:12 (OK)
• rpicam-hello -t 0 --viewfinder-mode 5472:3648:12 (OK)

[6by9]

I can't see anything obvious in the driver that would explain why it won't run after a mode switch, unless it is messing up the computation of hblank and vblank ranges, and therefore __v4l2_ctrl_modify_range is failing.
The particularly weird one is that preview at 2736x1824 followed by capture at 2736x1824 fails, at that shouldn't require anything to be recomputed.

Please note that unless the app has been updated, rpicam-still -t 5000 --viewfiner-width 1824 --viewfinder-height 1216 --width 2736 --height 1824 -o imx283_test.jpg does NOT guarantee that the viewfinder sensor mode is 1824x1216 nor capture mode being 2736x1824. Use --viewfinder-mode W:H:12 to explicitly set the viewfinder mode, and --mode W:H:12 to set the capture mode.

Could you log the output of v4l2-ctl --list-ctrls-menu -d /dev/v4l-subdev2 after you've tried
rpicam-still -t 5000 --viewfiner-width 2736 --viewfinder-height 1824 --viewfinder-mode 2736:1824:12 --width 2736 --height 1824 -o --mode 2736:1824:12 imx283_test.jpg
and
rpicam-still -t 5000 --viewfiner-width 2736 --viewfinder-height 1824 --viewfinder-mode 5472:3648:12 --width 2736 --height 1824 -o --mode 2736:1824:12 imx283_test.jpg
(First one you reported as failing, but the second worked).

[Dion4cen]

Thanks for the clarification on the mode flags. I have re-run the tests using the explicit --viewfinder-mode and --mode flags as suggested, while monitoring /dev/v4l-subdev2 status every 2 seconds.

Here are the specific findings based on your request:

1. The Failing Case

Command:

rpicam-still -t 5000 --viewfinder-width 2736 --viewfinder-height 1824 --viewfinder-mode 2736:1824:12 --width 2736 --height 1824 -o --mode 2736:1824:12 imx283_test.jpg

Result:
The operation failed with ERROR RPI pipeline_base.cpp:1346 Camera frontend has timed out!.

v4l2-ctl readings:

• During the Preview phase:
  vertical_blanking: value=2805
  horizontal_blanking: value=720

• During Capture attempt (before timeout):

vertical_blanking: value changed to 2016
horizontal_blanking: value=720

2. The Working Case

Command:

rpicam-still -t 5000 --viewfiner-width 2736 --viewfinder-height 1824 --viewfinder-mode 5472:3648:12 --width 2736 --height 1824 -o --mode 2736:1824:12 imx283_test.jpg

Result:
Success. The image was captured correctly without timeout.

v4l2-ctl readings:

• During the Preview phase:
  vertical_blanking: value=145
  horizontal_blanking: value=1440

• During Capture attempt (before timeout):

vertical_blanking: value changed to 2016
horizontal_blanking: value=720

Additional Observation: Eventual Success after Retries

One more critical detail to add: We noticed that despite the initial timeout errors, the capture eventually succeeds if we allow the application to continue running through the retry loops.

As seen in the logs below, the system triggers multiple "Camera frontend has timed out!" errors and restarts the device multiple times. After a period of these timeouts, the pipeline seemingly stabilises, and the image is saved correctly.

[kbingham]

Interesting - sounds like a bug we've discovered recently - switching from binned 3x3 mode to 2x2 mode (or 1x1 I think) causes some artificial delay and the sensor doesn't stream for 'about 11' seconds - after that it streams normally - but I suspect this would be long enough that the deque timers will fail as we see above.

It would be interesting to know if increasing that timeout to 30 seconds (although not a fix) shows that the camera starts streaming after 'some amount of time'.

[6by9]

If it spontaneously starts working again, I wonder if the sensor isn't always returning to LP-11 immediately on stopping streaming.

CFE wants to see the LP to HS transition on starting up, so missing it would result in no data. Powering the sensor down would trigger it every time.

I don't have a datasheet for imx283 (please ping me a link if there is a publicly leaked one!), but wonder if there is a non-continuous clock option in the register set.

[will127534]

cc will127534/OneInchEye#12