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
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
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 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?
Solved! Go to Solution.
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!
-----------------------------------------------------------------------------------------------------------------------
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!
-----------------------------------------------------------------------------------------------------------------------
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.
Good to know Bernd!
Thank you for sharing your finding, this may help others.
Regards!
Jorge Gonzalez