topic Re: Secured MKL04Z32 in Kinetis Microcontrollers

Secured MKL05Z32

wellissonrogato — Thu, 11 Aug 2016 12:47:52 GMT

Hi, i have a simple application for MKL05Z32, and i bought 5 devices for prototyping. With small changes in the circuit it worked and i have a big pressure for the fabrication of the first 100 products.

The problem is that whitin those 5 devices i couldn't program 2, it's said to be secure, and couldn't unsecure it.

I'm using USBDM, and the information that it's secured comes from their software.

I can see a sawtooth in the reset pin.

I tryed many procedure exposed in forums, force reset low and make a power cycle, 100nF cap in the reset pin, etc..

I see some possibilities:

1 - Those devices comes randomly secured, and i'm doing something wrong trying to unsecure it. So, making 100 products, i'm risking loosing ~ 40% (2/5), that comes secured.

2 - Those devices were manually soldered, so i could have damaged those that i couldn't program. Would i get those message if it's a hardware problem?

Any ideas?

Re: Secured MKL04Z32

jeremyzhou — Fri, 12 Aug 2016 03:16:36 GMT

Hi Wellisson Rogato，

Thank you for your interest in NXP Semiconductor products and the opportunity to serve you.

In opinion, almost two fifths of the 100 chips encounter the same issue and it seems so weird.

According to your statement above, you had tried a variety of ways to unsecure the 'secured' chips, however all approaches didn't work at all.

So I think these 'broken 'chips already had been damaged, and inappropriate manually soldering can cause the issue, but it needs more checking.

Now I'd highly recommend you to contact with the local DFAE about the issue and to check your own board.

And you can find the DFAE contact information in following.

Distributor Network|NXP
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Secured MKL04Z32

colin — Fri, 12 Aug 2016 17:53:31 GMT

If you have only tried using the USBDM device and software, I would definitely try different hardware and software before blaming the Kinetis MCUs themselves. If you have access to Segger J-Link or a P&E Multilink Universal, this would work, and you can use either the Segger/P&E gdb server, J-Link commander software, or Kinetis Design Studio to flash the chip.

You could even use a Freedom board and connect a SWD cable from it to debug your target MKL04Z32 chips. But you should definitely try some other device before giving up. Could be flaky debugger hardware that usually works but is not robust.

Re: Secured MKL04Z32

pgo — Sat, 13 Aug 2016 08:49:17 GMT

Hi Wellisson,

I've just retested USBDM with a KL03 which is the nearest I have to a KL04 and I couldn't get it to misbehave but as I only have one sample to test with this may not be realistic.

I tested with a JS16 based programmer and a MK20 based version and the latest version of the software (including BDM firmware).

Can I check the following please:

What USBDM hardware?
What operating system?
What software version?
What firmware version?
What result do you get when click "Detect Chip"?
What result when you manually select the device type and use "Mass Erase Now"?

If you have the time you can do some tests on a secured device using the USBDM TCL interpreter:

settarget arm
openbdm
connect
gs

Please report the results from the above commands.

bye

Results I obtained using TCL on secured device:

Press ? for help

===============================================================

usbdm_rc.tcl

================

This file is 'sourced' whenever usbdmScript.exe is executed

Add your own custom commands

===============================================================

% settarget arm

USBDM DLL Version = 4.12.1.130

BDM List:

0 - USBDM-OPENSDA-9158037 : USBDM ARM-SWD for OpenSDA

Found 1 devices

:setTarget ARM

% openbdm

Opening USBDM-OPENSDA-9158037

BDM Version = HW=59, SW=4C

% connect

Device appears secured

% gs

MDM-AP.Control => 0x00000000

DHCSR => Failed

DEMCR => Failed

MC_SRSH => Failed

MC_SRSL => Failed

WDOG_RSTCNT => Failed

Re: Secured MKL04Z32

wellissonrogato — Tue, 16 Aug 2016 12:51:07 GMT

Hi pgo,

thanks for your reply.

Information requested:

What USBDM hardware?

USBDM-SWD SER-JS16

What operating system?

Windows 10

What software version?

USBDM 4.12.1.120

What firmware version?

BDM Firmware Ver 4.12.1

What result do you get when click "Detect Chip"?

It is not possible to determine the device type as it appears to be secured. It is necessary to unsecure ...

(Click Yes)

Unsecuring the device failed. Reason: Execution of TCL script returned an error.

What result when you manually select the device type and use "Mass Erase Now"?

Unsecuring the device failed. Reason: Execution of TCL script returned an error.

settarget arm

USBDM DLL Version = 4.12.1.120

BDM List:

0 - USBDM-JS16-SWD_SER-0018 : USBDM HCS08, HCS12, CFV1, ARM-SWD BRM

Found 1 devices

:setTarget ARM

openbdm

Opening USBDM-JS16-SWD_SER-0018

BDM Version = HW=97, SW=4C

connect

Device appears secured

MDM-AP.Status => 0x0000003E FLASH_READY|SECURE|MASS_ERASE_EN|

MDM-AP.Control => 0x00000001 MASS_ERASE_EN|

DHCSR => Failed

DEMCR => Failed

MC_SRSH => Failed

MC_SRSL => Failed

WDOG_RSTCNT => Failed

Manually running the "proc massEraseTarget { }" in "Kinetis-KLxx-flash-scripts.tcl", seems that wcreg is not changing the registers, keeping the original value.

Re: Secured MKL05Z32

wellissonrogato — Tue, 16 Aug 2016 17:58:10 GMT

I first posted MKL04Z32, that was wrong, the device is MKL05Z32. Sorry.

Re: Secured MKL05Z32

pgo — Sun, 21 Aug 2016 09:43:24 GMT

Hi Wellisson,

I haven't got anywhere with this,.

I retested with a KL05 with slightly different results to what you obtained:

% gs

MDM-AP.Status => 0x00000034 SECURE|RESETn|MASS_ERASE_EN|

MDM-AP.Control => 0x00000000

DHCSR => Failed

DEMCR => Failed

MC_SRSH => Failed

MC_SRSL => Failed

WDOG_RSTCNT => Failed

% gs

MDM-AP.Status => 0x00000074 SECURE|RESETn|MASS_ERASE_EN|BACKDOOR_EN|

MDM-AP.Control => 0x00000000

DHCSR => Failed

DEMCR => Failed

MC_SRSH => Failed

MC_SRSL => Failed

WDOG_RSTCNT => Failed

This is slightly different to your results but shouldn't affect the programming outcome.

The minimal circuit I used was:

The only problems I have seen with these devices is tieing the NMI pin low upsets the programming. It is also important to have a bypass capacitor across the power near the chip as the current spikes when mass erasing.

bye