This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Overlaying code in the 2407a

Hello all:

 

I am working on a project that has grown too large to fit in the 2407 internal flash. We have added an external flash chip (connected via the SPI port) and I would like to overlay routines from there to the internal 2407 Code Ram located at 0x8700.

I have the mechinism working to actually load code from external to internal RAM, but have run into an issue.

I have one project that compiles the code required to be in external flash and programs the external flash (called INIT), and a second project that has all the other code and can load the external routines in as needed (called WORKING)

The problem is, the loader places dependent routines (subroutines called from the overlayed code) in different places in the 2 projects so when I run the WORKING, and call a routine from an overlayed code, it goes to the wrong address.

I found the order of the sections in the SECTIONS paragraph (.text, .cinit, .switch etc...) in the linker command file matters, and I also found I can select a "link order" in the project build options too.

Does anyone know how I can use the build output from one project to make the linker place routines in identical locations in a different project. For example, if I build WORKING first, is there a way I can use the map file, or even the absolute lister output, to make the linker place the routines in INIT in the same places?

This isn't just a problem in the code, but memory variables are ending up in different places too.

As a stopgap measure, I am making an external program to create a CMD file that will place each memory variable in a specific place by creating a single MEMORY and SECTIONS directive for each variable.

I am considering doing that for each routine that exists in both projects too (this means putting each routine in it's own C file so I get a seperate .obj file for each one.)

This is a really sucky aproach,  and I am hopeing for something much more automated. Both to make my  life easier, and to eliminate errors caused by me forgetting something.

Any help I can get to help me think outside the box, or help me better use the available tools will be appreciated.

Thanks for your help.

 

Mark.

 

  • Added info, I am using CCS DSK 2.21.

  • Hello

    Your software related questions are way out of my expertise and I will not try to answer them but I am curious to know whether you have considered 28xxx class devices instead of a 24xx device? Newer 28 devices will offer you more of everything with added benefit of efficient "C" programming. I am sure you have your good reasons to stay with 2407 but in future please seriously look at these newer devices.

  • Arefeen:

    Thanks for taking the time to reply.

    Yes, we are going to upgrade to the 2812 for the afore mentioned project, but we also intend to add features to the project and foresee it growing beyond even the capabilities of that processor.

    For a little more detail, We choose the 2407 (or 2812) mostly because of it's code security feature. The code I am putting in the external flash is encrypted, and each time I bring in a snippit, I must first decrypt it. While there is a performance penalty to pay, it isn't enough to impact the usage (the external flash and decryption algorithm is pretty fast.)

    This is why we havent simply added an external flash to the external memory buss and programmed it with the excess code.

    Mark.


     


  • Hello Mark

    I am sure you have selected the device most appropriate for your product but note that 2407 and 2812 are very different devices - 2812 will offer you similar peripherals like 2407 but will offer vastly improved core and memory configuration, C capability etc.  In addition ADC of 2812 is better than th eone on 2407. Anyway, I am hoping software experts will provide you a good answer on how to manage the code.