The fun, unique, and challenging aspect of SerDes devices is that every link is a pair of two chips, which doubles the number of variables to debug, but the device pair together can accurately tell the whole story of the link. When talking about these devices, the serializer transmits the bitstream onto the link, and the deserializer receives that bitstream from the link. In the previous blog post Detecting the Pixel Clock, we were able to detect a pixel clock that indicated something was flowing into the serializer. Today, we will discuss a deserializer equivalent that will indicate that video is flowing through the deserializer with the video lock signal.
Video Lock
Video lock is the indication that the deserializer is receiving a consistent stream of valid video data. After the GMSL link locks, the video locking procedure begins. Once enough valid video data packets have streamed through the deserializer, the video channel is locked and outputs the valid video data from the output PHY.
VIDEO_LOCK
Similar to PCLKDET in the serializer, all GMSL deserializers have another helpful bit that indicates video is streaming. The VIDEO_LOCK bit is asserted when the video channel is… locked. It does not indicate that the data is valid, but it is a simple check to determine if the deserializer is outputting data.
Figure 1: VIDEO_LOCK Bit in the MAX96716A Status Registers
The VIDEO_LOCK bit will quickly tell you if the deserializer is locked and is outputting video from the chip. If VIDEO_LOCK=0, then any potential concern with the processor receiving video is not worth investigating since there is no video output.
Each video pipe of the deserializer will have its own independent VIDEO_LOCK bit to provide additional details for the independent video streams. Each register address of every VIDEO_LOCK bit is indicated at the top left, describing the sequential video pipes. In Figure 1, 0x1FC is the register for pipe Y of the deserializer, and 0x21C is the register for pipe Z of the deserializer. This notation is widely used in GMSL data sheets to indicate that the same register set is being used for similar functional blocks in the device, like video pipes.
Debugging Steps
After confirming that the serializer is receiving some type of video stream with PCLKDET=1, the next quick check is looking at VIDEO_LOCK.
We used camera/sensor EV kits in our last debug, but now we’ll use some display EV kits for the GMSL display parts, MAX96751 and MAX96752, to demonstrate the same debugging techniques using the same register bits from the camera parts. In the following setup, our display panel is getting a very common black screen issue where nothing appears to be outputting.
Figure 2: Example of a Black Screen Display Issue
The first step is to confirm that we’re receiving a video from our Raspberry Pi 4 HDMI source.
Figure 3: Example of PCLKDET=1
This tells us that our source is outputting something, and the serializer has detected the pixel clock. The serializer has already helped us debug half of the link. We now need to confirm that our deserializer is receiving video.
Figure 4: Example of VIDEO_LOCK=0
Aha! The VIDEO_LOCK bit has confirmed that we do not have video flowing through the serializer. Our problem must be with the deserializer.
We can confirm that our lock bit is indicating link lock, and the error bit is indicating no errors in Figure 5, so there must be some configuration discrepancy we overlooked.
Figure 5: GMSL Link Is Locked and Error Free. (We will cover GMSL errors in a future blog post.)
After some exploration of the configuration script, the video stream ID was accidentally changed, causing the deserializer to not receive the video packets at all.
Figure 6: A Simple Configuration Issue Caused the Stream to Not Be Received
A quick fix to configure the deserializer with the correct stream ID now gets our image display without issue.
Figure 7: A Fully Working System with the Image Displayed
Conclusion
We are starting to see how we can use both the serializer and deserializer to help us tell a story as to what may be happening with the link. VIDEO_LOCK is what I consider a companion bit to the PCLKDET bit, helping us efficiently narrow down which side of the link any issue may occur on.
These are basic bits that contain a wealth of information. Start with these two bits for any issue that may arise. Configuration issues may become complex after this, but we have some helpful tools baked into our GMSL parts to help validate connections, like our Video Pattern Generator tool, which we will cover in the next blog. Stay tuned!
See all the blogs in the GMSL Debugging series.