Why does my MK02F12810 security not work?

[atilla]

I made the following change to my   devices/MK02F12810/gcc/startup_MK02F12810.S:

    .section .FlashConfig, "a"
#ifdef DEBUG
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFE
#else
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFFF
    .long 0xFFFFFFF4
#endif

I can confirm that the MCU is secured, as when I try to reflash, I have to ask for a mass erase, block erase doesn't work, as expected.

The unexpected part is, when I make a "release" build, the MCU doesn't start up. It doesn't give any life signs.

When I do a release build with the security bytes 0xFE, everything works as expected.

Where can I have a look? What might be wrong?

[mjbcswitzerland]

Hi

What happens if you try 0xffffffff instead of 0xfffffff4?

Regards

Mark

[atilla]

0xffffffff also locks up. I would debug but the point of enabling security is disabling the debug port.

We are using SDK 2.3 for gcc on Linux.

[kerryzhou]

Hi Atilla Filiz ,

  Please try the unsecured release version, whether that works or not?

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

[atilla]

Hi Kerry

The unsecured version (when FSEC = 0xFE) of the application works perfectly without any issues.

[kerryzhou]

Hi Atilla Filiz,

    Thank you for your updated information.

    What's the IDE you are using? You can change the IDE optimization, not set it to the highest in the release version, then try it again.

  Any updated test result, 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.
-------------------------------------------------------------------------------

[atilla]

Hello Kerry

We are not using any IDE. We tried gcc 6.3.1 and 7.3.1

We normally compile with -Os optimization. I removed the optimization flag, and it still behaved exactly the same. Here are the other flags

CPUFLAGS := -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

CFLAGS   := -DCPU_MK02FN64VLH10 -DFSL_RTOS_BM -DSDK_DEBUGCONSOLE=0 \
            -DUSE_STRICT_SBRK=1 -DDEBUG -g -Wall -fmessage-length=0 \
            -fsigned-char -funsigned-bitfields -ffunction-sections \
            -fdata-sections -fno-common -ffreestanding -flto

Removing -flto did not fix the issue either.

[mjbcswitzerland · Accepted solution]

Atilla

I propose you do the following:

1. In you application have a function that you can call to print out the flash config bytes in Flash so that you are sure what is programmed there.

2. Make a version with the security byte set to 0xfe so that it runs.

3. Add a command to allow you to change the security value during run time as follows:
- Copy the content of the first Flash sector to a RAM buffer
- Disable interrupts
- Erase the first sector
- Modify the value of the security byte in the RAM buffer to add the security setting you wish to have
- Program the RAM buffer back to the first sector if Flash
- Re-enable interrupts
- Use the first command to read back the vale that is programmed to be absolutely sure
(make sure the code controlling the programming is not in the first sector so that it can operate normally)

Presently the security is not yet active but the program will be operating

4. Reset the board and if it runs check the programmed value again with the first command.

If this works it points to a debugger/programmer problem that doesn't allow programming the security byte as desired and caused other issues in the process. I have had similar things with certain security values that I had to avoid using.

Regards

Mark

[atilla]

Hi Mark

I put the test you mentioned on hold due to the effort it takes, it is definitely something I need to test in the future.

However, I did a simpler test. Instead of using pyocd + a CMSIS-DAP debug probe (A FRDM-k22f board), I used a PEMicro Cyclone to flash the image. With PEMicro, the device indeed works in secure mode as intended.

mjbcswitzerland kerryzhou If you have any ideas what might be wrong with my probe or pyocd, I would love to hear.