SDIO WIFI模块调试的问题
来源:互联网 发布:二叉树的结点算法公式 编辑:程序博客网 时间:2024/06/04 19:49
上周开始,在我们的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检验错误的,反正我是没有百度到结果。
- SDIO WIFI模块调试的问题
- SDIO WiFi模块分析
- s3c2440 + wince5.0 + sdio接口wifi 8686的调试记录
- SDIO 接口的wifi驱动
- s5p4418-sdio接口的wifi模块驱动及往android层的延伸
- 二 关于s5p4418 无线wifi模块出现SDIO读写错误的解决方法
- 6085下调试SDIO的问题(完)
- S3C6410硬件模块分析 -- SDIO WiFi模块分析
- SDIO WIFI
- SDIO WIFI
- 【写的很给力呀】将wifi固件编译进内核,成功加载sdio wifi模块
- WiFi驱动(4)SDIO驱动SDIO卡的扫描
- WinCE下WIFI模块AR6102的调试
- mt7061 wifi模块调试
- Real6410 Android 2.1 的 SDIO WiFi
- 基于FS2410的SDIO WIFI移植
- 基于FS2410的SDIO WIFI驱动移植
- Linux SDIO WIFI驱动的编译
- html设置背景音乐
- No data
- Anaconda使用总结
- 成熟敏捷组织中管理者的角色是咋样的?
- 数据库选型:多核还是多线程?
- SDIO WIFI模块调试的问题
- Android 项目之飞机大战
- Java学习之线程安全详解(卖票案例)
- java final 关键字的使用
- 记一些常用的Git命令
- 【UR #10】汉诺塔 题解
- 什么是WebView?
- QTP应用实例-G.8032测试自动化(2)拓扑搭建
- vi如何删除到文档开头(首行)