How to know which data in hex files is for internal Flash & which is for External QSPI Flash?

[Harwinder Singh]

Hello Everyone,

I am working on a project in which we load hex or bin file in USB pendrive and stm32F7 will read this file over USB_FS using Fatfs. Then it will program it self using same hex file(IAP from USB pendrive ). if i am using only internal flash every thing is fine no doubt about hex or bin file, But if i will also use external qspi flash then IDE like cube ide or Keil are generating single hex or bin file for both Memory. Now my question is that how to identifies that which data in file is for internal flash and which one is for external one?

Thanks

[hs2]

You need to decode the hex records properly. A hex file might contain (load) addresses of multiple memory regions besides the program start address.

[Tesla DeLorean]

The format is not unduly complicated and is processed linearly, a line at a time.

The combination of segment and data lines should decode into an address, the range of address dictating which device the data should go. Addresses in the 0x90000000 range being external QSPI.​

[Andreas Bolsch]

By address, the QSPI memory space starts at 0x90000000. That's fixed in hardware.

[Harwinder Singh]

ok Thanks for your answers. Any idea about bin file because mcu is taking time to decode hex file. So if it is possible with bin file it will take less time.

Thanks

[Andreas Bolsch]

A binary file would be a rather bad idea. As there is no address information (except maybe for start address) a bin file would span the gap between the internal flash and the QSPI address range ... You'll get hundreds of MBytes then. Not really nice.

[hs2]

In comparison to the time needed to flash/write the data decoding is negligible. The bigger drawback might be the amount of data to transfer due to the ASCII encoding..

[Harwinder Singh]

Agree with all points. Thanks all for your answers. Further i will go with hex file and let you know the results.

Thanks.

[Tesla DeLorean]

Here we package firmware binaries, the files have structure so the size and addresses are known. Generally you want the things signed, and often compressed or encrypted.

The .ELF objects generally have too much noise in them, symbols, etc, but much of this can be minimized or stripped. Alternate object files can also be constructed.

ST's DFU file also encapsulates multiple memory regions in a binary form, the format is documented, and pretty compact, and has a CRC for checking integrity.