Can someone please suggest me a way to build a binary (monolithic?) Image containing the code of both cores of a STM32H745, so that I can copy it with drag & drop in the windows volume "NOD-H745ZIQ (X :)"?

[clemente]

I can run the code for the two cores if I program them separately from the Keil, but I would like to generate a .BIN image to send to my client, who is doing tests on a prototype, with the code for both cores.

I generate the .BIN with the "fromelf" program but it doesn't seem to allow me to merge two AXF files into a single BIN.

I tried to use "srec_cat" to merge the two .HEX but the resulting file, converted to .BIN, becomes a file of about 130MByte! Obviously I'm doing something wrong.

Can someone please suggest me a way?

Many Thanks

Clemente

[Tesla DeLorean]

What addresses are you building the M7 and M4 code for?

130MB suggests not creating an image for 0x08000000 and 0x08100000 ?

Data at 0x00200000 (ITCM FLASH) should also appear 0x08000000, so perhaps map it there for the purpose of making an image <2MB

I'd probably combine the two, perhaps with some packaging/wrapping, so the M7 code can determine if the M4 code image follows, and if it was different to the data in the M4 flash region currently, erase and replace that before proceeding.

[clemente]

Hello Tesla, thanks for your responce,

>What addresses are you building the M7 and M4 code for?

the Keil put the M7 code @0x08000000 and the M4 code @0x08100000. I have no problem to flash both core from Keil.

>130MB suggests not creating an image for 0x08000000 and 0x08100000 ?

I used this script for srec_cat:

# M7 HEX starting from 0x08000000
CORE_CM7.hex -Intel
# M4 HEX starting from 0x08100000
CORE_CM4.hex -Intel
# generate a complete binary file
-o .\MyCompleteProject.bin -binary

but I'm wrong with something because srec_cat create this file:

22/09/2021 09:03 135.414.736 MyCompleteProject.bin

>I'd probably combine the two, perhaps with some packaging/wrapping, so the M7 code can determine if the M4 code image follows, and if it was different to the

>data in the M4 flash region currently, erase and replace that before proceeding.

You are right. I think srec_cat is the right program to combine the two .HEX and create a monolithic .BIN image with both program, that I can drag&drop.

Can you point me to the way?

TIA

Clemente

[Tesla DeLorean]

Can you PM me the hex/object files in question so I can understand why this is happening?

​

C​urrently the tools seem to think they are working with different base addresses.

[clemente]

Hello Tesla, thanks for your response and sorry for my late reply.

I can't share my work, but I used another project from the ST Cube pack and there is the same problem.

I used this command script to run srec_cat:

# M7 HEX starting from 0x08000000
..\MDK-ARM\STM32H745ZI_Nucleo_CM7\Exe\STM32H745ZI_Nucleo_M7.hex -Intel
# M4 HEX starting from 0x08100000
..\MDK-ARM\STM32H745ZI_Nucleo_CM4\Exe\STM32H745ZI_Nucleo_M4.hex -Intel
# generate a complete Intel hex file
-o .\MyCompleteProject.bin -binary

and this file was generated as image:

22/09/2021 21:43 135.268.208 MyCompleteProject.bin

Attached the two .HEX files

Many thanks for your help

Clemente

[Andreas Bolsch]

I'd suspect your problem is that you want to generate a *binary* file at all. As "srec_binary(5)" explains in "Writing", this tends to generate such kind of mess.

My suggestion is to generate Intel-Hex or Motorola S-Rec for each core, these can simply be concatenated by 'cat' or 'copy', as long as they're ok (i.e. don't have overlapping address ranges). I don't know any recent flash programmer not supporting at least one of the two mentioned formats.

When converting to binary, all address information is lost (as it is plain binary), so the only sensible possibility is to (mis-) use file position as address, i.e. the file MUST span the range from 0x00000000 to 0x081??????. Or you must specify an address offset manually (see manual page above).

[Tesla DeLorean]

Probably needs an offset setting, but I'd have thought it could have inferred that from the .HEX files, and they are in order.

The basis for each is 0x08000000, 0x08100000 respectively, and the output would need to span 0x08000000..0x081FFFFF or a truncated subset thereof

I could do this with my own code probably quicker than fighting with srecord/srec_cat syntax and options

[clemente]

Hello Andreas, thanks for your responce,

I want to generate a monolithic binary image to "drag&drop" it to my NUCLEO.

I know that the binary file does not contain address information. This information are know by the "flash programmer" in this case the ST-Debugger inside the Nucleo. The ST-Debugger know that the binary file must be flashed starting at 0x08000000.

I need to build a complite 2MB binary image with the M4 positioned at 0x00100000.

TIA

Clemente

[Andreas Bolsch]

Yes, but you have to 'subtract' the offset as described in the man page cited above if you want to stick with srec_cat. This will create a binary where file position 0 corresponds to address 0x08000000. Or, alternatively, if you don't like to twiddle with srec_cat, just cut of the first 128 MBytes. On unix like systems, 'dd if=<old_binary> bs=1M skip=128 of=<new_binary>' would do that. Not very efficient, but ... Another way would be by use of 'objcopy' without the intermediate 130 MByte binary. But all methods require to specify the address offset more or less manually, because all these tools can't know it by magic.

[clemente]

Many thanks Andreas, you have make me to the right direction. 

Using srec_cat with the -offset option I'm be able to make an image file with the m7 and m4 codes positioned at the right address.

:: Binary file generated by Keil fromelf program
fromelf --bin -o M4.bin M4.axf
fromelf --bin -o M7.bin M7.axf
:: Single binary file with both code
srec_cat.exe CM7.bin -binary CM4.bin -binary -offset 0x100000 -o core.bin -binary

In this case I use the binary file generated using the fromelf program from Keil.

But I'm be able to generate the binary from the HEX using the srec_cat program:

srec_cat.exe M7.hex -Intel -offset -0x8000000 -o m7.bin -binary
srec_cat.exe M4.hex -Intel -offset -0x8100000 -o m4.bin -binary
srec_cat.exe m7.bin -binary m4.bin -binary -offset 0x100000 -o core.bin -binary

In this case I used to create the first two binary image subtracting the origin address by a negative offset, then I merged the two binary file putting the m4 code at offset 0x100000.

> But all methods require to specify the address offset more or less manually, because all these tools can't know it by magic.

You are right, but the fromelf program from Keil do the magic, I think because it reads the base address from the AXF file. I was mistakenly convinced that srec_cat did the same thing too.

Many thanks again.

Clemente