HotSync and backdoor key mechanism

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

HotSync and backdoor key mechanism

585 Views
martinbosma
Contributor I

Hi All,

 

My application has a bootloader and appliation. Recently a new app version was release, which contained a bug.

Programming using the bootloader works ok, but when the application start it seems to crash.

Now it is rebooting in an endless loop and I cannot access the bootloader nor the app, unfortunately.

 

The application runs on a mc9s08dz60 and I have enabled the backdoor key (NVBACKKEY0-7) and KEYEN=1.

I also found out that I can connect my debugger (Cyclone Pro) in HotSync, using the attach debug session type.

 

It seems I can connect with my device, but obviously all I read back is 0.

Now, is there any way I can enter the backdoor key so I can step through my code finding the line where the code crashes?

I can access the key registers using the register window and I can also write them with the key I have.

But nothing seems to happen. I've read somewhere that you also need to set KEYEN=1, but the register containing it is readonly.

 

Any other possibility is also very welcome.

Labels (1)
0 Kudos
1 Reply

441 Views
tonyp
Senior Contributor II

Some important things to note about security:

* The on-chip debug module cannot be enabled while the MCU is secure.

* If KEYEN is 1, a secure user program can temporarily disengage security by steps ... (1), (2), (3) [for details, see the MCU reference]

* The security key can be written only from secure memory (either RAM or flash), so it cannot be entered through background commands without the cooperation of a secure user program.

So, unless your code already residing in the secured MCU has some method to send the backdoor key to the NVBACKKEY locations, there is no possibility to disable security without erasing the chip.  Sending the backdoor key via Cyclone or any other BDM pod is not going to do you any good (as you've already witnessed).

As for your firmware resetting all the time, this is very likely a COP reset issue.  Try turning off COP watchdog and see if that helps.  If it does, then it's a matter of figuring out where your code runs too long without kicking the COP.  If not, the next thing to check is unbalanced stack or RAM corruption.

Is it not possible to load the app in another MCU but without security enabled so you can debug it there?

Hope this helps!