* ================================================================================================== * Detailed Description: * * This example shows how to implement ADC continuous scan with DMA read. * ADC1 is set to perform continuous scan of 4 channels (S10/S11/S12,S13) with DMA request enabled * for last channel S13. DMA reads respective sequential ADC data registers in one major loop. * * ADC1 channel S10 is connected to board's potentiometer, converted value is used to dim board's LED. * * ================================================================================================== * Test HW: S32K312EVB-Q172 * MCU: S32K312_172LQFP * Compiler: S32DS 3.6.3 * RTD release: S32K3_S32M27x Real-Time Drivers ASR R21-11 Version 6.0.0 * Debugger: On-Board Debugger (J40), Lauterbach * Target: Internal_FLASH * ==================================================================================================   Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.  

**************************************************************************************************** * Detailed Description: * * - CMU errors cannot be injected by any means other than manipulating the CMU thresholds, * except for FXOSC_CLK, which can be physically disrupted on the PCB. * * - CMU_FC_0 (FXOSC_CLK) is configured for **synchronous interrupt** on both LFF and HFF CMU events. * - CMU_FC_3 (CORE_CLK) is configured for **asynchronous destructive reset** triggered only by the LFF event; the HFF event is ignored. * - CMU_FC_4 (CORE_CLK) is configured identically to CMU_3: **asynchronous destructive reset** on LFF only; HFF is ignored. * - CMU_FC_5 (HSE_CLK) can be configured by the HSE_B core only. * Refer to the Reference Manual rev.10, Figure 122. Frequency checking (FC) instances * * - The configuration must be identical in both the MCU MCAL driver and the Clock Configuration Tool (clock details). * - To inject a specific CMU error, define one of the following macros: `INJECT_CMU_0`, `INJECT_CMU_3`, or `INJECT_CMU_4`. * * Behavior After Destructive Reset: * - Following a destructive reset (either `MCU_CORE_CLK_FAIL_RESET` or `MCU_AIPS_PLAT_CLK_FAIL_RESET`), * execution will halt in the `while(wait)` loop. * ------------------------------------------------------------------------------------------------ * Test HW: S32K3X4EVB_Q257 * MCU: S32K344, 0P55A * SDK: RTD 6.0.0 * Debugger: PEMicro Multilink FX * Target: internal_FLASH ****************************************************************************************************

**************************************************************************************************** * Detailed Description: * This code demonstrates how to inject an ECC (Error Correction Code) fault into either DTCM0 * (Data Tightly Coupled Memory) or SRAM0 using the EIM (ECC Injection Module). * * When the processor reads corrupted data from DTCM0 or SRAM0, an ECC error is detected, resulting in: * - A Bus Fault exception raised by the core. * - An error report generated by the ERM (Error Reporting Module), which can also trigger an interrupt. * * By default, the ERM interrupt has a lower priority than the Bus Fault exception. In this example, * the Bus Fault exception priority is intentionally lowered so that the ERM interrupt is serviced first. * This ensures the system can respond to the ERM interrupt before the core's Bus Fault handler executes. * * IMPORTANT: The interrupt vector table must not reside in SRAM0 or DTCM0 when injecting an * uncorrectable ECC fault into these memories. Otherwise, the ECC fault would corrupt the vector * table during a fetch, leading to unpredictable behavior. * Always check the VTOR (Vector Table Offset Register) * to confirm the vector table location before performing ECC fault injection. * * Memory Selection: * You can select which memory to inject the ECC fault into using the following macros: * #define SRAM0 * #define DTCM0 *************************************************************************************************** * ------------------------------------------------------------------------------------------------* * Test HW: S32K3X4EVB_Q257 * MCU: S32K344, 0P55A * SDK: NA * Debugger: Lauterbach Trace32 * Target: internal_FLASH ****************************************************************************************************

***************************************************************************** *Detailed Description: *This example will show you how to configure Sbc_fs23 Driver. *It initialization of Sbc_fs23 with watchdog window disabled. The Sbc_fs23_InitDevice() must be done within the dedicated 256 ms INIT window. *It Disable regulator V2, then re-enable it again. FS0b pin is asserted due to V2 Undervoltage reaction setting configured in FailSafe Init Configuration tab. *If the example runs without errors, the D12 LED on S32K31XEVB-Q100 will light up Green; otherwise, it will light up Red. *The SPI data between FS23 and S32K311 are captured and attached to the project. *Use the analog input of a logic analyzer or an oscilloscope to monitor the signals of FS23_V2 (TP27) and FS23_FS0 (TP8) on the KITFS23SKTEVM board. *------------------------------------------------------------------------------ *Test HW: * S32K31XEVB-Q100 Board SCH-55131 REV A P32K311HV 0P98C * KITFS23SKTEVM Dev-kit SCH-53096 REV B2 MFS2320BMBB1EP * My S32K31XEVB-Q100 has an onboard PFS2320A0L1W1, but Step 13/14 of AN14041 mention that A0 devices are not supported, so S32K311 communicate with the FS23 on the KITFS23SKTEVM. *Connections: KITFS23SKTEVM | S32K31XEVB-Q100 ------------------------------|-------------------- SPI_CSB J28-2 | J12-5(PTB-17) SPI_MOSI J29-2 | J12-7(PTB-16) SPI_SCK J31-2 | J12-11(PTB-14) SPI_MISO J32-2 | J12.9(PTB-15) VCC J6-1 | J40-15 GND J6-2 | J40-13 - KITFS23SKTEVM: SW1 - position 2-3 , J30 - ON, J26 5-6 ON, J26 9-10 ON . - Connect KITFS23SKTEVM Dev-kit and S32K3 MCU via on-board Arduino headers. *SDK: * S32K3 RTD 4.0.0 (SW32K3_S32M27x_RTD_R21-11_4.0.0_D2311_DS_updatesite.zip) * FS23 RTD 1.0.0 (S32K3xx_SBC_FS23_R21-11_1.0.0_D2508_DesignStudio_updatesite.zip) *Debugger: S32DS 3.5.8, OpenSDA/ PEmicro Multilink Universal FX *Target: internal_FLASH *Reference Documentation: * AN14041 FS23 quick start guide (Rev. 2.0 — 23 January 2025) * AN14129 FS23 implementation and behaviors (Rev. 2.0 — 13 December 2024) * FS23, Safety System Basis Chip (SBC) with Power Management, CAN FD and LIN Transceivers Data Sheet (Rev. 8.0 — 30 June 2025) * RTD_SBC_FS23_UM.pdf C:\NXP\S32DS.3.5\S32DS\software\PlatformSDK_S32K3\SW32K3_FS23_R21-11_1.0.0_D2312\Sbc_fs23_TS_T40D34M10I0R0\doc * This example is migrated from Sbc_fs23_example_HLD_S32K344. The method of migrating refers to the video "2.S32DS CT MCAL demo porting K344 to K312 based on RTD500": https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Tools-Part-How-to-port-RTD-s-existing-MCAL-demo-to-other/ta-p/1966315 ***************************************************************************** * Revision History: * Ver Date Author Description of Changes * 0.0 10-26-2025 Robin Shen Initial version * 0.1 11-21-2025 Robin Shen Upgrade FS23 RTD 1.0.0 from S32K3xx_SBC_FS23_R21-11_1.0.0_DS_updatesite_D2402_updated_D250115.zip to S32K3xx_SBC_FS23_R21-11_1.0.0_D2508_DesignStudio_updatesite.zip *****************************************************************************

***************************************************************************** *Detailed Description: *This example will show you how to configure Wdg_fs23 Driver. *Sbc_fs23_InitDriver, Sbc_fs23_GoToInitState, Wdg_43_fs23_Init, Sbc_fs23_InitDevice initialize the Sbc device and external Wdg in SLOW MODE(This mode can e.g. be used during system startup/initialization phase). *Sbc_fs23_InitDevice release FS0B, according to the configuration in Sbc_fs23 WatchdogConfig tab: Release safety outputs after init *Sbc_fs23_TimeDelay delay for an amount of time, allow Gpt ISR to trigger watchdog externally. *Wdg_43_fs23_SetMode(WDGIF_FAST_MODE); switch Wdg operation mode to FAST MODE(This mode can e.g. be used during normal operations of the ECU). *Wdg_43_fs23_SetTriggerCondition(10000U); sets a new timeout value to 10 seconds, during which Wdg_fs23_Cbk_GptNotification0 continuously refresh the watchdog. *To demonstrate the watchdog timeout, Wdg_43_fs23_SetTriggerCondition was not called again to set a new timeout value, and Wdg_fs23_Cbk_GptNotification0 no longer refreshed the watchdog. *The watchdog error counter(WD_ERR_CNT) continues to increase reached its maximum value(WD_ERR_LIMIT), causing fault error counter(FLT_ERR_CNT) to increment by 1. *FS23 eventually enters fail-safe mode because FLT_ERR_CNT >= max. At this point, it was observed that LEDs V1 (D7), V2 (D8), and V3 (D9) of KITFS23SKTEVM were turned off. *The SPI data between FS23 and S32K311 are captured and attached to the project. *------------------------------------------------------------------------------ *Test HW: * S32K31XEVB-Q100 Board SCH-55131 REV A P32K311HV 0P98C * KITFS23SKTEVM Dev-kit SCH-53096 REV B2 MFS2320BMBB1EP * My S32K31XEVB-Q100 has an onboard PFS2320A0L1W1, but Step 13/14 of AN14041 mention that A0 devices are not supported, so S32K311 communicate with the FS23 on the KITFS23SKTEVM. *Connections: KITFS23SKTEVM | S32K31XEVB-Q100 ------------------------------|-------------------- SPI_CSB J28-2 | J12-5(PTB-17) SPI_MOSI J29-2 | J12-7(PTB-16) SPI_SCK J31-2 | J12-11(PTB-14) SPI_MISO J32-2 | J12.9(PTB-15) VCC J6-1 | J40-15 GND J6-2 | J40-13 - KITFS23SKTEVM: SW1 - position 2-3 , J30 - ON, J26 5-6 ON, J26 9-10 ON . - Connect KITFS23SKTEVM Dev-kit and S32K3 MCU via on-board Arduino headers. *SDK: * S32K3 RTD 4.0.0 (SW32K3_S32M27x_RTD_R21-11_4.0.0_D2311_DS_updatesite.zip) * FS23 RTD 1.0.0 (S32K3xx_SBC_FS23_R21-11_1.0.0_D2508_DesignStudio_updatesite.zip) *Debugger: S32DS 3.5.8, OpenSDA/ PEmicro Multilink Universal FX *Target: internal_FLASH *Reference: * AN14041 FS23 quick start guide (Rev. 2.0 — 23 January 2025) * AN14129 FS23 implementation and behaviors (Rev. 2.0 — 13 December 2024) * FS23, Safety System Basis Chip (SBC) with Power Management, CAN FD and LIN Transceivers Data Sheet (Rev. 8.0 — 30 June 2025) * RTD_SBC_FS23_UM.pdf C:\NXP\S32DS.3.5\S32DS\software\PlatformSDK_S32K3\SW32K3_FS23_R21-11_1.0.0_D2312\Sbc_fs23_TS_T40D34M10I0R0\doc * RTD_WDG_43_FS23_UM.pdf C:\NXP\S32DS.3.5\S32DS\software\PlatformSDK_S32K3\SW32K3_FS23_R21-11_1.0.0_D2312\Wdg_43_fs23_TS_T40D34M10I0R0\doc * AUTOSAR_SWS_WatchdogDriver.pdf https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_SWS_WatchdogDriver.pdf * This example is migrated from Wdg_fs23_example_HLD_S32K344. The method of migrating refers to the video "2.S32DS CT MCAL demo porting K344 to K312 based on RTD500": https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Tools-Part-How-to-port-RTD-s-existing-MCAL-demo-to-other/ta-p/1966315 *****************************************************************************