Good morning,
I have a hard fault problem on an NXP Kinetis K64 using MCUXpresso with the libraries that FreeRTOS came with about 2 years ago. An Mbed TLS C structure’s member is being overwritten after a call to pvPortMalloc(). I am using the heap_4.c scheme but am unfamiliar with how FreeRTOS’ allocator works internally. See the screen shot.
Might you happen to know what the “Allocated” line above “MQTT Agent Task (Task Stack)” is reporting? Is it the sum of the pvPortMalloc() calls? I know it shows dozens of bytes or less before any mallocs are performed.
The important question is this: The MQTT Agent task eventually calls pvPortMalloc() right before it hard faults. The call returns a pointer to a block that is WITHIN the range as reported by the “Allocated” line in the screen shot. Does this mean this is stepping on memory block that is already being used?
Thank you for your reply. The Mbed TLS library uses a C structure for its context data. Right before a crash, I see that its members (pointers) are overwritten with English/ASCII text. This text matches what has been spit out of the diagnostic UART.
Debugging proves that those corrupted pointers are the cause of the crash. I also found that the pvPortMalloc() memory allocator re-issues a memory block to a print function where that memory block was already allocated. That would explain the text being written to the wrong place in memory (the same allocation shown in my graphic above).
I haven’t yet tried to learn why pvPortMalloc() seems to be malfunctioning, but I have a good suspect: The FreeRTOS OTA example I modified uses many print statements. I have avoided both mallocs and prints in my firmware career until this, my first FreeRTOS project. I suspect my non-thread-safe print library (NXP’s RedLib) is causing the issue. Removing the prints from the project fixes the problem, for example. So I’m going to focus my efforts there.
FreeRTOS’s pvPortMalloc and pvPortFree should be task-safe an not do that unless you do something wrong.
If using heap3, and somewhere else code calls malloc/free, then that will break the task-safety requirements unless the provided malloc/free are themselves thread-safe, which many are not (but some can be made that way with some helper locking functions). (if not using heap3, then pvPortMalloc will be safe, but other code that calls a non-thread-safe malloc will not be).
The re-issuing of blocks will be caused either by using a non-thread-safe malloc/free operation, freeing a block of memory and then still using it, or overrunning an allocation and breaking the heap structure.
I read somewhere that NXP’s RedLib C standard library is not thread-safe. Removing/replacing the printf family of calls, etc., fixed the issue.
The FreeRTOS Heap Usage debugger display and/or memory allocator was likely corrupted by the issue as well since it looked more normal after the repair–the 41 kB went down to just dozens of bytes like the rest of the Allocated lines displayed for other tasks.
