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

Summary

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 🙂

Advertisements

17 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 🙂

    Like

  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 https://mcuoneclipse.com/2012/05/04/dump-my-device-memory/

    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 ??

    Like

      • 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 ?

        Like

      • 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.

        Like

  8. Erich, your site continues to be very helpful to me!

    I discovered this page a month ago, and turned on the S19 export and print size options – they have been very helpful. But now, they are no longer running? Looking at the generated makefile, the steps are in there to run objcopy and size right after the linker, but they never get executed. The .elf file is always generated, but the .hex and .siz files are not.

    They used to work, and now they don’t. I’m sure it’s something silly that I did, but I can’t figure it out. Perhaps there is another obscure button like “skip breakpoints” that I accidentally hit?

    If you have any hints or suggestions, I’d truly appreciate hearing them.

    Like

    • Hi Adam,
      can you check if the refresh policy is matching your project name (see https://mcuoneclipse.com/2015/06/06/eclipse-project-refresh-policy-broken-incremental-build-with-external-make/)?
      And what is written in the Console view? I would check if there are any error messages/etc.
      And what IDE/version are you using?
      And: can you check that you are using the ‘External Builder’ (Project > Properties > C/C++ Build > Builder Settings > Builder Type)?
      I hope this helps,
      Erich

      Like

      • Thanks for the fast reply! Yes, I guess I should’ve included more details, sorry about that!

        — The refresh policy does match my project name.

        — I’m running CodeWarrior for MCU 10.6, build 140329 on Eclipse 4.2,1, and gcc build tools 4.7.3. I’m targeting a K70 and MQX 4.2.

        — The console view shows a successful invocation of the linker generating the .elf file, and then stops without running the additional tools – no error messages.

        — I am using the “External builder” – in fact, that setting is greyed out and it won’t let me change it.

        I took a hint from the linked article, and added “–debug=b” to the make command. This is what the console shows when it links the application:

        __________________________
        **** Build of configuration Int Flash DDRData Debug for project MDC_Application ****

        “D:\\Freescale\\CW MCU v10.6\\gnu\\bin\\mingw32-make” –debug=b all
        GNU Make 3.82
        Built for Windows32
        Copyright (C) 2010 Free Software Foundation, Inc.
        License GPLv3+: GNU GPL version 3 or later
        This is free software: you are free to change and redistribute it.
        There is NO WARRANTY, to the extent permitted by law.
        Reading makefiles…
        Updating goal targets….
        File `all’ does not exist.
        File `warning-messages’ does not exist.
        Must remake target `warning-messages’.
        Successfully remade target file `warning-messages’.
        File `explicit-dependencies’ does not exist.
        File `MDC_Application.elf’ does not exist.
        Must remake target `MDC_Application.elf’.
        Invoking recipe from makefile:72 to update target `MDC_Application.elf’.
        ‘Building target: MDC_Application.elf’
        ‘Executing target #92 MDC_Application.elf’
        ‘Invoking: ARM Ltd Windows GCC C Linker’
        “D:/Freescale/CW MCU v10.6/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc” @”MDC_Application.args” -o”MDC_Application.elf”
        ‘Finished building target: MDC_Application.elf’
        ‘ ‘
        Successfully remade target file `MDC_Application.elf’.
        Must remake target `explicit-dependencies’.
        Successfully remade target file `explicit-dependencies’.
        File `secondary-outputs’ does not exist.
        Must remake target `secondary-outputs’.
        Successfully remade target file `secondary-outputs’.
        Must remake target `all’.
        Successfully remade target file `all’.
        __________________________

        And here is the tool invocations portion of the generated makefile. Note that right after target #92 (which is shown to be executing in the above console output) there are targets #93 and #94 that are not executed:
        __________________________
        # All Target
        all: warning-messages explicit-dependencies MDC_Application.elf secondary-outputs

        # Tool invocations
        MDC_Application.elf: $(OBJS) $(USER_OBJS) ../Project_Settings/intflash_ddrdata.ld
        @echo ‘Building target: $@’
        @echo ‘Executing target #92 $@’
        @echo ‘Invoking: ARM Ltd Windows GCC C Linker’
        “$(ARMSourceryDirEnv)/arm-none-eabi-gcc” @”MDC_Application.args” -o”MDC_Application.elf”
        @echo ‘Finished building target: $@’
        @echo ‘ ‘

        MDC_Application.hex: MDC_Application.elf
        @echo ‘Executing target #93 $@’
        @echo ‘Invoking: ARM Ltd Windows GNU Create Flash Image’
        “$(ARMSourceryDirEnv)/arm-none-eabi-objcopy” -O srec MDC_Application.elf “MDC_Application.hex”
        @echo ‘Finished building: $@’
        @echo ‘ ‘

        MDC_Application.siz: MDC_Application.elf
        @echo ‘Executing target #94 $@’
        @echo ‘Invoking: ARM Ltd Windows GNU Print Size’
        “$(ARMSourceryDirEnv)/arm-none-eabi-size” –format=sysv -x > MDC_Application.siz MDC_Application.elf
        @echo ‘Finished building: $@’
        @echo ‘ ‘
        __________________________

        I also tried the “a” level of debug information. It spat out lots of additional information (too much to post.) Nothing jumped out at me as being an issue.

        It all looks good to me, but it just doesn’t work. I’m stumped…

        Like

  9. Thanks!

    Following that link, My makefile has the output macros empty, just like your example. There were no icon decorators, especially on any linker related files. I went ahead and created a new .ld file, copying the contents from the existing one, then changed the project settings and rebuilt – still no output macros, still no hex or siz files.

    I looked in the .cproject file, and there were a few lines for debugger files that were disabled. I went ahead and deleted those unused debugger files, and deleted the lines (after quitting Eclipse and using an editor outside of Eclipse.) Start up the IDE again, build, and now the output macros are filled in – Yippiee! But only the .siz file is generated, not the .hex file. Darn!

    Cleaned the project and rebuilt it: output macros filled in, hex and siz output generated!

    So I guess the outcome is that the entries can indeed have an impact on whether the additional tools run – even if those entries have nothing to do with the compile/link process!

    Like

    • Hi Adam,
      You have found yet another reason why I’m using version control systems to store all my files. That way I could track down and see what has been changed, just in case.
      Glad to hear that you are up and running again.
      Erich

      Like

What do you think?

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

WordPress.com Logo

You are commenting using your WordPress.com 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