[URGENT] Failed to boot from flash with binary which was compiled with GHS

[harry_choi]

Hello Community,

I have met the booting fail problem with the binary which was compiled with GHS.

There was no problem with the binary which was compiled with gcc.

I generated the binary file following below step.

1) convert .elf to binary using gmemfile.exe in GHS

2) add IVT and application header (RAM start pointer=0x34000000, and RAM entry pointer=address of intc_vector and application size)

3) flash to QSPI

4) Run application 

When I run the .elf using S32DS and debugger even though it was compiled with GHS, it worked well.

Do you have some advise for this?

Thanks,

Harry

[harry_choi]

I found some misterious case during booting.

If I try to access greater address within SRAM size than binary size which was copied from flash to SRAM by BootROM, then the booting stopped. (maybe exception occurred)

For example, the size of SRAM in S32G274A is 8MB, and the binary size is 2MB.

Then the Bootrom will copy 2MB binary from flash to SRAM and will jump to start address.

But it looks if boot code(startup_cm7.s or startup.c) try to access 0x300000 or 0x400000, then the cpu stopped.

Is this normal case?

In my case, .bss section is last section and GHS compiler didn't generate binary data for that because the section will be cleared during booting.

The start address and end address are stored correctly in the memory.

Boot code will clear the .bss section and the address is greater than the binary size.

So, the cpu stopped.

Thanks,

Harry

[qdv5]

Hey bro,I have the same problem with yours,how did u handle this,do u have some solution?

[harry_choi]

Hi, 

I didn't receive any information about this problem from NXP, so I just guess the root cause related with MPU not GHS.

In my thinking, Boot ROM is likely to configure the MPU with the size of application image which is located in application header.

If you build with GHS, then the bss section will not be included in the image.

On booting, the application tries to clear bss section, and the MPU will cause access violation.

I believe there will be two work-arounds,

1) make the application image include bss section even though the section will be set with '0' in application.

2) Initialize MPU with default memory map table before clearing bss section or change the access rights of SRAM - I didn't try this yet.

Thanks,

Harry

[qdv5]

Thanks for replying,as u say,I tried to configuration the MPU,but it also didn't work well.

If include bss in image,it will be very large.I noticed that XRDC can control the acess rights of memory,but I don't understand the periph,do u konw how to use it?

[harry_choi]

I don't know how you configured MPU before clearing bss.

Could you check where the boot stuck?

In my experience, the CPU stuck at init_data_bss() function. Is it same with me?

If not, it may be a different problem with me.

I could verify it using LED.

Could you put the disabling MPU code in early part of init_data_bss function and test again?

Thanks,

Harry