bf561 Blackfin FreeRTOS thực hiện thất bại trong thời gian chạy khi tải một nhiệm vụ

Question

tôi đã thực hiện trong Blackfin BF561 coreB FreeRTOS từ mã:

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

tôi chuyển đổi sang kim loại trần như thực thi tinh sử dụng gcc.

Tôi đóng nhưng tôi có lỗi thời gian chạy mà tôi không thể hiểu được. Khi bộ lập lịch bắt đầu và cố gắng kích hoạt nhiệm vụ đầu tiên, con trỏ bộ nhớ bị mất và nó không bắt đầu ngăn xếp đầu tiên, thay vào đó bắt đầu một hàm bên trong nhiệm vụ đầu tiên và bị mất khi đi ra khỏi hàm.

đây là debug log tương ứng:

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 

và đây là discution tôi bắt đầu trên diễn đàn Thiết bị Analog:

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

Answer 1

Ok cuối cùng tôi giải quyết vấn đề. vấn đề là mã assembler không trả về từ hàm gián đoạn mã vContext với RTI, thay vào đó nó đi thẳng tới hàm mã assembler tiếp theo, đó là ngắt hẹn giờ có cùng vấn đề và do đó con trỏ ngăn xếp sau đó sẽ đến địa chỉ tiếp theo là địa chỉ bắt đầu cho hàm app_init .....

Có thể là do thực tế câu lệnh RTI được thực hiện trong MACRO được gọi bởi hàm vContextSwitch, tôi là không chắc.

Tôi đã sửa nó bằng cách chuyển đổi chức năng lắp ráp thành chức năng C và giờ trở về ngăn xếp từ công việc ngắt đúng cách và sự cố được khắc phục. Lưu ý rằng lỗi bổ sung đã được tìm thấy sau đó đã bị lãng quên chức năng bộ nạp nhiệm vụ móc trong bộ lập lịch khi gọi vContextSwhitch cũng như thẻ của hàm móc mà không bao giờ được ghi lại trong ngữ cảnh của tác vụ.

Tất cả đã được sửa.

Best Regards,

William