以前用TMS320DM3730做过设计，重新做了一个方案。系统使用TF卡启动。X-Loader和Uboot及Linux内核都正常启动，但文件系统加载的时候总是报无法识别文件系统。
看前面的文件系统分区已经识别到，但加载时就说不支持的文件系统。
查看内核配置，确认是支持的文件系统，而且，相同的TF卡放到原设计平台上就能正常加载……对比了核心系统和TF卡的原理图，没有错误。
后来想到加载文件系统的时候或许读写速度会加快，导致数据错误。加上示波器，的确看在加载文件系统的时候速度提高了几倍，但从信号看数据应当算正常，不至于出错……于是在TF卡附近加了几颗瓷片电容，发现问题依旧。 然后就用笨方法了，从软件入手。查LINUX内核！经过两三天的跟踪，终于发现故障码居然提示“TF卡为只读”。再细看LINUX启动信息，居然在TF卡启动后有一个提示“(RO)”。瞬间木掉了，这两三天跟代码，LINUX启动信息看了N多遍，居然没注意到它……
TF卡可以看成是SD卡的缩小版，但却没有写保护引脚。
因为之前代码是支持SD卡的，所以有一个写保护状态的读取。原先工作正常的设计在这个读取状态的管脚有一段3厘米的PCB走线，连接到一个插座，但插座上的脚是悬空的。而新的方案里去掉了这个插座，同时删掉了这段“悬空线”。然后主芯片在读取这个信号状态的时候就读到两个不同的值。有“悬空线”的板子上认为读保护无效，而新方案里认为读保护有效。把内核里相关代码改一下，文件系统终于正常挂载了！
这个故障的定位过程我做了简写，实际过程更为曲折。3cm的一段PCB线差点导致新方案流产……
现在处理器的速度越来越高，信号电平也越来越低，管脚阻抗也非常高，管脚外连的引线接收到的细小干扰或对管脚负载的改变，都可能导致异常。在处理输入管脚的时候，即便管脚内部有上拉或下拉，也需要格外注意，尽量不要留多余走线，重要输入信号要加上拉或下拉电阻。
友情提示: 此问题已得到解决，问题已经关闭,关闭后问题禁止继续编辑，回答。
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn/data/attach/logo/logo.png', '推荐 zjd1 的问题《3厘米悬空线引发的案件》','https://www.xiaopingtou.net/q-144170.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
一周热门 更多>