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?
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?
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’:
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
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
as this starts a block with per file/folder custom settings.
Happy Resetting 🙂
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?
is your make file looking ok (and not as shown in the article with empty rule macros)? Is ‘Print Size’ working or failing too?
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.
exporting the project should not matter. I would carefully check if there are any custom build settings the project, with checking the .cproject file.
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.
Unfortunately, this is a problem with these plugins. You might try the Liviu Eclipse ARM plugins instead:
Thanks, that looks like an interesting project.
Unfortunately it’s not an option to switch away from CW for my current project though, so I’ll try to come up with a workaround. If I find something I’ll post it here.
You could use the ‘post build step’ in CodeWarrior and call the GNU utility to generate the S19 file from the command line?
Thanks, yes the post-build step works well. I made a batch script to generate the hex file and some other file manipulation.
Pingback: GNU Additional Tools: Create Flash Image, Print Size and Extended Listing Options | MCU on Eclipse
For me, i had 2 times an entry like this in .cproject.
deleting the second one with the folder, solved my problem
yes, that one happened to me several times too. Glad to hear you have found the solution now :-).