We are currently debugging a C167 project that has been developed 10 years ago, it's approx. 80x out there in the field. We found out that there is some misconfiguration in the memory map, the NCONST class is located to the XRAM memory address range.
NCONST( 0x00E000-0x00E3FF)
Now, the M66 linker output tells us, that 30bytes of constants have been located there. The linker name of this constants is ?C_LIB_NCONST. What is this and what is it used for? Doesn't seem to be important since the systems out there cannot use these constants. But we'd like to know in order to avoid problems in the future and of course to understand the project fully.
We are currently debugging a C167 project that has been developed 10 years ago
Sounds familiar :-)
We found out that there is some misconfiguration in the memory map, the NCONST class is located to the XRAM memory address range. NCONST( 0x00E000-0x00E3FF)
With XRAM you mean the on-chip XRAM I pressume.
C_LIB_NCONST seems to contain some constants used by the C167 library I guess.
Why can't the system use those 30 bytes? Depending on your linker file/memory map and matching startup.a66 (containing the BUSCON's/ADDRSEL's), it might be reading flash or RAM at that location. You can disable the on-chip XRAM from the startup.a66 file; check _XRAMEN. As far as I know, this memory region can then be used by any other BUSCON/ADDRSEL or fall back to BUSON0 (=chip select).
But then again, I don't know the exact setup of your system :-)
-- Joost
Hoi Joost,
the _XRAMEN is set to 1. That means it is enabled.
If the keil compiler would generate a LST-File for the C-Library, too, it would be easy to understand whats behind those constants. But since we need a dongle to run the compiler, the output won't be that verbose, I guess.
clemens
I see your problem now. If it's "const" the memory area won't contain anything if it's XRAM... It doesn't get initialized using the INIT section or anything.
Does the application copy itself to RAM?
Does it perhaps modify the BUSCON/ADDRSEL registers or XRAMEN bit on the fly?
When you're debugging the device, it means there's a problem. Does the problem occur when you modify the XRAMEN bit and put flash ROM in that memory area?
Perhaps Keil support can give you more insight into the constants. Will you be able to modify the devices in the field to fix this?
-- J
To all questions the answer is: no
No copying to ram, no modifying registers on the fly and, most important, no problems - yet. The application is running smoothly since years. You'd say, 'so what, don't care!', but it is used in a safety critical device and we need to make sure that it will work properly in the future, too. If the answer is: those constants are not only used in cases we do not have, then we're fine. Otherwise we need to fix the problem and that's going to be costly.
If the answer is: those constants are not only used in cases we do not have, then we're fine.
Only Keil can answer that... Or perhaps my using some smart emulator debugging to check if the memory area gets accessed and if so by which function. But even then, when the software (or Keil tools) ever gets updated - and they will - and the "consts" are still missing, things can still go wrong.
My suggestion is to disable the on-chip XRAM and put flash ROM in the area, or move the NCONST area to be in flash ROM space. That's the only way to make sure you won't run into problems (regarding this issue).
Good luck!