This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LPC2368 - Execute code out of RAM

I am attempting to execute code out of RAM.

I proved the concept by writing a simple LED blinky function and running it out of RAM. I actually got it work on the MCB2300 Dev Board.

My method is as follows - create an array/buffer to allocate some space on the stack (SRAM). The buffer must be large enough for the function and I get the size from the memory map. I then page align the buffer and copy the function into the buffer and execute.

    unsigned char codeBuffer[1024];

    unsigned char *alignedCodeBuffer = (unsigned char*)( ((int)codeBuffer + 256) & 0xFFFFFF00 );

    void (*functionPointer)(void) = (void(*)(void))alignedCodeBuffer;

    memcpy( (void*)alignedCodeBuffer, (void*)&toggleLed1, sizeof(codeBuffer) - 256 );

    VICIntEnClr = 0xFFFFFFFF;  //Disable all Interrupts

    functionPointer();

The problem now is that I moved this code to my real application and I am getting taken to

 DAbt_Addr       DCD     DAbt_Handler

I need my code to have relative addressing. Looking through the disassembly window, I see absolute addressing, or, references to the FLASH address space. Notice the 0x0000D67C.

0x0000D67C  E1B01000  MOVS      R1,R0
0x0000D680  E2400001  SUB       R0,R0,#0x00000001
0x0000D684  1AFFFFFC  BNE       0x0000D67C

Am I doing something wrong besides the obvious that it isn't working.

Is there a compiler flag I am missing?

Another possible solution is to replace the BNE instruction with a combination of other assembly instructions to move the PC back a few times.

Parents
  • Looking through the disassembly window, I see absolute addressing,
    No, you don't. You see PC-relative addressing, which the disassembler is helpfully displaying as the target address it resolves to. The clue is in the difference between the disassembly and the actual code bytes to the left of it.

    The more likely reason for you ending up in the Abort handler would be that you got your alignment wrong. Remember that Thumb code is defined by being at odd addresses.

Reply
  • Looking through the disassembly window, I see absolute addressing,
    No, you don't. You see PC-relative addressing, which the disassembler is helpfully displaying as the target address it resolves to. The clue is in the difference between the disassembly and the actual code bytes to the left of it.

    The more likely reason for you ending up in the Abort handler would be that you got your alignment wrong. Remember that Thumb code is defined by being at odd addresses.

Children