Generating Different Binaries for Different memory sections of the internal flash

The tiobj2bin utility is generally used in TivaWare examples to convert .out files to .bin. Do you plan to use this utility? You could try using the --exclude section_name option with it to ignore a specified section. Please see the ARM Assembly Language Tools Users Guide, section 12.7 for information on this option. Also this related thread might be helpful as well.

Thanks for your guidance!

I would like some further clarification on this. Assume there are 2 section in flash (section A and B). We would like to update section A by executing code in section B. Here section A is a  simply set of C functions. Hence we would like to generate a binary out of a set of C functions for programming section A. 

The executable in section B will update section A.

The thread mentions that upon excluding a particular section it is "filled with zeros", therefore on excluding section B  (to generate binary for section A ) will we loose existing code in section B ?

Thanks

A better way to achieve may be to generate two executables (link the project twice, with one outputting section A and the other section B). Then generate a bin file for each .out file.

Please see this related thread on this topic: http://e2e.ti.com/support/development_tools/compiler/f/343/t/284699.aspx

Actually Our requirement is,

We have a application specific function which need to be upgraded dynamically by the firmware.

Using the "type=NOLOAD > APPLICATION" we have moved that function to a specific address in FLASH memory.

Now,we have to generate a separate image file for that function alone which can be transferred to the firmware for upgrade so that next time it boots up it will execute the new function. Please suggest some points to achieve this?

Thanks,

Aman Kumar

Aman Kumar said:

Now,we have to generate a separate image file for that function alone which can be transferred to the firmware for upgrade

To achieve this, you would need to relink the application but this time, in the linker command file, all sections EXCEPT this special section should be marked as NOLOAD.

So basically you would link the project two times with two different linker command files:
- one with the special section ( function to be upgraded dynamically) marked as NOLOAD (which is the version you download to target) and
- another with everything except the special section marked as NOLOAD

Then you can convert the second linker output to binary to get an image of just the special section.

To create both these linker outputs from the same project, you can create two build configurations, with the only difference being the linker command file used for the link. Please see this wiki page for more information on build configurations: http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Build_Configurations

AartiG said:

To achieve this, you would need to relink the application but this time, in the linker command file, all sections EXCEPT this special section should be marked as NOLOAD.

To add to my previous reply, the key here is that the second link step should be identical to the first except for the difference in the linker command file with regard to which section is marked NOLOAD. Everything else should be identical, (ie) object files, linker options, order of files passed to the linker etc.

Although using different build configurations to generate the two builds (as I suggested in my previous post) should work, a safer way to ensure that the exact same object files are being used for the second link, is to perform the second link step on a command line or via a post build step in CCS. So you can perform the first build in CCS, then copy the linker step as it appears in the CCS build console and use that on command line to perform the second link, with the only change being the linker command file. Note that everything else should be exactly the same and in the same order. Alternately you could add the command line directly as a post build step in CCS or add it to a batch file and invoke the batch file as a post build step. More on post build steps here: http://processors.wiki.ti.com/index.php/Projects_and_Build_Handbook_for_CCS#Pre_and_Post_Build_Steps

Hope this helps you achieve what you were looking for.