rpicam: IMX283 Camera frontend timeout detected on Raspberry Pi 5
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- c, linux, raspberry-pi
- Domain
- embedded-iot, operating-systems
Research direction
Start with the IMX283 driver and the runtime power-management change using pm_runtime_set_autosuspend_delay(imx283->dev, 0), then reproduce with the provided rpicam-still command and resolution matrix. Done means determining whether the timeout is caused by the sensor failing to resume during reconfiguration and validating a fix across the listed preview and capture resolutions.
Written by the indexing model from the issue text.
Description
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
- Connect the IMX283 sensor to the Raspberry Pi 5.
- We found that the timeout error frequently occurs when the viewfinder (preview) resolution is lower than the capture resolution.
- 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.
- Dominant language
- C
- Stars
- 13.2k
- Forks
- 5.5k
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 21
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from raspberrypi/linux
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
raspberrypi/linux#7415 · 2 comments · 1 reaction ·
-
rp1-cfe doesn't forward V4L2_EVENT_SOURCE_CHANGE event from csi-2 sensor driver to userspace app Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
raspberrypi/linux#7399 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
raspberrypi/linux#7357 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
raspberrypi/linux#7054 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
raspberrypi/linux#7634 · 8 comments · 1 reaction ·
All issues in raspberrypi/linux
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zephyrproject-rtos/zephyr#119726 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BasedHardware/omi#15320 ·
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·