topic Re: EETS2K eeprom hardeware interlock in S12 / MagniV Microcontrollers

EETS2K eeprom hardeware interlock

lx — Fri, 10 Aug 2012 11:34:49 GMT

Hi,

Can anyone elaborate more info on eeprom hardware interlock. When testing a batch of boards with MC9S12DJ128 using the same firmware, I encounted the following problem: after power reset, bit EPOPEN and EPDIS of EPROT was set to zero on some boards and cannot be initialized to 1, while others have such issue.

thanks

Re: EETS2K eeprom hardeware interlock

kef — Fri, 10 Aug 2012 13:30:06 GMT

You can't disengage EEPROM write protection in normal operating mode. Most likely EPROT initialization byte at the end of EEPROM array (at offset 0x7FD) is programmed. You need to boot into special mode using BDM debugger, set EPROT to FF annd erase EEPROM byte at offset 0x7FD.

Re: EETS2K eeprom hardeware interlock

lx — Sat, 11 Aug 2012 01:42:48 GMT

Thanks for your reply.

I have checked the problem boards. Somehow the eeprom space 0x07FC - 0x7FF got corrupted (one board was 0x10 0x00 0x00 0x00, the other one was 0x10 0x00 0x10 0x00). when I tried to reset these location to 0xFF through BDM debugger, I was unable to do it. EPROT can be reset through BDM.

Any clue on it?

Re: EETS2K eeprom hardeware interlock

kef — Sat, 11 Aug 2012 02:39:34 GMT

Are you sure you are reading EEPROM? 0x7fd relative to the start of EEPROM array, and start of EEPROM array depends on INITEE.

Re: EETS2K eeprom hardeware interlock

lx — Sat, 11 Aug 2012 03:26:32 GMT

the INITEE is 0x01

Re: EETS2K eeprom hardeware interlock

kef — Sat, 11 Aug 2012 03:37:51 GMT

anyway mass erase, performed by debugger should cure it, unless you have some different MCU remarked as S12DJ128

Re: EETS2K eeprom hardeware interlock

lx — Sat, 11 Aug 2012 05:02:22 GMT

mass erase did the job. thanks.

My question is why these bytes got corrupted? Is there any hardware condition may cause this issue? We have to find the root cause as a few boards were corrupted in a week. Thanks.

Re: EETS2K eeprom hardeware interlock

kef — Sat, 11 Aug 2012 14:10:03 GMT

Most likely your firmware did it. You may also check how reliable is your external brown own detector circuit on /RESET pin, low voltage detector. As you know this is required for S12D family. Without it bad things may happen when supply voltage falls down slowly.

You can reliably prevent writes to 0x?7FD, setting up 0x?7FD to 0xF0 immediately after flashing your code, so

that 0x?7C0 to 0x?7FF are write protected.