0
\$\begingroup\$

I am trying to store my hex file in another sector of the flash memory i.e (0x00050000) I want to store a hex file at different sector of the flash and to change the execution point to that address through my bootloader. I am able store and change the address through the MCUExpress IDE. Now i want achieve the same without using the IDE.

Through IDE:-
I have flashed the .hex file at 0x00050000 and i'm changing the execution pointer to this address through MCUExpress IDE settings. At 0x00000000 i have my boot loader code which changes the execution point to 0x00050000.

When i write the .hex file(Some data)(Image 2) content at the location 0x00050000 , i observe that the stored hex data at the address is different . I checked it through flash magic. My data is being displayed in the ASCII region rather than the Hex region of the display memory in flash magic.

Image 1 : The Hex Data and its ascii form when observed through flash-magic when actual hex is flashed through IDE

The Hex Data and its ascii form when observed through flash.

Image 2 : Hex data when written through the application code. Hex data when written through the application code is being converted to some format.

So how to copy the hex into flash through application code ? Is there any conversion happens while flashing the hex file ?

\$\endgroup\$
  • 1
    \$\begingroup\$ You flashed ASCII text which represents your hex into your flash, not the actual binary code. Compare the text near the end of the 1st line "0080001" followed by the 2nd line "06D010..." to the 1st line of your hex dump "008000106D010...". You need to flash a .bin binary image, not a .hex text file. But even then it's not likely to work if you haven't compiled your code to run at that different location in memory - all the absolute jump addresses & lookups will be wrong. \$\endgroup\$ – brhans Feb 21 at 14:04
  • 1
    \$\begingroup\$ The problem is obviously that your application code reads the hex literally from the UART, without converting from Intel hex to binary. Study Intel hex, it is not "hex" as in raw binary, but an industry standard ASCII file format. \$\endgroup\$ – Lundin Feb 21 at 14:17
  • 2
    \$\begingroup\$ You should use something like xxx-xxx-xxx-objcopy (arm-none-eabi-objcopy if that is an NXP Arm...) to produce a flat binary output rather than a hex file from the original elf, or from the hex. But you will also need to link the code to the desired address, or be sure that it is all self relative. Your overall goal is far too broad to fit into a question here, if you are actually writing a bootloader that is typically a project that requires an understanding of the whole system, so perhaps you should look for an existing one, possibly (for some brands at least) already in the chip's ROM. \$\endgroup\$ – Chris Stratton Feb 21 at 14:34
  • \$\begingroup\$ okay, Thank you all. \$\endgroup\$ – Keerthana R May 16 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.