Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT). 3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow. 4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.

Designing a CAN-Based Communication Hub with the S32N55 using Model Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement. 3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation. 4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent. Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate. 5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors 6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.

S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello, I am developing an application on the following platform: MCU: NXP S32K314 RTD 7.0.0 (AUTOSAR MCAL) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 During development, I encountered a deadlock related to high-priority interrupts and would like to ask whether my understanding is correct and whether there is a recommended solution. Background FreeRTOS specifies that ISRs with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY must not call FreeRTOS APIs. However, I found that many RTD MCAL APIs internally execute FreeRTOS critical section APIs through the following call chain: MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() and MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() This behavior exists even in APIs that only perform simple peripheral register accesses, such as DIO and GPT. Problem When a MCAL API is called from a high-priority ISR (priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY), the internal call to taskENTER_CRITICAL_FROM_ISR() causes the FreeRTOS interrupt masking state to become inconsistent. As a result, after taskEXIT_CRITICAL_FROM_ISR() returns, BASEPRI is not restored correctly, causing lower-priority interrupts such as SysTick and PendSV to remain masked. The scheduler eventually stops because xPortSysTickHandler() is no longer executed. I was able to reproduce this issue using APIs such as: Dio_FlipChannel() GPT (PIT) interrupt processing Other MCAL APIs that use SchM exclusive areas Current Workaround To avoid modifying RTD-generated source code directly, I used the GNU linker --wrap option to wrap the following functions: OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() The wrapper checks the current interrupt priority. Please refer to the attached WrapperExample.c. If the current ISR priority is higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, it skips the original function. Otherwise, it calls the original implementation. This workaround appears to resolve the deadlock while leaving the generated RTD source unchanged. Questions Is this behavior expected by design in the RTD MCAL? Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Is there an official or recommended solution for this problem that does not require modifying generated RTD source code? Any advice or recommendations would be greatly appreciated. Thank you.

S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 你好， 我正在以下平台上开发一个应用程序： MCU：NXP S32K314 RTD 7.0.0（AUTOSAR MCAL） FreeRTOS 7.0.0 S32 设计工作室 3.6.4 在开发过程中，我遇到了与高优先级中断相关的死锁，想请教一下我的理解是否正确，以及是否有推荐的解决方案。 背景信息 FreeRTOS 规定优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 的中断服务例程 (ISR) 不得调用 FreeRTOS API。 然而，我发现许多 RTD MCAL API 在内部通过以下调用链执行 FreeRTOS 临界区 API： MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() 以及 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() 即使在仅执行简单外设寄存器访问的 API（例如 DIO 和 GPT）中，也存在这种行为。 问题 当从高优先级 ISR（优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY）调用 MCAL API 时，对 taskENTER_CRITICAL_FROM_ISR() 的内部调用会导致 FreeRTOS 中断屏蔽状态变得不一致。 因此，在 taskEXIT_CRITICAL_FROM_ISR() 返回后，BASEPRI 无法正确恢复，导致 SysTick 和 PendSV 等低优先级中断保持屏蔽状态。 调度程序最终停止，因为 xPortSysTickHandler() 不再执行。 我使用以下 API 重现了这个问题： Dio_FlipChannel() GPT（PIT）中断处理 其他使用 SchM 专属区域的 MCAL API 当前解决方法 为了避免直接修改 RTD 生成的源代码，我使用了 GNU 链接器的 --wrap 选项来包装以下函数： OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() 该包装器会检查当前的中断优先级。 请参考附件WrapperExample.c 。 如果当前 ISR 优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY，则跳过原始函数。 否则，它将调用原始实现。 这种变通方法似乎可以解决死锁问题，同时保持生成的 RTD 源不变。 问题 RTD MCAL 的这种行为是设计预期的吗？ 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？ 任何建议或推荐都将不胜感激。 谢谢！

S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック こんにちは、 私は以下のプラットフォームでアプリケーションを開発しています: MCU:NXP S32K314 RTD 7.0.0(AUTOSAR・マカル) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 開発中に、優先度の高い割り込みに関連するデッドロックに遭遇しました。私の理解が正しいかどうか、また推奨される解決策があるかどうかをお伺いしたいと思います。 バックグランド FreeRTOSでは、configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い優先度を持つISRは、FreeRTOS APIを呼び出してはならないと規定されています。 しかし、多くのRTD MCAL APIは、内部的に以下の呼び出しチェーンを通じてFreeRTOSのクリティカルセクションAPIを実行していることがわかりました。 MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() そして、 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() この挙動は、DIOやGPTのような単純なペリフェラルレジスタアクセスのみを行うAPIでも存在します。 問題 MCAL API が高優先度 ISR (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY より高い優先度) から呼び出されると、taskENTER_CRITICAL_FROM_ISR() の内部呼び出しによって FreeRTOS の割り込みマスキング状態が不整合になります。 その結果、taskEXIT_CRITICAL_FROM_ISR() が戻った後、BASEPRI が正しく復元されず、SysTick や PendSV などの優先度の低い割り込みがマスクされたままになります。 xPortSysTickHandler() が実行されなくなるため、スケジューラは最終的に停止します。 以下のようなAPIを使用して、この問題を再現することができました。 Dio_FlipChannel() GPT(PIT)割り込みプロセッシング SchMの排他領域を使用するその他のMCAL API 現在の回避策 RTDで生成されたソースコードを直接変更することを避けるため、GNUリンカーの--wrapオプションを使用して以下の関数をラップしました。 OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() ラッパーは現在の割り込み優先度をチェックします。 添付のWrapperExample.cを参照してください。 現在のISRの優先度がconfigLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い場合、元の関数はスキップされます。 そうでない場合は、元の実装を呼び出します。 この回避策は、生成されたRTDソースを変更せずにデッドロックを解消するようです。 質問 この挙動はRTD MCALのデザイン上当然のことですか? 高優先度のISRからDIO、GPT、CAN、または他のMCAL APIを呼び出すのは推奨されますか? NXPは、ウォッチドッグサービスやGPIOトグルなどの高優先度リアルタイム機能に対して専用ドライバ(複雑デバイスドライバ)の実装を推奨していますか? GNUリンカーの--wrapオプションを使用してOsIf_Interrupts_SuspendAllInterrupts()とOsIf_Interrupts_ResumeAllInterrupts()をラップすることは、許容できる回避策でしょうか？ 生成されたRTDソースコードを変更する必要のない、この問題に対する公式または推奨される解決策はありますか？ 何かアドバイスやご提案があれば、大変ありがたく思います。 よろしくお願いします。

iMX8M Plus - Flexspi chip select pin On the i.MX8M Plus EVK, the ECSPI chip select signal can be configured using a GPIO pin. Could you please confirm whether FlexSPI also supports GPIO-based chip-select signals, or whether only the dedicated FlexSPI chip select pins can be used? As per our requirement, we need two chip select signals for FlexSPI. Kindly suggest the recommended configuration for supporting two FlexSPI devices. Re: iMX8M Plus - Flexspi chip select pin Hi @pengyong What we can do for two chip select of QSPI? This is also from our requirement. If there is lack of CS pin means, can we use the any gpio has a chip select? If it will work Re: iMX8M Plus - Flexspi chip select pin Hi @Govind1807  You could use a GPIO-based chip select signal. However, you only have two FlexSPI Flash devices. Why would you use a GPIO as the chip select signal? The imx8mp has four FLEX SS signals that can be used directly： https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h B.R

例tflm_cifar10_cm33_core0に tflm_label_image_ext_mem のメモリ設定を使ってもいいですか? 良い１日を。 現在はEIQ例tflm_cifar10_cm33_core0 を使ってNPUモードでモデル化しています。モデルデータはSRAMに保存されます。推論時間は良好です。そして、こちらがメモリ構成です。このeiq例を5クラスのモデル用に修正しました https://docs.nxp.com/bundle/AN14700/page/topics/eiq_enablement.html しかし今はモデルが大きくなり、NPU tfliteモデルを外部メモリ上で特定したいと考えています。モデルデータはFlashに格納されています。そして、こちらは eiq の例tflm_label_image_ext_memの設定です。 https://docs.nxp.com/bundle/AN14700/page/topics/imx_rt700_system_details.html 私の目標は、ソースコードをtflm_cifar10_cm33_core0から保持したい(tflm_label_image_ext_memで新しいソースコードを作成したくはありません)が、NPU tfliteモデルを外部メモリ上で特定したい ということです。 私の解決策は、上記の画像のように、メモリ構成をSRAMから外部メモリに変更することだけです。それで合っていますか？あるいは、他の設定も変更する必要があるのかもしれません。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは、 @nnxxpp さん。 ご説明ありがとうございます。 「--use-sequencer」を外部メモリモデルの実行と組み合わせて使用しないでください。 「tflm_label_image_ext_mem」例では、モデルが外部メモリから実行されるため、「--fetch-constants-to-sram」を残し、「--use-sequencer」は削除してください。 モデルを以下のように変換してみてください。 ./Neutronコンバータ \ --入力 QAT.tflite\ --出力 QAT_NPU.tflite\ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --定数をSRAMに取得   お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? @mayliu1 こんにちは。これは新たな問題です（まだ解決されていません）。この問題は、外部メモリ(SRAMではなく)でのNPU tfliteモデルのデプロイに関連しています。 現在はSDKs of MIMRT700のeiqサンプルtflm_label_image_ext_memを使っています。この例はCANうまく実行できます。この例はモデル mobilenetv1 で、サイズ=224、クラス数=1000です。 サンプルのモデルを自分のモデル(同じ分類モデル)に置き換えようとしましたが、クラス数を変えました。 ラベルを変えました。(レーベル名の場合)、 サンプルのモデルを自分のモデルに置き換え、名前は同じまま使っています model_data.h ファイル内のmodel_data_lenも変更しました。 ビルドはできましたが、デバッグを実行するとプログラムは「静的プロセッシング」で停止し、結果が出ませんでした。 上の画像には 「モデルハンドルを保存できません。完了したらneutronModelUnprepare()を呼び出せ」というメッセージがありますが、NXPの従業員の一人はエラーではないと言っていました。https://community.nxp.com/t5/eIQ-Machine-Learning-Software/eIQ-FAQ/ta-p/1099741 NPUモデルが外部メモリ上にあるCASE、拡張子.tflite モデルを使います(モデルがSRAM上で位置する場合はヘッダーファイル.hではありません)。 モデルをフラグで--fetch-constants-to-sramに変換して、外部メモリ上のNPUモデルをこのように位置づけています ./Neutronコンバータ \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --use-sequencer \ --定数をSRAMに取得   NXPから設定や設定(SOの変更方法や場所)のチュートリアルが見当たらなかったので、上記の手順で試しましたがうまくいきませんでした。 手伝ってもらえますか?ありがとう。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは@nnxxpp さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 返信が遅くなり申し訳ありません。 前回の投稿で、問題はすでに解決済みだと書かれていたことに気づきました。全てが正常に機能していると聞いて安心しました。 ご理解いただき、改めて感謝申し上げます。 よろしくお願いいたします。 5月

MIMXRT1052CVJ5Bの電源問題 MIMXRT1050HDUGの仕様にあるように、このMCUには2つのバージョンが存在します。電源設計の参考にするために、自分のMCUの具体的なバージョンをどのように特定すればよいでしょうか？ i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 ありがとう！ Re: MIMXRT1052CVJ5B供电问题 こんにちは、 @Simon_CHan さん。 NXPのRTシリーズ製品にご関心をお寄せいただき、またNXPコミュニティをご利用いただきありがとうございます。 i.MX RT1050 のチップ正誤表にある ERR011093 を参照してください。正誤表には、この問題は A1 シリコンで修正済みであると記載されています。したがって、最も簡単な方法は、チップのシルクスクリーンでシリコン リビジョンを確認することです。A は A0、B は A1 を示します。バージョンが B の場合は、問題は修正済みです。バージョンが A の場合は、正誤表で規定されているとおり、DCDC_IN/DCDC_IN_Q を 2.8 V ～ 3.0 V の範囲内に制御する必要があります。 上記の情報がお役に立てば幸いです。 よろしくお願いします 5月

ADC Configuration Issue Hi @Senlent , I have also same issue which you mentioned above. Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral? S32 SDK for S32K1 Re: ADC Configuration Issue Hello @praveen_ext , Considering the previous Community thread, the behavior in BCTU Control Mode is expected: when the ADC is controlled by BCTU in Control Mode, normal conversions cannot be started independently on the same ADC instance. This explains why the current sensing becomes more stable in Control Mode, but the voltage and temperature channels configured in the normal chain stop working. In Trigger Mode, the situation is different. This mode allows BCTU-triggered conversions as well as normal/injected conversions, but all these conversions still share the same ADC instance and therefore the same ADC conversion resources. For a time-critical current sensing use case, especially if synchronized with PWM, the important point is not only whether the conversion is possible, but also whether the sampling instant remains deterministic. From the shared data, the current-sense signal seems mostly stable, but it shows occasional large spikes/dropouts. These do not look like ordinary random analog noise only. They look more like event-related outliers, possibly caused by conversion scheduling, result handling or interaction between the BCTU-triggered conversions and the normal chain conversions on the same ADC peripheral. Therefore, I would suggest first isolating whether the issue is caused by the mixed use of the ADC instance: 1. Please run only the BCTU-triggered current sensing in Trigger Mode and completely disable the normal chain execution.    - Do the current-sense spikes still occur? 2. Please run only the normal chain conversions and disable the BCTU-triggered current sensing.    - Are the voltage and temperature channels still stable? 3. Please check whether the current-sense spikes correlate with the moment when the normal chain conversion is started by the application.  Could you also clarify how the normal chain conversion is started while the BCTU-triggered current sensing is running? For example, is the normal chain started periodically by software, from an interrupt or from another scheduler task? One more point to confirm: from your channel list, ADC1-P2 and ADC1-P3 seem to be mentioned both as BCTU current-sensing channels and as normal-chain channels. Could you please confirm whether these channels are intentionally used by both acquisition methods or if this is only a description/configuration mismatch?  If the spikes disappear when the normal chain is disabled, then the likely issue is not the ADC electrical configuration itself, but the timing/scheduling of two acquisition flows on the same ADC instance. In that case, possible workarounds would be: - keep the current-sensing channels exclusively under BCTU control, - move the slower voltage/temperature measurements to another ADC instance, if available, - or schedule the normal chain conversions only in a time window where they cannot interfere with the BCTU/PWM-synchronized current measurement.   After this isolation test, it is still recommended to check the analog front-end, especially for the continuously noisy signals: - source impedance of the measured signal, - external RC filter values, - ADC input capacitor value, - capacitor placement close to the MCU ADC input pin, - whether the configured sampling time is sufficient for the given source impedance and external components.   Similar ADC accuracy/noise-related discussions are available here: - Issue with Inaccurate ADC Values on S32K3:   https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/m-p/2033042   - Smoke detector interfacing with FS32K146HAT0MLLT:   https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/m-p/1773787   - S32K3 Confusion about ADC accuracy and results:   https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/m-p/2006783   Best regards, Pavel

MIMXRT1052CVJ5B power supply problem As indicated by the MIMXRT1050HDUG, there are two versions of the MCU. How do I determine my specific version to guide my power supply design? i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 Thanks! Re: MIMXRT1052CVJ5B供电问题 Hi @Simon_CHan , Thank you for your interest in NXP's RT series products and for using the NXP community. You can refer to ERR011093 in Chip Errata for the i.MX RT1050. The Errata documentation states that this issue has been fixed in A1 silicon. Therefore, the simplest method is to check the chip silkscreen for Silicon Rev: A indicates A0, and B indicates A1. If it's version B, the issue has been fixed; if it's version A, you need to control DCDC_IN/DCDC_IN_Q within the 2.8 V–3.0 V range as required by Errata. I hope the above is helpful to you. Best Regards May

ARA240(.dvm)用のカスタムONNX/TFLiteモデルをコンパイルする方法は?(搬送波はi.MX95 FRDMを使用しています) 私はi.MX95 FRDMのARA240 M.2アクセラレータを評価しています。 ランタイムは正常に動作しています。 ARA240はPCIe経由で検出されます。 nnapp は提供された .dvm を正常に実行しますモデル. ランタイムSDKs(rt-sdk-ara240)とPython DVAPIバインディングがインストールされています。 しかし、自分でMobileNetモデルを展開したいのですが、モデルを.dvmにコンパイルするためのツールチェーンが見つかりません形式。 私の質問は以下のとおりです。 カスタムONNX/TFLiteモデルを.dvmにコンパイルする際のサポートワークフローは何ですか?ARA240用ですか？ Ara2コンバータ(またはdvconvert/dvnc)は公開されているのか、それともRuntime SDKsとは別に配布されているのか? NXPがサポートするカスタムCNNモデルを展開する方法はありますか(例:MobileNet) を ARA240 に移植する際に、私が見落としている点はありますか？ どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします！

How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) I'm evaluating the ARA240 M.2 accelerator on the i.MX95 FRDM. The runtime is working correctly: ARA240 is detected over PCIe. nnapp successfully runs the provided .dvm models. The Runtime SDK (rt-sdk-ara240) and Python DVAPI bindings are installed. However, I would like to deploy my own MobileNet model, and I'm unable to find the toolchain required to compile models into the .dvm format. My questions are: What is the supported workflow to compile a custom ONNX/TFLite model into .dvm for ARA240? Is the Ara2 Converter (or dvconvert/dvnc) publicly available, or is it distributed separately from the Runtime SDK? Is there an NXP-supported way to deploy custom CNN models (e.g. MobileNet) onto ARA240, that I am missing? Any guidance or documentation would be greatly appreciated. Thanks!

ユーザー空間からカーネルのrpmsgバッファにアクセスする こんにちは、 IMX8MPのMPUとMCU間で通信はできました。しかし、ユーザー空間から共有メモリのデータにアクセスしたいのです。これに関する例はありますか？ imx_rpmsg_pinpong.c についても質問したいのですがデバイスドライバは、カーネル空間とユーザー空間間の通信のためにLinuxのユーザースペースI/Oを処理するように拡張可能です。 よろしくお願いします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Accessing my kernel rpmsg buffer from user space こんにちは、 私も同じ問題に取り組んでいます。あなたが提示した例は、カーネルモジュールで動作します。 しかし、実はユーザースペースのアプリケーション例を探しています。Linux側でユーザースペース内で動かせるサンプルCプログラムを教えてもらえますか? ありがとう！ Re: Accessing my kernel rpmsg buffer from user space こんにちは、 @ababatola さん。 お元気でお過ごしでしょうか！返信が遅くなり申し訳ありません。 i.MX 8M Plus SDKsにあるrpmsg_lite_str_echo_rtosマルチコアの例を見ることをお勧めします。これはシンプルなアプリケーションで、Cortex AからCortex Mへメッセージを送信し、M4が受信した内容を表示し、同じメッセージを確認応答として返します。 SDKは https://mcuxpresso.nxp.com/ からビルドしてダウンロードできます これがあなたにとって有効かどうか教えてください。 よろしくお願いします、 ヘクター。

如何为 ARA240 (.dvm) 编译自定义 ONNX/TFLite 模型？（载板型号为 i.MX95 FRDM） 我正在评估 i.MX95 FRDM 上的 ARA240 M.2 加速器。 运行时运行正常： 通过 PCIe 检测到 ARA240。 nnapp 成功运行提供的 .dvm 文件模型。 已安装运行时 SDK (rt-sdk-ara240) 和 Python DVAPI 绑定。 但是，我想部署我自己的 MobileNet 模型，却找不到将模型编译成 .dvm 文件所需的工具链。格式。 我的问题是： 将自定义 ONNX/TFLite 模型编译成 .dvm 文件的受支持工作流程是什么？适用于 ARA240？ Ara2 变流器（或 dvconvert/dvnc）是公开提供的，还是与运行时 SDK 分开分发的？ NXP 是否支持部署自定义 CNN 模型（例如）MobileNet) 到 ARA240，我漏掉了什么吗？ 任何指导或文件都将不胜感激。 谢谢您！

MIMXRT1052CVJ5B供电问题 从MIMXRT1050HDUG可知，MCU有两个版本，那我要如何确定自己的版本，从而确定我的供电设计呢 i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 谢谢！ Re: MIMXRT1052CVJ5B供电问题 Hi @Simon_CHan ,  感谢您关注恩智浦RT系列产品以及使用NXP社区。 您可以参考 Chip Errata for the i.MX RT1050 中的 ERR011093 。该问题在 Errata 里说明已经 Fixed in A1 silicon 。所以最简单的方法是看芯片丝印Silicon Rev： A 表示 A0，B 表示 A1 。如果是 B 版本，则该问题已修复；如果是 A 版本，则需要按 Errata 要求将 DCDC_IN/DCDC_IN_Q 控制在 2.8 V–3.0 V 范围内。 希望以上对您有帮助 Best Regards May

iMX8M Plus - Flexspiチップセレクトピン i.MX8M Plus EVKでは、ECSPIチップ選択信号をGPIOピンで設定できます。 FlexSPIがGPIOベースのチップセレクト信号もサポートしているのか、それとも専用のFlexSPIチップセレクトピンのみが使えるのか確認していただけますか? 当社の要件に基づき、FlexSPIには2つのチップセレクト信号が必要です。FlexSPIデバイスを2台サポートするための推奨構成をご提案ください。 Re: iMX8M Plus - Flexspi chip select pin こんにちは@pengyong QSPIの2チップセレクトで何ができるでしょうか?これも私たちの要件です。もしCSのピン手段が不足している場合、チップセレクトがあるGPIOを使ってもいいのでしょうか?うまくいくなら Re: iMX8M Plus - Flexspi chip select pin こんにちは、 @Govind1807さん GPIOベースのチップセレクト信号を使うこともできます。しかし、FlexSPIフラッシュデバイスは2つしかありません。なぜGPIOをチップセレクト信号として使用するのですか？ imx8mpには4つのFLEX SS信号があり、直接使用できます: https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h BR

ADC構成の問題 こんにちは、 @Senlent さん。 私も上記で述べられたのと同じ問題を抱えています。 外部発振器のクロックは25MHzです。S32K322のデータシートによると、ADCは最大80MHzをサポートしているので、プリスケーラーは2MHzに設定しています。また、サンプリング時間を1.2マイクロ秒に設定し、BCTUモードをトリガーモードに設定しました。しかし、同じADC0ペリフェラルでBCTU方法とノーマルチェーン方法を同時に実行しても、依然としてノイズの多いデータが得られます。同じADC0ペリフェラルで両方を安全に動かす回避策や代替方法はありますか? S32 SDK for S32K1 Re: ADC Configuration Issue こんにちは、 @praveen_ext さん。 前回のコミュニティThreadを考慮すると、BCTUコントロールモードでADCが制御されている場合、同じADCインスタンス上で通常の変換を独立して開始できません。これが制御モードで電流検出が安定する一方で、通常のチェーンで設定された電圧と温度チャネルが機能しなくなる理由を説明しています。 トリガーモードでは、状況は異なります。このモードでは、BCTUトリガーによる変換と通常の/注入による変換の両方が可能ですが、これらの変換はすべて同じADCインスタンスを共有するため、同じADC変換リソースが使用されます。特にPWMと同期している時間的に重要な電流センシングのCASEでは、変換が可能かどうかだけでなく、サンプリング瞬間がデターミニスティックなままであるかどうかが重要なポイントです。 共有データから判断すると、電流検出信号は概ね安定しているように見えるが、時折大きなスパイクやドロップアウトが見られる。これらは普通のランダムなアナログノイズのようには見えません。これらはイベント情報関連の異常値のように見え、コンバージョンのスケジューリング、結果処理、またはBCTUトリガーの変換と同じADCペリフェラルでの通常のチェーン変換の相互作用が原因と考えられます。 したがって、まずは問題の原因がADCインスタンスの混在使用にあるかどうかを特定することをお勧めします。 1. BCTUトリガーによる電流検出のみをトリガーモードで実行し、通常のチェーン実行は完全に無効にしてください。 電流感知スパイクはまだ発生しますか？ 2. 通常のチェーン変換のみを実行し、BCTUトリガーによる電流検出を無効にしてください。 - 電圧と温度チャネルはまだ安定していますか? 3. 電流センススパイクがアプリケーションによって通常の連鎖変換が開始される瞬間と相関しているかどうかを確認してください。  また、BCTUトリガー電流検出が稼働している間に通常のチェーン変換がどのように開始されるのかも説明していただけますか?例えば、通常のチェーンはソフトウェアによって定期的に開始されるのか、割り込みからですか、それとも別のスケジューラタスクからですか? もう一つ確認したい点ですが、あなたのチャンネルリストを見ると、ADC1-P2とADC1-P3はBCTUの電流感知チャネルと正規連鎖チャネルの両方として言及されているようです。これらのチャネルが両方の取得方法で意図的に使われているのか、それとも単なる説明や設定の不一致なのか確認いただけますか?  通常のチェーンが無効化されたときにスパイクが消えた場合、問題はADCの電気構成自体ではなく、同じADCインスタンスで2つの取得フローのタイミングやスケジューリングにある可能性が高いです。その場合、回避策として考えられるのは以下の通りです: - 電流検出チャネルをBCTUの制御下に置くこと、 - 利用可能な場合は、より低速な電圧/温度測定を別のADCインスタンスに移動します。 - または、通常のチェーン変換をBCTU/PWM同期電流測定に干渉しない時間帯内にスケジュールする。   この絶縁テスト後も、特に連続的にノイズの多い信号についてはアナログフロントエンドの確認が推奨されます。 - 測定信号のソースインピーダンス、 - 外部RCフィルタ値、 - ADC入力コンデンサ値、 - コンデンサをMCU ADC入力ピンの近くに配置すること、 - 設定されたサンプリング時間が、指定されたソースインピーダンスと外部コンポーネントに対して十分であるかどうか。   同様のADC精度／ノイズ関連の議論は、こちらでもご覧いただけます。 - S32K3におけるADC値の不正確さに関する問題： https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/mp/2033042   - 煙感知器とFS32K146HAT0MLLTのインターフェース接続： https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/mp/1773787   - S32K3におけるADCの精度と結果に関する混乱： https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/mp/2006783   よろしくお願いいたします。 パベル

iMX8M Plus - Flexspi 芯片选择引脚 在 i.MX8M Plus EVK 上，可以使用 GPIO 引脚配置 ECSPI 片选信号。 请问FlexSPI是否也支持基于GPIO的片选信号，还是只能使用FlexSPI专用的片选引脚？ 根据我们的要求，FlexSPI 需要两个片选信号。请推荐支持两个FlexSPI设备的配置方案。 Re: iMX8M Plus - Flexspi chip select pin 嗨@pengyong 对于 QSPI 的两个片选信号，我们可以做什么？这也是我们的要求。如果缺少 CS 引脚，我们可以使用任何具有片选功能的 GPIO 吗？如果它有效的话 Re: iMX8M Plus - Flexspi chip select pin 你好@Govind1807 您可以使用基于 GPIO 的片选信号。但是，您只有两个 FlexSPI Flash 设备。为什么要使用GPIO作为片选信号？ imx8mp 具有四个可直接使用的 FLEX SS 信号： https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h BR

从用户空间访问我的内核 rpmsg 缓冲区 您好， 我已经能够实现我的imx8mp MPU和MCU之间的通信。但是，我想从用户空间访问共享内存中的数据。有例子吗？ 我还想问一下 imx_rpmsg_pinpong.c设备驱动程序可以扩展以处理 Linux 用户空间 I/O，从而实现内核空间和用户空间之间的通信。 谢谢！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Accessing my kernel rpmsg buffer from user space 你好， 我也在关注同样的问题。你提供的示例适用于内核模块。 但我实际上想找一个用户空间应用程序的示例。能否提供一个可以在Linux用户空间运行的C语言程序示例？ 谢谢！ Re: Accessing my kernel rpmsg buffer from user space 嗨@ababatola ， 希望你一切都好！抱歉回复晚了。 我建议您查看 i.MX 8M Plus SDK 中的 rpmsg_lite_str_echo_rtos 多核示例。这是一个简单的应用程序，允许你从 Cortex A 向 Cortex M 发送消息，然后 M4 显示接收到的内容，并将相同的消息回显作为确认。 您可以从https://mcuxpresso.nxp.com/版本和下载 SDK。 如果这个方法对你有效，请告诉我。 此致， 赫克托。

rw612 sdk 26.06 Hi, I downloaded SDK 26.06 for rw612, but it is not available in vs code, i imported the sdk, but i cannot generate project, it is not in the list also cannot open existing project which i created by 26.03 it is not in the dropdown list  Re: rw612 sdk 26.06 Hi. I did, but did not work. When I want to import the project, it says board not supported ( or something like this). but i generated SDK from https://mcuxpresso.nxp.com/ for my board. Re: rw612 sdk 26.06 Hello, Hope you are doing well. I am not able to reproduce this behavior. I would recommend updating the MCUXpresso Installer, and checking that all Software Kits are updated. Best Regards, Ricardo