Bootloader and flash read protection

[barbercolman]

I am confused about protecting flash from being read. I have the bootloader from AN4379 up and working. I want to protect the flash from reading and I still need to use the backdoor key to verify the part was correctly programmed at the factory. I think I need to do the following

1. In the bootloader file Boot_loader_task.c

       Set the KEYEN and SEC bits using NVOPT_INIT.

       Set the NVBACKKEY to my key.

2. At this point I an not sure what I have to do. When the bootloader runs does it need to enter the key to be able load the application. Can I include the key the application? Is this the correct approach?

[kef]

I'm not sure what part you are talking about, but S12, S08 and MCF51 operate almost identically.

• I want to protect the flash from reading and I still need to use the backdoor key to
• verify the part was correctly programmed at the factory.

Backdoor access is not required to verify flash programming at factory. MCU becomes secured and not readable over BDM only after reset. So you flash your code and verify it as many times as you wish without any problems. Just don't reset or cycle power between flashing and verify.

To enable backdoor access, you need to program KEYEN bits to 10 in NVOPT and fill NVBACKKEY bytes with your key.

To backdoor unsecure you need to execute routine in RAM, which would set KEYACC bit, write key to compare to NVBACKKEY  locations, and clear KEYACC bit. This should be done from function in RAM, since flash is not readable while KEYACC is set. (NVBACKEY is also not readable while KEYACC is set.)

• When the bootloader runs does it need to enter the key to be able load the application.

No. Flash erase and write are allowed while MCU is secured. So bootloader should have no problems operating in secured MCU. Security only disables reading flash, RAM and EEPROM via BDM pin.

Backdoor unsecure is required in case you want to debug secured MCU without erasing it, or read some parameters or error logs stored in secured MCU.

•  Can I include the key the application? Is this the correct approach?

This is possible. But you need some secure way to tell application it is time to unsecure. Sending unknown backdoor key over SCI may be quite secure. Applying some secred waveform to some test pin may be also quite secure.

[kef]

• When the bootloader runs does it need to enter the key to be able load the application.

[barbercolman]

Thanks for the help. 

I am using the MCF51.

The issue I am looking to resolve is the factory programmes a part and sends it to us. We need to verify that the correct code was programmed in the part. I want to temporaly want to unprotect the part then verify the flash. 

Normally we the Cyclone pro to program and verify. How do I execute code in ram and verify using the Cyclone? Is there a better way?

[kef]

Do you want to check correctness of factory programming or to check whether they programmed correct version of code?

Correctness of code flashing should be normally done adding code checksum check to your code. Blink some LED or something in case checksum doesn't match.

Version reporting could also be done pulsing some pin, sending version number over SCI etc

It is impossible to backdoor unsecure, unless you have 1) KEYEN bits programmed to binary 10, 2) programmed backdoor key other than all 0 or all FF, 3) your application provides some method to trigger backdoor unsecure routine. It looks like you don't have all 3 conditions met in factory programmed parts, so you can't backdoor unsecure them.

Search CF and CF CW forums for how to allocate function in RAM. Also see attached example. See Fibonacci routine in main.c and ### highlighted necessary modifications in *.lcf file.