S32K312 HSE ABSWAP BOOT_SEQ Write FAIL

[liangyouchao]

S32K312 HSE AB SWAP function, HARD_FAULT problem caused by failure to write Active area IVT BOOT_SEQ after all AB partition TAG writes are complete。

S32K312 HSE FW Version：HSE_FW_S32K312_0_2_40_0
S32K312 RTD Version：PlatformSDK_S32K3_2022_03 v2.0.3

HSE LIB Version:HSE_LIB_0.1.1.0.2

HSW FW INTERFACE:HSE_FW_S32K312_0_2_40_0\hse_ab_swap

Demo Project:

S32K312_SecureBootAppABSwap_EVBQ172_201_350_FW0210

S32K312_SecureBootCfgABSwap_EVBQ172_201_350_FW0210

Error Position:

In addition, I found that using JLINK single-step debugging, delay and wait for a while, can be configured successfully, running at full speed will certainly trigger the Hard Fault!

[DanNguyenDuy]

Hello @liangyouchao,

Follow to the Release Note of the S32K3 RTD 2.0.3 package:

This release was developed on S32K3 parts (for packages refer to chapter 2.3 Supported
Derivatives) and tested on:

HSE firmware release: S32K312: HSE_0.2.6.0 (RTM)

Silicon P32K312NHVPBS 0P09C CTZM2132A.

If you are using S32K3 RTD 2.0.3 package with S32K312 and Crypto driver, you have to use correct "HSW FW" and the silicon chip as above. If not, we are not in charge of any issues will occur.

Best regards,

Dan

[liangyouchao]

Hi, sorry for the late reply, been busy with other things for a while now.
I followed your tips and changed the version of HSE FW to HSE_0.2.6.0, but I still have the above problem, I troubleshooted the cause of the hardware failure and found that the register bit is IBUSERROR, may I ask what is causing this problem.

[DanNguyenDuy]

Hello @liangyouchao,

I got your issue from my side when I debug with T32 debugger.

I guess that most likely the code of UpdateIvt() function was placed on the Flash memory was erased when you call UpdateIvt( BLOCK0_IVT_ADDRESS, BLOCK0_IVT_ADDRESS, SECURE_IVT ); and after that, this cause the hardfault.

From my point of view, to avoid code of this function will be deleted, you can try to put the UpdateIvt() on the other address on Flash or put it on the SRAM for execution.

Best regards,

Dan

[liangyouchao]

Following your hints, I researched the feasibility of running C40_Ip in RAM, and I found that it is possible to run it on the S32K3_RTD_1_0_0_HF01_D2111_ASR_REL_4_4_REV_0000_20211105 version, and so I took the C40_Ip.c from RTD_1_0_0_HF01 and C40 _Ip.h files into the 2.0.3 RTD, and I found that when I debugged in JLINK, the execution was successful,.

```
write_status = HostFlash_EraseByLen(BLOCK0_IVT_ADDRESS , 0x2000);

```

but after I removed JLINK, I found other problems, and the line of code was not executable again when I didn't use JLINK emulation. Is there a problem why the configuration related to C40_RAM_CODE_ENABLE is not carried over to be used in subsequent versions?

[DanNguyenDuy]

Hello @liangyouchao,

Which are the C40_Ip functions put on RAM? And how did you do that?

Best regards,

Dan

[liangyouchao]

I referenced the configuration macros in C40_Ip in RTD version 1.0.0HF01 for the C40 running in RAM:
C40_RAM_CODE_ENABLE.

```

#if ( 1 == C40_RAM_CODE_ENABLE )
/* ram code start */
#define FLS_STOP_SEC_CODE
#include "Fls_MemMap.h"
#define FLS_START_SEC_RAMCODE
#include "Fls_MemMap.h"
#endif

```

[youxi]

Hello @liangyouchao ：

我用s32k312做secure boot，遇到了和您一样的情况，请问您现在解决这个问题了吗？

[DanNguyenDuy]

Hello @liangyouchao,

I can't find out "C40_RAM_CODE_ENABLE" in SW32K3_RTD_4.4_1.0.0, SW32K3_RTD_4.4_1.0.0_HF01 and SW32K3_RTD_4.4_1.0.0_HF02.

About your issue, most likely when you debug the C40_Ip functions can be placed on SRAM. But when you run (not debug) most likely those functions were not placed on SRAM.

Best regards,

Dan