Traps and Pitfalls: No Hex/Bin/S19 File Created with GNU?


I stumbled now twice over a problem, and only after a lot of head scratching (you should see my head now 😉 ) I have found the cause (and solution) for it. In the hope that I can save the readers of this blog some time, here is what happened.

I described in earlier posts how to enable GNU build tools to generate hex/bin/S19 files, or to write the code size to the console view. That works fine for me. But then I received a project were obviously this does not work: even with the project settings configured properly, there is no S19 file, and no code size printed. What’s wrong?

Additional Tools in ARM GNU Eclipse Panel

Additional Tools in ARM GNU Eclipse Panel

Tool Settings?

Checking the ‘Additional Tools’ project settings showed that everything is configured properly:

ARM GNU Create Flash Image

ARM GNU Create Flash Image

So next step is to check if there is something wrong with the generated make file?

Make File? Make File!

And indeed, the make (‘makefile’ inside the output (FLASH) folder) looked ok at the first sight: there is a rule in make file to create the flash image:

Make Rule to Create Flash Image

Make Rule to Create Flash Image

But then I saw this: the macros for the outputs are empty 😦 :

Empty Output Macros in Make File

Empty Output Macros in Make File

So that’s definitely not good. It means that the flash image file is not referenced, thus the rule is not executed, so this is why it fails. But why is the macro empty?

Project Options

Checking all the project options (they make sense), checking the make file builder in the project settings. Thinking that it could be because of the artifact name having a ‘-‘ (that’s not a problem), playing with different things. No positive result, still no hex file created.

Per File Options?

After sleeping over the problem, I remembered that I have seen issues with ‘per file’ options: in Eclipse I can set project options per file or folder. This is indicated with a special icon decorator as explained in this post.

And indeed: the linker file had such a decorator marking it as ‘excluded from build’:

Icon Decorator Excluded from Build

Icon Decorator Excluded from Build

Heureka, maybe?

Right click on the file, and then disabling the flag so it is included again in the build (cleared the checkbox):

Excluded from Build

Excluded from Build

Build again, and…….. still no hex file :-(.

But what I noticed is that the linker file still had a ‘per file option’ icon decorator (that small pin point):

Per File Option for Linker File

Per File Option for Linker File

That’s really strange, as this does not make sense, and there was no context menu Resource Configurations > Reset to default available for that file?

Reset to Default

Reset to Default

FileInfo Entry in .cproject?

Checking the .cproject file, I found this entry for the linker file:

<fileInfo id="org.eclipse.cdt.cross.arm.gnu.sourcery.windows.elf.debug.45568254.Project_Settings/Linker_Files/MK10DX256_flash.ld" name="MK10DX256_flash.ld" rcbsApplicability="disable" resourcePath="Project_Settings/Linker_Files/MK10DX256_flash.ld" toolsToInvoke=""/>

Checking this Eclipse page about what this means, and indeed that file should not be configurated as such. So I decided to remove that entry from the .cproject file.

💡 instead of changing the .cproject file, another way is to delete and re-create the *linker* file again. For example creating a new file (new.ln), then copy the content from the orginal linker file, save it, delete the old linker file and rename the new.ln to the correct linker file nam. This will get rid of the fileInfo entry in .cproject.

Now the icon decorator was gone (ufff!). Build again, but still no hex file generated?

Reset to Default? Yes!

But what I noticed was that it *has* that Reset to Default… on the Sources folder:

Reset to Default on Sources Folder

Reset to Default on Sources Folder

That’s now interesting! And an issue in Eclipse as it should show that ‘pin’ icon decorator, but somehow it does NOT :-(.

Checking the .cproject showed that there was another

<fileInfo  ..../>

block defining custom options for the Sources folder :-(.

Reseting that configuration with the context menu:

Reset Resource Configuration

Reset Resource Configuration

Building, and now I get:

'Building target: K10-IR_SP2.elf'
'Executing target #19 K10-IR_SP2.elf'
'Invoking: ARM Ltd Windows GCC C Linker'
"C:/Freescale/CW MCU v10.4/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-gcc"    @"K10-IR_SP2.args" -o"K10-IR_SP2.elf"
'Finished building target: K10-IR_SP2.elf'
' '
'Executing target #20 K10-IR_SP2.hex'
'Invoking: ARM Ltd Windows GNU Create Flash Image'
"C:/Freescale/CW MCU v10.4/Cross_Tools/arm-none-eabi-gcc-4_7_3/bin/arm-none-eabi-objcopy"  -O srec -j .text -j .data K10-IR_SP2.elf "K10-IR_SP2.hex"
'Finished building: K10-IR_SP2.hex'

Heureka! Really! 🙂

And now the make file generated is looking fine too:

Correct Make File

Correct Make File

Conclusion and Summary

Having custom file and folder settings can screw up the ARM GNU ‘Additional Tool’ settings. It looks that if the linker file is having custom build settings, and possibly conflicting source file and folder settings, then the make file is not generated properly, and as a result the hex file is not generated.

In the case above I believe the custom folder/source settings were introduced by a user error: because of I do the context menu Properties on a source folder or a source file, then settings get applied to that folder or files. To apply project-wide settings, *always* select the project folder, and not an individual file or folder!

Usually Eclipse informs me about these custom settings with the proper icon decorator. Not sure why this is not always the case. If there are any doubts, I recommend to use the context menu (Resource Configurations > Reset to default) to make sure that there are no intentional settings.

Another tip is to open the .cproject file (in the Eclipse project root) and search for

<fileInfo  ..../>

as this starts a block with per file/folder custom settings.

Happy Resetting 🙂

12 thoughts on “Traps and Pitfalls: No Hex/Bin/S19 File Created with GNU?

  1. Erich, We are using Codewarrior 10.5 and MK10DX128. Our project was set up to make a SREC file and it did work. Now for some reason, the SREC file is no longer made. We tried your suggestions in this post, but we have not been able to get it to work. Any ideas on what to check?
    Thanks,
    B.K.

    Like

      • Yes, the macros are empty and print size does not work. One software engineer thinks all was working before he “exported” the project so others could use it. The output to the console just seems to stop prematurely. The end of the build does not look normal, but the project can be downloaded and run on the target.

        Like

      • exporting the project should not matter. I would carefully check if there are any custom build settings the project, with checking the .cproject file.

        Like

  2. Thanks for this post — I ran into this problem and after finding your post determined that having some file-specific compilation settings was indeed the culprit (C files, not my linker). Any suggestions on how to deal with that? I need to keep the file-specific compilations settings I’m using.

    Like

  3. Pingback: GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options | MCU on Eclipse

  4. For me, i had 2 times an entry like this in .cproject.
    deleting the second one with the folder, solved my problem

    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