HCS12C32 to HCS12E128

I have been trying to change the HCS12C32 to HCS12E128. I changed the cpu bean to the hcs12E128. Had to change timers from TM0 to TM2C4. I am using a softec board. Changed led ports from B to T. Change button bean from PP0 to PAD04. Build option to small.(for now). Found the info on the vector.c file change so I am using the vport interrupts instead of the vtask interrupt routines. Changed the tick flag from TFLG1 to TIM2_FLG1. And changed the button flag from PIFP to PIFAD. Changed softec.ini file hardware from PK-HCS12C32 to PK-HCS12E128. Changed device name as well from MC9S12C32 to MC9S12E128. Putting a breakpoint inside the vTaskIncrement routine shows the tick occuring. But pressing continue in the debugger alows the trap to occur only about 15 times then the program crashes. Also I notice that the sp is growing and growing until it crashes. What am I missing.  

HCS12C32 to HCS12E128

> I have been trying to change the HCS12C32 to HCS12E128. The 128 has 4 time the ram of the 32, so should be ok. >I changed the cpu bean > to the hcs12E128. Had to change timers from TM0 to TM2C4. >I am using a softec > board. Changed led ports from B to T. Change button bean from PP0 to PAD04. Should not cause a problem even if this were not correct. > Build option to small.(for now). Easiest way to start.  Presume BANKED_MODEL is therefore not defined. >Found the info on the vector.c file change > so I am using the vport interrupts instead of the vtask interrupt routines. Not sure exactly what you mean by vport Vs vtask.  However, provided the interrupt functions are in the correct places in the table. > Changed the tick flag from TFLG1 to TIM2_FLG1. I think this would be very obvious were it wrong. >And changed the button flag from > PIFP to PIFAD. Likewise. >Changed softec.ini file hardware from PK-HCS12C32 to PK-HCS12E128. > Changed device name as well from MC9S12C32 to MC9S12E128. >Putting a breakpoint > inside the vTaskIncrement routine shows the tick occuring. So the vectors must be set up correctly. >But pressing continue > in the debugger alows the trap to occur only about 15 times then the program > crashes. >Also I notice that the sp is growing and growing until it crashes. Presumably the tick ISR does actually exit correctly and not just immediately reenter as if the interrupt has not been cleared?  Could this cause the SP to wind up in this way? > What am I missing. Seem to have everything covered.  I would suggest cutting the system back to the bones to start. 1) Set configUSE_PREEMTPION to 0 in FreeRTOSConfig.h. 2) Comment out the call to prvSetupTimerInterrupt() in port.c. 3) don’t create any of the demo tasks.  Instead create two tasks as this: void Task1( void *parameters ) { ____int count = 0; ____while( 1 ) ____{ ________++count; ________if( count > 1000 ) ________{ ____________vParTestToggleLED( 1 ); ____________count = 0; ________} ________portYIELD(); ____} } Task2 would be exactly the same but flash led 2. As no task delays or blocks the fact that the tick is not running will not matter.  With no interrupts it will be easier to step through the code and check that this is working first.  Each task should just run for one cycle then yield to the other task so they take it in turns to perform one loop.  Every 1000 loops it will toggle an LED.  1000 may be too high depending on the speed.  With this setup you should be able to step through everything using the debugger and see exactly what it is doing. Once this is working change portYIELD() to vTaskDelay(1) and uncomment prvSetupTimerInterrupt().  The tasks should behave in a similar manner but are now dependent on the tick ISR incrementing the tick count.  If this part fails then it looks like something in the ISR is causing the problem. Once this is working try changing configUSE_PREEMTPION back to 1 as the final step.

HCS12C32 to HCS12E128

The two tasks work when I use the portYIELD(). But when I switch to the vTaskDelay() the tasks stop working. I added a vParTestToggleLED( 4 ) before the vTaskDelay() in each task and the leds go on but do not toggle. Seems like a problem in the taskdelay area. Its like they only get executed a few times then stop for some reason. I can see the tickcount increment so the timer is still running. The scheduler is still enabled. Is there a good description of the TCB and how they are used? How do you determine the stack pointer?

HCS12C32 to HCS12E128

You said before that the stack was growing when it should not.  It is likely to be this that is trashing some data structure.  I think the problem lies in your interrupt?

HCS12C32 to HCS12E128

I think I found the problem in the interrupt. I started using a callm to a vParTestToggleLED(x) in the vTasktick routine so I could see a port bit flip. But that call the portENTER_CRITICAL(); and portEXIT_CRITICAL(); routines. I think that was what was messing up the stack. When I did your test ( without adding the vParTestToggleLED(x) call) the stack does not seem to grow now. Only the tasks are not enabled after the delay. But the TickCount is counting. It never stops. So the interrupt now seems to be working. Only the tasks are not starting up.

HCS12C32 to HCS12E128

I found out my problem. When you use the metrowerks bean processor it creates new code under the generated code folder. And since I had to change the Tick timer, because the HCS12E128 does not have TIM0 as in the HCSC32 port, I changed to the TIM2C4 timer. The bean generated new reset vector flags for this timer in the TickTimer.C file. But since we manually modify the vectors.c file to point to the port.c code. We need to manually update the vPortTickInterrupt routine to reset the new flag bit. You can find out the code snipet by looking at the bean generated code in the TickTimer.c file. I hope this info helps others porting to different HCS processors using the Metrowerks bean processor. Tom 

HCS12C32 to HCS12E128

Thanks for sharing this valuable information!

HCS12C32 to HCS12E128

This all is why I don’t like things like "Processor Expert" and "CodeWarrior".  I’m trying to spend a little more time on getting the real Demo working for the GCC/HCS12 port. I think I’m close.