Preliminary information:
- I am using the Tasking v6.3r1p5 compiler.
- I am using tricore TC3E7 controller with FS2633D SBC ext wdg NXP.
- The reaction of the SBC was set to zero to avoid resets during development and debugging
- SBC is having debug voltage on the Vdbg pin.
Good morning community,
I have a couple of question regarding the behavior of the FS26 SBC peripheral from NXP.
1. After following the procedure reported in the datasheet, I was able to successfully drive the SBC into normal mode.
After verifying that the fault error counter is zero and writing the exit debug mode flag, along with the procedure to release the safety outputs writing the RELEASE_FS0B_FS1B register, I can see that the SBC state is actually in normal mode (0xB).
Since my goal is to reach the stand-by mode before shutting down the microcontroller, I need to verify that the SBC is not reporting any error. Analyzing the FS_GRL_FLAGS register, I can see that the FS_WD_G flag is set which indicates some error on the watchdog refresh. Following the FS_DIAG_SAFETY1 register indicated in the SBC datasheet, I get the LBIST BYPASSED and BAD_WD_TIMING flags.
I read those two registers in a periodic task each 20ms and the FS_GRL_FLAGS register is not showing any error until i go to normal mode.
Does this indicate some type of problem with the SBC which can cause complications when driving it to the stand-by mode? Why is it happening?
2. Only after driving the SBC in normal mode, when resetting the MCU via debugger using the PORST line (shared between PORST pin on the MCU and RSTB pin on the SBC, driven to low), I get an hard reset coming from the SBC on the PORST line after 256ms which is exactly the watchdog window (please see image).
This does not happen when the SBC is in 'safety output not released' state but only after moving to normal mode.
I am able to successfully reset the MCU by sending continuous in-target reset commands from the debugger for approximately 2s. After starting the MCU again clicking 'go', the SBC seems to be starting from initFS and ending up in 'Safety output not released (0xA) again indicating that keeping the RSTB low for a certain amount of time seems to somehow reset the SBC. I've seen from the datasheet that we can end up in deep fail safe by keeping the RTSB line low but this requires a full 8s so this may not be the case.
I'm not sure why this is happening since the SBC watchdog was configured to have WD_FS_REACTION to zero and indeed I'm not getting any hard reset when debugging normally but it seems like the SBC is ending in some state, unknown to me, that makes it bypass the reaction configuration.
I inspected the datasheets about those two points but couldn't find any information regarding those behaviors and I thought you may have some information.
Thank you for your support.
Hi Alessandro,
In Debug mode, the INIT FS window is infinite and the WD window is fully opened meaning WD timing errors are not taken into account (the watchdog error counter will not be incremented).
If Debug mode is exit, and RSTB is asserted, the FS26 goes back into INIT FS state and a new 256ms window opens. During this period a good WD refresh is needed, otherwise an INIT FS timeout will occur, the fault error counter will be incremented by 1 and a new INIT FS window will be re-opened.
The two below sequences can be used to release the FS26 safety output(s) in Debug mode, once in INIT_FS state after the power-up sequence completion.
For more information, I would recommend to take a closer look at our AN13850 - NXP FS26 Implementation and Behaviors (Secure File requiring an NDA) or reach out to our local FAE based in Milan, Italy.
BR, Tomas
Hi @TomasVaverka, thank you for your clarification!
Your reply triggers another question: After going back to INIT_FS, why are we still in normal mode if we exit the Normal Mode Safety Outputs released? Is the concept of normal mode parallel to the safety states? I would expect the SBC to "restart" in debug mode when going back to RSTB Released.
I will also check the file you mentioned, thanks!
