Strange KDS/KE18F behavior

davidsherman — Thu, 13 Oct 2016 18:56:39 GMT

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.

Re: Strange KDS/KE18F behavior

davidsherman — Thu, 13 Oct 2016 20:20:18 GMT

I think I figured it out, it seems we've been lucky so far with the one part, apparently the debugger was attempting to initialize the EEPROM sections. I know from experience that it will bus fault if you try to read or write these fake regions, but apparently we got away with it having the one part.

I made an identical build configuration for debug only that uses a modified linker directive which has the NOLOAD option defined for those regions. Build the release configuration to generate the EEPROM S-records, then build the debug image without them.

topic Strange KDS/KE18F behavior in Kinetis Design Studio

Strange KDS/KE18F behavior

Re: Strange KDS/KE18F behavior