Blackfin BF561 realizacja FreeRTOS nie w czasie wykonywania podczas ładowania zadanie

Question

I zostały wdrożone w Blackfin BF561 coreB FreeRTOS z kodem:

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

konwertowane do gołego metalu jako elf wykonywalnego używając gcc.

Jestem blisko, ale mam błąd runtime, którego nie mogę odczytać. Gdy program planujący rozpoczyna i próbuje wyzwolić pierwsze zadanie, wskaźnik pamięci gubi się i nie uruchamia pierwszego stosu, zamiast tego uruchamia funkcję wewnątrz pierwszego zadania i gubi się podczas wychodzenia z funkcji.

ten jest odpowiedni dziennik debugowania:

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 

i to jest discution zacząłem na forum urządzeniem analogowym:

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

Answer 1

Ok I wreszcie rozwiązać problem. Problem polegał na tym, że kod assemblera nie powrócił z funkcji przerwania kodu vContext z RTI, zamiast tego został przekierowany do następnej funkcji kodu assemblera, która była przerwaniem timera, które miało ten sam problem, a tym samym wskaźnik stosu na następny adres, który był początkowym adresem dla funkcji app_init .....

Może problem był spowodowany faktem, że instrukcja RTI została wykonana w MACRO wywołanym przez funkcję vContextSwitch, jestem niepewny.

Naprawiłem to, konwertując te funkcje asemblera na funkcję C, a teraz stos powrotny z przerwania działa poprawnie i problem został naprawiony. Zauważ, że wykryto dodatkowy błąd po tym, który został zapomniany o funkcji programu ładującego hook w harmonogramie podczas wywoływania vContextSwhitch, jak również tag funkcji hook, która nigdy nie została zarejestrowana w kontekście zadania.

Wszystkie ustalone teraz.

Pozdrawiam,

William