S32K知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

S32K Knowledge Base

标签

讨论

排序依据:
FRDM-A-S32K358 LwIP enablement with RTD 6.0.0.
查看全文
**************************************************************************************** * Detailed Description: * * UART <-> Ethernet gateway demo for S32K344EVB-T172. * * UART messages are encapsulated into raw Ethernet frames * and transmitted over the Ethernet link. Received Ethernet * frames are decapsulated and forwarded to the UART terminal. * * Key Functionality: * - UART TX/RX interrupt driven communication. * - GMAC TX confirmation and RX indication interrupt processing. * - Four-deep message queue for UART/Ethernet decoupling. * - Runtime MAC address configuration. * - TJA1103 loopback, MASTER and SLAVE operation. * - Raw Ethernet frame transport (EtherType 0x88B5). * - RTD MCAL/HLD implementation (EthIf, Eth_43_GMAC, CDD_UART). * * Runtime status information including node configuration, * MAC addresses and link status is displayed on the UART terminal. * * Test Configurations: * * Single board: * GATEWAY_MODE_NODE_1_LOOPBACK * * Two-board setup: * Board 1 : GATEWAY_MODE_NODE_1_MASTER * Board 2 : GATEWAY_MODE_NODE_2_SLAVE * * Boards are connected using a 100BASE-T1 cable. * * Notes: * - EthIf.c contains custom gateway callback implementation. * - During S32 Configuration Tool code generation select "Keep Existing" for EthIf.c. * - Do not overwrite EthIf.c. * - On PC terminal enable local echo * * -------------------------------------------------------------------------------------- * Test HW: S32K3x4EVB-T172 Rev B * MCU: S32K344_172HDQFP * IDE: S32DS 3.6.8 * RTD release: S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger: Lauterbach, P&E Micro * Target: Internal_FLASH * Serial: 115200, 8N1 *****************************************************************************************   Terminal prints between two S32K344EVB-T172 boards In case of single board in PHY loopback    
查看全文
Pad Keeping As explained in the S32K3xx Low Power Management Application Note (AN), the S32K3 family is capable of retaining the output value of some selected pads when device is power-gated in Standby mode. All pins will retain their last set states in run mode during standby mode, and all pins will be placed to its default states after reset event by default. Which means that during the time between wakeup and Port reinitialization, the pins are uncontrollable and driven by default reset values. When pad keeping is enabled, HW ensures that the pin can retain its states from wakeup until the user unlocks it. The S32K3 family provides two pin groups: Run domain & Standby domain, however, the differences between them are not explicitly mentioned in the low power management application. Run domain pins are active only while the MCU is running, while Standby domain pins can also remain functional during Standby Referring to Chapter 41.12 Pad Keeping from S32K3XXRM (Rev. 12), all of the active pins in Standby are: Pin Function in Standby GPIO_4 CMP0_OUT GPIO_5 RESET_b GPIO_9 CMP2_OUT GPIO_11 CMP0_RRT GPIO_12 CLKOUT_STANDBY; CMP1_OUT GPIO_69 CMP2_RRT GPIO_110 CMP0_RRT GPIO_131 CMP0_OUT GPIO_138 CLKOUT_STANDBY GPIO_143 CMP1_RRT GPIO_158 CMP1_OUT GPIO_159 CMP1_RRT GPIO_174 CMP0_OUT GPIO_175 CMP0_RRT GPIO_196 CMP2_OUT GPIO_197 CMP2_RRT (As specified in the RM, see the IOMUX attached to it for details on different derivatives.) Configuration for Pad Keeping for both groups require the same global configuration, but standby domain pins require an additional step.  You could consider DCM.DCMRWF1[STANDBY_IO_CONFIG] field as a global enable for all pad keeping purposes during Standby mode. Additionally, for Standby domain pins, the corresponding MSCRn[PKE] field in SIUL2 must be set. Note: MSCRn[PKE] only needs to be set for Standby domain pins, and does not have effect on Run domain pins. Run domain pins Before entering standby: Configure SIUL2 output for desired pad (HIGH/LOW). Write 0 to DCM.DCMRWF1[STANDBY_IO_CONFIG] (enable global pad keeping). Complete Standby Entry Sequence described in RM. Standby domain pins Before entering standby: Configure SIUL2 output for desired pad (HIGH/LOW). Write 1 to SIUL2.MSCRn[PKE] (enable individual pad keeping). Write 0 to DCM.DCMRWF1[STANDBY_IO_CONFIG] (enable global pad keeping). Complete Standby Entry Sequence described in RM. For both Run and Standby domain pins After standby exit (wake-up event): Write 1 to DCM.DCMRWF1[STANDBY_IO_CONFIG] field on Standby mode exit to disable pad keeping. Note: After enabling Pad Keeping, user must write 1 to DCM.DCMRWF1[STANDBY_IO_CONFIG] to disable it before calling Port_Init() / Siul2_Port_Ip_Init(), otherwise pin initialization may fail. Example routine - Pad keeping    /* ------------------------------------------------------------------------- * Test HW : FRDM-A-S32K344 * MCU : S32K344_172HDQFP * IDE : S32DS 3.6.10 * RTD : S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger : P&E Micro * Target : Internal_FLASH * -------------------------------------------------------------------------*/ The attached example configures PTD13 (GPIO109) & PTD14 (GPIO110). PTD13 is a run domain pin, while PTD14 is a standby domain pin.  The macro PKE_CONFIG can be enabled to configure both SIUL2.MSCRn[PKE] & DCM.DCMRWF1[STANDBY_IO_CONFIG] directly through registers. Otherwise, configuration can be done through Siul2_Ip_Port and Power_Ip drivers: Enable SIUL2.MSCRn[PKE]:   Enable DCM.DCMRWF1[STANDBY_IO_CONFIG]:   After configuring Pad Keeping, the routine waits for USR_SW0 to be pressed, then sets both PTD13 & PTD14 HIGH and enters Standby. MCU can be waken up with USR_SW1. Green LED reflects MCU status (RUN = HIGH, STANDBY = LOW). Note: A small delay is added at to visualize time between standby exit (wake-up) and port initialization. Measurements   Using the attached routine, the following measurements were done: 1. Pad Keeping enabled for both PTD13 & PTD14. 2. Pad Keeping enabled for PTD13 and disabled for PTD14. 3. Pad Keeping disabled for both PTD13 & PTD14.   This example is provided as is with no guarantees and no support.
查看全文
* ================================================================================================= * Detailed Description: * * This example demonstrates Classical CAN and CAN FD reception and transmission using * interrupt-driven Message Buffers and FreeRTOS. * * FlexCAN0 is configured in Normal mode. MB0 receives standard-ID frames and MB1 receives * extended-ID frames. The FlexCAN callback copies every received frame into a FreeRTOS queue * and immediately rearms the corresponding RX Message Buffer. * * A dedicated FreeRTOS task waits for frames in the queue and echoes them through CAN TX MB2. * The transmitted frame preserves the received identifier type, identifier, payload length, * payload, CAN FD EDL state, and BRS state. The user LED is toggled after a transmit request * is accepted by the driver. * * Note: * FreeRTOS API functions such as xQueueSendFromISR() are used from the FlexCAN callback. * Therefore, the FlexCAN interrupt priority must comply with the FreeRTOS interrupt-priority * requirements defined by configMAX_SYSCALL_INTERRUPT_PRIORITY. * * ================================================================================================= * Test HW: FRDM-A-S32K344 (SCH-94921 / SPF-94921 Rev. C) * MCU: S32K344 * Compiler: S32DS 3.6.x * RTD release: S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_20250610 * Debugger: On-Board Debugger * Target: Internal_FLASH * Communication: Classical CAN / CAN FD, STD and EXT ID, optional BRS * =================================================================================================    
查看全文
* Detailed Description: * * This project provides a minimal bring-up and reference example for the LCD-PAR-S035 * display and GT911 capacitive touchscreen on the S32K344. It includes standalone LCD * and touchscreen diagnostic modes, together with an LVGL demonstration mode. * * The display is controlled through the LPSPI interface using the ST7796S * display controller driver. The touchscreen is controlled through the LPI2C * interface and uses GPIO signals for interrupt and reset control. * * The original LCD, DBI and touchscreen drivers were obtained from an NXP * App Code Hub MCUXpresso SDK example and adapted to the S32K3 RTD * environment. The project also integrates LVGL 9.4 as the graphical user * interface library. * * The application mode is selected at compile time using the APP_MODE macro * defined in this file. It allows the user to select a standalone display * test, a standalone touchscreen test or the complete LVGL demonstration. * Only one application mode shall be selected for each build. * * A graphical application can be designed using NXP GUI Guider 2.0.1. * GUI Guider is configured for LVGL 9.4.0. The contents of the GUI Guider * "generated" and "custom" output directories can be copied directly into * the corresponding gui_guider directories in this project. After replacing * the generated output, the project shall be rebuilt to include the updated * screens, widgets, events and custom callbacks. * * Installed packages for S32 Design Studio 3.6.6: * * SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip * * Software Sources: * * NXP App Code Hub demo: * https://github.com/nxp-appcodehub/dm-https-lcd-led-demo * * LVGL release/v9.4: * https://github.com/lvgl/lvgl/tree/release/v9.4 * * NXP GUI Guider 2.0.1: * https://www.nxp.com/webapp/Download?colCode=GUI-GUIDER-INSTALLER-2.0.1-WIN&appType=license * * Hardware: * * FRDM-A-S32K344: * Remove jumper JP11 when using an external debugger. * * LCD-PAR-S035: * Set SW1 to 111. * * Board Connections: * * +------------------+----------------------+-----------------+-------------------+------------------------------+ * | FRDM-A-S32K344 | MCU Signal | LCD-PAR-S035 | LCD-PAR-S035 | Function | * | Connector | | Signal | Connector | | * +------------------+----------------------+-----------------+-------------------+------------------------------+ * | J2-20 | PTC27 / GPIO | TP_INT | J5-12 | Touch interrupt, active low | * | J2-19 | PTC7 / LPI2C1_SCL | TP_SCL | J5-8 | Touchscreen I2C clock | * | J2-17 | PTC6 / LPI2C1_SDA | TP_SDA | J5-6 | Touchscreen I2C data | * | J2-13 | GND | GND | J5-4 | Signal ground | * | J2-11 | PTB14 / LPSPI1_SCK | LCD_WR | J5-5 | LCD SPI clock | * | J2-9 | PTB15 / LPSPI1_SIN | LCD_RD | Not connected | SPI data from LCD | * | J2-7 | PTB16 / LPSPI1_SOUT | LCD_MOSI | J5-9 | SPI data to LCD | * | J2-5 | PTB17 / GPIO | LCD_CS | J5-11 | LCD chip select, active low | * | J2-3 | PTC10 / GPIO | LCD_D_C | J5-7 | Command low, data high | * | J2-1 | PTC11 / GPIO | LCD_RST | J5-10 | LCD reset, active low | * | JA3-3 | VDD_HV_A | VCC | J5-1 or J5-2 | 3.3 V supply | * | JA3-13 or JA3-15 | GND | GND | J5-3 | Power ground | * +------------------+----------------------+-----------------+-------------------+------------------------------+ * * Project Files: * * Format: * File or directory - Description - Source - License * * | lvgl_app.c/.h * | LVGL application layer * | Created for this project * | NXP proprietary license * | * | lv_conf.h * | Project-specific LVGL configuration * | Derived from the LVGL v9.4.0 configuration template * | MIT License * | * | lv_port.c/.h * | LVGL initialization and S32K3 port layer * | Created for this project * | NXP proprietary license * | * | main.c * | Application entry point and compile-time mode selection * | Created for this project * | NXP proprietary license * | * +---gui_guider * | +---custom * | | User callbacks and custom GUI logic * | | GUI Guider 2.0.1 output * | | NXP proprietary license * | | * | \---generated * | Generated screens, widgets and events * | GUI Guider 2.0.1 output * | NXP proprietary license * | * +---lcdc * | fsl_st7796s.c/.h * | ST7796S LCD controller driver * | NXP App Code Hub demo * | BSD-3-Clause License * | * +---lcd_par_s035 * | lcd_par_s035.c/.h * | LCD-PAR-S035 board and display integration * | Created for this project * | NXP proprietary license * | * | lcd_par_s035_config.h * | LCD-PAR-S035 project configuration * | Created for this project * | NXP proprietary license * | * +---lvgl * | \---src * | LVGL 9.4 graphics library * | LVGL release/v9.4 * | MIT License * | * +---platform * | display_compat.h * | MCUXpresso SDK and S32K3 RTD compatibility definitions * | Created for this project * | NXP proprietary license * | * | fsl_dbi.c/.h * | Generic display bus interface implementation * | NXP App Code Hub demo * | BSD-3-Clause License * | * | lcd_dbi_s32k3.c/.h * | S32K3 DBI transport implementation using LPSPI * | Created for this project * | NXP proprietary license * | * | lcd_platform.c/.h * | S32K344 board and platform abstraction * | Created for this project * | NXP proprietary license * | * \---touchpanel * fsl_gt911.c/.h * GT911 touchscreen controller driver * NXP App Code Hub demo * BSD-3-Clause License * * gt911_s32k3.c/.h * S32K3 adaptation using LPI2C and GPIO * Created for this project * NXP proprietary license * * ---------------------------------------------------------------------------- * Test Hardware: FRDM-A-S32K344, schematic revision B * MCU: S32K344 * Display: LCD-PAR-S035 with ST7796S controller * Touchscreen: GT911 capacitive touchscreen controller * Debugger: Lauterbach TRACE32 * Build Target: internal_FLASH
查看全文
**************************************************************************** * Detailed Description: * * CAN <-> Ethernet gateway demo for FRDM-A-S32K344. * * CAN FD frames are encapsulated into raw Ethernet frames and * transmitted over the 100BASE-TX link. Received Ethernet frames * are decapsulated and forwarded to the CAN FD bus. * * Key Functionality: * - Interrupt-driven CAN FD reception via CanIf_RxIndication callback. * - Interrupt-driven Ethernet reception via EthIf_RxIndication callback * (EthCtrlEnableIngressQueueInterrupt, GMAC0_CH_RX_IRQHandler). * - GMAC TX confirmation interrupt processing (GMAC0_CH_TX_IRQHandler). * - Custom gateway format for CAN ID, DLC, flags and * payload (up to 64 bytes CAN FD) in a fixed 72-byte Ethernet payload. * - PHY CAN transceiver initialization. * - Ethernet PHY auto-detection and MDIO configuration via EthPhy driver. * - PHY initialization selectable at compile time: * PHY_INIT_BY_PIN_STRAPPING (default) * PHY_INIT_BY_SOFTWARE (MDIO register write) * * Main Loop Flow: * - CAN -> ETH : CanIf_bRxFlag set by ISR -> App_EthTransmit() * - ETH -> CAN : ethReceiveFlag set by ISR -> App_CanTransmit() * * Notes: * - Red LED set if Gateway_Init returns E_NOT_OK. * - Green LED toggles upon CAN reception. * - Blue LED toggles upon ETH reception. * - EthIf.c contains the custom EthIf_RxIndication gateway implementation. * - During S32 Configuration Tool code generation select "Keep Existing" * for EthIf.c to avoid overwriting the custom callback. * - Eth_43_GMAC_ReleaseRxBuffer() must be called unconditionally inside * EthIf_RxIndication. * * ------------------------------------------------------------------------- * Test HW : FRDM-A-S32K344 Rev A * MCU : S32K344_257BGA * IDE : S32DS 3.6.10 * RTD : S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * AUTOSAR : 4.9.0 * Debugger : P&E Micro * Target : Internal_FLASH * CAN : CAN FD, 500 Kbps nominal / 2 Mbps data, TJA1043 transceiver * Ethernet : RMII 100BASE-TX, DP83848 PHY **************************************************************************** ETH Reception with Wireshark: CAN Reception with PCAN-USB. Note 1: Inside project you can comment NODE_1 and define NODE_2 as 1 to enable simple routine which sends out a CAN frame if SW3 is pressed, and an ETH frame if SW2 is pressed. Note 2: For a real gateway application, use a queue or ring buffer instead of one global frame; otherwise, a second CAN frame can overwrite the first before Ethernet transmission completes. This example is for demostration purposes only.
查看全文
********************************************************************************* * Detailed Description: * * ADC hardware trigger demonstration using BCTU Trigger Mode on S32K358. * * An eMIOS1 Channel 23 reload event is used as a trigger source for the BCTU). * The BCTU initiates a hardware-triggered conversion of an ADC1 group containing * three channels. * * The result of the third ADC channel, connected to the on-board potentiometer * (ADCPOT0), is used to dynamically update the duty cycle of an * eMIOS Channel 5 PWM output. * * The PWM output drives the on-board LED, allowing the potentiometer position * to control LED brightness. * * Key Functionality: * - eMIOS-triggered BCTU operation. * - BCTU Trigger Mode configuration. * - ADC1 hardware-triggered group conversion. * - ADC notification callback processing. * - PWM duty-cycle update based on ADC result. * - LED brightness control using the potentiometer. * * ------------------------------------------------------------------------------ * Test HW: S32K3x8EVB-Q289 * MCU: S32K358 * IDE: EB Tresos 29.0.0 * RTD Release: S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_20250610 * Debugger: Lauterbach * Target: Internal_FLASH ******************************************************************************** * Revision History: * Ver Date Author Description of Changes * 1.0 02-10-2026 Petr Stancik Initial version ********************************************************************************
查看全文
********************************************************************************************** * Detailed Description: * This example demonstrates the S32K344 internal flash UTest (User Test) sequence using the * Mem_43_INFLS AUTOSAR driver. It covers Array Integrity Check (MISR-based) and User Margin * Read Check, exercised over the full configured Block 3 address range (starting at * 0x00700000), as defined in the Mem_43_INFLS instance configuration. * * Setup: * ProgramBlock3() erases one sector (8 KB) at 0x00700000 and programs the first 512 bytes * with a sequential byte pattern (0x00..0xFF repeating). The remainder of the block * contains erased cells (0xFF). The UTest operations in Steps 1–3 are performed over the * entire Block 3 — not only the 512 programmed bytes. * * Step 1 — Array Integrity Check, Golden MISR Capture: * Runs the Array Integrity Check at NORMAL read margin using sequential addressing over * the full block. UM0–UM9 are seeded with 0xA5A5A5A5. MisrExpectedValues is intentionally * set to 0x0, so JOB_FAILED is the expected outcome. A custom wait function polls the AID * bit directly (without calling Mem_43_INFLS_MainFunction) so that the UM registers are * read before the driver clears them on job completion. The captured MISR becomes the * golden reference (goldenMisr) for Steps 2 and 3. * GETSTATEUTEST_JOB is called afterward to confirm no real hardware fault occurred * (ECC error, breakpoint, or suspension) during the capture run. * * Step 2 — Array Integrity Check, Verification Run: * Re-runs the identical Array Integrity Check over the full block (same seed, same * sequential addressing) with MisrExpectedValues = goldenMisr captured in Step 1. * JOB_OK confirms flash content is unchanged; JOB_FAILED indicates corruption. * GETSTATEUTEST_JOB is called to verify clean hardware completion. * * Step 3 — User Margin Read Check, Cell Margin Verification: * Re-reads the full block at a tighter read margin (C40_IP_MARGIN_LEVEL_PROGRAM). * Same seed and goldenMisr are used. If all cells retain sufficient voltage margin at * the tighter threshold, the MISR matches and JOB_OK is returned. A JOB_FAILED result * indicates one or more cells are degrading before they produce a detectable ECC error * under normal read conditions. * Note: both Array Integrity Check and User Margin Read Check must use sequential * addressing (C40_IP_SEQUENTIAL) to produce a comparable MISR signature. * * Results are accumulated in the utestResults structure (Utest_TestResultType), recording * both the MISR job outcome (Utest_JobResultType) and the hardware UTest state * (Utest_HwStateType) for each step independently. * * NOTE: This example must be executed from SRAM. The Mem_43_INFLS UTest operations * (Array Integrity Check, User Margin Read Check) place the internal flash controller * in UTest mode, during which the flash array is not available for normal read access. * ------------------------------------------------------------------------------------- * MCU: S32K344 * FX_OSC: 16MHz * RTD: S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger: Lauterbach Trace32 * Target: Internal_FLASH **********************************************************************************************
查看全文
**************************************************************************************************** * Detailed Description: * * CM7_0 Safety Core (Lockstep): * * Runs as Domain 0 on the CM7_0+CM7_1 lockstep core pair of the S32K358. * Acts as the system master: performs full initialization of clocks, XRDC * domain assignment and memory region protection (Rm_Init), Port, Platform, * and releases CM7_2 from reset via Mcu_SetMode(McuModeSettingConf_1). * * XRDC memory layout configured by Rm_Init: * - 0x20480000 (SHARED_VARIABLE): Domain 0 RW, Domain 1 RW — Sema42 Ch 0 protected * - 0x20480010 (SHARED_FAULT_FLAG): Domain 0 RW, Domain 1 RW — Sema42 Ch 1 protected * - 0x20490000 (CM_0_OWNED_VARIABLE):Domain 0 RW, Domain 1 NO ACCESS — exclusive to CM7_0 * * Two Sema42 channels are used: * - Channel 0: guards the shared counter at 0x20480000 (competed with CM7_2) * - Channel 1: guards the fault flag at 0x20480010 (CM7_0 monitors CM7_2 violations) * * Main loop (continuous): * - Writes to the owned SRAM region (0x20490000) directly, without a semaphore — * XRDC guarantees exclusive Domain 0 access. Blinks BLUE LED on each write. * - Acquires Sema42 Ch 0, increments the shared counter at 0x20480000, * releases Ch 0. Competes with CM7_2 for the gate — mutual exclusion * is visible as either core stalls while the other holds the semaphore. * * XRDC_ISR_Handler (triggered by XRDC interrupt when CM7_2 violates 0x20490000): * - Spins on Sema42 Ch 1 until CM7_2's HardFault handler sets the shared * fault flag at 0x20480010, confirming CM7_2 has handled the violation. * - Acquires Ch 1 and clears the fault flag, signaling CM7_2 to resume * its main loop cycle. * - Together with CM7_2's HardFault handler, this implements a lightweight * cross-core fault notification and recovery handshake. * * CM7_2 Application Core * * Runs as Domain 1 on the independent CM7_2 core of the S32K358. * Only Sema42 is initialized here — XRDC and full RM initialization * are handled exclusively by CM7_0 (Domain 0, lockstep) before this core is released from reset. * * Two Sema42 channels are used: * - Channel 0: guards the shared counter at 0x20480000 (competed with CM7_0) * - Channel 1: guards the fault flag at 0x20480010 (CM7_2 signals CM7_0) * * Main loop (repeating cycle of 10 iterations, i = 0..8 + violation): * - Before each iteration, CM7_2 reads the shared fault flag via Ch 0 * and spins until CM7_0 clears it (fault recovery synchronization). * - Iterations 0..8 (9x): acquires Ch 0, increments the shared counter, * releases Ch 0, blinks GREEN LED to indicate successful access. * - Iteration 9: deliberately writes 0xDEAD to CM7_0's owned SRAM region * (0x20490000), which has no XRDC access for Domain 1. * This triggers a HardFault on CM7_2. After fault handling, variable i is reset * to 0 and the cycle repeats indefinitely. * * HardFault handler (triggered by XRDC violation on iteration 9): * - Lights RED LED immediately. * - Calls Rm_XrdcGetDomainIDErrorStatus() to read and decode the XRDC * error registers (domain, faulting address, access type, attribute). * Error registers are cleared automatically inside this API call. * - Acquires Sema42 Ch 1 and sets the shared fault flag at 0x20480010 * to notify CM7_0 that a violation was detected. ------------------------------------------------------------------------------------------------ * MCU: S32K358 * FXOSC 16MHz * RTD: S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger: PE Micro Multilink * Target: Internal_FLASH ****************************************************************************************************
查看全文
********************************************************************************************** * Detailed Description: * CMU_FM minimum reference count requirement: * RCCR[REF_CNT]_MIN = CEILING(MAX(3 * (f_reference_clock / f_bus_clock), * 8 + 5 * (f_reference_clock / f_monitored_clock))) * where: * f_reference_clock = FXOSC clock frequency * f_bus_clock = AIPS_SLOW_CLK frequency (40 MHz) * f_monitored_clock = metered clock frequency * * CMU_1 * ----- * FIRC clock frequency (fmonitored) = 48 MHz * FXOSC clock frequency (fref) = 16 MHz * * 3 * (fref / fbus) = 3 * (16 / 40) = 1.2 * 8 + 5 * (fref / fmonitored) = 8 + 5 * (16 / 48) = 9.667 * RCCR[REF_CNT]_MIN = CEILING(MAX(1.2, 9.667)) = 10 * The first term would dominate only at f_bus_clock < 4.96 MHz, for example. * * CMU_2 * ----- * SIRC clock frequency fmonitored = 32 kHz * FXOSC clock frequency (fref) = 16 MHz * * 3 * (fref / fbus)= 3 * (16 MHz / 40 MHz) = 1.2 * 8 + 5 * (fref / fmonitored) = 8 + 5 * (16 MHz / 32 kHz) = 2508 * RCCR[REF_CNT]_MIN = CEILING(MAX(1.2, 2508)) = 2508 * * * SR_FMTO (Frequency Meter Time Out): * --------------------------------------------------------------------- * FMTO could theoretically be triggered by configuring RCCR[REF_CNT] * to a value lower than the minimum number of reference clock cycles * required to observe one full monitored clock period. * This however cannot be guaranteed by NXP as the value is lower then RCCR_MIN. * NXP guarantees the MCU functionality only if RCCR > RCCR_MIN * When SR_FMTO is set, the SR_FMC is never set, and therefore the CMU_FM interrupt is never called. * * CMU_FM_1: * RCCR[REF_CNT] < f_FIRC / f_FXOSC < (48 MHz / 16 MHz) < 3 * CMU_FM_2: * RCCR[REF_CNT] < T_SIRC / T_FXOSC < 31.25 µs / 62.5 ns < 500 * * * POR_WDG: * --------------------------------------------------------------------- * In case CMU_FM_1 ISR is not executed within POR_WDG timeout, the MCU is reset by the POR_WDG. * Read DCMROPP1-4 * To inject this reset, select CMUFM_1_POR_WDG = 1 and CMUFM_1. * ------------------------------------------------------------------------------------- * MCU: S32K344 * FX_OSC: 16MHz * RTD: S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * Debugger: Lauterbach Trace32 * Target: Internal_FLASH **********************************************************************************************
查看全文
This example project will show user how to use and configure the basic functionalities of WKPU + SIUL2 (GPIO) for wake-up from Standby mode on the S32K358 MCU, with RTC time preservation across Standby and functional reset clock sourced through SIRC. Test HW: FRDM-A-S32K358 / S32K3X8EVB-Q289 MCU: S32K358 IDE: S32DS v3.5 & S32DS v3.6.x SDK release: RTD 6.0.0 Debugger: PE Micro Target: internal_FLASH This example routine configures the WKPU unit for GPIO interrupt wake-up using pins PTH1 (WKPU0) and PTH3 (WKPU15). RTC time is preserved across Standby via the VDDBY supply domain. After wake-up, the functional reset clock is sourced from SIRC before transitioning to the main PLL. No fast wake-up path is used. The routine waits for SW5 to be pressed, then turns off the green LED, and enters Wkpu_EnterStandby() function which: Switches core clock to FIRC. Initializes the WKPU instance. Configures WKPU0 (PTH1) and WKPU15 (PTH3) as wake-up sources. Enters Standby mode (normal wake-up). After pressing USER0/SW4(PTH1), MCU wakes up, resets and polls for USER1/SW5 (PTH3)  or USER0/SW4(PTH1) to be pressed again. Terminal output Settings: 115200 baud — 8 data bits — No parity — 1 stop bit — No flow control (LPUART6) The terminal interaction follows three distinct phases each cycle: boot/wake-up banner → SW6 to read RTC time → SW5 to enter Standby. A representative session is shown below. 1 — Initial power-on (cold start) RTC Standby example, press SW5 to enter standby......... Press SW6 to print RTC date & time......... Reset reason: 15 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 0 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 2 2 — Enter Standby → Wake-up → RTC time preserved MCU will enter standby........ RTC Standby example, press SW5 to enter standby......... Press SW6 to print RTC date & time......... Reset reason: 28 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 13 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 14 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 14 3 — Multiple Standby cycles (RTC keeps incrementing) MCU will enter standby........ RTC Standby example, press SW5 to enter standby......... Press SW6 to print RTC date & time......... Reset reason: 28 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 0 seconds 59 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 1 seconds 0 MCU will enter standby........ RTC Standby example, press SW5 to enter standby......... Press SW6 to print RTC date & time......... Reset reason: 28 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 1 seconds 4 Current RTC date & time: year 1970 month 1 day 1 hour 0 minutes 1 seconds 6 Disclaimer — PTH3 pin on S32K3X8EVB-Q289: The EVB button mapped to PTH3 may fail to trigger a wake-up event. This is caused by the button connected to the VDD_HV_B (3.3 V) rail, while PTH3 belongs to the VDD_HV_A domain, which defaults to 5 V. The signal level mismatch prevents correct wake-up detection. Workaround: switch Jumper J23 from position 1-2 (default, 5 V) to position 2-3 (3.3 V) to align VDD_HV_A with the button voltage level before testing wake-up via PTH3. This example is provided as is with no guarantees and no support.
查看全文
1. Abstract/Introduction Boundary scan is a method for testing interconnects (wire lines) on printed circuit boards or sub-blocks inside an integrated circuit (IC). Boundary scan is also widely used as a debugging method to watch integrated circuit pin states, measure voltage, or analyze sub-blocks inside an integrated circuit. The Joint Test Action Group (JTAG) developed a specification for boundary scan testing that was standardized in 1990 as the IEEE Std. 1149.1-1990. In 1994, a supplement that contains a description of the boundary scan description language (BSDL) was added which describes the boundary-scan logic content of IEEE Std 1149.1 compliant devices. Since then, this standard has been adopted by electronic device companies all over the world. Boundary scan is now mostly synonymous with JTAG. This test is based on existing application notes for LPC55(S)xx, i.MX RT and MCXA (See references). The procedure follows how to do both a BYPASS, IDCODE and SAMPLE test, as well as an EXTEST. Following boundary scan instructions are defined in the IEEE standard: BYPASS (mandatory): TDI is connected to TDO via a single shift register. IDCODE (optional): Reads the device identification register. SAMPLE (mandatory): Takes a snapshot of the normal operation of the IC. EXTEST (mandatory): Apply preloaded data of the boundary scan register to the ports. 2. Hardware platform Lauterbach: LA-3505 POWER-DEBUG-PRO S32K3: S32K3X8EVB-Q289 There are no hardware modifications needed for connecting JTAG interface, as the S32K3 family includes the standard Arm debug port, supporting both the JTAG and SWD interfaces. S32K3XX derivatives can directly use the JTAG interface. Ensure S32K3X8EVB-Q289's jumpers are set as in the Quick Start Guide for S32K3X8EVB Board: Default Jumper settings. Ensure a valid connection between the EVB's JTAG ARM 20-pin Standard Port (On board: J365), and the Debug Cable for Lauterbach interface. 3. Software platform This test uses Lauterbach's TRACE32 Software Package. Download the TRACE32_202509.7z to the computer and install it: Because the installation package is relatively large, you can install software components according to the target processor to save hard disk space. You can find installed driver at C:\T32\bin\windows64\drivers. 4. BSDL file validation using Lauterbach JTAG debugger. Confirm that Lauterbach probe is detected in 'Device Manager': Device Manager Trace32 device enumeration.   Note: Lauterbach debugger used is LA-3500, with Probe LA-3000 + LA-7844A Debug License. Related information can be found on the Lauterbach's page. Open TRACE32 Arm interface: Type in the following commands: SYStem.Down BSDL.RESet BSDL.ParkState Select-DR-Scan BSDL.state    BSDL.state window should now appear. Select 'FILE' and load BSDL from S32K3 HW Design Package. S32K3X8EVB-Q289 should use S32K358_bga289_customer_1995E01D.bsdl. BSDL.state window.  After loading the file, type the following command: BSDL.SOFTRESET​ Switch to the Check tab of the BSDL.state window. Click BYPASSall and IDCODEall button to see if both results pass. Both should change from 'No result' to 'Test PASS': BYPASS and IDCODE check. BYPASS: PASS means the bypass scan completed correctly for all configured devices. This indicates that the JTAG chain connectivity, chain order/length, and basic BSDL configuration are probably correct. IDCODE: PASS means the received device ID matches the expected BSDL description. This is evidence that the correct device and BSDL file are being used, but it still does not validate the boundary-register pin definitions. Next, click the SAMPLEall button, 'No result' should become Test done. Double-click the entity name, and the BSDL.SET window will pop-up: BYPASS and IDCODE check, BSDL.SET window appears. SAMPLE: PASS indicates that the pin can be observed through the boundary-scan cell, the BSDL input/observe mapping is likely correct, and that the captured value corresponds to the actual pad level. In the BSDL.SET window, uncheck Intern option to filter out the internal registers. The remaining contents are the sampled value on each signal pins. Use a multimeter to measure voltage of at least three signal pins and see if the logic state matches the sampled value. BSDL.SET window, SAMPLE check.   Next, in the Instructions field, click EXTEST and in the DR mode field, choose Set Write. Then switch to the BSDL.state window and check SetAndRun and TwoStepDR. BSDL.SET & BSDL.STATE windows EXTEST set up.   Switch back to BSDL.SET window, click 'ENABLE' in Init BSR to enable output of corresponding signal pins, and click the buttons in “Reg.” column to toggle their output logic state 0 or 1. Use a multimeter to measure if the logic state really toggles on those signal pins. At least three signal pins need to be verified. BSDL.SET window enable and toggle signal level Note: PTG29/30/31 (User LED indicators Red/Green/Blue) for simplicity reasons, however, as a diagnostic recommendation, use an unloaded or lightly loaded pad if possible. 5. Conclusion This procedure provides a practical method for validating the S32K3X8EVB JTAG boundary-scan chain using TRACE32 and the appropriate S32K358 BSDL file. BYPASSall and IDCODEall verify JTAG-chain connectivity and device identification, SAMPLEall confirms pin-state observation, and EXTEST verifies pin control through the boundary-scan register. While these checks confirm basic boundary-scan operation, additional pin-level testing is recommended to validate board connectivity and application-specific signals. Any reset observed during EXTEST should be investigated before concluding a BSDL-related issue. The final report should capture the BSDL file used, JTAG-chain results, validated pins, measured logic levels, and any reset behavior observed during EXTEST. 6. References How to Perform Boundary Scan for LPC55(S)xx based on μTrace AN12919: Introduction to Boundary Scan of i.MX RT Series – Application Note How To Perform Boundary Scan On MCXA Series Using μTrace And Trace32 Boundary Scan User's Guide S32K3 Auto General-Purpose MCUs | NXP Semiconductors Software Download | Lauterbach TRACE32
查看全文
********************************************************************************************** * Detailed Description: * This example uses RTD 7.0.0 and SPD 1.0.6. It initializes the internal * flash and executes the selected C40 UTEST diagnostic through the * Mem_43_INFLS driver. * The available tests are * ECC Logic Check (ECC_LOGIC_CHECK), * EDC-after-ECC Logic Check (EDC_AFTER_ECC_LOGIC_CHECK), * and Address Encode Logic Check (ADDRESS_ENCODE_LOGIC_CHECK). * The test-selection macros enable or disable each diagnostic, and more than one * test may be enabled at the same time. * * ProgramBlock3() is optional and is not required for the UTESTs. * It erases * and programs one data-flash sector only to provide a known, readable test * address. The UTESTs can also run without it, provided that AddressCheck is * a valid, aligned flash address. The ECC and EDC tests use synthetic * data/check-bit values, while the address is used to select the flash block * and trigger the hardware check. * * EMCEM_MODULE_ENABLED enables eMCEM support. WAIT_MAIN pauses execution * before eMcem initialization, while WAIT_AFTER_EMCEM_INIT pauses execution * after eMcem initialization to allow debugger attachment at the required * execution point. eMcem_Init() requires a reset without an attached debugger. * * Mem driver job results and handled eMCEM alarms are stored in g_MemTestResults. * The user alarm handler clears the configured FCCU/eMCEM * faults and records the corresponding alarm result. If a UTEST causes a * HardFault, the handler resumes interrupts and disables C40 UTEST mode * before returning so that pending FCCU alarm interrupts can be serviced. * ------------------------------------------------------------------------------------- * MCU: S32K3x4EVB-Q257 * Fsys: 160 MHz PLL with 16 MHz crystal reference * Debugger: Lauterbach Trace32, S32DS IDE 3.6.5 * Target: internal_FLASH **********************************************************************************************
查看全文