s32k144 - Device is secured

[Pranathi06]

Hi Team,

I am working with the S32K114 (AN12323) project. Initially, I flashed the Gateway project with CSEC disabled, and the programming was successful.

After that, I attempted to flash the CAN example application, but I encountered the following error:

"Device is secure, erase to unsecure."

To resolve the issue, I also tried using the "Emergency Kinetis Device Recovery" option, but it did not work.

Could you please suggest how to recover the device or remove the secure state so that I can flash the CAN example?

[Senlent]

Hi@Pranathi06

This issue is unrelated to whether "CSEC" is enabled in "S32K144_FOTA_Gateway" because when testing AN12323SW, your first step should be to download and run "S32K144_Memory_Partition" to perform partitioning, which already enables CSEC by default and assigns a key.

AN12130:

This is why the MCU is locked;

since the solution doesn't provide a reset CSEC operation, it cannot be recovered.

Next time, remember to modify "S32K144_Memory_Partition" to partition only, without enabling CSEC or the key.

[Pranathi06]

Hi @Senlent 

I didn't flash Memory_partition project. 

Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state"

 Is there any solution for recover?

Thanks.

[Senlent]

Hi@Pranathi06

"Before flashing my GATEWAY_PROJECT, I have flashed "Resetting flash to state"

I don't understand your meaning.

The AN12323SW doesn't have a "Resetting flash to state" program.

From what you're saying, you've modified "S32K144_FOTA_Gateway"?

You just need to check if your program has enabled the CSEc module and assigned a key, and whether you've considered restoring the CSEc module to its factory state within the application.

If not, then this situation is unrecoverable.

[Pranathi06]

Hi @Senlent 

I flashed AN5401_S32K144_CSEc_Resetting_Flash_to_Factory_State to erase the keys. After that, I flashed only the GATEWAY_PROJECT; I did not flash the Memory_Partition project.

Thanks.

[Senlent]

Hi@Pranathi06

Is your problem occurring when downloading the "S32K144_FOTA_Gateway" program, or have you already successfully flashed "S32K144_FOTA_Gateway"?

[Pranathi06]

Hi @Senlent ,

Yes, successfully flashed "S32K144_FOTA_Gateway", when I tried to flash Can_example project that time "Device is secured" after that I cannot be able to flash any software.

Thanks

[Senlent]

Hi@Pranathi06

The "S32K144_FOTA_GATEWAY" command doesn't involve any CSEc or flash security related operations, so I'm unsure what you've done to the MCU.

You could measure the waveform of the RESET pin and tell me its reset cycle.

The reset cycle can be used to determine if the chip can recover to normal operation.

[Pranathi06]

Hi @Senlent 

I measured the RESET_b pin waveform using an oscilloscope.

The RESET_b signal is continuously toggling.

• Pulse repetition appears to be roughly 400–500 µs (cursor shows Δt ≈ 475 µs).
• Peak level is around 5 V, which suggests you may be probing an external reset circuit rather than directly measuring a 3.3 V MCU pin, or there is a pull-up to 5 V on RESET.
• The reset activity is continuous and regular.

Thanks

[Senlent]

Hi@Pranathi06

If the reset signal period is not ~118µs, but greater than 200µs, such as 500µs or even longer,

the MCU will not be able to be decrypted and recovered via the SWD/JTAG debug interface using the mass erase command.

[Pranathi06]

Hi @Senlent ,

In which scenarios would the reset signal period be approximately 118 µs, and what factors could cause it to increase to around 475 µs in my case?

Thnaks.

[Senlent]

Hi@Pranathi06

This is based on experience, and your situation is quite similar: the CSEc hardware encryption module was enabled, preventing mass erase of the CSEc encryption key, which caused the problem.

Although the chip has deadlocked, and the MCU can no longer download programs or debug, as long as the chip's power supply is normal, you can still use a J-LINK debugger to connect to the CoreSight DAP debug access interface of the S32K1xx series MCU ARM Cortex M4F/M0+ via the SWD/JTAG debug interface to read the MDM-AP status register.

Therefore, you can determine the root cause of the chip deadlock based on the read MDM-AP status register value.

If you need me to help you pinpoint the cause of the deadlock, you can try using J-LINK to read the MDM-AP status register.