Actions
Engagement
  • Author Author: FreescaleTools_and_Software
  • Date Created: Date Created
  • Last Updated Last Updated:
  • Views 639 views
  • Likes 0 likes
  • Comments 1 comment
Related
Recommended

Tutorial for FRDM-KL25Z: Unsecuring the Freescale Freedom Board

This tutorial was extracted from Erich Styger blog http://mcuoneclipse.wordpress.com with his agreement.

 

imageimage

 

In "Device is Secure" I had a case where this was a false alarm. But recently there has been a report in the Freescale Forum that this can be a real problem with the Freescale FRDM-KL25ZFRDM-KL25Z Freedom board I’m using too. I was not able to reproduce this on my end, so a reader of this blog who sent me a binary file to reproduce it.

Well, I was really scared to try that "killer" file on my board, but well, that board is not that expensive, and I have 5 pieces of silicon at hand from a sample order :-) . So I took some risk, and programmed that binary using the simple flash programmer. And indeed, when I wanted to debug it again, I got that dialog with my black Freedom board:

 

image

Device is Secure. Erase to unsecure?

 

 

But even if I try ‘yes’ several times, it fails to unsecure the device through OpenSDA:

 

image

Console log

  

 

 

Several things to consider:

  • I knew my board is fine (power supply/etc). It is just that program I have flashed to the device.
  • Looking at the schematics: That R25 resistor which can or cannot be on the board did not make a difference.
  • I had the experience that unsecuring with OSBDM/OSJTAG seems not to work in all cases. The P&E Multilink does a much better job in my view, so I always have one on my desk, even if using a board with OSJTAG, OSBDM or OpenSDA
  • But: I have ordered the JTAG headers for the Freedom board, and they have not arrived yet, so no way to use the Multilink :-( .

 

How to solve it?

I knew from the Freescale forum that P&E had released new drivers *after* the MCU10.3 beta release. And indeed, they solve my above problem :-) . That "device is secure" shows up, and after one or two unsecure attempts I have access to my board again :-) . 

Integrating these files into Eclipse and MCU10.3 is relatively easy, if you follow the instructions below:

 

1. :!: This patch is for MCU10.3beta only! I assume it is *not* working for any other CodeWarrior release!

2. This is provided ‘as is’ :!: , so make backups as necessary (noted in the steps below)!


3. Close Eclipse/CodeWarrior if it is running.

4. Browse to this folder: <MCU10.3beta>\MCU\bin\plugins\support\ARM


5. This folder has a subfolder named ‘gdi’. Zip that folder (as a backup). Then remove the ‘gdi’ folder. It is *not* enough to rename that folder, as CodeWarrior still might load the DLLs. Or move that folder completely outside of your installation folder to a place somewhere else.


6. Download the zip file from here to your machine, and copy it into the folder from above step (<MCU10.3beta>\MCU\bin\plugins\support\ARM).


7. That zip file has a patched/modified version of the gdi folder. Unpack it as <MCU10.3beta>\MCU\bin\plugins\support\ARM\gdi


8. Restart Eclipse/CodeWarrior. Now you should be able to unsecure the board again. At least it worked for me :-) .

 

Happy Unsecuring  :-)

  • Perfect! This exact "secured" incident occured during my work with the Freedom board.  Like you, I had a part available, but kept putting off the soldering task, hoping someone would come along with a solution.  And this is indeed a solution.  I followed the steps you outlined to "patch up" the V10.3 beta and the board is alive and well!  Thanks for posting this most helpful info!

     

    Frank