c - Freertos + STM32 - malloc 线程内存溢出

Question

我正在用stm32+rtos实现一个基于spi flash的文件系统。对于freertos，我采用了heap_1实现。这就是我创建任务的方式。

osThreadDef(Task_Embedded, Task_VATEmbedded, osPriorityNormal, 0, 2500);
  VATEmbeddedTaskHandle = osThreadCreate(osThread(Task_Embedded), NULL);

我为该线程分配了 10000 字节的内存。

并且在这个线程中。我尝试将数据写入闪存。在前几个电话中，它工作得很成功。但不知何故，当我尝试更多的写入时间时，它崩溃了。

VATAPI_RESULT STM32SPIWriteSector(void *writebuf, uint8_t* SectorAddr, uint32_t buff_size){



    if(STM32SPIEraseSector(SectorAddr) == VAT_SUCCESS){
        DBGSTR("ERASE SECTOR - 0x%2x %2x %2x", SectorAddr[0], SectorAddr[1], SectorAddr[2]);
    }else return VAT_UNKNOWN;
    if(STM32SPIProgram_multiPage(writebuf, SectorAddr, buff_size) == VAT_SUCCESS){
        DBGSTR("WRTIE SECTOR SUCCESSFUL");
        return VAT_SUCCESS;
    }else return VAT_UNKNOWN;

    return VAT_UNKNOWN;

}

.

VATAPI_RESULT STM32SPIProgram_multiPage(uint8_t *writebuf, uint8_t *writeAddr, uint32_t buff_size){
    VATAPI_RESULT nres;
    uint8_t tmpaddr[3] = {writeAddr[0], writeAddr[1], writeAddr[2]};
    uint8_t* sectorBuf = malloc(4096 * sizeof(uint8_t));
    uint8_t* pagebuf = malloc(255* sizeof(uint8_t));
    memset(&sectorBuf[0],0,4096);
    memset(&pagebuf[0],0,255);
    uint32_t i = 0, tmp_convert1, times = 0;


    if(buff_size < Page_bufferSize)
        times = 1;
    else{
        times = buff_size / (Page_bufferSize-1);
        if((times%(Page_bufferSize-1))!=0)
            times++;
    }

    /* Note : According to winbond flash feature, the last bytes of every 256 bytes should be 0, so we need to plus one byte on every 256 bytes*/
    i = 0;
    while(i < times){
        memset(&pagebuf[0], 0, Page_bufferSize - 1);
        memcpy(&pagebuf[0], &writebuf[i*255], Page_bufferSize - 1);
        memcpy(&sectorBuf[i*Page_bufferSize], &pagebuf[0], Page_bufferSize - 1);
        sectorBuf[((i+1)*Page_bufferSize)-1] = 0;
        i++;
    }

    i = 0;
    while(i < times){
        if((nres=STM32SPIPageProgram(&sectorBuf[Page_bufferSize*i], &tmpaddr[0], Page_bufferSize)) != VAT_SUCCESS){
            DBGSTR("STM32SPIProgram_allData write data fail on %d times!",i);
            free(sectorBuf);
            free(pagebuf);
            return nres;
        }
        tmp_convert1 = (tmpaddr[0]<<16 | tmpaddr[1]<<8 | tmpaddr[2]) + Page_bufferSize;
        tmpaddr[0] = (tmp_convert1&0xFF0000) >> 16;
        tmpaddr[1] = (tmp_convert1&0xFF00) >>8;
        tmpaddr[2] = 0x00;
        i++;
    }
    free(sectorBuf);
    free(pagebuf);
    return nres;
}

我打开调试器，当我在函数“STM32SPIProgram_multiPage”中分配“sectorbuf”时，它似乎崩溃了，令我困惑的是我在“malloc”之后释放了内存。有人知道吗？

arm-none-eabi-size "RTOS.elf"
text data bss dec hex filename
77564 988 100756 179308 2bc6c RTOS.elf

Answer 1

阅读the man

Memory Management

[...]

If RTOS objects are created dynamically then the standard C library malloc() and free() functions can sometimes be used for the purpose, but ...

they are not always available on embedded systems, they take up valuable code space, they are not thread safe, and they are not deterministic (the amount of time taken to execute the function will differ from call to call) ... so more often than not an alternative memory allocation implementation is required. One embedded / real time system can have very different RAM and timing requirements to another - so a single RAM allocation algorithm will only ever be appropriate for a subset of applications.

To get around this problem, FreeRTOS keeps the memory allocation API in its portable layer. The portable layer is outside of the source files that implement the core RTOS functionality, allowing an application specific implementation appropriate for the real time system being developed to be provided. When the RTOS kernel requires RAM, instead of calling malloc(), it instead calls pvPortMalloc(). When RAM is being freed, instead of calling free(), the RTOS kernel calls vPortFree().

[...]

^{(强调我的。)}

所以意思是，如果直接使用malloc，FreeRTOS无法处理系统函数消耗的堆。如果您选择作为简单的 malloc 包装器的 heap_3 管理，则相同。

另请注意，您选择的内存管理没有免费功能。

heap_1.c

This is the simplest implementation of all. It does not permit memory to be freed once it has been allocated. Despite this, heap_1.c is appropriate for a large number of embedded applications. This is because many small and deeply embedded applications create all the tasks, queues, semaphores, etc. required when the system boots, and then use all of these objects for the lifetime of program (until the application is switched off again, or is rebooted). Nothing ever gets deleted. The implementation simply subdivides a single array into smaller blocks as RAM is requested. The total size of the array (the total size of the heap) is set by configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h. The configAPPLICATION_ALLOCATED_HEAP FreeRTOSConfig.h configuration constant is provided to allow the heap to be placed at a specific address in memory.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated, allowing the configTOTAL_HEAP_SIZE setting to be optimised.

The heap_1 implementation:

Can be used if your application never deletes a task, queue, semaphore, mutex, etc. (which actually covers the majority of applications in which FreeRTOS gets used). Is always deterministic (always takes the same amount of time to execute) and cannot result in memory fragmentation. Is very simple and allocated memory from a statically allocated array, meaning it is often suitable for use in applications that do not permit true dynamic memory allocation.

^{(强调我的。)}

附注:您必须始终检查malloc返回值!= NULL。