Caveats of the MC1322x port of FreeRTOS

I should point out that the port of FreeRTOS to MC1322x has a bit of "brittle" code to handle interrupts. The problem is that this part contains a ROM that holds code to many important functions of the MCU. Freescale does not provide the source code for this ROM. In addition some of this ROM gets "patched" in RAM, and we have no control over this. One place that this becomes a problem is interrupt handling. An interrupt-driven OS like FreeRTOS needs to maintain the exact state of the interrupted task, but the ISR is in ROM. If we wholesale replace the ISR then we break almost the entire ROM processing scheme causing us to have to replace every function provided in the ROM (including all of the driver interfaces and APIs). This is no small task!

To get around this I used the standard ISR that ships with the ROM, but I have to play a little trick. This port of FreeRTOS uses timer0. When the timer interrupts the IRQ ISR (IRQHandler) calls to a ROM routine called timerISR via BL and then that routine calls to a RAM callback routine via BL. See the problem? When we finally get to our timer callback function in RAM we've pushed two new stack frames so the LR (register 14) of the original running task was wiped out. You'll notice in our OS callback I deal with this by popping these two stack frames off before we call the portSAVE_CONTEXT macro. (This varies a little depending if we're talking about the IAR or GCC ports.) This requires using the reverse of what happened in IRQHandler and timerISR.

This popping of the two extra stack frames works just fine and doesn't require us to abandon the ROM system, but it does make us brittle w.r.t. any ROM patches that Freescale might make in RAM. We'll have to look at this carefully with each release of LLC.a and MC1322x.a. Yes, this is a pain, but until we get the source code (or one of you write an all-RAM replacement of the driver system) this is probably as good as we can get. Hey, at least it works!