Destructive Reset does not occur after Secure function

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Destructive Reset does not occur after Secure function

ソリューションへジャンプ
1,007件の閲覧回数
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.

タグ(3)
0 件の賞賛
返信
1 解決策
695件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

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

davidtosenovjan_0-1751446111115.png

 

元の投稿で解決策を見る

0 件の賞賛
返信
7 返答(返信)
967件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

Which specific device is this question related to?

0 件の賞賛
返信
920件の閲覧回数
sochoi
Contributor III
We are using S32K312.
0 件の賞賛
返信
871件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

Could you also specify used RTD and HSE FW version?

0 件の賞賛
返信
860件の閲覧回数
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 件の賞賛
返信
769件の閲覧回数
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 件の賞賛
返信
703件の閲覧回数
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 件の賞賛
返信
696件の閲覧回数
davidtosenovjan
NXP TechSupport
NXP TechSupport

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

davidtosenovjan_0-1751446111115.png

 

0 件の賞賛
返信