wrong value loaded

[rlw]

Please see the attached screen picture.

When the GLDD instruction was executed, the wrong value, 0x0008, was loaded. The expected value is 0x001d. Any idea why this might happen?

I executed this code one instruction at a time using assembly step.

[kef]

Is it simulator or real hardware? If real, then 1) it may be wrong flash/EEPROM/DFLASH clock divider setting, leading to incomplete programming of bits, which may cause random reads. 2) debugger may be caching contents of NV memory. You programmed one value and CPU reads it properly, but debugger is still showing old contents of NV memory. Try going to Multilink -> Debug Memory Map menu and checking "refresh when halting" chceckbox for particular flash/EEPROM/DFLASH memory.

[rlw]

Real hardware. I have confirmed flash clock setting conforms with AN3743:

//Uncomment the FCLK_DIV value according to the oscillator crystal.
//These values are chosen from the MC9S12XE100 datasheet.
//#define FCLK_DIV 0x1 // Flash clock divider for 2MHz crystal
#define FCLK_DIV 0x3 // Flash clock divider for 4MHz crystal
//#define FCLK_DIV 0x7 // Flash clock divider for 8MHz crystal
//#define FCLK_DIV 0x9 // Flash clock divider for 10MHz crystal
//#define FCLK_DIV 0x18 // Flash clock divider for 26MHz crystal

We are using an 8MHz crystal, so are using 0x7 as the value. (And commenting out the line for 4MHz crystal)

Also, I have confirmed that the "refresh when halting" checkbox is checked.

[kef]

Is it one time failure, or indeed it is always the same?

Since it seems you are using S12XE, which has emulated EEPROM, where writes to EEE buffer RAM are immediately granted instead of certain EEPROM programming sequence, then what if some interrupt writes to EEPROM by mistake or intentionally? Please make sure that no interrupt happened after GLDD but before debugger reads from EEPROM.

What if it's debugger's bug? Try checking if data at logical 0x0B20'L is the same. I would also try to make two copies in RAM of the same data using CPU. One copy using non-G instructions from EEPROM page, and another copy using G-instructions. Compating copies with what debugger reads directly from EEPROM should tell something

[rlw]

It is consistant, though the data values vary (as expected).

Currently, we are treating this as a debugger issue and are using alternative means to debug (sending bytes out a spare SPI port. Not optimal, since it requires modifying the code)

Will follow up as we are able to fit in your suggested experiments.