Hi,
there is no information about MCU you use.
I use S12XE and CodeWarrior Classic for description, I used a few days ago for another issue when the ctm was not able to secure the MCU. Your issue is opposite but you should check described things whether you do not perform them:
Addresses presented in the Table 21-4. Flash Configuration Field are your problem.
Flash protection and security oriented addresses are:
0x3_FF00-0x3_FF07 – Backdoor key if security enabled and backdoor key access enabled. See chapter 26.4.6.11 Verify Backdoor Access Key Command
FF0C – P-Flash protection byte – the description of the bits can be found in the chapter 26.3.2.9 P-Flash Protection Register (FPROT)
FF0E – Flash Nonvolatile byte.
The byte is loaded to FOPT register where, see table 1-29 and 1-30, bit 3,2,1,0 sets COP during
reset is required.
Bits 2:0 set CR[2:0] in the CPMUCOP register.
Bit 3 sets WCOP in the CPMUCOP register.
FF0F – P-Flash security byte – the description of the bits can be found in the chapter 26.3.2.2 Flash Security Register (FSEC)
These bytes are copied during reset automatically to corresponding flash protection and security registers FPROT and FSEC
If you do not want to use security then you should program the field in following way:
0x3_FF00-0x3_FF07 doesn’t care
FF0C – value 0xFF if protection of the flash is not required. If you want to protect the flash agains unexpected write
then program required value to the byte.
FF0E - if you want to enable COP during reset then program required value.
Otherwise FF must be written into the byte.
FF0F – if security is not required then the last two bits has to be programmed into the status 10.
Some notes to security:
0.18u technology S12(X) microcontrollers have a security feature. We have to set the flash security byte at address 0xFF0F (global address 0x3F_FF0F) to certain value to enable the security.
The default state of the flash security byte when the MCU is unsecured (we can use BDM device) is 0xFE.
The secured state is 0xFD.
The secured state when the backdoor key is enabled is 0xBD. (see the description of FSEC register for more details)
During the reset sequence, the flash security byte is loaded to FSEC register. On the basis of value stored in this flash security byte is made a decision if the chip is secured or not.
If the chip is secured then BDM commands are limited. We can only access the registers to be able to erase the chip. It is not possible to read the flash or ram and we can’t debug the code. (we can temporarily unsecure the chip using backdoor key – if enabled - to be able to debug the code. This functionality must be implemented in our code.)
If the chip is unsecured (flash security byte is 0xFE) then we can use BDM with no restriction.
How to enable the security:
We can set the flash security byte and backdoor key in this way in CodeWarrior (backdoor key is enabled and set to 0xAA…):
const unsigned char flash_array[] @0xFF00 = {0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xBD};
Or we can simply set only the flash security byte with the backdoor key disabled:
const unsigned char flash_fsec @0xFF0F = 0xFD;
Notice that we have to add following command to “preload” command file (P&E_Multilink_CyclonePro_Preload.cmd if you use PE Multilink):
FLASH NOUNSECURE
(So check the file whether the command is/is not inside it on dependence whether you want/do not want to be device secured after download)
Here is the explanation why we have to use this command:
Burner performs following steps when programming the MCU:
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 already set to 0xFE) and cumulative programming is not allowed.
The MCU will be secured and flash will be protected 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.”
FLASH NOUNSECURE command will turn off the step 2. It will ensure that the burner will not change security byte to unsecured state prior to programming.
Best regards,
Ladislav
HI
First,thanks for your answer. But when I add 'const unsigned char flash_array[] @0xFF08 = {0xFF,0xFF,0xFF,0xFF,0xCF,0xFF,0xFF,0xFE};' in my code , I can not download program successfully by USBDM. 0xFF0F = 0xFE,flash is unsecure, USBDM should be work,but now it can not debug. It make me confused.
Hi, I am sorry for delay.
now, it looks like you made a changes which secured your MCU. I am not able to check all your changes and what you do.
Is there a possibility to share your project package with me?
If your project is confidential, please insert a CASE into our support system and just introduce it with "Hello Ladislav" plus correctly fill necessary cells. It will find me. (follow following steps> https://community.nxp.com/docs/DOC-329745 )
Best regards,
Ladislav