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

Posted on April 11, 2014 by Erich Styger

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

CodeWarrior for MCU 10.x

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

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

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

The options are found in the Tool Settings Tab:

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 🙂

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

Liviu Ionescu (ilg) on April 11, 2014 at 13:46 said:

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

LikeLike

Reply ↓
- Erich Styger on April 11, 2014 at 13:58 said:
  
  Yes, I see that ‘copy-paste’ thing with the students in my class very often too 😉
  
  LikeLike
  
  Reply ↓
Pingback: GNU Linker, can you NOT Initialize my Variable? | MCU on Eclipse
Pingback: Binary Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins | MCU on Eclipse
Pingback: Printing Code Size Information in Eclipse | MCU on Eclipse
Pingback: Executing Multiple Commands as Post-Build Steps in Eclipse | MCU on Eclipse
Pingback: Tutorial: FreeRTOS Projects with Kinetis SDK V1.3 and the SDK Project Generator | MCU on Eclipse
mauroansa on March 23, 2017 at 13:50 said:

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

LikeLike

Reply ↓
- Erich Styger on March 23, 2017 at 21:51 said:
  
  I have not observed something like this, maybe there is indeed an issue. I’m usually using the S19 files (and not binary files) or the S-Record utility (see https://mcuoneclipse.com/2015/04/26/crc-checksum-generation-with-srecord-tools-for-gnu-and-eclipse/) for creating bin files, maybe this works for your case?
  
  LikeLike
  
  Reply ↓
  - mauroansa on March 24, 2017 at 17:19 said:
    
    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 ?
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 24, 2017 at 18:49 said:
      
      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.
      
      LikeLike
Adam on June 13, 2017 at 14:17 said:

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.

LikeLike

Reply ↓
- Erich Styger on June 13, 2017 at 14:50 said:
  
  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
  
  LikeLike
  
  Reply ↓
  - Adam on June 13, 2017 at 15:31 said:
    
    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…
    
    LikeLike
    
    Reply ↓
    - Erich Styger on June 13, 2017 at 15:45 said:
      
      Hi Adam,
      can you check this post:
      
      Traps and Pitfalls: No Hex/Bin/S19 File Created with GNU?
      
      ?
      I hope this helps,
      Erich
      
      LikeLike
Adam on June 13, 2017 at 17:27 said:

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!

LikeLike

Reply ↓
- Erich Styger on June 13, 2017 at 21:03 said:
  
  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
  
  LikeLike
  
  Reply ↓
Scott Miller on April 30, 2018 at 21:47 said:

Hi Erich,

I’ve used this before and I just set it up on another project last week, but for some reason one of my projects just doesn’t show the options at all. Nothing below ‘C++ compiler’, aside from the toolchain path, shows up in the toolchain tab. I’ve looked at .cproject and there are references to the tool. I can’t figure out what’s different between this and the other project.

I tinkered with it for most of an hour but finally had to settle on using arm-none-eabi-objcopy -O binary “project_name.elf” “project_name.bin” in the post-build steps.

If anyone happens to know what the problem is, let me know, but at least I’ve got it running for now.

Scott

LikeLike

Reply ↓
- Erich Styger on May 1, 2018 at 13:05 said:
  
  A screenshot of what you see would be helpful (but you cannot load images here :-(). I saw weird things in case Eclipse (Java) is running out of heap memory, so not sure if this is the case here.
  
  LikeLike
  
  Reply ↓
ANAND on October 16, 2020 at 04:26 said:

Hi Erich
I want to discard the launch configuration file section (.cfmprotect) of 16 Bytes ALONE to be eliminated on creating Flash image. But, I want .text and .data sections in my hex file.
HOW to attain this?
I find -j sections in the option. Whether it includes the section in creating a flash image or it discards?

LikeLike

Reply ↓
- Erich Styger on October 16, 2020 at 05:39 said:
  
  If you run objcopy on the command line it gives you the list of options. For -j:
  -j –only-section Only copy section into the output
  –add-gnu-debuglink= Add section .gnu_debuglink linking to
  -R –remove-section Remove section from the output
  
  Other than that:
  there is a nice article on https://hackaday.com/2020/10/01/even-more-firmware-in-your-firmware/ which explains some of the magic.
  
  LikeLike
  
  Reply ↓