S32K312 HSE ABSWAP BOOT_SEQ Write FAIL

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

S32K312 HSE ABSWAP BOOT_SEQ Write FAIL

1,192 Views
liangyouchao
Contributor I

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:

liangyouchao_1-1694779735821.png

 

 

liangyouchao_0-1694779505144.png

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!

 

0 Kudos
8 Replies

1,131 Views
nxf78987
NXP Employee
NXP Employee

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

0 Kudos

1,076 Views
liangyouchao
Contributor I

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.

liangyouchao_2-1696996051145.png

 

liangyouchao_0-1696995867866.jpeg

 

liangyouchao_1-1696995878206.jpeg

 

0 Kudos

1,048 Views
nxf78987
NXP Employee
NXP Employee

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

0 Kudos

1,031 Views
liangyouchao
Contributor I
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?
0 Kudos

985 Views
nxf78987
NXP Employee
NXP Employee

Hello @liangyouchao,

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

Best regards,

Dan

0 Kudos

978 Views
liangyouchao
Contributor I

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

```

0 Kudos

817 Views
youxi
Contributor IV

Hello @liangyouchao :

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

0 Kudos

919 Views
nxf78987
NXP Employee
NXP Employee

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

0 Kudos