HSC12 - demo application - out of RAM space

nobody wrote on Wednesday, May 03, 2006:

I am trying to run the HSC12_small demo application using Freescale’s CSM12C32 module (it has the MC9S12C32 MCU with 48 pins).  I have to reassign ports/pins as the original (SofTec) uses the 80pin version, but the rest should be the same, i.e., 2 kB RAM. Nevertheless, the linker complains about not enough RAM for the demo application: “Linker error: L1102: Out of allocation space in segment RAM at address 0xF8E”. RAM is starting at 0x800 and of size 0x800.

As I am sure the application has been tested with 2kB RAM, I assume I am doing something wrong here. Did anybody else experience this and could give me a hint on what to adjust?


Note: The .map file summarizes RAM usage to be 1934 bytes; FreeRTOSConfig.h uses #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 2048 - 256 ) ) which is 1792 bytes. But using 2048 does not make a difference.

nobody wrote on Thursday, May 04, 2006:

I think the RAM usage in this demo is quite tight.

As an experiment, try making the heap size smaller, say by 256 bytes to start with.  Then see if it links.  If so see how close you can get it back to the original value.  This will give you an idea of how close it is to fitting, and how much needs shaving off.

Does the FreeRTOS hcs12 demo use any special linker file, or just the standard one.  I remember there was something about the processor expert screwing up interrupt vectors, but i can’t think it would do anything to the linker.

Do the larger 80pin device headers include any badly written library code that is eating ram for no reason?

nobody wrote on Thursday, May 04, 2006:

Thanks for your input - changing the heap size does not seem to help but your advice made me look at the Processor Export CPU setting of the stack size: it was set to 80 rather than the smaller value of 30 of the original FreeRTOS HCS12 project. I guess creating/opening it with my PE set it to this default value?

I can know run all the demo tasks and the .map file indicates RAM usage of 1982 bytes, which may still be too high - I would appreciate any comments on this as it may indicate that I won’t be able to program much with 2kB RAM.

Note: I had to change one thing in main.c to correctly reset the PP5 button-interrupt:
/* Clear the interrupt flag. */
PIFP = 0x60; // PIFP = 1 doesn’t work

rtel wrote on Thursday, May 04, 2006:

Thanks for the heads up on the bit clearing.

On the smaller devices the demo apps are often written to take up a lot of the available RAM, if not all of it.  You can remove some of the demo tasks to free up the RAM requirements, then reduce the amount of heap allocated to the kernel.

If you are very tight on RAM then consider using co-routines instead of tasks.  These remove the necessity to allocate a stack to each ‘thread’ of execution.


imajeff wrote on Thursday, May 18, 2006:

Also sometimes the useless demo functions will free up a lot of RAM if removed for your own functions.

imajeff wrote on Thursday, May 18, 2006:

Oh Richard already mentioned removing the demo functions…

I want to make more clear the other thing suggested:
The demos are allocating most or all RAM for the RTOS heap. If the linker says "out of RAM", then that does not mean all the RAM in the heap is used. So in fact, if you are out of RAM, you actually might be able to _reduce_ the heap size to solve it.

In "heap_2.c" I looked and found pxNextFreeBlock. I have tracked this variable to see how much heap I needed. It was much less than what is allocated.

imajeff wrote on Thursday, May 18, 2006:

Sorry, was misleading about finding free heap space…

- in "heap_1.c" you can simply track xNextFreeByte to see how much heap used

- in “heap_2.c” looks more complicated
You would have to search the linked list starting at xStart and find the highest pxNextFreeBlock. It seems like xEnd.xBlockSize could be updated to track free space, but it isn’t. It is initialized:
xEnd.xBlockSize = configTOTAL_HEAP_SIZE;