secured MKL05 immediately self-destructs when trying to connect to it with j-link

prof7bit — Fri, 21 Aug 2015 07:29:04 GMT

Hi,

(Ok, it does not really destruct itself, only the contents of its memories).

I'm not sure whether this is a Kinetis feature or whether I should ask in the SEGGER forum because I cannot find any references to that behavior in any of the documentation. The observed behavior is this:

(A) programming with flash security bytes at 0x400 set to 0xffffffff ffffffff ffffffff fffffffe in the .bin file

- I can program the flash

- The program runs as intended

- I can debug with J-Link

- I can read out any memory area with jlink commander or with SEGGER's J-Mem tool

(B) programming with flash security bytes set to 0xffffffff ffffffff ffffffff ffffffff in the .bin file (If I understood it correctly this means mass erase is still allowed but reading back the flash with SWD is not)

- I can program the flash

- The program runs as intended, everything is fine, I can even use my own bootloader to update the firmware

- any attempt to connect with J-Link (just connect, not even trying to read) results in an immediate and complete chip erase without any prior warning or notice. It reads all flash memory as 0xff except that single one byte in the flash security area that reads as 0xfe, any trace of my program is gone (and it is really gone because neither my application nor my bootloader will run anymore, it basically instantly self-destructs when attempting to connect with J-Link)

This is how I connect to trigger the behavior:

Contents of jlink_readout_test.txt:

mem32 0x400 8

And this is when I execute it

>"C:\Program Files (x86)\SEGGER\JLink\JLink.exe" -Device "MKL05Z32XXX4" -CommandFile jlink_readout_test.txt

SEGGER J-Link Commander V5.00i ('?' for help)

Compiled Jul 10 2015 18:28:50

Script file read successfully.

Info: Device "MKL05Z32XXX4" selected.

DLL version V5.00i, compiled Jul 10 2015 18:28:14

Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46

Hardware: V8.00

S/N: 268004727

OEM: SEGGER-EDU

Feature(s): FlashBP, GDB

Emulator has Trace capability

VTarget = 3.287V

Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000

No devices found on JTAG chain. Trying to find device on SWD.

Info: Found SWD-DP with ID 0x0BC11477

Info: Found Cortex-M0 r0p0, Little endian.

Info: FPUnit: 2 code (BP) slots and 0 literal slots

Info: CoreSight components:

Info: ROMTbl 0 @ F0002000

Info: ROMTbl 0 [0]: FFFFE000, CID: B105900D, PID: 000BB932 MTB-M0+

Info: ROMTbl 0 [1]: FFFFF000, CID: B105900D, PID: 0008E000 MTBDWT

Info: ROMTbl 0 [2]: F00FD000, CID: B105100D, PID: 000BB4C0 ROM Table

Info: ROMTbl 1 @ E00FF000

Info: ROMTbl 1 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS

Info: ROMTbl 1 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT

Info: ROMTbl 1 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB

Cortex-M0 identified.

Target interface speed: 100 kHz

Processing script file...

00000400 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE

00000410 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF

Script processing completed.

J-Link>

As you can see in the 0x410 line it really erased the chip, there would be the beginning of the .text section and it is completely empty. I would have expected an error message that it cannot be read because the chip is secured but the fact that the jlink commander does not print a single line about this in the console led me to believe that this *might* be a feature that is built into the hardware itself and happens automatically. But I cannot find any references to such behavior in the documentation, neither Kinetis nor SEGGER nor elsewhere in the forums on the www.

Is this a Kinetis feature or should I ask in the SEGGER forum?

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link

Jorge_Gonzalez — Mon, 24 Aug 2015 17:50:25 GMT

Hello Bernd K:

The Kinetis MCU does not have such feature. When a device is secured the way to recover external access is with a Mass Erase, but it has to be triggered either internally by the MCU's programmed code (which I assume is not your case) or externally with EzPort or the JTAG/SWD tool itself.

The application note AN4507 contains very interesting information about security options in Kinetis:

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4507.pdf

The behavior you see must be caused by the JLink.exe software or the Segger J-Link tool. I think you can get more precise help from Segger forum.

Regards!,
Jorge Gonzalez

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

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link

prof7bit — Mon, 07 Sep 2015 09:16:29 GMT

I found it. It was indeed the SEGGER software, it has one of these "never ask me this question again" checkboxes (without any config dialog to turn it off again) in one of their tools and when checked this wil make *ALL* segger tools *always* immediately and silently mass erase any chip on connect as soon as it detects the chip is secured.

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link

Jorge_Gonzalez — Mon, 07 Sep 2015 21:09:18 GMT

Good to know Bernd!

Thank you for sharing your finding, this may help others.

Regards!

Jorge Gonzalez

Kinetis MicrocontrollersのトピックRe: secured MKL05 immediately self-destructs when trying to connect to it with j-link

secured MKL05 immediately self-destructs when trying to connect to it with j-link

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link

Re: secured MKL05 immediately self-destructs when trying to connect to it with j-link