FreeRtos executing On Off chip RAM

Hello, I m trying to run a freertos on off chipp RAM using an LPC2212 micro, and i get a problem when activating SWI interrupt by calling (”SVC 0″) in the function vPortYield existing in PortAsm.s file. the beahviour wich i saw that the PC jump to internal Flash just after this call, and i m sure that i have well configured the VIC to run in the external memory on the Startup.s Can you help me please. Best Regards

FreeRtos executing On Off chip RAM

Do you successfully have an application that uses SVC 0 running out of RAM, without FreeRTOS?  That would help narrow down if this is indeed a FreeRTOS problem, or just a configuration problem.  For example, maybe the vector table is not configured correct for RAM execution. Regards.

FreeRtos executing On Off chip RAM

I have an application that runs on On chipp ROM and uses SVC 0 with freeRtos, and when calling SVC 0, i have the software interrupt running so,  i call the vPortYieldProcessor for FreeRtos task switching context. in this case i have no problem. my code to configure the VIC running on the external RAM is : MEMMAP                        EQU 0xE01FC040
MEMMAP_VALUE                  EQU 0x02 MemRemap
    LDR     r0, =MEMMAP
    MOV     r1, #MEMMAP_VALUE
   STR     r1,
    MOV     pc, lr Best regards

FreeRtos executing On Off chip RAM

Do you successfully have an application that uses SVC 0 running out of RAM, without FreeRTOS?

FreeRtos executing On Off chip RAM

No,

FreeRtos executing On Off chip RAM

You may be using the wrong terminology, but the VIC doesn’t control where  SWI goes on ARM processors. ARM processors have an exception vector table, of which SWI is one entry and the VIC is another, which is normally at the bottom of memory. Some implementations of the ARM allow you to map different memories into the lower address space to let you change what is in the exception vector table, and some let you map the exception vector table to another address to do this, The fact that SWI jumps to low memory tells me that you haven’t successfully remapped the table to a different address (if it is even possible on your chip, I am not fluent with the LP series). You need to check the documentation for your chip and see what the proper way to replace the exception vector table is, and make sure your startup code is doing this. This is very chip dependent.

FreeRtos executing On Off chip RAM

thanks and sorry for the wrong terminology,
My exception vector table is mapped on the External RAM (Adress 0x81000000) and is as : ; Area Definition and Entry Point
;  Startup Code must be linked first at Address at which it expects to run.                 AREA    Reset, CODE, READONLY
                ARM Vectors
;//////////////////////////////////////////////////////
;// VECTEURS D’INTERRUPTION AU DEMARRAGE DU CODE
;//////////////////////////////////////////////////////
  LDR   PC, =ResetHandler    ;0x00: vecteur de reset
  B     MainExceptionHandler ;0x04: instruction inexistante
  B vPortYieldProcessor           ;0x08: interruption logicielle
  B MainExceptionHandler ;0x0C: erreur chargement instruction
  B MainExceptionHandler ;0x10: data abort
  NOP                       ;0x14: inutilise, on y met l”adresse du handler IRQ
  LDR     PC,       ; Vector from VicVectAddr
  LDR     PC,       ; Vector from VicVectAddr
VectorEnd ResetHandler
   ; All needed Configuratrion Normally, when calling SVC 0 form vPortYield, we must go to 0x08 Adress of exception vector table (equivalent to the adress 0x81000008 of External RAM) and we execute the vPortYieldProcessor? but the behavior that the PC goes to the adress 0x0000000C of internal flash. What can be the problem? thank’s a lot for your help Best Regards

FreeRtos executing On Off chip RAM

Ok, thank’s a lot

FreeRtos executing On Off chip RAM

Are you sure you have told the chip to remap the interrupt vector (you obviously haven’t as it is going to the wrong address). Just declaring the vectors at that address isn’t going to make the CPU do it. Looking at the Data Sheet for that part, this is controlled by the state of some pins on the CPU, are those configured correctly?