How to create a HEX file for LPC43 for internal flash memory that can be used with FlashMagic?
The standard hex file that's created starts at address 0x00000000 therefore when downloaded into the chip does not make a working program.
See on Project -> Option for Target-> Target and Read Only Memory Areas her is start address and size On chip ROM area
My question was not how to get a working image but how to get a hex file. I have an image that works with no problem when donloaded to the micro with a programmer. But how to convert it to a HEX file that can be used with Flash Magic?
Select appropriate IROM address base in Target Pane, check "Create .HEX File" in Output pane
This is exactly what I do. The HEX file I get starts like this
:020000041A00E0 :10000000F0210810051B001A0D1B001A0F1B001A07 :10001000111B001A131B001A151B001A5A5A5A5AA0 :10002000000000000000000000000000171B001A84 :10003000191B001A000000001B1B001A1D1B001AD0 :100040001F1B001A1F1B001A1F1B001A1F1B001A60
So the beginning looks correct, the starting address is 0x1a000000
However when Flash Magic downloads it to the micro it's diplaying addresses starting from 0x00000000 in the progress bar.
The problem may be somewhere else though. The checksum used by the bootloader for valid user code may not be correct. Is it calculated automatically when the HEX file is created and placed in the hex file?
After downloading the hex file to the micro my program doesn't start, the bootloader is still active.
It is the checksum problem. I compared flash memory contents for a working program downloaded with a flash programmer and flash conents for the hex file downloaded with Flash Magic. The diference is only in the checksum area.
So the question is how to automatically generate a HEX file for LP43 so the checksum is placed in it?
The common solution when needing download files with checksums is to add a post-build step in the project. Then write a tiny program that computes the checksum.
Either read the hex file, modify it with a checksum and save.
Or potentially use Keil's tool to convert your data to binary if you find it easier to work with raw binary data.
Keil's linker can't know if a specific boot loader for a specific platform might have special needs besides the actual binary data that forms the program. Especially since lost of customers writes their own boot loaders with totally own requirements. So the checksum might use CRC-32, CRC-64, MD5, SHA-1, Adler-32, ... And there are many ways a checksum can be stored. Should it be first in the file. Or last in the file. Just after the end of the actual code. Or in the last bytes of the internal flash of a chip. Stored big-endian? Little-endian? In binary form? In hex form? uu-encoded? And maybe that little checksum record is also expected to store a magic number to signify the intended platform, so firmware for hardware revision 1 can't be accidentally downloaded into hardware revision 2. And there might be a need to store a firmware version and potentially a build date in that meta-information record.
So in the end - customer-supplied build-steps are a great route to fulfill special bootloader needs.
Wow - first time in a long time I get text-based Captcha. So Keil staff has - in my view incorrectly - assumed that text-based captcha will solve the spam issues. Captcha is a great way to waste our time. But not a good solution to avoid spam. Why should we users have to suffer, because Keil can't invest the time and use real accounts?
The solution is first to run this $K\ARM\BIN\ELFDWT.EXE !L BASEADDRESS(0x1A000000) Which is needed anyway.
Then this $K\ARM\ARMCC\bin\fromelf --i32 --output=name1.hex name2.axf
That fixed the problem.
Of course the automatic HEX generation needs to be disabled.
BTW, I think LP43 is a great micro that deserves much better documentation. It's really hard to start working with it.