When I am done developing my code for the LPC1111, I use the uLink programmer to program the board and all is good.
When I try to give the code to the production people to program the part in their realm, it doesn't seem to work right.
here is a portion of the communication that I got from the production facility:
The Keil uVision tool generates the hex file that we use for programming. However, this hex file appears to be missing information in the interrupt vector section. uVision seems to know better, since when you program with uVision and the Ulink dongle, all the interrupt vectors are programmed properly.
Right now, the only way for us to figure out the correct data is to program with the dongle, dump that data, then use the dumped data with MultiWriter. The hex file by itself will not work.
Example:
Line from the hex file provided by PKC
:1000100000000000000000000000000000000000E0
Actual data that the Ulink programs
:100010000000000000000000000000001FF9FFEFDA
I am unsure what to tell them...
What is PKC?
I suggest using fromelf.exe (it's in the compiler directory) to dump the ROM-able bits of the AXF file (i.e., no debug output) and compare that to the data from the generated HEX file, correlated with the section size data in the linker map file. You can also use fromelf to generate a new set of hex files (one per load section in the linker file).
PKC is just the customer's name...
This was a great idea!! Thanks!
I tried it though and what I got was exactly the hex file that I already had which the production folks seemed to think was lacking.
Do you know what the difference is between the two lines, where the second example ends in 1FF9FFEF?
It's a checksum. Per section 26.3.3 of the LPC111x user manual, the bootloader is looking for a valid checksum for the user flash image and isn't finding it in the hex file the tools made for you. So it hangs around waiting for something else to happen rather than run your code.
For some LPC projects (e.g., LPC185x) this step is automatically added into the project options when the project is created. Not so for the LPC111x, apparently. This Keil note explains how to use ELFDWT.EXE to compute and insert the checksum into the image.
Checksum creation is probably already being done, which would explain why you see a valid checksum in the dump from ULink. But the hex file is made by the tools before the checksum is inserted, so the checksum in the hex file you sent is invalid. Here's an example build run showing when the hex file and checksum are computed:
linking... Program Size: Code=3166 RO-data=238 RW-data=12 ZI-data=868 FromELF: creating hex file... After Build - User command #1: C:\Keil_v5\/ARM/BIN/ElfDwT.exe .\Objects\testboot.axf BASEADDRESS(0000000) ELFDWT - Signature Creator V1.4.0.0 COPYRIGHT Copyright (C) 2014-2018, ARM Ldt. and ARM Germany GmbH *** Updated Signature over Range[32] (0x00000000 - 0x00000018): @0x0000001C = 0xEFFFF81F *** Processing completed, no Errors. ".\Objects\testboot.axf" - 0 Error(s), 2 Warning(s).
You could add another custom build action to generate the correct hex file after the image is updated with the checksum.
Adam,
Thank you soo much for the explanation. It all makes incredible sense once you have the key! I don't think I ever would have found that on my own.
So I ran elfDWT.exe and even put it as a run command in the compilation process. However, I am not sure about how to do the next part "getting it into the hex file" by rerunning the hex file creation process....
When I do this, the hex file is still missing this checksum...
I followed another thread and found out how to create the hex file!!
The trick is to "uncheck" create hex file on the Output page and include a fromelf command as the second run command on the User page:
Run #1: C:\Keil_v5\ARM\BIN\ElfDwT.exe !L
Run #2 C:\Keil_v5\ARM\ARMCC\bin\fromelf.exe --i32combined -o !H !L
and Voila!! the checksum is included!!
Once again, thank you very much for your help!!