Hello,
we noticed a strange behaviour when havin an image loaded from flash by the bootloader and get it executed.
We are not sure where the problem is loacted since it is really hard to debug.
So we created an elf-file and of that an rprc/tiimage. Additionally we have an Bootloader which loads those images placed inside our OPSI-Flash (it runs and starts correctly and loads the images). It does load the image correctly but when we connect to the application it stays inside an abort (sometimes data, sometimes undefined), when loaded with the symbols via CCS (definetly the application-symbols of the exact image inside the flash, which is loaded.)
When we load the same elf-file (so the same used for rprc/tiimage) to the SoC via CCS this problem does never occur.
It was hard to setup the debug-session and to get the debug running correctly but with some hw-breakpoints we could do it:
So the bootloader uses ONLY the first 0x00080000 bytes inside the internal SRAM. It does not use vectors at 0x00000000, which are of course used by our loaded application (that's where we placed the hw-breakpoint to get our application loaded and stopped before starting to run to debug and to get our symbols loaded correctly to see what happens).
Also our application does not use the first 0x00080000 bytes of the SRAM with any initializing stuff (marked with NOLOAD) in Linker-script.
The abort does happen somewhere inside __TI_auto_init_nobinit but we could not really locate why it occurs. It seems to be somewhere in the C++-initialization.
We are excessivly using the linker-script where we locate some sections at different memory-locations, e.g. something like this:
GROUP {
.textStack:
{
-l "libz.lib"(.text),
-l "liby.lib"(.text),
-l "libx.lib"(.text),
--library="libc++.a"(.text),
--library="libc++abi.a"(.text),
-l "libballuff-platform-mcu1_0.a"(.text)
} palign(8)
.rodataStack:
{
-l "libz.lib"(.rodata),
-l "liby.lib"(.rodata),
-l "libx.lib"(.rodata),
--library="libc++abi.a"(.rodata),
} palign(8)
} > MCU1_0_R5F_MEM_TEXT
we also place some sections inside our external RAM (via GPMC, not DDR!) and we noticed, when the c++-libs are not placed inside the internal SRAM but in the external RAM it is not able to run the application because even when loaded via CCS it directly gets an data-abort, when initializing the c++-stuff. So this was needed.
We may fiddle around with the linker-script right now but we have no clue what really produces this issue. In general we could load an application which has not that much linker-modifications and is kept simple (so just with general.text-sectionplacing and so on, eben with external RAM) from the flash by the bootloader. So it must have something to do with the linking-procedure or at least with the creation of the rprc-image and how the bootloader (or sysfw, I'm not sure her) loads the application into RAM.
It could happen (because that really sometimes happen), when I now change the locations of the sections, the problem is resolved temporarily, but it's not the first time we investigated this problem.
Best regards
Felix
