Hi NXP experts,
I am developing on the S32K388 and using the SPD (Safety Peripheral Drivers) v1.0.6 as a reference to implement the STCU/BIST functionality.
In my main.c, I enable the BIST test and then read the reset reason from MC_RGM. I observe that the reset reason returned is MCU_ST_DONE_RESET.
I have the following questions:
Does the value written to the STCU_WDG register affect the online watchdog timeout duration during BIST execution? In other words, is the WDTOSW flag directly triggered when the BIST execution time exceeds the STCU_WDG value?
When MCU_ST_DONE_RESET is reported, can I conclude that both LBIST and MBIST completed normally and passed? Or does this reset reason only indicate that the STCU sequence finished, regardless of whether a timeout occurred?
In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1 (see attached screenshot). Does this mean the BIST execution timed out and was prematurely terminated/aborted, so the memory tests were actually forced to stop before completion? Or can MCU_ST_DONE_RESET still be generated even if WDTOSW was set?
I also checked the Bist_IntegrityTest() flow from the SPD driver (see attached code screenshot), which expects the LBIST/MBIST end flags (LBESW0/MBESW0) to be set to 1 after completion. However, during my actual debugging, I found that both the LBIST and MBIST end flag bits are 0, not 1. Why would the end flags be 0 even though MCU_ST_DONE_RESET was generated?
Additional context:
- I am using the Safety Boot BIST configuration table similar to the SPD example.
- Observed STCU_WDG value: 0xC35E (49998).
- Observed STCU_ERR_STAT value: 0x80140 (RFSW=1, WDTOSW=1).
Could you please help clarify the relationship between STCU_WDG, WDTOSW, MCU_ST_DONE_RESET, and the LBESW0/MBESW0 end flags?
Thank you in advance.
Best regards,
Hello,
In my main.c, I enable the BIST test and then read the reset reason from MC_RGM. I observe that the reset reason returned is MCU_ST_DONE_RESET.
That is correct behaviour.
1. Does the value written to the STCU_WDG register affect the online watchdog timeout duration during BIST execution? In other words, is the WDTOSW flag directly triggered when the BIST execution time exceeds the STCU_WDG value?
No. STCU_WDG is watchdog for BIST execution. Not connected anyhow to SWT. SWT module is also tested by BIST, so the SWT module is not functional during the BIST. Therefore you guard execution time with STCU_WDG.
When MCU_ST_DONE_RESET is reported, can I conclude that both LBIST and MBIST completed normally and passed? Or does this reset reason only indicate that the STCU sequence finished, regardless of whether a timeout occurred?
You can only conclude that the test procedure ended. Results are stored in different registers like STCU2 Online LBIST Status (LBSSW0) - such will indicate you pass /fail conditions.
In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1 (see attached screenshot). Does this mean the BIST execution timed out and was prematurely terminated/aborted, so the memory tests were actually forced to stop before completion? Or can MCU_ST_DONE_RESET still be generated even if WDTOSW was set?
MCU_ST_DONE_RESET is always generated after test. No matter on the results. As during the test the registers and RAMs are tested with patterns. Reegisters need to be set to the default values - such are loaded during reset. Otherwise you will get all registers full of test patterns and the uC wont operate with such random values.
RAMs need to be initialized by SW as the ECC syndromers will not match data after BIST execute test patterns on the RAMs.
In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1
This means test fails.
I also checked the Bist_IntegrityTest() flow from the SPD driver (see attached code screenshot), which expects the LBIST/MBIST end flags (LBESW0/MBESW0) to be set to 1 after completion. However, during my actual debugging, I found that both the LBIST and MBIST end flag bits are 0, not 1. Why would the end flags be 0 even though MCU_ST_DONE_RESET was generated?
Explained above.
Your BIST did not executed in the STCU_WDG timeout.
Best regards,
Peter
Hello,
let me summarize the answers and I will post them later.
Best regards,
Peter