MCUXpresso erasing KMS ROM

[christophertsch]

We are in the early stages of development of AC motor hardware using the KV31 MCU with KMS. Our part number is MKV31F512VLL12P. We are trying to use the KMS tool to start off the development and then change and add code for other peripherals. We are using our control boards to debug and have managed to erase the KMS libraries on 2 of the 3 boards. They have all been loaded exclusively using MCUXpresso v10.1.1_606 and JLINK Segger JTAG programmer with KMS 1.2 and SDK 2.3.0. We were aware of all the warnings regarding the dangers of erasing the libraries so we went looking for pertinent check boxes in the debug configuration for the JLINK but found nothing. We have downloaded both KMS and non-KMS projects to all 3 boards, although the board that still has the library intact was probably the least downloaded of the 3.

How can I prevent the debugger from erasing the KMS libraries?

We believe the libraries because the call to GetMotorObserverSecureVersionIsCompatible() returns true and causes the HardFault_Handler() to run on the 2 bad boards.

[philip_drake]

In general the JLINK tools will not do a mass erase unless the MCU is secure (The FSEC bits 1 and 0 are not equal to 'b10). Some of the tools have incorrectly mis-identified the MCU as secure when the FSEC was set to 0xEE, but MCUXpresso and IAR have been fixed. I have not run any test with the JFLASH tool so I cannot attest to it's correct operation.

If you erase the flash config (0x400 - 0x40f)  area of the MCU and perform a reset then the part will be secured since the FSEC is set to 0xFF.  So, you need to complete the re-programming of the flash with the new project, which correctly sets the flash config space after a region erase and before the next reset. If you do end up securing the part without a backdoor key set, then the only way to re-use the MCU for anything is to mass erase it.  That is just how the Kinetis security is designed. This erases the KMS library and the part is no longer able to support KMS. 

You should replace the MCU with another KMS enabled MCU.

Within the KMS reference project is the file flash_config.c

If you want to prevent future mass erase accidents remove the comments brackets around the code like below. Recompile, download with the debugger, reset the MCU and run to application.  If you want to check out what this is doing for you, you can read about the effects of the MEEN bits in the RM.  Basically these setting stop any of the flash tools from doing a mass erase that will remove the KMS library.

/**
* @var KMS_MASS_ERASE_DISABLED
* @brief Use Kinetis FPROT and MEEN to disable mass erase to guard KMS lib.
*/
#define KMS_MASS_ERASE_DISABLED‍‍‍‍‍

Using the memory tool, a read of the flash config space with the IDE shows that the FPROT bits have been set and the FSEC default is set to 0xEE - meaning not secure, but mass erase disabled.

0x00000400  FFFFFFFF FFFFFFFF 7FFFFFFF  ÿÿÿÿÿÿÿÿÿÿÿ.
0x0000040C  FFFFFFEE                    îÿÿÿ‍‍‍‍

[onkarpatil]

I also faced the same issue. Once I used MCUXpresso then my board (MKV31F512VLL12P) was not able to detect to KMS. Going further I tried flashing the firmware using J-Flash but it is not allowing that as well. KMS used is v1.2