Other Parts Discussed in Thread: LMH1218, LMH1219
主题中讨论的其他器件:LMH1218、
工具/软件:
我们将对一个现有产品进行调试、该产品以菊花链形式连接两个 2 个 LMH1219 和两个 LMH1218。 在某些模块上、我们一直经历 通过链中的第二个 LMH1219 的不经常、零星的视频丢失、这也可以通过某些模块上的加热来实现。 发生这种情况时、某些寄存器(包括 CableEQ/驱动器页面的寄存器 0x7)中的奇数值已 变高、该值变为 0xFF、而不是 0x24。 这是一个保留寄存器、我们不知道该寄存器的功能、但将其设置回 0x24 将导致信号再次传递。 由于这发生在链中的第二个 LMH1219 上并可通过加热来复制、因此怀疑 SPI 菊花链信号的时序。 初始化后、仅在菊花链器件上执行读取(即不应发生写入)。 我们的 SPI 接口使用处理器 GPO 而不是硬件 SPI 接口进行“位拆裂“。 降低 SPI 接口速率可以改善问题、但如果不了解原因、或者随着时间/条件的推移是否仍然存在问题、则可能无法提供可靠的修复。 我们对几个 SPI 信号边沿进行了微调以确保数据表时序、但没有改进。
在查看数据表以了解 SPI 详细信息时、图 19 显示 SS_N 在读取期间的事务中变为活动状态。 但是、相对于 SCLK 或 MOSI、不为该脉冲提供时序。 此外、第 7.4.2.2 节指出“在 N x LMH1219 器件的菊花链配置中、主机在概念上可以看到基本 SPI 事务的长度为 17 x N 的移位寄存器、在此期间、SS_N 在 17 x N 个时钟周期内被置为低电平。“ 在该句子的末尾“在此期间 、SS_N 在 17 x N 个时钟周期内被置为低电平“、将导致 SS_N 实际上不应在事务期间变为活动状态。
目前、软件工程师(属于硬件)已经根据图 19 在事务中实现了 SS_N 脉冲、因为如果没有这个、他们根本无法正常工作。 尽管如此、图中没有显示 脉冲的相对时序、其实现必须是任意的。 是否需要中事务 SS_N 脉冲? 如果是、我们能否收到与 SCK 和 MOSI 相关的时序详细信息? 问题是、该脉冲可能会导致 MISO 在 菊花链中后续器件的 R/W 位期间进入 tri 状态、从而导致第一个器件的一些读取变更为第二个器件的写入。
谢谢、Alex