本文参考文章:
目录
(一)前言
使用设备:stm32f103c8t6、正点原子lora模块(ATK-MW1278D) 、CH340等
笔者前阵子在调试lora模块时,为了图方便抱着侥幸的心理用了手头一个AMS1117稳压芯片的多电压输出稳压模块(实在懒得焊稳压模块了),AMS1117带载能力比较弱最大输出电流在1A左右,用这个电源模块给两块stm32、两个lora模块(最大功率模式)以及两个oled小屏幕供电,某一次上电时很有可能是由于负载瞬变导致的电流尖峰将AMS1117直接击穿,整个面包板上的所有器件包括稳压模块全部报废π﹏π
![](https://img-blog.csdnimg.cn/direct/544a4e1afe9f4bd38015531b2ba9bfb8.jpeg)
为了防止再次因为电源带来意外稳妥起见我在洞洞板上焊了一个demo测试电路,stm32与lora模块通过串口相连,同时电脑通过CH340接到lora模块串口用于命令调试:
(二)异常现象
问题描述:在一块测试板上使用正点原子的lora上位机调试时发现“发送指令超时”,而另一块测试板上则正常工作。
初步推测可能的原因:其中一块lora模块坏了、洞洞板焊接错误
(三)排查过程
更换lora模块以及排查电路焊接,以及反复交换两个测试板上的器件后发现,上位机能不能与lora模块通信只取决于测试板上的最小系统板是否是具体的那一块(暂定为A),即使是更换新的最小系统板也不能正常工作,所有的最小系统板只有A能正常工作。
这是一个很奇怪的现象,因为这两块测试洞洞板上的电路完全一样,并且目前只是用电脑上位机调试,与单片机的程序没有任何关系,在测试洞洞板上stm32最小系统板对于lora模块仅仅是提供了一个3.3V的逻辑电平引脚让lora模块进入配置模式。
因此问题的关键是在那一块能正常工作的最小系统板与其他的最小系统板之间的区别,首先通过显示屏显示的代码初步判断单片机能否正常工作,发现所有的最小系统板都正常运行。随即把注意力放在了为lora模块提供3.3V电平的引脚,经过测试发现A的逻辑电平仅有2.5V左右而其他的最小系统板输出的都是3.3V。
另外,此时与之前使用面包板调试时不同的是,我在使用面包板调试时仅仅是测试lora模块本身的通信,直接通过两个CH340连接电脑使用上位机调试模块配置以及通信模式,stm32只是安装在了面包板上并没有与lora模块接线(具体可以看前文第一张图片),而测试洞洞板上的stm32与lora模块之间由于焊接的原因所有接线是完整的(包括串口线),于是又用万用表测试了一下引脚状态。
最终经过好一番排查发现,导致异常的原因是在无意中串口的一对多连接,lora模块同时通过CH340串口连接了电脑上位机又连接了stm32的串口,而串口一对多连接时需要使用二极管对通信线进行特殊处理,以消除不同设备之间串口上拉对通信线上信号电平的影响。将stm32的串口关闭后lora模块即可正常与电脑上位机通信,另外只有A这一块最小系统板能正常工作的原因是这块板子坏了,导致引脚的高电平只有2.5V左右,串口上拉能力弱对通信线上的影响相对较小,因此即使A打开串口也不影响CH340工作。具体的情况类似于之前调试CC2530遇到的情况,可以参考我的上一篇博客:CC2530串口通信时由于输出驱动能力弱导致的通信异常
(四)后记
其实我当时在学IIC的时候就在想,不同设备之间通过不同的包头加以区分,串口也能实现一对多通信,之前在参加工训赛时所用的一些设备比如串行总线舵机就是一对多串口通信,这就是后来我才知道的modbus协议。所以我一直默认串口时可以一对多通信的,然而当时不知道这些设备在通信电路上已经做好了特殊设计,才导致这次问题的产生并且困扰了我整整两天时间π﹏π
在负载设备较多情况下调试,供电尽量选择开关电源,LDO提供逻辑电平π﹏π