单片机和4G模块通信总结（EC20）

偏执的太偏执、 2023-01-21 02:24 48阅读 0赞

第一代数据汇集单元基本开发完毕，运行也有一年了，做下总结吧，希望能够给大家提供帮助。

4G模块选择的是移远的EC20，通过串口和单片机交互。其实是什么型号并不重要，大体的流程

和注意事项基本都一样。

## **[ 《AT指令的一种解析想法》][_AT]** ##

## **[《编程学习笔记之消息地图》][Link 1]** ##

# 一、硬件 #

首先4G模块本身功耗很高，尤其是4G模块刚上电开机瞬间，会有一个大的电流脉冲，这里我们

选择的芯片本身参数符合指标，但是实际使用时候，发现有一些模块损坏问题，现场反馈是后台

没有数据，查问题发现是MCU不断在重启，在查发现是4G模块重启导致MCU复位，再分析是4G

电源貌似处于一种震荡状态。**查看正常4G电源启动波形，发现有一个电流脉冲，电压有个起伏，**

**硬件工程师建议是换取更大电流的IC芯片，我是在软件上把每次连接关闭4G电源流程去掉，减少**

**4G电源冲击，现场设备升级软件测试半年，没有发现问题**。

# 二、软件 #

4G模块本身的AT指令不复杂，我采用消息地图（请看[AT指令的一种解析想法][_AT]）方案。

消息地图：

const static msg_t c_tMSGMap[]  =  {
        {"ATE0\r\n",                lte_4g_protocol_default_send},
        {"ATE0\r\n",                lte_4g_protocol_default_send},
        {"ATE0\r\n",                lte_4g_protocol_default_send},
        {"ATE0\r\n",                lte_4g_protocol_default_send},
        {"AT+CPIN?\r\n",            lte_4g_protocol_CPIN},
        {"AT+CSQ\r\n",              lte_4g_protocol_CSQ},
        {"AT+CREG?\r\n",            lte_4g_protocol_CREG},
        {"AT+CGREG?\r\n",           lte_4g_protocol_CGREG},
        {"AT$MYNETCON",             lte_4g_protocol_MYNETCON},          //设置APN
        {"AT$MYNETCON1",            lte_4g_protocol_MYNETCON1},         //设置用户名和密码
        {"AT$MYNETACT=0,0\r\n",     lte_4g_protocol_MYNETACT},          //去激活
        {"AT$MYNETACT=0,1\r\n",     lte_4g_protocol_default_send},      //激活
        {"AT$MYNETACT?\r\n",        lte_4g_protocol_default_send},      //是否激活成功
        {"AT$MYNETSRV",             lte_4g_protocol_MYNETSRV},          //配置服务器IP和端口号
        {"AT$MYNETCLOSE=0\r\n",     lte_4g_protocol_MYNETCLOSE},        //关闭socket
        {"AT$MYNETOPEN=0\r\n",      lte_4g_protocol_default_send},      //创建socket
    };

## 2.1AT执行逻辑 ##

每个AT指令执行成功，则继续下一条，如果本条AT指令执行失败，则重复执行，最多执行10次，

如果10全部失败，则本轮结束，从第一条指令开始执行，如果5轮全部失败，则重新执行4G模块

硬件初始化流程（电源复位（可跳过），4G模块复位，开机），然后继续执行AT指令；

创建完成socket，则整个流程结束。

## 2.2收发逻辑 ##

**由于4G模块有收和发流程，在进行接收流程时候不能进行发送流程；在进行发送流程时候，不能**

**进行接收流程。否则4G模块不能收和发（实际测试发现此现象）。**

## 2.2.1发送流程 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70][]

历程：（发送流程不可打断）

MCU->4G:AT$MYNETWRITE=0,10 //向0 号Socket 发送10 字节数据

4G->MCU:$MYNETWRITE: 0,10

MCU->4G:123456789

4G->MCU:OK //数据发送成功

注意：发送数据为ASCII码，HEX变成ASCII，长度要增加一倍。

## 2.2.2接收流程 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 1][]

![20210514100624485.png][]

数据到来，主动上报模式：（接收流程不可打断）

![20210514101318381.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 2][]

4G->MCU:$MYURCREAD: 0

MCU->4G:AT$MYNETREAD=0,1460

4G->MCU:$MYNETREAD: 0,10 //有10 字节数据  
1234567890  
OK //接收数据成功

注意：接收数据为ASCII码，ASCII变成HEX，长度要减少一倍。

# 三、问题 #

### 1、现象4G模块不断重启 ###

分析原因，是MCU主动发起4G重启流程，在分析，发现服务器不回复数据，导致登入服务器失败，

但是测试服务器，发现服务器没有问题。把4G断电，重新复现现象，分析Log发现，4G模块在登入

服务器后，一直再往服务器发送数据（下面传感器数据量太频繁），而服务器发给4G模块后，4G

模块并没有报告$MYURCREAD（我自己做的定时read任务也没有起作用，由于一直在发送忙），

导致4G模块接收缓存溢出（模块复位也不起作用），解决方案如下：

（1）和服务器通信改问答模式；

（2）强制定时读取4G模块数据(注意数据溢出，如果处理不好，很大概率会导致4G模块接收溢出)。

### 2、现场传感器全部掉线 ###

运行了三天三夜后，传感器全部掉线。分析LOG，发现4G在不断重启，基站在不停登入服务器，再分析发现基站发送登入帧后，服务器也回复确认帧，但是基站没有解析出来，分析服务器下发报文，也是正确报文。怀疑原因：

（1）栈乱了，为了增加接收缓存，我调小了栈区；

（2）SRAM乱了，里面用的链表，有BUG；

（3）接收机制有BUG,当接收某个字节出错，导致长度出错，一直处于“死等”本帧收完状态，导致不解析。

从LOG分析和代码分析，第三点可能性更大，增加接收数据后，5S没有收到完成帧，则清除buffer机制，测试下看看，有结果再发生来。

程序已经跑了一周了，没有出现这个现象，基本确定就是原因（3）引起的，当时写逻辑代码时候特别注释了这个问题，只是后面测试没有出现。

### 3、客户要求域名登入 ###

现场客户提出域名登入，不提供IP，查看AT手册没有发现域名相关指令，但是手册里面有如下说明：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3][]

其中提到Address需要支持域名，于是进行如下测试：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 4][]

结果：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 5][]

### 4、增加HmacSHA256和 BASE64算法 ###

客户那边是MQTT协议，本来是配置用户名和密码直接登入，考虑到安全问题，需要增加HmacSHA256和 BASE64和算法。具体算法是怎么实现的和算法原理，这里不做介绍，只说应用。

HmacSHA256算法下载地址：[SHA256和HMAC-SHA256的C语言实现\_HMAC-SHA256C-C文档类资源-CSDN下载][SHA256_HMAC-SHA256_C_HMAC-SHA256C-C_-CSDN]

BASE64算法下载地址：[C语言实现Base64编码/解码\_开挂的熊猫-CSDN博客][C_Base64_-CSDN]

经过验证，这两个算法都是没有问题的，这里说下使用注意地方：

1）HmacSHA256算法生成的是32个字节的HEX进制数，如果需要64字节的字符串，需要自己转换下，和算法本身无关，仅仅是生成的信息摘要格式转换；

2）BASE64算法的信息输入是什么格式，需要双方协议，和算法无关；

3）BASE64算法在提供的连接中使用的是malloc动态分配内存，这里根据自己实际使用环境修改，我是自己传入了一个数组地址；

4）BASE64算法在提供的连接中默认输入的是字符串格式，如果是HEX格式，需要做简单的修改。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 6][]

[_AT]: https://blog.csdn.net/wuhenyouyuyouyu/article/details/83010935
[Link 1]: https://blog.csdn.net/wuhenyouyuyouyu/article/details/79347688?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163460352516780357235981%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=163460352516780357235981&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_v2~rank_v29-6-79347688.pc_v2_rank_blog_default&utm_term=%E6%B6%88%E6%81%AF&spm=1018.2226.3001.4450
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70]: /images/20221021/cdbe41bd1ae045ae8f935b8238f38b15.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 1]: /images/20221021/d2ac7e52b6ca4b05b2928fc8efc7d1de.png
[20210514100624485.png]: /images/20221021/d523ecf5f0fa47968fbc16a1fa5db395.png
[20210514101318381.png]: /images/20221021/ea9047f323f842069d4acda9e60d41d3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 2]: /images/20221021/aeb021ed2bde41d485e14eff127fc34c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3]: /images/20221021/72f4667bdd7645f88b6918976d0bf8db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 4]: /images/20221021/06a4da5233474e8599eccc1bd650c7ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 5]: /images/20221021/8143740097b640e0b9b012549c8dcb01.png
[SHA256_HMAC-SHA256_C_HMAC-SHA256C-C_-CSDN]: https://download.csdn.net/download/miniphoenix/13188999
[C_Base64_-CSDN]: https://blog.csdn.net/qq_26093511/article/details/78836087
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 6]: /images/20221021/681594908320461985500aca72de94f2.png