全部文档
概述 硬件支持 快速开发指南 内核 驱动 通用组件 专业组件 常见问题

FAQ


Cube使用常见问题

Q:OneOS-Cube会被某些杀毒软件删除

A:如果被删了重新安装OneOS-Cube即可,每次运行OneOS-Cube之前把杀毒软件关掉

工程配置常见问题

Q.【AP6181】内存不足会导致WLAN模块初始化失败

A:在使用WiFi模组时建议把其它不用、不相关驱动设备都关掉,比如audio、senseor等;配置方法:menuconfig->Drivers

Q.【ESP8266】WiFi模组收发大数据包失败,扫描空口AP信息卡住无结果返回

A:在menuconfig->Drivers->Serial 将TX/Rx buffer调大,在内存够用的情况下可调至4096

Q.内存不足导致网络文件系统(NFS)挂载失败,串口输出out of memory

A:使用NFS前建议把其它不用的文件系统、驱动等都关闭。关闭配置:menuconfig->components->virtual file system, menuconfig->drivers

Q.【ML302-OC】开发板载入工程之后,串口打印(OS_OBJECT_TASK == os_object_get_type((os_object_t *)task)) assertion failed at function: os_task_sl[221] 进而卡死,开发板LED指示灯不闪烁

A:#define UIS8910DM_RECV_BUFF_LEN 2048;配置过大,恢复默认的512即可,配置方法如图:

Q.模组M5311自动创建后再手动修改UART2波特率,导致执行AT指令超时

A:menuconfig工程配置时已指定UART2波特率为19200,中移模组M5311自动创建初始化时就以波特率19200生效,若模组自动创建成功后,再手动修改波特率为115200会导致设置不生效不自动更新,进而导致执行AT指令时全部超时

OneOS-API常见问题

内核

Q: 程序正在执行时,发生了不可预知的错误,难于确定问题原因,有什么好的排查方法?

A:怀疑方向之一:可以考虑到使用任务等结构体是否使用了局部变量,局部变量申请时为随机值,若任务控制块成员变量为随机值,将无法确保程序按预定设计运行

建议做法:使用任务等内核相关功能时,建议使用全局变量,确保系统稳定性

Q: 在线程未结束时强行销毁线程返回OS_BUSY

A:原因分析:如果某个变量count可能会被线程A和线程B进行读写操作,用户使用互斥锁mutex对变量count进行保护。假定线程A获取到互斥锁mutex还未来得及释放时,线程C对线程A强行删除。由于mutex获取和释放只能由同一线程完成,所以mutex就一直得不到释放,导致线程B一直等待,如果线程B是tshell,表现就可能是shell卡死,不能使用。为了避免这个问题,如果删除(os_task_destroy或者os_task_deinit)持有未释放锁的线程时,函数会返回OSEBUSY,表示删除不成功。

建议做法:用户在销毁线程需要判定返回值,如果返回OS_BUSY,可以采取延时后再删除的方式。另外,信号量获取释放、文件打开和关闭、内存获取释放等也可能存在以上问题,对这些情况无处理机制,需要用户保证被删除线程无未释放资源。

BSP

Q:Pandora开发板的屏幕SPI3和WIFI SDIO管脚冲突

A: 将SPI3配置为半双工模式

Q: stm32f1系列PC13\14\15引脚上拉输入无效

A:问题现象:tm32f107-vct6-100开发板的PC13引脚配置为上拉输入时,实测内部上拉无效,存在问题;PC14\15为RTC引脚,配置为外部LSE晶振引脚,不能再进行配置为上拉输入,不存在问题

问题分析:1、PC13引脚和RTC关联,在F1系列上通过STM32CUBE进行配置时会存在问题,RTC存在三种模式:

Disable模式:该模式会隐藏的将PC13配置闹钟输出引脚,导致该引脚无法进行正常的IO操作;

No RTC Output模式: 该模式不会影响PC13的IO功能;但是会在初始化代码中强制无检测的重写RTC时间;

RTC Output on the Tamper pin:该模式会强制将PC13配置为闹钟输出引脚,不再具有普通IO口功能,同时会在 初始化代码中强制无检测的重写RTC时间;

2、将RTC晶振去掉,然后PC14\15配置为普通IO后,PC14\15功能正常;

建议做法:该问题属于STM32CUBE的限制,RTC开机初始化代码中强制无检测的重写RTC时间不符合我们的使用 要求,因此不能配置为后两种模式,客户在使用时需要根据自己的情况进行配置和代码调整

Q: F429开发板串口自回环测试数据收发丢失

A:stm32f429-atk-apollo 开发板的串口(usart1、usart6都试过)在 115200 波特率、循环 DMA 接收会出现丢包现象,推测该问题是F429芯片本身缺陷

规避方案:F429 驱动里面串口默认使用普通 DMA 接收。

注意事项:潜在问题-普通DMA在两次接收间隔,也可能会丢掉数据。

组件

Q:模组适配的时候,大包(大于1500bytes)发送失败

A:适当调大OS_SERIAL_RX_BUFSZ,建议配置值如下表:

模组型号 M5310A M5311 ML302 EC200X ESP8266
OS_SERIAL_RX_BUFSZ 4096 2048 1500 3072

Q:通过gcc编译的工程在shell下调用atest_run执行测试用例出现tshell stack overflow导致测试执行阻塞

A:问题现象:

问题原因:局部变量太大导致线程栈溢出,因为gcc的库函数没有keil那么精简,调用起来开销会大一点,所以用keil编译出来的没问题,gcc编译出来的就会溢出,同时用shell调用函数也是比用atest调用函数开销小

解决办法1:局部变量改用用全局变量或者动态申请内存

解决办法2:menuconfig->components->shell 将the stack size for shell stack设置成4096

Q:【MQTT】onenet mqtt在某些网络下会出现不停重连重新订阅的情况

A: 该问题是由运营商的NAT机制导致,在某些区域运营商会设置两分钟的NAT保活机制,再两分钟TCP连接无数据经过,就会把这个连接拆除

Q: 模组M5310A建立TCP连接时会概率性建连失败

A:通过抓包确认断开连接是模组发起的行为,不受MCU控制,模组固件的问题,molink和适配层无法解决这种问题。模组程序有BUG,需要模组厂商解决或者优化

Q: 万藕开发板直连A7600X模组在运行mo_netconn收发数据时有URC概率丢包的现象

A: 问题原因:万藕开发板串口与A7600C1开发板通信串口直接连接后,A7600C1的TXD引脚电平是2.22V,RXD引脚电平是3.21V,已超出A7600C1硬件手册给出的范围

解决办法:使用匹配电路将3.3V转换成1.8V再与A7600C1对接,数据收发均正常

注意事项:使用模组时,首先确认模组手册需要使用的串口电平是多少?是否需要连接电平转换器?错接或不接可能发生数据丢失,收发数据时无故溢出的现象。另外sim7600ce和A7600C1由于中间须加3.3V转换1.8V电路及杜邦线连接,这些也会造成硬件环境连接不稳定,可能会造成长时间和大包数据传输过程中仍有概率出现丢包现象

Q: 使用模组自动创建失败时,系统进入断言无法启动

A:创造错误条件,组件按照流程正常返回对应错误码,结束初始化流程,故模组对象本身创建失败是正常流程,但是自动初始化OS_CMPOENT_INIT失败后的流程是由系统统一调度的,按照当前的设计流程,模组对象初始化失败后系统挂在此处符合预期。

注意事项:在使用模组自动创建时,先确认模组串口配置正确,硬件连线正确。

其它使用常见问题

Q:Pandora开发板与模组通过杜邦线该怎么连接?

A:开发板与模组的TXD、 RXD 、GND分别一一对应,TXD与RXD不用交叉连接

Q:有没有OneOS硬件支持(soc/mcu、board、sensor)的全集?

A:有,持续更新中,请参考官方开发者文档 https://os.iot.10086.cn/doc/hardware_support/soc_mcu.html

持续更新ing

results matching ""

    No results matching ""