NXPs32k312 HSE reset issue

[Anitha7]

Hi, @lukaszadrapa 

Solved: Re: NXP s32k312 HSE Reset Issue - NXP Community

We are currently using RTD 4.0.0 and do not have the option to upgrade to a newer version. To address the HSE reset issue occurring without a debugger connection, we implemented the following solution 1 based on your earlier suggestion:

Solution 1:

/* Before configuring HSE_CLK and accessing the CONFIG_REG_GPR register,
the driver should wait for Secure BAF to enter WFI state by checking
the PRTN0_CORE2_STAT register. */
do {
WfiStatus = (BOARD_MC_ME->prtn0_core2_stat & MC_ME_PRTN0_CORE2_STAT_WFI_MASK);
} while (WfiStatus != MC_ME_PRTN0_CORE2_STAT_WFI_MASK);

This solution is implemented during clock initialization to ensure proper reset behavior without the debugger.

However, the NXP community also suggests an alternate approach:

Solution 2:

#define MU_FSR_ADDRESS (volatile os_uint32_t*)0x4038c104U
#define HSE_INIT_OK_SHIFT 24U
#define UTEST_HSE_ENABLED_ADDRESS (volatile os_uint32_t*)0x1B000000U
#define UTEST_HSE_ENABLED_DEFAULT 0xFFFFFFFFU

if (UTEST_HSE_ENABLED_ADDRESS != UTEST_HSE_ENABLED_DEFAULT)
{
board_waitforHSEinit();
}

void board_waitforHSEinit(void)
{
volatile os_uint32_t* Mu_FSR_Address = MU_FSR_ADDRESS;
while (((*Mu_FSR_Address >> HSE_INIT_OK_SHIFT) & 0x01) != 0x01U);
}

Although both solutions resolve the reset issue without a debugger, we are concerned that in Solution 2, if the HSE status bit is unexpectedly corrupted or never set (e.g., due to hardware fault), the software could get stuck indefinitely in the while loop.

Could you please advise which of these two approaches is more appropriate and robust for handling HSE reset issues without debugger support?

[lukaszadrapa]

Hi @Anitha7 

You should do both. The WFI says if it is already possible to configure clocks. HSE_STATUS_INIT_OK says, if HSE was successfully started and you can start using HSE services. If the status bit is not set, HSE firmware may be corrupted and user's action is required. Read section "14.6.7 HSE Firmware Handshake" in HSE firmware reference manual for details. 

Use a timeout when waiting for HSE_STATUS_INIT_OK. It may take up to approximately 1s after AB SWAP until the flag is set. That's because HSE takes backup of itself to passive partition. I recommend timeout about 1.3s.

Regards,

Lukas

[Anitha7]

Hi, @lukaszadrapa 

Thank you for your response.

I have a few points that I would like to clarify:

1. If we apply Solution 1 and Solution 2 externally with RTD 4.0.0, could this lead to any additional issues?

2. In the case of HSE firmware corruption, is there any automatic recovery mechanism available without relying on external recovery methods or debugger intervention?

3. Is the reset issue (without using a debugger) addressed internally as part of the improvements in RTD 5.0.0?

4. We are using the EB stack, which implements its own clock configuration using RTD 4.0.0.

5. Even when a valid HSE image is present, if the HSE status flag bit is cleared (we observed this issue), Solution 2 causes the code to get stuck in a loop.

6. we added WFI and HSE status Flag checking solutions during clock initialization stage

Could you please provide a clear and stable solution for handling the reset issue without a debugger, specifically for RTD 4.0.0, as we currently do not have the option to upgrade to a newer RTD version?

[lukaszadrapa · Accepted solution]

1. If we apply Solution 1 and Solution 2 externally with RTD 4.0.0, could this lead to any additional issues?
   
   - I can’t see other issues.  
   
   
2. In the case of HSE firmware corruption, is there any automatic recovery mechanism available without relying on external recovery methods or debugger intervention?
   
   - This can be still solved by software without debugger. The software should follow handshake procedure (in fact, it’s just a triggering of several resets while checking if HSE works). If handshake procedure is not successful, the firmware must be installed again which can be also done by software only.  
   
   
3. Is the reset issue (without using a debugger) addressed internally as part of the improvements in RTD 5.0.0?
   
   - This is not a known problem, first we have to identify the source of your troubles.  
   
   
4. We are using the EB stack, which implements its own clock configuration using RTD 4.0.0.
   
   - What is your HSE_CLK? If you do not use secure boot, it should be set to 60MHz.  
   
   
5. Even when a valid HSE image is present, if the HSE status flag bit is cleared (we observed this issue), Solution 2 causes the code to get stuck in a loop.
   
   - If HSE_STATUS_INIT_OK is not set, there’s something wrong with HSE firmware and handshake procedure must be started.  
   
   
6. we added WFI and HSE status Flag checking solutions during clock initialization stage
   
   - Ok.  

Let me ask again what I already asked in previous thread:
Have you tried to attach your debugger (I mean hot-sync without reset) after the fail to see what happened? Just reset the MCU externally, so it does not run in debug mode and try to attach the debugger afterwards.