Other Parts Discussed in Thread: SYSBIOS
Tool/software: TI C/C++ Compiler
Hello,
Abstract of the Problem:
We are updating all libs of our c6678-Project to newer versions which are coming with the the "sdk-rtos-c667x-evm-04.03.00.05". In the current
state the MAR-CPU-Registers are corrupted when reaching the "main" after "_c_int00". Depending on the values, some Core's won't see the
MAGIC_ADDRESS, because thier addressspace became unwanted cacheable in Core_0. The DSP is booting from a SPI-Flash.
///////////////////////////////////////////////////////////////////////////////
Version/Build details:
Custom-Board. Our Project is compiled with the 8.1.3 Compiler in CCS 8.1.0.00011.
Probably most relevant version changes related to this Problem:
Old:
XDCtools: 3.25.4.88
SYS/BIOS: 6.35.4.50
(PDK 6678: 1.1.2.6)
New:
XDCtools: 3.50.03.33
SYS/BIOS: 6.52.00.12
(PDK 6678: 1.1.2.6)
PDK isn't changed to the PDK C667x 2.0.9 because we can't currently build with this version in the moment.
Question0: Is a change neccessary?
The error occurs with BIOS config "instrumented" and "debug". The project is compiled in both cases without optimization.
The constants for MAR's are placed in *.map:
.const.3 0 0c2aef80 00011d44 UNINITIALIZED
"other stuff"
0c2bba70 00000400 firmware_pe66.oe66 (.const:ti_sysbios_family_c66_Cache_marvalues__C)
"more other stuff"
Sidenote0: const.3 is placed in MSMC-Ram
Sidenote1: When looking into firmware_pe66.c we can see the correct default values for the token "ti_sysbios_family_c66_Cache_marvalues__C"
Question1: What is the exact meaning of "UNINITIALIZED"?
The MAR's Hardware addresses are beginning at: 0x01848000 (MAR0-MAR255)
///////////////////////////////////////////////////////////////////////////////
What happens with screens:
The first screen shows the state of the addresses when we reached the "_c_int00" routine. The constants are not loaded. The MAR's have default values.
This is funny because they have exactly the same values what should be written anyway, when the constants are loaded.
The second screen shows the state of the addresses when we reached the "main" function. The constants are loaded. The MAR's are broken, because the last
nibble comes from the uninitialized constants. With the Debugger we could track that the MAR's are indeed initialized with the uninitialized constant
values. So the constants must be loaded sometime later.
With the old libraries we obviously didn't had this problem.
Question2: Are the constants loaded too late or the initialization of the MAR's is too early?
Question3: When should the constants be loaded?
Question4: Who is responsible for loading the constants?
Sidenote: Reseting the CPU/System and loading the *.out into the Core0 didn't change anything.
Sidenote: When the constants are loaded (second screen state), then resetting the system causes all the Cores to start correctly.
If more informations are necessary, please ask.
Thanks and kind regards,
Lukasz