onenet基础通信套件返回+CIS ERROR: 50的问题解决

1. 场景分析，主要问题就是有些操作返回+CIS ERROR: 50

2. 看了一下在AT+MIPLOBSERVERSP这个指令里面是没有返回+CIS ERROR: 50的错误类型的，所以应该是在解析这个AT指令之前出现的，那么为啥会出现，猜测一，模块进入睡眠，唤醒之后第一个串口字符丢失，但是用自己的板子测试，这个概率并不高，客户测试几乎100%出现，猜测二，就是外部MCU进入睡眠之后改变RX的电平，所以接收数据多了一个上升沿或者下降沿，还有就是AT+MIPLNOTIFY的时候出现的，暂时没发现下面的指令有什么区别。

3. 在app_at.h里面出现50错误的有三种情况，我觉的有必要进一步区分这三种情况，所以进行了修改，其中有一个问题需要注意，如果没有这个AT指令的话，那么回复的就是50错误，我猜测下面AT_RET_NOT_NUMERIC的意思就是找不到AT指令，不过好像是不是数字的意思。下面第3个是语法错误

    {AT_RET_NOT_NUMERIC, },     //Incorrect parameters
    {AT_RET_PARAM_MISSING, },   //Incorrect parameters
    {AT_RET_SYNTAX_ERROR, },    //Incorrect parameters

修改完之后测试一下，首先是非数字看是否能测试到，首先是字符问题

[::44.372]发→◇AT+CGSN=
□
[::44.386]收←◆
+CGSN:

OK

[::48.004]发→◇AT+CGSN=A
□
[::48.016]收←◆
[::48.068]收←◆
+CIS ERROR: 

然后是

[::58.380]发→◇AT+CGS2N=
□
[::58.393]收←◆
+CIS ERROR: 

继续测试，所以目前猜测，之前的错误很有可能就是这个53，语法错误

[::33.091]发→◇AT+MIPLOP
□
[::33.103]收←◆
+CIS ERROR: 

[::36.709]发→◇AT+MIPLOP1EN=,
□
[::36.730]收←◆
+CIS ERROR: 

3. 目前唯一新添加的就是低功耗，难道和低功耗有关？会不会是上一次的指令没执行完，低功耗之后继续执行，然后此时又来了一条AT指令？正成的测试，发现注册会失败，只能到连接成功，都是注册成功的一直没下发下来。难道是保存参数的数组不够11个？现在很有可能是AT指令没查找到，估计那个字符出错了，验证一下NOTIFY还没完成的时候，继续下一条NOTIFY。接下来使用SecureCRT软件，测试更高的波特率，看是回复什么？之前用STM32的时候用内部晶振，9600波特率是有问题的。不过波特率有偏差的话，那么为啥只有第5条NOTIFY才有问题？所以当时屏蔽了这个想法.

4. 有可能存在一种情况，在进入PSM之后，波特率的容限率低了很多。等待进入PSM模式，PSM模式，串口应该也是休眠状态，目前猜测53应该就是之前的50。据说，STM32使用内部LSI时钟作为串口9600波特率时钟源，那么在温度高和低的时候，波特率差别很大，目前猜测是这个问题，但是好好的温度怎么上升了？难道芯片运行一段时间之后，消耗电量温度上升？

5. 看下下面的例程，我感觉就是有的时候，模组唤醒之后，第一条指令不能正确识别，应该是海思SDK的底层问题。

6. 产生了一个问题，比如超时时间是1个小时，那么1个小时到之前必须更新注册。如果在1个小时到之前NOTIFY的话，不算更新注册。

7. 下面一个问题，写资源、写实例和预期回复不一样。看下图实际回复

预期回复

8. 观察资源和预期回复不一样，取消观察资源没测。

代码写错误

sprintf(rsp_string, "+MIPLOBSERVE:%d,%d,%d,%d,%d,%d", ref_id, msgid, observe_flag, oid, 
CIS_URI_IS_SET_INSTANCE(&node->uri)?node->uri.instanceId:-,CIS_URI_IS_SET_RESOURCE(&node->uri)?node->uri.resourceId:-);

//早先错误的写法
sprintf(rsp_string, "+MIPLOBSERVE:%d,%d,%d,%d,%d,%d", ref_id, msgid, observe_flag, oid, 
CIS_URI_IS_SET_INSTANCE(&node->uri)?node->uri.instanceId:-,CIS_URI_IS_SET_RESOURCE(&node->uri)?node->uri.instanceId:-);

16. 任务阻塞失败？

TaskHandle_t udp_recv_task_handle  = NULL;
xTaskCreate( callbackRecvThread, "onenet_udp_recv", , (void *)ctx, TASK_PRIORITY_ONENET, &udp_recv_task_handle );
vTaskSuspend(udp_recv_task_handle);

难道是第一的notify其实还没有开启UDP的接口和发送部分，不是的。任务名字太长？

#define configMAX_TASK_NAME_LEN                 10 

顺便发现了FreeRTOS可裁剪的配置FreeRTOSConfig.h

#define configUSE_NEWLIB_REENTRANT              0               // Not adding a feature packed c library
//#define configMINIMAL_STACK_SIZE                128           <- Moved to platform specific configuration
#define configMAX_PRIORITIES                    10              // This sizes an array so should be kept small.
#define configUSE_PREEMPTION                    1
#define configUSE_IDLE_HOOK                     1
#define configUSE_TICK_HOOK                     0
#define configUSE_16_BIT_TICKS                  0
#define configUSE_CO_ROUTINES                   0

#define INCLUDE_vTaskPrioritySet                1
#define INCLUDE_uxTaskPriorityGet               1
#define INCLUDE_vTaskDelete                     1
#define INCLUDE_vTaskSuspend                    1
#define INCLUDE_vTaskDelayUntil                 1
#define INCLUDE_vTaskDelay                      1
#define INCLUDE_xTaskGetIdleTaskHandle          0
#define INCLUDE_xTaskAbortDelay                 0
#define INCLUDE_xQueueGetMutexHolder            0
#define INCLUDE_xSemaphoreGetMutexHolder        1
#define INCLUDE_xTaskGetHandle                  0
#define INCLUDE_uxTaskGetStackHighWaterMark     1
#define INCLUDE_eTaskGetState                   0
#define INCLUDE_xTaskResumeFromISR              1               // Enabled by default in FreeRTOS.h
#define INCLUDE_xTimerPendFunctionCall          1
#define INCLUDE_xTaskGetSchedulerState          1
#define INCLUDE_xTaskGetCurrentTaskHandle       1

#define configMAX_CO_ROUTINE_PRIORITIES         0               // Must be greater or equal to 1 if configUSE_CO_ROUTINES is enabled.
#define configUSE_DAEMON_TASK_STARTUP_HOOK      0               // See also IOT-5451
#define configUSE_APPLICATION_TASK_TAG          0
#define configNUM_THREAD_LOCAL_STORAGE_POINTERS 0
#define configUSE_RECURSIVE_MUTEXES             1
#define configUSE_MUTEXES                       1
#define configUSE_TIMERS                        1
#define configUSE_COUNTING_SEMAPHORES           1
#define configUSE_ALTERNATIVE_API               0               /* Deprecated, and now removed from FreeTROS 9. */
#define portCRITICAL_NESTING_IN_TCB             0
#define configMAX_TASK_NAME_LEN                 10              // Allow 10 characters for task names
#define configIDLE_SHOULD_YIELD                 1

在后来的版本，只修改过BS和非BS合在一起，难道和这个有关？难道开启BS的话，是创建了2个UDP的接收任务？经过测试发现，非BS的版本确实可以进入低功耗，因此应该是建了2个UDP的接收任务，已经确认应该是建立了2个任务。所以删除任务的时候删除两次。