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