S32K3_HSE_ERR_GENERAL

wuxianlong

Hi,NXP

My chip(S32K312) has encountered an HSE_ERR_GENERAL error, and the HSE is not working.
HSE_FW :s32k312_hse_fw_1.13.0_2.40.0_pb230730.bin.pink

According to the Error and Warning Management chapter, when reading the GSR register, it is found that bit 0 reports an error, and there are also errors in bit [16~31]. However, this error is parsed internally by NXP.

The manual describes that the HSE_ERR_GENERAL error can be viewed through the address of HSE_GPR_STATUS_ADDRESS (0x4039C02C), but there is no reference significance. Regardless of whether the HSE is normal or not, bit 0 of HSE_GPR_STATUS_ADDRESS will be set.

How should I analyze the problem now? How can I restore my HSE? I tried POR and performing W1C on the GSR register, but both were ineffective.

Best Regards,
xianlong

lukaszadrapa

Hi @wuxianlong

Generally, first step is to check HSE GPR at 0x4039_C028 if bit 0 is set. If bit 0 is ‘0’ after reset, HSE firmware is not present at all, it is erased completely by SBAF due to fatal error.

If the bit 0 in HSE GPR is ‘1’ (HSE FW present) but HSE_STATUS_INIT_OK remains ‘0’ after reset, it means that the firmware is present but it did not start. It’s necessary to start the handshake procedure.

Updated version of HSE Firmware Reference Manual was released recently (version 2.4). It’s slightly updated and clarified in comparison with v2.3.

Take a look at section:

14.6.7 HSE Firmware Handshake

And also at new section:

9.3.2 General use

It depends on HSE and SBAF version how many resets are needed. But even if you have newer versions, more resets can still be needed.

We don’t have sample code for handshake but it should be as simple as this: if HSE GPR bit 0 is ‘1’ (i.e. the firmware is present) but the HSE_STATUS_INIT_OK does not get set, trigger functional reset. SBAF will do the counting of resets/attempts for you, SBAF will restore the firmware from backup if possible or SBAF will erase the firmware completely. Just keep checking the condition above after each reset and keep triggering the functional resets. Once the HSE_STATUS_INIT_OK gets set to ‘1’, it was successful and you can use HSE again. Once the bit 0 in HSE GPR is cleared to ‘0’, it means it was not possible to recover and user is required to install the HSE FW again.

If HSE_STATUS_INIT_OK is set, there’s an option to run HSE_SRV_ID_FW_INTEGRITY_CHECK service which checks the integrity of HSE FW and SYS-IMG.

As described in “10.2.2.4 Code Flash Firmware Integrity Check” in HSE FW RM, it’s highly recommended to run this service after each reset.

If general error is not set right after reset, it's caused by some HSE service which was triggered by your application. Such error usually happens when HSE does not have access to some memory - for example, when you provide wrong pointer to input parameters, when there's double bit ECC error or when HSE does not have access right to that memory due to XRDC settings. In this case, just try to find which service caused the error and check all the parameters of that service.

Regards,

Lukas

View solution in original post

wuxianlong

Hi, NXP

I tried to restore in MU mode. But it did not take effect. After writing 0xA5 and resetting, the Sbaf flag will not be set to 1 and there is no data in MU_RR.（0x4038c280）

Best Regards,
xianlong

lukaszadrapa

Hi @wuxianlong

Generally, first step is to check HSE GPR at 0x4039_C028 if bit 0 is set. If bit 0 is ‘0’ after reset, HSE firmware is not present at all, it is erased completely by SBAF due to fatal error.

If the bit 0 in HSE GPR is ‘1’ (HSE FW present) but HSE_STATUS_INIT_OK remains ‘0’ after reset, it means that the firmware is present but it did not start. It’s necessary to start the handshake procedure.

Updated version of HSE Firmware Reference Manual was released recently (version 2.4). It’s slightly updated and clarified in comparison with v2.3.

Take a look at section:

14.6.7 HSE Firmware Handshake

And also at new section:

9.3.2 General use

It depends on HSE and SBAF version how many resets are needed. But even if you have newer versions, more resets can still be needed.

We don’t have sample code for handshake but it should be as simple as this: if HSE GPR bit 0 is ‘1’ (i.e. the firmware is present) but the HSE_STATUS_INIT_OK does not get set, trigger functional reset. SBAF will do the counting of resets/attempts for you, SBAF will restore the firmware from backup if possible or SBAF will erase the firmware completely. Just keep checking the condition above after each reset and keep triggering the functional resets. Once the HSE_STATUS_INIT_OK gets set to ‘1’, it was successful and you can use HSE again. Once the bit 0 in HSE GPR is cleared to ‘0’, it means it was not possible to recover and user is required to install the HSE FW again.

If HSE_STATUS_INIT_OK is set, there’s an option to run HSE_SRV_ID_FW_INTEGRITY_CHECK service which checks the integrity of HSE FW and SYS-IMG.

As described in “10.2.2.4 Code Flash Firmware Integrity Check” in HSE FW RM, it’s highly recommended to run this service after each reset.

If general error is not set right after reset, it's caused by some HSE service which was triggered by your application. Such error usually happens when HSE does not have access to some memory - for example, when you provide wrong pointer to input parameters, when there's double bit ECC error or when HSE does not have access right to that memory due to XRDC settings. In this case, just try to find which service caused the error and check all the parameters of that service.

Regards,

Lukas

wuxianlong

Hi,@lukaszadrapa

Thank you very much for your information.
I see in the manual that the HSE will judge the EER bit of the MCRS of FLASH. So I enabled PFCR4[DERR_SUP]. Then, after multiple resets, the HSE returned to normal. I don't have other chips to test whether only a reset is needed.

At present, can I understand it this way? The HSE has implemented abnormal recovery measures to prevent the HSE in the chip from hanging. For example, the ECC error of the HSE this time, or even other more serious exceptions.

We just need to perform multiple resets simply. If the exception can be recovered, the HSE can be restored. If it cannot be recovered, the HSE will also be completely erased, allowing us to reinstall it through MU.

Best Regards,
xianlong

lukaszadrapa

... and what is your HSE_CLK? If it is configured to 120MHz, it's necessary to update MISC DCF record in UTEST. Try to set 60MHz to see if it makes a difference (no change in DCF is needed when 60MHz is used).

wuxianlong

Hi,

Add a piece of information: FLASH generated an ECC error.

Best Regards,
xianlong