STM32 Flash HAL: HAL_FLASH_Program about stm32-bootloader

[akospasztor]

Hi pycan,

While the ARM Cortex architecture theoretically supports both little- and big-endianness, (see https://en.wikipedia.org/wiki/Endianness), almost all of the Cortex M MCUs are little-endian. Therefore, the HAL_FLASH_Program should do exactly the described behavior :) So it must write the LSB byte first, then the MSB byte at last.

Btw, why would you like to have the "Big Endian" writing method? (MSB byte comes first)

Best,
Akos

[pycan]

Hi Akos,

Thanks for your reply.
I checked the hex file that is generated by the project and the data is indeed LSB. However, when it is written by the flash driver it will be LSB of LSB. Therefore, each DWORD has to be MSB and then pass it to HAL_FLASH_Program so that it ends up LittleEndianess in the Flash.

How did you handle this issue in your project?

[akospasztor]

Hi pycan,

First of all: are you talking about a hex file (https://en.wikipedia.org/wiki/Intel_HEX) or a binary file? Because those two are entirely different. Secondly, please excuse me, but your question does not make any sense to me.

Let's imagine we have 52651 (decimal) pieces of apples in a (really big) bucket. It's entirely up to you how you represent this number in your head or on paper, or in the microcontroller flash. The most important thing is that we have this amount of apples, and no matter which representation we use, we are always talking about the same number of apples.

Now, if we are talking about the human form, we can write the number "43981" on a piece of paper. Actually we, humans, learned to represent and imagine numbers in "big-endian" format (which is not exactly correct, since there are no "bits" in decimal representation). Anyways, that's why we write "43981" on the paper. If we want to represent the same number in a "little-endian" decimal format, then we would write "18934". It does not matter, as long as we both know which representation are we talking about. The numbers are just symbols. This goes the same for hexadecimal representation. If I decide to write this number in the big-endian format, it would be 0xABCD. If I decide to write it in little-endian format, it will be 0xCDAB.

Sorry for the long text, let's get practical. You write a small application, and you compile it into a binary file. The very first 32bit data of an application code is the initialization value of the stack pointer. This value has to be within the RAM range of the MCU, meaning it should be between 0x20000000 and 0x20050000 (this is written in the human-form, meaning big-endian), considering an STM32L496xx MCU. Let's say you have a stack pointer value of 0x20012345. When you compile your program and flash it to a little-endian MCU, the very first byte of the flash will be 0x45, then the second 0x23, and so on.

When you build an application and generate a binary output, it will be little-endian (in your case). When you want to use the bootloader to copy this application binary to the microcontroller flash, you don't have to do anything but copy the bytes one-to-one to the MCU flash. Take the first DWORD (8 bytes), pass it to the HAL_FLASH_Program without changing the byte order, and that's it.