I have to use command line flash programming for a project . So I created a fake project similar thand the original one. The problem is that I'm using a .ini for flash downloading to program a modfied .hex and not the axf file. If I'm using command line , the .ini is ignored and uv4 want to flash an .axf file ... How can I solve this problem ?
Translate the .HEX into a .ELF/.AXF? Use a different programming utility, not Keil/U-Link? Have your own application accept update .HEX images via serial port? Kobayashi Maru?
What a sarcastic answer ... But I can play too :) If I had the choice, my simple solution will be to just forget all feet programmed keil tools ... It's not the first time I'm stucked with the 90's - ide , the locked ,slown, useless tools. The funniest here is that my company use Keil for the IDE , not the middleware. So $$$ for useless updates at our levels (in 7 years, I didn't saw real improvements in uvision itself). Our dev team is in the process to switch to Eclipse, and the last link we have to cut seems to be maybe the only thing that worked well expect for that useless command line call, Ulink2... Sincerely, Keil could add one or two command line options to choose the target project file we want to use and the final file to program. At most 1 day of work ...
My suggestion #1 is probably a hour or so depending on how polished it needs to be. You've likely been banging on this problem for longer that already. Like I said, change your paradigm, you might be able solve it then, instead of complaining there's no solution.
Why can't you just get the GNU/GCC tools just generate .ELF files as they normally do and use those? AXF = ELF for most purposes.
Yeah it would do the trick .It's just seems funny to have an axf to hex then go back to axf. I just have to shout why I'm feed up to fight against tools thinking their purpose are to help me :-/ There are real non senses in the keil toolchain, and sometimes you know it's just butch up. In the case of the command line flashing , I like to think Keil could repair such a lack ! :)
Indeed, and goes to the core here, WHY do you need to use the HEX if you already have an AXF? Or course going from AXF->HEX->AXF is ridiculous, but it's a premise you've created. One could sanitize/refactor an ELF/AXF file directly if leaking symbols, etc is an issue.
You've set up this condition that you don't want to change, and everyone else has to adapt to this new unduly awkward method. Chip vendors normally have tools to program their devices too.
I think Keil assumes their tools are not used as a production programming platform. They are too expensive for that, and there are cheaper, more efficient methods.
It's a part of a process where the hex code is patched with various CRCs and version numbers . Thats' why .hex are used with srec tools. But you cannot deny that it's strange to take into account the specified .ini for flash programming in uvision IDE and NOT when using flash programming calling the same project file.. ;-)
It's a part of a process where the hex code is patched with various CRCs and version numbers . Thats' why .hex are used with srec tools.
That explains why you're producing a modified .hex file. It does not explain at all why you so aggressively insist on using a software development tool for what is obviously the job of a production programmer. Or to put it in a different way: if you're not going to be doing any debugging anyway, why even use the debugger?
That pain you feel is from using a screwdriver to do what is the hammer's job.
I absolutely don't want to use ulink as a production flashing tool. I just want to be able to program my firmware from Eclipse IDE . In an ideal world I would like to debug from Eclipse too , but the eclipse plugin does not work.
The Keil tool is happy to program a hex file without using an ini file.
I have a "Generic Project" that is called burnhex.uvprojx
The Name of the executable in this project is burnhex.hex. This is the name of the file you want to burn (and yes, it can be and is a hex file)
IF if run this from the command line "UV4 -f burnhex.uvprojx" it burns the burnhex.hex file to the board. Is this what you want?
Ok , thanks, I'll try !!. I just hop the text field manages relative/absolute path and not only the name of the file to program.