Heap_5 unable to free memory

Hello, I am using heap_5 to spread the heap between available internal and external memory. The sizes and locations are found with the linker file, and the definitions are done as so:

uint32_t     heapSize      = (uintptr_t)&__heap_limit_mp - (uintptr_t)&__heap_start_mp;
    uint32_t     heapSize3     = (uintptr_t)&__heap_limit_mp3 - (uintptr_t)&__heap_start_mp3;
    
    HeapRegion_t heap_regions[] = { 
        { (uint8_t*)&__heap_start_mp, heapSize }, // Remaining on chip RAM non-CCM
        { (uint8_t*)&__heap_start_mp3, heapSize3 }, // Remaining off chip PSRAM
        { NULL, 0 } };
    vPortDefineHeapRegions( heap_regions );

I’m inconsistently hitting eitherconfigASSERT( heapBLOCK_IS_ALLOCATED( pxLink ) != 0 ); or configASSERT( pxLink->pxNextFreeBlock == NULL );, leading me to believe that the memory locations are being changed or overwritten, but there is nowhere in code that I am doing this, and I’ve checked for memory leaks. Sometimes, it also works without issue. Has anyone come across this or something similar and found a solution?

My first guess would be that the heap implementation is just detecting the corruption, not causing it, and that something unrelated is writing outside of the heap area or just happens to be corrupting the heap area.

Seems like a memory corruption. You can try to comment out parts of your application to narrow down the problematic part. You can also try to use data breakpoint to catch memory corruption.

Thanks for the responses. @aggarg is there a way you’d recommend doing that with FreeRTOS? I’m assuming that it can be done with gdb somehow but I’ve never done anything like that before.

I assume you are asking about data breakpoint. If yes, you need to use debugger only. You can use watch GDB command.