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, 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个任务。所以删除任务的时候删除两次。