FreeRTOS中堆变量进入新函数后重置的常见原因咨询

背景信息 #

基于STM32 + FreeRTOS集成CANopenNodeStack，使用的仓库为CANopenNode/CanOpenSTM32。相关代码如下：

void canopennode_mtr(void* argument) {
    uint32_t ticks = osKernelGetTickCount();

    canopen_init();
    while (1) {
        canopen_app_process();
        
        // Sleep for 1ms, you can decrease it if required, in the canopen_app_process we will double check to make sure 1ms passed
        ticks += 1;
        osDelayUntil(ticks);
    }
}

void canopen_init(void) {
    //Assign CANOpenNode parameters
    CANopenNodeSTM32 canOpenNodeSTM321;
    canOpenNodeSTM321.CANHandle = &hcan1;
    canOpenNodeSTM321.HWInitFunction = MX_CAN1_Init;
    canOpenNodeSTM321.timerHandle = &htim14;
    canOpenNodeSTM321.desiredNodeID = 0x11;
    canOpenNodeSTM321.baudrate = 500;
    canopen_app_init(&canOpenNodeSTM321);
}

问题描述 #

堆中的CANopenNodeSTM32* canopenNodeSTM32变量完成初始化后，进入CANopenNode Stack的canopen_app_process函数时会被重置为0。现咨询FreeRTOS环境下导致堆变量重置的通用原因（排除CANopenNode Stack本身问题）。

通用原因分析 #

• 栈溢出破坏堆内存：FreeRTOS任务栈配置过小，任务执行时栈溢出，覆盖了堆区域的变量。可通过增大任务栈深度（在任务创建时调整栈大小参数），或启用FreeRTOS的configCHECK_FOR_STACK_OVERFLOW栈溢出检测功能排查。
• 堆内存越界访问：其他任务或中断中存在数组越界、指针非法操作，写入了超出分配内存范围的区域，破坏了目标堆变量。可借助硬件调试器的内存断点、内存检测工具定位非法写入的代码。
• 变量作用域错误：若canopenNodeSTM32被错误声明为局部栈变量（而非通过pvPortMalloc等堆分配函数创建），函数退出后栈空间被复用，后续操作会覆盖该变量内容。需确认变量的分配方式正确。
• 中断上下文非法操作堆：在中断服务函数中直接操作堆变量，或调用堆操作函数时未用portENTER_CRITICAL/portEXIT_CRITICAL保护临界区，导致并发访问堆时数据损坏。
• 堆内存分配失败：pvPortMalloc分配内存时返回NULL，但代码未做检查，后续对空指针的操作引发未定义行为，表现为变量被重置。需检查堆分配返回值，同时确认configTOTAL_HEAP_SIZE配置的堆空间足够。
• 并发访问无保护：高优先级任务或中断频繁抢占，在堆变量未完成初始化时就被访问，或多任务并发写入堆变量导致数据覆盖。需确保变量初始化完成后再被访问，必要时用互斥量保护对堆变量的操作。

内容的提问来源于stack exchange，提问作者ro88