Destructive Reset does not occur after Secure function

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

Destructive Reset does not occur after Secure function

Jump to solution
1,006 Views
sochoi
Contributor III

void ForceDestructiveReset(void)
{
MC_ME->MODE_CONF = 0x00000002;
MC_ME->MODE_UPD = 0x00000001;
MC_ME->CTL_KEY = 0x00005AF0;
MC_ME->CTL_KEY = 0x0000A50F;


while (1) {}
}

We have observed that the following software reset logic (e.g., ForceDestructiveReset()) was functioning correctly when all secure functions (such as Secure Boot, Secure Debug, and Lifecycle state like HSE_LC_IN_FIELD) were disabled.

However, after enabling the secure functions, the same reset code no longer works. This issue is currently blocking our FOTA (Firmware Over-the-Air) functionality, since we can no longer reliably trigger a system reset from software.

We are seeking advice on this issue:

Could you provide any insights into why the Destructive Reset via MC_ME may be failing under secure lifecycle conditions?

Alternatively, are there other recommended approaches to perform a software-triggered reset in this lifecycle (e.g., HSE command, watchdog, or any other method)?

Please note: we do not consider this a security-related reset, but rather a general-purpose software reset requirement.

We would appreciate any suggestions or best practices to resolve this situation.

0 Kudos
Reply
1 Solution
694 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Anyway your sequence triggers functional reset, not destructive as you may need.

davidtosenovjan_0-1751446111115.png

 

View solution in original post

0 Kudos
Reply
7 Replies
966 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Which specific device is this question related to?

0 Kudos
Reply
919 Views
sochoi
Contributor III
We are using S32K312.
0 Kudos
Reply
870 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Could you also specify used RTD and HSE FW version?

0 Kudos
Reply
859 Views
sochoi
Contributor III
The HSE FW(full_memory) in use is s32k312_hse_fw_0.13.0_2.40.0_pb230730.

The RTD information used by mcal_MCU is shown below.
* Autosar Version : 4.7.0
* Autosar Revision : ASR_REL_4_7_REV_0000
* Autosar Conf.Variant :
* SW Version : 3.0.0
* Build Version : S32K3_RTD_3_0_0_P01_D2303_ASR_REL_4_7_REV_0000_20230331

I look forward to your reply.
0 Kudos
Reply
768 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

I don't see any direct relation between option to initiate SW reset and device's LC unless your application set up any kind of restriction according LC. How the issue manifests actually? You only described "it does not work". Do you some exception what exactly?

0 Kudos
Reply
702 Views
sochoi
Contributor III
We have not explicitly configured any reset-related restrictions based on the device's lifecycle state (LC).
However, in case such restrictions were implicitly applied or exist by default under secure lifecycle modes (e.g., HSE_LC_IN_FIELD),
could you kindly suggest any alternative ways or best practices to reliably trigger a software reset (including destructive reset) in this LC state?

Even if some reset restrictions are in place, is there a recommended method—such as using HSE services, watchdog, or another mechanism—to perform a general-purpose software reset?

Any guidance would be greatly appreciated
0 Kudos
Reply
695 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

Anyway your sequence triggers functional reset, not destructive as you may need.

davidtosenovjan_0-1751446111115.png

 

0 Kudos
Reply