GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options

One question I have been asked several times here at FTF:

“How can I create an S19/Motorola S-Record with Eclipse?”

The answer depends on which Eclipse you are using. Actually it depends on which (ARM) build  tools plugin you are using, as with Eclipse you have the freedom of choice.

And this is not only about S19/Binary (Flash Image), but covers ‘Extended Listing’ and ‘Print Size’:

Additional Tool Options

Additional Tool Options

CodeWarrior for MCU 10.x

In CodeWarrior, there is an ‘Additional Tools’ group to enable it:

CodeWarrior Additional Tools Panel

CodeWarrior Additional Tools Panel

❗ IMPORTANT: You need to press the ‘Apply Button’ to get the additional groups showing up on the left hand side!

The format of the flash image file is configured here:

Output format Selection

Output format Selection

The output file is generated into the folder where your .elf file resides.

❗ Note that for this plugin the file name extension is always *.hex, even if it is a S-Record file.

Eclipse with GNU ARM Eclipse Plugins

The GNU ARM Eclipse Plugins maintained by Liviu have solved the problems mentioned above (‘Apply’ button, File Name Extension). So this plugin is my plugin of choice for Eclipse, and the same plugins is used in the Kinetis Design Studio too. It is just that the options are in a different place:

GNU ARM Eclipse Plugin

GNU ARM Eclipse Plugin

The options are found in the Tool Settings Tab:

GNU ARM Eclipse Plugin Output Format Selection

GNU ARM Eclipse Plugin Output Format Selection


It is very easy to enable the additional GNU tools, all what I need to know is where to look :-).

Previous articles on that topic:

Happy Tooling 🙂


11 thoughts on “GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options

  1. > CodeWarrior for MCU 10.x …
    > Note that for this plugin the file name extension is always *.hex, even if it is a S-Record file.

    Ah, now I understand why the look of CodeWarrior CDT plugins, especially the Additional Tools, looked so familiar to me.

    The wrong name extension was a known bug in GNU ARM Eclipse plug-in versions 0.5.x. Apparently CodeWarrior copy/pasted it entirely, including the bugs 🙂


  2. Pingback: GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse

  3. Pingback: Binary Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins | MCU on Eclipse

  4. Pingback: Printing Code Size Information in Eclipse | MCU on Eclipse

  5. Pingback: Executing Multiple Commands as Post-Build Steps in Eclipse | MCU on Eclipse

  6. Pingback: Tutorial: FreeRTOS Projects with Kinetis SDK V1.3 and the SDK Project Generator | MCU on Eclipse

  7. The generation if a *.bin raw binary image file using objcopy that translates from ELF works fine for small and big projects if m_interrupts and m_text are not modified.
    If an offset of 0x10000 is applied , for a small projects it does not cause any trouble.
    But if I try to convert a big one (around 500kByte of occupied flash memory), the generated bin file is not correct. The first few bytes are all 0xFFFF, followed by a large number of 0x00000. The rest of the file seems filled with random data.
    And if I try to use objcopy outside the IDE (tested also with a newer version) the result is the same.

    The project is for a Kinetis K64 (KDS3.0 and SDK1.2 MQX ) , the linker file has been modified using Processor Expert moving the code at 0x10000 in order to be loaded using a boot loader .

    To generate a correct .bin file The only workaround I found is to dump the memory in a file as in

    This .bin file can be loaded and executed.
    I understand that obycopy is widely used and is working correctly also for big file, then maybe is the generated ELF file that has something strange in it.
    It can be loaded as it is, but not converted by obycopy ??


      • Thank for the prompt answer! And many tanks for your invaluable work.
        Following your suggestion I did test using objcopy to convert from S19 file to binary and also used srec_cat, but the output binary file is still not correct. I discovered that it has a sort of unwanted header of 0x10000 bytes (that is exactly the intended offset of the program in memory). So I could cut in some way the bin file to discard the first 0x10000 bytes, but then I’m more confident in a dump of the memory in a bin file. Maybe there is a way to perform this automatically at the end of the link, inside the KDS ?


      • binary files are really a 1-to-1 image of the memory. So if your program starts at 0x1000, it will contain the first 0x1000 unless you apply an offset to it. I have not an example at hand, but I’m sure the Srecord tool supports that.


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s