This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

convert object file to hex?

Hi all

I am working on STM32F030R8 chip,using Keil MDK. For every unit, it carries it own characteristics, and hence for every calibrated unit, I need to re-flash a part of the flash to put the characteristic in.

For example, the characteristics is an array of bytes, so I create a characteristic.c file to put the data at specific location: (0x0800F000)

const unsigned char array[] __attribute__(at(0x0800F000)) = {1, 2, 3, 4, 5, 6} ;

The compiler will generates object file: characteristic.o

Now the question is, how can I get this object file converted to a hex file, that I can just page flash into the target? I think there should have simple command from the MDK suite.

Thanks

Calvin

  • Well there is a check box option in the project output pane, and there is FROMELF

  • Hi

    This is not a complete project, there is no main, and no reset vector, no stack, no heap, and the project output fail to generate hex file.

    I am not familiar with formelf.exe, may be someone can share his/her expertise on this.

    a complete example on the command line is appreciated.

    Rgds

    Calvin

  • Given your example data, it would probably be simpler to knock up some simple tool to enter text and output hex data. So many ways and languages to do it. For something as trivial as that, I'd be tempted to knock up a Python script.

    Could hardly be described as a difficult task.

  • Hi

    Thank you for your suggestion.

    The example that I have given here is a stripped down sample to demonstrate my intention. The actual characteristic is far more than this. It is a complicated multiple layers of structures and sub-structures.

    Rgds

    Calvin

  • I suspect you don't know the full implications of what your asking.

    Converting an object file to a hex file is not normally a requirement. Object files normally contain (at least some) relocatable items that are resolved during the link.

    If it really is complex, then another alternative might be to link your module into a dummy executable, create a hex file from that fully linked executable and then extract the portion that interests you.

  • Documentation, review
    http://www.keil.com/support/man/docs/armutil/

    The underlying format is from an era when processors clock at 1 MHz and below, so it is not at all complex
    http://www.keil.com/support/docs/1584/

    Dumping a C structure to a .HEX file is something a first year college student should be able to do in under half an hour.

  • The actual characteristic is far more than this. It is a complicated multiple layers of structures and sub-structures.

    Even so, the compiler is entirely the wrong tool for that kind of job. If you need to patch your hex files, then you should exactly that: patch them. Not generate new ones from scratch, for every unit.

    Even though it's probably possible to automate the compiler to the extent you have in mind, it's almost certainly not an option to run the compiler for every unit you produce. It would be too slow, too expensive, and there would be nobody around at the production site who knows how to use it.

  • create a hex file from that fully linked executable and then extract the portion that interests you.

    Compilers tend to be too clever for such simple plans to work reliably, these days. Unused data will be removed from the executable, or the compiler will directly use the known values verbatim, instead of referring to the master instance of the constant indirectly. So patching the master copy may have hardly any effect at all, or it might only affect a fraction of the places where that number was used. Calling the result not exactly well-behaved will probably be a massive under-statement.

  • Hans-Bernhard Broeker, you are right, compiler is very clever on this, and I am aware of this. My code to address this is to use a pointer to the structure, so the master code is like:

    #define structurePtr (const structureType *)(0x0800F000) // my intended calibration structure location

    in the code, I reference the member as: structurePtr->entity.member1 ......

    So the compiler cannot do the clever thing that you mentioned, and is forced to address the corresponding location for the data.

    Here is my solution to my own question, with this simple example:

    create the test.c file containing a single line:

    const unsigned char array[] __attribute__((at (0x0800F000))) = {1, 2, 3, 4, 5, 6} ;

    create a batch file test.bat containing 3 lines:
    armcc test.c
    armlink --output test.axf test.o
    fromelf --i32 --output test.hex test.axf

    The 1st line armcc complies the c file with test.o output (with warning, can be ignored)
    The 2nd line links the file to test.axf (with warning, can be ignored)
    The 3rd line create the hex file that I want.

    running the batch file gets instant result, even with my complicated structure.

    Then incorporate STM's flash Loader Demo (bootloader demo from STM - STMFlashLoader.exe) into the batch file as the fourth line to complete the job by patching the flash page.

  • running the batch file gets instant result, even with my complicated structure.

    Wow. Where do you buy such hammers? I've got a pile of nuts here to crack.

  • modified the 1st line in the batch file to make the 2nd line obsolete:

    armcc -o test.axf test.c

    So the final batch file of 3 lines finish the job in one go:

    armcc -o test.axf test.c
    fromelf --i32 --output test.hex test.axf
    STMFlashLoader.exe -c --pn 4 --br 115200 -i STM32F0_5x_3x_64K --fn test.hex .................

  • Are you saying that you do this for every unit made?

  • Lots of people use a commercial-grade downloader software when factory-programming - so the downloader supports a script language where it can auto-generate serial numbers, MAC addresses, production week or other information and inject into the download on-the-fly. And can at the same time write an output file in CSV or similar for import into a production database for later tracking.

  • Per Westermark, this is exactly the approach. My way of doing this is very similar. So an application that can get characteristics from csv file, somehow generate the patch hex data code to flash to the target.

    This somehow way can be intake the csv record, and in my example, generate the c file, shell out to call the compiler/linker/fromelf to get the hex and then page flash to the target.

    Nevil Chapada - yes, need to characterised for every unit, as Per Westermark's example of MAC addresses and serial numbers.

  • I'm well aware of the requirement to individually program each unit with specific detail. I've done it myself many, many times during the past 25+ years!

    What I have never considered and would never seriously consider is using the compiler to produce that specific detail. It just sounds plain wrong!