MK22FN read protection (first project with Kinetis).

EgleTeam · ‎01-27-2016

Hello,

We just finished our first project using Kinetis MCUs (MK22FN512VLH12). We just need to protect the flash content (only reading). We have few questions.

1. It is enough with change:

/* Flash Configuration */

.section .FlashConfig, "a"

.long 0xFFFFFFFF

.long 0xFFFFFFFE

by:

/* Flash Configuration */

.section .FlashConfig, "a"

.long 0xFFFFFFFF

in startup_MK22F51212.S ?

2. Why we can continue debugging if it is suppossed that the flash is protected?

3. Once programmed the MCU in release mode: Will be possible to read the flash content from inside of the MCU (we need it)? I mean: Does FSEC(SEC) protec from outside (jtag-swd) or also from internal reading?.

I launch the questions because, we don't know why, our Jlink-Pro doesn't recognizes the MCU outside KDS so we can't try to read the flash content using Segger tools.

Thank you and regards.

Manuel.

mjbcswitzerland · ‎01-27-2016

Manuel

You can either create a connection target (rather than a debugging target).

Or you can edit the debugging target propertites (in KDS) to connect without loading code; if you search the dialogue there is a check box for this somewhere.

Usually the debugger will warn that it is unsecuring a target when loading code but Segger looks to be doing it silently in your case.

Regards

Mark

View solution in original post

mjbcswitzerland · ‎01-27-2016

Hi

If you write 0xff unstead of 0xfe the device is secured and the JTag, EzPort, SWD can no longer read the Flash content (to recover, a mass erase followed by write of 0xfe is required, as long as the mass erase function has not been disabled). The Flash can still be used normally by the processor.

After writing 0xff a reset is necessary for the protection to actually take effect.

If you can still connect (after a reset) via JTAG and read the content, read the values at 0x400..0x40f to see what is programmed there since it can't be as you expect.

Regards

Mark

EgleTeam · ‎01-27-2016

Mark,

Thanks for solving questions 1 and 3.

I dind't say I can read the flash memory after change the value to 0xFF. I said that I can still debug the code in KDS with J-Link when I program the MCU in debug mode (I see 0xFF in 0x40C in the hex file after building). As I said, I can't test if I can read the flash after programming in release mode since, as far as I know, KDS doesn't have any tool to read the content and the rest of tools of Segger (I don't know why) doesn't recognize the MCU. This why I asked about if it is normal that I can still debug when FSEC(SEC) = 0xFF.

Regards,

Manuel.

mjbcswitzerland · ‎01-27-2016

Manuel

It is not normal that you can debug when the FSEC field is set to 0xff. The debugger should not be able to connect.

It is however possible that you have the debugger set up to automatically perform a chip erase to reset security when you load code. Then it could well be like that.

Try "connecting" (without loading) rather than loading new code each time and it should tell you that it can't without first erasing and re-programming to work around security.

Regards

Mark

EgleTeam · ‎01-27-2016

Mark,

it seems you are right. Each time I click to debug this is the output in the console:

SEGGER J-Link GDB Server V5.10g Command Line Version

JLinkARM.dll V5.10g (DLL compiled Jan 6 2016 13:44:33)

-----GDB Server start settings-----

GDBInit file: none

GDB Server Listening port: 2331

SWO raw output listening port: 2332

Terminal I/O port: 2333

Accept remote connection: localhost only

Generate logfile: off

Verify download: on

Init regs on start: on

Silent mode: off

Single run mode: on

Target connection timeout: 0 ms

------J-Link related settings------

J-Link Host interface: USB

J-Link script: none

J-Link settings file: none

------Target related settings------

Target device: MK22FN512xxx12

Target interface: SWD

Target interface speed: 1000kHz

Target endian: little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link ARM-Pro V3.x compiled Jun 6 2014 16:00:09

Hardware: V3.00

S/N: 173001072

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.29 V

Listening on TCP/IP port 2331

Connecting to target...Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x00000000 (Data = 0x20010000)

Target interface speed set to 30 kHz

Resetting target

Halting target CPU...

...Target halted (PC = 0x000004D8)

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000

R12= 00000000, R13= 20010000, MSP= 20010000, PSP= 00000000

R14(LR) = FFFFFFFF, R15(PC) = 000004D8

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Select auto target interface speed (2000 kHz)

Flash breakpoints enabled

Semi-hosting enabled (Handle on BKPT)

Wrong client mask. Semihosting I/O not changed.

SWO disabled succesfully.

SWO enabled succesfully.

Downloading 1024 bytes @ address 0x00000000 - Verified OK

Downloading 16 bytes @ address 0x00000400 - Verified OK

Downloading 16144 bytes @ address 0x00000410 - Verified OK

Downloading 16064 bytes @ address 0x00004320 - Verified OK

Downloading 13204 bytes @ address 0x000081E0 - Verified OK

Downloading 8 bytes @ address 0x0000B574 - Verified OK

Downloading 4 bytes @ address 0x0000B57C - Verified OK

Downloading 4 bytes @ address 0x0000B580 - Verified OK

Downloading 16364 bytes @ address 0x0000B584 - Verified OK

Downloading 8852 bytes @ address 0x0000F570 - Verified OK

Read 4 bytes @ address 0x000004D8 (Data = 0xF000B672)

Read 2 bytes @ address 0x000014FA (Data = 0xF000)

Resetting target

Halting target CPU...

...Target halted (PC = 0x000004D8)

Read 2 bytes @ address 0x000014FA (Data = 0xF000)

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000

R12= 00000000, R13= 20010000, MSP= 20010000, PSP= 00000000

R14(LR) = FFFFFFFF, R15(PC) = 000004D8

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Read 4 bytes @ address 0x000004D8 (Data = 0xF000B672)

Setting breakpoint @ address 0x000014FA, Size = 2, BPHandle = 0x0001

Starting target CPU...

...Breakpoint reached @ address 0x000014FA

Reading all registers

Removing breakpoint @ address 0x000014FA, Size = 2

Read 4 bytes @ address 0x000014FA (Data = 0xFA57F000)

Reading 64 bytes @ address 0x2000FFC0

Where can I change the configuration to avoid the reloading?

Many thanks!

Manuel.

mjbcswitzerland · ‎01-27-2016

Manuel

You can either create a connection target (rather than a debugging target).

Or you can edit the debugging target propertites (in KDS) to connect without loading code; if you search the dialogue there is a check box for this somewhere.

Usually the debugger will warn that it is unsecuring a target when loading code but Segger looks to be doing it silently in your case.

Regards

Mark

EgleTeam · ‎01-27-2016

Mark,

I think is done. Debug icon ==> debug configuration ==>> Debugger ==>> Connect to running target.

Once clicked, "Initialize registers on start" is unchecked by itself, the ouput of the console is:

SEGGER J-Link GDB Server V5.10g Command Line Version

JLinkARM.dll V5.10g (DLL compiled Jan 6 2016 13:44:33)

-----GDB Server start settings-----

GDBInit file: none

GDB Server Listening port: 2331

SWO raw output listening port: 2332

Terminal I/O port: 2333

Accept remote connection: localhost only

Generate logfile: off

Verify download: on

Init regs on start: off

Silent mode: off

Single run mode: on

Target connection timeout: 0 ms

------J-Link related settings------

J-Link Host interface: USB

J-Link script: none

J-Link settings file: none

------Target related settings------

Target device: MK22FN512xxx12

Target interface: SWD

Target interface speed: 1000kHz

Target endian: little

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link ARM-Pro V3.x compiled Jun 6 2014 16:00:09

Hardware: V3.00

S/N: 173001072

Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

Checking target voltage...

Target voltage: 3.29 V

Listening on TCP/IP port 2331

Connecting to target...Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x00008DE0 (Data = 0x681B4B02)

Target interface speed set to 30 kHz

Select auto target interface speed (2000 kHz)

Flash breakpoints enabled

Semi-hosting enabled (Handle on BKPT)

Wrong client mask. Semihosting I/O not changed.

SWO disabled succesfully.

SWO enabled succesfully.

Read 4 bytes @ address 0x00008DE0 (Data = 0x681B4B02)

Reading 64 bytes @ address 0x2000FFC0

Read 4 bytes @ address 0x00001524 (Data = 0x46182301)

Read 2 bytes @ address 0x000014FA (Data = 0xF000)

R0 = 00000000, R1 = 0000A6E4, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 2000FFE8

R8 = 00000000, R9 = 00000000, R10= 20000000, R11= 00000000

R12= 00000000, R13= 2000FFE8, MSP= 2000FFE8, PSP= 00000000

R14(LR) = 000014D9, R15(PC) = 00008DE0

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Read 4 bytes @ address 0x00008DE0 (Data = 0x681B4B02)

Setting breakpoint @ address 0x000014FA, Size = 2, BPHandle = 0x0001

Starting target CPU.

And nothing happens (the debugger keeps frozen). There's not any advertisement but I guess that it is because the debugger can't read the flash content.

Am I wrong?

Is this enough to trust that the MCU will be protected in release mode?

Regards,

Manuel.

mjbcswitzerland · ‎01-27-2016

Manuel

I don't understand the Segger output but the fact that it hangs is a good sign (better would be a pop-up to say that it can't connect due to the secured mode as other debuggers tend to do - but this may also be a JLink configuration that you can manipulate too).

You could also try other debuggers and the EzPort programmers if you want to convince yourself 100%. An EzPort cloner is detailed here: EzPort Cloning

You can even try setting security in Teensy's K20 (https://www.pjrc.com/teensy/) to verify that its own on-board debugger can no longer handle it and so the board has to be thrown away.....

However, I can confirm that no one can read the program flash when the secured code is set - I have used security in many different Kinetis based products with many different Kinetis parts and it has always worked as is stated on the box.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html

K22: http://www.utasker.com/kinetis/FRDM-K22F.html / http://www.utasker.com/kinetis/TWR-K22F120M.html

For the complete "out-of-the-box" Kinetis experience and faster time to market