S32K144 Security Configuration - How to Change from Secure to Completely Unsecured

[Kishore_14]

Hi,

I have tested the S32K144 backdoor key example project and need guidance on changing the security configuration.

Current Situation:

1. Flashed Example_S32K144_Verify_Backdoor_Access_Key_S32DS1.3_v2 project with secure debug enabled
2. After flashing, popup appeared: "device is secure, erase to unsecure" in s32 ds.
3. On every reset: Red LED turns on first (secure), then Blue LED turns on (unlocked via backdoor key)
4. This behavior is working as expected

Currently the startup file has:

.long 0xFFFF7FBF /* FSEC = 0xBF (secured with backdoor key enabled) */

I want to change to:

.long 0xFFFF7FFE /* FSEC = 0xFE (completely unsecured) */

1. Is simply changing the FSEC value from 0xBF to 0xFE and reflashing the correct procedure

2.Are there any additional steps required when changing from secured to unsecured configuration?

Please confirm if this method is correct.

Thanks.

[Kishore_14]

Hi @danielmartynek ,

I understand that CSEc can block mass erase regardless of FSEC.

However,

1.When I program FCCOB5 in the flash region, the DEPART value updates as expected. But when I try to erase using CMD_DBG_CHAL and CMD_DBG_AUTH commands in the same flash region, the DEPART value does not get erased or reset. Why is this happening?

2. If mass erase is blocked by CSEc, can the PEmicro debugger  (using standalone PEmicro software tools, not S32DS) still perform a mass erase, or will it also be blocked by the CSEc engine?

Thanks.

[danielmartynek]

Hi @Kishore_14,

There are no other steps.

If mass erase is enabled (FSEC[MEEN]).

You can mass erase the MCU, which will remove the security.

After the Mass erase, the flash configuration field is in this state:

All 0xFF but the FSEC[SEC] = 0xFE.

Regards,

Daniel

[Kishore_14]

hi @danielmartynek 

First flash:

.long 0x76543210 /* Backdoor key */
.long 0xFEDCBA98
.long 0xFFFFFFFF
.long 0xFFFF7FBF /* FSEC=0xBF: Secured with backdoor enabled */

Result: Device correctly secured, backdoor functional

Second flash :

.long 0xFFFFFFFF /* No backdoor key */
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFF7FFE /* FSEC=0xFE: Should be unsecured */

Result: Device shows "Device is secure. Erase to unsecure?" - remains locked

• "Device is secure. Erase to unsecure?" popup appeared multiple times
• Clicked "Yes" repeatedly on each popup occurrence
• After multiple erase attempts, device no longer enters debug mode
• Device behavior confirms it's still executing original 0xBF secured configuration
• LED confirmation: Red LED glows first, then blue LED glows (matches 0xBF behavior)

1. Is the device now permanently locked due to failed erase attempts?
2. What recovery procedure exists for devices in this state?

Thanks.

[Kishore_14]

Additional Detail to the above ticket,

After clicking "Yes" on the security erase popup, the following debugger connection error now occurs:

• Cannot flash any firmware to the device after this error
• All programming operations completely fail
• We are using PEmicro OpenSDA debugger (on-board). We do not have access to a dedicated S32 debugger unit. 

We need working recovery procedure to restore device functionality. Kindly assist on that.

[Kishore_14]

in addition to:

In S32 Design Studio, I changed the runtime option to "Attach to running target" and entered debug mode. The FSEC register now shows 0xBE

However, I still cannot flash or program the device.
Why is programming blocked even though mass erase is enabled and the device appears unsecure?

[danielmartynek]

Hi @Kishore_14,

The most likely explanation is that CSEc was enabled on the MCU before you programmed this example. Could you check the DEPART register? Its value will indicate whether the MCU has been partitioned. Also, when CSEc is enabled, you cannot access the portion of FlexRAM reserved for CSEc keys.

Once CSEc is enabled, the mass‑erase operation is blocked by the CSEc module.

For more details, refer to:

AN12130 – Production Flash Programming Best Practices for S32K1xx MCUs.

https://www.nxp.com/docs/en/application-note/AN12130.pdf

3.2.5.2 Mass erase and CSEc considerations

Regards,

Daniel

[Kishore_14]

hi @danielmartynek 

• We found the DEPART register value is 0xA, which means the FlexNVM is partitioned 
• The FSEC register shows 0xBE mass erase is enabled (MEEN bits = 11b).
• On one board, the device is secured and cannot be erased so, on another board, I tried to erase using "resetting flash to factory state sdk from an5401" but the DEPART value (0xA) does not change

Questions:

1. If FSEC says mass erase is enabled, why does enabling CSEc still block mass erase? Does CSEc override FSEC?
2. Is the DEPART register/partition permanent? Can it ever be erased or changed back to factory default, or is it one-time programmable?
3. Can the DEPART register value itself block mass erase?
   
   

Thanks.

[danielmartynek]

Hello @Kishore_14,

1.

Yes, regardless of FSEC, if the MCU is partitioned with CSEc keys allocated, mass erase is blocked by the engine.

2.

No, DEPART is reset to its default values after either Mass erase or after the CSEc keys are erased with the CMD_DBG_CHAL and CMD_DBG_AUTH commands.

AN5401: Getting Started with CSEc Security Module

https://www.nxp.com/webapp/Download?colCode=AN5401

Please create a new thread if you need more information about it.

3.

No.

Regards,

Daniel

[Kishore_14]

Hi @danielmartynek 
I understand that CSEc can block mass erase regardless of FSEC.

However,

1.When I program FCCOB5 in the flash region, the DEPART value updates as expected. But when I try to erase using CMD_DBG_CHAL and CMD_DBG_AUTH commands in the same flash region, the DEPART value does not get erased or reset. Why is this happening?

2. If mass erase is blocked by CSEc, can the PEmicro debugger  (using standalone PEmicro software tools, not S32DS) still perform a mass erase, or will it also be blocked by the CSEc engine?

Thanks.

[danielmartynek]

Hello @Kishore_14,

1.

I'm sorry, but I don't understand the question. I'm also not an expert on CSEc, so if you need help with that, please create a new thread.

2.

This is also blocked. As long as the CSEc keys are not erased, the mass‑erase operation is blocked.

Regards,

Daniel