Nordic 遇到的问题

在项目中使用的52840搭载的FreeRTOS操作系统,使用的是SES开发环境而非Keil(因为Nordic买了SES的版权,使用SES不会有版权问题)

52840 相关

1、P0.9和P0.10

由于52840支持NFC功能,因此该两个引脚默认为NFC引脚,在项目中如果用作普通的GPIO,则需要进行设置。

需要在system_nrf52.c中加宏定义

#define CONFIG_NFCT_PINS_AS_GPIOS

2、SPI问题

在nrf52840做主机时,需要使用DMA进行发送,但是由于SPI的easyDMA的长度限制为不超过256字节,因此,在我的项目中,由于使用的是每包512字节的机制,所以需要进行分包发送。还出现过uninit时,while循环导致重启,由从机导致。需要注意此点。

3、I2C问题

目前有很多单片机中的I2C变成了TWI。TWI全兼容I2C,但并不局限于I2C,双线发送均可使用TWI进行操作。

TWI在操作上较I2C复杂,需要自己写一个I2C的接口,使用TWI进行封装

4、FDS问题

    较高版本中,官方库支持FDS进行flash的读写操作,实现了擦写均衡,适合于数据量较小且经常容易变动的数据
  1. 需要对数据长度有较好管控,否则一旦读取的长度比实际长度长时,可能会导致HardFault,原因是fds不对长度进行校验,因此长度过长,超出FLASH的映射空间,就会有HardFault产生。
  2. 读FLASH数据时,需要使用memcpy将数据读出,否则可能会导致HardFault,原因是fds返回的地址并非是内存地址(0x2000000起始),而是flash地址(0x0起始),在执行一些操作时,由于地址不是内存地址而产生
  3. fds不对数据进行加密,当使用flash读取工具时,(jFlash,nrf—connect)则会读出存储的设备信息,可能有很关键的信息,这个是需要考虑的点,当然也可以在产品出厂时设置为flash不可读取,但是也会有一些不方便之处
  4. 我实测一次gc的时间大概是800ms左右
  5. 推荐进行封装成write和read两个函数,否则操作很麻烦

5、堆栈问题

nrf52840的例程中,使用的heap较小,当开辟较大数据时,容易出现开辟失败的情况,如果需要的话,需要对heap进行扩容。也需要保证malloc和free的匹配性,当然也可以使用官方的内存管理机制,为原子操作,更放心,但是需要对其较为了解。

6、GPIO中断问题

GPIO本来是只支持8个引脚的中断,但是使用PORT,还有sdk_config.h中的宏,来进行规避此问题,例如我的项目中就高达10个中断。

使用该方式时,有可能需要将结构体元素中的hi_accuracy进行赋值为1,否则可能会有检测不到中断的可能性!!!

7、低功耗问题

    一般使用该芯片都是用作低功耗的场景,因此低功耗是一个关注的点
  1. 起始芯片自身的功耗是非常少的,只有2~3uA,因此即使是一个小电容也可能供电一段时间,这也是一个调低功耗的坑,断电时间过短,由于电容供电,导致芯片还在工作一点时间,需要把握好这个时间节点,也可以使用一些外部的按键等快速放电
  2. 蓝牙的功耗,蓝牙的功耗是随着广播时间的间隔或者打开关闭来改变的,但是广播也和设备连接有一定的关系,广播越久,功耗越低,设备连接越慢,需要进行取舍。我的项目中,测试大概是1s广播间隔,连接时间最长可能达到十多秒,平均功耗在20uA左右,可以尝试了解快慢广播的概念,然后进行配置,在两者之间做出平衡
  3. 蓝牙的引脚,蓝牙的引脚默认都是disconnec的状态,因此,不配置就是最低的功耗。低功耗应用场景,一般都有对于外围芯片电源的控制,因此即开即关也是一个功耗处理点,对于不需要关闭电源的设备,一般来说会有加速度传感器,加速度传感器一般的选型是LiS2DH,该芯片的内部有一个上拉电阻,功耗可达百微安级别,需要设置成不可使用上下拉,另外一个采样频率也是一个功耗点,我的项目中为25Hz
  4. MCU的外设也是需要即开即关,但是经常会需要init和uninit不同步导致的断言问题,因此需要控制好
  5. 蓝牙引脚设置为默认状态时,外部设备的连接为浮空状态,可能为高电平,该状态可能与外部IC冲突,导致的功耗问题,我的项目中需要和另一个wifi芯片进行通讯,wifi芯片的唤醒中断引脚,因为这个默认状态而导致的休眠失败是一个功耗点

8、复位问题

nrf芯片可以记录复位原因,包括复位引脚,上电,看门狗,也可以用户在需要重启的时候写入寄存器,自定义原因,在上电时,就可以进行分别处理,我的项目中,是做了非用户操作的重启,则用户不感知重启的功能。重启不清零数据的内存地址放到了 _attribute_((section(“.non_init”)));如果有bootloader,需要同步设置

9、重启定位问题

    设备重启,则有多种原因导致,APP_ERROR_CHECK,HardFault,看门狗,用户复位等。需要了解一些pc指针的知识
  1. APP_ERROR_CHECK,在app_error.c文件夹中,可以打印出具体的文件名字和行号、以及错误代码,较为简单。
  2. HardFault,在hardfault_implementation.c文件中,已经详细对其做出了打印,则根据PC指针,LR寄存器等,来推断导致hardfault的位置。LR寄存器一般存放产生hardfault的函数,pc指针定位到了具体的代码地址
  3. 看门狗复位,看门狗是为了防止程序异常死机,但是正常情况下也是不允许该情况的,可以在看门狗中断函数中,读出传参sp[6]的值,该值就是PC指针,然后记录下来,放到重启不清零的RAM地址(__attribute__((section(".non_init")))),即可进行打印地址,定位问题。
  4. 用户复位就不需要分析了吧

10、PC指针

这个可以通过map文件搜索,和debug模式下搜索,可以找到具体的代码,进行定位问题

11、fstorage问题

默认队列为4,当队列用完时,会返回错误码,此处导致的问题需要注意

12、日志问题

由于我的项目中,软件测试是用串口接收打印,而不是使用Jlink,因此需要将数据通过串口输出,但是当使用串口进行输出时,出现的异常重启则不可以进行打印,导致分析出现问题。因此需要将APP_ERROR_CHECK和HardFault的数据也通过串口输出出来。

下面为我的调试代码:用于重大错误即将重启之前的调用

nrf_drv_uart_t m_uart = NRF_DRV_UART_INSTANCE(UART_LOG_INSTANCE);
static volatile bool m_xfer_done;
//发送完成中断函数
static void uart_evt_handler(nrf_drv_uart_event_t *p_event, void *p_context)
{
    m_xfer_done = true;
}

//重大错误调用函数,在HardFault中也可调用
void _anker_log_error(char *fmt, uint16_t len)
{
	//反初始化串口,这个地方需要注意,因为不知道有没有进行开始串口,内部可通过标志位或者事件进行对应处理
    uart_driver_deinit();
    
    //初始化串口
    nrf_drv_uart_config_t config = NRF_DRV_UART_DEFAULT_CONFIG;
    config.pseltxd = UART_LOG_TX_PIN;   //只需要用到发送串口
    config.pselrxd = NRF_UART_PSEL_DISCONNECTED;
    config.pselcts = NRF_UART_PSEL_DISCONNECTED;
    config.pselrts = NRF_UART_PSEL_DISCONNECTED;
    config.baudrate = (nrf_uart_baudrate_t)NRF_LOG_BACKEND_UART_BAUDRATE;
    nrf_drv_uart_init(&m_uart, &config, uart_evt_handler);

    //日志进行格式化,带颜色较为清晰
    uint8_t err_buf[256];
    snprintf(err_buf, sizeof(err_buf), "\r\n\033[31m<<<<<fatal error:please reboot>>>>>:\033[0m\033[33m %s\033[0m", fmt);

    m_xfer_done = false;

    //进行数据输出
    nrf_drv_uart_tx(&m_uart, (uint8_t *)err_buf, strlen(err_buf));

    //tick用来确保中断被关闭时,也能正常退出
    uint32_t tick = 1000000;
    while (m_xfer_done == false && tick-- != 0)
    {
    }
    nrf_drv_uart_uninit(&m_uart);

    //调试使用,连上jlink时,也可进行jlink输出
    NRF_LOG_FLUSH();
}

操作系统相关

1、内存问题

在所有使用freertos的工程中,一般默认推荐的都是使用的heap_4这个内存管理机制。

该内存管理机制是用FreeRTOS进行统一管理,FreeRTOS使用的所有内存都从一个数组中进行开辟。而Nordic官方使用的heap_1作为例程。当进行任务开辟时,非常容易由于总共的堆栈空间分配不足,导致失败。因此我后来也是选用了heap_4这个内存管理机制

但是当任务堆栈不足时,也会导致任务开辟失败。可通过修改configTOTAL_HEAP_SIZE的值进行处理。默认为4k,几个任务就不够了。

需要注意的问题是,你任务中使用的所有变量,局部变量、函数调用占用的空间等,都是占用的任务的堆栈空间,malloc函数占用的是程序的堆空间。因此要保证开辟任务时,保证开辟的任务堆栈空间不足,否则就会导致重启,可通过configCHECK_FOR_STACK_OVERFLOW为1,在钩子内进行打印堆栈溢出的任务名字,进行确认。还可以通过使用INCLUDE_uxTaskGetStackHighWaterMark的方式来查看任务的最深调用。当接近0时,需要增加任务堆栈,当一直远远大于0时,可考虑进行减少任务堆栈。

需要注意可能并不是所有任务都初始化时就开始,有些任务可能开辟,不久就释放,所以测试时,需要进行全部任务开启测试,保证运行中开辟任务时,出现内存不够的问题。

2、中断问题

由于FreeRTOS的机制问题,需要区分中断的快速操作处理还是非中断模式下的可延时等待处理,因此给了两个函数,中断中需要调用带FromISR的函数,因此在写代码时需要非常注意。但是可以通过一个函数来进行判断0 == __get_CONTROL()

if (0 == __get_CONTROL()) // in isr handler
{
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xQueueSendFromISR(log_QueueHandle, &info, &xHigherPriorityTaskWoken);
}
else
{
    xQueueSend(log_QueueHandle, &info, wait_time);
}

3、打印与功耗问题

由于nordic移植的函数 configUSE_IDLE_HOOK一般为0,不会有功耗问题,但是打印不全,因为没有位置调用NRF_LOG_FLUSH函数,进行日志输出。但是当该值设置为1时,打印完全,但是芯片却没有休眠,一直在执行该函数。

知道该原因也就好解决了,我的采用方式是,定义自己的日志输出函数,通过串口输出,当自己的日志进行输出时,也直接调用NRF_LOG_FLUSH函数。

4、优先级问题

nordic的任务优先级configMAX_PRIORITIES中最大为3 ,可能不满足任务要求,推荐经典值16 ,与uCOSII不同,该值越大,优先级越高

当高优先级的任务产生时,会直接打断正在运行的低优先级任务,因此很多函数可能需要做好重入处理。比如外设的init和uninit函数。否则由于该问题导致的重启就很难找到。

5、定时器问题

nordic的定时器任务深度默认只有80,当项目中增加定时器,需要注意此处导致的重启configTIMER_TASK_STACK_DEPTH,我的项目中应用的为1k

6、任务名字问题

nordic的默认名字configMAX_TASK_NAME_LEN长度为4 ,推荐根据具体项目具体更改。

7、看门狗问题

建议看门狗单独做一个任务,且任务优先级为1,不能和其他任务同时使用,否则则可能出现任务中的其他功能阻塞掉看门狗任务,导致看门狗重启。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!