Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 Hello, We have encountered a HardFault while performing IVT fusing and a Lifecycle transition on the S32K328 using HSE Firmware 2.40.0 (AB_SWAP). We would like to ask for your assistance in investigating this issue. 1. Development Environment MCU: S32K328 HSE Firmware: S32K358_HSE_FW_2.40.0 (AB_SWAP) 2. Issue Description We implemented a function that sequentially performs IVT fusing followed by a Lifecycle transition to IN_FIELD. During testing, we observed the following behavior: A HardFault occurred during the first function call. After the MCU was reset, we confirmed that IVT fusing had been completed, but the Lifecycle had not been changed. When the same function was called again, another HardFault occurred. After the MCU was reset, we confirmed that the Lifecycle had been changed to IN_FIELD. The memory placement of the Hse_Ip_ServiceRequest function, its subordinate functions, and related data that we have identified so far is as follows: 004117a4+000378 .mcal_text Hse_Ip.o
21006cac+000008 .mcal_bss Hse_Ip.o
00411ca8+000008 .mcal_const Hse_Ip.o
00411b1c+00003e .mcal_text OsIf_Timer.o The above information covers only the items identified so far. Additional subordinate functions and related data may also be involved. For reference, our test environment is configured as a single-core, bare-metal system using synchronous service requests. No other operations are performed during this procedure apart from the service requests. We previously performed the same operation on the S32K314, and it completed successfully without any issues. Although the detailed memory layout was different, the code was also located in Flash Block 0 at that time. 3. Questions Q1. Possibility of Flash Read-While-Write (RWW) Conflict During UTEST Programming We suspect that an RWW conflict may occur while the HSE is programming the UTEST area during either IVT fusing or the Lifecycle transition, which is performed through the HSE_SRV_ID_SET_ATTR service. Specifically, the Host Core may be executing code from Flash Block 0 while the HSE is programming UTEST, resulting in an RWW conflict and subsequently a HardFault. Could you please confirm whether this is a valid explanation for the observed behavior? Additionally, could you confirm whether the UTEST area belongs to the same RWW partition as Flash Block 0 on the S32K328? Q2. Identifying the Cause of the HardFault and Diagnostic Methods After Reset Since the MCU's Lifecycle state may change each time IVT fusing and the Lifecycle transition are performed, repeatedly using new MCU samples for root cause analysis is not a practical approach. Therefore, we would like to clarify the following: Is there any register or status information that can be used to identify whether an RWW conflict occurred and determine its cause at the time of the HardFault? Is this error information retained after the MCU resets following the HardFault? Are there any Flash Controller status registers, RWW Error Status registers, or other diagnostic methods that can be used to identify the cause even after a reset? If possible, please provide the relevant register names and bit fields that should be checked. Q3. Memory Regions Where Code Execution Is Restricted in the Event of an RWW Conflict If the suspected RWW conflict described in Q1 is the actual cause, we would like to identify the specific memory regions where code execution is restricted during IVT fusing and the Lifecycle transition, since the address range of Flash Block 0 is relatively large. Could you provide the restricted memory regions on a Flash Sector basis (0x2000 bytes per sector)? This would help us distinguish between the regions within Flash Block 0 where code execution is permitted and those where execution is restricted while the relevant service is being performed. Q4. Code That Needs to Be Relocated to SRAM or Another Flash Block to Prevent RWW Conflicts If the suspected RWW conflict described in Q1 is the actual cause, we are considering relocating the relevant code to SRAM or another Flash Block to prevent this issue. Assuming that all Lifecycle transition service requests are performed synchronously, would relocating only the Hse_Ip_ServiceRequest function and its subordinate functions to SRAM or another Flash Block be sufficient? Or would the functions that call Hse_Ip_ServiceRequest also need to be relocated? Additionally, should any constant data referenced during function execution or interrupt service routines (ISRs) also be placed in SRAM or another Flash Block? We would appreciate your review and guidance to help us identify the root cause and prevent this issue from recurring. Thank you for your support. Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 Hi Lukas, Thank you for your detailed explanation. Please find the requested information below. 1. RTD Version SW32K3_S32M27x_RTD_4.4_4.0.0_HF04_D2504 2. OSIF Mode The current test code is configured to use the Dummy Counter (OSIF_COUNTER_DUMMY). However, this configuration is only used for testing purposes and may differ in the actual application. Therefore, could you please provide a complete list of all functions and resources that need to be relocated to RAM during UTEST programming, covering all supported OSIF modes rather than only the current Dummy Counter configuration? 3. Hse_Ip_apMuBase Memory Placement We checked the Hse_Ip.c source code and found that the declaration of Hse_Ip_apMuBase uses the following memory mapping macros: #define CRYPTO_START_SEC_CONST_UNSPECIFIED
#include "Crypto_MemMap.h"
/*! @brief Array of MU base pointers */
static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;
#define CRYPTO_STOP_SEC_CONST_UNSPECIFIED
#include "Crypto_MemMap.h" This differs from the code snippet you provided, which uses CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED and Crypto_43_HSE_MemMap.h. We also checked the map file and confirmed that Hse_Ip_apMuBase is placed in the .mcal_const section within Flash Block 0, at the following address: .mcal_const 00411ca8+000008 Hse_Ip_apMuBase Based on this, accessing Hse_Ip_apMuBase during UTEST programming could also cause an RWW conflict, even if the Hse_Ip_ServiceRequest function itself is relocated to RAM. Could you please check which specific functions and resources need to be relocated to RAM for our RTD version, considering all supported OSIF modes? 4. Additional Questions Regarding RWW Conflict I have a few additional questions regarding the reproducibility and conditions of this issue. 4.1. Reproducibility with the Same Memory Layout If another S32K328 is configured with the same firmware and memory layout, would the same RWW conflict occur consistently? In other words, if the conditions for an RWW conflict are met, should we expect the issue to be reproducible across different S32K328 devices with the same configuration? 4.2. Impact of Differences in Memory Layout Even if the relevant code and data are located in Flash Block 0, could differences in their specific memory addresses or placement affect whether the RWW conflict occurs? For example, could a different placement of Hse_Ip_ServiceRequest, its called functions, or the data they access prevent the issue? 4.3. Impact of Execution Timing Even with the same firmware and memory layout, could the occurrence of an RWW conflict depend on the timing of the service request or other execution conditions? Specifically, does the conflict occur only when the Host Core attempts to access Flash Block 0 while UTEST programming is in progress? 4.4. Reproducibility and Occurrence Frequency Is this issue deterministic under specific conditions, or can it occur intermittently depending on execution timing? In other words, if the same operation is repeated under identical conditions, should we expect the issue to occur every time, or could the occurrence vary between attempts? 5. MCSR Register and RWE Flag You mentioned that the RWE flag in the Flash MCSR register is set when an RWW conflict occurs. However, I could not find a register named MCSR in the reference manual. Could you please confirm whether you are referring to the MCRS register shown in the attached image? Specifically, should we check the RWE bit at bit position 20 (address: 0x402EC004) to determine whether an RWW conflict has occurred? Thank you for your support. Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 Hi @wodudwo
Yes, the behavior you described is most likely caused by an RWW conflict.
On S32K328, UTEST and Flash Block 0 belong to the same RWW partition.
Please also refer to this post, where I explained which resources need to be relocated to RAM when calling Hse_Ip_ServiceRequest():
https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/m-p/2369325/highlight/true#M58774
The exact functions that need to be relocated depend on the OSIF mode being used, and there may also be differences between RTD versions.
There is one additional point to check. The Hse_Ip_apMuBase array used by Hse_Ip_ServiceRequest() may be declared as a constant and therefore placed in Flash, depending on the RTD version:
#define CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED
#include "Crypto_43_HSE_MemMap.h"
/*! @brief Array of MU base pointers */
static MU_Type* const Hse_Ip_apMuBase[HSE_IP_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;
#define CRYPTO_43_HSE_STOP_SEC_CONST_UNSPECIFIED
#include "Crypto_43_HSE_MemMap.h"
If CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED is located in the affected physical Flash Block 0, accessing this array would still result in a Flash read during the restricted period.
As a workaround, the array can be moved to RAM using CRYPTO_43_HSE_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE, with the const qualifier removed.
I have already submitted a feature request to add support for UTEST programming to the Hse_Ip driver, as the current implementation can lead to this type of issue.
If you let me know which RTD version you are using and which OSIF mode is configured (do you use OSIF_COUNTER_DUMMY?), I can check exactly which functions and resources need to be relocated.
If an RWW conflict occurs, the RWE flag in the Flash MCSR register should be set. Please note that this information is not retained across a reset.
While HSE is programming UTEST, neither the UTEST area nor the entire Flash Block 0 can be read.
Operations such as advancing the lifecycle, enabling IVT authorization, and other operations that trigger UTEST programming should therefore be performed in a controlled environment. I recommend keeping interrupts disabled during these operations. Otherwise, all resources used by the interrupt handlers would also need to be located either in another Flash block that remains accessible or in RAM.
Regards,
Lukas
Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 For synchronous Hse_Ip_ServiceRequest() execution from RAM, please place the following functions in RAM:
Hse_Ip_ServiceRequest()
OsIf_MicrosToTicks()
OsIf_GetCounter()
OsIf_GetElapsed()
Additionally, place the functions of the selected OSIF timeout implementation in RAM:
Dummy OSIF: OsIf_Timer_Dummy_MicrosToTicks(), OsIf_Timer_Dummy_GetCounter(), and OsIf_Timer_Dummy_GetElapsed().
System OSIF: OsIf_Timer_System_MicrosToTicks(), OsIf_Timer_System_GetCounter(), OsIf_Timer_System_GetElapsed(), plus the selected system timer backend functions.
Custom OSIF: OsIf_Timer_Custom_MicrosToTicks(), OsIf_Timer_Custom_GetCounter(), and OsIf_Timer_Custom_GetElapsed().
The MU access functions and the memory barrier are inline code. OsIf_Interrupts.c is not used by the synchronous request path.
Hse_Ip_apMuBase is defined as a constant in this RTD:
#define CRYPTO_START_SEC_CONST_UNSPECIFIED
#include "Crypto_MemMap.h"
/*! @brief Array of MU base pointers */
static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;
#define CRYPTO_STOP_SEC_CONST_UNSPECIFIED
#include "Crypto_MemMap.h"
So, change it to:
#define CRYPTO_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE
#include "Crypto_MemMap.h"
/*! @brief Array of MU base pointers */
static MU_Type* Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;
#define CRYPTO_STOP_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE
#include "Crypto_MemMap.h"
Regarding reproducibility – if the startup conditions are always exactly the same (that means simple sequential code, no interrupts etc.), you should see the same result. That’s because the same data and code is cached, the flash read buffers are in the same state etc.
If there’s any indeterminateness, you may see different results. For example, I saw a case when a customer got no hardfault but the life cycle information was not stored correctly to UTEST and LC_ERR flag (Error In Life Cycle Scanning) was set after reset. That means it is important to run that code from RAM or from another flash block as discussed above.
And I’m sorry, that was a typo, it’s Module Configuration Status (MCRS).
Regards,
Lukas
View full article
