0
\$\begingroup\$

I created a bootloader image for my STM32 and I stored it in a specific area of the memory. I have a new Keil project which represents the application layer. By default, Keil generates a HEX file. What I want to do is to keep the bootloader image and flash the application layer in another area in the memory. The final FW will verify a GPIO input. If it is in a high level, the bootloader image will be launched and it will upgrade the application layer with a new image, otherwise (The GPIO input is in a low level), The normal mode is activated and the application will run. My question is:

  1. Should I convert the generated Hex file of the application layer to a BIN file in order to flash it to a specific area of the memory?
  2. How Can I specify the start address the application layer and its length ?.
  3. If I use a tool to convert a HEX file to binary, what should I do with the empty address reserved for the bootloader image ?
\$\endgroup\$
4
\$\begingroup\$
  1. That depends on your bootloader application. Can it read HEX files?
  2. You use the target dialog in the target options, or a scatter loading file.
  3. You do not include empty regions this in the image. Keil includes a tool to create binary files.

Note that you might want to sign your binary file with a checksum. The arm linker cannot do this. But you can do this with SRecord. (also removing/converting regions)

\$\endgroup\$
  • 1
    \$\begingroup\$ For an example of how to use SRecord to add a checksum, see the Startup Testing section of ROM Self-Test in MDK-ARM application note. \$\endgroup\$ – kkrambo Jan 2 at 19:07
3
\$\begingroup\$

I'm not familiar with the Keil toolchain, so I can only give general answers to which the specifics you will have to research in your toolchain manual.

  1. HEX files contain information on where to place the bytes. This might or might not be useful in your situation. The simplistic bootloaders I encountered so far handled just binary files. They started writing bytes to the location you told it to, so the address handling was outside of the bootloader.
  2. This is usually done with a linker file. The linker file will contain the address space of your application - which doesn't have to be all the available memory in a device. In a IDE there is usually a dialog which will allow you to change those settings. In a project build on the command line, you either have to specify it via command line parameters but usually it is a file (they can get rather complex).
  3. Do not include the (empty) space which is used by other parts. Start with the first byte of your application.
  4. Use a checksum mechanism to make sure you have a runnable application. For example place a CRC32 at the end of your space of your application, fill the unused space with 0xFF just to make sure that those are also included. (Application - 0xFFs - 32 bit CRC at the end). Hopefully your toolchain has a tool to do that (linkers probably don't do this, for IAR it's the ielftool which does this).
\$\endgroup\$

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.