Hello!
My project is finished 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?
Best regards
Lukasz
已解决! 转到解答。
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.
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.
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?
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.
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 .
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?
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.
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