P128, flash securnig

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

P128, flash securnig

Jump to solution
4,167 Views
cs_Lukasz
Contributor III

Hello!

 

My project is finished :smileyhappy: and the last thing i will have to do is flash securing. So,  project contains bootloader at last page (0xC400...0xFEFF) and main program. That works fine. Next I have to secure flash from unauthorised access. In bootloader I wrote:

 

volatile const tU16 FlashSecurity @ 0xFF0E = 0xFFBC;  // backdoor enabled, flash secured

 

Now, when user wants to chang a FW, i must unsecure flash. Backdoor keys I wrote also in bootloader:

 

volatile const tU16 BKD_KEY0 @ 0xFF00 = BOOKDOOR_ACCESS_KEY0;
volatile const tU16 BKD_KEY1 @ 0xFF02 = BOOKDOOR_ACCESS_KEY1;
volatile const tU16 BKD_KEY2 @ 0xFF04 = BOOKDOOR_ACCESS_KEY2;
volatile const tU16 BKD_KEY3 @ 0xFF06 = BOOKDOOR_ACCESS_KEY3;

 

I was looked on AN3275(S12 All-Access Bootloader for the HCS12 Microcontroller Family) and there flash is uncesured in this way:

 

<code>

void near UseBackdoor(uint8 cmd)
{
  FlashSectorBackup();
  InterruptVectorBackup();
  if (!(FSEC & 0x02))                                    /* If Secured */
  {
    vfnSCITxMsg(gi8aMCUSecuredMsg);         /* Asks for current BackdoorKey */
    EnterKeys();
    vfnSCITxMsg(gi8aUnSecuringMsg);         /* Display message */
    Unsecure();
    //(void)RunFunctionInRAM(&Unsecure);      /* Call restoreKeys procedure to unsecure the MCU */
    if ((FSEC & 0x03) == 0x02)
    {
      vfnSCITxMsg(gi8aUnSecuredMsg);        /* Display message if unsecure succesful */
    }
    else
    {
      vfnSCITxMsg(gi8aCantUnsecureMsg);     /* Display message if unsecure failed */
      return;
    }
  }
  if((uint8)cmd==ChangeKeys)
  {
    EnterKeys();
  }
  KeysNSec[7] = cmd;
  FlashSectorRestore();
  InterruptVectorRestore();   
  vfnSCITxMsg(gi8aNewSecurityAppliedMsg);   /* Display messages */
}

</code>

 

And now I have problem. When I do this in the same way it dont works. If I set at the begin  FSEC to 0xBC , program read 0xFF from this register (I sent this value by SCI), but if I set this register to 0xBE program read it right. I dont know whats wrong.

 

And other question. Text form documentation to family P128:

"Access Key command match the backdoor keys stored in the Flash memory, the SEC bits in the FSEC
register (see Table 13-10) will be changed to unsecure the MCU. Key values of 0x0000 and 0xFFFF are
not permitted as backdoor keys. While the Verify Backdoor Access Key command is active, P-Flash
memory and D-Flash memory will not be available for read access and will return invalid data."

So, when Backdoor Key unlock flash securiy, it will be possible to  read a flash data for example by BDM? In other way, while the user dont finish sending of new FW the flash will be unsecured but will it be readable from extern?

 

Sorry for my english :smileyhappy:

Best regards

Lukasz

Labels (1)
0 Kudos
Reply
1 Solution
1,604 Views
cs_Lukasz
Contributor III

Solution from support:

 

Burner performs following steps when programming the MCU:
1. Whole flash is erased.
2. FSEC is programmed to unsecured state 0xFE.
3. New code is loaded into flash.

Step 2 is the problem. If your code contains data that are loaded to
phrase 0xFF08-0xFF0F then ECC error will occur (checksum is corrupted).
Why? Because this phrase has not been erased (FSEC is set to 0xFE) and
cumulative programming is not allowed.

The MCU will be secured and flash will be PROTECTED (this is the problem
you met) during the reset sequence if ECC error is found out in phrase
0xFF08-0xFF0F.

You can read in datasheet:

"If a double bit fault is detected while reading the P-Flash phrase
containing the P-Flash protection byte during the reset sequence, the
FPOPEN bit will be cleared and remaining bits in the FPROT register will
be set to leave the P-Flash memory fully protected."

"If a double bit fault is detected while reading the P-Flash phrase
containing the Flash security byte during the reset sequence, all bits
in the FSEC register will be set to leave the Flash module in a secured
state with backdoor key access disabled."


Solution:
You have to add following command to "preload" command file
(P&E_Multilink_CyclonePro_Preload.cmd if you use PE Multilink):

FLASH NOUNSECURE

This command will turn off the step 2. It will ensure that the burner
will not change security byte to unsecured state prior to programming.

 

View solution in original post

0 Kudos
Reply
8 Replies
1,604 Views
kef
Specialist I

Now, when user wants to chang a FW, i must unsecure flash. Backdoor keys I wrote also

No. Flash must be unsecured only in case you need to debug your firmware. Backdoor access allows to unsecure MCU and hotplug-debug existing firmware. In the past there was some buggy S12DP256 maskset that inhibited flash writes while secured. I don't think S12P has the same issue.

 

Backdoor unsecure works different on classic S12 parts and on S12P. S12P doesn't have KEYACC bit in FCNFG register. Instead S12P has dedicated backdoor unsecure command.

 

So, when Backdoor Key unlock flash securiy, it will be possible to  read a flash data for example by BDM? In other way, while the user dont finish sending of new FW the flash will be unsecured but will it be readable from extern?

Right. You shouldn't unsecure you MCU for update. Also you shouldn't unsecure MCU rereflashing FPROT reset value @ 0xFF0F, along with whole vectors table. It is absolutely not secure.

0 Kudos
Reply
1,604 Views
cs_Lukasz
Contributor III

Thx for reply. 

 


. Flash must be unsecured only in case you need to debug your firmware. Backdoor access allows to unsecure MCU and hotplug-debug existing firmware. In the past there was some buggy S12DP256 maskset that inhibited flash writes while secured. I don't think S12P has the same issue.

Right. You shouldn't unsecure you MCU for update. Also you shouldn't unsecure MCU rereflashing FPROT reset value @ 0xFF0F, along with whole vectors table. It is absolutely not secure.


 

 

 

I thougt that same.  But there is a problem and I dont know where. As I wrote, in bootloader i add a line:

volatile const tU16 FlashSecurity @ 0xFF0E = 0xFFBC;  // backdoor enabled, flash secured

or only:

volatile const tU16 FlashSecurity @ 0xFF0E = 0xFFFC;  // backdoor disabled, flash secured 

 

This bootloader don't works corretly. Transmission with PC is ok, it is receiving frames with FW correctly, but new FW don't starts. At the end of updating bootloader checks a CRC of program flash and it is always bad. So when I set flash security it is looking like that flash is also write protected !? 

 

In other case, when I don't set flash security bootloader and FW works good. FSET register is only one thing which differ. CRC of program flash is good and new program starts. 

 

So, what do You think? Where the bug can be? 

0 Kudos
Reply
1,604 Views
kef
Specialist I

Is bootloader working on unsecured MCU also while powered with BDM not connected? I didn't try S12P yet, but maybe it failt due operating mode differences? Some S12P flash commands are not available in special modes and some in notmal modes. I don't know.

0 Kudos
Reply
1,604 Views
cs_Lukasz
Contributor III

Thx for reply. It was very helpfull. Just now i have been reading about two modes of operation: normal and special (depending on MODC pin). I am using two flash commands: Program P-Flash and erase P-Flash sector. They are avainable in all modes except secured special single (special for BDM operation). So i have to set secured normal operation. MODC is connected by pullup resistor to VCC, so after rising edge of reset pin procesoor should be in normal mode (BDM unconnected). Unfortunatelly probably isnt in this mode, i dont now why yet but I will know soon :smileyhappy:

0 Kudos
Reply
1,604 Views
cs_Lukasz
Contributor III

I maked next experiment. I check is processor in normal mode (MODE & MODE_MODC_MASK), and mode is '1' after BDM disconection and reset. In MC9S12P128 Reference Manual is written that the program P-Flash and erase sectors are enabled for secured normal mode, limitations are only for secured special mode (only mass erase is enabled). But I think sth dont works in this feature. After bootloader upload when 912S is in secured normal mode I am sending by SCI programmed pages of flash and I am receiving only 0xFF. It looks program P-Flash dont works in this mode. For addition I sended last page on which bootloader is, and this page looks correctly.

 

I completly dont know what can be wrong. Maybe in manual is bug, and P-family dont support P-Flash programming in secured mode?

0 Kudos
Reply
1,604 Views
J2MEJediMaster
Specialist I
I think you have reached a point where you need to file a service request. Click here to file a service request.
0 Kudos
Reply
1,605 Views
cs_Lukasz
Contributor III

Solution from support:

 

Burner performs following steps when programming the MCU:
1. Whole flash is erased.
2. FSEC is programmed to unsecured state 0xFE.
3. New code is loaded into flash.

Step 2 is the problem. If your code contains data that are loaded to
phrase 0xFF08-0xFF0F then ECC error will occur (checksum is corrupted).
Why? Because this phrase has not been erased (FSEC is set to 0xFE) and
cumulative programming is not allowed.

The MCU will be secured and flash will be PROTECTED (this is the problem
you met) during the reset sequence if ECC error is found out in phrase
0xFF08-0xFF0F.

You can read in datasheet:

"If a double bit fault is detected while reading the P-Flash phrase
containing the P-Flash protection byte during the reset sequence, the
FPOPEN bit will be cleared and remaining bits in the FPROT register will
be set to leave the P-Flash memory fully protected."

"If a double bit fault is detected while reading the P-Flash phrase
containing the Flash security byte during the reset sequence, all bits
in the FSEC register will be set to leave the Flash module in a secured
state with backdoor key access disabled."


Solution:
You have to add following command to "preload" command file
(P&E_Multilink_CyclonePro_Preload.cmd if you use PE Multilink):

FLASH NOUNSECURE

This command will turn off the step 2. It will ensure that the burner
will not change security byte to unsecured state prior to programming.

 

0 Kudos
Reply
1,604 Views
kef
Specialist I

Just got the same problem setting NVPROT byte on S12XE. Flashing didn't succeed and MCU was secured every time I tried. Solution is the same

 

You have to add following command to "preload" command file (P&E_Multilink_CyclonePro_Preload.cmd if you use PE Multilink):

FLASH NOUNSECURE

0 Kudos
Reply