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, 50}, //Incorrect parameters
{AT_RET_PARAM_MISSING, 52}, //Incorrect parameters
{AT_RET_SYNTAX_ERROR, 53}, //Incorrect parameters
修改完之后测试一下，首先是非数字看是否能测试到，首先是字符问题
[18:43:44.372]发→◇AT+CGSN=1
□
[18:43:44.386]收←◆
+CGSN:865353030039314
OK
[18:43:48.004]发→◇AT+CGSN=A
□
[18:43:48.016]收←◆
[18:43:48.068]收←◆
+CIS ERROR: 53
然后是
[18:44:58.380]发→◇AT+CGS2N=1
□
[18:44:58.393]收←◆
+CIS ERROR: 53
继续测试，所以目前猜测，之前的错误很有可能就是这个53，语法错误
[18:49:33.091]发→◇AT+MIPLOP
□
[18:49:33.103]收←◆
+CIS ERROR: 53
[18:49:36.709]发→◇AT+MIPLOP1EN=0,300
□
[18:49:36.730]收←◆
+CIS ERROR: 53
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:-1,CIS_URI_IS_SET_RESOURCE(&node->uri)?node->uri.resourceId:-1); //早先错误的写法 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:-1,CIS_URI_IS_SET_RESOURCE(&node->uri)?node->uri.instanceId:-1);
16. 任务阻塞失败？
TaskHandle_t udp_recv_task_handle = NULL;
xTaskCreate( callbackRecvThread, "onenet_udp_recv", 400, (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个任务。所以删除任务的时候删除两次。