STM32F401VET6 flash partition to store 3 binary files at particular flash addresses. These binary files need to be used for some product applications.

[JSaro.1]

We have STM32F401VET6 in our product development. Currently, our project (makefile) compiles and stores application binary in STM MCU internal flash. We would like to store three other binary/hex files to the STM MCU internal flash as part of the building (makefile) of the project. We intend to store some other sub-components FW binaries in STM MCU's flash and use them during product use.

As we can see that flash address space is divided in the below table,

we would like to have 4 partitions as follows:-

1. Application Binary when we compile the project:- 0x0800 0000 to 0x0805 FFFF
2. Componenet 1 binary from 0x0806 0000 to 0x0806 7FFF (32 KB)
3. Component 2 binary from 0x0806 8000 to 0x0806 FFFF (32 KB)
4. Component 3 binary from 0x0807 0000 to 0x0807 FFFF (64 KB)

During the product use, if Component 1 needs to be updated, STM MCU will just read binary starting from 0x0806 0000 to write its FW. Similarly other two components will be updated.

Can somebody provide a way to the update the building of a project in this manner so that the flash gets written in that manner.

 

[TDK]

Going to be hard to have multiple independent components share a page of flash effectively and update them independently. Since they share a page of flash, you would need to read out page, erase it, and rewrite all components.

You could modify the linker file and place code into specific sections, but in order to update those without affecting the rest of the program, you're going to need a lookup table which tells the main program where each function is within the flash, or fix them to specific locations. Not something I would recommend.

[JSaro.1]

@TDK​  Then, what will be your recommendations to store 3 files in the flash. We want STM MCU to read these files and update FW using those files ?

[TDK]

My recommendation would be to keep it as one binary and spend your mental effort on making the program better instead. An in-place firmware update can be done in a variety of ways. Storing it in the second half of flash and using a magic keyword to trigger erase/updating of the original firmware is my preferred method.

Is there a compelling reason to keep components separate?

[JSaro.1]

@TDK​ Yes, we will have one binary-only but these subcomponents are outside of the product and STM MCU needs to read the binary content and send it to the sub-component over UART. So, STM MCU must have understanding the start of address from where it needs to send these bytes to update sub-components.

If not possible in binary, can we append hex if we have sub-components FW in hex format. Thanks

[TDK]

Oh, so these are not binaries used by your application, but they are sent somewhere else to be used. I misunderstood that. Then you can treat them as raw data as far as the STM32 is concerned.

Hard-coding the start/end address of each seems fine.

Converting the HEX files to BIN would probably be best, since I'm guessing they will be located somewhere else on the sub-component. Then you can write the binary to the given address range. Note that you'll still need to erase the entire flash page when updating these.

[JSaro.1]

@TDK​ 

Yes, you got me half-correct this time. Yes, that will be just raw data as far as STM32 is concerned.

Our ask is --> We have three files file1.bin , file2.bin and file3.bin and these file are already available in code files/repo and we want to store them at a particular address as per the above message:-

1. Componenet 1 binary from 0x0806 0000 to 0x0806 7FFF (32 KB)
2. Component 2 binary from 0x0806 8000 to 0x0806 FFFF (32 KB)
3. Component 3 binary from 0x0807 0000 to 0x0807 FFFF (64 KB)

Is there any reference example we can find where our build artifacts (like makefile, .linker) will make sure that these binary contents get written at those addresses as part of building the project itself? If this becomes possible, STM MCU can update subcomponents by reading binary starting from a particular address. ?

[TDK]

Okay, so you have multiple BIN files (or maybe one HEX and three BIN).
Convert BIN to HEX with this, making sure to add the appropriate starting address.
https://www.keil.com/download/docs/113.asp
Combine HEX files with this:
https://developer.arm.com/documentation/ka004500/latest
(HEX files are text, so you can also combine them with copy/paste or similar, but do not duplicate the last line.)
Then you should have a single HEX file with all the data in it which you can flash to the chip.
These commands can be added as a post-build operation on the main file.
Hopefully I understood fully this time around.

[Tesla DeLorean]

You'd typically do the merge or image construction post-link.

Binary components can be merged and manipulated with basic C file handling function, ie fopen,fseek,fread,fwrite, and fclose.

The .HEX format isn't unduly complex, you could create these on the fly, or use other tools to generate and/or merge.

The linker script or scatter file can define the addresses used, SystemInit() can manage the setting of the correct base address for the vector table.

Generally people don't split the 128KB flash sectors in this way as they can only be erased as a whole.

Consider if you can better manage the low range smaller sectors to hold these things, they will be a lot easier to replace individually.

[Pavel A.]

@JSaro.1​ Note that your components 1,2,3 occupy parts of one 128K erase block.

To rewrite only one of them you will have to erase the whole block and save somewhere other two components.

So, you'll want to change the layout:

• the main app binary at 0x08020000, sectors 5,6,7
• Component 1: at 0x08000000 sectors 0,1
• Component 2: at 0x08008000 sectors 2,3
• Component 3: at 0x08010000 sector 4

At the start address 0x08000000 should be a small "bootloader" or startup code that jumps to the main binary.

This boot code will take a part of component1.

--pa