I am seeing something strange on a KE18F512 with KDS 3.2. It seems to be a linkage problem, but it shows up under debug.
We use an external SPI EEPROM to store data. We've done this on KE06 and KE18F successfully. I modified the linker directive to map the EEPROM section to a "fake" memory region, and in the post-build steps, I use objcopy to separate the EEPROM section into a separate S-record:
${cross_prefix}objcopy -O srec -R.nvsec c3main.elf c3main.srec&${cross_prefix}objcopy -O srec -j.nvsec --change-section-address .nvsec=0x0 c3main.elf c3eeprom.srec
We have the means to program the EEPROM with initial data in-circuit, and the debugger is aware of the "fake" addresses, but correctly identifies what is there. I have my own routines for reading and writing the EEPROM.
Now we've added a second SPI EEPROM, but things are going tragically wrong. I've added to the post build-steps:
${cross_prefix}objcopy -O srec -R.nvsec -R.nvsec2 c3main.elf c3main.srec&${cross_prefix}objcopy -O srec -j.nvsec --change-section-address .nvsec=0x0 c3main.elf c3eeprom.srec&${cross_prefix}objcopy -O srec -j.nvsec2 --change-section-address .nvsec2=0x0 c3main.elf c3eeprom2.srec
Everything is fine, until I actually put something into the second EEPROM, then the debugger can't stop at the beginning breakpoint, and it jumps into strange sections of code. I can't stop it, I just have to kill the process. It doesn't even make it to where it reads or writes the EEPROMs, it just won't boot at all. The linker directive has this:
/* Specify the memory areas */
MEMORY
{
m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0007FBF0
m_flex (RW) : ORIGIN = 0x10000000, LENGTH = 0x00010000
m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00008000
m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00008000
eeprom (RW) : ORIGIN = 0x60000000, LENGTH = 0x00040000
eeprom_2 (RW) : ORIGIN = 0x60040000, LENGTH = 0x00040000
}
....
.nvsec :
{
. = ALIGN(4);
KEEP(*(.nvdata))
KEEP(*(.nvstrings))
KEEP(*(.nvptrs))
KEEP(*(.nvfptrs))
. = ALIGN(4);
} > eeprom
.nvsec2 :
{
. = ALIGN(4);
KEEP(*(.nvdata2))
. = ALIGN(4);
} > eeprom_2
It's not a problem of address location; if I move the original EEPROM section up to 0x60040000, it still works fine. It's only when it has data in the second section.
What gives? Do we have too many sections defined? Am I missing something? Once I put things back into the first EEPROM so that nothing is there, everything runs normally.
