EETS2K eeprom hardeware interlock

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

EETS2K eeprom hardeware interlock

Jump to solution
2,194 Views
lx
Contributor I

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

Labels (1)
0 Kudos
Reply
1 Solution
1,921 Views
kef
Specialist I

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.

View solution in original post

0 Kudos
Reply
7 Replies
1,921 Views
kef
Specialist I

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.

0 Kudos
Reply
1,921 Views
lx
Contributor I

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?

0 Kudos
Reply
1,921 Views
kef
Specialist I

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

0 Kudos
Reply
1,921 Views
lx
Contributor I

the INITEE is 0x01

0 Kudos
Reply
1,921 Views
kef
Specialist I

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

0 Kudos
Reply
1,921 Views
lx
Contributor I

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. 

0 Kudos
Reply
1,922 Views
kef
Specialist I

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.

0 Kudos
Reply