Other Parts Discussed in Thread: LMH1218,
Tool/software:
We're debugging an existing product that daisy-chains two 2 pieces of LMH1219 followed by 2 pieces of LMH1218. On some modules, we've been experiencing infrequent, sporadic video loss through the second LMH1219 in the chain, which can also be replicated by heating on some modules. When this occurs, odd values have turned up in some registers, including register 0x7 of the CableEQ/Drivers page, which becomes 0xFF instead of 0x24. This is a Reserved register and we don't know the function of it, but setting it back to 0x24 will cause signal to pass again. Since this occurs at the second LMH1219 in the chain and can be replicated by heating, timing of SPI daisy-chain signals is suspect. Only reads are performed on daisy-chained devices following initialization (i.e., no writes should be occurring). Our SPI interface is "bit-banged" using processor GPO instead of a hardware SPI interface. Slowing the SPI interface rate can improve the issue but may not provide a solid fix without understanding why, or whether it might still occur over time/conditions. Several SPI signal edges have been nudged around to ensure data sheet timing, but without improvement.
While reviewing the data sheet for SPI details, Figure 19 shows SS_N going active mid-transaction during read. However, no timing is given for this pulse relative to SCLK or MOSI. Also, section 7.4.2.2 indicates "In a daisy-chain configuration of N x LMH1219devices, the host conceptually sees a shift register of length 17 x N for a basic SPI transaction, during which SS_N is asserted low for 17 x N clock cycles." The end of that sentence, "during which SS_N is asserted low for 17 x N clock cycles," would entail that SS_N should actually not go active during the transaction.
Currently, the software engineer (I'm hardware) has implemented the SS_N pulses mid-transaction according to Figure 19, since they didn't find it working at all without this. Albeit, the diagram shows no relative timing for the pulse and their implementation must be arbitrary. Are mid-transaction SS_N pulses required? If so, can we please receive timing details relative to SCK and MOSI? A concern is that the pulse may be causing MISO to go tri-state during the R/W bit at the subsequent device in the daisy-chain, causing some reads of the first device to morph into writes of the second device.
Thanks, Alex
