KSDK示例列表 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 当前 KSDK 1.3 的示例位于C:\Freescale\KSDK_1.3.0\examples 中间件示例（tcpip、文件系统）位于C:\Freescale\KSDK_1.3.0\middleware   还有更多示例，创建如下：   KSDK 1.3 使用 KSDK 1.3 的 FTM PWM 实现彩虹色 如何在 KDS3.0 + KSDK1.3 中使用 printf() 将字符串打印到 UART 使用 KSDK 驱动程序驱动 16x2 LCD 将NFC控制器库与KSDK集成 KL43Z 使用 KDS3.0 +KSDK1.3.0 + 处理器专家支持 sLCD 和触摸感应   KSDK 1.2 使用 DMA 和 KSDK 模拟 ADC 灵活扫描模式 编写我的第一个KSDK1.2KDS3.0 中的应用 - Hello World 和使用 GPIO 中断切换 LED 使用 KSDK [FTM + GPIO] 控制直流电机的速度和伺服电机的位置 带 KSDK 的线扫描相机 [ADC + PIT + GPIO] 检测飞思卡尔杯智能赛道中心的简单方法 Kinetis Design Studio 中带有 KSDK 的 FatFs + SDHC 数据记录器 KSDK 段式 LCD 示例 KSDK GPIO驱动程序，带处理器专家 DAC Sinus 演示（使用 PEx + KSDK 1.2 + KDS 3.0） 如何基于KSDK演示代码启动定制的KSDK项目   KSDK 1.1 使用 SDK 和 CMSIS 在 KV31 上实现 FIR 功能的示例项目 如何使用KSDK 1.1.0切换KDS 2.0中的LED和处理器专家 KSDK SPI 主从控制器，带 FRDM-K64F 配置 Kinetis 软件开发套件 (KSDK) 以使用超声波传感器测量距离 Kinetis SDK 1.1.0 的 USB HID 双向通用设备演示项目 配置 Kinetis 软件开发套件 (SDK) 以使用红外 (IR) 传感器测量距离 在 KDS 中编写我的第一个 KSDK 应用程序 - Hello World 和 GPIO 中断   KSDK 1.0 使用 FRMD-K64F + KDS 1.1.0 编写您的第一个 LED 切换应用程序+ KSDK 1.0.0非处理器专家 使用 SDK 的低功耗应用 KSDK I2C EEPROM示例 概述 回复：KSDK示例列表 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这些示例是否会针对 KSDK 2.0 进行更新 - 这些示例适用于过时的 KSDK 版本，不是吗？ 此外，Processor Expert 显然已经过时并且不会进一步开发？ 谢谢， 谨致问候，戴夫

飞思卡尔 ARM ®微控制器概述 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将概述飞思卡尔 ARM 微控制器以及基于 ARM ® Cortex ® -M4 / M+ 的 Kinetis MCU 和基于 Cortex-A8 和 Cortex-A9 的 i.MX 应用处理器的产品系列路线图。会议还将介绍飞思卡尔专注于 Kinetis MCU 的部分内容，例如 KM、KM 和 KV 系列。 James Huang 主讲 2015 年 5 月 7 日，台北 DwF 展 会话 ID：APF-IND-T1453 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将概述飞思卡尔 ARM 微控制器以及基于 ARM ® Cortex ® -M4 / M+ 的 Kinetis MCU 和基于 Cortex-A8 和 Cortex-A9 的 i.MX 应用处理器的产品系列路线图。会议还将介绍飞思卡尔专注于 Kinetis MCU 的部分内容，例如 KM、KM 和 KV 系列。 James Huang 主讲 2015 年 5 月 7 日，台北 DwF 展 会话 ID：APF-IND-T1453 i.MX 应用处理器 Kinetis Cortex ® -M 微控制器

AN5200 - MPC55xx および MPC56xx にインプリメントされたエラー訂正コード この文書のリビジョン1が正式に公開されました。 https://www.nxp.com/docs/en/application-note/AN5200.pdf   関連するコード例は、こちら(AN5200SWに等しい)にも掲載されています。 例 1 - MPC5634M_2b_RAM_ECC_error_injection CW210 例 2 - MPC5674F_1b+2b_RAM_ECC_error_injection CW210 例3 - MPC5643L 1b_RAM_ECC_error_injection CW210 例 4 - MPC5643L 2b RAM と 2b FLASH ECC エラー挿入 CW210 例 5 - MPC5675K-2b_RAM+2b_FLASH_ECC_error_injection CW210 この文書のリビジョン1が正式に公開されました。 http://cache.freescale.com/files/microcontrollers/doc/app_note/AN5200.pdf http://cache.freescale.com/files/microcontrollers/doc/app_note/AN5200SW.zip   関連するコード例は、こちら(AN5200SWに等しい)にも掲載されています。 例 1 - MPC5634M_2b_RAM_ECC_error_injection CW210 例 2 - MPC5674F_1b+2b_RAM_ECC_error_injection CW210 例3 - MPC5643L 1b_RAM_ECC_error_injection CW210 例 4 - MPC5643L 2b RAM と 2b FLASH ECC エラー挿入 CW210 例 5 - MPC5675K-2b_RAM+2b_FLASH_ECC_error_injection CW210 日時: AN5200 - MPC55xx および MPC56xx に実装されたエラー修正コード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 解決。コードは正しく実行されていますが、正しく実行されていませんでした。 問題はまったく異なっていました。私が(2回)ダウンロードしたところ、コードが破損していました。今日、もう一度ダウンロードすると、実行されているのがわかりました。次に、SSDを使用してコードをアプリケーションに変換します。今はあらゆることがうまくいっています。私はExceprion_Handlers壊れたフラッシュブロックを修正したかったのですが、それはうまくいきます。 ありがとうございます。 日時: AN5200 - MPC55xx および MPC56xx に実装されたエラー修正コード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 2b ECCエラーインジェクションについて話しているのか(6.2章と例で説明されているため、機能Generate_noncorrectable_FLASH_ECC_errorで示されているMPC5643L)、またはフラッシュメモリコントローラに実装された特定のECCエラー報告フラグ(EER)に関連しているのかはわかりません。私はこれらのフラグを冗長だと考えているため、アプリケーションノートでは言及していません。また、簡単にするためにSSDドライバーを使用していませんが、SSDドライバーでECCエラーを注入することはでき、原理は同じです。 日時: AN5200 - MPC55xx および MPC56xx に実装されたエラー修正コード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、ドキュメントがあまりありません。ご態度ありがとうございます。 MPC5634M、CW10.2、SSD C90LCを使用しています。フラッシュを過度にプログラムすると、EERが発生する可能性があります。MPC56XX_C90LC_JDP_SSD_100_DEVD またはECC_preliminaryで破棄された例は、e200z335 コアで EER をシミュレートしていません。または、(プロジェクト内に)欠落しているファイルがあるか、これを行うための実用的なルーチンがありません(SSDドライブ内)。 もしお役に立てれば...

所有电路板的 GPIO 测试常见问题解答（FAQ） <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 虽然您可以自行开发驱动程序来在内核空间中控制 GPIO，但从用户空间访问 GPIO 有一种更为简便的方法。当时间要求不严格时，您可以使用 GPIO-SYSFS。 SYSFS 是一个虚拟文件系统，它将内核内部框架的一些功能导出到用户空间，而 GPIO 是可以通过 SYSFS 导出功能的框架之一。 GPIO-SYSFS 功能自内核 2.6.27 版本起，在所有主线内核中均已可用。 配置内核以通过SYSFS导出GPIO 要在 SYSFS 中启用 GPIO，请选择以下内核选项： 设备驱动程序 ---> --- GPIO 支持 [*] /sys/class/gpio/... (sysfs 接口) 如果您使用的是 i.MX233 或 i.MX28，在重新编译内核后，请务必重新生成引导流，因为即使在 ltib 环境下，这一操作也不会自动完成。 请确认您打算使用的引脚确实可用作 GPIO 引脚，且未被内核请求（gpio_request）。如果某个引脚已通过 gpio_request 进行了请求，您需要在内核中使用 gpio_export 导出该引脚，以便通过 SYSFS 进行访问。若引脚未被默认配置为 GPIO，您需要在 /arch/arm/mach-XXX中的相应文件中设置 IO MUX。 在用户空间访问GPIO 启用 GPIO-SYSFS 功能后，您可以使用新内核启动设备，以进行一些测试。 首先，您需要将要测试的 GPIO 导出到用户空间： echo XX > /sys/class/gpio/export XX 应由以下算法确定： GPIOA_[B] 是您需要导出的 GPIO，其中，“A” 表示 GPIO 组，“B” 表示该组中引脚的偏移量。若第一个可用的 GPIO 存储区是 0 // (例如 iMX.28) XX = A×32 + B； 否则 // 第一个 GPIO 存储区是 1 XX = (A-1)×32 + B； 导出 GPIO 引脚后，您将能够看到 GPIO 接口被导出到： /sys/class/gpio/gpioXX 通过该接口，您现在可以执行一些操作，例如： # 读取引脚值 cat /sys/class/gpio/gpioXX/value # 更改引脚方向 echo in > /sys/class/gpio/gpioXX/direction echo out > /sys/class/gpio/gpioXX/direction # 切换 GPIO 输出电平 echo 0 > /sys/class/gpio/gpioXX/value echo 1 > /sys/class/gpio/gpioXX/value 需要特别注意的是，通过 GPIO 虚拟文件系统，每次只能操作一个 GPIO 引脚（每个命令仅针对一个引脚）。 关于：所有电路板常见问题解答 GPIO 测试 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这或许是个愚蠢的问题，但我要怎样才能知道哪个引脚在物理上与 gpioXX 相连呢？

Automotive Comfort Control Using FRDM-A-S32K344 Microcontrollers 1. Overview This module demonstrates how to implement a vehicle comfort control system using GPIO, PWM, and stepper motor sequencing on NXP S32K3 microcontrollers. The application reads user inputs from push-buttons and translates them into two independent comfort functions: a DC motor that simulates a cabin cooling fan (regulated through PWM) and a stepper motor that simulates an electric window mechanism (driven through GPIO coil sequencing). Both actuators react in real time, mimicking how comfort body-control modules work in modern vehicles. This example is based on the Application Code Hub demonstration for: Vehicle Comfort Control for FRDM-A-S32K344 In this workshop, on-board push-buttons simulate the driver's comfort commands. When the student presses a button, the MCU reads the input through GPIO, decodes the requested action, and drives the associated actuator: a PWM duty cycle is generated for the DC Motor 2 Click (regulating the fan speed), or a full-step coil sequence is generated through GPIO outputs to the H-Bridge Click (moving the NEMA17 stepper motor up or down). Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle comfort control system and the ideas behind HVAC regulation and electric window control. Use on-board push-buttons as simulated driver comfort commands. Read digital inputs using the GPIO peripheral and understand debouncing considerations. Generate PWM signals to regulate DC motor speed (fan simulation). Implement a full-step drive sequence (A → B → C → D) to control a stepper motor. Configure the DC Motor 2 Click and H-Bridge Click boards over the mikroBUS interface. Recognize the actuation data flow: user input → MCU processing → PWM / GPIO actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why comfort functions are relevant in modern automotive body electronics. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Push-buttons (on-board buttons simulate driver comfort commands) Processing: S32K3 MCU (reads GPIO, decodes the command, drives the correct actuator) Output: Dual actuation (DC motor via PWM for the fan, stepper motor via GPIO sequencing for the window) This matches the classic flow of an embedded body-control system: user input → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button that corresponds to a comfort action The GPIO peripheral reads the button state The application decodes the command (fan control or window movement) Depending on the command, the MCU generates either a PWM signal or a stepper coil sequence The DC motor changes speed, or the stepper motor rotates in the requested direction This loop runs continuously to ensure real-time comfort control. Comfort_Control_Application.png Vehicle Comfort Control Application Architecture 4. Key Concepts 4.1 GPIO (General-Purpose Input/Output) The push-buttons on the FRDM-A-S32K344 board are connected to GPIO input pins. The MCU polls (or reads on interrupt) the pin state and interprets a logic transition as a user command. GPIO is also used as output for the stepper motor coil control signals, driving the H-Bridge Click inputs. GPIO handling is the foundation of automotive user-interface processing — used for buttons, switches, ignition detection, and many others. 4.2 PWM — Pulse-Width Modulation and Fan Speed Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A DC motor interprets the average voltage produced by this PWM as a proportional rotational speed. In this demo, the S32K344 generates PWM on a mikroBUS pin that drives the DC Motor 2 Click, which in turn powers the 5 V fan motor. Increasing the duty cycle increases fan speed; decreasing it slows the fan down — a typical pattern used in cabin ventilation and HVAC systems. 4.3 DC Motor Direction and H-Bridge Concept The DC Motor 2 Click integrates an H-Bridge driver that can be configured for forward, reverse, brake, or coast modes. The MCU controls the direction pins and applies PWM on the enable input to regulate speed. This is exactly the same principle used in real automotive fan modules, where a low-side or full-bridge driver is switched at kilohertz frequency to obtain smooth speed control without dissipating power in a series resistor. 4.4 Stepper Motor Full-Step Sequencing A stepper motor like the NEMA17 rotates in fixed angular increments (typically 1.8° per step) when its coils are energized in the correct order. The MCU generates a repeating four-phase pattern (A → B → C → D) on four GPIO pins connected to the H-Bridge Click. Reversing the sequence (D → C → B → A) reverses the direction. The step frequency directly determines rotation speed, and counting the number of steps gives an open-loop position estimate — the exact behavior needed to simulate an electric window moving up or down. 4.5 Push-Buttons as Comfort Commands The on-board buttons are a simplified, safe stand-in for the physical HVAC and window switches found in a real vehicle. The student presses them by hand, the GPIO state changes, the MCU decodes the command, and the corresponding actuator reacts. This isolates the student from real body-electronics wiring while preserving the full software logic. 4.6 Data Flow at a Glance Button press → GPIO input → command decoding → selection of actuator (fan or window) → PWM duty cycle update or stepper coil sequence advance → motor response. This direct chain from the student's finger to the actuator shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the comfort control application and drive the connected peripherals. FRDM-K64 Click Shield FRDM K64 click shieldFRDM K64 click shield mikroBUS expansion board used to connect Click modules to the FRDM platform. DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge driver board used to control DC motor speed and direction via PWM. H-Bridge Click H-Bridge ClickH-Bridge Click Dual H-Bridge driver used to sequence the stepper motor coils. 5 V Fan Motor 5V Fan Motor5V Fan Motor Actuator used to simulate the vehicle cabin cooling fan controlled through PWM. Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Actuator used to simulate the electric window mechanism through step sequencing. USB-C  — Provides power and enables programming and debugging of the system. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate cabin cooling and electric window control. Vehicle Comfort Control Full Setup on FRDM-A-S32K344 Comfort Full SetupComfort Full Setup Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) S32K3 Automotive Software Package Application Code Hub project import Vehicle Comfort Control for FRDM-A-S32K344 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the vehicle comfort control demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable and external 12 V supply Attach FRDM-K64 Click Shield, DC Motor 2 Click and H-Bridge Click Wire the 5 V fan motor and NEMA17 stepper motor Verify wiring before powering the system Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Press the fan control buttons Observe DC motor speed change Press the window up/down buttons Observe stepper motor movement and direction Fan speed and window motion follow user commands in real time 7. Signal Behavior and Control Logic The Vehicle Comfort Control application drives two independent actuators from a single S32K344 MCU: a DC fan motor controlled through a PWM signal for cooling, and a stepper motor controlled through a 4-channel GPIO sequence for electric window movement. User inputs (SW2 and SW3) are read by the MCU, which then generates the appropriate signal type for each actuator. The two diagrams below describe the signal behavior and control logic for each subsystem. 7.1 Cooling System – Fan Speed Control (PWM) Comfort_Fan_PWM.png Figure: Fan speed control mapping. The MCU generates a PWM signal on the EMIOS channel to drive the DC fan motor through the DC MOTOR 2 Click board. Each SW2 press increments the duty cycle by one step (0 % → 33 % → 67 % → 100 %) and each SW3 press decrements it, so fan speed is directly proportional to duty cycle. Duty Counts represent the raw PWM compare values (period = 20000 counts). When the fan is fully stopped, the TB6593FNG driver is automatically put into low-power sleep mode to prevent wasted current through the windings. 7.2 Window System – Stepper Motor Full-Step Sequencing Direction Step # Coil A (PTA13) Coil B (PTD0) Coil C (PTA3) Coil D (PTC10) Active Pair UP (SW2 pressed) 1 ON OFF ON OFF AC 2 OFF ON ON OFF BC 3 OFF ON OFF ON BD 4 ON OFF OFF ON AD DOWN (SW3 pressed) 1 ON OFF OFF ON AD 2 OFF ON OFF ON BD 3 OFF ON ON OFF BC 4 ON ON OFF OFF AC Table: Stepper motor full-step sequencing for window control. The MCU drives the stepper motor through four GPIO lines connected to the H-Bridge Click board, using dual-coil activation (two coils energised per step) to maximise torque. Pressing SW2 executes the Up sequence AC → BC → BD → AD (window moves up), while SW3 executes the reversed Down sequence AD → BD → BC → AC (window moves down). Each press advances the motor by one full step with a 3 ms delay, and the coil pair remains energised as long as the button is held. When no button is pressed, all coils are de-energised to prevent motor winding overheating during idle periods. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE Fan Does Not Spin Verify PWM configuration and duty cycle Check DC Motor 2 Click wiring and enable pins Ensure the 5 V motor supply is present Stepper Not Moving Verify GPIO output configuration for coil pins Check H-Bridge Click wiring and coil order Confirm the step delay is not too short (motor stalls) Stepper Rotates Wrong Direction Invert the coil sequence in software (A→B→C→D vs D→C→B→A) Swap one coil pair on the H-Bridge output Buttons Not Responding Verify GPIO input configuration and pull-up/pull-down Add software debouncing Check that the correct button pins are mapped 9. Extending the Application The basic implementation can be extended in several ways: Feedback-Based Control Add temperature or Hall-effect sensors for closed-loop fan speed regulation Add end-stop switches or encoders for accurate window position tracking Automatic Comfort Modes Implement predefined climate or ventilation profiles Trigger comfort actions based on sensor thresholds CAN Communication Enable communication with other vehicle ECUs (e.g., HVAC master, door module) Receive comfort commands over the vehicle network Diagnostic Functions Add fault detection for stuck motors, over-current or open loads Expose diagnostic status via LEDs or debug UART Position Memory Store and restore window or fan positions in non-volatile memory Recall the last comfort state after each power-up State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver commands Immediate response to control signals Reliable actuator control for both speed and position In real systems: Redundancy is required for safety-relevant functions (e.g., anti-pinch on windows) Fault detection mechanisms are implemented (over-current, stall, over-temperature) Systems must comply with ISO 26262 (functional safety standard) where applicable Modern comfort modules also implement anti-pinch protection on power windows, ensuring the motor stops or reverses when an obstruction is detected — a safety-critical requirement for real vehicles. 11. Conclusion This module demonstrates how a simple embedded system can implement vehicle comfort control using GPIO inputs, PWM outputs, and stepper motor sequencing on the S32K344 platform. It shows how: Digital user inputs are acquired through GPIO Commands are decoded and processed in real time A DC motor is controlled using PWM for smooth speed regulation A stepper motor is controlled using a full-step coil sequence for precise positioning Result on FRDM-A-S32K344 Comfort ResultComfort Result The course provides a strong foundation for more advanced systems, including feedback-based control, CAN networking, diagnostics, and safety-oriented designs typical of automotive body-control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

MCXA153：LPSPI 数据突发传输。 你好， 参考手册 MCXA153 包含了对 TDBRn 和 RDBRn LPSPI 寄存器的描述： “TDBRn 和 RDBRn 寄存器支持向发送 FIFO 发送数据进行突发传输，以便与 DMA 控制器一起使用”。 请问有人可以分享一下使用这些寄存器进行突发传输的示例代码吗？ 此致 博格丹 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCXA Re: MCXA153: LPSPI data burst transfer. 嗨@bogdan_u 抱歉，目前没有相关示例。 我找到的最接近的 MCXA153 示例使用 LPSPI_MasterTransferEDMALite() 和 eDMA，但驱动程序通过 LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() 来定位 TDR/RDR，而不是突发别名窗口。 但我认为你可以尝试使用。 typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR 哈里

Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a vehicle lighting control system using analog input acquisition and FlexIO-based LED driving on NXP S32K3 microcontrollers. The application reads analog inputs from the Analog Key Click module (six push-buttons, each generating a distinct voltage level) and converts them into commands that drive a 4x4 RGB LED matrix. Each button press activates a specific lighting function — low beam, high beam, turn signals, brake lights, or hazard lights — while safety interlocks and blinking patterns run continuously in the background, mimicking how a real automotive Body Control Module (BCM) manages vehicle lighting. This example is based on Application Code Hub demonstrations for: Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 In this workshop, the Analog Key Click simulates six vehicle lighting controls. When the student presses a button, an analog voltage proportional to the pressed key is read by the MCU through the ADC (with software debouncing), decoded into a specific lighting command, and translated into an RGB pattern generated by the FlexIO peripheral. The 4x4 RGB Click then displays the corresponding automotive lighting behavior in real time — warm white for low beams, cool white for high beams, blinking amber for turn signals and hazards, and red for brake lights. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle lighting control system and the ideas behind an automotive Body Control Module (BCM). Use the Analog Key Click as a simulated multi-button user interface (six inputs on a single analog line). Acquire analog values (0–3.3 V) using the ADC and understand how multiple buttons share one channel through voltage division. Perform software debouncing and decode which button was pressed based on ADC value ranges. Drive an RGB LED matrix using the FlexIO peripheral, generating precise timing for WS2812-style LEDs. Implement safety interlocks between lighting functions (e.g., high beam requires low beam ON). Implement continuous background patterns such as blinking turn signals and synchronized hazards. Recognize the actuation data flow: analog input → ADC → command decoding → FlexIO LED output. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why lighting functions are relevant for automotive safety and driver visibility. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Analog Key Click (six buttons T1–T6, each generating a distinct analog voltage level) Processing: S32K3 MCU (reads the ADC, decodes the button, applies BCM logic, updates the LED state) Output: 4x4 RGB Click (16-LED matrix driven by FlexIO to display lighting patterns) This matches the classic flow of an embedded body-control system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button on the Analog Key Click (T1–T6) Each button generates a distinct analog voltage on the shared output line The ADC samples the voltage and converts it into a digital value The application decodes which button was pressed (with debouncing) The BCM logic applies interlocks and dependencies (e.g., high beam requires low beam) The FlexIO peripheral drives the RGB Click LEDs with the corresponding color pattern This loop runs continuously to ensure real-time lighting control, with blinking patterns and safety interlocks maintained in the background. System_Architecture_Lights.pngVehicle Lighting Control Application Architecture  4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The Analog Key Click outputs 0–3.3 V on a single analog line, with each button generating a specific voltage step. The ADC samples this voltage on ADC0_P0 (pin PTD1) at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). Each button corresponds to a specific value range, allowing six digital inputs to be read through a single ADC channel. ADC acquisition is the foundation of automotive sensing — used for switches, buttons, sensors, and many others. 4.2 Analog Multi-Button Decoding Instead of using six separate GPIO pins, the Analog Key Click uses a resistor ladder that produces a different voltage for each button press. The application performs software debouncing (multiple ADC samples must agree before a press is confirmed) and then compares the ADC value against predefined thresholds to identify which button (T1–T6) was pressed. This technique is common in automotive steering-wheel controls, where many buttons share a single analog line to save wiring and pins. 4.3 FlexIO — Driving the RGB Click LEDs FlexIO is a highly flexible peripheral on S32K3 that can emulate serial protocols like WS2812/NeoPixel. The RGB Click uses individually addressable LEDs that require precise timing (~800 kHz with strict pulse widths). FlexIO on PTA13 (FlexIO_D8) generates this waveform in hardware, without loading the CPU. Each of the 16 LEDs receives its color data through a serial stream, allowing independent control of color and brightness per LED. 4.4 RGB LED Mapping and Lighting Zones The 16 LEDs of the RGB Click are logically grouped into automotive lighting zones: LEDs 13, 14 → Low Beam Headlights (warm white) LEDs 8, 9, 10, 11 → High Beam Headlights (cool white) LEDs 0, 12 → Left Turn Signal (blinking amber) LEDs 3, 15 → Right Turn Signal (blinking amber) LEDs 1, 2, 5, 6 → Brake Lights (red) LEDs 0, 3, 12, 15 → Hazard Lights (synchronized blinking amber) 4.5 BCM Safety Interlocks and State Dependencies The application implements safety logic typical of a real Body Control Module: high beam can only be activated when low beam is already ON; turning OFF the low beam automatically disables the high beam; hazard lights synchronize left and right turn signals simultaneously; high beam state is preserved during hazard blinking and restored between cycles. These interlocks illustrate how real automotive lighting logic prevents unsafe combinations and preserves driver intent. 4.6 Data Flow at a Glance Button press → analog voltage on shared line → ADC sample → software debouncing → button decoding → BCM logic (interlocks + dependencies) → FlexIO WS2812 output stream → RGB LED color update. This direct chain from the student's finger to the LEDs is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the lighting application and process user inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the lighting application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Analog Key Click analog-click.jpg Six-button analog module used to simulate the vehicle lighting controls (headlights, indicators, brakes, hazards). 4x4 RGB Click 4x4-rgb-click.jpg 16-LED RGB matrix used to display the automotive lighting patterns in real time. USB-C / 12 V supply — Provides power and enables programming and debugging of the system through a single USB-C connection. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate a complete vehicle lighting control system. Vehicle Lighting Control on FRDM-A-S32K312 Vehicle Lighting Control on FRDM-A-S32K344 Lights_k312.png Lights_k344.png Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio 3.6.5 Select “Import project from Application Code Hub” Search for “Lighting” Select the desired project for your FRDM board Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB-C cable (and 12 V supply for FRDM-A-S32K312) Attach FRDM-K64 Click Shield, Analog Key Click and 4x4 RGB Click Verify wiring on PTA13 (FlexIO) and PTD1 (ADC) Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously; LEDs perform startup test sequence 5 Functional Validation Press buttons T1–T6 on the Analog Key Click Observe corresponding LED patterns on the RGB Click Verify safety interlocks (high beam requires low beam) Verify continuous blinking on turn signals and hazards RGB LEDs display the correct automotive lighting patterns for each button 7. Signal Behavior and Control Logic   The following diagram illustrates how each user input on the Analog Key Click is mapped to a specific lighting function and to the individual LEDs of the 4×4 RGB Click matrix. Each button (T1–T6) triggers a unique combination of LEDs, colors, and patterns, reproducing the behavior of a simplified automotive lighting system.   Led_Matrix_Mapping.png  The MCU continuously monitors the analog input from the Analog Key Click and decodes which button is pressed. Based on the detected input, the application activates the corresponding lighting function by driving the assigned LEDs on the 4×4 RGB Click through the FlexIO serial interface. Steady functions (Low Beam, High Beam, Brake) keep the associated LEDs constantly ON, while directional functions (Left Turn, Right Turn, Hazard) toggle the LEDs at approximately 1 Hz to reproduce the blinking behavior of real vehicle indicators. Additional control rules — such as High Beam requiring Low Beam to be active, or Hazard Lights preserving and restoring the High Beam state — reflect the interdependencies found in a real automotive body control module. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB-C cable and drivers Verify debugger connection Restart IDE No LEDs Lighting Up Verify FlexIO configuration on PTA13 Check 3.3 V and GND wiring on RGB Click Confirm data-line wiring to IN1 Buttons Not Detected Verify ADC0_P0 configuration on PTD1 Check 3.3 V and GND wiring on Analog Key Click Confirm software debouncing thresholds Wrong Button Triggered Recalibrate ADC value ranges for each button Verify power supply stability (3.3 V) Check for noise on the analog line Incorrect LED Colors or Timing Verify FlexIO clock configuration (WS2812 timing) Check LED index → color mapping in code Ensure RGB order (GRB vs. RGB) matches the LED type High Beam Not Activating Ensure low beam (T1) is ON first — BCM interlock Check application logic for beam dependencies 9. Extending the Application The basic implementation can be extended in several ways: Additional Lighting Functions Add fog lights, parking lights, or daytime running lights (DRL) Simulate reverse lights that activate when a specific input is triggered Adaptive Front Lighting Integrate a steering angle input (e.g., POT Click) to swivel the headlights Simulate cornering lights that turn on when indicators are active Ambient Light Sensing Add a light sensor to automatically enable low beams at dusk Implement smooth dimming between day and night modes Brake Light Enhancements Add an emergency brake flashing pattern for hard braking Implement a third brake light (single LED, always ON with brakes) CAN Communication Enable communication with other vehicle ECUs (e.g., BCM master, doors) Receive lighting commands over the vehicle network State Machine Implementation A more advanced approach is to implement a formal state machine covering: Off DRL / Parking Low Beam High Beam Hazard / Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator (LED) control with predictable timing Safety interlocks between lighting functions (high beam requires low beam) In real systems: Redundancy is required for safety-relevant functions (e.g., brake lights, hazards) Fault detection mechanisms are implemented (open lamp, short circuit, overcurrent) Systems must comply with ISO 26262 (functional safety standard) Vehicle lighting is one of the most safety-critical automotive functions because it directly affects driver visibility and vehicle conspicuity. Modern Body Control Modules implement extensive diagnostics, backup lighting strategies, and fail-safe defaults (e.g., hazard lights activated on power-loss recovery). 11. Conclusion This module demonstrates how a simple embedded system can implement complete vehicle lighting control using ADC input and FlexIO output on the S32K3 platform. It shows how: Multiple digital inputs can share a single analog line through resistor-ladder decoding Analog data is acquired, debounced and processed in real time Complex automotive lighting patterns are controlled through FlexIO-driven WS2812 LEDs Safety interlocks and background blinking patterns are managed by BCM-style logic Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 The course provides a strong foundation for more advanced systems, including adaptive lighting, CAN networking, ambient sensing, and safety-oriented designs typical of automotive body-control modules.

FAQs – NXP TJA1445, TJA1446, TJA1465 and TJA1466 CAN Transceivers with Partial Networking Introduction This document summarizes the most common customer questions regarding the NXP TJA1445, TJA1446, TJA1465 and TJA1466 CAN transceivers. It is intended as a practical guide covering basic product selection, partial networking, wake-up behavior, low-power operation, and key implementation considerations. 1) What are the TJA1445, TJA1446, TJA1465 and TJA1466 devices? They are high-speed CAN transceivers that provide the physical interface between a CAN/CAN FD controller and the two-wire CAN bus. All four devices support partial networking via selective wake-up, enabling low-power ECU operation while still allowing wake-up by a valid bus event or local wake input. 2) What is the main difference between the 1445/1446 and 1465/1466 families? The TJA1445/TJA1446 are high-speed CAN FD transceivers, while the TJA1465/TJA1466 are CAN SIC transceivers with Signal Improvement Capability, which reduces ringing and enables reliable communication in more complex topologies and at higher CAN FD speeds. The TJA1465/TJA1466 can support CAN FD up to 8 Mbit/s, whereas the TJA1445/TJA1446 target up to 5 Mbit/s CAN FD. 3) What is the difference between TJA1445 and TJA1446? Both support CAN FD and partial networking, but the TJA1446 adds advanced system monitoring features such as a Q&A watchdog, RST_N, LIMPFSO_N, and accurate VIO undervoltage/overvoltage monitoring. The TJA1445 does not include these monitoring and safety interface features. 4) What is the difference between TJA1465 and TJA1466? Both devices support CAN SIC, partial networking, and CAN FD/XL passive behavior, but the TJA1466 additionally integrates the watchdog, VIO monitoring, RST_N, and LIMPFSO_N fail-safe/limp-home support. The TJA1465 is the simpler CAN SIC partial networking transceiver without these advanced monitoring functions. 5) What is Partial Networking (PN), and why is it useful? Partial Networking allows ECUs that are not needed to remain in low-power mode while selected ECUs remain active on the bus. A sleeping node can be woken by a local wake event or by a remote selective wake-up frame containing the ECU-specific CAN identifier. This reduces vehicle power consumption and is especially useful for modern vehicles and EVs. 6) What is selective wake-up? Selective wake-up is the PN feature in which the transceiver does not wake up on arbitrary CAN traffic, but only on a valid wake-up frame matching the configured identifier, and optionally also matching DLC and data mask conditions. This helps keep undesired ECUs asleep even while other CAN messages are present on the bus. 7) What is the difference between CAN wake-up pattern (WUP) and wake-up frame (WUF)? A Wake-Up Pattern (WUP) is a low-level CAN bus pattern used to activate biasing and trigger wake-up when selective wake-up is not active. A Wake-Up Frame (WUF) is a valid CAN frame checked by the PN filter and used for selective wake-up when PN is configured and enabled. 😎 Which device should I choose for 8 Mbit/s CAN FD or more demanding network topologies? For higher CAN FD speeds and more challenging topologies, the TJA1465/TJA1466 are the preferred options because they include Signal Improvement Capability, which significantly reduces signal ringing and enables reliable operation up to 8 Mbit/s CAN FD. 9) Which VIO voltages are supported? The TJA1445/TJA1465 support interfacing with 1.8 V, 3.3 V, and 5 V MCUs. The TJA1446/TJA1466 are offered as dedicated variants: A = 1.8 V, B = 3.3 V, and C = 5 V-oriented / higher-voltage VIO variants. The 1446/1466 variant must be chosen to match the target MCU I/O level. 10) What supply pins do these transceivers use? They use three main supply pins: VBAT, VCC, and VIO. VBAT is the main supply and must be present in all operating modes, VCC supplies the CAN transmitter and biasing, and VIO supplies the digital interface level adaptation to the MCU. 11) What operating modes are available? The devices support Normal, ListenOnly, Standby, and Sleep modes. In Normal, the node can transmit and receive. In ListenOnly, the receiver is active but the transmitter is disabled. Standby is the first-level low-power mode with INH active, and Sleep is the deeper low-power mode with INH inactive. 12) What is the purpose of ListenOnly mode? ListenOnly mode is intended for node diagnosis, failure containment, and pretended networking use cases. In this mode the device can receive CAN traffic but does not actively transmit onto the bus. In low-power ListenOnly configurations, the receiver can remain active while minimizing current consumption. 13) How is local wake-up performed? Local wake-up is performed through the WAKE pin, which can be configured to detect rising and/or falling edges. A local wake-up request is registered when the new WAKE level remains stable for at least the configured wake filter time. 14) What are typical WAKE pin application examples? Typical examples include a switch to ground, connection to an ignition signal, or using the INH output of another transceiver as the wake source. We also provide design guidance for ESD protection and resistor/capacitor selection in these WAKE circuits. 15) What is the INH pin used for? The INH output is used to control external regulators or high-side enable logic so that the MCU and related circuitry can be automatically powered down in low-power modes and re-enabled on wake-up. In Sleep mode, it allows the transceiver to keep wake-up capability while the rest of the ECU is powered down. 16) How is selective wake-up configured? Selective wake-up is configured via SPI by programming the PN ID registers, ID mask, frame control, and data rate/filter registers. If data-field-based wake-up is needed, the DLC and data mask registers are also configured. The configuration becomes active after setting CPNC = 1 and PNCOK = 1. 17) What happens if I change a PN register after configuration? When the content of any PN-related register is changed, PNCOK is automatically cleared, and it must be set again to load and activate the updated PN configuration. 18) Can the device wake on identifier only, or also on data? Both are possible. The devices support identifier-only filtering when PNDM = 0, and identifier + DLC + data mask filtering when PNDM = 1. With data mask filtering, the wake-up decision also depends on the configured DLC and data mask bits. 19) Can Remote frames be used for selective wake-up? If PNDM = 1 and the selective wake-up checks the data field, Remote frames are not supported because they do not carry data. If Remote frames need to be able to trigger wake-up, identifier-only filtering should be used instead PNDM = 0. 20) How many MCU pins are needed to interface these devices? For the TJA1445/TJA1465, typically six MCU pins are needed: four SPI pins plus TXD and RXD. For the TJA1446/TJA1466, typically seven MCU pins are needed because the RST_N pin should also be connected to the MCU. 21) Are the SPI pins shareable with other peripherals? Yes. SCK, SDI, and SDO may be shared with other devices, but the transceiver requires its own dedicated SCSN chip-select. Daisy-chain SPI connections are not supported. 22) What are the GPIO pins used for? On the TJA1445B/TJA1465B, three GPIOs are available, and on the TJA1446/TJA1466, two GPIOs are available. They can be configured for general-purpose I/O and various special functions, including additional TXD/RXD, status signaling, wake-up input behavior, and other remote I/O style uses. 23) Can one transceiver be connected to two CAN controllers? Yes. GPIO1/2 can be configured as RXD2/TXD2, allowing a second CAN controller in the MCU to connect to the same transceiver. 24) What is TXEN_N and how does it behave? On the TJA1445B/TJA1465B, TXEN_N is the transmitter enable/disable control. A HIGH level on TXEN_N disables the CAN transmitter. In low-power modes, special care is needed so that the pin does not unnecessarily increase quiescent current if VIO remains present. 25) What extra features do TJA1446/TJA1466 provide for safety and system monitoring? The TJA1446/TJA1466 provide a Q&A watchdog, RST_N, LIMPFSO_N, and VIO undervoltage/overvoltage monitoring. They can supervise the MCU, detect fault conditions, trigger system reset, and support limp-home or fail-safe strategies in the ECU. 26) What is LIMPFSO_N used for? LIMPFSO_N can be configured either as a limp-home output or as a fail-safe output, depending on the system safety concept. In a limp-home application, it can activate backup hardware in case of failure. In a fail-safe application, it can keep safety-relevant hardware disabled until correct system operation is confirmed. 27) What is RST_N used for on TJA1446/TJA1466? RST_N is a bidirectional active-low reset pin used both to reset the MCU in response to transceiver-detected failures and to allow the transceiver to detect reset-related fault conditions from the system side. It should be connected to the MCU reset input. 28) What ESD robustness is specified on CANH and CANL? The quick reference data in the datasheets specifies ±8 kV IEC 61000-4-2 ESD handling capability on CANH and CANL. External protection components can still be considered if required by the application environment. 29) Is there any timing requirement for the first SPI access after power-up or wake-up? Yes. For the TJA1445/TJA1465 family, the first SPI interaction should occur within the MCU reaction timeout after power-up or wake-up from Sleep; otherwise the device may automatically enter Sleep mode with wake-up sources enabled. This mechanism helps limit battery drain if the MCU fails to initialize correctly. 30) Are there any common pitfalls when entering Sleep mode? Yes. Before entering Sleep, the required wake-up sources must be enabled and pending wake-up interrupts should be cleared. The transceiver will not enter Sleep unless at least one main wake-up source is enabled and all wake-up interrupts are cleared. 31) Can these devices support in-system MCU flashing through the CAN bus? Yes. The datasheets describe Start-to-Normal (SNM) behavior, which allows the device to enter Normal mode directly after boot if the CAN bus is held dominant before the internal check completes. This can support generic bootloader or end-of-line flashing use cases. 32) Are these devices safety-oriented parts? Yes. All four families were developed in compliance with ISO 26262 and achieve ASIL B. The TJA1446/TJA1466 go further with advanced monitoring and fail-safe-oriented interfacing. 33) Which packages are available? The TJA1445A/TJA1465A are available in SO14 and HVSON14, while the B variants are available in DHVQFN18. The TJA1446/TJA1466 are available in DHVQFN18. 34) Where can I find example initialization and SPI command guidance? For practical implementation guidance, we provide AN14388 for TJA1445/TJA1465 and AN14452 for TJA1446/TJA1466. These application notes include SPI usage guidance, initialization considerations, PN setup recommendations, WAKE pin examples, GPIO usage examples, and low-power mode handling. 35) In one sentence, when should I choose each family? Choose TJA1445 for CAN FD + PN, TJA1446 for CAN FD + PN + advanced system monitoring, TJA1465 for CAN SIC + PN + higher-speed or more demanding networks, and TJA1466 when you need CAN SIC plus advanced monitoring and safety-oriented system supervision. CAN PHY Transceiver

RW612非セキュアフラッシュ設定によりリセット機能が破損する こんにちは、 FRDM-RW612上でARM TF-MとZephyr（NXPダウンストリームv4.3.0）を使用している際に、奇妙なバグが発生しています。フラッシュメモリの一部領域を、セキュリティ保護機能のないLittleFSファイルシステムに使用したいと考えています。NXPのガイド（リンク）に従ってNS領域を追加したところ、ファイルシステムにその領域を正常に使用でき、Zephyr/FS APIやアクセスに関する問題も発生しませんでした。 私の問題は、CONFIG_FLASH KConfigオプションを有効にすると、ボードをリセットできなくなることです。tfm_platform_system_reset()、NVIC_SystemReset() を呼び出したり、物理的なリセットボタンを押したりしても、プロセッサがロックされてしまい、実際にはボードがリセットされなくなります。 デバッガーを使ってステップ実行したところ、デバッガーが切り離される直前に実行された最後の行は core_cm33.h:2683 でした。（__NVIC_SystemReset内）： SCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) | (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) | SCB_AIRCR_SYSRESETREQ_Msk ); リセット後にデバッガを接続すると、GDBはアドレス0x20005840のプログラムが永久に停止すると報告します。 非常に基本的なプログラムで同じことを試してみましたが、Zephyrのhello worldプログラムにCONFIG_FLASHを追加しても、リセットが同じように失敗します。 どんなご協力でもありがたいです。ありがとうございます！ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、@jm-streametric さん。お元気でお過ごしでしょうか。 この動作をより詳細に分析するために、ハローワールドのサンプルで行ったテストにおいて、追加した設定はCONFIG_FLASHのみであることを確認してもらえますか？それとも、ガイドから作成した設定（CONFIG_TFM_CUSTOM_DATA_IMPORT_REGION=y）を使用して、追加したNS領域も有効にしていますか？ 私はZephyr（v4.3.0 ダウンストリーム）のhello worldサンプルをCONFIG_FLASH設定のみを追加して実行しようとしましたが、ボードをリセットすることができました。 Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 投稿でボードを指定する際に誤りがありました。RW610を搭載したカスタムボードを使用していますが、フラッシュ構成はFRDM-RW612と全く同じです。CONFIG_FLASH=y に設定しても開発ボードをリセットすることはできますが、私のカスタムボードでは、以前の投稿で説明した問題が発生します。 TF-MとZephyrのリポジトリをFRDM-RW612のデフォルトに設定しても、CONFIG_FLASH=yの場合（カスタムデータ領域の有無に関わらず）、ボードをリセットできないという問題が発生します。RW610とRW612の間には、フラッシュメモリやFlexSPIに問題を引き起こす可能性のある違いはありますか？それとも、私のボードに別の問題があるのでしょうか？ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ジェイクさん。ご説明ありがとうございます。 RW610とRW612の違いは、RW610が802.15.4プロトコルをサポートしていないため、FlexSPI周辺機器との違いはないという点です。 これらの機能をテストする際に、FRDM-RW612ファイルを使用しているかどうか確認していただけますか？それとも、Zephyrでボード用のディレクトリを独自に作成しましたか？ また、リセット機能を使わずにサンプルを正しく実行することは可能でしょうか？それとも、MCUはどこかの時点でハードフォルトを起こすのだろうか？ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 私のボードは同じフラッシュICを使用しているため、フラッシュ機能のテストには未修正のFRDM-RW612ファイルを使用しています。私のボードには様々な**ペリフェラル**が搭載されており、それぞれにオーバーレイを適用していますが、今回のフラッシュテストケースではそれらのオーバーレイは適用しません。 フラッシュメモリは正常に動作しており、カスタムリージョン内のフラッシュデータにも問題なくアクセスできます。カスタム領域外のフラッシュにアクセスするとエラーが発生しますが、これは想定内の動作です。唯一うまくいかないのは、物理的に、またはtfm_platform_system_reset()を使用してボードをリセットしようとすると、上記のようにボードがロックされてしまうことです。 ありがとう Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality ジェイクさん、情報ありがとうございます。 つまり、プロジェクトに「CONFIG_FLASH=y」設定を追加すると、アプリケーションは通常どおり実行できるが、リセット操作を行うとプログラムがアドレス0x20005840で無限ループに陥る、ということでしょうか？ リセット原因が登録されているかどうかを確認するために、リセットステータスレジスタ（ SYS_RST_STATUS ）をご確認いただけますでしょうか？さらに、セキュリティ保護機能のないバージョンのボードで全てのテストを実施しましたか？ FRDM-RW612ボードをお持ちでしたら、カスタムボードでのテストに追加しているのと同じ設定で、この現象が発生するかどうかをテストして教えていただけますでしょうか？ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 つまり、プロジェクトに「CONFIG_FLASH=y」設定を追加すると、アプリケーションは通常どおり実行できるが、リセット操作を行うとプログラムがアドレス0x20005840で無限ループに陥る、ということでしょうか？ はい、その通りです。ボードの電源を一度切ってから入れ直す以外に、プログラムを再起動する方法がありません。 リセット原因が登録されているかどうかを確認するために、リセットステータスレジスタ（ SYS_RST_STATUS ）をご確認いただけますでしょうか？ 現在、zephyrのサンプル「hello_world」を使ってこれらのテストを試しています。CONFIG_FLASH=y の有無に関わらず、またカスタムボードでも実際の FRDM-RW612 でも、SYS_RST_STATUS の値を取得できませんでした。物理的なリセットボタン（SOC上のPDnに接続）を押したり、printf文の後にtfm_platform_system_reset()を呼び出したり、NULLポインタにアクセスしてハードフォルトを発生させたりしてみましたが、いずれもリセットステータスレジスタに値が表示されませんでした。 リセット前、リセット後のアドレス 0x20005840 のループ内、およびリセット後の BL2 ステージでサンプリングを試しましたが、SYS_RST_STATUS が 0 であるかどうかは関係ありませんでした。チェック方法が間違っているかどうかわかりませんが、GDB (west attach 経由) を使用してデバッグし、 p *((PMU_Type*)0x40031000u)を印刷して PMU ブロック内の値を取得しました。参考までに、サンプリングしたときの SYS_RST_EN レジスタは常に 0x39 でした。 さらに、セキュリティ保護機能のないバージョンのボードで全てのテストを実施しましたか？ はい、ビルドフォルダを削除してからwest build -b frdm_rw612/rw612/nsを実行することで、これらのテストをすべてクリーンにビルドします。 独自のボードでテストするために追加している設定と同じ設定で、この動作が発生するかどうか教えてください。 私の設定のほとんどは、Flexcommポート上のペリフェラルに関するものです。この問題に関する私のテストでは、TF-Mプロファイルに加えた変更点のみを残しました。TF-M FWUパーティションを使用して無線ファームウェアアップデートを実行できるように、私はTF-Mのラージプロファイルではなくミディアムプロファイルを使用しています。そのため、ZephyrのKConfigオプションを3つ追加しました。 CONFIG_TFM_PROFILE_TYPE_AROTLESS=y CONFIG_TFM_SFN=y CONFIG_TFM_ISOLATION_LEVEL=1 そして、TF-Mモジュールフォルダで編集したのは、modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nxp/frdmrw612/config.cmakeにある以下のプロファイル設定だけです。 set(TFM_PROFILE "profile_medium_arotless" CACHE STRING "TF-Mプロファイル") これは「profile_large」から変更されたものです ご協力ありがとうございました。他に何か情報が必要な場合はお知らせください。 Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality ジェイクさん、質問に答えていただきありがとうございます。 FRDM-RW612でテストしたとのことですが、このボードでもリセット動作を再現できますか？あなたの設定とTF-Mのビルド変更（TF-Mプロファイル）を追加して試してみましたが、それでもあなたの動作を再現できませんでした。 もしこの現象を再現できるのであれば、FRDM-RW612でその動作を再現するために実行した詳細な手順を共有していただけますでしょうか？ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 基板の回路図が間違っていたこと、そして私が使用していたフラッシュチップがFRDM-RW612のようなW25Q512ではなく、実際にはW25Q01だったことが分かりました。W25Q512を基板にはんだ付けしたところ、問題なくリセットできるようになりました。先ほどはお時間を無駄にしてしまい、申し訳ありませんでした。 私のチップに対応するようにフラッシュメモリの設定を再構成する方法に関する資料はありますか？flash_config.c に fc_flexspi_nor_config_t 構造体が見つかりました。これはW25Q512用に設定されているのですが、新しいチップに対応するために変更する必要がある箇所を具体的に説明したドキュメントやガイドはありますか？ Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ジェイク。気にしないでください。根本原因を教えてくれてありがとう。 残念ながら、フラッシュメモリの再構成に関する具体的なガイドはありません。ただし、異なるフラッシュを使用する場合にどのような変更が必要になるかについては、RD-RW612-BGAボードのディレクトリ構造、またはIRIS-W1-EVKボードのディレクトリ構造（u-Blox社製）を参考にすることができます。これらのボードはどちらもFRDMボードとは異なるフラッシュICを搭載しています。 TF-Mの場合、RD-RW612-BGA非セキュアバージョンのボードのディレクトリも存在し、これも必要な変更の参考として利用できます。 お役に立てば幸いです！

S32K566 IMCR Confilct 错误 MCU: S32K566 MCAL 套餐：RTD 0.8.0 (S32K5_RTD_0_8_0_D2512_ASR_REL_4_9_REL_4_9_REV_0000_20251205) 端口插件：端口_TS_T40D85M8I0R0 工具：EB Tresos / NXP MCAL 生成器 (McalGenerator_Nxp_S32K5-0.8.0) 说明： 我正在尝试使用端口 MCAL 插件在 S32K566 上配置多个 ADC0 模拟输入引脚。当我配置多个 ADC0 输入通道时，代码生成器会报告 IMCR 冲突错误。 配置： PCR 209 → 模式： ADC0_ADC0_CH2_P2_IN （映射到 SIUL2_3 上的 PORT209） PCR 226 → 模式： ADC0_ADC0_CH4_P4_IN （映射到 SIUL2_3 上的 PORT226） 问题 当仅配置一个 ADC 引脚时，代码生成成功，但 IMCR 索引报告为 0。 当添加第二个 ADC 引脚时，会出现 IMCR 冲突错误，因为两个引脚都映射到 SIUL2_3 上的同一个 IMCR 索引 0。 我调查了 port_s32K5_resource.m 文件，发现所有 ADC0 模拟输入通道都是使用 IMCR 映射 0 定义的 需要更改哪些配置才能解决这个问题？ 如果这是一个已确认的错误，有没有已知的解决方法？ Re: S32K566 IMCR Confilct Error 你好@JaeHeonJeong 由于 S32K5 仍处于 NPI 状态，我建议使用专用的支持渠道——要么直接 FAE 支持，要么在此处输入票证 (https://support.nxp.com/s/?language=en_US)，这样它就会分配给区域 FAE 团队。也可能有专门针对贵公司的私人社区空间，但我不确定，因为我没有访问权限。 该社区尚未支持 S32K5。感谢您的理解。 此致， Lukas Re: S32K566 IMCR Confilct Error ADC0 通道可能基于不同的 IO 引脚和不同的 IMCR。而每个 IO 引脚都专用于一个 IMCR 不确定 K556 设置是关于什么的，因为它是一款非常新的设备。您能提供截图吗？

这是 2026 年最好的 IPTV 服务吗？我的诚实评论（体育、电影& 更多） 和你们中的许多人一样，我一直在寻找真正可靠的 iptv 服务，经历了令人沮丧的过山车之旅。我尝试过无数的 iptv 供应商，处理过缓冲、链接中断和一夜之间消失的 iptv 订阅等问题。在过去的一年里，我对各种iptv服务进行了广泛的测试，现在我非常高兴地与大家分享我的经验，我相信这可能是我迄今为止发现的2026年最佳iptv解决方案： 伟大的IPTV. 如果你想在2026年寻找一家可靠的IPTV服务提供商，提供优质的流媒体服务，并能真正发挥作用，那么GreatestIPTV将脱颖而出，成为潜在的最佳IPTV服务： ✅ 海量& 多元化频道阵容拥有来自世界各地的令人难以置信的直播电视频道选择。如果您需要覆盖美国的 iptv 或来自英国、加拿大和许多其他地区的频道，他们都有。体育、最新电影、新闻、儿童内容、纪录片和全天候流媒体都包括在内。这是一个综合性的 iptv 订阅，可满足不同的兴趣爱好。 📡 高质量、稳定的流媒体（高清& 4K Live IPTV） 性能是关键，而这正是其出众之处。他们提供令人惊叹的 4k iptv 和全高清直播流。质量出众，流媒体加载速度快，即使在重大体育赛事直播期间，我也几乎没有遇到缓冲。如果您正在寻找 4k IPTV，这款产品值得考虑。 📱 可在所有设备上无缝运行（2026 年 Firestick 最棒的 IPTV？）灵活性至关重要。支持 m3u 和 Xtream 代码等标准协议。这意味着它的用途非常广泛。许多人会同意，它是Firestick 4K（可能成为Firestick 2026年的最佳IPTV）、智能电视（三星、LG等）、安卓盒子、使用IPTV Smarters或TiviMate等应用程序的手机以及个人电脑（VLC）等设备上的IPTV的最佳IPTV。我在这些地方都用过它，没有问题。它兼容您喜欢的所有 iptv 流媒体。 🧠 轻松设置& 提供真正有用的支持 开始使用 iptv 订阅非常简单，这要归功于他们清晰的指南。真正让他们在 iptv 提供商中脱颖而出的是他们的支持。他们反应迅速，乐于助人，这在 iptv 服务领域实属罕见。 💸 有竞争力的定价& 可选择购买 IPTV 试用版 考虑到质量和广泛的频道列表，我发现这项服务的定价非常有竞争力。您可以直接从他们的网站上轻松购买 iptv 计划。最重要的是，他们提供试用账户。这是在承诺购买 iptv 高级计划之前了解它是否最适合您的最佳 iptv 方法。我使用试用版订阅了 iptv，它让我信服。 🔚 我对寻找2026年最佳IPTV的最终结论 如果您还在寻找2026年最佳IPTV服务，或者已经厌倦了不可靠的IPTV供应商，我强烈建议您访问GreatestIPTV。它兑现了承诺，拥有庞大的频道列表（包括美国的优质iptv和英国的iptv内容），稳定的4k IPTV直播，广泛的设备支持（使其在许多平台上最适合IPTV），以及出人意料的出色客户服务。这是我最近体验过的最好的 iptv，如果你想购买真正有效的 iptv，它值得考虑。 如果您正在考虑这家 iptv 提供商，或者好奇它与我测试过的其他 iptv 订阅相比如何，我很乐意回答您的任何问题。让我们来谈谈如何找到最适合您的 iptv 解决方案！

Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600 * Detailed Description: * Updated the example lwip_FreeRTOS_s32K344 to enable pinging the lwIP stack from the command window * *ping 192.168.0.209 * *Pinging 192.168.0.209 with 32 bytes of data: *Reply from 192.168.0.209: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.209: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.209: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.209: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.209: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * * EVB: * - All jumpers in default positions. * * Configuration: * - Updated pin configuration * - Modified FXOSC, PLLAUX + dividers * - Platform: added EMAC_0_IRQn interrupt * - IP address set to 192.168.0.209 and enabled UDP_ECHO, etc. * - Added DIO * * main.c * - Updated only the header * device.c * - No updates * test.c * - Commented out the code that shuts down the TCP/IP stack after its predefined timeout * - Added LED task * * ------------------------------------------------------------------------------------------------ * Test HW: MR-CANHUBK344 * MCU: S32K344 * Debugger: Lauterbach Trace32 * Target: internal_FLASH * EVB connection: EMAC <-> RDDRONE-T1ADAPT <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11

Linkserverのダウンロードはひどく失敗しました MCUXpresso IDEとLinkserverの両方が必要なのですが、Linkserverをダウンロードしようとすると、ウェブサイトを操作するよりもひどい頭痛がします。もし関係あるなら、私はこのリンクからダウンロードしようとしていました。システム（Win10および様々なLinuxディストリビューションで試しました）、ブラウザ（Chrome、Firefox、Brave）、リンクサーバーのターゲットプラットフォーム（MAC、Linux、Windows、aarch64）に関係なく。必ず404エラーが発生します。「[url]に一時的な問題が発生しているか、移動した可能性があります」。 以前（2024年頃）このソフトウェアを使ったことがありますが、そのような問題は記憶にありません。サイト運営者やホスティング担当者は、ユーザーが「万が一のために」古いバイナリをバックアップしておくことを期待しているのでしょうか？ MCUXpresso IDEについてはまだ触れていませんでしたね。なぜ？昨日ダウンロードしたのですが、今日試してみたところ、アプリとサービス→ソフトウェアアカウント→プロファイル→アプリとサービス、といった画面をループしてしまい、時折「予期しないエラー」が表示されます。このサイトはどうしてこんなに不具合が多いのですか？最新バージョンが3月26日版であることは承知していますが、それでも、このような事態はあってはならないはずです。 Re: Downloading Linkserver fails miserably 私も同じように感じています。すべてのLinkServerダウンロードリンク（例：macOS aarch64、linux) では、10 バイトのファイル「NOT FOUND」が返されます。ダウンロードリンクを修正できますか？ Re: Downloading Linkserver fails miserably こんにちは、 申し訳ありませんが、ダウンロードサイトに問題が発生しています。ウェブチームに問題を報告しました。 どのバージョンをご希望か教えていただければ、お送りいたします。   BR アリス Re: Downloading Linkserver fails miserably 探しているのはこれです： MacOS Arch64 用 LinkServer インストーラー PKG Rev 26.3.1232026 年 3 月 26 日 26.17 KB LINKSERVER-MACOS-AARCH Re: Downloading Linkserver fails miserably おい、 古いバージョンが利用可能かどうかはわかりませんが、問題がなければ、Linux x86-64 用の最新版 (LinkServer_26.3.123.x86_64.deb.bin) が望ましいです。 よろしくお願いします。 Re: Downloading Linkserver fails miserably こんにちは、皆さん。 そちら側で再度ダウンロードを試していただけますか？   BR アリス Re: Downloading Linkserver fails miserably 試してみましたが、やはりうまくいきません... 同じ手順で、異なるバージョン、異なるブラウザを使用しても、どれも機能しません。「cache.nxp.com」が原因です。応答しない Re: Downloading Linkserver fails miserably こんにちは、私もWindows版で同じ問題が発生しています。私も送っていただけますか？ ありがとう、 ロバート Re: Downloading Linkserver fails miserably Linux版でも同じ問題が発生しています。幸いなことに、pyOCDを使うことができました。 https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/nxp/frdm_mcxa153/board.cmake#L9 「pyocd pack install MCXA153VFM」でサポートをインストールしたら、正常に動作するようになりました！ Re: Downloading Linkserver fails miserably こんにちは。私もLinkserverユーティリティパッケージのWindowsインストーラーが必要です。 Re: Downloading Linkserver fails miserably 皆さん、こんにちは。 LinkerServerがダウンロード可能になりました。 ご迷惑をおかけして申し訳ございません。ご質問やご不明な点がございましたら、お気軽にお問い合わせください。 よろしくお願いします。 BR アリス Re: Downloading Linkserver fails miserably 皆さん、こんにちは。 ご迷惑をおかけして誠に申し訳ございません。 このチケットは私の側で最優先事項として設定し、できるだけ早く問題を解決するためにウェブチームにエスカレーションします。 いつもご利用いただき、ありがとうございます。 BR アリス Re: Downloading Linkserver fails miserably 笑 もしこんなに怪しくなかったら、これを手に入れるために「トレント」を探し回っていたでしょう。 Re: Downloading Linkserver fails miserably @Alice_Yang さん、これについて調べていただけますか？ Re: Downloading Linkserver fails miserably 今後何かをダウンロードする必要がある場合は、以下の方法で、くだらないキャッシュやログイン追跡を無視してファイルを直接取得できます。 https://www.nxp.com/lgfiles/updates/mcuxpresso/LinkServer_26.5.59.x86_64.deb.bin パスを完全に一致させる必要があるかもしれませんが、まあ、私の場合はうまくいきました。あなたにも役立つことを願っています。 Re: Downloading Linkserver fails miserably 新しい一日、同じ問題。キャッシュサーバーを修正するか、ダウンロードへの公開パスを提供してもらえませんか？ Re: Downloading Linkserver fails miserably 大爆笑。その通りです。 🤣 私はここで問題の数を数えるのをずいぶん前にやめました。オープンソースソフトウェアの代替手段と比べて、どれほど多くの独自仕様のゴミが壊れているかは、まさに奇跡的だ。無意味な「DRM」は、これらすべてに拍車をかけるものだ。あらゆる独自製品を比較すると、これが最も厄介なものだ。 私は疲れている。これと格闘するよりも、もっと使いやすい他のプラットフォームに移行する方がはるかに良い考えだ。

i.MX8QX6 – UUUフラッシュがlibusbエラーで停止する（LPDDR4行アドレスの不一致の可能性） こんにちは、 現在、以下の構成で作業を行っています。 SoC： NXP i.MX8QX6（MIMX8QX6AVLFZAC） LPDDR4: Micron MT53E768M32D2ZW-046 (AIT:C) Yoctoリリース: walnascar-6.12.34-2.1.0 Universal Update Utility を使用して imx-boot-imx8qxp-mek-sd.bin-flash_spl イメージをフラッシュしようとしています。 フラッシュ処理中にツールが停止し、最終的にLIBUSB_ERROR_NO_DEVICEを報告して、フラッシュ処理が完了しなくなります。 トラブルシューティングを実施しました 問題を特定するために、以下のことを試みました。 以前のリリースに含まれる古いimx-bootバイナリを使用してテストしました。 LF_v6.6.52-2.2.2_images_IMX8QXPC0MEK LF_v5.15.32-2.0.0_images_IMX8QXPC0MEK UUUツールの最新バージョンを使用しました フラッシュ処理を複数回繰り返した しかし、その行動は変わらない。 疑われる原因 メモリデバイスの仕様を精査した結果、社内調査により、 SoCのDDRコントローラ構成と実際のLPDDR4デバイスとの間でDDRアドレス行構成の不一致が発生している可能性があることが示唆されました。 Micronのデータシートによると、メモリデバイスは行アドレスR[16:0]（17行）を使用します。 しかし、SoCのドキュメントによると、DDRコントローラは最大16行のアドレス線（R0～R15）をサポートしているようです。 この違いから、 DDRコントローラ構成とメモリデバイスのアドレス指定方式に不一致がある可能性があると推測されます。 質問 LPDDR4構成における行アドレスの不一致が原因で、起動初期段階でUUUフラッシュ処理がLIBUSB_ERROR_NO_DEVICEエラーで停止する可能性はありますか？ これが原因である可能性がある場合、 i.MX8QX6 上のこの LPDDR4 デバイスの DDR パラメータを正しく設定するための推奨される方法は何ですか？ 構成はNXPが提供するDDRツール/RPAツールを使用して生成すべきでしょうか、それともこの特定のメモリデバイス用のリファレンス構成は既に用意されているのでしょうか？ 何かご助言やご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: i.MX8QX6 – UUU flashing stalls with libusb error (possible LPDDR4 row address mismatch) こんにちは、 @Yogesh_   私は自分のimx8qxpボードでテストしました。問題は発生していません。私は以下のコマンドを使用してflash.binファイルをフラッシュします。 uuu -b emmc .\imx-boot-imx8qxpc0mek-sd.bin-flash   Snipaste_2026-03-17_10-23-38.png ご質問にお答えします： Q1 & Q2：これはこの問題を引き起こしません Q3：DRAMの適切なパラメータを設定する必要があります。次に、新しいflash.binファイルを再コンパイルします。しかし、おっしゃる通りです。お使いのDRAMの行数は17ですが、imx8qxpがサポートする最大行数は16です。ですから、16行の別のDRAMに交換してください。つまり、最大4GB（32Gb）のLPDDR4密度をサポートするには、構成は16行2ランクでなければならない。 BR Re: i.MX8QX6 – UUU flashing stalls with libusb error (possible LPDDR4 row address mismatch) UUUツールがハングアップ／停止する問題を解決するための代替案をご提案いただけますでしょうか？以前のバージョンと最新バージョンのUUUツール両方を試してみましたが、依然として同じエラーが発生します。 Re: i.MX8QX6 – UUU flashing stalls with libusb error (possible LPDDR4 row address mismatch) ご返信ありがとうございます。 Yoctoで生成されたimx-boot-imx8qxp-mek-sd.bin-flash_splとflash.binイメージの両方のログを添付しました。flash.binはRPAツールを使用して設定され、SCFWポーティングキットでビルドされ、正常に起動しています。 Re: i.MX8QX6 – UUU flashing stalls with libusb error (possible LPDDR4 row address mismatch) こんにちは、 @Yogesh_ 以下のコマンドを実行した結果はどうなりますか？ uuu -lsusb BR Re: i.MX8QX6 – UUU flashing stalls with libusb error (possible LPDDR4 row address mismatch) こんにちは、 @Yogesh_ 以下のコマンドは使用しないでください sudo uuu -v -b emmc_all imx-boot-imx8qxp-mek-sd.bin-flash_spl 以下のコードを使用してください。 uuu -b emmc imx-boot-imx8qxp-mek-sd.bin-flash_spl 1. Windows OS上でuuuツールを実行してみてください。 2. 下記のコマンドの結果を共有してください。 uuu -lsusb BR

LS1043 DDR DQS vs DQ Calibration Hi, I am running QCVS DDR 1D margin test on my board, and I am confused about how this test runs internally. My questions are: Q1: The 1D margin test sweeps the strobe signal in the data eye for each byte lane. How is it achieved? I don't see any configuration register for adjusting the data eye timing for each byte lane. Is this configuration register reserved and not shown to users? Q2: Will centering the data eye for each byte lane be automatically done in the DDR initialization flow without any customer register configuration ? Re: LS1043 DDR DQS vs DQ Calibration Dear @lingjun , Regarding your questions: Q1. The tool “sweeps the strobe signal in the data eye for each byte lane, using small timing steps”, this sweep happens after the controller has already initialized using its normal internal calibration sequence. NXP does not expose these  DQS delay registers in the memory map, they are internal PHY registers accessed by the controller firmware used during training and by the QCVS validation tool.   Q2. Yes, the DDR controller performs automatic read/write leveling and strobe centering. The QCVS margin test uses this calibrated specific value timing as the reference point.   Best regards LFGP Re: LS1043 DDR DQS vs DQ Calibration Dear LFGP:  thanks your reply, It really helpful to me. But in margin test in my board occur another wired question.  From  QCVS FAQ Guide.pdf the  bright green cells means which the controller  automatic choose strobe center point. My test result show below, the Lane 0~2  have the bright green cells,but Lane 3 don't have bright green cell. Q1: Does the controller choose strobe point fall into the failing regions cell and so no bright green shown in Lane3? Q2: can your give some suggestion how to deal with the Lane3 issue?  thanks very much. IMG_20260309_162518.jpg

xtest 在 IMX8MPLUS 上失败 在 imx8mplus-BB 开发板上，安装 optee，在上面运行 xtest，下面会出现以下错误。 z23cc_0-1725417836722.png 后来，我将 r = ADBG_EXPECT_TEEC_RESULT(c,TEEC_ERROR_SECURITY,res)修改为 r = ADBG_EXPECT_TEEC_RESULT(c,TEEC_ERROR_GENERIC,res)，然后又发现了下面的问题。 z23cc_1-1725417906601.png z23cc_2-1725418162989.png 非常困惑，不知道如何解决 ！ Re: xtest fails on IMX8MPLUS 这是个老话题了，你可能已经不关心答案了，但也许其他人也会遇到同样的问题，并看到这个帖子。 在我的案例中，切换到另一个软件版本似乎就能解决问题。当我使用 optee-os 和 x-test6.6.52-2.2.0 ("4.4.0") 时，测试失败的方式与您提出的相同。在 optee-os 和 x-test6.12.49-2.2.0 ("4.8.0") 上，这种情况不再重现。 如果你是从头开始构建，记得使用恩智浦的 github 仓库进行 optee 和 x-test： -https://github.com/nxp-imx/imx-optee-test -https://github.com/nxp-imx/imx-optee-os Re: xtest fails on IMX8MPLUS 你使用的是哪个版本的 BSP？ Re: xtest fails on IMX8MPLUS 事实上，就是这个提交修复了我的问题（6.12 版有，6.6 版没有）： commit c6c7967f74d4c6267750b3ff42067c004f8cad33 Author: Jens Wiklander Date: Fri Dec 13 10:01:33 2024 +0100 core: pta: secstore: decrease TA buffer install_ta() uses a buffer allocated from the heap while hashing a TA while installing it. The buffer size is 8kB which is a bit large to reliably allocate from the heap, so decrease it to 1kB. Signed-off-by: Jens Wiklander Acked-by: Jerome Forissier Reviewed-by: Etienne Carriere diff --git a/core/pta/secstor_ta_mgmt.c b/core/pta/secstor_ta_mgmt.c index 162de43be..b8dc9283c 100644 --- a/core/pta/secstor_ta_mgmt.c +++ b/core/pta/secstor_ta_mgmt.c @@ -44,7 +44,7 @@ static TEE_Result install_ta(struct shdr *shdr, const uint8_t *nw, struct tee_tadb_ta_write *ta; void *hash_ctx = NULL; size_t offs; - const size_t buf_size = 2 * 4096; + const size_t buf_size = 1024; void *buf; struct tee_tadb_property property; struct shdr_bootstrap_ta bs_ta;

MCUXpresso IDEでJ-link seggerを使用してデバッグするためのピン配置MCXN546VKLTを備えたPCBの回路を作成する こんにちは@Habib_MS 、DCDC と LDO の両方の構成用の MCXNxxxVDFT の回路が記載されたドキュメントがありますが、MCUXpresso IDE で J-link segger を使用して適切にデバッグするには、DCDC と LDO の両方の構成用の MCXN546VKLT の PCB 回路とその電源ピン配列を構築する必要があります。j-link segger を使用してデバッグするためのピン配置回路図をご指導の上、お送りください。 コアとメモリ 開発ボード Re: To make a circuit of PCB with pinouts MCXN546VKLT to debug using J-link segger with MCUXpresso I こんにちは@Elakiya 、 ご投稿ありがとうございます。 回路設計が異なるため、デバイスを LDO モードと DCDC モードの両方で同時に動作するように構成することはできません。HLQFP‑100 パッケージの場合、2 つのモード間の唯一のハードウェアの違いはDCDC_LXピンにあります。 具体的には： LDO モードで動作している場合、DCDC を無効にするには、 DCDC_LX ピンをフローティングのままにする必要があります。 DCDC モードで動作する場合、 DCDC インダクタを DCDC_LX ピンに接続する必要があります。 詳細については、最新の UG10092 (rev 5) を参照してください。     お役に立てれば幸いです。他にご質問がございましたらお知らせください。 BR セレステ Re: To make a circuit of PCB with pinouts MCXN546VKLT to debug using J-link segger with MCUXpresso I 解決策をありがとうございます

SDK 2.2.0 MKL16Z128xxx4 和 McuXpresso IDE V25.6 你好，我以前使用过 McuXpresso V19.xxx 和上述 SDK，在构建时没有问题。 将集成开发环境升级到 V25.6 后，fsl_common.c 出现问题，错误信息是 构建目标：MKL16_BLE_CLIENT_V1_0.axf 调用：MCU 连接器 arm-none-eabi-gcc-nostdlib-Xlinker-Map= " mkl16_ble_client_v1_0.map "-Xlinker --gc-sections -Xlinker -print-memory-usage -Xlinker --sort-section=alignment -Xlinker --cref -mcpu=cortex-m0plus -mthumb -T MKL16_BLE_CLIENT_V1_0_Debug.ld -o"MKL16_BLE_CLIENT_V1_0.axf"./source/LPS22HH_driver.o ./source/LSM6DS3_driver.o ./source/STHS34PF80TR_driver.o ../source/VL53L1_driver.o ./source/adc_driver.o ./source/batt_driver.o ./source/ble_driver.o ./source/cop_driver.o ./source/eeprom_driver.o ./source/fonts.o./source/i2c_driver.o ./source/init_dev_from_struct.o ./source/irq_driver.o ./source/led_driver.o ./source/lptmr_driver.o ./source/main.o ./source/mode_driver.o ./source/mtb.o。/source/oled_driver.o。/来源/semihost_hardfault.o。/source/spi_driver.o。/source/swd_driver.o。/source/uart_driver.o。/drivers/fsl_adc16.o。/drivers/fsl_clock.o。/drivers/fsl_cmp.o。/drivers/fsl_common.o。/drivers/fsl_dac.o。/drivers/fsl_dma.o。/drivers/fsl_dmamux.o。/drivers/fsl_flash.o。/drivers/fsl_gpio.o。/drivers/fsl_i2c.o。/drivers/fsl_i2c_dma.o。/drivers/fsl_llwu.o。/drivers/fsl_lpsci.o。/drivers/fsl_lpsci_dma.o。/drivers/fsl_lptmr.o。/drivers/fsl_pit.o。/drivers/fsl_pmc.o。/drivers/fsl_rcm.o。/drivers/fsl_rtc.o。/drivers/fsl_sim.o。/drivers/fsl_smc.o。/drivers/fsl_spi.o。/drivers/fsl_spi_dma.o。/drivers/fsl_tpm.o。/drivers/fsl_tsi_v4.o。/drivers/fsl_uart.o。/drivers/fsl_uart_dma.o。/board/clock_config.o。/board/peripherals.o。/board/pin_mux.o。/cmsis/system_mkl16z4.o C: /nxp/mcuxpressoide_25.6.136/ide/plugins/com.nxp.mcuxpresso.tools.win32_25.6.0.202501151204/Tools/bin/.../lib/gcc/arm-none-eabi/14.2.1/../../../../../../arm-none-eabi/bin/ld.exe:。/drivers/fsl_common.o：在函数 `__assertion_failed' 中： C:\Software Projects\ConSyTech\MKL16_BLE_CLIENT_V1_0\workspace\MKL16_BLE_CLIENT_V1_0\Debug/../drivers/fsl_common.c:49:(.text.__assertion_failed+0x10)：对 “dbgConsole_printf” 的未定义引用 已用内存区域大小 区域大小%已用内存年龄 程序闪存： 12728B 128KB 9.71% Sram: 2968 B 16 KB 18.12% collect2.exe：错误：LD 返回 1 退出状态 make[1]：*** [makefile:48: MKL16_BLE_CLIENT_V1_0.axf] （译注：MKL16_BLE_CLIENT_V1_0.axf）。错误 1 make：*** [makefile:39: all] 错误 2 " make-r-j8 all " 以退出代码 2 终止。版本可能不完整。 08:49:54 版本失败。3 个错误，0 个警告。(耗时 430 毫秒） 请教如何纠正。 克莱斯 Re: SDK 2.2.0 MKL16Z128xxx4 and McuXpresso IDE V25.6 你好@claeskjellstrom 请添加 debug_console 和 serial_manager 元器件。如果问题仍然存在，请分享您的项目，我将帮助您进行检查。   谢谢！   BR 爱丽丝 Re: SDK 2.2.0 MKL16Z128xxx4 and McuXpresso IDE V25.6 嗨，Alice，因为时间有点紧，我又换回了 11.9.1Build 2710 版的集成开发环境，但现在的问题似乎是我根本看不到"Clocks Diagram" ，MKL02 和 MKL16 MCU 都是如此。它们之前一直在工作，但无论" 关于透视" ，我都看不到它们，而且由于它是一个裸金属项目，一直在低功耗（不同的时钟设置）下运行，所以非常依赖它们。说来话长，我尝试了各种方法，最后在 MKL02 项目中，通过更改 mexfile，我现在可以看到它们了。 如果我从一个完全空白的项目开始，除了某些文件外，总是看不到时钟图？ 此致 克莱斯       Re: SDK 2.2.0 MKL16Z128xxx4 and McuXpresso IDE V25.6 通过删除 x:// Program Data 文件夹/NXP/!!!!!!!!!delete 下以前版本的所有安装文件解决了这个问题。 Re: SDK 2.2.0 MKL16Z128xxx4 and McuXpresso IDE V25.6 您好， 谁能描述一下 mcuXpresso 版本和 mcu 配置工具之间的关系？如前所述，我使用的是 IDE 11.9.1，并尝试了不同版本的配置工具。我用 MKL16Z128xxx 的正确 SDK 制作了一个干净的项目，调用了所有驱动程序（fsl）等。据我所知，如果你有很久以前的配置工具生成的 mex 文件，你就不需要下载它，但显然版本真的很糟糕。当我运行配置工具作为独立组网 (SA)时，我收到的消息要么是太旧的版本，要么是更新版本。似乎什么都不合适。 Re: SDK 2.2.0 MKL16Z128xxx4 and McuXpresso IDE V25.6 您好， 对所附的屏幕转储有何评论？

S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hardware: Board: S32G399A-VNP-RDB3 Boot Sequence: U-Boot loads M7 binary → startm7 command → Linux boots on A53 Software: M7 Core: RTD 5.0.0 (S32_RTD_5_0_0_QLP03_D2505) with FreeRTOS and IPCF A53 Cores: Linux Scarthgap BSP 46 Development Tool: S32 Design Studio for S32 Platform 3.5 Current Working Status: I have coupled several M7 example applications that work correctly: CAN communication DIO (LED control) GPT (timers) All these applications function properly in M7 standalone mode. But when I try and add the IPCF example to this, I'm facing the below problem. When the M7 RTD application calls Mcu_InitClock(), the A53 side experiences corrupted UART output and system hang. After U-Boot executes the startm7 command, the A53 becomes unresponsive and cannot proceed to Linux boot. U-Boot Command Sequence: => dcache off => mw.q 0x34000000 0x0 0x60000 => fatload mmc 0:2 0x80000000 myBin.bin => cp.b 0x80000000 0x34300000 ${filesize} => startm7 0x34500400 => boot Observed Behavior with Mcu_InitClock() M7 Console: Successfully displays all logs for UART, CAN, and DIO examples M7 application runs normally and all peripherals function correctly A53/U-Boot Console: Displays garbage characters: �c?�p8�p� System becomes completely unresponsive Cannot proceed to Linux boot I have also noticed that the linux device tree specifies the IPCF address range used for PFE reservations, I have modified the device tree with proper reservations for IPCF address range. [Linker snippet: MEMORY { int_itcm : ORIGIN = 0x00000000, LENGTH = 0x00000000 /* 0KB - Not Supported */ int_dtcm : ORIGIN = 0x20000000, LENGTH = 0x0000E000 /* 64K */ int_dtcm_stack : ORIGIN = 0x2000E000, LENGTH = 0x00002000 /* 8K */ int_sram_shareable : ORIGIN = 0x24000000, LENGTH = 0x00004000 /* 16KB */ int_hse_sram_shareable : ORIGIN = 0x22C00000, LENGTH = 0x00004000 /* 16KB */ IPCFsharedRAM (RW) : ORIGIN = 0x34000000, LENGTH = 0x00300000 /* 3MB */ int_sram_c0 : ORIGIN = 0x34300000, LENGTH = 0x00200000 /* 2.0MB - M7_0 code/data */ int_sram_no_cacheable_c0 : ORIGIN = 0x34500000, LENGTH = 0x00100000 /* 1MB, includes int_results */ ram_end_c0 : ORIGIN = 0x34600000, LENGTH = 0x00000000 /* End of core 0 ram */ int_sram_c1 : ORIGIN = 0x34600000, LENGTH = 0x00100000 /* 1.0MB */ int_sram_no_cacheable_c1 : ORIGIN = 0x34700000, LENGTH = 0x00080000 /* 512KB */ ram_end_c1 : ORIGIN = 0x34780000, LENGTH = 0x00000000 /* End of core 1 ram */ int_sram_c2 : ORIGIN = 0x34780000, LENGTH = 0x00100000 /* 1MB */ int_sram_no_cacheable_c2 : ORIGIN = 0x34880000, LENGTH = 0x00080000 /* 512KB */ ram_end_c2 : ORIGIN = 0x34900000, LENGTH = 0x00000000 /* End of core 2 ram */ int_sram_c3 : ORIGIN = 0x34900000, LENGTH = 0x00000000 /* 0MB */ int_sram_no_cacheable_c3 : ORIGIN = 0x34900000, LENGTH = 0x00000000 /* 0KB */ ram_end_c3 : ORIGIN = 0x34900000, LENGTH = 0x00000000 /* End of core 3 ram */ ram_rsvd2 : ORIGIN = 0x34900000, LENGTH = 0x00AFFFFF /* End of SRAM */ LLCE_CAN_SHAREDMEMORY : ORIGIN = 0x43800000 LENGTH = 0x3C800 LLCE_LIN_SHAREDMEMORY : ORIGIN = 0x4383C800 LENGTH = 0xa0 LLCE_BOOT_END : ORIGIN = 0x4383C8A0 LENGTH = 0x50 LLCE_MEAS_SHAREDMEMORY : ORIGIN = 0x4384FFDF LENGTH = 0x20 } ] I felt the garbage value was becuase the RTD Mcu_InitClock() function calls Clock_Ip_ResetClockConfiguration(), which attempts to write all MC_CGM MUX selectors. This includes MC_CGM_1 registers that control A53_CORE_CLK and XBAR_CLK.(?) When M7 reconfigures these shared clock sources, the A53 LinFlexD_0 UART loses its correct clock configuration, resulting in corrupted output and subsequent system hang. I would appreciate guidance on the following points: 1. Clock Initialization Sequence What is the recommended RTD clock initialization approach for AMP mode when U-Boot manages the clock tree? Should M7 skip Mcu_InitClock() entirely? Is there a specific API or configuration to enable only M7 partition clocks without affecting shared resources? 2. Is there a reference project or application note that demonstrates RTD with IPCF in AMP mode using the U-Boot boot flow? I would requrest someguidance on proper clock and resource partitioning for AMP scenarios. So, I would greatly appreciate your insights on this if you could help me with either; Documentation or guidelines for RTD initialization sequence in AMP mode Required U-Boot or ATF modifications to properly configure M7 peripheral clocks XRDC configuration examples for M7 and A53 resource partitioning Reference to any application notes or example projects for this use case I did come across scattered community posts on similar issues, but was not able to conclude anything. Came cross this document today [https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/nxp-designs%40tkb/692/1/S32G_Bootloader_V1-2022.0909.pdf] and felt it is closer to what I'm facing and would appreciate if there was a cleaner and updated version of this. Thankyou. Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot That's a great piece of advise 😊 Thankyou for your time in actually reading my questions and answering them. Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hello, @sanchez  Thanks for your post. The issues are likely caused by the clock/resource, etc. confliction between M and A cores For multi-core working on S32G, it is suggested introducing a bootloader to boot the board, the sample method is documented in AN13750 BR Chenyin Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hello, @sanchez  You are welcome, it is my pleasure to assist. BR Chenyin Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Adding few more details regarding the versions I'm using: Linux BSP 46 EB tresos AutoCore 8.8.7 for S32G3 GoldVIP-S32G3-1.15.0 S32DS.3.6.1 SW32G_RTD_4.4_5.0.0 SW32G_RTD_4.4_5.0.0_QLP04 SW32G_IPCF_4.11.0 S32G Real-Time security Crypto Driver(5.0.0 QLP01) - Not available S32G Safety Software Framework (2.0.3) - Not available S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hi @chenyin_h  As suggested by you, I'm trying to introduce a bootloader to the board following steps from AN13750. I've copied all the necessary files from plugins into the Tresos directory and have a fullt trusted license as well on the EB Tresos License Administrator. But to follow the next steps and remove un-required components, I;m getting this No License found error. I've referred to the bootloader manual and developer notes as well for GoldVIP and it is not clear to me what license is missing! Could you shed some light on this, please? S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hi again @chenyin_h  I've also tried installing this version, but I got this error while activating the license; Am i missing something? Activating NodeLocked License 6xxx-xxxx-xxxx-xxxx, Number Of Licenses: 1 Status: 4, Creating request Status: 5, Request created Status: 6, Context created Status: 7, Connected to remote server Status: 8, Request Sent Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 10, Waiting for response Status: 9, Polling for response Status: 11, Done ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hello, @sanchez  Thanks for your reply. For building with bootloader project, I suggest using the following tool(EB tresos studio 27.1)instead of "EB tresos AutoCore 8.8.7 for S32G3". chenyin_h_0-1770606533038.png BR Chenyin Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Sure, thankyou Re: S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hello, @sanchez  Thanks for your reply. According to the log you shared, it is because "quantity specified exceeds maximum quantity allowed". As you may know, EB is not NXP's product, we obtained evaluation licenses from EB, and while users exceed the quantity EB defined, the license shown in the download page could not be used any more. Let me report it soon and usually it would be updated in a few days, sorry for your inconvenience. BR Chenyin  Re S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hi @chenyin_h  I’m following up regarding the status of the license update, as it has been couple of days and I have not yet seen it reflected on your website. We are currently working against a firm timeline, so I would greatly appreciate a clear update on where things stand and the expected timeframe for completion. If possible, please also confirm that I will be notified as soon as the license becomes active and publicly available. BR Re: Re S32G399 AMP Mode M7 RTD Clock Initialization Crashes A53/U-Boot Hello, @sanchez  Now, our team is in the process of updating the activation code information in the system. It will be reflected later. Also, please check the mail of your inbox of the community. BR Chenyin

S32K376 VCU – S32DS で SPI ベースの DIO (MSDI) を実装するにはどうすればよいですか? 私は、MSDI デバイスが SPI 経由でコネクテッドされているS32K376 VCU POC ボードに取り組んでいます。 回路図から、次の MSDI 関連信号が使用されます。 schourasiya_0-1770014720752.png SPI信号: MSDI_CS、MSDI_SCLK、MSDI_MOSI、MSDI_MISO 制御/ステータス信号: MSDI_INTB、MSDI_WAKEB アナログ/MUX信号: MSDI_AMUX デジタル入力と出力に使用されるMSDI SGx / SPxピン 私はこれをMBDT（Simulink）とS32構成ツール（S32CT）を使用して実装したいのですが、正しいソフトウェアアプローチがわかりません。 具体的には、以下の点について指導が必要です。 S32CTのSPIピンを外部MSDIデバイスで動作するように設定して使用する方法 MSDI_INTB と MSDI_WAKEB をどのように構成するか(DIO vs ICU/EXTI)、MBDT でどのように処理するか MSDIデジタル入力/出力（SGx / SPx）がソフトウェアでどのようにアクセスされるか MCAL サポート パターンはありますか? それとも、カスタム SPI コマンド + アプリケーション レベルの抽象化として実装する必要がありますか? MSDI_AMUX の一般的な処理方法 (ADC パス / 使用法の想定) S32K376/96 VCU および BMS サンプル POC プロジェクト用のMBDT + S32CTを使用してこのフローを示す実用的なリファレンスまたは例はありません。 推奨される実装アプローチ（ステップバイステップまたはブロックレベル）を提案していただけますか？ Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? こんにちは@mariuslucianand これについてコメントしていただけますか? よろしくお願いいたします。 BR、ペトル Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? こんにちは、みんな、 誰も返信しなかったので、私は自分の方でいろいろ試してみたところ、同じVCU POCボード上でS32K396を使用して作業している際に、外部MSDIデバイスがLPSPI3経由で接続されていることがわかりました。しかし、実行時にバスフォルトが発生し、SPIの初期化が失敗します。 確認された問題 Lpspi_Ip_Init() の実行中に、コードが次の箇所でエラーを起こします。 Base->CFGR1 = PhyUnitConfigPtr->Cfgr1; デバッガーの観測結果： schourasiya_0-1776852999802.png schourasiya_1-1776853010374.png インスタンス = 3 ベースアドレス = 0x40364000 レジスターには次のように記載されています: VERID = 53248 PARAM = 53249 CR = 53249 SR = 53249 続いて：BusFault：不正確なデータアクセスエラー ハードフォルトのエスカレーション：これは、LPSPI3へのレジスタアクセス時に発生します。 以下の件についてご協力をお願いします： 添付ファイルを参照して、具体的にどの設定/構成が間違っているのでしょうか？または MSDI I/Oピンデータに正しくアクセスするために、どのような追加設定/MBDTブロックセットが必要ですか？ schourasiya_2-1776853047143.png Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? こんにちは、 MC33CD1030 ICからデータを取得するためのSPIペリフェラルの設定方法については、以下の記事を参照してください。 方法: NXP MBDTを使用してS32K396BMS-EVB上のMSDI MC33CD1030 なお、この記事はMC33CD1030 ICとの間でデータを送受信するためのSPI構成に焦点を当てています。CD1030に関する詳細については、データシートを参照してください。 よろしくお願いいたします。 ソリン・バンシラ