zhuguohun wrote on Sunday, February 13, 2005:
I Compile the FreeRtos with codewarrior, there a problem after simulate, it is always fail on debug when execute the user task coding:
undefined instruction
Why?
rtel wrote on Sunday, February 13, 2005:
Unfortunately I am not familiar with CodeWarrior. Is it a GUI for the GCC compiler - as per CrossWorks? If so then how is the linker file and startup code produced?
zhuguohun wrote on Monday, February 14, 2005:
Firstly compiler the command line is below
-info totals -entry 0x00000000 -ro-base 0X00000000 -rw-base 0X40000000 -first VECTORS.O(Startup)
Secondly I try to debug and puzzle
when the taskYIELD is called (SWI)
but the function
void vPortYieldProcessor( void ) __irq;
has no responsed,
in other words, the function
portRESTORE_CONTEXT was calling but the function portSAVE_CONTEXT has never run.
So I guess the portSAVE_CONTEXT should be call before portRESTORE_CONTEXT, is ture or false?
Thank you again
rtel wrote on Monday, February 14, 2005:
Although you don’t say - from the command line and the __irq extension I am guessing that CodeWarrior is not a GCC wrapper GUI.
>Secondly I try to debug and puzzle
>when the taskYIELD is called (SWI)
>but the function
>void vPortYieldProcessor( void ) __irq;
>has no responsed,
Has the SWI interrupt handler been installed. Does the SWI vector point to the vPortYieldProcessor() function. This should be set up in your startup code.
>So I guess the portSAVE_CONTEXT should be
>call before portRESTORE_CONTEXT, is ture or
>false?
When the scheduler is initially started the stack is already set up, so *only* portRESTORE_CONTEXT should be called.
During a context switch when the scheduler is running both should be called.
Thank you again
zhuguohun wrote on Monday, February 14, 2005:
Sorry to say the CodeWarrior, it is not the Gui for Gcc,
Would you like give me you email, I send the code which modified by mine, and maybe you can point how to solve the problem.
Thank you.
rtel wrote on Monday, February 14, 2005:
If you send the code to the email address available on the Contacts page of the FreeRTOS.org WEB site I can have a look - but I don’t have CodeWarrior and cannot therefore support it directly.
Regards.
zhuguohun wrote on Tuesday, February 15, 2005:
Thank you, I have send the code to you, please check it.
when goto my task code
the pxCurrentTCB is
HeapSTRUCT_SIZE 0x8
ulCriticalnesting 0x0
pxCurrentTCB 0x40000180
.pxTopOfStack 0x40000388 value=0
.pxStack 0x400001D0 value=00xA5A5A5A5
.uStackDepth 0x80
.pcTaskName "LED"
.ucPriority .
.XGenericListItem
.xItemValue 0
.pxNext 0x4000008c
.pxPrevious 0x4000008c
.pvOwner 0x40000180
.pxContainer 0x40000080
.xEventListItem
.xItemValue 3
.pxNext 0
.pxPrevious 0
.pvOwner 0x40000180
.pvContainer 0
.ucTCBNumber 0
Current Register values
r0=0
r1=0x01010101
r2=0x02020202
r3=0x03030303
r4=0x04040404
r5=0x05050505
r6=0x06060606
r7=0x07070707
r8=0x08080808
r9=0x09090909
r10=0x10101010
r11=0x11111111
r12=0x12121212
r13=0x4000003cc
r14=0xAAAAAAAA
pc=0x00001E0
cpsr=nzcvqifT_SYS
spsr=Unavailable
LedTask
000001e0 [0xe92d4070] * stmfd r13!,{r4-r6,r14}
000001e4 [0xe59f0124] ldr r0,0x00000310 ; = #0xe002c000
000001e8 [0xe5901000] ldr r1,[r0,#0]
000001ec [0xe5801000] str r1,[r0,#0]
000001f0 [0xe5901004] ldr r1,[r0,#4]
000001f4 [0xe5801004] str r1,[r0,#4]
000001f8 [0xe2406c40] sub r6,r0,#0x4000
000001fc [0xe5960008] ldr r0,[r6,#8]
00000200 [0xe3800f54] orr r0,r0,#0x150
00000204 [0xe5860008] str r0,[r6,#8]
---------------------------------------
step next -->error occur
------------------------------------------
00000004 [0xe59ff018] ldr pc,UndefinedAddr ; = #UndefinedAddr
rtel wrote on Tuesday, February 15, 2005:
Hi,
Without the tools all I can do is look at the source code to see if I can see anything wrong. From what I can see you have based your CodeWarrior project on the Keil demo, making the changes listed in your last post.
Current Register values
r0=0
r1=0x01010101
r2=0x02020202
r3=0x03030303
r4=0x04040404
r5=0x05050505
r6=0x06060606
r7=0x07070707
r8=0x08080808
r9=0x09090909
r10=0x10101010
r11=0x11111111
r12=0x12121212
r13=0x4000003cc
r14=0xAAAAAAAA
These all appear to be what is expected. The registers have their default initial values which shows that the first RESTORE_CONTEXT has worked as expected.
pc=0x00001E0
Again this looks correct, the first instruction in your LED task.
portmacro.h —>
extern __inline void portSAVE_CONTEXT(void);
extern __inline void portRESTORE_CONTEXT(void);
__inline void portENABLE_INTERRUPTS(void)
__inline void portDISABLE_INTERRUPTS(void)
These are now defined in the ISR_Support.s file. The context save/restore macros *MUST* be inline and it might be that the compiler will ignore the __inline keywork in this case. Can you check the assembly output to make sure that the portENABLE/DISABLE_CONTEXT macros are really being inlined and there is no function call being generated by the compiler.
You appear to have setup the stack for the supervisor and IRQ modes. Does your task start in System mode? I presume this is what nzcvqifT_SYS means.
Also are you running in ARM mode only, or ARM/THUMB interwork mode? It appears that the code is compiler for ARM mode (32bit) but I cannot tell from the nzcvqifT_SYS value whether you are in ARM or THUMB mode. Does the T in nzcvqifT_SYS mean THUMB mode?
zhuguohun wrote on Tuesday, February 15, 2005:
Thank you for your help.
-----------------------------------------------
These are now defined in the ISR_Support.s file. The context save/restore macros *MUST* be inline and it might be that the compiler will ignore the __inline keywork in this case. Can you check the assembly output to make sure that the portENABLE/DISABLE_CONTEXT macros are really being inlined and there is no function call being generated by the compiler.
-----------------------------------------------
I disassemble the function
vPortISRStartFirstTask
B portRESTORE_CONTEXT
vPortYieldProcessor
0x00000004: e92d500f .P-. STMFD r13!,{r0-r3,r12,r14}
0x00000008: ebfffffe … BL portSAVE_CONTEXT
0x0000000c: ebfffffe … BL vTaskSwitchContext
0x00000010: ebfffffe … BL portRESTORE_CONTEXT
0x00000014: e8bd500f .P… LDMFD r13!,{r0-r3,r12,r14}
0x00000018: e25ef004 …^. SUBS pc,r14,#4
so it is not the truely inline
-----------------------------------------
…I presume this is what nzcvqifT_SYS means
---------------------------------------------
the last init stack coding as belwo
…
; /* We want to start in supervisor mode. Operation will switch to system
; mode when the first task starts. */
msr CPSR_c, #MODE_SVC|I_BIT|F_BIT
mov sp, r0
------------------------------------
Also are you running in ARM mode only, or ARM/THUMB interwork mode
------------------------------------
Yes, the code run in ARM only