It’s time to dig a little further into the root of the problem that is specific to your GMSL device. Up to this point in the blog series, we’ve been discussing simple debugging topics that apply to all GMSL devices in general. Every family of devices provides specific registers associated with the input or output interface to narrow down problems with even finer resolution.
Covering each device is beyond the scope of this post, but I highly recommend digging deeper into the specific parts on GMSLU, ADI’s online catalog of GMSL training videos.
Interface-Specific Errors
Most of the GMSL parts released utilize the MIPI-CSI2 interface. We’ll focus on parts with this interface, like the MAX96717 and MAX96716A, for our examples.
We now know how to check some basics of the GMSL link, such as PCLKDET or VIDEO_LOCK, but how can we take this a step further and examine the configuration of the data coming into the serializer or the data going out of the deserializer? Each device will have a set of registers dedicated to these PHYs that we can leverage.
Let’s focus on a very helpful register in the MAX96716A deserializer (a similar register is available for other MIPI deserializer devices).
MIPI Interface Insights
Imagine a system where the pixel clock is detected and video is locked. Sounds like the system is operational, right? Not entirely; our processor indicates that no video is being received. But if the video is locked in the deserializer, as some bloggers have told us that the video is flowing, why aren’t we seeing it on the processor?
Figure 1: Current Register Status Indicates Data is Flowing in Pipe Y (Green) but Not Leaving the Device’s Physical Layer (Yellow)
The MIPI-CSI2 deserializer devices include an extremely helpful PHY packet counter in the subsection of registers labeled MIPI_PHY. The description of the register even has a helpful reminder to “use for debugging to determine if video data is outputting from the MIPI PHY.”
Figure 2: MIPI_PHY Register Helps to Indicate that Video is Output from the Device
When configuring GMSL, you need to indicate which pipe to connect to which output PHY. The devices will default to a basic configuration, but sometimes an application requires minor modifications. This counter will reflect the physical layer activity of the MIPI transmission to confirm the final leg of travel through the signal chain and out of the deserializer.
In a healthy system, the register that is correctly connected to the pipe will continuously change, and the packets continue to flow through the PHY. In our hypothetical system, this stays unchanged, reading 0x00 indicating that nothing is flowing. Well, there’s our problem. Even though the video pipe has video flowing, the packet counter reflects that nothing is flowing out of the device.
After going through our configuration, we were able to deduce that we had the video pipe connected to the wrong output PHY. We were able to confirm this when checking the packet counter for MIPI port B and saw the register changing continuously. If needed, reviewing the MAX96716A configuration video could help us double-check our routing.
The best part about debugging this specific problem is that we were able to diagnose and address the issue through some simple register reads and without needing to probe our PCB with a scope. These registers become even more beneficial on embedded systems, where we can’t easily access the PCB.
Another helpful example focuses on the serializer to provide some indication on the data fidelity of the data output from the sensor going into the input PHY of the serializer. Sometimes, everything may appear fine from the pattern generator on the serializer, but using data received on the PHY tells another story.
The MAX96717 provides a handful of registers to give insight into bit level errors of the MIPI data stream. MIPI is a high-speed interface where a good PCB layout is mandatory. The GMSL receiving PHY can alert to discrepancies in the bitstream such as sync pattern errors, unrecognized or invalid sequences, and error correcting code (ECC) or cyclic redundancy clock (CRC) issues with the data.
Figure 3: MIPI_RX Register Helps to Indicate Any Issues with the Received Bitstream
Feedback like this, which registers provide, would usually require expensive equipment to decode, but the serializer provides an alternative, non-intrusive way to quickly and easily determine what is going wrong.
Conclusion
The interface-specific registers of GMSL devices, such as the packet counter in the MAX96716A or bitstream status indicators in the MAX96717, are powerful tools for efficient, non-intrusive debugging. They provide critical insights into signal flow and interface configurations, helping you identify and resolve issues with precision.
As we continue this series, we’ll explore more advanced features of SerDes devices that enhance their reliability and performance. Stay tuned for more in-depth explorations into the world of GMSL technology!
See all the blogs in the GMSL Debugging series.