MK22FN512 flash security

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MK22FN512 flash security

2,970 Views
dusek_martin
Contributor IV

Hi,

I use NXP_Kinetis_Bootloader_2_0_0\targets\MK22F51212\kds\freedom_bootloader flash resident bootloader and my app on MK22FN512.

What is the correct Flash Configuration value (address 0x400 - 0x40F)  for me if I want:

mass erase enabled

backdoor disabled

nxp factory access denied

flash memory readback protection enabled (there is no way anybody can read my app's code using jtag, ezport, bootloader api or anything else)

ezport disabled

update application firmware using the bootloader

I tried to set it to:

.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFF908

This way KinetisFlashTool shows that the security state is "SECURED" and the update of my app is not possible:

Updating image......
Error: Update image failed(Command disallowed when security is enabled.).

Thanks

Martin

Labels (1)
0 Kudos
Reply
15 Replies

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

    About the flash configuration field in your code:

.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFF908

  it is according to this picture:

pastedImage_12.png

So, you configure the 0X40C as 0X08, it is 0b00001000

pastedImage_13.png

So, you really configure your code as secured mode.

But don't worry, you still enable the mass erase, now you can use the JLINK commander, and input: unlock kinetis

do the mass erase to unlock it.

If you want to protect the flash, you need to configure 0X408-0X40b, this is the program flash protection bytes.

Wish it helps you!

Have a great day,
Kerry

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

Hi Kerry,

the problem with configuring flash security in bootloader this way:

.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFF908

is that I can't update my app using flash resident bootloader (KinetisFlashTool.exe), because KinetisFlashTool.exe outputs:

Updating image......
Error: Update image failed(Command disallowed when security is enabled.).

(if I don't secure my chip then the update works)

So, how to secure my chip and at the same time be able to update my app using bootloader?

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

   Thank you for your udpated information.

   Please try to secure the chip, but don't configure flash protection, whether it works OK or not?

   Please also give me the KinetisFlashTool screen shot about your question.


Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

As far as i know this:

.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFF908

will set FPROT to ones which means unprotected flash areas. And it will secure the chip as you confirmed earlier. So I don't understand yours: "Please try to secure the chip, but don't configuration flash protect, whether it works OK or not?"

This is printscreen of KinetisFlashTool:

printscreen.png

I also tried to set "Erase All to Unlock" without success - obviously, as this is probably trying to mass erase the device and it would mass erase also the bootloader which is at the beginning of the flash memory. I don't want to use backdoor key.

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

   It's my fault, you didn't enable the flash protection function.

   Please give me your K22 chip full name, I need to check whether the flash bootloader can be used as your chip, as you know, K22 have a lot of chip, different chip have different feature.

   The bootloader code is mainly used for the FRDM-K22f120m board and the twr-k22f120m board.

  If you are using the same chip as FRDM-K22 board, please check the bootloader project, do you use the debug mode or the release mode? When the chip is secured, you need to select "Erase All to unlock", if you select this item, do you still have the same log in your above reply?


Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

It is MK22FN512VLL12

The bootloader can be for sure used on MK22FN512VLL12 or you want to tell me that your bootloader can be used only for one specific K22 MCU?

I use release mode. I repeat: bootloader works just fine, the problem is only with flash security settings.

The Erase All to unlock causes:

Start update progress......
Unlock device by ERASEALL......
Error: Unlock device failed(FlashEraseAllUnsecure isn't supported!).
Update process is stopped by error.

Obviously, the bootloader doesn't want to erase itself...

If you don't know answer to my issue, please can you pass it to another competent engineer?

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

  Please take easy!

  I already test it on my side, I can reproduce your problem now.

  So, I check it with our MCUBOOT R&D team this afternoon.

  I have got that, the flash bootloader don't have the unlock function, the EraseAll to Unlock is used for the kinetis chip which contains the ROM bootloader.

 K22 and K64 don't have the ROM bootloader, so it just use the flashbootloader.

So, they recommend me to use the backdoor key to unlock the flashbootloader.

 Now, follow me to use the backdoor key, and secure the flash bootloader.

1. In the flash bootloader

  1)Set the backdoor key, take an example:

BackDoorK0      EQU     0x1
BackDoorK1      EQU     0x1
BackDoorK2      EQU     0x1
BackDoorK3      EQU     0x1
BackDoorK4      EQU     0x1
BackDoorK5      EQU     0x1
BackDoorK6      EQU     0x1
BackDoorK7      EQU     0x1

2) FSEC enable the backdoor key and secure the chip

FSEC          EQU     0xbf

2. In the KinetisFlashTool, please do it like this:

pastedImage_1.png

Now, it works perfectly.

Please try it on your side.

Any updated information from your side, please kindly let me know.
Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

I'm sorry, but after 3 posts I had feeling that you still don't understand the issue.

As I wrote in post 2 or 3, I don't want to use backdoor key.

So, it seems that the conclusion is:

If we want:

1) secure the MCU so nobody is able to read contents of flash - either via JTAG, ezport, or bootloader (if there is read command implemented in flash resident bootloder - I don't know). Backdoor key is not an option in this case

and

2) update firmware using flash resident bootloader.

Then this is not possible.

To be honest, I don't understand why the flash resident bootloader can't erase and reprogram flash of secured device. This is perfectly possible and it seems it is just not implemented in your bootloader.

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

   You are right, the flash bootloader is designed like that.

   Why the bootloader can't erase and reprogram flash of secured device, it is also the flash bootloader function designed result. I have checked this confusion with our bootloader R&D department in the last week. They told me, just don't let the MCU have the risk in the secured mode.

   So, if you want to let the flash bootloader still work, you totally can modify the flash bootloader source code by yourself. 

  From the chip function side, you can do it, because as you know, the secure just relate to the SWD interface. But the bootloader UART interface, if your bootloader code don't have limitation, you still can do it.

  Now, if you have interest, you totally can modify the flash bootloader by yourself, if you even don't want to use the back door key. The back door key which I told you, just give you the method to let it work with the exist flash bootloader.

 

  


Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

Hi Kerry,

thank you. Finally we got to the point. I apologize for my impatience.

I modified bl_command.c:

  kCommandsAllowedWhenSecure = (HAS_CMD(kCommandTag_FlashSecurityDisable) | HAS_CMD(kCommandTag_GetProperty) |
HAS_CMD(kCommandTag_Reset) | HAS_CMD(kCommandTag_SetProperty) | HAS_CMD(kCommandTag_ReceiveSbFile) | HAS_CMD(kCommandTag_FlashEraseRegion) | HAS_CMD(kCommandTag_WriteMemory))

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

   Now, after the modification, do you make it work on your side?


Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

Yes, it works for me, I can't see any unexpected behaviour.

Can you also confirm that this modification will work as intended?

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

  Do you just modify the enum _secure_commands located at line 111 in file bl_command.c?

enum _secure_commands
{
    //! @brief Bitmask of commands allowed when flash security is enabled.
    //!
    //! This bitmask uses the same format as the AvailableCommands property. This is,
    //! the bit number for a given command is the command's tag value minus one.
  /*  kCommandsAllowedWhenSecure = (HAS_CMD(kCommandTag_FlashSecurityDisable) | HAS_CMD(kCommandTag_GetProperty) |
                                  HAS_CMD(kCommandTag_Reset) | HAS_CMD(kCommandTag_SetProperty) |
                                  HAS_CMD(kCommandTag_FlashEraseAllUnsecure) | HAS_CMD(kCommandTag_ReceiveSbFile))
*/
    kCommandsAllowedWhenSecure = (HAS_CMD(kCommandTag_FlashSecurityDisable) | HAS_CMD(kCommandTag_GetProperty) |
                                  HAS_CMD(kCommandTag_Reset) | HAS_CMD(kCommandTag_SetProperty) | 
                                 HAS_CMD(kCommandTag_ReceiveSbFile) | HAS_CMD(kCommandTag_FlashEraseRegion) | 
                                 HAS_CMD(kCommandTag_WriteMemory)) 
};

  Then your Erase All to unlock in the KinetisFlashTool can work?

  I tried this point, it can't work on my side.

Have a great day,
Kerry

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

2,617 Views
dusek_martin
Contributor IV

Yes, I modified that (for me it is on line 117, I use NXP_Kinetis_Bootloader_2_0_0).

No, you can't do erase all to unlock, this operation is not allowed.

I just select update file and perform update. Sector erase operation and flash write is allowed.

0 Kudos
Reply

2,617 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Martin,

   You are right, if not select the erase all to unlock, it works ok, this is my test result:

pastedImage_1.png

You can use it now.

Thanks a lot for your effort.


Have a great day,
Kerry

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

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply