S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure

Kishore_14 · ‎11-24-2025

Hardware: S32K144 Development Board
IDE: S32 Design Studio
Programming: Direct via S32DS

Issue Description:

I successfully implemented CSEc secure boot on S32K144 with the following steps:

Configure keys - Set up MASTER_ECU_KEY and BOOT_MAC_KEY
Flash application in flash region - Used Debug_FLASH configuration via S32DS
Set up secure boot - Used Debug_RAM configuration via S32DS to store BOOT_MAC
After reset - Secure boot working properly
Application working - Confirmed with LED indication, BOK=1

Problem:
When testing negative case (failure scenario):

Try to flash different application in flash region → "Device is secure. Erase to unsecure?" dialog appears
Click "Yes" to erase → Same dialog keeps appearing repeatedly
Tried factory reset → Still same error
Cannot flash any new application

Questions:

Is clicking "Yes" supposed to perform mass erase automatically? Why does dialog keep reappearing?
How to properly unsecure the device using S32DS only? What's the correct procedure?
Can I use mass erase command in S32DS? If yes, what's the exact procedure?
Is device permanently locked? Or is there a recovery method via S32DS?

Current Status:
Device appears stuck in secure state. Cannot flash any applications using S32DS. Need step-by-step recovery procedure to unsecure the device.

lukaszadrapa · ‎11-25-2025

Hi @Kishore_14

Which secure boot mode did you configured? There's sequential mode, parallel mode or strict sequential mode.

If sequential or parallel boot mode fails, the only consequence is that boot protected keys cannot be used. That's the only effect, it does not affect your application, it's still executed.

If strict sequential boot mode fails, the device stays in reset forever and there's no way to recover.

Did you check the reset signal? Is it released after power-on?

Also once CSEc is enabled, mass erase (Erase All Blocks command) is locked:

To enable mass erase, it is necessary to erase all keys by CMD_DBG_CHAL and CMD_DBG_AUTH commands with knowledge of MASTER_ECU_KEY.

Regards,

Lukas

Kishore_14 · ‎11-25-2025

Which secure boot mode did you configured? There's sequential mode, parallel mode or strict sequential mode.

If sequential or parallel boot mode fails, the only consequence is that boot protected keys cannot be used. That's the only effect, it does not affect your application, it's still executed.

If strict sequential boot mode fails, the device stays in reset forever and there's no way to recover.

ANS: Using the S32K144_CSEc_Secure_boot_add_boot_MAC_Manual example from AN5401sw, we configured serial secure boot with boot mode 1 in the BOOT_DEFINE() function. if boot mode 1 corresponds to strict sequential boot mode, this would explain the permanent reset behavior we're experiencing."

/* Step-3 Define the secure boot flavor and the BOOT_SIZE*/

csec_error = BOOT_DEFINE(128*1024*8, 1);

"

Did you check the reset signal? Is it released after power-on?

ANS: Yes, I have checked the reset signal. The reset signal remains active (reset LED stays on) after power-on, indicating the device is still in resetting state

Also once CSEc is enabled, mass erase (Erase All Blocks command) is locked:

To enable mass erase, it is necessary to erase all keys by CMD_DBG_CHAL and CMD_DBG_AUTH commands with knowledge of MASTER_ECU_KEY.

ANS: When attempting to flash AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State, I receive "Device is secure. Erase to unsecure?" dialog. Even after clicking "Yes", the same dialog keeps appearing repeatedly

S32DS has "Emergency Kinetis Device Recovery by Full Chip Erase" option. Should we use this to recover the device?

Note:
We don't have the debugger setup for flashing and erasing. We are using S32DS for flashing and debugging. Hence need assistance on mass erase.

lukaszadrapa · ‎11-25-2025

Strict sequential boot mode is configured when Boot Flavor parameter is set to 0:

But it does not make sense if you kept original sequential boot:

/* Step-3 Define the secure boot flavor and the BOOT_SIZE*/
csec_error = BOOT_DEFINE(128*1024*8, 1);

Even if sequential boot fails, this should definitely not cause permanent reset. Did you try to check the signal by an oscilloscope or did you watch the LED only? Isn't the reset signal toggling?

If the reset signal is asserted permanently, I'm afraid there's no way to recover.

Kishore_14 · ‎11-25-2025

As observed directly, LED is not toggling,, It is permanently on.

If it is Sequential boot mode, What could be the possibility that the device is on continuous reset when a new application is flashed?

How will the device get Secured when all the Flashconfig settings in the examples are as below:

/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF /* 8 bytes backdoor comparison key */
.long 0xFFFFFFFF /* */
.long 0xFFFFFFFF /* 4 bytes program flash protection bytes */
.long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = unsecured) */

Can i try Kinetis option for mass erase since no direct debugger flashing possible due to unavailablity.

Note: We also observe this case for another board and posted in below link:
error: Device is secure. Erase to unsecure - NXP Community

lukaszadrapa · ‎11-26-2025

Toggling on the reset pin can be so fast that it might not be visible to the naked eye. And that’s why I asked if you tried it with an oscilloscope.

I can see only two reasons for permanent reset:
1. Failed strict sequential boot mode.
2. Hardware issue - typically insufficient voltage, so voltage monitors does not allow to start the device...

There's no way how to force the device to permanent reset by (wrong) application. This could only be done in some kind of self-destructive way, for example by setting a GPIO to short-circuit or something similar.

The message "Device is secure. Erase to unsecure?" is just general one. Most of the time, this usually means that the debugger was not able to establish the connection ever. And in this case, even if the device is secured, it would not be possible to unsecure it because mass erase operation is blocked by enabled CSEc module.

Kishore_14 · ‎11-27-2025

hi,
Toggling on the reset pin can be so fast that it might not be visible to the naked eye. And that’s why I asked if you tried it with an oscilloscope.
Did you check the reset signal? Is it released after power-on?

Ans: we observed that reset pin is toggling.

Does it mean that the previous application flashed is stuck in any SW /WDG reset?
can it be recovered via SWD debugger flashing?

lukaszadrapa · ‎11-27-2025

Do you have Segger J-Link probe or Lauterbach debugger to read MDM-AP? Unfortunately that's not possible with Pemicro.

There's a rare scenario when the device can be locked. Please check this thread:

https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227

To confirm it, it's necessary to read MDM-AP.

Kishore_14 · ‎11-27-2025

Unfortunately, we dont have JLink or PE Micro for flashing.
We use S32DS OpenSDA for Debugging.

Below was mentioned from AN12130,
When launching program partition command (PGMPART), be sure to allocate CSEc key size to value different than zero.
• Program CSEc keys, at least the MASTER_ECU_KEY.
• 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.
If any CSEc key is ‘write-protected’ the above procedure will not work thus mass erase cannot be launched.

QUestion: When we flashed a different application, it flashed successfully in the first attempt.
Since the above said sequence is not followed, upon next reset, new application might got into continuous resets? IS this right ?

lukaszadrapa · ‎12-01-2025

OpenSDA is also from Pemicro.

Normally it is possible to program new application by OpenSDA even if CSEc is enabled, even if some keys are write protected etc. That's because it erases the flash block by block, not via mass erase. I meant that AN12130 talks about issues like this:

So, these are rather issues when something goes wrong during the programming - unexpected reset or something like that.

Unfortunately the only way to confirm such state is to read mentioned MDM_AP register. Then we could say if the device is locked permanently or not. But the register cannot be read by OpenSDA.

Regards,

Lukas