I'd like to use the .hex output of the Keil compiler to program
After reading thu http://www.keil.com/support/docs/1584/
i created a python which turns the hex file to c sructure
Then I read the ADU320 flash to compare FLASH content with Hex
The data in the ADU320 flash differs from HEX file
so what needs to be programmed ?
Why? What is the point of that?
Surely, your programming tool already has a 'Verify'
"The data in the ADU320 flash differs from HEX file"
So how, exactly, does it differ?
Are you sure that the chip was actually programmed with the same
code in the first place?
Note that a Hex file typically only contains data for the
locations that actually need to be programmed - so there may be
Does the code use Flash for any data storage?
Maybe you have bugs in your python converter and/or your
My product is a module based on the ADU320.
I have a host system which simulates customer system and want to
program the module. Until now I used the Keil with ULINK programmer
to program module
The point of the converter is to allow easy embedding of module
ADU320 code into host system
The hex file is the output of the compilation which is then
programmed with Keil with ULINK programmer. Why should the files
differ in such a case ?
They differ at many places and the python seems to work well after
some random tests in the hex layout
i look for gaps in the he altho it looks consecutive
any idea how the keil goes about programming from code -
>After reading thu http://www.keil.com/support/docs/1584/
i created a python
>which turns the hex file to c sructure
I don't know why you are doing this. A hex file is text and two
hex files can be compared with a text editor to see if they are
identical. If the hex file comes from different sources (programmer
or MDK), you might have to convert it. However, there are free tools
available to convert files to any format with many options. Please
(convert to binary file)
(convert to C compatible constants)
Please send an example of the code differences in the support case
you have opened.
.HEX file do not have to be linear, or describe all memory. You'd
do better converting each to a binary image for the ROM(s) in
question and doing a binary compare. If you normalize the files you
might be able to do a diff/compare, but if you understood the data
and what it is describing you'd appreciate there are more effective
ways to do that.
The Keil tools send programming code into RAM, and then send
blocks of binary data in to RAM, and execute the programming code.
They don't send the .HEX or .AXF files directly.
Thank you for the links actually I looked for these kind of tools
but then wrote them..
Now I verified with my program again and after reading the KEIL
programming process I reset my module before creating the dump
from within my design, so that I was not running with debugger, and
now indeed the Keil output and memory dump look identical.
I also dumped from within the Keil using the save command and
received the same file.
So I think we can close the support case
View all questions in Keil forum