Subscribe, Like, Rate...

Products Mentioned

MAX96716A Production
The MAX96716A converts dual GMSL2 serial inputs to MIPI CSI-2. It also transmits and receives control-channel data, enabling transmission of forward-path...
Datasheet
MAX96716A on Analog.com

MAX96724 Recommended for New Designs
The MAX96724/F/R deserializer converts four GMSLâ„¢2/1 inputs to 1, 2, or 4 MIPI D-PHY or C-PHY outputs. The device allows simultaneous transmit bidirectional...
Datasheet
MAX96724 on Analog.com

EZ Spotlight Topics
A padlock on a circuit board, featuring a keyhole, symbolizes security in technology.

GMSL Debugging: Getting a Lock

tombrady
8 minute read time.

Imagine a scenario where you have a brand-new board design or are excited to try out some evaluation kits only to find out that the two devices can’t talk with each other. This will cause some debugging time and frustration when bringing up a gigabit multimedia serial link (GMSL). GMSL is a robust technology used in modern systems, enabling high-speed, low latency data transmission in a wide range of harsh environmental applications like automotive, industrial, digital healthcare, aerospace, and many more. A systematic approach to debugging GMSL link lock is essential. This guide aims to provide you with the insights and tools needed to achieve and troubleshoot link lock effectively, ensuring reliable and seamless data transmission.

GMSL is ADI’s SerDes link technology. SerDes is a portmanteau of a SERializer and DESerializer and from the name you can infer that there are two devices connected to each other to create a serial link.

This poses a unique challenge when debugging a serial link because rather than looking at a single chip, you must consider the system as a whole. Additionally, the channel that connects these two devices will be part of the equation when we start to narrow down where an issue may occur.

GMSL Link LOCK

For both camera and display GMSL devices, the most fundamental functional check in any GMSL system is achieving link lock. This is indicated by the LOCK LED on the GMSL EV kits or by the LOCKED bit available in the registers.

Field Monitoring and Maintenance of Functional Safety The ISO 26262 Functional Safety standard not only governs the development phase but also mandates ongoing maintenance after a product is released to production. While ASIL compliance is typically verified at the end of development, manufacturers are also responsible for monitoring products in the field. This includes evaluating any safety implications that may arise from customer returns or failures observed during real-world operation. The added value of the field monitoring is at least in two areas: Safety Aanomalies First, we need to verify that returned parts show no potential safety anomalies. This is an essential step in validating our safety concepts on real-world applications. If anomalies are found, corrective actions must be taken. Based on feedback provided to the development team, updates to the original safety case—specifically, the product's FMEDA and risk analysis—must be made. Lessons Llearned Second, returned parts provide valuable insights and lessons learned for a specific product or product category. As part of the 8D problem resolution process, these lessons must drive preventive measures to avoid future failures. Corrective actions taken for a specific product are documented in the DFMEA and serve as references for future designs. To complete the feedback loop, any new failure modes or corrective actions are transferred to our internal databases. This ensures that updated DFMEA templates automatically incorporate these insights into future product development. Closing the loop with efficient field monitoring processes Figure 1 (below) shows the relevant items for closing the loop and supporting a process for continuous improvement. The main steps of the field monitoring process are: Analyze all automotive 8D reports in a specific period of time with respect to their root causes and document their status with respect to observed failure modes, effects at the application level, and root causes associated with components within the IC. Additionally, classify the associated report by its main root cause categories like “IC Production (Fab)”, “Test Coverage”, “Design” or “Assembly”. Conclusions may be drawn by a dedicated peer review. If corrective actions are required to address failures in areas such as design or test coverage, the corresponding preventive measures must be documented in the risk analysis, specifically in the DFMEA (Design FMEA). For fault types related to IC production or assembly, the PFMEA (Process FMEA) must be reviewed to ensure it includes preventive or detection measures for future occurrences. This step is not unique to Functional Safety—it is a standard part of quality management and aligns with international standards like IATF 16949. In the third step, we evaluate the impact of the observed symptom with respect to the product-specific safety goals. This involves verifying whether the failure mode is already addressed by the existing safety concept and whether a dedicated safety mechanism is in place to detect or mitigate it. Evidence for this is typically gathered through bench evaluation during the failure analysis. If the failure mode is effectively covered by a safety mechanism or if it naturally leads the system to a safe state, it is not classified as a safety anomaly. A team of experts— typically functional safety managers—summarizes the evaluation results and creates a conclusion that is documented in the relevant database or 8D systems. Diagram 3, SmartArt diagram Figure 1: Closing the loop using Field Monitoring Field monitoring processes supporting lessons learned The data extracted from the field monitoring process contains a lot of valuable additional information that can be used for new projects. Any new set of potential failure modes or additional preventive/detective measures can be collected and transferred back to the corresponding risk analysis tools. Items relevant to a DFMEA (Design FMEA) would lead to an update of the associated DFMEA templates supported by our DFMEA tools and lead to a new revision of the template. Users can be automatically informed about template updates, and new projects will always be started from the newest version, considering all relevant information extracted from field data. The same applies to any items pertinent to the FMEDA that could result in an update of the related components within the component reuse libraries. The efficient implementation of the field monitoring process is not only a formal requirement of ISO26262 but also adds significant value by identifying risks related to field returns and closing potential gaps. Additionally, it serves as a valid source of lessons learned.

Figure 1: Location of the “LOCK” LED on the Evaluation Kits

Link lock, often referred to as LOCK, indicates that the GMSL PHYs can communicate effectively. This status confirms that both data paths—the forward channel (deserializer receive path) and the reverse channel (serializer receive path)—are properly synchronized.

Figure 2: Asymmetric, Full Duplex Data Directions

Figure 2: Asymmetric, Full Duplex Data Directions

Once link lock is established, both video transmission and control channel functionality become immediately available. For monitoring link lock status, each GMSL serializer and deserializer features a dedicated LOCK pin that provides a hardware-level indication of the lock status.

Additionally, this status can be verified through register access as seen in Figure 3.

Figure 3: MAX96716A Register for Link A LOCKED Bit

Figure 3: MAX96716A Register for Link A LOCKED Bit

On multiple input devices, like the Another example is the MAX96724, in which the LOCK pin will only assert when all enabled links are locked. If not using all links, disable the unused links to correctly acquire LOCK. In these cases, the LOCK pin will only assert when all the links are locked to indicate that the system is behaving as designed.

While the lock status is reflected on both ends of the link, monitoring the end connected to the main processor is typically sufficient. For camera systems, monitor the LOCK pin on the deserializer. For display systems, monitor the LOCK pin on the serializer.

Debugging Steps

If your system boots up without achieving link lock, it points to a fundamental configuration or connection problem. Here’s a checklist for troubleshooting link lock issues to identify and resolve the issue:

  • Verify external connections by checking all physical connections to the GMSL device, ensuring they are secure and correctly aligned.
  • Inspect the GMSL link connections by confirming the positive and negative terminals of the GMSL link are properly connected.
    • Common issues include incorrect schematic symbols or misconfigured shielded twisted pair cables.
    • If needed, use a multimeter for a quick check to verify pin-to-pin continuity and proper cable connections.
  • Confirm power supply integrity by ensuring all power supplies are within regulation and meeting the required voltage levels for the GMSL chips.
  • Validate configuration pin settings by verifying that the device is booting into the correct configuration by checking the CFG pin settings.
    • Common issues include incorrect VDDIO voltages applied to the CFG pin divider or external connections causing noise or errant voltages on the CFG pin during boot-up.
    • If one side boots up in 3 Gbps mode and the other boots in 6 Gbps mode, the parts will not be able to lock.
    • On parts that support tunnel mode, it is also important to ensure both ends of the link boot up in the same mode whether it’s pixel or tunnel mode. A mismatch would cause data corruption.
  • When using an external crystal, check the crystal oscillator by confirming it is operating at 25 MHz and producing a clean clock signal.
  • Verify active and inactive links by ensuring that inactive links are disabled in the configuration.

  • Review device errata by checking the device revision in register 0x0E and consulting the corresponding errata documentation for any additional changes that may be required.
    • The errata documentation can be obtained from the product pages on analog.com, such as the MAX96724 errata sheet.

If all the above checks pass and lock is still not achieved, signal integrity issues may be at play. Investigate potential problems in the physical setup, such as cable quality or electromagnetic interference. If possible, attempt to communicate with both sides of the link independently to confirm that each side is functioning properly.

By systematically addressing each of these areas, you can isolate and resolve link lock issues in your GMSL system, ensuring reliable communication and system functionality.

Conclusion

Achieving and maintaining link lock in a GMSL system is an essential first step for ensuring the lines of communication between your serializer and deserializer devices. From incorrect schematic symbols to misconfigured cables, and even mismatched boot modes or signal integrity issues, a host of common pitfalls can throw a wrench into the works. But fear not! By following the steps outlined above, you can confidently establish a stable GMSL link. In the end, knowing how to achieve and monitor link lock will provide you with the first step of establishing a reliable insight into your GMSL system.

Once the link is established, we’ll investigate how to detect a pixel clock into the serializer to confirm that data is flowing. Stay tuned!

See all the blogs in the GMSL Debugging series.

Enjoy this topic, test your knowledge, and be entered to win a $25 gift card. Click here.

Tags: GMSL Debugging MAX96724 Wireless Communication Solutions MAX96716A interface and isolation Show More