Hello Community,
I have a problem to boot from QSPI flash on S32G-VNP-RDB2 board.
There is no problem to boot from eMMC flash on same board with same application image but I don't know why but the booting stuck from QSPI flash.
I generated the image using IVT configuration tool by align the same image for QSPI flash.
So, I have checked the end value of the binary image which will be copied from QSPI to SRAM by turning on the LED if the end value of the QSPI and SRAM are same.
Is there anybody to succeeded to boot from QSPI flash on S32G-VNP-RDB2 board with bit image(at least 2MB)? If yes, then could you help me?
Thanks,
Harry
Solved! Go to Solution.
There is a contradiction in this problem description. On one hand, you state
that your code fails to boot, on the other, that a LED is switched on after
a successful comparison of the SRAM and Flash contents, which can only happen
if some code starts and does the job to compare memories. Generic recommendations
for building bootable images for QSPI can be found on page 100 of S32DS User
Guide. Use S32DS debug and trace capabilities to find where and why your code
locks.
Best Regards,
Platon
Actually the stuck happened in the middle of booting from QSPI flash as I said in original post.
I guess memory allocation caused the problem because the problem disappeared after I replace xTaskCreateStatic() with xTaskCreate() and removed malloc().
Thanks,
Harry
Hi Platon,
I meant that it was stuck in the middle of booting.
I put the code comparing QSPI flash and SRAM on early side and I checked my binary code in the flash was copied successfully to the SRAM.
There is no problem with eMMC booting or S32 Debugger with same application image.
Thanks,
Harry
According to S32G2RM, Section 30.7, the boot sequence ends when the control is
passed to the application image. Once you are able to compare the memories in your code,
you are not in the middle of booting. The best way to see why your application
does not behave as you expect is to debug it.
Best Regards,
Platon
There is a contradiction in this problem description. On one hand, you state
that your code fails to boot, on the other, that a LED is switched on after
a successful comparison of the SRAM and Flash contents, which can only happen
if some code starts and does the job to compare memories. Generic recommendations
for building bootable images for QSPI can be found on page 100 of S32DS User
Guide. Use S32DS debug and trace capabilities to find where and why your code
locks.
Best Regards,
Platon