AnsweredAssumed Answered

Strange KDS/KE18F behavior

Question asked by David Sherman on Oct 13, 2016
Latest reply on Oct 13, 2016 by David Sherman

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.

Outcomes