S32K1xx 0x400 security address

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

S32K1xx 0x400 security address

Jump to solution
1,165 Views
ovidiuadrian
Contributor II
Hello all,
 
We are trying to program S32K144 targets via JTAG with OpenOCD.
Right now, we are loading a small firmware in RAM. This firmware will erase program flash memory(using FLASH_DRV_EraseBlock) and wait in a loop to send him data to RAM, if we send any data to him, he will write it to program flash memory (starting with 0x0 and using FLASH_DRV_Program).
The problem is, some of our colleagues are writing data in memory address 0x400 to 0x410. 
From my understanding, if we try to erase and write again, we will lock the controller. Right now, it is something isolated but, in the future, more people will work with security enabled. 
My questions are, can you help us with some way to unlock those controllers? We already have a few samples(for unlocking we can use j-link ultra +), we also tried this and didn't work in our case.
Also, I have to find a way to not touch that area of memory in our programming process, can you help me with some steps in this direction? 
"Erase Keys by issuing CMD_DBG_CHAL and CMD_DBG_AUTH commands. The CMD_DBG_AUTH command will erase the data IFR thus erasing the partition code and allow mass erase to work again."
Can you help me with some extra steps on how to do this ? Can we erase those keys with our firmware ?
From my understanding, when system security is set, and we want to program the memory again we will need to follow the below steps:
  1. Erase the security keys(with our firmware, we need help on how to do it)
  2. Erase program flash.
  3. Program again the application software
  4. Set the security keys back
Is this right ? If not, can you correct please ?
Can we get in contact with someone from NXP to help us with this issue?
 
BR,
Ovidiu
0 Kudos
Reply
1 Solution
1,132 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @ovidiuadrian,

The problem is that when the first sector is erased, the Flash configuration field is erased (FSEC = 0xFF = SECURE, Backdoor = all 0xFF) and the IVT along with the SP and Reset vector is erased too. If something goes wrong and the MCU is reset, the MCU will be secured, and it won't be able to jump to the SRAM where the routines are. It detects a fault exception that is escalated all the way to core lockup (which means System reset on this device). The only way would be to erase the CSEc keys before the Block gets erased, then, Mass erase would be allowed again to unclock it if something goes wrong.

 

Regards,

Daniel

 

View solution in original post

3 Replies
1,143 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hello Ovidiu,

 

Was the CSEc enabled (keys allocated through partitioning) on that MCUs that got locked?

If so, and if the MCU was reset while the first sector was erased (FSEC[SEC] = SECURE), there is no way to unlock it.

There would need to be a code that launches the Backdoor key command, or as you mentioned, the CSEc would have to be disabled by erasing the CSEc keys.

I would recommend keeping the bootloader in the PFlash at the first sector that includes the IVT, Flash configuration field, so that it can't be erased. The rest of the PFlash can be erase using the Erase Sector FTFC command and reprogrammed.

 

I believe your company have FAEs assigned, can you contact them?

 

BR, Daniel

1,135 Views
ovidiuadrian
Contributor II

Hello Daniel,

Thank you for your reply, yes, we have an FAEs assigned, we send him the same text in an email, so far we didn't get any news from him, so if you can put us in contact with someone it is highly appreciated.
We are using erase block and CSEc was enabled. This is bad news for us because we can't test any implementation of the flasher without losing a unit.
We can launch a Backdoor key command or erase the CSEc keys from our RAM firmware. (Having a bootloader in PFlash wont work for us because we use all PFlash)
But I will need some help on how to unlock it before erasing.

0 Kudos
Reply
1,133 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Hi @ovidiuadrian,

The problem is that when the first sector is erased, the Flash configuration field is erased (FSEC = 0xFF = SECURE, Backdoor = all 0xFF) and the IVT along with the SP and Reset vector is erased too. If something goes wrong and the MCU is reset, the MCU will be secured, and it won't be able to jump to the SRAM where the routines are. It detects a fault exception that is escalated all the way to core lockup (which means System reset on this device). The only way would be to erase the CSEc keys before the Block gets erased, then, Mass erase would be allowed again to unclock it if something goes wrong.

 

Regards,

Daniel