3厘米悬空线引发的案件

coco

以前用TMS320DM3730做过设计，重新做了一个方案。系统使用TF卡启动。X-Loader和Uboot及Linux内核都正常启动，但文件系统加载的时候总是报无法识别文件系统。
        看前面的文件系统分区已经识别到，但加载时就说不支持的文件系统。
        查看内核配置，确认是支持的文件系统，而且，相同的TF卡放到原设计平台上就能正常加载……对比了核心系统和TF卡的原理图，没有错误。
        后来想到加载文件系统的时候或许读写速度会加快，导致数据错误。加上示波器，的确看在加载文件系统的时候速度提高了几倍，但从信号看数据应当算正常，不至于出错……于是在TF卡附近加了几颗瓷片电容，发现问题依旧。
        然后就用笨方法了，从软件入手。查LINUX内核！经过两三天的跟踪，终于发现故障码居然提示“TF卡为只读”。再细看LINUX启动信息，居然在TF卡启动后有一个提示“(RO)”。瞬间木掉了，这两三天跟代码，LINUX启动信息看了N多遍，居然没注意到它……
        TF卡可以看成是SD卡的缩小版，但却没有写保护引脚。
        因为之前代码是支持SD卡的，所以有一个写保护状态的读取。原先工作正常的设计在这个读取状态的管脚有一段3厘米的PCB走线，连接到一个插座，但插座上的脚是悬空的。而新的方案里去掉了这个插座，同时删掉了这段“悬空线”。然后主芯片在读取这个信号状态的时候就读到两个不同的值。有“悬空线”的板子上认为读保护无效，而新方案里认为读保护有效。把内核里相关代码改一下，文件系统终于正常挂载了！
        这个故障的定位过程我做了简写，实际过程更为曲折。3cm的一段PCB线差点导致新方案流产……
        现在处理器的速度越来越高，信号电平也越来越低，管脚阻抗也非常高，管脚外连的引线接收到的细小干扰或对管脚负载的改变，都可能导致异常。在处理输入管脚的时候，即便管脚内部有上拉或下拉，也需要格外注意，尽量不要留多余走线，重要输入信号要加上拉或下拉电阻。