I've got a Freescale evaluation board that I'm working through for the KL02. All of the Freescale documentation is awesome, and then I jump into the example code and the world of KEIL MDK and am stunned by how there is literally no documentation whatsoever. It's like I'm on an egg hunt. I've got uVision compiling the example project and it produces an AXF file. I have no idea what to do now. Searching online I have found no information on how to convert an AXF to SREC, which is what OpenSDA wants for loading, that or a binary file. How do I get a BIN file?
Also, the debugger doesn't seem to work. I installed the "Freescale Kinetis OSJTAG Drivers V1.14" just as instructed on the Freescale website, and after installing KEIL MDK. When I try to debug or even just download the code to Flash, it doesn't see any device connected to USB. Come on guys, not even a readme file or something? Really disappointed.
Here on the forum I see someone else who had the exact same problem as me back in March, no replies. I hope I get some replied.
fromelf can convert axf to bin.
But don't you think the support links on this site works better than to post to a forum that Keil have officially said they aren't guaranteed to monitor? This is an end-user forum.
Thanks. I have contacted KEIL support actually but haven't gotten a response.
A few questions.
1) Where do I get fromelf? I don't see this as an option on the download list anywhere. The link provided by the second commenter leads to the "ARM Compiler toolchain," also don't see a link to download that in the download area. Searching in Keil/bin I don't see a fromelf.exe, so it didn't come with the MDK.
2) Why would they leave something critical like this out of the MDK? Why is it external? This makes no sense, for the debugger to work (which it isn't) it has to download the binary data to the MCU. Why is there no simple option to output binary in the IDE?
3) Why is everything referring to ELF when the filename is AXF? I'm I supposed to convert from AXF to ELF to BIN?
Ok I found fromelf in the ARMCC folder. So scratch my #1 question. And it works, I processed the AXF and am able to create and then manually load a SREC file. Progress!
I'm still curious why there isn't an IDE option? I guess what I'm really asking for is confirmation that there isn't an IDE option. It just baffles me that they'd make things unnecessarily time consuming like this, and for such an expensive suite.
Still don't have the debugger working with OpenSDA, any thoughts there?
Thanks
The majority of users download without this extra step - I only use it when creating files for remote download, i.e. for over-the-air updates.
Next thing is that you can add own post-processing steps to the build process and have this tool called automatically.
What seems to baffle you is that a company does something different than you expect. Wouldn't life be dull if every tool had to be written according to a strict regulation?
In the end, a too rigid tree will break in the storm...
It's pretty odd you managed to find an old post, which you didn't cite, and I was able to find a direct hit with Google for the answer in seconds. The information to do the things you want is out there.
C:\Keil422\ARM\BIN40\fromelf.exe
There is a check button to make INTEL .HEX files, which uses FROMELF.
Motorola S-Records are atypical in ARM development, in my experience, and I've used both, though generating INTEL, MOTOROLA or TEKTRONIX hex files is NOT a complex task, neither is writing loaders to process, or translate them.
When you spend millions developing an SoC, you often have to create custom tools, scripts, generators, translators and fitters, a $5K tool from Keil is not a particularly expensive product, nor is it a silver bullet. The IDE does provide provision for pre/post link processing, user tools can compress, encrypt and package firmware images. Flexibility is the name of the game, not rigid dogma.
What does OpenSDA need for debug? Motorola S-Records don't really provide much in the way of symbolic information, unlike Tektronix hex. The ELF/AXF format provides symbolic and line numbering info, but creating binary or hex data strips all that metadata away.
>>3) Why is everything referring to ELF when the filename is AXF? I'm I supposed to convert from AXF to ELF to BIN?
Look at an .AXF file in a hex editor/file viewer some time.
Please consider that I'm working with an evaluation board here. An evaluation board that came with zero documentation from KEIL. I don't know what terms you typed into the search, but they are probably from the perspective of someone with more information. If they simply had a 2 page readme that were included with the sample code all this could have been avoided. A welcome to ARM document explaining themes like AXF/ELF, etc. The only documentation I have is from Freescale, and it uses terminology that is different than what you guys use. I'm sure things will smooth out after I get past the learning curve, but that process doesn't need to be so painful. I've never run into these sort of initial problems with any other embedded platform I've worked with. Even Microchip, who's IDE is historically lousy, it's intuitive or at the least well documented when it's not.
I've got code compiling now, but debugger still won't connect. As for what OpenSDA needs? I'm not sure what you're asking me. The drivers are all installed, it just isn't seeing the USB device in the debugger for some reason. Although Windows sees it. This may be a failing unrelated to KEIL. I'm waiting to hear back from the OpenSDA folks as well.
I've done all those same steps as well, probably a dozen times with different variations. Maybe it's a bad board. Everything else works though, I can manually flash, debugger just won't connect. I think I'm just going to start from scratch. Maybe I have an old OpenSDA firmware installed. Going to redownload everything and just start over.
One more thing I noticed. For some reason the SDA firmware was not programmed when I dragged it to the Bootloader drive directly out of the zip file.
If you still get a mass storage device when attaching this indicates that the wrong firmware runs.