• State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 22 subscribers
  • Views 1723 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

Change the execution address of a library

Carmen Moreno

Hello

I am working with a C161U micro on an EASY UTAH target.

Well I have two projects, startup and application, that I load on Flash with the Flash Tool.

At the target reset, what it is on flash begins to run: the startup project.
The startup project copies the application project from flash to RAM, and its last instruction is to jump to the beginning of the RAM, and then the application project is executed from RAM. To accomplish this, I must avoid absolute call to functions by converting the calls in relative calls thanks to the key word near before each function.
For example the function void near config (void) is at address 0x20100 (this is the load address in Flash), so if the RAM start address is 0x110000, then this function is copied at address 0x110100. When this function is called, this is not with a CALLS CC_US, 0x20100 but with a CALLA CC_US, 0x00100 thanks to near. The call is then relative and the function is executed from RAM.

Well, I have a problem with the library functions used in my program C_PCASTS or MEMCPY, because they are executed in Flash. I don't know how to specify that they must be called with relative calls since I can't put the near word before their declarations.

How to obtain their execution in RAM and not in Flash?

Thanks for your help
Best regards
Carmen

Parents
  • 0 in reply to Mik Kleshov

    One of the startup functions I use does the following:
    1) Checks the main program in Flash using a CRC.
    2) Copies the program to external RAM.
    3) Copies a small code segment to XRAM.
    4) Jumps to the start of the XRAM code.
    5) The XRAM function remaps the RAM to 0x00'0000 where flash used to be. This function was written in assembly and is about 15 lines long.
    6) Performs a pseudo reset by resetting the stack pointer and jumping to 0x00'0000.
    7) The application then performs it's own 'startup.a66' and runs.

    This function also handles download and programming of flash if the program is corrupted.

    You must be careful of the EINIT instruction since it locks the SYSCON register, stopping remapping of the internal flash to 0x01'0000.

    One of my other startup functions leaves the internal flash alone since it is the fastest code memory but copies external flash to external RAM to avoid the wait state. This code must be able to ID the processor since internal flash sizes vary from processor to processor.
    Best Luck
    Scott

Reply
  • 0 in reply to Mik Kleshov

    One of the startup functions I use does the following:
    1) Checks the main program in Flash using a CRC.
    2) Copies the program to external RAM.
    3) Copies a small code segment to XRAM.
    4) Jumps to the start of the XRAM code.
    5) The XRAM function remaps the RAM to 0x00'0000 where flash used to be. This function was written in assembly and is about 15 lines long.
    6) Performs a pseudo reset by resetting the stack pointer and jumping to 0x00'0000.
    7) The application then performs it's own 'startup.a66' and runs.

    This function also handles download and programming of flash if the program is corrupted.

    You must be careful of the EINIT instruction since it locks the SYSCON register, stopping remapping of the internal flash to 0x01'0000.

    One of my other startup functions leaves the internal flash alone since it is the fastest code memory but copies external flash to external RAM to avoid the wait state. This code must be able to ID the processor since internal flash sizes vary from processor to processor.
    Best Luck
    Scott

Children
No data