Unsecuring the KL25Z Freedom Board

Posted on October 26, 2012 by Erich Styger

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 Freedom KL25Z 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:

Device is Secure. Erase to unsecure?

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

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:

❗ This patch is for MCU10.3beta only! I assume it is *not* working for any other CodeWarrior release!
This is provided ‘as is’ :!:, so make backups as necessary (noted in the steps below)!
Close Eclipse/CodeWarrior if it is running.
Browse to this folder: <MCU10.3beta>\MCU\bin\plugins\support\ARM
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.
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).
That zip file has a patched/modified version of the gdi folder. Unpack it as <MCU10.3beta>\MCU\bin\plugins\support\ARM\gdi
Restart Eclipse/CodeWarrior. Now you should be able to unsecure the board again. At least it worked for me :-).

Happy Unsecuring 🙂

18 thoughts on “Unsecuring the KL25Z Freedom Board”

Nana on October 26, 2012 at 10:51 said:

Hello, I want to thank you about the work you have done !
The unsecureing procedure worked for me ! But now I have a problem doing debugging. It’s failing to initialize the target! If i use the MSD_Bootloader to load srec files every thing seems to work ok, but not if I want to debugg a project ! I have replaced back the gdi folder with original one and the problem persist !

LikeLike

Reply ↓
- Erich Styger on October 26, 2012 at 11:18 said:
  
  Hello,
  keep in mind that you need to load a different ‘applet’ into OpenSDA: one for debugging and one for MSD bootloading. Have you loaded the DEBUG-APP_Pemicro_v102.SDA file on the K20?
  
  LikeLike
  
  Reply ↓
quevedounicamp on October 29, 2012 at 18:16 said:

Hello,

I ran into the “secure device” problem early this morning. After replacing the drivers, the board resumed working. Now, the same thing has happened again, and replacing drivers again is not working. I will try connecting the board in my home computer tonight (problems have happened in my work computer). By the way, I have tried the debugger applet with CW10.3, and I have also tried the MSD applet, dragging a precompiled file. Nothing worked.

LikeLike

Reply ↓
- Erich Styger on October 29, 2012 at 18:28 said:
  
  In case you have set the ‘disable mass erase’ bit in your download, then you have definitely bricked the device: game over 😦 and you won’t be able to recover the microcontroller. Have you set the security bits AND the disable mass erase? If you want, you can send me your S19 file and I’ll have a look.
  
  LikeLike
  
  Reply ↓
  - quevedounicamp on October 29, 2012 at 18:36 said:
    
    Well I do not remember which test program I was downloading when that happened. I tried one short program I wrote myself to change LED color… it worked fine… then I do not remember if I used the debugger, or changed to the MSD. Anyway, I had just used default settings. I do not know where I set the security and mass erase bits. Could you tell me where I can set them on CW10.3, so I can check on my project?
    
    LikeLike
    
    Reply ↓
  - quevedounicamp on October 30, 2012 at 11:19 said:
    
    After trying hard to remember what I had done wrong, I think I know what I did. I tried to download an ELF file using the MSD applet. Maybe it has messed up the security and erase bits. The board does not accept programming through CW10 and the debugger applet, and also does not accept SREC downloads. OpenSDA bootloader works fine. I tried that in 2 computers. I am going to buy a new microprocessor and substitute it on the board.
    
    Maybe you could write something on how to avoid messing up with these processors. That would be very helpful.
    
    Thank you
    
    LikeLike
    
    Reply ↓
    - Erich Styger on October 30, 2012 at 13:44 said:
      
      I have heard that a next version of the MSD bootloader will check if the disable mass erase bit is set to avoid such a problem.
      As about how to find out if that bit is set: the best way is to inspect the S19 or intel hex file. If I find time, I’ll describe how this can be done manually.
      
      LikeLike
    - Erich Styger on November 4, 2012 at 11:34 said:
      
      Here is more about what is behind securing, and how to avoid the problem (or how to create a toxic baby :-)): https://mcuoneclipse.com/2012/11/04/how-not-to-secure-my-microcontroller/
      
      LikeLike
Richard Schloss on October 31, 2012 at 23:55 said:

Hey Erich,

Thanks for posting this solution. I spent almost all afternoon trying to figure this bug out.

Richard

LikeLike

Reply ↓
Pingback: How (not) to Secure my Microcontroller | MCU on Eclipse
Pingback: Bricking and Recovering FRDM-KL25Z Boards: Reset, SWD Clock and Low Power | MCU on Eclipse
Manjit on February 4, 2014 at 07:54 said:

Can I unlock my device using IAR & OpenSDA.

I am working on FRDM-KE02Z board and my device get locked. Can you please help me out?

LikeLike

Reply ↓
- Erich Styger on February 4, 2014 at 08:05 said:
  
  I recommend that you load the latest P&E firmware on the board (see https://mcuoneclipse.com/2013/12/14/new-pe-opensda-firmware-v114/) and then use CodeWarrior for MCU10.5 to unlock the board. MCU10.5 with P&E has updated the unlocking. At least for my boards, CodeWarrior was able to unlock all of my boards (except one, where as well Keil and IAR failed). Otherwise I suggest that you submit a ticket to IAR.
  
  LikeLike
  
  Reply ↓
  - vinod on March 7, 2014 at 06:55 said:
    
    Hello Sir,
    I am trying to program a custom board (KL04) via the Multilink.It worked fine, but then it shows the “Device is secure.Erase to unsecure”.I keep pressing Yes.
    AFter doing this twice the “Multilink” not connected is shown. There was another board that was doing the same.
    
    But, its now, surprisingly working,except this 1 board.
    
    I tried the Processor halt utility. Still no luck.Uninstalled/installed PE drivers. No luck.
    
    Also, no where in the code have I modified that register (FTFA_FOPT or any such dangerous registers:) .
    
    Infact CODE WARRIOR warns you if you make any changes to such registers.).
    Also, is there any way I can ensure such a message/error does not occur in any future boards. Can this be done via s/w code or so.
    I saw in a site that I can look at the Binary files at the location 0x40C. How can I look at 0x40C. Kindly help me out. This is a disaster as 1 board is beyond recovery.
    
    Another thing that I am planning to do is inspect the intel hex file before programming it into the controller( the 0x40C frame for disable mass erase). You had mentioned you wld so that in one of your earlier posts. Can u tell me how to read an ihex file. For eg – the 1st line is “:10000000000C002025090000C9080000C9080000F4”
    How do I analyse this. Thank u sir.
    
    Vinod.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 7, 2014 at 08:53 said:
      
      Hi Vinod,
      I suggest you check if the clock of your board is working properly, and that the supply voltage is correct. I have seen ‘secured’ messages for all kind of things where the debugger is not able to talk to the device. Another common cause is that you programmed the wrong file in error to the board.
      In the worst case, your board is lost.
      As for reading hex (or other files like S19), see https://mcuoneclipse.com/2012/09/27/s-record-intel-hex-and-binary-files/
      
      LikeLike
Angel G. on May 2, 2015 at 00:11 said:

I locked my custom KL26 board by flashing it with precompiled example for FRDM-KL26:
– via CMSIS-DAP firmware (on the K20 chip of FRDM-KL25), using Openocd this way:
flash write_image erase “/media/blink_red_blue_freedom.srec”
after several commands “kinetis mdm mass_erase” to get it back, poweroff/on, OpenOCD still showed
“Your Kinetis MCU is in secured state, blah…” but after several “reset halt” commands it was able to halt. Then I successfully reprogrammed it with a .bin file. Will try to break it again 🙂

LikeLike

Reply ↓
- Erich Styger on May 2, 2015 at 08:49 said:
  
  I have experienced that that CMSIS-DAP with OpenOCD is not a good choice to unlock a locked board. P&E and Segger was what working for me. Using OpenOCD in my cases either always failed, or only worked after many attempts (as in your case?). The reason is probably that OpenOCD is much slower, and therefore misses the small window to regain access to the chip.
  
  LikeLike
  
  Reply ↓
  - Angel G on August 12, 2015 at 15:26 said:
    
    Not after we have OpenOCD 0.9, here’s my dialog with it:
    > kinetis mdm mass_erase
    Attempting mass erase without hardware reset. This is not reliable; it’s recommended you connect SRST and use “reset_config srst_only”.
    > reset halt
    MDM: Chip is unsecured. Continuing.
    ———-
    
    LikeLike
    
    Reply ↓