9S12B64 read EEPROM variables issue

[Zeke]

Hi all,

We have product that use 9S12B64 chip. We test EEPROM to read variables over and over again. Our procedure is
a) open power
b) read EEPROM variable (that is already existed)
c) check variable value (equal or unequal)
d) use I/O to output the result
e) power down
f) go to a)

It gets different result, when testing 4 ~ 15 times. Then we use 9S12D64 to replace B64. That issue never happened again. We try more EEPROM variables and copy them to FLASH. We get 0xFF value all of them when check fault. But we read EEPROM via P&E BDM tool that same as we programming it early with S19 file. Anyone has idea or anybody use B64 chip before?

Operation Environment:

Crystal : 4 Mhz
Oscillator circuit : Pierce circuit
Compiler : Cosmic

EEPROM address:
B64 : 400h ~ 7FFh
D64 : C00h ~ FFFh

Simple test code:

@eeprom U8 EETEST = 0x78; // At EEPROM start address 0x400 for B64, 0xC00 for D64

void Boot(void)
{
U8 *p1;
U8 test;

PLLCTL |= mskSCME;

SYNR = 5; /* PLLCLK = 48M Hz */

while (!(CRGFLG & mskLOCK));

CLKSEL |= mskPLLSEL;
COPCTL = mskCR0 + mskCR1 + mskRSBCK; /* CR[2:0] = 011 */

INITRG = 0x00;
INITRM = 0x39;
nop();

INITEE = 0x09;
nop();

FCLKDIV = mskFDIV2 + mskFDIV4;
ECLKDIV = mskEDIV2 + mskEDIV4;

DDRA = 0xFF;
nop();
nop();

PORTA = 0x00;

p1= (U8*)0x400; //0x400 for B64,0xC00 for D64

test = *p1;

if ( test == 0x78)
PORTA= 0x02; // OK
else
PORTA= 0x01; // wrong value

if( EETEST == 0x78)
PORTA |= 0x08; // OK
else
PORTA |= 0x04; // wrong value

while(1)
{
ARMCOP = 0x55;
ARMCOP = 0xAA;
}

} /*** END of Boot ***/

If checking fault, it will show PARTA = 0x01 + 0x04.

[kef]

INITEE = 0x09;

With this setting B64 and D64 EEPROM is mapped to 0x800-0xFFF. No wonder you can't verify your EEPROM at 0x400.

[Zeke]

---

kef wrote:

INITEE = 0x09;

With this setting B64 and D64 EEPROM is mapped to 0x800-0xFFF. No wonder you can't verify your EEPROM at 0x400.

---

Dear kef,

I try 0x800-0xBFF and 0xC00-0xFFF with INITEE=0x09 setting. It can't write value to EEPROM. So I post "About MC9S12B64 EEPROM Start address" on Freescale Forums. And I get a answer from Lundin. It can read and write at the address 0x400-0x7FF. But this time, I find that the return value will different when I power on/off B64 serial times. So I have no idea what is happen.

I get a answer as same as you from Freescale Technical Support. Mr. Lukas suggest INITEE should be 0x01. I set INITEE to 0x01 and try it again. The issue still exists.


Thank for your reply.

Zeke

[kef]

Dear Zeke,

Dear kef,

I try 0x800-0xBFF and 0xC00-0xFFF with INITEE=0x09 setting. It can't write value to EEPROM. So I post "About MC9S12B64 EEPROM Start address" on

Freescale Forums. And I get a answer from Lundin. It can read and write at the address 0x400-0x7FF. But this time, I find that the return value will different when I power on/off B64 serial times. So I have no idea what is happen.

Your code you post here previously doesn't write to EEPROM at runtime. So I'm not sure what's behind "It can't write value to EEPROM". Looking at your code I see that you are trying to read and verify notexisting locations (RAM and EEPROM is remapped from 0x400). That should explain why you can't read what you expect from 0x400. And now you are asking why doesn't it write. OK, the only line in you code that could write is this:

@eeprom U8 EETEST = 0x78; // At EEPROM start address 0x400 for B64, 0xC00 for D64

Looks like Cosmic? I have no experience with Cosmic, but I guess that this line just defines EETEST variable and initializes it in S-records (or other ROM image file). Flash/eeprom burner like ZAP, PROG12z or others are expected to burn this EETEST to EEPROM. Right? Burner should be aware what are your default INITEE settings. Also in parts like D64 or B64 after reset EEPROM is not visible, it's hidden by RAM. So burner should also know how and where to remap RAM to make EEPROM visible and programmable. Also does your burner support EEPROM programming at all?

Anyway I don't see the whole picture but I believe that it's not buggy B64 chip.

Regards

[Zeke]

Dear kef,

Yes, I use cosmic complier. I am sorry that I don't make sure what you mean.

I declared a pointer using the @eeprom type qualifier. And the cosmic compiler will call eeprom library automatically when I want the pointer to store a value.
Example:

@eeprom U8 *ptr;  /* U8 = unsigned char */


ptr = 0x400;

*ptr = 0x01;  /* cosmic compiler will call function that can write on byte to eeprom in eeprom library */

By this way, I can write one byte to eeprom. So I try 0x400-0x7FF, 0x800-0xBFF, and 0xC00-0xFFF to write several bytes(eeprom segment declared to 0x400-0x7FF, 0x800-0xBFF, and 0xC00-0xFFF at link file). Only 0x400-0x7FF can be written values to eeprom.

I use filler 0x00 to fill eeprom in the another test.

+seg .eeprom -b0x400 -m0x300 -f0x00 -n.EEPROM

And I add a process to copy data from eeprom to flash (512 bytes,0x400-0x5FF). If the return value from eeprom  unequals 0x00 (PORTA = 0x01), I use P&E multilink to show flash data that all of them are 0xFF. If return vale is 0x00, the data of flash are 0x00.

B64 is compatible to D64. But  D64  does  not  has  eeprom  issue. It could be cosmic compiler or link issue. Could someone provide the S19 or take our code to test with other compiler for our B64 eeprom testing?

Best regards,
Zeke