Hello,
My setup:
S32DS 3.6.4
S32 Flash Tool
S32 Debug Probe
S32E288-975EVB
I have a problem running a simple LED blinking code from QuadSPI Serial Flash with the S32E288-975EVB.
The code runs and builds with no issues when I use the S32 Debug Probe "S32E288_FreeRTOS_M33_Debug_RAM_S32Debug".
The problem:
I use the IVT tool to generate a BLOB. The BLOB contains:
1. the IVT image - I set the boot target as System Manager M33
2. a DCD file - for initialising RAM
3. The Application Bootloader binary - The .elf file format is too large to use as the application bootloader, which is why I use the raw binary. As I understand, the .elf adds some additional debug information, but shouldn't modify the code itself.
I then use the S32 Flash Tool to flash my BLOB on the board at location 0x0000_0000 (The start of QuadSPI_flash).
When I power on the board and attach to it using the S32 Debug Probe, I can see, that the Program Counter has gotten stuck at 0xefff_fffe, which seems to be outside the address range in general..? Also, when I attach to the board and set the program counter to the RAM_START, then everything seems to run fine at first, but at some point, the program counter ends up again at 0xefff_fffe. The Disassembly fails to read the command at that location.
Where or how can I find what leads to this erratic program counter value or does the value itself already somehow give an indication of the error?
I am also using freeRTOS, should that change anything in the bring up sequence?
What does the DEBUG_RAM version do extra, that my application bootloader or BLOB doesn't?
When writing my own application bootloader, what steps should I write in to my initialization script and what does the compiler take care of? For Example, do I need to initialize stack pointer, do I need to initialize any other peripheral besides RAM?
