• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 567 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

allocating constant tables in flash

MattLipsey
Genius 3575 points

In my 6435 app, I would like to place some large constant tables in flash and then load them into ddr2 at run time.  I want to place the tables at the end of flash so that I can erase/rewrite them without hitting the code stored at the other end of flash.  Is this as simple as editing the linker command file to split flash up into two sections, and then using data section & data align pragmas on a constant array?  I don't mind manually loading the tables, but I don't quite grok how the linker and the aisGen tools play together to make sure that code fits into the first segment of flash without possibly overwriting the second.  So my second question is:  If I am planning on burning my application to flash using ais (EMIFA boot), how do I make sure it fits in the piece of flash that I want it to without spilling into allocated table space?

  • 0
    TI__Mastermind 41665 points

    MattLipsey said:
    Is this as simple as editing the linker command file to split flash up into two sections, and then using data section & data align pragmas on a constant array?

    Assuming you are using NOR flash (as opposed to NAND) you could access the memory directly, however since you are planning on copying the data into DDR anyway it would probably be easier to just put the data at a known address and than use a pointer in C to copy the table into an array in DDR (which could be static or dynamic). I believe you could do this as you describe by creating the section in the linker command file as a NOLOAD type.

    MattLipsey said:
    If I am planning on burning my application to flash using ais (EMIFA boot), how do I make sure it fits in the piece of flash that I want it to without spilling into allocated table space?

    You could start by taking a look at the map file generated by the linker (-map=filename linker flag), this has statistics about what goes where as well as the overall size of what is being loaded. The flash image should be contiguously placed in the beginning of the flash, so that as long as the total size of code and data is less than the distance in the flash to your data tables you should be ok. I don't have the tools in front of me but you may be able to get similar information out of the aisGen process or by examining the output file. In general if you put your data tables at the highest addresses in the flash than you will be able to fit the maximum amount of application code/data in the flash.

  • 0 in reply to Bernie Thompson TI
    TI__Guru*** 125430 points

    I like Bernie's idea of using the NOLOAD type in your linker command file.  I think there might be some "devil in the details" though.

    Here's how I think it should go:

    1. You create a flash memory section corresponding to your constant tables.
    2. Use a NOLOAD type in your linker command file when specifying the placement of your constant sections in flash.  The reason for the NOLOAD is because you want to prevent the AIS tools from bundling this data into your image.  (You don't want this memory folded into your AIS image or else it will start out at the wrong location and the AIS bootloader will attempt to copy them at run-time to your other location in flash, which will fail miserably!)
    3. As a separate step, you will need to burn those constant tables into flash.
    4. Your linker command file should specify separate load and run addresses for your constants.
    5. Your application will need to copy them from flash (load addr) to DDR (run addr) before your app references those variables.

    Bernie, is that along the lines you were thinking or did I just derail this thing?  ;)

    Brad

  • 0 in reply to Brad Griffis
    TI__Mastermind 41665 points

    Brad Griffis said:
    Bernie, is that along the lines you were thinking or did I just derail this thing?  ;)

    That sounds about right if you wanted to use NOLOAD and have it actually mapped into C environment's known space, I wouldn't consider this derailing ;). My first thought on this was just to use steps 3 and 5, as if you burn the constant tables to flash at a consistent location than  you could make up a pointer in C based on that location and copy the data tables into the C environment at run time, sort of like treating the tables as a hardware resource as opposed to a software structure. The benefit of this more manual method is that you don't have to worry about using NOLOAD and about mapping in the special tables section of flash into what your application's C environment is aware of (i.e. the tables wouldn't exist in the linker command file) so it is what I would consider easier (up for interpretation). The downside of the manual method is that you have to ensure that the C pointer you use and the location of the tables remain constant, whereas if you had the NOLOAD section in place the C environment would handle the addressing change if you moved the section around.