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

Execute in RAM program loaded on Flash

Hello,

I work with an EASY UTAH board with C161U microprocessor and a Flash ST M29F040B 90K1 on target. I'd like to have my program loaded on Flash but executed on RAM.
First I work with the blinky example to check the well functionning. When I load the blinky program to flash with the Flash Tool provided by Infineon, I effectively see that the led switch well.

For executing the program in RAM, I wrote two different applications, one with the startup code and a copy routine for copying code from flash (segment 1) to RAM. I load this startup application in Flash at segment 0.

The second program is the blinky one (without startup code) that I load in Flash at segment 1.

When I reset the board, I could observe on oscilloscope a lot of access to flash (CS0) and RAM (CS1). But the led doesn't switch.

In the startup code I specify CS1/RAM from 0x80000 with a size of 4K.


I am really new to this so I don't know if the program is freeze doing the copying loop from flash to RAM, or if the execution is wrong. Someone have an idea of what is happening?

Just to say that I don't want to use the application note 138 because I think this is not the solution to my problem. Effectively I want all my program executed in RAM and not only the critical routines.

If someone have an idea or have same problems, I will be very grateful to have some help and to understand what I'm doing wrong. Thanks

Regards

Parents
  • I believe the blinky program uses interrupts which reside at 0x00'0000 - probably still in Flash space after the copy. There are several ways to get around this:

    1) Don't use interrupts - not very good solution.

    2) Re-vector the interrupts in Flash to the RAM locations with ISR code. The RAM function addresses must be at a fixed location known to the Flash code or have a table of function addresses at a fixed location so the Flash can look up the location of the ISR at runtime.

    3) Relocate the RAM to 0x00'0000 after copying the code to it. The way to do this is:
    A) Copy the code block to the base of RAM (the address which will become 0x00'0000).
    B) Copy a second small function to internal XRAM.
    C) Branch to this function.
    D) This function remaps CS1/ to 0x00'0000.
    E) The function then jumps to the Reset vector location.
    F) The program runs in RAM, including the vector table.
    Notes: The internal RAM function exists because you cannot change CSx/ addressing while using the CSx/ for code. Also the remapping doesn't take affect right away due to pipeline delays.
    This solution allows the RAM program to have it's own startup which will initialize the 'C' variables, etc. Just remember that writes to SYSCON are ignored after the EINIT instruction. EINIT is usually configured in startup.a66 after SYSCON has been set.
    Best luck
    Scott

Reply
  • I believe the blinky program uses interrupts which reside at 0x00'0000 - probably still in Flash space after the copy. There are several ways to get around this:

    1) Don't use interrupts - not very good solution.

    2) Re-vector the interrupts in Flash to the RAM locations with ISR code. The RAM function addresses must be at a fixed location known to the Flash code or have a table of function addresses at a fixed location so the Flash can look up the location of the ISR at runtime.

    3) Relocate the RAM to 0x00'0000 after copying the code to it. The way to do this is:
    A) Copy the code block to the base of RAM (the address which will become 0x00'0000).
    B) Copy a second small function to internal XRAM.
    C) Branch to this function.
    D) This function remaps CS1/ to 0x00'0000.
    E) The function then jumps to the Reset vector location.
    F) The program runs in RAM, including the vector table.
    Notes: The internal RAM function exists because you cannot change CSx/ addressing while using the CSx/ for code. Also the remapping doesn't take affect right away due to pipeline delays.
    This solution allows the RAM program to have it's own startup which will initialize the 'C' variables, etc. Just remember that writes to SYSCON are ignored after the EINIT instruction. EINIT is usually configured in startup.a66 after SYSCON has been set.
    Best luck
    Scott

Children