目录
1、背景
外设有裕太YT8512/8521 phy芯片、4G模块EC20芯片、仁珏lora 470和2.4G模块....
2、以太网调试
网口调试需要学会使用命令ethtool和mii-tool:
linux 网络命令 mii-tool 和 ethtool 使用_老王不让用的博客-CSDN博客_linux查看网卡速度
mii-tool常用命令:
1) 查看网络接口的协商状态
mii-tool -v eth0
2) 设置网络接口为1000Mb/s全双工模式
mii-tool -F 100baseTx-FD
mii-tool -v eth0
3) 回复网卡的自适应工作模式
mii-tool -r eth0
ethtool常用命令:
1) 查看机器上网卡的速度
ethtool eth0
2) 停止网卡的发送模块TX
ethtool -A tx off eth0
3) 查看网卡eth0采用了何种驱动
ethtool -i eth0
4) 关闭网卡对收包的校验功能
ethtool -K eth0 rx off
5) 将千兆网卡的速度降为百兆
ethtool -s eth0 speed 100
6) 查看网卡,在接收/发送数据时,是否正常,统计对应信息
ethtool -s eth0
(1)裕太YT8512
板子一开始处于单机状态,唯一和外界通信的是调试串口。调试的首要目标是要么能传东西到板子中,要么板子能联网下东西。前者要求网口能通(网线连电脑),后者要求4G模块能通。当然,将网口接到能联网的路由器上就一步到位了。
第一步:uboot自动识别板子上有多少个网口,ifconfig便生成多少个网卡,如eth0、eth1等等。其实我也不清楚哪个网卡名对应哪个网口。那么都试试吧。给某个网卡配置了ip之后,看能不能ping通。不通是吗,换一个网卡名试试。
第二步:如果所有网卡名都试过了全不通,那么敲dmesg看看网卡名生成的log,有没有error报错
第三步:如果没有error,
(2)YT8521
这是千兆以太网芯片。调试时,确保网线另一端(PC端)网口支持千兆,网线建议使用CAT6.
如果系统自动识别网卡时百兆,那么把pc端的网卡speed设置为1G,而不是自动协商auto,同样的,关闭板载网卡的自动协商功能,设置速度为千兆:
ethtool -s eth0 autoeg off
ethtool -s eth0 speed 1000
在我的801环境中,一开始千兆link为百兆,然后换了6类网线,并且PC端外接更加新的网口之后,千兆link显示为OK,此时pc端和板子端网口均为自动协商模式。
3、EC20芯片
AT命令:
ati
AT+CPIN? ----+CPIN: READY
AT+COPS? ----+COPS: 0,0,"CHN-UNICOM",7
at+qeng="servingcell" ---+QENG: "servingcell","NOCONN","LTE","FDD",460,01,59C5223,435,1650,3,5,5,510E,-67,-5,-41,30,60
在一块板子上ppp能通,可是将系统的内核镜像(这里只选了PPP,其他和ppp相关的配置没有选中)、相同的原始文件系统烧到另一块板子上,ppp报错:
Couldn't set tty to PPP discipline: Invalid argument
网上的解决方案是内核配置增加ppp,可是我的/dev目录下有ppp,内核也配置了ppp。说明内核配置了ppp。后来把第一块板子的文件系统导出,烧录到第二块上,结果奇迹般得ppp拨号成功了!我也是醉了。
我建议把所有和ppp相关的配置都选中,如下图所示:
虽然我建议如此,但是我依然认为上述报错和ppp的相关配置没有关系。
4、仁珏lora模块
我们手上有3种模块:TS-47S、TS-47A、TS-24A。TS-47S和TS-47A都是470MHz的模块,TS-24A是2.4G的。每个模块的AT命令有差别(这里只贴出查询类命令):
TS-47S:
AT+MCFG?\r\n +MCFG=0,0,70,1,0,30,0,0,0,101
AT+MSTAT?\r\n +MSTAT=0,0,0,0,0
AT+MID?\r\n +MID=000000000001,1
TS-47A:
AT+MCFG? \r\n
TS-24A:
AT+MCFG? \r\n +MCFG=1,0,0,60000,10,0,5,1,1,150,150,60318
AT+NLIST?\r\n +NLIST=000128200001,74
AT+NCFG?000000000001\r\n 000000000001是入网设备ID +NCFG=000000000001,0,0,0,0,0,0,0,0,0,1
AT+WLIST?\r\n
AT+BLIST?\r\n
AT+RST= DD\r\n
busy microcom和minicom是linux的串口调试工具,如果通过它们无法向某个UART口发送AT指令,那么从以下几个方面排查:
(1)看看设置的串口波特率对不对,只有和模块一致的波特率,AT的操作和回显才是对的。
(2)cpu的UART口能用吗?
minicom打开串口,发送任意字符串,用示波器测其TX对地有没有波形输出,有则表示cpu的uart口可用。至于波形是否正确需要后续仔细分析;
(3)lora模块坏了吗?
如果担心cpu接lora模块的中间电路对定位结果有影响,有两个方向可以探索:
一是先将lora对外电路断开,引出其TX RX VDD和GND,通过TTL转USB模块,接到pc电脑上,用windows的串口调试助手,往该串口上发AT指令。
如果没有回显或者有乱码,再用示波器测试pc发给模块的TX引脚的波形,如果有,再测RX的波形。
二是lora模块有reset引脚,用金属物手动触发模块复位,看看模块的TX有没有波形输出。
上述方法基本定位lora模块是否正常。
(3)如果前三个方向都没出现问题。
那么看看模块和cpu间的电路有没有问题。这个电路很简单一般不会出错。
如果是还没发现问题,可能和时序和波形有关了,要分析具体的输出波形了:通过电压的高低电平读出具体的01值,再结合波特率,看看和实际的AT命令字符是否一致。
5、研恳的蓝牙模块
背景介绍:
型号是YK71BMLE(S)。他家的资料很简陋。也是因为模块比较简单,它默认使用透传模式。用通用的蓝牙调试助手app便能调试。安卓手机使用BLE调试助手,苹果手机使用Lightblue。
该型号默认使用的write和notify的uuid通道分别是:以e34729bb3结尾是write信道,以4bd9-ba61-23c647249616结尾的是接收信道。
基本原理:
透传模式即“所写即所得”,你写什么出去,另一端就得到什么样的数据。
CPU写流程:
cpu write UART------>蓝牙模块-------->手机app notify
手机通过23c647249616信道实时看到来自蓝牙模块的数据。
手机app写流程:
手机app write-------->蓝牙模块---------->cpu read UART
手机通过e34729bb3信道随时写数据给蓝牙模块。
调试思路:
因为我的蓝牙模块在通信小板上,插在底板上,我可以把通信小板拔下来,单独测试蓝牙模块的好坏,所以我的思路是:
1、先测试蓝牙模块的好坏
将上述流程中的“cpu read UART”改为pc机的串口调试助手,排查cpu自己的问题。
2、再测试cpu uart口的好坏
将cpu那个UART口的rx和tx短接,在cpu上(ubunntu系统)用minicom或者busybox microcom工具操作串口,看看能否自发自收。
3、最后放一起测试
小通信板接到底板上,发现不通。不管是app写数据、cpu读,还是cpu写数据、app读,均没有反馈。
后来发现,原来蓝牙模块的reset引脚接在cpu的某个GPIO口上,而该GPIO上电便一直是低电平,蓝牙芯片一直处于复位状态,自然不能工作。
所以,在调试软件之前,请先确认硬件上disable reset这些引脚是什么状态,这个很重要!
6、大普 RTC-ins5699s
调试过程请看调试大普RTC芯片驱动-ins5699s_汉尼拔勇闯天涯的博客-CSDN博客
注意点:i2c 数据脚和时钟脚要接4.7K的上拉电阻。
i2ctools常用命令总结:
./i2cdetect -l :查看当前设备使能了那些i2c总线
./i2cdetect -r -y 0 :扫描i2c0总线上所有地址,查看地址上的设备有无回应。
./i2cset -f -y 1 0x20 0x77 0x3f :设置i2c-1上0x20器件的0x77寄存器值为0x3f
./i2cget -f -y 1 0x20 0x77 :读取i2c-1上0x20器件的0x77寄存器值
./i2cdump -f -y -a 1 0x38 :读取i2c1上0x38器件的所有寄存器
7、SPI WK2124 串口扩展芯片
详细的调试过程见我的博客:
记住spi从设备的接线方式:
一根总线接一个从设备:
注意master的MO接slave的SI,MI接SO。
接多个从设备:
图中的SS1 SS2 SS3都是片选引脚。
在常规模式下,主机需要为每个从机提供单独的片选信号。
一个简单的增加片选的方法是使用GPIO来模拟SPI_CSn信号,在每传输一个数据之前,将相应的GPIO置低(假设从设备片选信号为低有效),选中对应的SPI从设备,传输结束后再将GPIO置高。
注意:如果你的从设备是飞线方式接入总线上的,注意从设备的频率。飞线影响数据通信,可能导致驱动加载失败,或者数据交互时好时坏。请在驱动源码中降低频率,也许就正常了。