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?

Tool Settings?

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

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:

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

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’:

Heureka, maybe?

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

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):

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?

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:

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:

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:

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 🙂