FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2005 Threads] CodeWarrior Compile problemPosted by Zhu Guohun on 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?
RE: CodeWarrior Compile problemPosted by Richard on 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?
RE: THX the problem againPosted by Zhu Guohun on 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
RE: THX the problem againPosted by Richard on 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
RE: CodeWarrior Compile problemPosted by Zhu Guohun on 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.
RE: CodeWarrior Compile problemPosted by Richard on 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.
RE: CodeWarrior Compile problemPosted by Zhu Guohun on February 15, 2005 Thank you, I have send the code to you, please check it. when goto my task code the pxCurrentTCB is HeapSTRUCT_SIZE0x8 ulCriticalnesting0x0 pxCurrentTCB 0x40000180 .pxTopOfStack 0x40000388 value=0 .pxStack 0x400001D0 value=00xA5A5A5A5 .uStackDepth0x80 .pcTaskName"LED" .ucPriority. .XGenericListItem .xItemValue0 .pxNext0x4000008c .pxPrevious0x4000008c .pvOwner0x40000180 .pxContainer0x40000080 .xEventListItem .xItemValue3 .pxNext0 .pxPrevious0 .pvOwner0x40000180 .pvContainer0 .ucTCBNumber0
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
RE: CodeWarrior Compile problemPosted by Richard on 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?
RE: CodeWarrior Compile problemPosted by Zhu Guohun on 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
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|