INCLUDE directive replaces 0x0D to 0x0A (or vice versa) in including files...
} > ROM
Yes there is!
I just found this after finding (very very painfully) this same bug.
Any time you INCLUDE a binary file with 0x0d it silently corrupts it.
HEY MISTER LINKER WRITER - OPEN THE FILE IN BINARY MODE NOT ASCII MODE
If whoever wrote that linker was near me right now I'd be shouting at them.
I'm astonished, this is a lame bug and it really ruined my day (and deadline)
Sorry I need a beer now. That was the most frustrating bug of the year to find. Silent corruption of my data files - thx
I'm not the linker writer, but I have contacted the right group which can fix this.
I know first hand how painful such things can be.
I have created a formal bug report internally so this can be addresssed right now.
Thanks, I feel better now.
I asked my freescale contact and he said "yes it's a known issue", as did the person who ACK'd my submitted bug report today.
I said "....Ah, thanks... It wasn't a known issue to me, there was no fix, update or note provided and I had to find it the hard way.. ..So where is the known issue list, so I can read it now and avoid tearing my hair out next time I encounter an inexplicable bug?"
A. "When a new release goes out, it contains a list of the corrected issues in a Readme file."
Uhh...at this point I realized I had better things to do.
Anyway, I look fwd to a new linker build. For anyone reading this, the broken version is
mwldmcf.exe (in \MCU\Coldfire_Tools\Command_Line_Tools\ )
CodeWarrior Linker for ColdFire.
Copyright (c) 2009, Freescale Semiconductor, Inc
All rights reserved.
Version 6.0 build 3009 (build 3009)
Runtime Built: Dec 22 2010 18:40:35
if you have this (or older? don't know) you have this bug.
One way round it would likely be to convert your binary file to a big C style array of hex bytes and compile it.
Thanks for prompt replies,
another workaround would be to include the binary file as S19 file (convert it with the burner utility to an S19 file, then use it in the .lcf file).
Otherwise: I have attached a zip file of the linker from the upcoming 10.2 beta which has this issue fixed.
Rename your existing linker executable and use the attached one instead.
I like your "Otherwise: " option very much because that fixes it.
Thank you BlackNight! Also thanks of course to the compiler team persons who whipped that out.
Much appreciated, that's as quick as I've ever had a tool bug fixed in 25+ years of geekin'.
Retrieving data ...