How can I porting lpc2129 demo to lpc2468

oldmee wrote on Wednesday, April 30, 2008:

hi all
I am using IAR kickstart kit for lpc2468. I have tried to porting lpc2129 code
to lpc2468 a few times in past week. what I did is:

1.download lpc2129 freertos demo code for IAR IDE.
2.It was compiled with no erro and warning
3.Changing processor option setting in IAR IDE from lpc2129 to lpc2468
4.changing lpc2129 header file to lpc2468.
5.fix a few compiling error by rename and add couple variables.
6. Notice PLL setup has changed, so copy some code from other demo to this project

what I get now:
1.I can let the code running through LED flash task creat.
2.Get data or undefine abort after scheduler start. The idel task or LED flash task
  what ever own cpu time.

Need help!
what is the fast and safe ways to porting exiting lpc2129 IAR demo to lpc2468 with same
IAR setting.

Thanks in advance for your valuable time of any input here 

Steve

rtel wrote on Wednesday, April 30, 2008:

Hi Steve,

I just replied to your post on the LPC2000 group.  For completeness I have posted the same reply below:

> Here is my story. Download lpc2129 porting(IAR IDE) from freertos
> websit.

So you are starting with a working project.  This is good as it means you will have the correct setup and things should compile straight off.  However, it might be that you need to change the configuration of the timer that generates the RTOS tick, as it is likely to be a bit different on the 2468 compared to the 2129.

The timer configuration is contained in a function called prvSetupTimerInterrupt() which can be found in port.c.  For GCC there are two different versions, one can be found in Source\portable\GCC\ARM7_LPC2000\port.c, and the other in Source\portable\GCC\ARM7_LPC23xx\port.c.  I have not checked the data sheet but it is likely that you will require the latter version.  You can copy the changes from the referenced GCC version into your IAR files.

> and demo board (lpc2468) from IAR too. Made a few changing:
> 1. changed processor to lpc2468 option in IAR IDE setting.
> 2. changed processor header file from lpc2129 to lpc2468
> 3. notice there are some differenc in PLL area, made some
> changed there.
>
> what I can run now:
> 1. can turn LED on and off without OS start creat tasks.

That is encouraging, so there is a good chance that the linker script and processor configuration are good.

> 2. afer running into OS code, has data or undefine abort.
> 3. the abort happen after schedulor start.

Do you ever hit the first task?  Put a break point at the beginning of the highest priority task to see if you ever reach it.  If not then it is likely that the MCU is in the wrong mode when you start the scheduler.

Also check that the call to xTaskStartScheduler() never returns, to do so would be indicative of having too smaller heap to allow the idle task to be created.

> I am thinking that I am facing a configuraton problem. Have tried
> to modify code in startup.s and freertosconfig.h and others which
> freertos suggest to take a look. Well, I am still no lucky to let
> it running.

What did you change in startup.s?  Can you check that the MCU is in Supervisor mode when main() is called?  This is the most likely cause of the problem.

Startup.s should also allocate stacks for IRQ mode, FIQ only if used, and Supervisor modes.  If using the 2129 project as a base you should also setup the VIC to vector directly to an ISR handlers as well as making sure that the vPortYieldProcessor is installed as the SWI handler.  If you are using the demo project startup file then this should all be done already.

Regards

oldmee wrote on Wednesday, April 30, 2008:

hi Richard:
>> 2. afer running into OS code, has data or undefine abort.
>> 3. the abort happen after schedulor start.
> Do you ever hit the first task? Put a break point at the beginning of the >highest priority task to see if you ever reach it. If not then it is likely >that the MCU is in the wrong mode when you start the scheduler.

>Also check that the call to xTaskStartScheduler() never returns, to do so >would be indicative of having too smaller heap to allow the idle task to be >created.

In the main funcaton, vTaskStartScheduler   —> xPortStartScheduler()
with first run prvSetupTimerInterrupt(), then go vPortStartFirstTask();   
I first to see the problem is in last code of vPortStartFirstTask()
(in here same as portRESTORE_CONTEXT) 
; And return - correcting the offset in the LR to obtain the    
; correct address.                                     SUBS    PC, LR, #4

I can not step through the code, which casue a data abort. But there is way
to walk around(I don’t understand why) is step into it. them take me to

static portTASK_FUNCTION( prvIdleTask, pvParameters ) "in System mode now"

then step to

if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ tskIDLE_PRIORITY ] ) ) > ( unsigned portBASE_TYPE ) 1 )
{
                            
  taskYIELD();
}

abort here in code " SWI 0"

>> I am thinking that I am facing a configuraton problem. Have tried 
>> to modify code in startup.s and freertosconfig.h and others which
>> freertos suggest to take a look. Well, I am still no lucky to let
>> it running.

>What did you change in startup.s? Can you check that the MCU is in Supervisor >mode when main() is called? This is the most likely cause of the problem

In startup.s file ,I tried to change MAM to zero ( it won’t help ).
The MCU is in Supervisor mode when main() is called.

Thanks

Steve

rtel wrote on Wednesday, April 30, 2008:

I’m not sure why the first task to run would be the idle task.  Do you create any higher priority tasks, or are all your tasks at priority 0?

>abort here in code " SWI 0"

Can you check that the SWI handler is installing in startup.s (as per my previous email) but it should be as you are using the same startup.s file.  I recall there was some conditional compilation around the vector table so best to double check.

Plus, also check that the SWI handler is compiled to ARM mode, not THUMB mode.

Regards.

oldmee wrote on Wednesday, April 30, 2008:

>I’m not sure why the first task to run would be the idle task. Do you create >any higher priority tasks, or are all your tasks at priority 0?

That was I took out all code about running a task such as LEDflash. and now I put LEDflash code back.

the startschuduler return to
static portTASK_FUNCTION( vLEDFlashTask, pvParameters )

then code abort here
      /* Update so the next task uses the next LED. */
        uxFlashTaskNumber = uxFlashTaskNumber + 1;

as
undef_handler
    b         undef_handler

>>abort here in code " SWI 0" 

>Can you check that the SWI handler is installing in startup.s (as per my >previous email) but it should be as you are using the same startup.s file. I >recall there was some conditional compilation around the vector table so best >to double check.

>Plus, also check that the SWI handler is compiled to ARM mode, not THUMB mode.

SWI handler in here, should go to vPortYieldProcessor call. It looks like run to THUMB mode. How Can I find out?
the code is vPortYieldProcessor:

ADD  LR, LR, #4          ;Add 4 to the LR to make the LR appear exactly
                  ; as if the context was saved during and IRQ; handler.
                               
portSAVE_CONTEXT             ; Save the context of the current task…

LDR R0, =vTaskSwitchConte; before selecting the next task to execute.
    mov     lr, pc
    BX R0
    portRESTORE_CONTEXT        

    here is my startup.s

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Part one of the system initialization code,
;; contains low-level
;; initialization.
;;
;; Copyright 2006 IAR Systems. All rights reserved.
;;
;; $Revision: 10608 $
;;

        MODULE  ?cstartup

        ;; Forward declaration of sections.
        SECTION IRQ_STACK:DATA:NOROOT(3)
        SECTION ABT_STACK:DATA:NOROOT(3)
        SECTION SVC_STACK:DATA:NOROOT(3)
        SECTION UND_STACK:DATA:NOROOT(3)
        SECTION FIQ_STACK:DATA:NOROOT(3)
        SECTION CSTACK:DATA:NOROOT(3)

;
; The module in this file are included in the libraries, and may be
; replaced by any user-defined modules that define the PUBLIC symbol
; __iar_program_start or a user defined start symbol.
;
; To override the cstartup defined in the library, simply add your
; modified version to the workbench project.

        SECTION .intvec:CODE:NOROOT(2)

        PUBLIC  __vector
        PUBLIC  __vector_0x14
        PUBLIC  __iar_program_start
    EXTERN    vPortYieldProcessor

        ARM
__vector:
        ;;
        ldr   pc,[pc,#+24]              ;; Reset
        ldr   pc,[pc,#+24]              ;; Undefined instructions
;;        ldr   pc,[pc,#+24]              ;; Software interrupt (SWI/SVC)
        b vPortYieldProcessor
        ldr   pc,[pc,#+24]              ;; Prefetch abort
        ldr   pc,[pc,#+24]              ;; Data abort
__vector_0x14
        DC32  0                         ;; RESERVED
        ldr   pc, [PC, #-0x120]         ;; IRQ
        ldr   pc,[pc,#+24]              ;; FIQ

        DC32  __iar_program_start       ;; Reset
        DC32  undef_handler             ;; Undefined instructions
        DC32  0       ;; Software interrupt (SWI/SVC)
        DC32  prefetch_handler          ;; Prefetch abort
        DC32  data_handler              ;; Data abort
        DC32  0                         ;; RESERVED
        DC32  0                           ;; IRQ
        DC32  fiq_handler               ;; FIQ

undef_handler
    b         undef_handler
   
prefetch_handler
    b         prefetch_handler

data_handler
    b         data_handler

fiq_handler
    b         fiq_handler
; --------------------------------------------------
; ?cstartup – low-level system initialization code.
;
; After a reser execution starts here, the mode is ARM, supervisor
; with interrupts disabled.
;

        SECTION .text:CODE:NOROOT(2)

;        PUBLIC  ?cstartup
        EXTERN  ?main
        REQUIRE __vector

        ARM

__iar_program_start:
?cstartup:

;
; Add initialization needed before setup of stackpointers here.
;

; Errata  MAM.1Incorrect read of data from SRAM after Reset and MAM
; is not enabled or partially enabled.
; Work-around: User code should enable the MAM after Reset and before
; any RAM accesses
MAMCR    DEFINE  0xE01FC000     ; MAM Control Register
MAMTIM   DEFINE  0xE01FC004     ; MAM Timing register

        ldr     r0,=MAMCR
        ldr     r1,=MAMTIM
        ldr     r2,=0
        str     r2,[r0]
         ldr     r2,=3     ; 1 < 20 MHz; 20 MHz < 2 < 40 MHz; 40MHz > 3
      ;;  ldr     r2,=0     ; 1 < 20 MHz; 20 MHz < 2 < 40 MHz; 40MHz > 3
        str     r2,[r1]
      ldr     r2,=2
      ;;  ldr     r2,=0
        str     r2,[r0]

; Initialize the stack pointers.
; The pattern below can be used for any of the exception stacks:
; FIQ, IRQ, SVC, ABT, UND, SYS.
; The USR mode uses the same stack as SYS.
; The stack segments must be defined in the linker command file,
; and be declared above.
;
; --------------------
; Mode, correspords to bits 0-5 in CPSR
MODE_BITS DEFINE  0x1F    ; Bit mask for mode bits in CPSR
USR_MODE  DEFINE  0x10    ; User mode
FIQ_MODE  DEFINE  0x11    ; Fast Interrupt Request mode
IRQ_MODE  DEFINE  0x12    ; Interrupt Request mode
SVC_MODE  DEFINE  0x13    ; Supervisor mode
ABT_MODE  DEFINE  0x17    ; Abort mode
UND_MODE  DEFINE  0x1B    ; Undefined Instruction mode
SYS_MODE  DEFINE  0x1F    ; System mode

        MRS     r0, cpsr                ; Original PSR value

        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #ABT_MODE       ; Set ABT mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(ABT_STACK)     ; End of ABT_STACK

        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #SVC_MODE       ; Set SVC mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(SVC_STACK)     ; End of SVC_STACK

        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #UND_MODE       ; Set UND mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(UND_STACK)     ; End of UND_STACK

        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #FIQ_MODE       ; Set FIQ mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(FIQ_STACK)     ; End of FIQ_STACK

        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #IRQ_MODE       ; Set IRQ mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(IRQ_STACK)     ; End of IRQ_STACK

        BIC     r0 ,r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0 ,r0, #SYS_MODE       ; Set System mode bits
        MSR     cpsr_c, r0              ; Change the mode
        LDR     sp, =SFE(CSTACK)        ; End of CSTACK

#ifdef __ARMVFP__
        ;; Enable the VFP coprocessor.

        MOV     r0, #0x40000000         ; Set EN bit in VFP
        FMXR    fpexc, r0               ; FPEXC, clear others.

;
; Disable underflow exceptions by setting flush to zero mode.
; For full IEEE 754 underflow compliance this code should be removed
; and the appropriate exception handler installed.
;

        MOV     r0, #0x01000000         ; Set FZ bit in VFP
        FMXR    fpscr, r0               ; FPSCR, clear others.
#endif

;
; Add more initialization here
;
        BIC     r0, r0, #MODE_BITS      ; Clear the mode bits
        ORR     r0, r0, #SVC_MODE       ; Set SVC mode bits
        MSR     cpsr_c, r0              ; Change the mode
       
; Continue to ?main for C-level initialization.

        LDR     r0, =?main
        BX      r0

        END
   

rtel wrote on Wednesday, April 30, 2008:

>then code abort here 
>/* Update so the next task uses the next LED. */
>uxFlashTaskNumber = uxFlashTaskNumber + 1;

There is nothing here that could abort, so I’m guessing that you got a tick interrupt at this point, and that was the source of the abort.  I cannot see anything wrong though.  Hmm.  Is there anything particularly different about this LPC2000 device compared to the smaller devices?  Can you look in the startup code provided by IAR for this device to see if it does anything extra.

Regards.

oldmee wrote on Wednesday, April 30, 2008:

hi Richard:
Thanks your constant support, feeling much better now(it is such a good thing
to have people to talk about it GOOD or BAD ).

I will take a look code that I download from HITEX, they did a porting to lpc2468.

Thanks you very much

PS: I will post you what I have learn from them

oldmee wrote on Wednesday, April 30, 2008:

hi Richard:
I was think that too, but why the tick interrupt  always kick me on same position, same code in every time I debug ?

Steve