Permanently Unsecuring Flash without mass erasing...

[sebbyBaby]

Hi...

I am trying to unsecure flash permanently, without a 'mass erase',

and it isn't working: the device is unsecured, but reverts back to the

secured state after a reset.

Device is mc9s12c32

The data sheet states: "Once the MCU is unsecured, the Flash

security byte can be programmed to the unsecure state, if desired"

Pseudo-code for my latest version of code looks like:

WriteBAckDoorKey();

if( FlashIsUnsecured() )

{

     EraseTopSector();

    set NVFPROT to 'protected top 8K'

    set NVFSEC  to KEY_DISABLED, SEC_DISABLED

    RestoreTopSector();

}

[We have been locking the flash, and unlocking it temporarily,

for quite a while now, and we are confident that the code 'blocks'

are OK]

I have tried a few variations on the above, (e.g. restoring the

trashed key in the 'if' block, setting NV_FSEC to KEY_ENABLED),

but have not had any success.

It seems as if permanently unsecuring the flash requires a mass

erase. This would make the operation similar to that of changing

the protection setting in NV_FPROT, and is logical enough.

Does anyone know if this is indeed the case?

With thanks, and best regards,

Sebastian

[kef]

Unsecure has nothing in common with the write protection. You can unsecure flash, but can't write-unprotect it. Resetting FPROT into not protected state requires operation in special single chip mode, which is only possible using BDM debugger.

If you need to be able to reprogram security bits, then you should not set NVPROT to protect sector containing security bits.

I don't really understand what for are you trying to disable security permanently. Once backdoor unsecure is complete, you can use Hiwave debugger in hot-plug mode. You can halt MCU, debug; if you wish read all the flash, mass erase and reflash chip with the same data but with security off.

[sebbyBaby]

Hi...

Ty for getting back to me...

I agree that what we are doing is quite unorthodox, and that we are

using the flash locking / unlocking feature very differently from what

it was intended for.

By way of (brief) background info:

We are using the state of FSEC as a means of controlling the re-

programming of the ECU... All programming commands

sourced on the CAN bus check this byte, and if the unit is secured,

they don't do anything.  An 'authorised person' will lock the device

with a key known to himself only, and then the ECU can't be changed

without his unlocking it first. [quite literally: use of a BDM is impossible

once the unit has been assembled.]

electronically, it doesn't actually prevent us from programming it, nor

is it actually secure from hacking, but it does prevent impromptu code

changes. 

Problem is: it is not always convenient to have to re-program the ECU

in the presence of the 'authorised person', and it would be much more

workable to be able to get him to unlock it, and then we give it back to him 

2, 3 days later to re-lock.

Thing is, NVFSEC seems to be similar to NVFPROT, in that they may only

be re-programmed after a mass erase... And I was wondering if this was

actually the case, or if there is a trick that I'd missed.

Best regards,

Sebastian

PS: surprisingly enough, there was no problem 'protecting' the back door

key BAKEY with the FPROT mechanism.  Buit I do agree that it is very risky,

in that the upper sector of code will be trashed (and the ECU written off!) if

something goes wrong...

[kef]

Purpose of security bits is to prevent read out of firmware using BDM. Security bits don't control writeability of flash. To lock in application programming (programming over CAN in your case), you should use your own NV-variable in not write protected flash. Clearly this variable should not be placed in vectors area. Customizeable unlocking keys also should not be placed in vectors area.

• [quite literally: use of a BDM is impossible once the unit has been assembled.]

But not when you replrogram NV security bits to disable security.

• Problem is: it is not always convenient to have to re-program the ECU in the presence of the 'authorised person', and it would be much more workable to be able to get him to unlock it, and then we give it back to him 2, 3 days later to re-lock.

What authorised person is doing with your units? Is he debugging firmware in the field (setting breakpoints, doing some tests, inspecting variables etc), or just reflashing parts of your firmware? Disabling security is required only for debugging purposes. Write locking/unlocking for reprogramming over CAN or other non-BDM interface should not require  disengage of security.

• Thing is, NVFSEC seems to be similar to NVFPROT, in that they may only be re-programmed after a mass erase... And I was wondering if this was actually the case, or if there is a trick that I'd missed.

No, NVFSEC is not similar to NVFPROT. Reprogramming of NVFSEC doesn't require mass erase. Mass erase is required only to be able to reprogram your units using BDM. 

• PS: surprisingly enough, there was no problem 'protecting' the back door key BAKEY with the FPROT mechanism. 

No surprise here. Security bits and backdoor key is writeable until you set FPROT register (or NVPROT and then reset) to protect sector containing vectors, backdoor key, NVPROT and NVFSEC.

•  Buit I do agree that it is very risky, in that the upper sector of code will be trashed (and the ECU written off!) if something goes wrong...

 Yes, it's like shooting to your own foot.

[sebbyBaby · Accepted solution]

Hi...

Just to update:

We took your advice, and moved our 'key' to a different area, and

everything works as we intend it to.

Thanks for answering the question as well, i.e. confirming that

NVFSEC should be reprogrammable without mass erase. It

does, however, mean that I was trying to do it incorrectly... 

I wonder if our use of NVFPROT at the same time was preventing

the reprogramming of NVFSEC, and causing the problem I was

seeing...  I may revisit it one day out of curiousity.

Thanks once again,

Seb

[kef]

Yes, write protecting vectors sector makes whole vectors sector write protected, no exceptions are available for NVFPROT, NVFSEC and NVBACKKEY. Programming NVFPROT makes write protection permanent and removeable only using BDM debugger. Less permanent write/erase protection is available using FPROT register. Instead of programming NVFPROT you write protection setting to FPROT. Protection in this case is enabled until reset.