NXP S32k312 HSE reset issue Understanding

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

NXP S32k312 HSE reset issue Understanding

957 Views
Anitha7
Contributor III

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?

Tags (1)
0 Kudos
Reply
1 Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2157509%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3ENXP%20S32k312%20HSE%20reset%20issue%20Understanding%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2157509%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%2C%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F37795%22%20target%3D%22_blank%22%3E%40lukaszadrapa%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2FOther-NXP-Products%2FNXP-s32k312-HSE-Reset-Issue%2Fm-p%2F2148312%23M29567%22%20target%3D%22_blank%22%3ESolved%3A%20Re%3A%20NXP%20s32k312%20HSE%20Reset%20Issue%20-%20NXP%20Community%3C%2FA%3E%3C%2FP%3E%3CP%3EWe%20are%20currently%20using%20RTD%204.0.0%20and%20do%20not%20have%20the%20option%20to%20upgrade%20to%20a%20newer%20version.%20To%20address%20the%20HSE%20reset%20issue%20occurring%20without%20a%20debugger%20connection%2C%20we%20implemented%20the%20following%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3Esolution%201%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3Ebased%20on%20your%20earlier%20suggestion%3A%3C%2FP%3E%3CP%3E%3CSTRONG%3ESolution%201%3A%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%2F*%20Before%20configuring%20HSE_CLK%20and%20accessing%20the%20CONFIG_REG_GPR%20register%2C%3CBR%20%2F%3Ethe%20driver%20should%20wait%20for%20Secure%20BAF%20to%20enter%20WFI%20state%20by%20checking%3CBR%20%2F%3Ethe%20PRTN0_CORE2_STAT%20register.%20*%2F%3CBR%20%2F%3Edo%20%7B%3CBR%20%2F%3EWfiStatus%20%3D%20(BOARD_MC_ME-%26gt%3Bprtn0_core2_stat%20%26amp%3B%20MC_ME_PRTN0_CORE2_STAT_WFI_MASK)%3B%3CBR%20%2F%3E%7D%20while%20(WfiStatus%20!%3D%20MC_ME_PRTN0_CORE2_STAT_WFI_MASK)%3B%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EThis%20solution%20is%20implemented%20during%20clock%20initialization%20to%20ensure%20proper%20reset%20behavior%20without%20the%20debugger.%3C%2FP%3E%3CP%3EHowever%2C%20the%20NXP%20community%20also%20suggests%20an%20alternate%20approach%3A%3C%2FP%3E%3CP%3E%3CSTRONG%3ESolution%202%3A%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%23define%20MU_FSR_ADDRESS%20(volatile%20os_uint32_t*)0x4038c104U%3CBR%20%2F%3E%23define%20HSE_INIT_OK_SHIFT%2024U%3CBR%20%2F%3E%23define%20UTEST_HSE_ENABLED_ADDRESS%20(volatile%20os_uint32_t*)0x1B000000U%3CBR%20%2F%3E%23define%20UTEST_HSE_ENABLED_DEFAULT%200xFFFFFFFFU%3C%2FP%3E%3CP%3Eif%20(UTEST_HSE_ENABLED_ADDRESS%20!%3D%20UTEST_HSE_ENABLED_DEFAULT)%3CBR%20%2F%3E%7B%3CBR%20%2F%3Eboard_waitforHSEinit()%3B%3CBR%20%2F%3E%7D%3C%2FP%3E%3CP%3Evoid%20board_waitforHSEinit(void)%3CBR%20%2F%3E%7B%3CBR%20%2F%3Evolatile%20os_uint32_t*%20Mu_FSR_Address%20%3D%20MU_FSR_ADDRESS%3B%3CBR%20%2F%3Ewhile%20(((*Mu_FSR_Address%20%26gt%3B%26gt%3B%20HSE_INIT_OK_SHIFT)%20%26amp%3B%200x01)%20!%3D%200x01U)%3B%3CBR%20%2F%3E%7D%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EAlthough%20both%20solutions%20resolve%20the%20reset%20issue%20without%20a%20debugger%2C%20we%20are%20concerned%20that%20in%3CSPAN%3E%26nbsp%3B%3C%2FSPAN%3E%3CSTRONG%3ESolution%202%3C%2FSTRONG%3E%2C%20if%20the%20HSE%20status%20bit%20is%20unexpectedly%20corrupted%20or%20never%20set%20(e.g.%2C%20due%20to%20hardware%20fault)%2C%20the%20software%20could%20get%20stuck%20indefinitely%20in%20the%20while%20loop.%3C%2FP%3E%3CP%3ECould%20you%20please%20advise%20which%20of%20these%20two%20approaches%20is%20more%20appropriate%20and%20robust%20for%20handling%20HSE%20reset%20issues%20without%20debugger%20support%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E