Skip to content

IMX327 camera mess randomly with libcamera. #4811

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
waveshare opened this issue Jan 6, 2022 · 1 comment
Closed

IMX327 camera mess randomly with libcamera. #4811

waveshare opened this issue Jan 6, 2022 · 1 comment

Comments

@waveshare
Copy link

Describe the bug

Stand the camera on the desktop and check the preview, the preview screen mess up randomly even I do not move the camera.
I have no idea about the problem.

Steps to reproduce the behaviour

  1. Connect OV9281 camera and modify config.txt file:
    camera_auto_detect=0
    dtoverlay=imx290,clock-frequency=37125000
  2. reboot
  3. Preview the camera with the command: libcamera-vid -t 0

Move objects

Device (s)

Raspberry Pi 4 Mod. B

System

OS and version:
Raspberry Pi reference 2021-10-30
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 288b21fc27e128ea6b330777aca68e0061ebf4fe, stage4

firmware version:
Oct 29 2021 10:47:33
Copyright (c) 2012 Broadcom
version b8a114e5a9877e91ca8f26d1a5ce904b2ad3cf13 (clean) (release) (start)

kernel version:
Linux raspberrypi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

Logs

No response

Additional context

A test video is attached for reference.
https://www.youtube.com/watch?v=vo_iYaIBGrw

@6by9
Copy link
Contributor

6by9 commented Jan 6, 2022

That form of corruption is indicative of multi-bit errors on the CSI2 bus resulting in a packet (line) of image data being dropped.
CSI2 can detect and correct single bit errors in any packet, but only detect multi-bit errors - see section 9.5.4 "Applying ECC on RX Side" of the CSI2 spec.
Dropping a line corrupts the Bayer pattern. Red and blue become green, and greens become red and blue, hence things tend to go pink/magenta. A second multi-bit error in the same frame results in a second line being dropped and the colours go back to normal (although the image is now shifted up by 2 lines).

Who is making the image sensor you are using?
I have seen no image corruption issues with either Vision Components IMX290 or IMX327 sensors, nor Inno-maker IMX327.

Unicam does report bit error status values, but they currently aren't logged or accumulated.
In UNICAM_STA:

  • UNICAM_CRCE denotes a CRC failure.
  • UNICAM_SBE is single bit errors (corrected).
  • UNICAM_PBE is parity bit error.
  • UNICAM_HOE is a higher order (ie multiple bit) error.

These correspond to the decode scenarios described in the spec section 9.5.4.

It may be useful to check these bits when UNICAM_STA is read in unicam_isr, and incrementing stats stored in struct unicam_device. unicam_log_status can then dump those out when triggered via v4l2-ctl --log-status or similar.

@6by9 6by9 closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants