使用STM32F767驱动中移F02X5G模块中遇到的一些坑

只看该作者 · 2022-9-30 19:30

出于某种原因，导师要我用stm32F7来驱动5G模块。说实话这真的是吃力不讨好，单片机根本无法利用5G那么快的速度，官方给的程序只有Linux和windows的驱动，其他一点资料都没有。磨了两个月终于给磨出来了，虽然用的是USB Full Speed和速度受限的ppp通信，但好歹成功连上了。这期间遇到的坑实在是太多太多了，在这记录一下。=

模块只支持通过USB传输数据，鼓捣了一段时间确定是使用USB CDC。好在官方有STM32_USB-Host-Device_Lib库，在找不到CDC Host的教程（网上都是Device的）的情况下，只能硬着头皮上去看资料读代码。

使用库里面的例程，先后遇到了许多坑。

只看该作者 · 2022-9-30 19:31

1.获取描述符失败。这很正常，毕竟是厂商定制的模块，而模块的设备描述符我是完全不知道的。好在厂商提供了windows的驱动，最后在windows上使用USBView软件，成功找到了该设备的所有描述符。然后进程序里面的枚举部分USBH_HandleEnum(USB_OTG_CORE_HANDLE *pdev, USBH_HOST *phost)
修改对应的条件判断。

只看该作者 · 2022-9-30 19:32

2.获取linecoding失败。
设备没有返回，直接手动设置波特率等内容。

只看该作者 · 2022-9-30 19:33

3.能够收发AT指令后，ATD*99***1#返回ERROR
对比了linux的收发数据后确定是在lincoding阶段少发送了一个CDC_SET_CONTROL_LINE_STATE_REQUEST
这是对usb模拟串口握手协议支持（RTS/CTS）的设置，少了就不行。

只看该作者 · 2022-9-30 19:33

4.进行LCP握手时从机应答不正确。
这个搞了老久了，最后动用了逻辑分析仪才找到原因。我在程序中显示发送数据的代码（printf）是写在output回调函数中。而发送的数据在这之后到真正发送（CDC_ProcessTransmission）之前被改变了。应该吧printf的代码放在CDC_ProcessTransmission内的USBH_BulkSendData前才能看到正确的发送数据。这里出错的原因是LWIP发送某两个包的时间间隔极短，导致包A被提供到USB线程还未发送完成前，LWIP准备完包B就覆盖了包A。在output时会判断usb发送是否busy，这里就当然busy直接丢弃。但是，由于我在output回调中直接将data指针传入了USB线程，导致LWIP线程准备完B写入data后，一路跟着usb内将发送的数据也被修改了。解决办法很简单，自己建立一个buffer，中间拷贝一下就OK了。

只看该作者 · 2022-9-30 19:34

本帖最后由 yellow555 于 2022-9-30 19:35 编辑

5.LCP握手完毕，接受IPCP报文时只能接受到前五个字节。
这个也是动用逻辑分析仪才找到原因。确认模块发送了完整的数据，但程序只收了前5个字节。原因是USB在接受数据后，会在buff尾加一个0x00，再提供一个buff头的指针，意思就是要我们提取数据直接从buff头指针到0x00为止。
在LCP握手时没有出现问题，因为会对数据进行填充，0x00会被填充成7D 20。而进入IPCP后，LWIP程序会解除这个保护，使得IPCP报文中会出现为0的字节（IPCP报文请求IP时会有0.0.0.0的IP地址，所以绝对会有0）所以我之前的到0为止提取数据就出问题了。
解决办法可以是换一个获取数据的算法（不是到0为止）。
我是直接进USB的接收程序，不只是buff头，把buff尾-buff头的大小，也就是接收到的包长度也一并发了出来，这样就OK了。

后面就没啥大问题了，成功获取IP地址，创建TCP客户端连接TCP服务器，一切正常。接下来就是测试功耗速度等内容了。