- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hello,
So I have a firmware which uses different load- and run-addresses. We also use the STS 3.1.0 compiler and MCU PLUS SDK 9. CCS is version 12.4
This one worked some months ago (with older SDK and LTS 2.1.3), but now we are reactivating it and somehow only one of the code-parts work, but the other doesn't.
Without making it too complex for now: We made a UNION in the linker-script like it is described in the compiler-manual, as well we are using the generated copy-tables, the copy_in-command with the respective run-addresses and a CacheP_wbInv at exactly those addresses afterwards.
1.
Debugging is not possible. It always loads the file which is related to the not active code-part and not the one that is really loaded. Thus the symbols shown also don't match.
How can I manually tell CCS to use the other file and symbols?
Those are the generated tables:
2.
Also I noticed that I can't somehow check the memory view as soon as I want to check an address after 0x701a5360 it says: "MAIN_Cortex_R5_0_0: Trouble Reading Memory Block at 0x701a5360 on Page 0 of Length 0x1bd"
an example of the memory-view:
here it's still working:
as soon as I scroll further:
If I scroll back again it works and further it doesn't work again and so on.
Does this have something to do with the cache writeback invalidation?
3.
Additionally I noticed that the loaded code even at the load-address is not the real code that should be loaded. So of course the copied in code is also the wrong code. The generated tables point to valid addresses and at least for one part it works also correctly and the code is correct in the load-address and run-address later on. The other part somehow has just garbage at its load-address.
the linker script would put the sections to its load-address here, like seen in the map-file:
notice two sections have the same run-address.
So I thought about dumping the sections directly out of the elf-file with the command:
tiarmobjcopy --dump-section .XCode=path/Xcode.bin (first one)
tiarmobjcopy --dump-section .YCode=path/Ycode.bin (second one)
I checked them with a hex-viewer and "XCode"-section looks different (so correct) than the one loaded at the load-address by CCS (which is garbage).
So the section that is defined in the linker script should look like this:
so for the first "XCode"-section it looks like this at the load-address:
It's not what is in the dumped section-bin-file.
As we may see the other "YCode"-section:
and what's at the load-address:
if we change endianess it's exactly the expected code. So this one works!
The code for them in the linker-script looks like this:
UNION
{
.XCode:
{
-l "libX.a"(.text),
-l "relocatableobjectX.out"(.text),
} load > MCU1_0_PSRAM_CODE, palign(8), table(X_CODE)
.YCode:
{
-l "libY.a"(.text),
-l "relocatableobjectY.out"(.text),
} load > MCU1_0_PSRAM_CODE, palign(8), table(Y_CODE)
} run = MCU1_0_R5F_MEM_TEXT
in the source (with dummy-names, since original code is nda and so on):
So since the section is correct in the elf-file itself as we checked when we dumped it, what happens here when I load the elf-file? what can go wrong that even at the load-address the wrong code is loaded?
My Debug-configuration for Program/memory load is the following:
I also tried to run a program verification but it says that it's ok. what I doubt heavily.
Best regards
Felix
Hello Felix,
Are you using the same AM243x device in terms of GP versus HS-FS?
To determine if the device is secure, refer to field parameter for device revision: "r" of the Device name. If the Device Revision is "B" or a subsequent alphabetical letter, then the device is a Secure device.
The proper expert for this topic is out of office until Wendesday and so please wait until then for additional support on your question.
Regards,
Erik
