Secured MKL05Z32

[wellissonrogato]

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?

[wellissonrogato]

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

[pgo]

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

0

% 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

[pgo]

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:

1. settarget arm
2. openbdm
3. connect
4. gs

Please report the results from the above commands.

bye

Results I obtained using TCL on secured device:

USBDMScript incorporating TCL - Copyright(c) 2011

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.Status  => 0x0001007F MASS_ERASE_ACK|FLASH_READY|SECURE|MASS_ERASE_EN|BACKDOOR_EN|HALT|

MDM-AP.Control => 0x00000000

DHCSR          => Failed

DEMCR          => Failed

MC_SRSH        => Failed

MC_SRSL        => Failed

WDOG_RSTCNT    => Failed

0

%

[wellissonrogato]

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

gs

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

0

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

[colin]

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.

[jeremyzhou]

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!
-----------------------------------------------------------------------------------------------------------------------