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個任務。所以刪除任務的時候刪除兩次。