SDIO WIFI模块调试的问题

        上周开始,在我们的AM3358开发板上调试WIFI模块,模块是RTL8189ES。当底层使用CMD53命令读时,会出现CRC校验错误。这个问题的原因是连接SDIO模块的线太长了,把连接线弄短就好了。

        以下内容纯属吐槽,解决问题的话只看上边就可以了。

       刚开始厂商给了一个RTL8189FS的驱动,编译过后怎么都不能正确驱动设备,看驱动里对应的设备号是F179,而我们这个设备出来的设备号是8179。没办法,后来发邮件,让他给重发了一个驱动rtl8189ES的。这个驱动可以识别并驱动设备,但是加载过程中系统就死了,还是有问题。

       我以为系统死了,那就是驱动的问题,于是开始调试驱动。发现RTL8189驱动在调用sd_read32时死了,而这个函数是进入到了SDIO核心层提供的API;想来想去核心层应该不会出什么问题,它也是调用主板上的MMC HOST驱动。

        在MMC HOST驱动的源文件drivers\mmc\host\omap_hsmmc.c中,我加入了很多的打印语句。从这里可以看到系统在死机之前已经给MMC发了很多的指令,只有在发CMD53时才会死机,发送CMD52没有问题。于是查看SDIO的spesification:CMD52命令传数据只用到了CLK和CM两条线,HOST向下发Command和DEVICE的Response数据都是通过CMD线进传的;CMD53命令就不一样了,除了Command和Response是通过CMD线传的,数据是通过DAT[0:3]传的。我又在驱动里加入了打印MMC寄存器状态的代码,MMC的状态有问题,CRC错误,还是数据线上的CRC16错误了。我想是不是因为传输速度太高了,各数据线之间有干扰?于是把时钟从50M改成400k,还是不能解决问题。

        既然是底层的问题那就要用逻辑分析仪了。刚开始把探针接到靠近MMC控制器的一端,抓到数据后发现,DAT0的数据要比DATA[1:3]的数据早半个时钟周周期;再把探针接到靠近WIFI模块的地方,发现四条线上的数据是对齐的,好神奇!找到其中的DAT0,对其数据进行分析,发现CRC校验确实错了,而且总的数据还少了一个起始位。这个WIFI芯片也有好多的厂商在用,不可能这么渣。那会不会是我们飞的线太长了呢?我们飞的这个线有10CM,再加上主板上的线长度,得有15CM还多。于是想到把WIFI模块和主板上的引用用一个更短的线接上了,再次初始化,居然通过了。

      到这时候差点一口老血吐出来,居然是因为飞的线太长了!估计可能是因为SDIO并行传输时干扰太大,或是时钟线太长的延迟问题。

     注意,调试SDIO时,飞线不要太长,可能会出CRC检验错误的,反正我是没有百度到结果。

 

评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值