看到这里是永久等待，应该是串口回调通知的数据到达。
看这样应该是故障导致得唤醒，具体的返回错误是什么，为什么会出故障呢？
这个修改挺好的，可以提交到 RTT 的 github 仓库呀！
2 个回答
经过数据分析及对通信线路进行抓包发现，BC28返回值正常，且通信没问题，而at_device缓冲器用来与关键字对比的数据出现了异常，字符重复以致超出缓冲区长度，内容如下所示
从图片看，右侧BC28返回数据数据始终正常，且已经连接到网络中，但程序运行始终返回失败。
对at_device软件包进行分析，发现通信过程建立了一个at_clnt0线程，且通信接口使用了uart2设备，接收在终端中完成，程序线程及设备列表如下图
推测是at_device从uart2设备缓冲区读取字符时出错，
对程序分析发现，at_device在从串口缓冲区读取字符时，并未对返回值进行判断，而直接将其存入自身的缓冲区，这就导致即使串口没有接收到数据，也会循环读取串口缓冲区中的最后一个字符,如下图
针对此问题我们在at_device从串口取字符时增加返回值判断，修改后程序如下
重新编译下载测试，返回值判断正常，BC28模组驱动正常
撰写答案
请登录后再发布答案，点击登录
我这个是在老版本的rt_thread上移植的，2.0的版本，很多年前的产品了，
在新版本的rt_thread 4.0的框架中测试过，并没有此问题，所以就没往仓库中提交。
估计是新版本修正了这个bug或者是at_device与老版本框架不兼容导致，
毕竟，at_device软件包也是从3.x之后才开始有的
是的，我查看代码发现，除非故障并不会出现这个情况。所以，还是比较在意底层对串口的处理，既然是之前的版本，那可能有些问题。解决了就好 ^-^。