2011-12-18 7 views
5

he implementado en Blackfin BF561 coreB FreeRTOS del código:BF561 aleta negra aplicación FreeRTOS fallar en tiempo de ejecución cuando se carga una tarea

http://www.freertos.org/index.html?http://interactive.freertos.org/forums/79366-analog-devices

que convierte al metal desnudo como ejecutable elf con gcc.

Estoy cerca, pero tengo un error de tiempo de ejecución que no puedo resolver. Cuando el planificador se inicia e intenta activar la primera tarea, el puntero de la memoria se pierde y no inicia la primera pila, sino que inicia una función dentro de la primera y se pierde al salir de la función.

este es el correspondiente registro de depuración:

COREB: end setup LED                
COREB: handler declared               
COREB: Initialise New TCB:NewTCB address: 3d01000        
COREB: TopofStask: 0, pxTopOfStack = 3d0263c          
COREB: pxTaskCode =3c033a0, pvParameters = 0          
COREB: returned pxNewTCB->pxTopOfStack = 3d02588         
COREB: task created:                
COREB: top of stack: 3d02588              
COREB: GenericListItem: 0              
COREB: Event ListItem: 9               
COREB: Priority: 1                
COREB: start of stack: 3d02000             
COREB: Task Name: BootTas              
COREB: TCB number: 0                
COREB: Task Tag: 0                
COREB: Add the idle task at the lowest priority         
COREB: Initialise New TCB:NewTCB address: 3d03000        
COREB: TopofStask: 0, pxTopOfStack = 3d0431c          
COREB: pxTaskCode =3c0295c, pvParameters = 0          
COREB: returned pxNewTCB->pxTopOfStack = 3d04268         
COREB: task created:                
COREB: top of stack: 3d04268              
COREB: GenericListItem: 0              
COREB: Event ListItem: a               
COREB: Priority: 0                
COREB: start of stack: 3d04000             
COREB: Task Name: IDLE               
COREB: TCB number: 1                
COREB: Task Tag: 0                
COREB: end Add the idle task at the lowest priority        
COREB: if xReturn == 1, and xReturn = 1           
COREB: before disable interupt             
COREB: after disable interupt             
COREB: before xPortStartScheduler            
COREB: start xPortStartScheduler fn before set core timer      
COREB: after ContextSwitch interupt flag           
COREB: before prvSetupTimerInterrupt            
COREB: after prvSetupTimerInterupt            
COREB: Task Switch context called            
COREB: The scheduler is running             
COREB: trace switched out TCB:ff700bf8           
COREB: name of switch out task:efore xPortStartScheduler      

COREB: before Task first check for stack overflow        
COREB: Task first check for stack overflow called        
COREB: Task second check for stack overflow called        
COREB: before call get owner of next entry          
COREB: get owner of next entry:             
COREB: current TCB 3d01000              
COREB: pxReadyTasksLists[ uxTopReadyPriority ] = 1        
COREB: TCB content:                
COREB: top of stack: 3d02588              
COREB: GenericListItem: 0              
COREB: Event ListItem: 9               
COREB: Priority: 1                
COREB: start of stack: 3d02000             
COREB: Task Name: BootTas              
COREB: TCB number: 0                
COREB: Task Tag: 0                
COREB: trace switched in:BootTas             
COREB: write trace to buffer              
COREB: task increment tick: 1             
COREB: end of app init               
COREB: execption 2b addr ff700be4            
COREB: coreb dump stack               
COREB: found fp: ff700b64 

y este es el discution Empecé en el foro Analog Device:

http://ez.analog.com/message/38669#38669

Respuesta

0

Ok finalmente resolver el problema. el problema era que el código del ensamblador no regresaba de la función de interrupción del código vContext con el RTI, sino que pasaba directamente a la siguiente función del código del ensamblador, que era la interrupción del temporizador que tenía el mismo problema y por lo tanto el puntero de la pila a la siguiente dirección que sea la dirección inicial de la función app_init .....

Puede que el problema se deba a que la declaración RTI se realizó en un MACRO llamado por la función vContextSwitch, estoy no es seguro.

Lo arreglé convirtiendo esa función de ensamblador en función C y ahora el retorno de la pila de la interrupción funciona correctamente y el problema está solucionado. Tenga en cuenta que se encontró un error adicional después de lo que se olvidó de la función del cargador de tareas hook en el planificador cuando se llama a vContextSwhitch, así como a la etiqueta de la función de enlace que nunca se grabó en el contexto de la tarea.

Todo arreglado ahora.

Best Regards,

William

Cuestiones relacionadas