I am trying implement the FLASH task using the RTOS Demo for the HCS12 (banked) as a starting point (I removed all the other tasks, since I’m going for simplicity first time around). I had to make some changes since ProcessorExpert is not yet supported with the HCS12X. The changes I basically made were to setup the Periodic Interrupt Timer 0 as the RTOS Tick interrupt, hardcoding it for 1000 Hz (just like the demo). I changed the prvSetupTimerInterrupt() in port.c to simply start the PIT0 timer. The interrupt vector table is also updated so that the Tick ISR is serviced with the PIT0. My problem is that in xBankedStartScheduler(), the application quits with an unknown event (quitting at the XIRQ interrupt for some reason). If I comment out the portRESTORE_CONTEXT(); and __asm( "rti" ); lines, it runs through (but obviously just sits in the loop in vMain()). I think its somewhere not correctly restoring the context so that the rti instruction goes to the correct Task, but I’ve been hung up for a while trying to track down what’s going on. Does anyone have any suggestions on what may be causing the problem? I’m thinking theres still something I need to change so that RTOS is correctly ported to the HCS12X and its memory map in regards to storing a task’s context. Anyway, any suggestion/help is greatly appreciated! Thanks, - Mike
Not familiar with the HCS12X but some things come to mind reading your post. 1) The processor expert can be a pain wrt interrupts. The FreeRTOS demo requires that the interrupt table be populated manually after the expert has run. Also there was something I recall about having a file read only so the expert does not overwrite it. You might one to check that out. 2) Have you checked your timer without FreeRTOS? Simply setting up a timer and toggling a bit every 1000 ticks or something. Once you can guarantee that the interrupts are correct you can add the FreeRTOS code in. 3) You could try not turning on the interrupt (so it does not get in the way) and stepping through the starting of the first task to see exactly what it does. Obviously it will not run without the interrupt but it is easier to debug.
The Tick interrupt works just fine and is very accurate to 1000 Hz. I’ve stepped through the code a bit, and found something interesting. When the function xTaskCreate is called, the first parameter if the address of the function that has the task code (for me, that is located at memory location FE86CA). However, when debugging, it passes the address 86CAFE (the page is appended to the end for some reason?). It does this with the address-of operator as well. I’m thinking that something is not storing correctly in the stack, and so when RTI is called from the StartScheduler, it goes to a memory location for the XIRQ ISR (my vector table is setup so that each interrupt channel has its own ISR, then all the ISRs that are not used are simply blank).
I fixed the issue. It has to do with the HCS12X having a larger CCR register (2 bytes instead of one). The first 5 bits are unused for future use, then comes IPL[2:0], and than the other 8 bytes. The two high bytes of the actual CCR register (S and X) need to be set to 1, or else the application ceases (clearing 0 or X causes an interrupt; which is why I was getting the XIRQ interrupt due to the X flag being cleared). So here’s what needs to be added to port.c in the function *pxPortInitialiseStack Where the CCR is save to the stack, simply add stack the extra byte 0xC0 (C to set the S and X flags). /* CCR: Note that when the task starts interrupts will be enabled since I" bit of CCR is cleared */ *pxTopOfStack = ( portSTACK_TYPE ) 0xC0; pxTopOfStack–; *pxTopOfStack = ( portSTACK_TYPE ) 0x00; pxTopOfStack–; So far I’ve gotten the Flash task to work correctly. If there are any other locations in the code where the CCR register is stacked, or unstacked, then that will need to be edited too (I have just now started to actually write my application since finding this issue). I hope this helps future users who are trying to implement FreeRTOS on an HCS12X (XGate). Cheers, Michael
Thanks for reporting back – very useful information. Regards.
I had to trace the stack very carefully too, for my HCS12 port. With a new compiler and new MCU, you have to carefully count the bytes on the stack to see what address it will return to with the rti. One more thing, I don’t know if anyone mentioned the reason the memory bank (0xfe) is in the LSB instead of first in the "far" address. It’s a new standard address type with 9S12X, I believe.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.