S32K116 Bricked after CSEc Operations

Showing results for 
Search instead for 
Did you mean: 

S32K116 Bricked after CSEc Operations

Contributor I


   Here I have two chip bricked when I erase the chip through J-flash and J-link. After I Configure Part for CSEc operations and load Keys in secrue memory , I erase the chip through J-link, at first I can connect the chip and I select the S32K116 (ALLOW SECURITY) device to erase chip, then it will pop-up a window to tell the RAM* error occured and  disconnect. I can't connect the chip after that. Even I use J-link commander "unlock kinetis",which will told me I unlock the device OK,I can't connect the device anymore.

  I wonder if it is not permitted to  erase the chip when I have configured Part for CSEc operations ,or I need some special operations to do?

Tags (3)
0 Kudos
3 Replies

NXP TechSupport
NXP TechSupport


as mentioned in this application note:



... all keys must be erased to be able to issue flash mass erase. And also the mass erase cannot be disabled (see description of MEEN bit field in FSEC register in the reference manual).

For more details, see section "4.5 Resetting Flash to the Factory State". There's also SW example in the zip file:





Contributor I


    Thanks for your reply. I have recently proved the demerit you mentioned. Here I have two questions

1:I was wondering if I could implement THE AES-ECB functionality using only RAMKEY instead of flash partitioning and building other keys.This will make the process much easier.

2.The encryption result calculated by me according to the routine provided by APP NOTE is inconsistent with the encryption result in  SDK by Freescale Semiconductor. What is the reason?I have changed MASTER_ECU_KEY_VALUE and KEY_1_VALUE according to the SDK to be the same as the SDK.But the results are still inconsistent. Infact, I get the same value as SDK with the pure software algorithm.

Please see the below:

the data in SDK. 

* key = 000102030405060708090a0b0c0d0e0f
* plaintext = 00112233445566778899aabbccddeeff
* ciphertext = 69c4e0d86a7b0430d8cdb78070b4c55a

my result:

KEY_1_VALUE[4] = {0x3020100,0x7060504,0xB0A0908,0xF0E0D0C};

plain_text[4] = {0x33221100, 0x77665544, 0xbbaa9988, 0xffeeddcc};

encrypted_text[4] = {0xAD5ADBEE,0x87C76183,0x604E3A70,0x5B16B98B}

0 Kudos

NXP TechSupport
NXP TechSupport


1. No, that's not possible. Partitioning needs to be done. If the partition command is not executed, CSE commands will return '0' which means the command was not performed.



After some investigation, I found out that the result depends on interpretation of input values.

SHE specification provides test vectors which can be used for comparison of the results and which I used for my test.

For CMAC, the values are:


KEY      2b7e151628aed2a6abf7158809cf4f3c

MESSAGE    6bc1bee22e409f96e93d7e117393172a

OUTPUT    070a16b46b4d4144f79bdd9dd04a287c


AN5401SW expects that the numbers are provided in this form:

uint32_t key[4] = {0x2b7e1516, 0x28aed2a6, 0xabf71588, 0x09cf4f3c};

uint32_t data[4] = {0x6bc1bee2, 0x2e409f96, 0xe93d7e11, 0x7393172a};


And SDK driver expect this format:

uint8_t key[16] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6, 0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c};

uint8_t data[16] = {0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a};


The data are then stored in different order in the memory.


AN5401SW then works with the data as with 32bit words, SDK driver works with the data as with 8bit words, so the input data are swapped by the driver and the result is then also swapped.

If I follow this requirement, I’m getting correct result.