We have a custom carrier board with a ADV7280AWBCPZ-M which converts CVBS video into CSI. This CSI is connected to pins 148+150 (D0) and 160+162 (Clk).
We have found that about 50% of the SoMs we have purchased will have this functionality not working. We have ruled out the carrier board being the issue as SoM will behave the same across multiple boards. SoMs are running identical software.
Is there any know fault that may be causing this, or anything ideas of where I could start looking to find a solution?
Verdin iMX8MP Q 4GB WB IT
V1.1A
Ser no: 15006679 works
Ser no: 15006677 does not work
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Good Afternoon, Tom,
The issue you’re experiencing with the Verdin iMX8MP modules and the ADV7280AWBCPZ-M chip showing inconsistent functionality across different SoMs is indeed peculiar. Given that you’ve already ruled out the carrier board as the source of the problem by testing multiple SoMs on the same board, there are a few areas we can explore to troubleshoot this issue:
Power Supply Stability: Ensure that the power supply to both the SoM and the ADV7280 is stable and within the recommended specifications. Power supply fluctuations can cause inconsistent behavior, especially in high-speed interfaces like CSI.
Signal Integrity and Layout: Even though the carrier board has been ruled out, it’s worth reviewing the layout around the CSI interface, particularly the traces from the ADV7280 to the SoM pins. Signal integrity issues can arise from layout problems, leading to inconsistent behavior. Ensure that the differential pairs for D0 and Clk are matched in length and impedance.
Software Configuration: Verify that the software configuration for the CSI interface is consistent across all SoMs. This includes checking the device tree settings for the CSI interface and ensuring that any necessary patches or configurations for the ADV7280 are applied correctly. Differences in software configuration or kernel versions could lead to inconsistent behavior.
Batch Variations: Since you’ve observed this behavior is specific to certain SoMs, it’s possible there may be variations between different production batches. This could be related to slight variations in the SoM components or assembly process. While this is less common, it’s not outside the realm of possibility.
Hardware Revision Differences: Ensure that all SoMs are of the same hardware revision and that there are no subtle differences that could affect the CSI interface’s functionality. Although you’ve specified the SoM model, verifying that there are no revision differences that could impact the interface is crucial.
Electromagnetic Interference (EMI): EMI can cause unpredictable behavior in high-speed digital interfaces. Ensure that there is adequate shielding and grounding in the design to minimize the impact of EMI.
To further diagnose the issue, you could also perform signal integrity measurements on the CSI interface using an oscilloscope or a high-speed digital analyzer. Comparing the signal quality between a working and a non-working SoM could provide insights into the problem.
Given the serial numbers you’ve provided, it might also be helpful to check if there’s any correlation between the serial numbers and the production batches to identify if
Please, also check if these links can help you solve your problem:
Thanks for posting this question!
Do you think you could provide us with some logs (either from the kernel or any error logs from your application) that could help us understand the issue better?
I am also working on this with Tom.
Could you provide details of what logs might be useful? I can get these off of a working and non-working board.
However, all the logs I have looked at and dmesg on both SoMs look the same (except for the inherent timing differences due to multithreaded loading of the kernel).
I am not back in office until Monday now, but if I can have a few ideas of log locations to export and check I can get that done first thing Monday morning.
Hello @izzycoding,
Do you see the CSI camera driver being properly initialized when the camera fails to capture?
Do you use gstreamer for the capture? When you start the capture on the failing modules, are there any error messages?
Hi,
On initial boot I see the csi and everything come up without any issues at all.
Initial tests for this are done via v4l utis where I run:
‘v4l2-ctl -d /dev/video{CVBS-DEVICE-ID} —set-format-video={EXPECTED-FORMAT} —stream-mmap’
This on a working SoM shows that buffers are coming in (with the chevrons being printed).
On a “broken” SoM nothing happens and it just hangs indefinitely.
If I use gstreamer line (too long for me to remember off the top of my head) and set the logging up I can see that it gets stuck at waiting for buffers. But that is all I see.
Regards,
It has been a while since last post on here.
After a lot of debugging and digging deep into the driver code, what we have noticed on the SoMs that fail is that it seems the chip goes into “low power” mode for some reason.
Not sure why this is the case, but we currently have a workaround which resets the device and in our app we issue some ioctl commands to set the power state (but this has to be done after triggering the stream to start processing; both with v42l and gstreamer).
I am wondering if something from another question might help us (although it will be a while before we get back to investigating this further). verdin-imx8mp-adv7281a-m
