Problem Securing HCS12 flash

[Red]

I'm working on a project involving the HCS12 (specifically the MC9S12DP512) and I'm having problems securing/unsecuring the flash memory.

My intention was to secure and unsecure the flash through firmware routines that could be called through one of the SCI ports.

So far, I have been able to write routines that allow me to secure the flash and also unsecure the flash but there's a few issues.  The main one is that, despite setting a backdoor key when securing the device, the flash can be unsecured just by changing the value of $FF0F (ie. without doing any writing to $FF00 - $FF07.)  Note that consecutive lock-unlock operations are done with a reset inbetween.

Another problem is that, if I do try to unsecure the device through the backdoor key method, the MCU seems to hang as soon as I try to set KEYACC in FCNFG.  Note that this only occurs once the device is locked.

Finally, when the device is unlocked, I've noticed that I cannot use bset to set KEYACC and instead have to do a full write to FCNFG.  A bset simply doesn't set KEYACC.

I suspect that the first two issues may be due to me not securing the device correctly.  While the Freescale documentation explains how to unsecure the device there doesn't seem to be any explicit explanation on how to secure it in the first place.  This is the design of the current routine:-

1. FCNFG = 0x20 (KEYACC)
2. Write backdoor keys to $FF00 - $FF07 (written directly, not through flash writing routine)
3. FCNFG = 0
4. Copy vector table into ram
5. Erase Sector starting at $FC00
6. Rewrite vector table into flash (through flash writing routine)
7. Set $FF0F to 0xBC (written as word (0xFFBC) starting at $FF0E through flash writing routine.)

This is the unsecure routine that I'm trying to get to work (but hangs at step 1)

1. FCNFG = 0x20 (KEYACC)
2. Write backdoor keys to $FF00 - $FF07 (written directly, not through flash writing routine)
3. FCNFG = 0
4. Copy vector table into ram
5. Erase Sector starting at $FC00
6. Rewrite vector table into flash (through flash writing routine)
7. Set $FF0F to 0xFE (written as word (0xFFFE) starting at $FF0E through flash writing routine.)

Doing steps 4 to 7 of the unsecure routine currently unsecures the device.

Any idea what could be causing the problems?

[miroslavvaclave]

Hi,

I have another problem with secure of my S12G128 device. If I change configuration field at address 0xFF0F. My new value is 0xFC. After reset FSEC is still 0xFE.

I tried send message after reset with value at address 0xFF0F and second message with FSEC and receive data in my terminal are 0xFC, 0xFE. I tried many resets but result is the same.

Here is my code:

if flasher module:

===============================

.

.

const unsigned char flash_array[] @0xFF08 = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC};

/*

0xFF08-0xFF0B - reserved

0xFF0C - P-Flash Protection byte = 0xFF (default state, protection is disabled)

0xFF0D - D-Flash Protection byte = 0xFF (default state, protection is disabled)

0xFF0E - Flash Nonvolatile byte = 0xFF (default state, watchdog is disabled)

0xFF0F - Flash Security byte = 0xBC (secured)

*/

.

.

in main module:

================================

.

.

#pragma OPTION ADD _CONST_FAR "-CpPPage"   

//================== IMPLEMENTACE VEŘEJNÝCH FUNKCÍ ===========

//=============================================================

// Spusteni hlavni funkce loaderu

// Vstupy:    bez vstupu

// Vystupy: bez vystupu

// Pozn.:

void main(void)

{

    AppExecute_t    *pt_AppRestVector;

    LONG                    u32_ResetApplAddr = ((LONG)APPL_END_ADDR) - 1;

    volatile BYTE *__far pau8_Cfg = (BYTE *__far)0x3FF0F;

    pt_AppRestVector = (AppExecute_t*)((WORD)u32_ResetApplAddr);

    PE_low_level_init();

    V_Sci0_InitPort();

    V_Sci0_PutChar(*pau8_Cfg);

    V_Sci0_PutChar(FSEC);

    if(u8_Main_WaitForFlashMo

.

.

I do not understand why FSEC is 0xFE if this register is loaded during reset from address 0xFF0F and here is 0xFC.

CW: 5.9.0

Programmer: P&E Multilink

Device: S9S12G128F0CLH

Thanks a lot for any idea.

Mirek

[kef]

---

Red wrote:

So far, I have been able to write routines that allow me to secure the flash and also unsecure the flash but there's a few issues.  The main one is that, despite setting a backdoor key when securing the device, the flash can be unsecured just by changing the value of $FF0F (ie. without doing any writing to $FF00 - $FF07.)  Note that consecutive lock-unlock operations are done with a reset inbetween.

---

Of course. If vector area isn't write protected then you can reprogram FF0F as any other byte and just reset. Part will get unsecured. Backdoor is to let you unsecure temporarily without program/erase cycles.

Red wrote:

Another problem is that, if I do try to unsecure the device through the backdoor key method, the MCU seems to hang as soon as I try to set KEYACC in FCNFG.  Note that this only occurs once the device is locked.

Finally, when the device is unlocked, I've noticed that I cannot use bset to set KEYACC and instead have to do a full write to FCNFG.  A bset simply doesn't set KEYACC.

MCU "hangs" if you set KEYACC while running from flash. When KEYACC is set - MCU can't read program in flash. It's the same like with program/erase, flash is not readable while it's being programmed.

I didn't try to BSET KEYACC on unsecured part, but I was able to BSET FCNFG,#0x20 secured D64. Hm, but what for are you setting KEYACC in unsecured parts?

Regards

[Red]

---

kef wrote:

Of course. If vector area isn't write protected then you can reprogram FF0F as any other byte and just reset. Part will get unsecured. Backdoor is to let you unsecure temporarily without program/erase cycles.

Ok, that makes sense.  From the documentation, I was under the impression that the device would somehow prevent the value of FF0F being changed while secured. 

There are statements like 'The contents of the Flash Protection/Options byte at $FF0F in the Flash Protection/Options Field must be changed directly by programming $FF0F when the device is unsecured and the higher address sector is unprotected.'

I did however wonder how there could be any protection against a single byte in flash memory given that it's sector can be erased.

---

MCU "hangs" if you set KEYACC while running from flash. When KEYACC is set - MCU can't read program in flash. It's the same like with program/erase, flash is not readable while it's being programmed.

---

Of course!  I thought I was missing something obvious.  I'll execute that code in RAM.

[kef]

Red wrote:

There are statements like 'The contents of the Flash Protection/Options byte at $FF0F in the Flash Protection/Options Field must be changed directly by programming $FF0F when the device is unsecured and the higher address sector is unprotected.'

I did however wonder how there could be any protection against a single byte in flash memory given that it's sector can be erased.

I'm not sure what the question is, but there are two different things: 1) flash security and 2) flash protection. Security is to make code not readable via BDM. Write Protection is to make memory not writeable/eraseable by firmware running in MCU. There are FSEC and FPROT registers. There are also default values for these registers which get loaded on reset from bytes at FF0F, FF0D, FF0C etc. If you want to unsecure part by reprogramming (from firmware in MCU) security byte at FF0E, then vector area must be not write protected. Backdoor will work even if vector area is write protected provided KEYEN=10.

---

ramabh wrote:
I am not completely depending on the debugger.when i tried to overwrite at FF0F i got that error message and from the reset onwards i am not able to connect to debugger.It means i overwritten the data at FFOF to FC,i thought my rest of the also code resides in memory but nothing is working.

You were uploading your code to target, debugger stopped at FF0F with error and didn't go further, right? If so then vectors wasn't programmed, they should probably come after  FF0F.

---

ramabh wrote:
I am placing the constant data at FF0F not at BF0F.From the datasheet i understand that what ever data placed at FFOF will be replicated at BF0F.

---

Not exactly. FF0F replicates at BF0F only if PPAGE register is set to 3F is 9S12 part or PPAGE=FF if 9S12X.

[ramabh]

HI...Kef

 what u mentioned was absolutely correct:

"You were uploading your code to target, debugger stopped at FF0F with error and didn't go further, right? If so then vectors wasn't programmed, they should probably come after  FF0F"

But why i am getting that error......

whether we cannot overwrite data in flash at thar address

or there is any debugger option to change its default value FE to FF

[imajeff]

ramabh, what error are you still asking about? Here is the summary:

1. Your program cannot run if you have not written the vector @ fffe
2. Your debugger cannot do anything because you have just secured the part. If your part is a good maskset, the debugger will be able to erase the flash in order to unsecure the part.

Also, kef, I don't get this: "Of course. If vector area isn't write protected then you can reprogram FF0F as any other byte and just reset."...
If it is that simple to permanently unsecure without erasing Flash then that seems to nulify a lot of complexity I've seen in the other unsecuring method(s). Mainly I'm thinking of the fact that there is no way to read what the backdoor key is. I thought that was to protect from an intruder reading the key from Flash and then unsecuring to do something further. Oh well, I guess that feature didn't have much advantage anyway.

[kef]

Broken phone game.

Securing from PC through BDM port isn't the same as securing from firmware running in MCU. I think the thread wasn't about the 1st but about the 2nd.

[nerdboy]

I read through this entire thread to try to confirm how to secure the device in firmware and found that the information is kinda scattered about.  For those of you who are trying to do this here's a method that works:

- Write 0xfffc to address 0xff0e (you could probably alternatively do a single byte write to 0xff0f)

You don't need to erase the sector first (so no vector table eraseage) - effectively you're just clearing the SEC bits.  When the two SEC bits are cleared, the device is secured. 

Of course, it's not as simple as a single instruction - the code that writes flash will have to be in RAM or somewhere else outside of flash.  There are examples of flash programming routines in application notes and on this forum. 

[Red]

---

kef wrote:

I'm not sure what the question is

---

There wasn't actually a question.  I was just explaining that I had originally thought that the MCU somehow prevented the value of $FF0F being changed while secured and also how I'd had some doubt over how it would do it.  I guess using the word 'protected' in my previous post brought confusion given that there are both protection and security functions in the MCU.

I'm clear on how it works now, thanks for your help. 

The set up seems a little odd to me (having authentication built into the hardware for doing a temporary unsecure but still allowing a permanent unsecure by simply erasing/rewriting $FF0F and reseting) but I guess that's just due to the context of my application.

[ramabh]

Hi Red

---

kef wrote:

Of course. If vector area isn't write protected then you can reprogram FF0F as any other byte and just reset. Part will get unsecured. Backdoor is to let you unsecure temporarily without program/erase cycles.

what kef mentioned is absolutely right.

I just want to clear one thing...

FFOF comes under unpaged memory and Flash block 0,so when u want to overwrite data at FF0F u have to use flash routines that are located in flash block 1 or eeprom or ram or stack..

[ramabh]

Hi kef..

with ur reply it sounds that u r familiar with flash secure and unsecure.so i just want to know more about this....

I am working on HCS12 ..and by default when i look at the memory location FF0F it is FE(Unsecured state)and to secure MCU i erased the sector and then at FFOF i changed to FC..its working fine..but the problem is i donot want to erase my vectortable and i just want to load the contents at FFOF to FC while programming only so that from the reset onwards the MCU will be secured.

inorder to acheive this i defined like this in a ".c " file named as security.c

typedef struct
{
const UINT16 key1;
const UINT16 key2;
const UINT16 key3;
const UINT16 key4;
const UINT16 res1;
const UINT16 prot1;
const UINT16 prot0;
const UINT16 security;
}tFlashProt;

extern const tFlashProt FlashProtection =
{
0xFFFF, /* key1 */
0x1234, /* key2 */
0xFFFF, /* key3 */
0xFFFF, /* key4 */
0xFFFF, /* res1 */
0xFFFF,

0xFFFF, /* block  protection */
0xFFFc, /*security */
};

and in linker file i placed it as

+seg .const -b 0xFFF00 -o 0xFF00 

C:\IMU\FLASH\\security.o

With this when i am loading the program the compiler gives a error "Error while programming flash in area 3FBF0E"

and afterwards when i look at that locations at FF02 the data is 12 and at FFOF its FC and next time to program the MCu i have to unsecure the device.

I thought it is behaving as expected with that error only i tried to run the program....it is behaving as if there is no data in flash.

If u have any idea please guide me. 

[kef]

ramabh,

---

ramabh wrote:

With this when i am loading the program the compiler gives a error "Error while programming flash in area 3FBF0E"

and afterwards when i look at that locations at FF02 the data is 12 and at FFOF its FC and next time to program the MCu i have to unsecure the device.

---

It's not the compiler who gives you "Error while programming flash in area 3FBF0E". It's your flash burner. How do you "when I look at locations.."? Your debugger can show you not the MCU's memory but what debugger cached from your program image. So be careful with conclusions. "Error while programming" could mean a) that programming didn't verify or b) that burner did reset the part and can't read anything because part got secured. c) IIRC NoICE debugger when programming substitutes the least FF0F bits with 10. You can try to program FF0F to xxxxxx01, but NoICE will program it as you specified xxxxxx10...

---

ramabh wrote:

I thought it is behaving as expected with that error only i tried to run the program....it is behaving as if there is no data in flash.

---

When part is secured it may look through BDM debugger window as if your part doesn't have flash memory or if it got damaged. I suggest you to not trust your debugger 100% when you are debugging you flash program/erase/backdoor unsecure code.

[ramabh]

hi kef

I am not completely depending on the debugger.when i tried to overwrite at FF0F i got that error message and from the reset onwards i am not able to connect to debugger.It means i overwritten the data at FFOF to FC,i thought my rest of the also code resides in memory but nothing is working.

I am placing the constant data at FF0F not at BF0F.From the datasheet i understand that what ever data placed at FFOF will be replicated at BF0F.

how to avoid that error..is there any way to set FC at FFOF without errasing vector table.

[ramabh]

Hi....

I am also facing the same type of problem.

But as far as i know i can say one thing...to secure the device we just have to write FC at location FFOF and to unsecure the device there is a software from P&E.u can just go through their site and download that unsecure software.

and for the backdoor access you have to change the bits in FSEC also which u didnot mentioned .u have to set the backdoor key acess enable other than KEYACC. It is not necessary to unsecure the device only through backdoor key access.if u are able to change the location(FF0F) to FE then the device will be unsecured.Bit i donot know how ur changing this.

whether it is not possible to change the data at FFOF with out moving the vector table to ram and then to flash...

what i tried is just defined a constant variable at that address.

[Red]

Thanks for the reply ramabh.

I had originally set the KEYEN bits in FF0F (which gets copied to FSEC on reset) although I seem to have forgetten about that when I started troubleshooting.  On first looks, setting the KEYEN bits correctly doesn't seem to be helping but I'll spend a bit of time trying it.

With regards to not needing the backdoor key access, the reason I want to be able to unsecure the device through this method is because this method doesn't erase the flash.  In contrast, as far as I know any other option (eg. using P&E unsecure) involves erasing the flash.  There could be situations when it would be beneficial for us to be able access the device through BDM after it has been secured while keeping the flash data intact.

[Lundin]

I don't know much about the security in the S12 but I do know that there is an errata for earlier masks ("B" ) that will prevent you from changing contents in flash/eeprom when the device is secured. Perhaps you are using one of the early masks?