Blackfin BF561 implementazione FreeRTOS fallire in fase di esecuzione durante il caricamento di un compito

Question

Ho implementato in Blackfin BF561 COREB FreeRTOS dal codice:

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

ho convertito in metallo nudo come elfo eseguibile utilizzando gcc.

Sono vicino ma ho un errore di runtime che non riesco a capire. Quando lo scheduler si avvia e tenta di attivare la prima attività, il puntatore della memoria si perde e non avvia il primo stack, invece avvia una funzione all'interno della prima attività e si perde quando esce dalla funzione.

questo è il corrispondente registro di debug:

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 

e questo è il discution ho iniziato sul forum Analog Device:

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

Answer 1

Ok ho finalmente risolvere il problema. il problema era che il codice assembler non veniva restituito dalla funzione di interruzione del codice vContext con l'RTI, invece passava direttamente alla successiva funzione del codice assemblatore, che era l'interrupt del timer che aveva lo stesso problema e quindi il puntatore dello stack stava andando al prossimo indirizzo che risulta essere l'indirizzo di partenza per la funzione app_init .....

Il problema era dovuto al fatto che l'istruzione RTI era stata creata in una MACRO chiamata dalla funzione vContextSwitch, sono non sono sicuro.

L'ho risolto convertendo la funzione assembler in funzione C e ora il ritorno dello stack dall'interrupt funziona correttamente e il problema è risolto. Si noti che è stato rilevato un errore aggiuntivo dopo quello che è stato dimenticato della funzione di caricamento task hook nello scheduler quando si chiama vContextSwhitch e il tag della funzione hook che non è mai stata registrata nel contesto dell'attività.

Tutto risolto ora.

migliori saluti,

William