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检验错误的，反正我是没有百度到结果。