2375584_en-US

[#1]

Running 2 M7 binaries for M7_0 and M7_1 from SD card on S32G-VNP-GLDBOX3 (S32G399)

Hello,

I have created two projects in S32 DS, for M7_0 and M7_1, I have tested via debugger that both cores are executing the respective applications. Now I want to test by running both binaries from SD card.

Previously I have tried running one application with DCD and IVT setup and flashed via S32 Flashing tool. It works but I am not sure how to flash two binaries with the same workflow or will it be a different workflow altogether. The goal is to have them running out of SD card. In future there will be a total of 4 binaries for each M7 core.

Thanks,
Rizwan.

Re: Running 2 M7 binaries for M7_0 and M7_1 from SD card on S32G-VNP-GLDBOX3 (S32G399)

This is how I was able to boot both M7_0 and M7_1 binaries without NXP autosar bootloader:

• let ROM boot only one IVT image from SD
• make that IVT image contain one combined application payload
• place both M7_0 and M7_1 raw binaries into that payload at their correct linked SRAM offsets
• let M7_0 start M7_1 at runtime using the normal core-start mechanism

The important point is that ROM does not boot two independent M7 application images for you. It loads one application image. So two separate .bin files cannot just be flashed independently and expected to boot together from SD.

What I did

My linker placements are:

• M7_0 load base: 0x34304000
• M7_1 load base: 0x34D04000

M7_1 start/vector address is:

• 0x35204400

M7_0 entry address is:

• 0x34304010

So the combined payload has to look like this in memory:

• offset 0x00000000 -> M7_0 binary at 0x34304000
• offset 0x00A00000 -> M7_1 binary at 0x34D04000

This means you must create a padded combined binary. Simple concatenation is wrong unless the second image is linked immediately after the first one.

Why this is needed

ROM copies one contiguous application image to SRAM. If M7_1 is linked at a higher SRAM address, the gap between the two images must exist in the combined payload as padding.

So the image creation logic is:

• choose base load address = M7_0 load address
• place M7_0.bin at offset M7_0_ADDR - BASE
• place M7_1.bin at offset M7_1_ADDR - BASE
• fill the gap with 0x00
• use the combined file as the application payload for IVT packaging

My IVT/application values

For my current build:

• application load address: 0x34304000
• application entry address: 0x34304010
• combined payload size: 0xF3C008

Tools I used

I made a small Python helper plus a .bat wrapper:

• image_util.py
• combine_m7_bins.bat

The batch file runs the combine command directly and outputs:

• artefacts/combined_m7.bin

I will attach/upload those files separately.

Important runtime note

Combining the binaries is only the image-loading part.

You still need correct multicore runtime behavior:

• M7_0 must start M7_1
• M7_1 must be started at the correct vector/start address
• global init must be coordinated between cores

In my setup, M7_0 is responsible for releasing M7_1.