I have try the S32 SAF V1.0.4 example code with RTD V4.0.0
1. The system enter ISR_SWT0 during sCheck xbic test (which the next test after SWT0 count test )(please refer screentshot1)
2. I have try to add breakpoint on SWT0 test. all of count passed(screentshot2). but scheck ISR triggered after SWT0 uninstall (screenshot3)
May I ask if there any suggestion ?
screentshot3
Hi RadoslavB
My sales support team told me there is a bug of SWT0 since RTM 1.0.2 , and RTM 1.0.4 not fixed it.
Thanks for you help.
Hi Sifan,
I need to see your setup during debug session.
Please contact me via NXP Sales Force system, so we can arrange the debug session.
Kind Regards,
Radoslav
Hi RadoslavB
1. Yes, demo example, not modifed on configuration. startup & ld file has update to IAR format
2. I have try to add break pointer on SWT0_ISR first line, but it reboot again & again which seems cause by SWT0 timeout because no ISR handler it ( stop at breakpoint )
3. The WEN are zero when hang on SWT0_ISR trap.
4. I have try to disable SWT0 check via EB, and system won't enter SWT0 ISR.
Hi Sifan,
if I understand correctly, you are executing SAF demo example, did you anyhow modify the code or configuration?
On my side with the Demo example for S32K344 the SWT0 handler is triggered only once during the test as expected. I have all the time FRZ=0.
Could you set breakpoint inside SWT0 handler, first intentional break stop should be during execution of sCheck_Swt_CounterTestRun() during the for loop. The SWT0 is enabled and disabled within Check_Swt_CounterBitCycle(), so beside that part the SWT IRQ should not be triggered.
You can check if WEN bit is really zeroed or if there is still SWT0 interrupt pending bit set even after leaving SWT0 interrupt routine.
Kind Regards,
Radoslav
Hi RadoslavB
1. SWT0 is disabled before the test. also it is disabled when issue occured.
2. AIPS_SLOW_CLK frequency is 40M.
3. Yes, FRZ bit is set to 0 which as same as SAF Demo V1.0.4. I have to try to run without any debugger or without any breakpoint, The system hang on SWT0 ISR "while trap", too.
Hi Sifan,
sCheck does lat1ent faults check, as per ISO26262 it is sufficient to perform the test only once per drive cycle so no need to execute in both startup and runtime/shutdown.
Before the test could you please check the SWT0 CR register if it is really disabled?
Because SBAF bootrom enables SWT0 if it's enabled in Boot Configuration Word, bit APP_SWT_INIT. SAF Demo should disable the SWT0 in startup, but please double check.
Please check if the selected STM instance in sCheck Tresos is really same as it is configured in the RTD MCU driver
And please check also AIPS_SLOW_CLK frequency in RTD MCU (CGM0_MUX0).
The interrupt should be not triggered when disabling the SWT0 (if it was really disabled before the test).
Edit:
If you are using SWT0 setting from the SAF Demo startup, there is FZR bit se to 0 which means that the SWT0 is running even during debug break, so it might happen that if you have breakpoint before the sCheck restore function the timer elapses and trigger interrupt as soon as you continue debugging.
For test purpose you can change the bit setting to 1 manually in the startup by modifying the value as depicted:
Or use RTD WDG configuration with unchecked depicted option:
But for production code you need to have FRZ bit se to 0, this is also checked by the sBoot module as this is recommended safety configuration by NXP.
Kind Regards,
Radoslav
Hi RadoslavB
1. I'm executing the SWT0 test as Starup & Runtime
2.This issure not 100% occured for each time. so Startup may success , but for runtime always hang on ISR trap under continue test.
3.I'm not enable SWT0 . not configure it up & running. Just test it on runtime continue test.
I think it may cause by SWT disable ( when sCheck swt count test done) and SWT interrupt coming at same time, and S32K has few time to uninstall ISR before it handle the interrupt.
Hello Sifan,
please are you executing the SWT0 test as Starup or Runtime/Shutdown?
In case of startup test, sCheck does restore SWT.CR register, so if SWT0 was disabled it should be disabled after the test as well and should not trigger the interrupt.
In case you are executing the SWT0 test in runtime/shutdown it is expected that you have configured the SWT0 so it's up and running and therefore you should have implemented also your handler for refreshing the SWT0, from the screenshot I can see there is just the while trap instead. In this case, please update the interrupt handler and replace the while trap with routine refreshing the SWT0.
Kind Regards,
Radoslav