I am using the CORTEX-R4TICCS5 port with v8.0.0 FreeRTOS. This is Demo for cortex R4 processors and the TMS570 series. The port uses heap_4.c and appears to never initialize the heap. When the first call to pvPortMalloc is called, the pvReturn var is never accessed. Obviously I am missing something. Any help would be appreciated. Thanks, Ron M.

The heap is initialized if pxEnd is found to be NULL, which it should be the first time pvPortMalloc is called because it is initialized to NULL where it is declared. If you find it is not NULL then I guess you have a start up code or linker script problem which is either not setting it to NULL before main() is called or clobbering the value after main() is called.

Thanks Dave, That does appear to be the case, the pxEnd is never being set to Null. Looking at the value, I don’t think it is being clobbered but don’t know for sure. Do you have any idea how to make sure all the necessary initialization is taking place before the first call from main? Thanks, Ron

NULL is zero, so the variable should get allocated by the linker into the bss section, then cleared to zero by the compiler or chip vendor supplied C start up code before main() is called. This is a normal part of setting up the C run time environment. The C start up code is normally called something like boot.s or crt0.s – but can have any name and may even have a different file extension (such as .asm). If you set your debug interface to break on entry rather than breaking on the first instruction of main() then you will be able to step through the C start up code and see why it is not working as would be expected. Regards.

First, thanks for the help. I’m not sure exactly how to set the debugger in CCS to break on entry but I will figure it out. There was a similar problem with an MSP430 application some time back and there was a function you could invoke that assured the initialization completed before the WD timer hit. Perhaps there is something like that going on here. Thanks again – I’ll keep after it. Ron