Find tools that generate multiple binary files from intel hex file (with multiple sections)

[WSHAN.1]

Hello,

I’m using STMCUBE Version: 1.9.0  with  STM32h750 chip.

1. I would like to know to convert intel hex file to a binary file with multiple section addresses? We like to prevent a scenario in that intel hex sections are not sequential, and the binary file is address-less.

For instance, we have the next sections: D1 D2 D3 are not sequential 

currently, With the CUBE we got one binary file that includes all sections but sequentially. We can't use this file when loading that to the RAM.

Please Help.

Memory Configuration

Name       Origin       Length       Attributes

DTCMRAM     0x0000000020000000 0x000000000001ff00 xrw

ITCMRAM     0x0000000000000000 0x0000000000010000 xrw

RAM_D1      0x0000000024000000 0x0000000000080000 xrw

RAM_D2      0x0000000030000000 0x0000000000048000 xrw

RAM_D3      0x0000000038000000 0x0000000000010000 xrw

FLASH      0x0000000008000000 0x0000000000200000 xr

NOINIT      0x000000002001ff00 0x0000000000000100 xrw

*default*    0x0000000000000000 0xffffffffffffffff

[Pavel A.]

The C/C++ startup code of CubeIDE (and all other decent toolchains) can load data from a .bin image to one or several RAM areas. All this data is sequentially stored in a single .bin

Why this does not work for you? Are you having a X/Y problem?

[Tesla DeLorean]

Hex File aren't exactly complex.

Couldn't you post-process the file into a form that suites you?

Use the .ELF object form.

Looked at tools like SRecords

>>For instance, we have the next sections: D1 D2 D3 are not sequential 

Not really sure what that means in this context? The regions are sparse, but what does the model you want look like?

[WSHAN.1]

Thanks for your answers:

I didn't explain myself correctly, so here is some more information following my questions above :

We intend to store several images of our app in the external FLASH - for instance: app-Ver1, App-Ver2. We use only one of the app at any certain of time.

In general - The image of our application can be in any format, but we have limited space on the external FLASH. Hence, our chosen appearance format is a binary file that includes only the raw code and data.

Compared to the Intel Hex - this binary file doesn't handle any address, size of the image, and any sanity check information of the block we need to copy to the RAM.

In addition, the fact that the code and data need to be located on several sections of RAM D1 D2 D3 - puts more complications on the bootloader, requiring knowing where to copy each section.

So something need to change here. We need to add the missing information to the binary data.

After power-up, The bootloader, running from internal FLASH, copy the relevant image app to the RAM and jump to start.

To copy the image to RAM, to bootloader do this, the target address's information to copy and size should be part of the binary file (for instance, a simple header with this information will be helpful).

Then, the bootloader copies each part of the code/data to the appropriate section location address.

For instance, section D1 will be copied to the section started with 0x24000000 (with offset) using the size of this section. Similarly, for Section D2, D3.

Yes - wrapping each section of the code/data section must be done in the post-compiling phase ('the tool').

Assuming that, using a St programming tool - store those parts of 'binary files' (including code/data + header) into the external FLASH.

The question is - does this tool exist?

We want to know if ST (or anyone else) builds such a tool.? It seems a generic tool for many applications.

And, no, this is not XY's problem.

NOTE: Yes - we understand the intel hex format, and We can build such a tool that extracts the binary file from the Intel-Hex file and adds a simple header. We prefer to use a generic tool (if it exists) for this job.

w.

[Pavel A.]

> We use only one of the app at any certain of time.

...

>To copy the image to RAM, to bootloader do this, the target address's information to copy and size should be part of the binary file (for instance, a simple header with this information will be helpful).

Just copy the image to the RAM, at it intended target address. Then let its startup code to initialize its data. The bootloader indeed could replace this function of the startup code, but start from something simple.

The bootloader should only know the image (.bin) size to copy, and - good to have - something for integrity check (CRC, signature etc.). This info can be part of the the image, or outside (like a table of pointers and sizes).

> The question is - does this tool exist?

Not known to me. I did this myself for several projects where use of a "normal" filesystem is not justified. It wasn't too hard.