Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 14, 2005
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.

RE: HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 15, 2005
> 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.

RE: HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 15, 2005
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?

RE: HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 15, 2005
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?

RE: HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 15, 2005
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.

RE: HCS12C32 to HCS12E128

Posted by Nobody/Anonymous on December 21, 2005
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

RE: HCS12C32 to HCS12E128

Posted by Richard on December 21, 2005
Thanks for sharing this valuable information!

RE: HCS12C32 to HCS12E128

Posted by Jeff Smith on December 29, 2005
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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS