Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hello,     we are bringing up Bluetooth on a Verdin i.MX95 WB running the NXP Android 15 BSP (Linux 6.6.58). The onboard wireless module is a u-blox MAYA-W260 based on NXP IW612. Wi-Fi works correctly over SDIO, and the combo firmware is successfully loaded: Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active ,Bluetooth instead does not appear to work. Whenever we enable it on Android settings, the UI switch is frozen and no BT device is found. Bluetooth is connected to LPUART6 (/dev/ttyLP5). The NXP vendor HAL opens the UART successfully. We initially found that hardware flow control blocked transmission; after temporarily disabling CRTSCTS, the HAL sends the four-byte HCI Reset command: 01 03 0c 00 The UART counters then show: tx:4 rx:0 No response is received from the IW612. The same result occurs with a direct manual UART test at 115200 baud, 8N1, without hardware flow control. Our current configuration is: mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fw is left disabled because the combo firmware is already downloaded by the Wi-Fi driver. Could you please clarify: After loading sduart_nw61x_v1.bin.se through SDIO, should the IW612 Bluetooth UART respond directly to an HCI Reset at 115200 baud? Is a boot-sleep trigger, wake command, vendor command, or another initialization sequence required first? Is hardware flow control mandatory for IW612, and what should the expected CTS state be after firmware initialization? Should we use the UART firmware-download path with uartspi_n61x_v1.bin.se instead of relying on the combo firmware loaded by Wi-Fi? Is there a recommended bt_vendor.conf for IW612 on i.MX95? Any reference configuration or expected UART trace would be very helpful. Best regards. Android Linux
記事全体を表示
LX2160ARDB Default boot images Hi, Can anyone please suggest a way to get the default boot images been used in LX2160A-RDB-B board. Evaluation Board Re: LX2160ARDB Default boot images You could use the latest Layerscape Yocto BSP v26.06 The following precompiled images are hosted on https://www.nxp.com/lgfiles/llsdk/walnascar/ > 14 firmware_lx2160ardb-rev2_uboot_emmcboot.img BSP firmware image for LX2160ARDB eMMC boot 15 firmware_lx2160ardb-rev2_uboot_sdboot.img BSP firmware image for LX2160ARDB SD boot 16 firmware_lx2160ardb-rev2_uboot_xspiboot.img BSP firmware image for LX2160ARDB xSPI boot 23 fsl-image-networking-lx2160ardb-rev2.rootfs.tar.gz Layerscape rootfs supports basic networking functionality on LX2160ARDB 24 fsl-image-networking-full-lx2160ardbrev2.rootfs.tar.gz Layerscape rootfs supports full networking functionality on LX2160ARDB 25 flex-installer Deploy tools 4 boot_lx2160ardb-rev2_lts_6.12.tgz Bootpartition image for LX2160ARDB Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf
記事全体を表示
PN7642 SPI controller interface SPI controller interface is mentioned in the PN7642 documents and PN7642.h, as well as on OM27642EVK (as SPIM) but that's all. I can't find an example or driver for that SPI controller (I don't mean Host SPI). AI search says that there are specific SPI function calls ,phhalSpi.h ,phhalSpi.c. , but I can't find anything even similar. Does it exist and how can I find it? Thanks for the help. Re: PN7642 SPI controller interface Hello, thank you for your interest in our products. PN7642 does have a set of SDK examples. I'm not sure if you have already imported some of them.       As you are able to see, you can just import the examples from the Quick Start panel -> Import SDK examples and search for the SPI as shown in the image. Please keep in mind that OM27642EVK has Follower Pins and Leader Pins. Please also mind section 7 of the Quick Start Guide documentation.
記事全体を表示
[S32G3]LLCECANのCan_SharedMemoryワード0で異常値が発生しました。 NXPのエキスパートの皆様、こんにちは。 私たちのプロジェクトにおけるLLCE CAN 機能に異常がありました。時折、送信は正常なのにECUから報告された特定のCANメッセージの受信に問題が起きました。デバッグの結果、CAN割り込みは通常通りトリガーできることが判明しましたが、u32Word0の読み取りはCan_SharedMemoryから0x18008から0x1800fに変わり、異常な値でした。計算されたu32MbMessageIdは0でした。これによりメッセージが失われました。 RxMbDescIdxには値があり、変化していました。また、word1は0になることもありましたが、これも変化していました。この状況は断続的に起こり、影響を受けたCANラインもランダムでした。 この状況の分析にご協力ください。デバッグ用のスクリーンショットを以下に添付します。次のデバッグ手順はどのように進めればよいでしょうか?あるいは、どのような解決策がありますか? LLCEのバージョンは1.0.10です。 。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. こんにちは、 canhe お問い合わせいただきありがとうございます。 もう少し詳しく教えていただけますか? 1. あなたはどのバージョンのRTDを使用していますか? 2. 自分でボードやソフトウェアを使っていますか? BR ジョーイ
記事全体を表示
AEC-Q100 MFS2613HMDA2ADはAEC-Q100規格に適合していますか?FS26のすべての部品番号はAEC-Q100規格に適合していますか? ありがとう、 エンリコ Re: AEC-Q100 こんにちはESof 良い一日! はい、FS26ファミリ全体がAEC-Q100の資格を持っています。これを証明するドキュメントは機密扱いなので、必要なら直接私たちにケースを開いて、何ができるか確認し、NDAの手続きを開始することをお勧めします。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 ご迷惑をおかけして申し訳ございません。 良い一日をお過ごしください。幸運を祈ります。
記事全体を表示
[S32G3]LLCECAN 的 Can_SharedMemory 字 0 中出现了异常值。 各位NXP专家,大家好! 我们的项目中,S32G399A 的 LLCE 罐功能使用出现了异常。有时,ECU 报告的某个 CAN 消息接收出现问题,而变速箱运行正常。经过调试,发现 CAN 中断可以正常触发,但是从 Can_SharedMemory 读取的 u32Word0 从 0x18008 变为 0x1800f,这是一个异常值。计算出的 u32MbMessageId 为 0。这导致消息丢失。 RxMbDescIdx 有一个值并且正在变化,word1 有时为 0,但也在变化。这种情况偶有发生,受影响的 CAN 总线也是随机的。 请帮忙分析一下这个问题,调试截图如下。我应该如何进行下一步的调试?或者有哪些解决方案? LLCE 版本为:1.0.10 。 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. 嗨, canhe 感谢您与我们联系。 您能提供更多信息吗? 1. 您使用的是哪个版本的RTD? 2.你们使用的是自己的电路板和自己的软件吗? BR 乔伊
記事全体を表示
[S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi NXP Experts, There was an abnormality in the use of the LLCE can function of the S32G399A in our project. Occasionally, there was an issue with the reception of a certain CAN message reported by the ECU, while the transmission was normal. After debugging, it was found that the can interrupt could be triggered normally, but the u32Word0 read from Can_SharedMemory changed from 0x18008 to 0x1800f, which was an abnormal value. The calculated u32MbMessageId was 0.This led to message loss. The RxMbDescIdx had a value and was changing, and word1 sometimes was 0 but was also changing. This situation occurred sporadically, and the affected CAN line was also random. Please help analyze this situation,The debugging screenshots are provided below. How should I proceed with the next debugging steps, or what solutions are there? The LLCE version is: 1.0.10 . Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,Joey_z Yes, we use our own boards and software. We employ LLCE in the M core and have integrated the MICROSAR com protocol stack of vector. RTD version:RTD_4.4_5.0.0_QLP03 Re: [S32G3]An abnormal value has occurred in the Can_SharedMemory word0 of LLCECAN. Hi,canhe Thank you for contacting us. Could you tell us more information? 1. Which version of RTD are you using? 2.Are you using your own boards and your own software? BR Joey
記事全体を表示
コンボファームウェアのダウンロード後、i.MX95でIW612 Bluetooth UARTが応答しない こんにちは、 Verdin i.MX95 WBでNXP Android 15 BSP(Linux 6.6.58)を搭載した上でBluetoothを起動します。搭載されている無線モジュールは、 NXP IW612をベースにしたu-blox MAYA-W260です。 SDIO経由でWi-Fiは正常に動作し、コンボファームウェアも正常にロードされました。 Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active Bluetoothは動作しないようです。Android設定で有効にすると、UIスイッチがフリーズし、BTデバイスも見つかりません。 BluetoothはLPUART6(/dev/ttyLP5)に接続されています。NXPベンダーのHALがUARTを正常に開きました。 当初、ハードウェアフロー制御が送信をブロックしていることが判明しました。CRTSCTSを一時的に無効にした後、HALは4バイトのHCIリセットコマンドを送信しました。 01 03 0c 00 UARTカウンタは以下のように表示されます。 tx:4 rx:0 IW612からの応答がありません。ハードウェアフロー制御なしで、115200ボー、8N1で直接手動でUARTテストを行った場合も同じ結果になります。 現在の構成は以下のとおりです。 mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fwは、Wi-Fiドライバーによってすでにコンボファームウェアがダウンロードされているため無効のままです。 もう少し詳しく教えていただけますか: SDIO経由でsduart_nw61x_v1.bin.seをロードした後、IW612 Bluetooth UARTは115200ボーのHCIリセットに直接応答するはずですか? ブートスリープのトリガー、ウェイクアップコマンド、ベンダーコマンド、またはその他の初期化シーケンスが最初に必要ですか? IW612ではハードウェアフロー制御は必須ですか?また、ファームウェア初期化後のCTSの状態はどうあるべきですか? Wi-Fiでロードされるコンボファームウェアに頼るのではなく、uartspi_n61x_v1.bin.seを含むUARTファームウェアダウンロードパスを使用すべきでしょうか? i.MX95上のIW612に推奨されるbt_vendor.confはありますか? 参考となる設定情報や想定されるUARTトレースがあれば大変助かります。 よろしくお願いいたします。 Android Linux
記事全体を表示
Software & Hardware Environment for Parking Sensor System 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article focuses on the software and hardware environment required to build, deploy, and monitor the parking sensor node. On the software side, it presents the MATLAB/Simulink workflow, NXP's Model-Based Design Toolbox (MBDT) for S32K1xx devices, FreeMASTER, and the supporting build environment. On the hardware side, it describes the S32K144-Q100 evaluation board, the MaxBotix MB1020 ultrasonic sensors, the wiring approach, and the communication/debug interfaces used in the setup. The goal is to provide a clear setup foundation before moving into the next article, where the internal model architecture, control flow, and application behavior will be described in more detail. 3 Required Software The parking sensor application is developed using a model-based workflow built around MATLAB, Simulink, Stateflow, and NXP's MBDT for S32K1xx devices. The Simulink model remains the main development artifact, while the supporting toolchain is used to generate code, build the application, download it to the target board, and monitor the running system. 3.1 MATLAB, Simulink and Stateflow MATLAB and Simulink provide the main environment for developing the parking sensor application model. Simulink and Stateflow are used to organize the application structure, configure the processing blocks, and prepare the model for deployment on the S32K144 target. Figure 1. PSS top-level model in Simulink 3.2 NXP Model-Based Design Toolbox for S32K1xx NXP's Model-Based Design Toolbox (MBDT) for S32K1xx acts as the bridge between the Simulink model and the S32K144 hardware. It provides dedicated blocks for configuring and using the microcontroller peripherals required by the parking sensor node. In this project, MBDT is used for Analog-to-Digital Converter (ADC) acquisition, General-Purpose Input/Output (GPIO) control, Local Interconnect Network (LIN) communication, and FreeMASTER for real-time data visualisation. This allows the model to interact directly with the target hardware without requiring the developer to manually implement low-level peripheral code. The key point for this article is that MBDT keeps the hardware configuration close to the model. The detailed usage of each block and how the blocks are arranged inside the application will be explained in the model architecture article. 3.3 Code Generation and Deployment Flow The application is prepared for embedded deployment through the code generation flow supported by Simulink, Embedded Coder, ARM Cortex-M support, and NXP MBDT. From the developer's perspective, the main workflow remains inside Simulink: the model is configured, generated, built, and deployed to the S32K144 board. NXP's toolchain environment integrated in MBDT provides the compiler and target support used by the build process. In this setup, it does not need to be treated as a separate development step. The generated application can be downloaded to the S32K144-Q100 evaluation board through the MBDT build/deploy workflow using the on-board JTAG debug interface. This keeps the setup straightforward: once MBDT is installed, the application can be built and programmed from the Simulink workflow. 3.4 FreeMASTER FreeMASTER is used as the runtime monitoring tool during development. It provides visibility into the embedded application while it is running on the S32K144 board. In the Parking Sensors System (PSS) setup, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, processed distance values, and selected application variables. This helps during bring-up and validation because the developer can check the behavior of the generated application without adding custom debug code. Note: The FreeMASTER channel is separate from the LIN communication used by the parking node to exchange data with the zonal controller. 3.5 Toolchain Versions The following software components are used for this demo setup: Component Version / Variant MATLAB / Simulink / Stateflow R2024a or newer Embedded Coder Matching MATLAB release ARM Cortex-M support Matching MATLAB release NXP MBDT for S32K1xx 4.3.0 FreeMASTER 3.2 or newer These versions define the reference environment used to build and deploy the parking sensor application. 4 Required Hardware The hardware setup is centered on the S32K144-Q100 evaluation board, which acts as the local parking sensor node. Four MaxBotix MB1020 ultrasonic sensors are connected to the board through analog inputs and control lines. The board also connects to the zonal controller over LIN and to the development PC through the FreeMASTER interface. Figure 2. Parking Sensor Node Hardware Setup 4.1 NXP S32K144-Q100 Evaluation Board The S32K144-Q100 evaluation board is the target hardware used for the parking sensor node. It provides the microcontroller platform required to run the generated application and includes the peripherals needed by the demo: ADC channels for the ultrasonic sensor outputs, GPIO pins for sensor control, LIN support for communication with the zonal controller, and a debug interface for programming and monitoring. In this setup, the board performs the hardware-side interaction with the sensors and communication interfaces. Figure 3. S32K144-Q100 Evaluation Board Used for the Parking Sensor Node The board configuration used by the project is summarized below. Setting Value Device S32K144 Package 100-LQFP SRAM size 64 KB External crystal 8 MHz System clock 80 MHz Memory model FLASH Debug interface JTAG The exact configuration is provided by the MBDT configuration block in the Simulink model. 4.2 MaxBotix MB1020 Ultrasonic Sensors The demo uses four MaxBotix MB1020 sensors, also known as LV-MaxSonar-EZ ultrasonic sensors. Each sensor provides an analog voltage output that varies with the measured distance, which makes the device easy to connect to the S32K144 ADC inputs. The sensor also includes an RX pin that can be used as an enable or control input. 4.3 Sensor Wiring and Pin Mapping Each MB1020 sensor is connected to the S32K144-Q100 board using two main signal types. The analog output pin is connected to one ADC input channel, while the RX pin is connected to a GPIO output and can be used by the application to control the sensor. Power and ground are distributed from the evaluation board through the breadboard. The following pin mapping comes from the PSS model connection annotation. Sensor Analog pin to S32K144 RX enable pin to S32K144 SONAR1 — Left AN → PTB2, ADC0_SE6, J2.11 RX → PTA11, J1.2 SONAR2 — Center Left AN → PTB3, ADC0_SE7, J2.9 RX → PTA17, J1.4 SONAR3 — Right AN → PTA0, ADC0_SE9, J5.7 RX → PTD10, J1.6 SONAR4 — Center Right AN → PTA1, ADC0_SE15, J5.5 RX → PTD11, J1.8 Power and ground connections are defined as follows. Signal Connection GND Breadboard black rail → J13.4 on S32K144-Q100 VCC 5 V Breadboard red rail → J3.9 on S32K144-Q100 Figure 4. Sensor Wiring Between the S32K144-Q100 Board and MB1020 Sensors 4.4 ADC Configuration The MB1020 sensors provide analog voltage outputs, so the S32K144 ADC is used to convert these signals into digital values. In the project setup, ADC0 is configured for software-triggered acquisition and uses the channels assigned to the four ultrasonic sensors. Setting Value ADC instance ADC0 Resolution 12-bit Trigger source Software trigger Voltage reference 5 V / 0 V Used channels ADC0_SE6, ADC0_SE7, ADC0_SE9, ADC0_SE15 Averaging Enabled, 4 samples This section describes only the peripheral setup. The timing of the acquisitions and the conversion from ADC values to distance measurements will be covered in the next article. 4.5 LIN Interface to the Zonal Controller The parking node communicates with the zonal controller using LIN. In this setup, the parking node is configured as a LIN slave, while the zonal controller acts as the LIN master. Setting Value Peripheral LPUART2 in LIN mode Node function Slave Baud rate 19200 bit/s Checksum Enhanced LIN 2.x LIN TX pin PTD7 LIN RX pin PTD6 The physical connection between the parking node and the zonal controller uses LIN and ground lines. Signal Zonal board pin Parking S32K144-Q100 pin LIN J31.8 J11.1 GND J31.2 J11.4 4.6 FreeMASTER Debug Channel FreeMASTER uses a dedicated serial channel that allows the developer to monitor the application on the PC while the parking node continues to communicate with the zonal controller. Setting Value Interface LPUART1 Baud rate 115200 bit/s RX pin PTC6 TX pin PTC7 Usage Runtime monitoring and variable visualization 5 References Developing a Parking Sensor System with Model-Based Design Toolbox 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 NXP S32K144 Reference Manual and S32K144-Q100 evaluation board user guide MaxBotix MB1020 / LV-MaxSonar-EZ1 datasheet MathWorks documentation: MATLAB, Simulink, Stateflow, Embedded Coder, ARM Cortex-M support FreeMASTER Run-Time Debugging Tool 6 Conclusion This article described the software and hardware environment required to build and run the Parking Sensor System. The software side is based on MATLAB, Simulink, Stateflow, NXP MBDT, code generation support, and FreeMASTER. The hardware side uses the S32K144-Q100 evaluation board, four MaxBotix MB1020 ultrasonic sensors, ADC input channels, GPIO control lines, LIN communication, and a dedicated FreeMASTER serial channel. With this environment in place, the PSS model can be built, downloaded to the S32K144 board, monitored in real time, and connected to the zonal demo setup. The next article will move inside the model and explain the application architecture, including the sensor acquisition flow, model structure, distance conversion, and LIN communication behavior.
記事全体を表示
Zone Node Logic Control (Main model overview) 1 Table of Contents • Introduction • Black-Box Overview • Simulink Model Overview • Inputs • Algorithm • Outputs • References • Conclusion 2 Introduction This article explains the internal behavior of the Zone Node by opening the component "black box" and describing how information flows through the application. The objective is to provide a functional understanding of the model, starting from the incoming inputs, continuing through the internal processing logic, and concluding with the generated outputs. The Zone Node acts as an intermediary between the Central Controller and the Edge Nodes located within a vehicle zone. While previous articles introduced the component and the development environment, this article focuses on the application's behavior and the responsibilities performed by the embedded software. This article focuses on the functional behavior of the Zone Node and explains how information flows through the component. Detailed aspects such as CAN routing implementation, LIN scheduling mechanisms, peripheral configuration, and communication stack integration will be covered in dedicated articles later in the series. 3 Black-Box Overview From a system perspective, the Zone Node behaves as a communication gateway and data aggregation component. It receives information from different communication networks, processes that information according to predefined routing rules, and forwards the resulting data to other parts of the system. At a high level, the component can be represented as: Figure 1. Black-Box Overview The Zone Node does not implement vehicle-level control strategies. Functions such as braking decisions, steering calculations, or vehicle state management remain the responsibility of higher-level controllers. Instead, the Zone Node focuses on: Receiving messages from the Central Controller Receiving messages from Edge Nodes Acquiring data from local LIN-connected devices Routing information between networks Aggregating and forwarding data Providing monitoring and diagnostic information The result is a reusable communication component that can be deployed in different vehicle zones while maintaining the same overall behavior. 4 Simulink Model Overview The Zone Node functionality is implemented as a Simulink model organized around communication, routing, scheduling, and diagnostic subsystems. From a model perspective, the application can be divided into four logical areas: Input handling Routing and processing Communication scheduling Outputs and diagnostics Figure 2. Main Simulink Application The input layer receives information from CAN and LIN communication interfaces and makes it available to the application logic. The processing layer evaluates incoming messages and determines how they should be handled. The scheduling layer manages periodic communication activities, while the output layer is responsible for forwarding messages and generating diagnostic information. This separation helps keep the model modular and makes it easier to extend the application with additional communication paths or Edge nodes without changing the core routing behavior. 5 Inputs The Zone Node receives information from three main categories of inputs. 5.1 CAN Network Inputs CAN communication represents the primary source of information processed by the Zone Node. Messages can originate from: Central Controller Lighting modules Steering modules Motor control modules Other Edge Nodes within the zone Typical examples include: Vehicle commands Status reports Diagnostic information Fault indications Actuation requests The exact set of messages depends on the specific Edge Nodes connected to the zone. 5.2 LIN Device Inputs The Zone Node also acquires information from LIN-connected devices. In the reference implementation, LIN communication is used to retrieve parking sensor information. The Zone Node periodically requests data from the LIN device and receives measurement values in response. Examples include: Front parking distances Rear parking distances Other LIN-based sensor information From the perspective of the Zone Node, LIN data behaves similarly to any other external input source. 5.3 Configuration Inputs Before normal operation begins, the Zone Node initializes its communication interfaces and loads the required configuration information. Examples include: CAN interface configuration LIN interface configuration Communication schedules Routing rules These parameters define how the application interacts with the surrounding networks. 6 Algorithm Internally, the Zone Node performs three main processing activities. 6.1 Message Reception The first step consists of collecting incoming communication data. Whenever a message arrives, the application captures: Communication source Message identifier Data payload Message length This information becomes available to the routing and aggregation logic. Figure 3. CAN Reception Pipeline 6.1.1 Model Representation of Message Reception Within the Simulink model, message reception is implemented using communication interface blocks and dedicated processing subsystems that capture incoming network events and make the received information available to the rest of the application. Figure 4. CAN Reception Main Flow Figure 5. CAN Reception Subsystem At a high level, the reception subsystem performs three actions: Detects incoming communication events Stores the received information Makes the information available to the routing logic This allows the routing algorithm to operate independently from the physical communication interface. 6.2 Message Routing Message routing represents the primary responsibility of the Zone Node. The routing logic determines the origin of each incoming message and forwards it to the appropriate communication interface. The behavior can be simplified as: Figure 6. Bidirectional CAN Routing Messages received from the Central Controller are forwarded toward the Edge Nodes, while messages originating from Edge Nodes are routed back toward the Central Controller. The routing mechanism remains independent of the actual application payload, allowing the same software architecture to support different message sets and vehicle functions. 6.2.1 Model Representation of Routing Logic The routing functionality is implemented as a dedicated subsystem responsible for deciding where each received message should be forwarded. Figure 7. Message Routing Main Flow Figure 8. Message Routing Subsystem The routing subsystem evaluates the origin of the received message and selects the appropriate destination interface. At this level, the application does not interpret individual signal meanings; it simply ensures that information reaches the correct communication network. This approach keeps the routing layer independent from application-specific functionality and allows the same architecture to be reused across different deployments. 6.3 LIN Scheduling and Data Acquisition In parallel with CAN routing, the Zone Node periodically acquires data from LIN-connected devices. The sequence follows a simple request-response model: Figure 9. LIN Parking Acquisition Cycle This mechanism allows information originating on a LIN network to become available to the rest of the vehicle through CAN communication. 6.3.1 Model Representation of LIN Scheduling Periodic LIN communication is implemented using a dedicated scheduling subsystem. Figure 10. LIN Scheduling Main Flow The scheduler periodically requests data from LIN-connected devices, waits for a response, and updates the application data used by the rest of the system. Depending on the communication requirements, the scheduler may manage one or more request-response sequences while maintaining a deterministic execution pattern. 6.4 High-Level Data Flow The internal data flow implemented by the Zone Node can be summarized as follows: Figure 11. Zone Node Data Flow 7 Outputs The Zone Node produces several categories of outputs that are consumed by different parts of the vehicle architecture and by development tools used during validation and debugging. 7.1 Routed CAN Messages The primary outputs of the Zone Node are CAN messages forwarded between communication networks. Examples include: Commands sent from the Central Controller to Edge Nodes Status information returned from Edge Nodes Diagnostic messages Fault reports Configuration updates By routing these messages between communication domains, the Zone Node maintains communication between the central controller and the devices located within its assigned vehicle zone. 7.2 Aggregated Device Data In addition to forwarding CAN traffic, the Zone Node generates CAN messages containing information acquired from locally connected devices. One example is parking sensor data collected through a LIN interface and republished on CAN. This allows the Central Controller to access the information without requiring direct interaction with the LIN-connected device. The process can be summarized as: Figure 12. LIN-to-CAN Data Path This approach creates a unified communication interface while hiding the complexity of the underlying network topology. 7.3 Diagnostic Outputs The Zone Node generates diagnostic information that is useful during development, system integration, and troubleshooting activities. Examples include: Communication counters Status variables Network activity indicators Communication statistics Device data used for monitoring purposes These outputs provide insight into the current behavior of the application and can be accessed through development tools such as FreeMASTER. 7.4 Visual Indicators In addition to communication outputs, the Zone Node drives visual indicators available on the evaluation hardware. The on-board LEDs provide immediate feedback regarding: Message reception activity Message transmission activity LIN communication activity Application execution status Although these indicators are not used by the vehicle itself, they simplify application bring-up and validation by providing a quick visual confirmation that the software is operating correctly. 7.5 Output Destinations The outputs generated by the Zone Node are consumed by several different system components. Central Controller Receives: Status information from Edge Nodes Aggregated sensor data Diagnostic information generated within the zone Edge Nodes Receive: Commands originating from the Central Controller Configuration and control messages forwarded through the Zone Node Local Devices Receive: Periodic requests issued by the Zone Node Communication messages required to acquire local measurements Development Tools Receive: Monitoring variables Communication statistics Diagnostic information used for debugging and validation 7.6 High-Level Output Flow Figure 13. System Topology This output structure allows the Zone Node to act as a communication intermediary while simultaneously providing visibility into the behavior of the system during development and validation. 8 References NXP Model-Based Design Toolbox (MBDT) S32K3 Microcontroller Documentation S32K344-WB Evaluation Board Documentation 9 Conclusion This article described the internal behavior of the Zone Node by examining its inputs, processing logic, and outputs. By presenting the component as a functional black box, it explained how information is received, routed, aggregated, and distributed throughout the system without focusing on implementation-specific details. The next articles in the series will build upon this foundation by examining individual communication paths in more detail, including CAN-to-CAN routing, LIN-to-CAN routing, and the techniques used to validate and troubleshoot communication behavior.
記事全体を表示
Creating virtual vehicle with MathWorks - SW & HW Environment 1 Table of Contents • Introduction • Software Environment • Hardware Environment • References • Conclusion 2 Introduction Turning a vehicle concept into an interactive Virtual Vehicle requires more than a standalone simulation model. It requires a connected software and hardware environment that can define the vehicle architecture, simulate the powertrain and vehicle dynamics, place the vehicle in realistic driving scenarios, visualize the behavior in 3D, and allow user interaction through driver-in-the-loop inputs. This article continues the Virtual Vehicle system series by moving from the system-level overview to the enablement layer behind the application. It highlights the MathWorks tools and host-side hardware resources that make the virtual vehicle demonstrator possible. At the core of the workflow is Model-Based Design. MathWorks tools are used to configure the vehicle architecture with Virtual Vehicle Composer, model the powertrain and vehicle dynamics, define and execute driving scenarios, create 3D road environments, exchange CAN-based signals, and analyze simulation results. The same environment also supports interactive execution, where driver inputs from a steering wheel and pedals can influence the virtual vehicle behavior during scenario playback. 3 Software Environment The software environment provides the modeling, simulation, scenario definition, visualization, communication, and analysis capabilities required by the Virtual Vehicle system. Each MathWorks tool contributes a specific part of the workflow, from vehicle architecture definition and plant modeling to 3D scenario execution and CAN-based interaction with external systems. 3.1 MATLAB and Simulink R2025b MATLAB and Simulink form the central engineering environment for the Virtual Vehicle. Figure 1. MATLAB MATLAB provides the scripting, data management, parameterization, and analysis capabilities required to configure simulations, process logged signals, and evaluate test results. Figure 2. Simulink Simulink provides the model-based design environment in which the virtual vehicle, control logic, communication interfaces, and test harnesses are assembled. The system-level model can connect plant models, vehicle dynamics, driver inputs, scenario interfaces, and network communication blocks into a single executable simulation. 3.2 Virtual Vehicle Composer Figure 3. Virtual Vehicle Composer Virtual Vehicle Composer is the configuration and assembly environment used to create the Virtual Vehicle model. It allows the user to define the vehicle class, select the powertrain architecture, choose the vehicle dynamics fidelity, configure components, specify test scenarios, select logged signals, build the vehicle model, run the configured tests, and analyze the results. In this Virtual Vehicle system, Virtual Vehicle Composer acts as the entry point for building a consistent vehicle model. It assembles the selected architecture from predefined and customizable components and prepares the model for closed-loop simulation in Simulink. The app also supports repeatable test execution. The same virtual vehicle can be operated across selected scenarios, while relevant signals are logged for review. This makes it suitable for early design studies, component comparison, control validation, and system-level behavior analysis before moving to hardware integration. 3.3 Powertrain Blockset Figure 4. Powertrain Blockset Powertrain Blockset provides the vehicle powertrain modeling foundation for the Virtual Vehicle model. It includes reference applications and component libraries for conventional, hybrid, and battery-electric propulsion systems. In this system, Powertrain Blockset supports the definition of the propulsion architecture, energy storage, electric motors, drivetrain elements, tires, driver models, and supervisory control behavior. It also provides workflows that help configure, resize, calibrate, and analyze the selected powertrain components. The generated vehicle model can be used for performance analysis, energy management studies, range evaluation, component sizing, control parameter optimization, and hardware-in-the-loop preparation. Because the models are open, project-specific subsystems can be integrated into the generated architecture when needed. 3.4 Vehicle Dynamics Blockset Figure 5. Vehicle Dynamics Blockset Vehicle Dynamics Blockset provides the vehicle motion and handling foundation for the Virtual Vehicle. It includes reference applications and component libraries for propulsion, steering, suspension, vehicle body, brakes, tires, driver models, and supervisory controllers. For the Virtual Vehicle system, the blockset enables different levels of vehicle dynamics fidelity depending on the simulation objective. Longitudinal dynamics can be used for drive-cycle and energy studies, while combined longitudinal, lateral, and vertical dynamics can be used for handling, chassis behavior, and more complex driving scenarios. The blockset also supports 3D visualization workflows, allowing the virtual vehicle behavior to be observed in a realistic environment. This helps connect numerical simulation results with intuitive visual feedback during ride, handling, ADAS, and driver-in-the-loop demonstrations. 3.5 Automated Driving Toolbox Figure 6. Automated Driving Toolbox Automated Driving Toolbox supports the definition, simulation, and analysis of driving scenarios used to exercise the Virtual Vehicle. It provides capabilities for creating road layouts, actors, trajectories, sensor-related contexts, and repeatable test cases. In this setup, the toolbox is used to create controlled and repeatable traffic situations around the ego vehicle. These scenarios can be used to evaluate how the virtual vehicle behaves in predefined maneuvers, traffic interactions, lane-following conditions, or other driving situations relevant to the demonstration. By combining scenario definition with the vehicle model, the Virtual Vehicle can be validated in a structured way. Instead of testing only isolated model behavior, the complete system can be exercised against realistic road and traffic conditions. 3.6 Vehicle Network Toolbox Figure 7. Vehicle Network Toolbox Library Vehicle Network Toolbox brings vehicle network communication into the model-based workflow. It provides MATLAB functions and Simulink blocks for sending, receiving, encoding, and decoding messages over in-vehicle network protocols such as CAN, CAN FD, J1939, and XCP. In the Virtual Vehicle, the toolbox is used to exchange selected vehicle signals with external systems or hardware components. CAN messages can be packed and unpacked using database-driven definitions, allowing the model to follow the same signal structure expected by the vehicle-level architecture. This makes communication behavior visible and testable during simulation. Commands, feedback, status information, and selected virtual vehicle signals can be validated before deployment or integration with physical controllers, reducing late-stage integration risk. 3.7 RoadRunner Figure 8. RoadRunner RoadRunner provides the 3D scene creation environment used by the Virtual Vehicle system. It enables the design of detailed road networks, intersections, lane markings, traffic signs, buildings, terrain, and other environmental assets required for realistic driving simulation. In this workflow, RoadRunner supplies the visual and spatial context in which the virtual vehicle operates. The generated scenes can represent controlled proving-ground layouts, urban intersections, highway segments, or demonstration environments used for scenario execution. When combined with Simulink and the vehicle model, RoadRunner helps transform the simulation from a signal-level model into an interactive visual experience. This is especially useful for driver-in-the-loop demonstrations, ADAS workflows, and stakeholder-facing presentations. 3.8 Simulink 3D Animation Figure 9. Simulink 3D Animation Library Simulink 3D Animation connects Simulink models and MATLAB algorithms to a 3D simulation environment, enabling dynamic systems to be visualized in photorealistic scenes. In the Virtual Vehicle system, it provides the visualization and interaction layer used to observe vehicle behavior in a 3D environment during simulation. The toolbox can use prebuilt scenes or imported scenes created in RoadRunner, and it allows vehicles, objects, lighting, weather effects, and sensor-related elements to be controlled during simulation. This makes it suitable for connecting the Virtual Vehicle model to visually rich driving environments. For driver-in-the-loop operation, Simulink 3D Animation also supports interactive navigation and manual control through hardware devices. This allows steering wheel and pedal inputs to influence the simulated vehicle while the resulting motion is visualized in the 3D scene. 3.9 Stateflow Figure 10. Stateflow Library Stateflow provides the graphical environment for modeling state machines, decision logic, and event-driven behavior inside the Virtual Vehicle system. It is used when vehicle behavior must depend on operating modes, transitions, conditions, timers, or fault states. Within the Virtual Vehicle model, Stateflow can support supervisory control, mode management, scenario state handling, driver input interpretation, startup and shutdown sequencing, or fallback behavior. This helps separate discrete decision logic from continuous plant and controller behavior. Using Stateflow keeps the system behavior easier to understand, review, and validate. Complex conditions can be represented explicitly as states and transitions, which improves traceability during simulation and debugging. 4 Hardware Environment The hardware environment provides the execution platform, user input interface, and visualization resources required to operate the Virtual Vehicle system interactively. The main components are the GPU-accelerated PC and the Xbox-compatible steering wheel and pedal controller. 4.1 PC with GPU Acceleration The PC is the main host platform for the Virtual Vehicle system. It runs MATLAB, Simulink, Virtual Vehicle Composer, RoadRunner-related workflows, and the supporting toolboxes used to model, simulate, visualize, and analyze the vehicle behavior. GPU acceleration is important because the system includes visually rich 3D scenes and interactive simulation workflows. The graphics hardware helps render the driving environment smoothly, maintain responsive visualization, and support a more realistic driver-in-the-loop experience. In this setup, the PC also acts as the integration point between the simulation model, the 3D environment, the input devices, and any external communication interfaces. This makes it the central execution and orchestration node of the Virtual Vehicle demonstration. 4.2 Xbox-Compatible Wheel Controller Xbox-Compatible Wheel Controller The Xbox-compatible wheel controller provides the physical driver input interface for the Virtual Vehicle system. It allows the user to control steering, acceleration, and braking through a steering wheel and pedal set instead of using keyboard-based commands. This input device makes the simulation suitable for driver-in-the-loop demonstrations. User actions can be mapped into the Simulink model and used to influence the virtual vehicle response during scenario execution. The wheel controller improves the realism and accessibility of the demonstration. It allows engineers and stakeholders to experience the virtual vehicle behavior interactively, making it easier to evaluate the relationship between driver input, vehicle response, and 3D scene feedback. 5 References The following resources provide useful background for the technologies referenced in this article: MathWorks MATLAB and Simulink documentation MathWorks Virtual Vehicle Composer documentation MathWorks Powertrain Blockset documentation MathWorks Vehicle Dynamics Blockset documentation MathWorks Automated Driving Toolbox documentation MathWorks Vehicle Network Toolbox documentation MathWorks RoadRunner documentation MathWorks Simulink 3D Animation documentation MathWorks Stateflow documentation 6 Conclusion This section described the software and hardware enablement required for the Virtual Vehicle system. The software environment combines MATLAB and Simulink with Virtual Vehicle Composer, Powertrain Blockset, Vehicle Dynamics Blockset, Automated Driving Toolbox, Vehicle Network Toolbox, RoadRunner, Simulink 3D Animation, and Stateflow to support vehicle configuration, system-level modeling, scenario execution, 3D visualization, communication, and analysis. The hardware environment combines a GPU-accelerated PC with a steering wheel and pedal controller to support interactive driver-in-the-loop execution. Together, these elements provide the foundation for building, operating, visualizing, and validating the virtual vehicle before integration with physical controllers or target hardware.
記事全体を表示
Streams and Transcode Video with Gstreamer This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below: This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false You can check the results with the 1080p@24fps.
記事全体を表示
MCXN547: 利用可能な拡張Flex PWMインスタンスはいくつありますか? リファレンス・マニュアルには、PWMモジュールの2つのインスタンス(PWM0とPWM1)がMCXN547で提供されていると記載されています。しかし、ヘッダーファイル(MCXN547_cm33_core0_COMMON.h)では、PWM0のベースアドレスは含まれていますが、PWM1のベースアドレスは含まれていません。 私はMCXN547VKLTという部品を使用しており、PWM出力にはピン17(ポート2_3)を使用する予定です。データシートMCXN547、ポート2_3はALT5 - PWM1_B2機能として設定可能とされています。しかし、MCUXpresso IDEのピン設定ツールを使うと、ALT5 - PWM1_B2機能のためにPin17(ポート2_3)を選択するオプションがありません。 そこで、MCXN547VKLTが2つのEnhanced Flex PWMインスタンスをサポートしているかどうかを確認したいです。 クロック|タイマー MCX N Re: MCXN547: How many Enhanced Flex PWM instances are available? こんにちは、 @JawaharA さん。 投稿ありがとうございます。 MCXN547VKLT FlexPWMモジュールは1つ(FlexPWM0)しか持っていないことは確認できます。 リファレンス・マニュアルとピンマックステーブルは、いくつかのMCX Nシリーズデバイス(N94/N54/N53/N52/N24)に共通しているため、すべてのデバイスバリアントに存在しないペリフェラルに関連する信号が含まれている場合があります。 デバイス固有の機能の利用可否については、データシートの表4(機能比較)を参照してください。この表に基づくと、FlexPWM1はMCXN547VKLTでは利用できません。 したがって、P2_3は共通ピンマルチプレクサテーブルではPWM1_B2として記載されていますが、MCXN547VKLTではこの機能はサポートされていないため、MCUXpresso Config Toolsでは利用できません。 お役に立てば幸いです。他に質問がありましたら、お気軽にお知らせください。 BR セレステ
記事全体を表示
Simulinkに統合されるNXP MBDTツールボックスを使用してOSを開発することは実現可能でしょうか? こんにちは、チームのみなさん。 私の目的は、MATLAB/Simulink、Embedded Coder、NXP MBDTを用いて、NXP S32G3向けの完全なベアメタルオペレーティングシステム/ソフトウェアプラットフォームを開発する実現可能性を評価することです。 目標は、Simulinkで完全なソフトウェアスタックを開発し、Embedded Coderを使ってCコードを生成し、生成されたコードを外部オペレーティングシステムやRTOS、AUTOSAR BSWに依存せずに直接S32G3 Gold Boxにデプロイすることです。 特に、NXP MBDTを用いて、Cortex-AコアとCortex-Mコアの両方をS32G3上で実装し、生成されたソフトウェアがシステムの初期化、スケジューリング、割り込み管理、メモリ管理、ハードウェア抽象化、周辺機器初期化、IPCメカニズム、その他オペレーティングシステムで通常提供されるサービスとして技術的に実装できるかどうかを理解したいです。 Boot ROMはハードウェア上に常駐しており、アプリケーションより先に実行されると理解しています。私の意図としては、ハードウェアの起動プロセス以降のすべての処理を、可能な限りNXP MBDTワークフローを通じてSimulinkで生成されたコードを使用して実装することです。 したがって、私の主な質問は次のとおりです。 1. NXP Model-Based Design ToolboxとMATLAB/Simulink、Embedded Coderを組み合わせて、Cortex-AおよびCortex-Mの両方を対象としたS32G3向けのベアメタルソフトウェアプラットフォーム(OS風フレームワーク)を開発することは技術的に実現可能か?MBDTのワークフローに制限がある場合、どの部分が手書きのCやアセンブリを必要とするのかを明確に教えていただけますか? MBDTはNXPによって開発されたものだと理解しています。しかし、もしこの質問にNXP MBDTチームがより適切に回答できる場合は、適切な連絡先やサポートチャネルをご案内していただけるとありがたいです。 ご指導ありがとうございました。 Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink こんにちは、 @charan032001 投稿ありがとうございます。 別のスレッドで言及され、返信もあったのに気づきました。 NXPの製品にご関心いただきありがとうございます。 BR チェイン
記事全体を表示
Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink? Hi team, My objective is to evaluate the feasibility of developing a complete bare-metal operating system/software platform for the NXP S32G3 using MATLAB/Simulink, Embedded Coder, and the NXP MBDT. The goal is to develop the complete software stack in Simulink, generate C code using Embedded Coder, and deploy the generated code directly onto the S32G3 Gold Box without relying on an external operating system, RTOS, or AUTOSAR BSW. In particular, I would like to understand whether, using the NXP MBDT, it is technically feasible to implement software for both the Cortex-A cores and the Cortex-M core on the S32G3, with the generated software handling system initialization, scheduling, interrupt management, memory management, hardware abstraction, peripheral initialization, IPC mechanisms, and other services typically provided by an operating system. I understand that the Boot ROM is hardware-resident and executes before the application. My intention is for everything after the hardware boot process to be implemented, as much as possible, using Simulink-generated code through the NXP MBDT workflow. Therefore, my primary question is: 1. Is it technically feasible, using the NXP Model-Based Design Toolbox together with MATLAB/Simulink and Embedded Coder, to develop an entire bare-metal software platform (OS-like framework) for the S32G3 targeting both the Cortex-A and Cortex-M cores? If there are any limitations within the MBDT workflow, could you please clarify what portions would still require handwritten C or assembly? I understand that MBDT is developed by NXP. However, if this question is better addressed by the NXP MBDT team, I would appreciate it if you could kindly direct me to the appropriate contact or support channel. Thank you for your guidance. Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink Hello, @charan032001  Thanks for your post. I noticed it is mentioned via another thread and it had been replied. Thanks for your interest on NXP's product. BR Chenyin
記事全体を表示
"8MPLUSLPD4-EVK" build issue with Ubuntu 26.04 LTS Hello NXP, i am using "8MPLUSLPD4-EVK"  . I am trying build the BSP but i am facing some build issue. Please help on this issue. Please let me know if you need more information. error logs: dasmiddepogu@dasmiddepogu-ThinkPad-P14s-Gen-6:~/NXP/project/imx-yocto-bsp/build$ bitbake core-image-minimal ERROR: Attempting to set server environment: Unable to update the server configuration with local parameters: Traceback (most recent call last): File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/command.py", line 91, in runCommand result = command_method(self, commandline) File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/command.py", line 291, in updateConfig command.cooker.updateConfigOpts(options, environment, cmdline) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py", line 471, in updateConfigOpts self.reset() ~~~~~~~~~~^^ File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py", line 1741, in reset self.handlePRServ() ~~~~~~~~~~~~~~~~~^^ File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py", line 337, in handlePRServ self.hashserv.serve_as_process(log_level=logging.WARNING) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/asyncrpc/serv.py", line 402, in serve_as_process self.process.start() ~~~~~~~~~~~~~~~~~~^^ File "/usr/lib/python3.14/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) ~~~~~~~~~~~^^^^^^ File "/usr/lib/python3.14/multiprocessing/context.py", line 230, in _Popen return _default_context.get_context().Process._Popen(process_obj) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ File "/usr/lib/python3.14/multiprocessing/context.py", line 306, in _Popen return Popen(process_obj) File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__ super().__init__(process_obj) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ File "/usr/lib/python3.14/multiprocessing/popen_fork.py", line 20, in __init__ self._launch(process_obj) ~~~~~~~~~~~~^^^^^^^^^^^^^ File "/usr/lib/python3.14/multiprocessing/popen_forkserver.py", line 47, in _launch reduction.dump(process_obj, buf) ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.14/multiprocessing/reduction.py", line 60, in dump ForkingPickler(file, protocol).dump(obj) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^ _pickle.PicklingError: Can't pickle local object .run at 0x7802f7325380> when serializing dict item '_target' when serializing multiprocessing.context.Process state when serializing multiprocessing.context.Process object repo details: $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync $ DISTRO=fsl-imx-xwayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b build Linux host PC details: PRETTY_NAME="Ubuntu 26.04 LTS" NAME="Ubuntu" VERSION_ID="26.04" VERSION="26.04 (Resolute Raccoon)" VERSION_CODENAME=resolute ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=resolute LOGO=ubuntu-logo Host PC configuration: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 42 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 16 On-line CPU(s) list: 0-15 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM) Ultra 7 255H CPU family: 6 Model: 197 Thread(s) per core: 1 Core(s) per socket: 16 Socket(s): 1 Stepping: 2 CPU(s) scaling MHz: 17% CPU max MHz: 5100.0000 CPU min MHz: 400.0000 DDR size : 32GB i.MX8ULP Re: "8MPLUSLPD4-EVK" build issue with Ubuntu 26.04 LTS Hello @middepogudas  Hope you are doing very well. The imx-linux-scarthgap BSP was validated on supported in Ubuntu 22.04 and Ubuntu 24.04. Ubuntu 26.04 uses Python 3.14 by default and seems the Bitbake version in that BSP is not fully compatible with Python 3.14. I recommend to you to compile using Ubuntu 24.04 LTS or Ubuntu 22.04 LTS until Ubuntu 26.04 LTS is fully supported. Also, you can try using a virtual environment with python 3.12. Best regards, Salas.
記事全体を表示
Ubuntu 26.04 LTS 上的“8MPLUSLPD4-EVK”版本问题 您好,NXP, 我正在使用“8MPLUSLPD4-EVK”。我正在尝试构建电路板支持包,但遇到了一些构建问题。请帮忙解决这个问题。如果您需要更多信息,请告诉我。 错误日志: dasmiddepogu@dasmiddepogu-ThinkPad-P14s-Gen-6:~/NXP/project/imx-yocto-bsp/build$ bitbake core-image-minimal 错误:尝试设置服务器环境:无法使用本地参数更新服务器配置:回溯(最近一次调用): 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/command.py”,第 91 行,在 runCommand 中 result = command_method(self, commandline) 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/command.py”,第 291 行,在 updateConfig 中 command.cooker.updateConfigOpts(options,环境,命令行) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py”,第 471 行,在 updateConfigOpts 中 self.reset() ~~~~~~~~~~^^ 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py”,第 1741 行,在 reset 中 self.handlePRServ() ~~~~~~~~~~~~~~~~~^^ 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/cooker.py”,第 337 行,在 handlePRServ 中 self.hashserv.serve_as_process(log_level=logging.WARNING) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/home/dasmiddepogu/NXP/project/imx-yocto-bsp/sources/poky/bitbake/lib/bb/asyncrpc/serv.py”,第 402 行,在 serve_as_process 函数中 self.process.start() ~~~~~~~~~~~~~~~~~~^^ 文件“/usr/lib/python3.14/multiprocessing/process.py”,第 121 行,开始 self._popen= self._Popen(self) ~~~~~~~~~~~^^^^^^ 文件“/usr/lib/python3.14/multiprocessing/context.py”,第 230 行,在 _Popen 中 返回 _default_context.get_context().Process._Popen(process_obj) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ 文件“/usr/lib/python3.14/multiprocessing/context.py”,第 306 行,在 _Popen 中 返回 Popen(process_obj) 文件“/usr/lib/python3.14/multiprocessing/popen_forkserver.py”,第 35 行,在__init__ super(). __init__ (process_obj) ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^ 文件“/usr/lib/python3.14/multiprocessing/popen_fork.py”,第 20 行,在__init__ self._launch(process_obj) ~~~~~~~~~~~~^^^^^^^^^^^^^ 文件“/usr/lib/python3.14/multiprocessing/popen_forkserver.py”,第 47 行,在 _launch 中 reduction.dump(process_obj,布法罗) ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/python3.14/multiprocessing/reduction.py”,第 60 行,转储 ForkingPickler(file, protocol).dump(obj) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^ _pickle.PicklingError:无法序列化本地对象 .run在 0x7802f7325380> 序列化字典项“_target”时 序列化 multiprocessing.context.Process 状态时 序列化 multiprocessing.context.Process 对象时 仓库详情: $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest-b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ 仓库同步 $ DISTRO=fsl-imx-xwayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b build Linux主机PC详情: PRETTY_NAME="Ubuntu 26.04 LTS" 名称="Ubuntu" 版本 ID="26.04" 版本="26.04(坚定的浣熊)" 版本号=resolute ID=ubuntu ID_LIKE=debian HOME_URL=" https://www.ubuntu.com/ " 支持网址=" https://help.ubuntu.com/ " BUG_REPORT_URL=" https://bugs.launchpad.net/ubuntu/ " PRIVACY_POLICY_URL=" https://www.ubuntu.com/legal/terms-and-policies/privacy-policy " UBUNTU_CODENAME=resolute LOGO=ubuntu-logo 主机配置: 架构:x86_64 CPU 操作模式:32 位、64 位 地址大小:物理地址 42 位,虚拟地址 48 位 字节顺序:小端 CPU数量:16 在线 CPU 列表:0-15 供应商 ID:GenuineIntel 型号名称:Intel(R) Core(TM) Ultra 7 255H CPU系列:6 型号:197 每个核心的线程数:1 每个插槽的核心数:16 插槽数:1 步数:2 CPU频率扩展(MHz):17% CPU 最大频率:5100.0000 MHz CPU 最低频率:400.0000 MHz DDR内存容量:32GB i.MX8ULP Re: "8MPLUSLPD4-EVK" build issue with Ubuntu 26.04 LTS 你好@middepogudas 希望你一切都好。 imx-linux-scarthgap BSP 已在 Ubuntu 22.04 和 Ubuntu 24.04 中得到验证。 Ubuntu 26.04 默认使用 Python 3.14,而 Bitbake 版本(即 电路板支持包)似乎与 Python 3.14 不完全兼容。 我建议您使用 Ubuntu 24.04 LTS 或 Ubuntu 22.04 LTS 进行编译,直到 Ubuntu 26.04 LTS 完全得到支持为止。 另外,您还可以尝试使用 Python 3.12 的虚拟环境。 顺祝商祺! 萨拉斯。
記事全体を表示
使用NXP MBDT工具箱开发操作系统并将其集成到Simulink中是否可行? 大家好, 我的目标是评估使用 MATLAB/Simulink、Embedded Coder 和 NXP MBDT 为 NXP S32G3 开发完整的裸机操作系统/软件平台的可行性。 目标是在 Simulink 中开发完整的软件栈,使用 Embedded Coder 生成 C 代码,并将生成的代码直接部署到 S32G3 Gold Box 上,而无需依赖外部操作系统、RTOS 或 AUTOSAR BSW。 具体来说,我想了解使用 NXP MBDT 在技术上是否可行,能否在 S32G3 上为 Cortex-A 内核和 Cortex-M 内核实现软件,生成的软件能够处理系统初始化、调度、中断管理、内存管理、硬件抽象、外设初始化、IPC 机制以及操作系统通常提供的其他服务。 我了解到启动 ROM 是硬件驻留的,并且在应用程序之前执行。我的目标是尽可能地使用 NXP MBDT 工作流程,通过 Simulink 生成的代码来实现硬件启动过程之后的所有操作。 因此,我的主要问题是: 1. 使用 NXP 基于模型的设计工具箱以及 MATLAB/Simulink 和 Embedded Coder,为 S32G3 开发一个完整的裸机软件平台(类似操作系统的框架),同时面向 Cortex-A 和 Cortex-M 内核,在技术上是否可行?如果 MBDT 工作流程存在任何限制,能否请您说明哪些部分仍然需要手写 C 代码或汇编代码? 据我了解,MBDT是由NXP公司开发的。但是,如果这个问题更适合由 NXP MBDT 团队解答,请您指点我到合适的联系方式或支持渠道。 感谢您的指导。 Re: Is it feasible for developing the OS using NXP MBDT toolbox which will be integrated to simulink 你好, @charan032001 感谢你的帖子。 我注意到另一个帖子也提到了这件事,而且已经有人回复了。 感谢您对恩智浦产品的关注。 BR 陈银
記事全体を表示
MCXN547: How many Enhanced Flex PWM instances are available? The reference manual mentions 2 instances of PWM modules (PWM0 and PWM1) are available in MCXN547. However, in the header files (MCXN547_cm33_core0_COMMON.h), base addresses for PWM0 is included and not for PWM1.  I am using MCXN547VKLT part and I was planning to use Pin 17 (Port 2_3) for PWM output. MCXN547 datasheet indicates Port 2_3 can be configured as ALT5 - PWM1_B2 function. However, if I use the Pin config tool in MCUXpresso IDE, there is no option to select Pin17 (Port 2_3) for ALT5 - PWM1_B2 function.  Hence, I would like to get confirmation, whether MCXN547VKLT supports 2 instances of Enhanced Flex PWMs.  Clock|Timers MCXN Re: MCXN547: How many Enhanced Flex PWM instances are available? Hello @JawaharA , Thanks for your post. I can confirm that MCXN547VKLT only has one FlexPWM module (FlexPWM0). The Reference Manual and pinmux tables are common to several MCX N series devices (N94/N54/N53/N52/N24), so they may contain signals associated with peripherals that are not present on every device variant. For device-specific feature availability, please refer to Table 4 (Feature Comparison) in the Data Sheet. Based on this table, FlexPWM1 is not available on MCXN547VKLT. Therefore, although P2_3 is listed as PWM1_B2 in the common pinmux table, the function is not supported on MCXN547VKLT, which is why it is not available in MCUXpresso Config Tools. Hope it helps. Please let me know if you have any further questions. BR Celeste
記事全体を表示
MCXN547:有多少个增强型 Flex PWM 实例可用? 参考手册提到 MCXN547 中有 2 个 PWM 模块实例(PWM0 和 PWM1)。然而,在头文件(MCXN547_cm33_core0_COMMON.h)中,PWM0 的基地址已包含在内,但 PWM1 的基地址未包含在内。 我正在使用 MCXN547VKLT 器件,并计划使用引脚 17(端口 2_3)作为 PWM 输出。MCXN547 数据手册表明端口 2_3 可以配置为 ALT5 - PWM1_B2 功能。但是,如果我使用 MCUXpresso IDE 中的引脚配置工具,则没有选项可以选择引脚 17(端口 2_3)作为 ALT5 - PWM1_B2 功能。 因此,我想确认一下,MCXN547VKLT 是否支持 2 个增强型 Flex PWM 实例。 时钟|计时器 MCX N Re: MCXN547: How many Enhanced Flex PWM instances are available? 你好@JawaharA , 感谢你的帖子。 我可以确认 MCXN547VKLT 只有一个 FlexPWM 模块 (FlexPWM0)。 参考手册和引脚复用表是几个 MCX N 系列设备(N94/N54/N53/N52/N24)通用的,因此它们可能包含与某些设备变体上不存在的外围设备相关的信号。 有关设备特定功能的可用性,请参阅数据表中的表 4(功能比较)。根据此表可知,MCXN547VKLT 上没有 FlexPWM1。 因此,尽管 P2_3 在通用引脚复用表中被列为 PWM1_B2,但 MCXN547VKLT 不支持该功能,因此 MCUXpresso 配置工具中没有该功能。 希望对您有所帮助。如果您还有其他问题,请告诉我。 BR 塞莱斯特
記事全体を表示