Porting to hcs12x (mc9s12xdp512--hcs12 with xgate; code warrior; banked; FreeRTOS 5.02 demo)

1. hcs12x saves 3 additonal bits of CCR (IPV) meaning SaveContext must create 10-byte stack not 9 as in hcs12. (Demonstration, best seen with FCS: break before the _asm(rti) in startscheduler. Verify values at end of SP frame (ccr,ab,x,y,pc). Assembler-step. Verify new PC is bytes 9 and 10, therefore frame is actually 10B not 9B as in demo's code.)

2. demo also seems to use heap2.c for pvPortMalloc and pvPortFree yet "unable to allocate to segment RAM at 2068" in linker. Problem is due to linker trying to allocate the heap's data. One fix is to use Codewarrior's ansilib malloc()/free(). Not sure about impact on banking.

Other experiences?

Are you referring to the HSC12X port from this page http://www.freertos.org/RTOS-contributed-ports.html ?

The 5.02 contained a demo/hcs12_codewarrior_banked, no 12x. The link provided mentions demo/unsupported_demos. I grabbed 5.04, the directory was there; sure enough, port.c contains a check for #ifdef __HCS12X__ which similarly added the second ccr byte. Okay, 1 down.
However, there still seems to be a reference to heap_2.c which nails me. 2 is in the air.
Performance on 16MHz oscclk seems to be about 3 mS between tick and thread (only 1 thread and idle running), measured by the FCS. Does that seem about right? I experimented with moving tick to the RTI, but it appears RTICTL wants to be reloaded every tick.

Not sure what your problem is with heap_2. If the linker is trying to allocate the C heap then set the C heap size to 0 (or close to zero) so you don't waste RAM. Alternatively use heap_3 which just uses malloc and free anyway.

3ms between a tick running and a task seems very, very long but I don't really know what it is you are measuring.