My binary code file produced by Keil's ELF tool has about 320 bytes more than the 'same' JTAG upload code file. It looks like the last 320 bytes are the same as the previous 320 in the binary file. i.e. From 0 to 0x34DCB, both JTAG uploaded file (CPU Flash) and the binary file are the same. From 0x34DCC-to 0x34F2B (end of code) is 0xFF in the code memory. But, in the binary file, it looks the same as 0x34C9C-0x34DCB (the prior bytes). I would think the binary file and the uploaded JTAG file should match exactly for the purpose of using IAP off an SD card.
Sutton
I'm not sure if I fully got your post but the ELF file is not the same as the bin (binary file).
The ELF file contains extra information such as the location of where to load the code.
There is a tools called fromelf that converts ELF files to binary files that could be used for firmware upgrades using IAP.
I am using the 'FROMELF' tool to generate the binary file from a .AXF file. That binary file is uploaded using IAP into CPU Flash. However, the JTAG upload is different. Because sometimes my automatic upload process hangs upon CPU restart (but is fixed by uploading the same code via JTAG), I'm trying to understand the difference between the JTAG upload and the IAP upload of the binary file.
As far as I know there should be no difference as to what is programmed into the flash.
Of course when using the debugger interface of uVision with a JTAG there may be some initialization code that is run?
Also what micro are you using? Are you modifying the CRP? Are you writing to the entire flash from IAP? If so is the code that writes to the flash executing from RAM?