Zone Node Software & Hardware Environment 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. dragostoma_0-1784698703294.png Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles. 3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer. 4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. dragostoma_0-1784547235185.png Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series. 5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board 6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.

Processor-in-the-Loop (PIL) 1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior. vladmitroi_0-1784549882563.png Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. (function() { var wrapper = document.getElementById('lia-vid-6401636318112w386h386r961'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. (function() { var wrapper = document.getElementById('lia-vid-6401636809112w960h540r168'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation

UM11490とBluetooth Classic NXPサポートの皆様、 お客様の一人がUM11490の149ページから以下のコマンドを実行していますが、波形が見えません。 追加のコマンドや条件が不足していないか、ご確認ください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 ------------------------------------ # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 39 00 00 00 --------------------、TXトランスミッションの前にBLEとCLASSICのスキャンを止めること---------------- # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # BLEスキャンを無効に root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 00 > HCIイベント:0x0eプレン4 01 1A 0C 00 # クラシックスキャンを無効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCIコマンド:ogf 0x08、ocf 0x000c、プレン2 00 00 > HCIイベント:0x0eプレン4 01 0C 20 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 63 07 00 00 **テストモードに入る前にスキャンを無効にすると、TX送信の停止により次のようになります。 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント:0xffプレン6 19 01 ED 04 00 00 Wi-Fi 5GHz用 -------------------------------------------------------------------------------- パラメータ: 連続送信、帯域幅 = 40 MHz、802.11ac、DFSなし、CH = 40、MCS0 (13.5)、電力 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 SDCMD52RW=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 バンド=1 BW=1 チャネル=44 radio_mode[0]=3 radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 0 4294967295 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic こんにちは、 @Christine_Li さん。 文脈が抜けていて申し訳ありません。 カーネルバージョン：lf-6.6.52-2.2.2（6.6.yとマージ済み）コミュニティカーネル FWバージョン：IW612-18.99.3.p25.7、BT/WiFiファームウェアは別々、コンボは不可 製品:IW612 UM11490 バージョン: Rev.1.8 — 2025年6月2日 以下の詳細は近日中に公開されます ファームウェアをロードしたときのdmesgログまたはコンソールログ スペクトラムアナライザの設定画面のスクリーンショット その間、他に何か必要なことがございましたら、お知らせください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 Re: UM11490 and Bluetooth Classic こんにちは、 @pierluigi_p どのWi-Fi/Bluetooth製品を使っていますか? Linuxカーネルのバージョンは何ですか?WiFi/BluetoothドライバとFWバージョンは? コマンドログからは、すべてのHCIコマンドが正常に完了し、TXスタートコマンドがコントローラに受け入れられます。さらに、TX停止コマンドで返されるベンダー固有のイベント情報にはゼロでないパケットカウンタが含まれており、これはコントローラがテスト期間中にパケットが送信されたと判断していることを示します。 したがって、この問題はテストシーケンスにおけるHCIコマンドの欠落が原因ではないと考えられる。 確認することをお勧めします： スペクトラムアナライザの中心周波数とスパンの設定。 TXテストコマンドで設定したBluetoothチャネル。 基板上のRFアンテナ構成。 Bluetoothファームウェアが正しくロードされているかどうか。 また、以下のことも教えていただけますか: 使用されているチップはどれですか（IW416/IW612など）？ 正確なUM11490のバージョンは？ ファームウェアをロードしたときのdmesgログまたはコンソールログは？ コンボファームウェアをインストールしていますか、それともBluetooth専用ファームウェアをインストールしていますか？ スペクトラムアナライザの設定画面のスクリーンショットはありますか？ よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、ピアとクリスティーン 私はHelbert、Verisciteフォーラムでスレッドを始めた開発者です。 テストに関する添付ファイルは以下のとおりです。 dmesgログ（電源設定なし）： dmesgログ（電源設定を含む）： スペクトラムアナライザと5GHz帯の設定ファイル（自社実装およびNXP実装）のスクリーンショット 5GHz-running-test.png 実行後 5GHz-after-test.png 注：電力に-1を使用するとデフォルト値が使用されることがわかりましたが、異なる値も実験しました。 NXPスクリプト: NXP-5GHz-running-test.png 定番のBluetoothテストのスクリーンショット： Bluetooth-2.4-Classic-RUNNING.png ご覧の通り、波形は生成されません BLEテスト実行時のスクリーンショット： BLE-RUNNING-2.4-CH2.png BLEテスト後のスクリーンショット（波形が途切れています）： BLE-FINISHED.png 下の図で、テスト終了時に波形が中断されたことがわかります Modinfoのログ: テストされたHCI CMD: Re: UM11490 and Bluetooth Classic 補足ですが、HackRFの異なる設定(ゲインやグラフィック調整)で試したところ、2.4GHz(Wi-Fi)波形が見えます。さらに、imx-firmwareリポジトリ内の異なるバージョンの異なるファームウェアをテストし、RF-test用のファームウェアも含まれています(sduart_nw61x_rftm_v1.bin.se)は https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se)で成功しませんでした。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細を教えていただきありがとうございます。 あなたの情報とスクリーンショットを確認してから、返信します。 少々お時間をください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細情報をご提供いただきありがとうございます。 あなたのスクリーンショットには背景ノイズが少ししか映っておらず、有用なRF波形情報はありません。 お尋ねしてもよろしいでしょうか？ 1.弊社のIW612-EVKをご利用ですか？または、どのモジュールでも構いませんか？モジュールに関するものであれば、モジュールの部品番号を教えていただけますか？ 2. ハードウェアと試験装置との接続状況はどうですか？ 3.ご質問はBluetoothに関するものですか、それともWi-Fiに関するものですか？ BTの場合、RFテストガイドでテストコマンドが見られますが、停止コマンドは以下の通りです: hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF しかし、あなたは以下を送信しています: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 実行する際は、ガイドに記載されているコマンドに正確に従ってください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。確認していただきありがとうございます。 1.弊社のIW612-EVKをご使用ですか？それとも他のモジュールをご使用ですか？モジュールをご使用の場合は、モジュールの部品番号をお知らせいただけますでしょうか？ 当社では、このモジュールをSoM Variscite DART-IMX8Mに統合しています。https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ 部品番号はLBES5PL2EL.4です。 2. テスト機器とのハードウェア接続はどうですか? HackRF One機器を通じて無線で機器の無線にアクセスでき、アンテナで信号をキャプチャできます(他の信号も受信できます。これがノイズが見られる理由です) 3 - 質問はBTですか、それともWi-Fiですか? どちらの場合にも当てはまります。クラシックなBluetoothでは生成された波形が見えず(Bluetooth Low Energyのみ)、Wi-Fiでは5GHz帯の信号をキャプチャできませんでした HCIコマンドについては両方見ましたし、NXP/Murataの文書でも推奨されています AN14114では、47ページに短いコマンドがあります UM11490では150ページに長いコマンドがあります クラシックなBluetoothについては、解決策を見つけたと思います。UM11490を確認すると、コマンドの説明は次のようになります。 hcitool -i hci0 cmd ドキュメントの例では、tx_test_intervalを0x0Dに設定していますが、このシナリオでは間隔が少し長くなるため、生成された波形が見づらくなります。それはノイズのように見える。このパラメータを0x01に設定すると、波形が一貫しているのが見えました。さらに、低帯域幅の波形であるため、周波数範囲を狭めました。これでBluetoothの問題は解決したと思います。 しかし、5GHzの波形はまだ確認できません。何かコツはありますか？ ご協力ありがとうございました。 Re: UM11490 and Bluetooth Classic クリスティーンさん、私の使用済みSoMに別の村田モジュールが搭載されている可能性が指摘されました。地雷を分解してみると、部品番号が「LBEE5PL2DL」であることが分かりました。 したがって、2ELのコマンドがこのモデルにも適用されるかどうかを確認しなければなりません Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 初期キャプチャの帯域幅を40MHzから20MHzに変更してみていただけますか? echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config 読み上げ結果によると  bw=1  AN14114では次のように定義されています。 40MHz ;  bw=0  は 20MHz 。 HackRFによる観測においては、20MHzの方が最初のテストとして適しています。なぜなら、40MHzのWi-Fiは、狭帯域または限界に近いSDR設定では、きれいに捕捉/認識するのが難しいためです。 20MHz帯で正常に動作するかどうか教えてください。次に、段階的に40MHzへと移行します。   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 情報ありがとうございます。Bluetoothが正常に動作するようになったとのこと、良かったです。 では、Wi-Fi 5GのRFテストモードの問題に焦点を当てましょう。 LBEE5PL2DLモジュールのチップセットは、NXP製のWiFi/BluetoothチップセットであるIW611です。 IW611とIW612の違いは以下の通りです:IW612は802.15.4をサポートしています。しかしIW611はサポートしていません。 しかし、Wi-FiとBluetoothに関しては、IW611とIW612は同じです。 つまり、 2ELのコマンドはこのモデル(LBEE5PL2DL)にも適用できるということです。 では、AN14114のセクション「2 Wi-Fi RFテストモード」に従ってボードを設定し、WiFi 5G RFテストを開始するのを手伝ってください。 現在、あなたが共有してくれた cat /proc/mwlan/adapter0/config の結果からは、疑わしい点は見つかりません。唯一の注意点は、テスト機器の接続とハードウェアの接続を確認することです。 同時に、これら2つのモジュールでRFテストがサポートされているかどうか内部で確認させてください。確認したのは、IW611またはIW612のEVKボードでテストは可能ですが、これら2つのモジュールについては、RF性能をテストするためにハードウェアの再作業が必要かどうかを確認する必要があるということです。 何か進展があればお知らせします。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティーンさん。 サポートありがとうございます。 もう少しデバッグしてみたところ、潜在的な問題点が見つかりました。ここで提供されているファイルを使用してリージョンを変更する場合: https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL、IWのレギュレーションセットに問題があることに気づきました 基本的には、ここに投稿されているアイデアに従ってください:https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working  2EL(および2DL、同じです)用のファイルを使いましたが、リージョンを切り替えた際にiwレジスターの位置が変わっていないことが確認でき、以下のメッセージが表示されました: HelbertPaulino_0-1784905230306.png したがって、ファイル *txpower*.bin でドライバーが使用する領域を変更する際、システムリージョンを変更していたわけではありません。選択した地域や無線機に適用した設定によっては、波形の発生を阻止できる可能性があることが分かりました。 regulatory.db* を削除しました村田製作所から提供されたファイルを使用し、オリジナル版を使用しましたが、動作が改善されたようです。5GHzの波形をいくつか検出できた一方で、ノイズで隠れていると思うものもあります iw reg set/reg と使用されたレギュレーションファイルが波形生成に影響を与えるか確認してもらえますか? もしそうなら、問題の根本原因を見つけたと言えるでしょう。ファームウェアやスクリプト、キャリブレーションファイルの問題ではなく、地域制限の問題です。これは理にかなっていると思いますか？それとも他に容疑者をご存知ですか？ 改めてありがとうございました。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。このメッセージに気づかず、別のメッセージに返信してしまいました。 はい、色々なBW設定を試しましたが、問題はリージョンの制限や一部のリージョンでのノイズに起因するのではないかと考えています。 Re: UM11490 and Bluetooth Classic やあ、クリスティーン コマンドを確認していたのですが、あなたの言う通りですが、なぜそのパラメータ(SHORT_PREAMBLEとADVANCED_CODING)が-1(次のように表される)として表示されているのか分かりません4294967295) おそらく最初の実装で誤って-1に設定されていたのかもしれません。しかし、ご要望に返答すると、5GHz(tx_frame)の波形を生成できるようになりました。tx_continuousでは波形は見えましたが、振幅が小さい(ほとんど見えないほどです) 下の写真でフレーム生成の様子を見ることができます: 5GHz-CH100-BW40-FRAME-0x1100-14.png 連続音をトリガーしようとしたとき、波形は見えましたが、とても滑らかでした 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png 上記の設定を使用しました。 チャネルの波形が見えない問題は、機器内のノイズが波形自体よりも大きいからだと思います。私はハードウェアチームに、より高性能なスペクトラムアナライザを使用して検証するよう依頼しました。生成されていない波形に関する質問を閉じるために、その回答を待っています。 では、領域についてですが、なぜ一部の波形が生成されないのか説明できると思いますか?   Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 以下のコマンドで試してみてください。 echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config tx_frameコマンドの代わりに？ 以前の「cat /proc/mwlan/adapter0/config」の出力で、 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff 正しく認識されないのではないかと心配です。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino はい、誤ったリージョン/レギュレーションドメインの設定も、一部の5 GHz Wi-Fi波形が生成されない理由や、特定のチャネルで全く送信できない理由を説明できます。   貴社のハードウェアチームは、より高性能なスペクトラムアナライザを使用して検証を行う予定ですか？ このCASEで他に何かCANことはありますか?   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。 今回の確認と、彼らが別の無音環境で行ったテストの結果から、すべてが正常に機能していることが確認されたと思います。 サポートありがとうございます。 はじめまして Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino ご返信ありがとうございます。すべてが正常に動作するようになったとのこと、安心しました。 では、このThreadの解決策として私の回答をマークしてくれませんか?SOすればこのCASEを終結CANできます。 また、FUTUREも他のトピックに関する質問があれば、どうぞ新しいCASEを作成してください。 いつでもあなたをサポートできることを嬉しく思います! よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic クリスティン、改めて本当にありがとう。 そうします 🙂

UM11490 和蓝牙经典 尊敬的NXP技术支持： 我们的一位客户正在运行 UM11490 第 149 页中的以下命令，但看不到任何波形。 请检查并确认是否缺少任何其他命令/条件。 谢谢！ 顺祝商祺！ 码头 ------------------------------------ # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 启动TX变速器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 39 00 00 00 -------------------- 在发送数据之前停止对蓝牙低功耗 (BLE) 和经典蓝牙 (Classic) 的扫描 ---------------- # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 禁用蓝牙扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 00 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 禁用经典扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI 命令：ogf 0x08，ocf 0x000c，plen 2 00 00 > HCI 事件：0x0e plen 4 01 0C 20 00 # 启动TX变速器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 63 07 00 00 ** 在进入测试模式前禁用扫描时，TX 传输停止会显示以下信息： root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 ED 04 00 00 适用于 5 GHz Wi-Fi -------------------------------------------------------------------------------- 参数：连续发射，带宽 = 40 MHz，802.11ac无DFS，CH = 40，MCS0（13.5），功率 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config 硬件状态=0 netlink_num=31 驱动模式=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=1 bw=1 频道=44 radio_mode[0]=3 radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic 嗨@Christine_Li ， 抱歉，我没理解上下文： 内核版本：lf-6.6.52-2.2.2 已与 6.6.y 合并社区内核 固件版本：IW612-18.99.3.p25.7独立的蓝牙/WiFi固件，没有组合固件 产品：IW612 UM11490 版本：修订版1.8 — 2025年6月2日 以下详情将尽快公布。 加载固件时，dmesg 日志或控制台日志会显示出来。 频谱分析仪设置的屏幕截图 在此期间，如果您还有任何需要，请随时告知我们。 谢谢！ 顺祝商祺！ 码头 Re: UM11490 and Bluetooth Classic 嗨， @pierluigi_p 您使用的是哪款Wi-Fi/蓝牙产品？ 你的Linux内核版本是多少？WiFi/蓝牙驱动程序和固件版本？ 从命令日志来看，所有 HCI 命令均已成功完成，并且 TX 启动命令已被控制器接受。此外，TX stop 命令返回的厂商特定事件包含非零数据包计数器，这表明控制器认为在测试期间已传输了数据包。 因此，该问题似乎并非由测试序列中缺少 HCI 命令引起。 我建议您查看： 频谱分析仪中心频率和跨度设置。 通过 TX 测试命令配置的蓝牙通道。 板上的射频天线配置。 蓝牙固件是否已正确加载。 您能否也分享一下： 所使用的芯片型号（IW416/IW612等）？ 具体是哪个版本的UM11490？ 加载固件时，dmesg 日志或控制台日志会显示什么？ 你加载的是组合固件还是仅BT固件？ 频谱分析仪设置的截图？ 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 补充一点，我们尝试了 HackRF 的不同设置（增益和图形调整），可以看到 2.4 GHz（wifi）波形。此外，我们还测试了 imx-firmware 存储库中不同版本的不同固件，其中包括一个用于 RF 测试的固件（ https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se中的 sduart_nw61x_rftm_v1.bin.se），但均未成功。 Re: UM11490 and Bluetooth Classic 皮尔和克里斯汀，你们好 我是 Helbert，在 Veriscite 论坛上发起这个帖子的开发者。 以下是一些关于测试的附件： dmesg 日志（不包含电源配置信息）： Dmesg 日志（包含电源配置信息）： 频谱分析仪截图和 5 GHz 的配置文件（包括我自己的实现和 NXP 的实现） 5GHz-running-test.png 修改后 5GHz-after-test.png 注意：我们发现，当功率值为 -1 时，我们使用默认值，但也尝试了不同的值。 NXP脚本： NXP-5GHz-running-test.png 经典蓝牙测试的屏幕截图： Bluetooth-2.4-Classic-RUNNING.png 如图所示，没有生成波形。 BLE测试运行中的屏幕截图： BLE-RUNNING-2.4-CH2.png BLE测试后的屏幕截图（波形中断）： BLE-FINISHED.png 从下图可以看出，测试结束时波形中断了。 模块信息日志： 已测试的 HCI 命令： Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 谢谢你提供详细信息。 我需要查看一下你的信息和截图，然后再回复你。 请给我一些时间。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，Christine，有人提出我的二手SoM里可以再加一个Murata模块。我拆解了地雷，发现它的零件编号是：LBEE5PL2DL 因此，我需要检查一下2EL的指令是否也适用于这个型号。 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 感谢您提供详细信息。 您的截图中只显示了一些背景噪音，没有任何有用的射频波形信息。 请问： 1.您正在使用我们的IW612-EVK吗？或者任何模块？如果是模块，请问您能否告知一下模块的零件编号？ 2.您的硬件与测试设备的连接情况如何？ 3.您的问题是关于蓝牙还是Wi-Fi？ 如果是针对蓝牙的测试，我看到了您的测试命令，根据我们的射频测试指南，停止命令是： hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 但您正在发送： root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 请严格按照我们的指导命令执行操作。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好克里斯汀，谢谢你的核实。 1. 您使用的是我们的 IW612-EVK 模块吗？还是其他模块？如果是模块，能否告知您模块的零件编号？ 我们已将该模块集成到 Variscite DART-IMX8M 系统模块 (SoM) 中https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ 它的零件编号是：LBES5PL2EL.4 2.您的硬件与测试设备的连接情况如何？ 我们通过 HackRF One 设备无线访问设备的无线电，该设备可以使用其天线捕获信号（但它也会捕获其他信号；这就是您看到一些噪声的原因）。 3 - 你的问题是关于蓝牙还是Wi-Fi？ 两者皆适用。对于传统蓝牙，我们无法看到生成的波形（只有低功耗蓝牙可以），而对于 Wi-Fi，我们无法捕获 5 GHz 频段的信号。 关于 hci 命令，我看到了两种说法，NXP/Murata 的文档中都推荐了这两种说法。 在 AN14114 中，我们在第 47 页找到了简短的命令。 在 UM11490 中，第 150 页有很长的命令。 对于经典的蓝牙连接，我想我已经找到了解决方案。检查 UM11490 时，该命令的解释如下： hcitool -i hci0 cmd 文档中的示例将 tx_test_interval 设置为 0x0D，在这种情况下，间隔似乎有点长，因此，很难看到生成的波形。听起来像是噪音。将此参数设置为 0x01 时，我可以看到稳定的波形。此外，由于它是低带宽波形，所以我降低了频率范围。所以，我认为这解决了蓝牙问题。 但是，我仍然看不到 5 GHz 的波形。你有什么建议吗？ 非常感谢您的帮助 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 请尝试将初始捕获的带宽从 40MHz 改为 20MHz？ echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config 您的回读显示  bw=1  ，AN14114 将其定义为 40 MHz ；  bw=0  是 20 MHz 。 对于 HackRF 观察而言，20 MHz 是更好的首次测试，因为在窄带或边缘 SDR 设置上，40 MHz Wi-Fi 更难清晰地捕获/识别。 请问它在 20MHz 下是否运行良好？然后我们逐步过渡到 40MHz。   顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，克里斯汀，我没看到这条消息，回复的是另一条。 是的，我尝试过不同的黑白设置，但我倾向于认为问题可能归因于某些地区的限制和噪声。 Re: UM11490 and Bluetooth Classic 你好，克里斯汀， 非常感谢您的支持。 经过一番调试，我发现这里可能存在问题。使用此处提供的文件更改区域时： https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL我注意到 iw reg set 存在问题 基本上，我参考了这里发布的想法： https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working 我使用了 2EL（和 2DL，它们是一样的）对应的文件，但在切换区域时，我注意到 iw reg get 并没有改变它的位置，并显示了以下消息： HelbertPaulino_0-1784905230306.png 因此，当使用文件 *txpower*.bin 更改驱动程序要使用的区域时，我们并没有更改系统区域。我发现，根据所选区域和应用于收音机的设置，这有可能阻止波形被触发。 我删除了 regulatory.db*我从 Murata 那里获取了文件，并使用了原始文件，而且它似乎表现得更好。我成功触发了一些5GHz的波形，但其他一些波形我认为被噪声掩盖了。 请问iw寄存器组/寄存器以及所使用的监管文件是否会影响波形生成？ 如果答案是肯定的，那么我认为我们找到了问题的根源。这不是固件/脚本/校准文件的问题，而是地区限制。你觉得这个推断合理吗？还是你怀疑另有其他嫌疑人？ 再次非常感谢！ Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 谢谢你的信息，很高兴听到蓝牙现在可以正常工作了。 现在我们来重点讨论 Wi-Fi 5G 射频测试模式问题。 LBEE5PL2DL 模块的芯片组是我们 NXP 的 WiFi/蓝牙芯片组：IW611。 IW611 和 IW612 的区别在于：IW612 支持 802.15.4，但 IW611 不支持。 但对于 WiFi 和蓝牙来说，IW611 和 IW612 是相同的。 所以这意味着， 2EL 的命令也适用于此型号（LBEE5PL2DL）。 现在请按照 AN14114 的第 2 部分“Wi-Fi RF 测试模式”来设置您的板子并开始 WiFi 5G RF 测试。 从你分享的 cat /proc/mwlan/adapter0/config 的输出结果来看，我没有发现任何可疑之处。唯一需要注意的是：请检查您的测试设备连接以及硬件连接。 同时，让我内部确认一下这两个模块是否支持射频测试。我确认的是：我们可以在 IW611 或 IW612 EVK 板上进行测试，但对于这两个模块，我需要检查是否需要进行任何硬件改造才能测试射频性能。 如有任何更新，我会通知您。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，克里斯汀 我正在验证该命令，您是对的，但我不知道为什么这些参数（SHORT_PREAMBLE 和 ADVANCED_CODING）显示为 -1（表示为4294967295）。 或许在代码的最初实现中，它们被错误地设置为了 -1。不过，根据您的要求，现在我们可以生成 5 GHz (tx_frame) 的波形了。对于 tx_continuous，我可以看到波形，但幅度很低（几乎看不见）。 您可以在下图查看帧生成过程： 5GHz-CH100-BW40-FRAME-0x1100-14.png 尝试触发连续信号时，我可以看到波形，但波形非常平滑。 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png 我使用了上述配置。 我认为无法看到通道波形的问题是，我们设备中的噪声比生成的波形要大。我要求硬件团队使用功能更强大的频谱分析仪进行验证。我正在等待他们的回复，以便结束关于非生成波形的问题。 但是关于区域的问题，你认为这可以解释为什么有些波形没有生成吗？   Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 请尝试使用以下命令： echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config 而不是使用 tx_frame 命令？ 我在你之前的输出“cat /proc/mwlan/adapter0/config”中找到了 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff 我担心它可能无法被正确识别。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 是的，错误的区域/监管功能域配置也可以解释为什么某些5GHz Wi-Fi波形无法生成，或者为什么设备在某些信道上完全不发射信号。   你们的硬件团队是否打算使用功能更强大的频谱分析仪进行验证？ 关于这个案子，我还能为您做些什么吗？   顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好，克里斯汀， 我认为这一确认以及他们在另一个无噪音环境下进行的测试证实，现在一切都运行正常了。 非常感谢您的支持。 很高兴见到你 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 感谢您的回复，很高兴听到一切都运行正常了。 那么，能否请您将我的回答标记为本帖的解决方案，以便我们关闭此问题？ 此外，如果您将来有任何其他主题方面的问题，也请随时向我们创建新案例。 我们一直很乐意为您提供支持！ 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 再次非常感谢你，克里斯汀。 我会这么做。 🙂

UM11490 and Bluetooth Classic Dear NXP support, one of our customer is running the following commands from pag 149 of UM11490, but cannot see any waveform. Please kindly check and verify if any additional command / condition is missing. Thanks Best Regards Pier ------------------------------------ # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 39 00 00 00 -------------------- STOPPING THE SCAN FOR BLE AND CLASSIC BEFORE THE TX TRANSMISSION ---------------- # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # DISABLE THE BLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 00 > HCI Event: 0x0e plen 4 01 1A 0C 00 # DISABLE THE CLASSIC SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI Command: ogf 0x08, ocf 0x000c, plen 2 00 00 > HCI Event: 0x0e plen 4 01 0C 20 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 63 07 00 00 ** When disabling the scan before entering in the test mode, the stop for TX transmission give us: root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 ED 04 00 00 For Wifi 5 GHz -------------------------------------------------------------------------------- Paramters: Continuous transmit, BW = 40 MHz, 802.11ac, No DFS, CH = 40, MCS0 (13.5), Power = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 band=1 bw=1 channel=44 radio_mode[0]=3 radio_mode[1]= total rx pkt count=0 rx multicast/broadcast pkt count=0 rx fcs error pkt count=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic Hi @Christine_Li, sorry for missing the context: kernel version: lf-6.6.52-2.2.2 merged with 6.6.y community kernel FW version: IW612-18.99.3.p25.7, sepaated BT/WiFi FW, no combo product: IW612 UM11490 version: Rev. 1.8 — 2 June 2025 The following details will come ASAP dmesg logs or console logs when you load FW screenshot of the spectrum analyzer settings In the meanwhile, please let us know if you may need anything else. Thanks Best Regards Pier Re: UM11490 and Bluetooth Classic Hi, @pierluigi_p  Which Wi-Fi/Bluetooth product are you using? And what is your Linux kernel version? WiFi/Bluetooth driver and FW version? From the command logs, all HCI commands are completed successfully and the TX start command is accepted by the controller. In addition, the vendor-specific event returned by the TX stop command contains non-zero packet counters, which indicates that the controller believes packets have been transmitted during the test period. Therefore, the issue does not appear to be caused by a missing HCI command in the test sequence. I would recommend checking: The spectrum analyzer center frequency and span settings. The Bluetooth channel configured by the TX test command. The RF antenna configuration on the board. Whether the Bluetooth firmware are loaded correctly. Could you also share: The chip being used (IW416/IW612/etc.)? The exact UM11490 version? The dmesg logs or console logs when you load FW? Are you loading a combo FW or BT only FW? A screenshot of the spectrum analyzer settings? Best regards, Christine. Re: UM11490 and Bluetooth Classic Just adding, it was attempted with different settings for HackRF (gain and graphic adjustments), and we can see the 2.4 GHz (wifi) waveforms. Furthermore, we tested using different firmwares, for different versions in the imx-firmware repository, which includes one firmware for RF-test (sduart_nw61x_rftm_v1.bin.se in https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se) without success. Re: UM11490 and Bluetooth Classic Hello Pier and Christine I'm Helbert, the developer who started the thread in the Veriscite forum. Here are some attachments about the testing: Dmesg log (without the power configuration):  Dmesg log (with the power configuration):  Screenshot with the spectrum analyzer and the config file for 5 GHz (own implementation and NXP implementation) 5GHz-running-test.png after 5GHz-after-test.png Note: it was found that using -1 for power, we use the default value, however different values was experimented too. NXP script: NXP-5GHz-running-test.png Screenshot with the classic Bluetooth test: Bluetooth-2.4-Classic-RUNNING.png As you can see, there is no waveform generated Screenshot with the BLE test running: BLE-RUNNING-2.4-CH2.png Screenshot after the BLE testing (waveform interrupted):   BLE-FINISHED.png We can see in the graphic below that the waveform was interrupted when finishing the test Modinfo log: Tested HCI cmds:  Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for providing me the details. Let me check your info and screenshot, then reply to you. Please allow me some time. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi， @HelbertPaulino  Thanks for providing us the details. Your screenshot only shows some Background noise, there is no any useful RF waveform information. May I ask: 1.You are using our IW612-EVK? or any module? If module, would you mind let me know your module part number? 2.How is your HW connections with the test equipment? 3.Your question is for BT or Wi-Fi? If for BT, I see your test commands, in our RF test guide, the stop command is: hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF but you are sending: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 Please follow exactly our guide command to execute. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hello Christine, thanks for your checkings 1.You are using our IW612-EVK? or any module? If module, would you mind let me know your module part number? We have the module integrated into the SoM Variscite DART-IMX8M https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ It has the part number: LBES5PL2EL.4 2.How is your HW connections with the test equipment We have wireless access to the equipment's radio through the HackRF One equipment, which can capture the signals using its antenna (but it can capture other signals too; that's the reason for why you are seeing some noise) 3 - Your question is for BT or Wi-Fi? It's for both. For classical Bluetooth, we weren't able to see the generated waveforms (only for Bluetooth Low Energy), and for Wifi, we couldn't capture signals in 5 GHz About the hci command, I saw both, and we have both recommended in the NXP/Murata documents In AN14114, we have the short command on page 47 In UM11490 we have the long command on page 150 For the classic Bluetooth, I think I found the solution. When checking the UM11490, the explanation for the command is: hcitool -i hci0 cmd The examples in the document set tx_test_interval as 0x0D, in this scenario, the interval seems to be a little longer and, hence, it's a little hard to see the generated waveform. It appears like noise. When setting this parameter to 0x01, I could see a consistent waveform. Furthermore, I decreased the frequency range because it's a low-BW waveform. So, I think this solves the Bluetooth issue. However, I'm still not able to see the 5 GHz waveform. Do you have any tips for it? Thanks very much for your assistance Re: UM11490 and Bluetooth Classic Hey Christhine, It was raised the possibility of having another Murata Module in my used SoM. I disassembled the mine and I detected that its part number is: LBEE5PL2DL Hence, I have to review if the commands for 2EL are applicable to this model too Re: UM11490 and Bluetooth Classic Hello Christine, Thanks very much for your support. Debugging here a little more, I found a potential trouble here. When changing the region using the files provided here: https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL, I noticed a trouble with iw reg set Basically, following the idea posted here: https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working  I used the files directed for 2EL (and 2DL, they are the same), but when switching the regions, I could note that the iw reg get wasn't changing its location, by presenting the following message: HelbertPaulino_0-1784905230306.png Hence, when changing the regions to be used by the driver with the file *txpower*.bin, we weren't changing the system region. I saw that this has the potential to prevent the waveforms from being triggered, depending on the chosen region and settings applied to the radio. I removed the regulatory.db* files from Murata and used the original, and it seems to have better behavior. I was able to trigger some 5 GHz waveforms, and others I think are being masked by the noises May you confirm if the iw reg set / reg and the used regulatory files can affect the waveform generation? If yes, then I think we found the root cause of the problem. It's not Firmware / Script / Calibration files, but a region limitation. Do you think it makes sense or do you have another suspect for this? Thanks very much again Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for your info and glad to hear that Bluetooth is now working. So now let's focus on the Wi-Fi 5G RF test mode issue. LBEE5PL2DL module's Chipset is our NXP's WiFi/Bluetooth chipset: IW611. The difference between IW611 and IW612 is: IW612 supports 802.15.4, but IW611 does not support. But for WiFi and Bluetooth, IW611 and IW612 are same. So it means,  the commands for 2EL are applicable to this model(LBEE5PL2DL) too. Then now please help to follow AN14114's section: 2 Wi-Fi RF test mode to set your board and start the WiFi 5G RF test. Currently from your shared cat /proc/mwlan/adapter0/config results, I do not find any suspect points. The only thing is: please check your test equipment connections and also HW connections. At the same time, let me check internally to see whether it is supported to test RF on these 2 modules. What I confirmed is: we can test on our IW611 or IW612 EVK board, but for these 2 modules, I need to check whether need to do any HW reworks to allow to test RF performance. Once have any updates, will let you know. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi Christine, I didn't see this message and replied to the other. Yes, I tried different BW settings, but I'm trending to think the problem can be attributed to the region limitation and noise in some regions. Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Can you please have a try with changing 40MHz to 20 MHz bandwidth for initial capture? echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config Your readback shows  bw=1  , which AN14114 defines as 40 MHz ;  bw=0  is 20 MHz . For HackRF observation, 20 MHz is the better first test because 40 MHz Wi-Fi is harder to capture/recognize cleanly on a narrow or marginal SDR setup. Please let me know whether it works fine for 20MHZ. Then we step by step to move to 40MHZ.   Best regards, Christine. Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Can you please have a try with below command: echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config instead of tx_frame command？ I found in your previous output of "cat /proc/mwlan/adapter0/config" tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff I worry it might not be recognized correctly. Best regards, Christine. Re: UM11490 and Bluetooth Classic Hey Christine I was verifying the command, and you are right, but I don't know why that parameters (SHORT_PREAMBLE and ADVANCED_CODING) was appearing as -1 (represented as 4294967295) Maybe in the first implementation for the code, they was wrongly set as -1. However, replying your request, now we can generate the waveform for 5 GHz (tx_frame). For tx_continuous I could see the waveforme, but in a lower amplitude (almost not possible to see) You can look the frame generation in the picture below: 5GHz-CH100-BW40-FRAME-0x1100-14.png When trying to trigger the continuous, I could see the waveform, but very smoothly 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png I used the configuration above. I think the problem of not being able to see the waveforms for channels is due to the noise we have in the equipment are bigger than the waveform generated. I requested the Hardware team to verify using a more powerful spectrum analyzer. I'm waiting for its response to close the question for the non-generated waveforms. But about the regions, do you think it can explain why some waveforms are not being generated?   Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Yes, an incorrect Region/Regulatory Domain configuration can also explain why some 5 GHz Wi-Fi waveforms are not being generated, or why the device does not transmit at all on certain channels.    Does your Hardware team to verify using a more powerful spectrum analyzer? Anything else I can do for you on this case?   Best regards, Christine. Re: UM11490 and Bluetooth Classic Hello Christine, I think this confirmation and the tests that the guys did in another noiseless environment confirm that everything is now working properly. Thanks very much for your support. Nice to meet you Re: UM11490 and Bluetooth Classic Hi, @HelbertPaulino  Thanks for your reply and glad to hear that everything is now working properly. Then would you please help to mark my answer as a solution for this thread so that we can close this case? And also, please feel free to create new case to us if you have any other topic questions in the future. We are always glad to support you! Best regards, Christine. Re: UM11490 and Bluetooth Classic Thanks very much again, Christine. I'll do that 🙂

Radar - SW & HW Environment 1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model. Automated Driving - Bird's-Eye Plot.png   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation S32R45 Radar MPU Block Diagram.png   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX

求找适用于 PCF8563TS/5,118 的电容 我正在使用 PCF8563TS/5,118 IC，想正确连接 OSCI 引脚上的外部电容。 我正在使用 50k ESR、12.5pF 32.568KHz 的晶体，尽可能短的走线，原理图与数据手册中的应用图完全相同。 我查阅了数据手册和 UM10301，尝试进行计算，以了解该设备。我发现很难找到一种清晰的方法来计算外部电容的值，因为数据表在同一主题的不同页面上提到了并联和串联，即 OSCI 和 OSCO。 我看到外部 OSCI 和 OSCO 引脚并联了一个内部 25pF 电容。数据手册中的表 30 表明 CL 是并联计算的，但有一个注释显示，CL 是串联电容的计算方法。 我找不到能让设备正常工作的外接电容。没有收到 I2C 响应。我尝试了 25pF、22.5pF、20pF、25pF、10pF、8.2pF、6pF。所有 0603 C0G/NP0 帽。 我通过完全不放置电容器，成功地让它在另一块板上工作了。经过计算，这根本说不通。 我想请您举例说明一下如何计算这些输入值（12.5pF 50k ESR 晶体），因为我无论通过计算还是暴力破解都无法使其正常工作。 Re: Help finding capacitor for PCF8563TS/5,118 是的，那是内置电容的数值，我在自己的帖子中也提到过。我已阅读过该文件。 如果你能把你想表达的意思写下来，那会更有帮助。感谢您抽出时间。 Re: Help finding capacitor for PCF8563TS/5,118 db16122_0-1784461035005.png UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123 和 PCA21125 用户手册 Re: Help finding capacitor for PCF8563TS/5,118 亲爱的戴维： db16122 正确地指出了UM10301 中的表 3。如果您的目标负载电容为 12.5pF，则需要在 OSCI 引脚上连接一个 25pF 的中间值的微调电容。 JozefKozon_0-1784524368704.png JozefKozon_1-1784524409356.png 这个 25pF 值可以通过表 30 下方的公式计算得出。在PCF8563 数据手册中。 JozefKozon_2-1784524493868.png 其中 CL 为目标负载电容，在本例中为 12.5pF。 Cosco 是已知的内部电容，25pF。 JozefKozon_3-1784524560452.png 根据公式，可以推导出 Ctrim 值： CL=Ctrim*Cosco/(Ctrim+Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim 边际贡献 = CL * Cosco / (Cosco - CL) = 12.5 * 25 / (25 - 12.5) = 312.5 / 12.5 Ctrim=25pF 由于内部 Cosco 电容还有余量，因此需要可变微调电容。Cosco 值可能在 15pF 到 35pF 之间波动。 JozefKozon_4-1784525019076.png 最诚挚的问候， 约瑟夫

PCF8563TS/5,118用のコンデンサを探すお手伝いをします 私はPCF8563TS/5118 ICを使用しており、OSCIピンの外部コンデンサを正しく接続しようとしています。 私は50k ESR、12.5pF、32.568KHzの結晶、可能な限り短いトレース、データシートのアプリケーション図と同じ回路図を使っています。 デバイスを理解するために、データシートとUM10301の両方を参照して計算を試みました。外部コンデンサの値を明確に計算する方法を見つけるのが難しかったです。なぜなら、データシートには同じトピックの別々のページ、OSCIとOSCOで並列と直列が記載されているからです。 外部のOSCIピンとOSCOピンに並列に25pFの内部コンデンサが接続されているのがわかります。データシートの表30では、CLは並列接続の場合に計算されると記載されていますが、代わりに直列接続の場合の計算方法を示す注記があります。 デバイスを動かす外部コンデンサが見つかりません。I2Cからの応答がありません。25pF、22.5pF、20pF、25pF、10pF、8.2pF、6pFを試しました。0603 C0G/NP0 キャップすべて。 別の基板では、コンデンサを全く取り付けないことで動作させることができました。計算してみると、それは全く意味をなさない。 これらの入力値（12.5pF、50k ESR水晶発振器）の計算方法の例を教えていただけないでしょうか。計算しても、値を総当たりで試しても、うまく動作させることができませんでした。 Re: Help finding capacitor for PCF8563TS/5,118 はい、それは内蔵コンデンサの値で、私自身の投稿でも触れました。私はそのファイルを読みました。 あなたが伝えたいことを実際に書いてくれた方が、はるかに役に立つでしょう。時間を割いていただきありがとうございました。 Re: Help finding capacitor for PCF8563TS/5,118 db16122_0-1784461035005.png UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123、PCA21125のユーザーマニュアル Re: Help finding capacitor for PCF8563TS/5,118 親愛なるデイビッド、 db16122さんが正しく表3を案内してくれました。UM10301で。目標負荷静電容量が12.5pFなら、OSCIピンに25pF中間値のトリムコンデンサを接続する必要があります。 JozefKozon_0-1784524368704.png JozefKozon_1-1784524409356.png この25pF値は表30の下記式から計算できます。PCF8563のデータシートに記載されています。 JozefKozon_2-1784524493868.png ここでCLは目標負荷静電容量、あなたの場合は12.5pFです。 コスコは既知の内部静電容量、25pFです。 JozefKozon_3-1784524560452.png この式から、Ctrimは次のように導くことができます: CL = Ctrim * Cosco / (Ctrim + Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim Ctrim = CL * Cosco / (Cosco - CL) = 12.5 * 25 / (25 - 12.5) = 312.5 / 12.5 Ctrim=25pF 可変トリムコンデンサが必要なのは、内部のCoscoコンデンサに余裕があるためです。Coscoは15pFから35pFの範囲で変動する場合があります。 JozefKozon_4-1784525019076.png 敬具、 ヨゼフ

Help finding capacitor for PCF8563TS/5,118 I'm working with a PCF8563TS/5,118 IC, trying to get the external cap on OSCI pin right.  I'm working with a 50k ESR, 12.5pF 32.568KHz crystal, shortest possible traces, Schematic just like in the application diagram on the datasheet. I tried making the calculations by consulting both the datasheet and UM10301 to get an understanding on the device. I found it difficult to find out a clear way to calculate the value for the external cap because the datasheet mentions parallel and series on different pages of the same topic, OSCI and OSCO.  I see there is an internal 25pF cap in parallel with the external OSCI and OSCO pins. Table 30 on the datasheet indicates CL is calculated in parallel, but has a note that shows the calculation for series capacitors instead. I can't find an external cap that makes the device work. Getting no I2C response. I tried 25pF, 22.5pF, 20pF, 25pF, 10pF, 8.2pF, 6pF. All 0603 C0G/NP0 caps. I did get it to work on a different board by not placing a capacitor at all. Which doesn't make any sense after making the calculations. I would like to please get an example of how you calculate a value for these inputs (12.5pF 50k ESR crystal) because I haven't been able to make it work neither by calculating it nor by bruteforcing values. Re: Help finding capacitor for PCF8563TS/5,118 Yes that's the value of the integrated internal capacitor and I mentioned that in my own post. I have read that file. It would be way more helpful if you actually wrote what you intend to convey. Thanks for taking the time though Re: Help finding capacitor for PCF8563TS/5,118 db16122_0-1784461035005.png UM10301 User Manual for PCF85x3, PCF85x63, PCA8565, PCF2123, and PCA21125 Re: Help finding capacitor for PCF8563TS/5,118 Dear David, db16122 correctly pointed you to the Table 3. in the UM10301. If your target load capacitance is 12.5pF, then you need to connect a trim capacitor on the OSCI pin with 25pF middle value.  JozefKozon_0-1784524368704.png JozefKozon_1-1784524409356.png This 25pF value can be calculated from the formula below the Table 30. in the PCF8563 datasheet.  JozefKozon_2-1784524493868.png Where CL is the target load capacitance, in your case 12.5pF.  Cosco is the known internal capacitance, the 25pF.  JozefKozon_3-1784524560452.png From the formula, the Ctrim can deduced: CL=Ctrim*Cosco/(Ctrim+Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim Ctrim=CL*Cosco/(Cosco-CL)=12.5*25/(25-12.5)=312.5/12.5 Ctrim=25pF The variable trim capacitor is required because there is margin for the internal Cosco capacitor. Cosco may vary from 15pF to 35pF.  JozefKozon_4-1784525019076.png With Best Regards, Jozef

FreeMaster Over CAN on interrupt on 轮询模式 编译失败 我尝试修改“FreeMaster over CAN”和“s32k3xx_fm_over_can_s32ct”生成的代码，以启用轮询模式。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN和FMSTR_DEBUG_TX 但最终编译失败，原因是传输功能 freemaster 通过 can 从“s32k3xx_fm_over_can_s32ct”响应中断，但如果电机控制情况使用许多 irq，例如至少 10khz 的快速任务以及 bctu 和 hall、wagtch dog，freemaster 没有收到来自控制器 k312 的响应，因此需要轮询模式。 如何启用这 3 个微控制器并为“s32k3xx_fm_over_can_s32ct”打开轮询模式？ Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 沟通方式是互斥的选项。错误信息的意思正是如此。 FreeMASTER 驱动程序例程可能需要较长的处理时间，以下 3 个设置旨在帮助开发人员根据不同的使用场景平衡执行时间： FMSTR_POLL_DRIVEN - FreeMASTER 例程完全在 FMSTR_Poll 函数中执行 - 开发人员可以决定何时调用该例程，但必须确保其调用频率足以使 FreeMASTER 跟上通信速度。 FMSTR_LONG_INTR - FreeMASTER 例程完全在 FMSTR_CanIIsr 函数中执行 - 开发人员通过分配更高的优先级强制系统执行它（我假设之所以使用这个优先级，是因为它最适合处理大量中断的情况）。 FMSTR_SHORT_INTR 是前两者的混合体：通信发生在中断处理程序 (FMSTR_CanIsr) 中，但处理发生在 (FMSTR_Poll) 中。 我认为你想尝试的是最后一种方法（轮询+中断的组合）。虽然中断可以保证读取 CAN 帧，但如果 FMSTR_Poll 没有被足够频繁地调用（由于优先级更高的中断），则电路板可能无法及时响应。因此，FreeMASTER桌面工具将显示超时错误。 开发人员必须确保系统能够为计算密集型应用程序中的 FreeMASTER 驱动程序例程分配足够的时间。 希望这能帮助大家了解 FreeMASTER 的通信模式。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我之前也尝试过使用和你一样的设置： 例如，我将FMSTR_POLL_DRIVEN 改为 1（之前为 0，表示中断模式）。 // 选择中断驱动或轮询驱动的串行通信 #define FMSTR_LONG_INTR 1 // 在中断中完成消息处理 #define FMSTR_SHORT_INTR 0 //中断中完成排队 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7. 错误：主要原因是 #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN )) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN )) || \ ( FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !( FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* 中断模式不匹配，只能选择一种 */ #错误您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 #endif 上述编译过程中出现了 3 个错误。 ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ 一个不够，两个也都失败了。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes ， 要启用轮询模式，您需要更新以下宏： #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 这 3 个参数中只能有一个设置为 1，否则代码将无法编译。 关于FMSTR_DEBUG_TX - 这是一个用于验证 TX 线的调试宏。结合之前的定义，得出以下定义： #define FMSTR_DEBUG_TX 1 将指示 FreeMASTER 驱动程序持续发送调试帧（注意：这有助于您检查 TX 线，但启用此功能后，您将无法使用 FreeMASTER 工具连接到电路板）。 能否分享一下编译错误日志？ 据我所知， s32k3xx_fm_over_can_s32ct 示例是由基于模型的设计工具箱 (MBDT)团队实现的。如果您使用 Simulink 开发应用程序，则可能需要更新模块配置，而不是手动修改代码。在这种情况下，MBDT 开发人员可以通过专用的 MBDT社区为您的用例提供更好的帮助。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes ， 我会尝试排查FMSTR_LONG_INTR模式的问题，因为它是唯一有效的模式，即使只能维持很短的时间。我会调查以下几个方面： 您能否使用逻辑分析仪检查 CAN 总线，并确认 CAN 消息是否不再从电路板发送，或者是否正在发送但已损坏？ 在PC端，你读取了多少个变量？变量的数量与PC工具和板之间交换的数据量成正比。如果可能的话，我会先从几个变量开始，然后逐渐增加变量的数量，看看什么时候会出问题。 除了 FreeMASTER 驱动程序之外，还有其他程序使用 CAN 实例吗？ 您是从 MATLAB/Simulink 模型还是 S32 Design Studio 示例应用程序开始的？根据原始来源的不同，FreeMASTER CAN 驱动程序的实现方式可能会有所不同。 如果可以，请附上源文件（它们应该命名为freemaster_s32_flexcan.h和freemaster_s32_flexcan.c ）。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 感谢你的澄清，是的，我的目标是轮询+中断相结合。 重述问题：目标 k312 在 FreeAmster 运行一段时间后无法发送响应。 以下是反馈意见： 中断模式：freemaster 工作正常，问题如上所述，仅限 FMSTR_LONG_INTR 轮询模式：编译，freemaster 无法工作，即使移除 freemaster_private.h:326:2 中的 FMSTR_POLL_DRIVEN 错误消息： 混合：freemaster 可以运行，可以编译，但流量问题仍然存在，FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 这三个值都设置为 1，并移除 freemaster_private.h:326:2 处的错误消息： 现在我推断：可能是我的 CAN 驱动程序问题。 如果您可以提供进一步的支持，您需要哪些信息？ Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1、我使用 PeakCan View 来监控消息流， 是的，板不再发送CAN消息了。 Freemaster 运行正常时，消息闪烁非常快；Freemaster 死机时，从 S32k312minEVB 发送的 CAN 消息明显停止，但从 Freemaster 读取的消息仍然可见且速度很慢； 2，总共少于 20 个变量，但数量远小于 demon fm 项目 s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3. CAN 实例仅供 freemaster 使用； 您说得对，我们的 BSW 使用 RTD 来实现 CAN 上的 FM，集成了 DEMON s32k3xx_fm_over_can_s32ct MCAL 驱动程序中的 flexcan_43 和 flexcan_ipw 层。但上述问题仍在解决中。 顺便说一下，由于 CAN IP 层限制，我们的 can 驱动程序可以接受标准消息 ID，所以 freeamster 配置设置：发送标准，接收扩展。 请查收附件中的 4 个文件，它们与您关系密切。 您需要所有 CAN IP 配置文件吗？实际上所有 43/ipw 配置都与 demon s32k3xx_fm_over_can_s32ct 相同。 您也可以直接给我发邮件。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes ， 很遗憾，我没有在这个帖子里找到任何附件，但我从 MBDT 获取了这些文件，它确实与我们团队的实现方式不同。 您能否尝试将 MBDT 实现替换为我们的版本（请参阅附件 - 这些文件对应于freemaster_s32k3xx_can.c和freemaster_s32k3xx_can.h ）？ 我注意到的一个不一致之处在于 CAN 中断处理程序的签名： FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 对比 void FMSTR_CanIsr(void); 假设 CAN 详细信息（例如缓冲区 ID）已在freemaster_cfg.h中定义我们不需要在处理程序中使用它们。我们也使用 RTD（底层硬件层），您的配置不应更改。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我上传文件请求失败，请问如何将文件上传到这个帖子？ Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 除了请求帮助查找重置 CAN 读取缓冲区的任何功能之外， 我还怀疑MBD CAN驱动程序代码Can_43_FLEXCAN_Ipw.c中做了一处修改。 其中，函数 当我将 MBD MCAL CAN 驱动程序形容功能时作“内置”，形容器件时作“集成”到 RTD NON-MCAL 驱动程序中时，Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 被强制使用 memcpy 进行传输。 如果没有手动传输，使用 RTD NON-MCAL CAN 驱动程序时，Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 将无法读取所有 CAN 信息。 原版 MBD DEMON s32k3xx_fm_over_can_s32ct 不需要手动传输，因为 demon 使用的是 MCAL CAN 43 驱动程序。 如果手动传输会导致 Freemaster 问题，有没有办法避免在函数 Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() 中进行手动传输？ 或者通过你知道的某个功能手动RESET缓冲区？ static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer （ const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ） { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 反馈：感谢您提供RTD版本的FreeMaster驱动程序代码， 我用 rtd 驱动程序 freemaster_can_flexcan 中的 FMSTR_CanIsr() 替换了 mcal 驱动程序 freemaster_s32k3xx_can 中的 MBD 版本函数 FMSTR_CanIsr(*,*,*..*)。 集成和运行，Freemaster 无法连接到 s32k312MINEVB。 当 S32K312N=MINEVB 无法发送消息时，freemaster 冻结，我开始调试，发现软件处于忙于读取状态，导致 CAN 读取未完成，间接导致 CAN 发送延迟无限长； 是否有类似缓冲区满时RESET读取操作的手动清除缓冲区的功能？

エッジAI imx93でEDGE AIアプリを提案する Re: edge ai i.MX 93には、エッジAIの産業用ビジョン/タッチレスHMIアプリケーションが最も適していると提案します。 i.MX 93に適合する理由： i.MX 93は、インダストリアル、オートモーティブ、IoTマーケット全体でML加速と高速エッジ推論を備えた省エネエッジ・コンピューティングを目的としています。 組み込みおよびIoTデバイスにおける機械学習推論の高速化を目的としたArm Ethos-U65 microNPUを統合しています。 NXPのドキュメントには、産業用HMI、産業用ビジョン、産業用オートメーション、タッチレスアクセス制御、マシンビジョンが93の応用分野として具体的に挙げられています i.MX。 このプラットフォームは、コンピュータビジョン、音声認識、物体検出、顔認識、ポーズ検出などのAIユースケースをサポートしています。 実用的なアプリのコンセプト： スマートインダストリアルビジョン+タッチレスオペレーターインターフェース 機能例： 部品の存在、ラベルチェック、欠陥スクリーニングのためのカメラベースの物体検出。 非接触式機械制御のためのジェスチャーまたは姿勢検出。 オプションで音声コマンドインターフェースを備え、ハンズフリー操作が可能です。 i.MX 93でのローカル推論により、クラウド依存度とレイテンシを削減します。 i.MX 93セキュリティアーキテクチャを用いた安全なデバイス識別およびライフサイクルサポートを提供し、i.MX 93資料で言及されたEdgeLock関連機能も含まれます。 i.MX 93のエッジAIアプリケーションとして有望なその他の候補： アプリのアイデア なぜそれが適しているのか スマートドアベル/アクセスコントロール 顔/物体検出と局所推論を用い、スマートドアベルとスマートロックは93 i.MX スマートホームのターゲットに挙げられています。 ドライバー監視システム DMSは i.MX 93のオートモーティブ認定部品に明確にリストされています。 異常検知付きエネルギーメーター エネルギーメーターはインダストリアル/ビル制御用途として記載されています。MLはローカルで使用状況の異常を検出できます。 スマートフィットネス／姿勢検出デモ ポーズ検出やスマートフィットネスの例は、エッジAIのユースケースとして記録されています。 最良のおすすめは、i.MX 93上でインダストリアル ビジョンやタッチレスHMIエッジAIアプリを構築することです。これは文書化された i.MX 93 NPU、インダストリアル ビジョン、HMI、ローカルML推論のユースケースに直接連動するからです。

如何使用 S32 设计工作室 MCP 集成 如何使用S32 Design Studio MCP集成？是否有相关资料和文档？ Re: How to use S32 Design Studio MCP Integration 你好， 遗憾的是，相关文档和使用示例仍在开发中。我希望它能尽快对外发布，但不知道具体日期。

ISP tuning in FRDM I am currently bringing up a Bayer sensor in Verdin iMX95 FRDM kit and have got stream and about to start the ISP tuning. The tuning here is totally different and has a vast difference from iMX8M Plus. Has anyone already done tuning with Verdin iMX95 kit.

LLCE FlexRay configuration on S32DS Hi,  I am encountering a configuration issue for LLCE FlexRay on S32DS. I would like to set this parameter to TRUE, after spending a long time on the IDE, still could not find the right place to change it. Is there someone can provide any clue? My IDE version is S32DS3.5.10. Thank you in advance. LLCE_FlexRay_Config.png Re: LLCE FlexRay configuration on S32DS Hi,Yang_C Thank you for contacting us. What version of LLCE are you using? And are you using S32G2 or S32G3? BR Joey Re: LLCE FlexRay configuration on S32DS Hi Joey, I am using S32G399 with S32DS3.5.10, LLCE 1.0.7, RTD 4.0.2.  BR, Yang Re: LLCE FlexRay configuration on S32DS Hi,Yang_C This seems to be an issue with the software itself. I will assist you in confirming it with the internal software developers! BR Joey Re: LLCE FlexRay configuration on S32DS Hi Joey, Thank you for your help. Looking forward to you reply. BR, Yang Re: LLCE FlexRay configuration on S32DS Hi,Yang_C Regarding "repeatTx", the driver is supported, but the interface configuration interface in EB is not. The main reason is that "repeatTx" is not a standard ECUC configuration item defined by the AUTOSAR FlexRay Interface (FrIf) specification, but rather an underlying Message Buffer extension attribute of the NXP FlexRay_IP Driver. BR Joey Re: LLCE FlexRay configuration on S32DS Thank you Joey. I will try manually update. Re: LLCE FlexRay configuration on S32DS Hi,Yang_C Thank you for your reply. The S32DS is also not configurable and needs to be manually modified, but there are drivers that can achieve this function.  BR Joey Re: LLCE FlexRay configuration on S32DS Hi Joey, Thanks for your reply, I am a little bit confused because you mentioned EB does not support configuring 'Repeat TX', but I am using S32DS. Wondering if S32DS support set repeat TX for FlexRay? BR, Yang

S32DSにおけるLLCE FlexRay構成 こんにちは、 S32DS 上で LLCE FlexRay の設定に関する問題が発生しています。 このパラメータをTRUEにしたいのですが、IDEで長い時間を費やしたのに、正しい変更場所が見つかりませんでした。何か手がかりをくれる方はいませんか? 私のIDEバージョンはS32DS3.5.10です。 事前に感謝いたします。 LLCE_FlexRay_Config.png Re: LLCE FlexRay configuration on S32DS こんにちは、 Yang_C お問い合わせいただきありがとうございます。 使用しているLLCEのバージョンは何ですか？S32G2とS32G3のどちらを使用していますか？ BR ジョーイ Re: LLCE FlexRay configuration on S32DS こんにちは、ジョーイ。 私はS32DS3.5.10でS32G399を使用しています。LLCE 1.0.7、RTD 4.0.2 BR、 ヤン Re: LLCE FlexRay configuration on S32DS こんにちは、ジョーイ。 ご協力ありがとうございます。 お返事をお待ちしております。 BR、 ヤン Re: LLCE FlexRay configuration on S32DS こんにちは、 Yang_C これはソフトウェア自体の問題のようです。社内のソフトウェア開発者と確認するのを手伝います! BR ジョーイ Re: LLCE FlexRay configuration on S32DS こんにちは、 Yang_C 「repeatTx」についてはドライバーはサポートされていますが、EBのインターフェース設定インターフェースはサポートされていません。主な理由は、「repeatTx」がAUTOSAR FlexRay Interface(FrIf)仕様で定義された標準的なECUC設定項目ではなく、NXP FlexRay_IPドライバーの基盤となるMessage Buffer拡張属性であるためです。 BR ジョーイ Re: LLCE FlexRay configuration on S32DS こんにちは、Yang_C ご返信よろしくお願いします。 S32DSも設定不可で手動で修正する必要がありますが、この機能を実現できるドライバもあります。 BR ジョーイ Re: LLCE FlexRay configuration on S32DS こんにちは、ジョーイ。 ご返信ありがとうございます。EBが「Repeat TX」の設定をサポートしていないとおっしゃっていましたが、私はS32DSを使っています。S32DSのサポートがFlexRayのリピート送信を設定しているのか気になっていますか? BR、 ヤン Re: LLCE FlexRay configuration on S32DS ありがとう、ジョーイ。手動でアップデートしてみます。

FreeMaster Over CANは割り込み時にポーリングモードでコンパイルできません 「FreeMaster over CAN」と「s32k3xx_fm_over_can_s32ct」から生成されたコードから、ポーリングモードを有効にするために3 micoを変更しようとしています。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN 、およびFMSTR_DEBUG_TX しかしコンパイルに失敗しました。理由は、転送機能のフリーマスターオーバーが割り込み時に「s32k3xx_fm_over_can_s32ct」応答から可能になるためです。しかし、モータ制御の場合、少なくとも10kHzの高速タスクやBCTU、ホール、ワッチドッグ、フリーマスターはControllewr K312からの応答を受け取れず、ポーリングモードが必要です。 これら3つのマイクロコントローラを有効にして、「s32k3xx_fm_over_can_s32ct」のポーリングモードを開く方法 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 通信手段は相互に排他的な選択肢である。エラーメッセージはまさにそのことを意味しています。 FreeMASTERドライバールーチンはかなりの処理時間を必要とする場合があり、これら3つの設定は利用ケースに応じて実行のバランスを取るのに役立ちます。 FMSTR_POLL_DRIVEN - FreeMASTERルーチンはFMSTR_Poll関数内で完全に実行されます。開発者は呼び出しタイミングを決定しますが、FreeMASTERが通信速度に追いつけるような頻度で呼び出されるようにする必要があります。 FMSTR_LONG_INTR - FreeMASTERルーチンは完全にFMSTR_CanIIsr関数内で実行されます。デベオパーはシステムに高い優先度を割り当てることで実行を強制します(これは多数の割り込み時に最適だったため使われたと思います)。 FMSTR_SHORT_INTR - は前述の2つの混合であり、通信は割り込みハンドラー(FMSTR_CanIsr)で行われ、プロセッシングは(FMSTR_Poll)で行われます あなたが試すべきなのは、最後の方法（ポーリングと割り込みの組み合わせ）だと思います。それでも割り込みはCANフレームの読み取りを保証するかもしれませんが、FMSTR_Poll呼び出す頻度が十分でない場合(より高い優先度の割り込みによる)、ボードが時間通りに応答しないことがあります。その結果、FreeMASTERデスクトップツールでタイムアウトエラーが表示されます。 開発者は、計算集約型アプリケーションにおいてFreeMASTERドライバーのルーチンに十分な時間を割り当てられるかを確実にしなければなりません。 これでFreeMASTERの通信モードが明確になったことを願います。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 以前、あなたと同じ設定で試してみました。 例えば、 FMSTR_POLL_DRIVENを1に変更しました（以前は割り込みモードとして0でした）。 // 割り込み駆動またはポーリング駆動のシリアル通信を選択します #define FMSTR_LONG_INTR 1 割り込みにおけるメッセージプロセッシングの完了 #define FMSTR_SHORT_INTR 0 //割り込みでキューイングが完了 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7 エラー: 主に #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN )) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN )) || \ ( FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !( FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) 割り込みモードでは1つだけ選択可能です */ #エラーFMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります #endif コンパイル時に上記で3つのエラーが発生しました ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: エラー: #error FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります 326 | #エラー FMSTR_LONG_INTR、FMSTR_SHORT_INTR、またはFMSTR_POLL_DRIVENのいずれか1つだけを有効にする必要があります。 | ^~~~~ 1つでは不十分だが、2つでもすべて失敗に終わった。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 ポーリングモードを有効にするには、以下のマクロを更新する必要があります。 #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 3つのうち1つだけを1に設定する必要があります。そうしないと、コードはコンパイルされません。 FMSTR_DEBUG_TXについてですが、これはTXラインを検証するためのデバッグマクロです。これまでの定義と合わせて、次の定義も考えられます。 #define FMSTR_DEBUG_TX 1 FreeMASTERドライバーに継続的にデバッグフレームを送信するよう指示します(注:これはTXラインの検査に役立ちますが、この機能が有効になっている間はFreeMASTERツールでボードに接続できません)。 コンパイルエラーログを共有してもらえますか? 私の知る限り、s32k3xx_fm_over_can_s32ct例はモデルベースデザインツールボックス(MBDT)チームによって実装されています 。Simulinkでアプリケーションを開発する場合、手動のコード変更ではなくブロック設定の更新が必要になるかもしれません。この場合、MBDT開発者は専用のMBDTコミュニティを通じて、あなたのユースケースにより適切な支援を提供できます 。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ご説明ありがとうございます。はい、ポーリングと割り込みの組み合わせが私の目標です。 問題の要約：ターゲットk312は、freeamsterをしばらく実行した後、応答を送信できません。 フィードバックは以下のとおりです。 割り込みモード：フリーマスター動作中、上記の問題発生、FMSTR_LONG_INTRのみ ポーリングモード: コンパイル、freemaster が動作しない、freemaster_private.h:326:2 のエラーメッセージを削除しても FMSTR_POLL_DRIVEN: 混合:FreeMasterは動作し、コンパイルは可能ですがトラフィックの問題は残ります。FMSTR_LONG_INTRまたはFMSTR_SHORT_INTRまたはFMSTR_POLL_DRIVENの3つすべてが1に設定され、freemaster_private.h:326:2のエラーメッセージが削除されます: 今は正当化します:おそらくCANドライバーの問題かもしれません。 もし追加のサポートができるなら、どのような情報が必要ですか? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 FMSTR_LONG_INTRモードは、たとえ短時間しか動作しないとしても、唯一動作するモードなので、このモードのトラブルシューティングを試みるつもりです。私が調査するであろう事項は以下のとおりです。 ロジックアナライザでCANバスを点検して、CANメッセージがボードから送信されていないのか、送信されているものの破損しているのかを確認できますか? PC側で読み込んでいる変数はいくつありますか？変数の数は、PCツールとボード間でやり取りされるデータ量に正比例する。可能であれば、まずは少数の変数から始めて、徐々に数を増やしていき、どこで問題が発生するかを確認したいです。 CANインスタンスはFreeMASTERドライバー以外のルーチンで使われていますか? MATLAB/Simulinkモデルから始めましたか?それともS32 Design Studioのサンプルアプリケーションから始めましたか?元のソースによって、FreeMASTER CANドライバの実装は異なる場合があります。 可能であれば、ソースファイル（ freemaster_s32_flexcan.hとfreemaster_s32_flexcan.cという名前である必要があります）を添付してください。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1. Peakcan Viewを使用してメッセージフローを監視しました。 はい、CANメッセージはもうボードから送信されていません フリーアムスターがスムーズに動作しているとき、メッセージが非常に速く点滅します。freeamasterがフリーズすると、S32k312minEVBから送信されたCANメッセージは停止したようですが、Freemasterからのメッセージは依然として表示され、動作が遅くなっています。 2、合計で20個の変数が少ないですが、その数はdemon fmプロジェクトs32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct"よりもはるかに少ないです。 3.フリーマスター専用のCANインスタンス; おっしゃる通り、私たちのBSWはRTDを使ってCANを使ったFMを実装し、DEMON s32k3xx_fm_over_can_s32ct MCALドライバーのflexcan_43とflexcan_ipwレイヤーを統合しています。しかし、上記の問題にはまだ取り組んでいます。 ちなみに、CANのIP層制限により、私たちのCANドライバは標準のmsg IDを受け入れることができるので、freeamsterの設定設定:標準送信、受信拡張。 添付ファイルに、あなたに近いと思われる4つのファイルがありますのでご確認ください。 すべてのCAN IP設定ファイルが必要ですか？実際、43/ipw はすべて demon s32k3xx_fm_over_can_s32ct と同じように構成されます。 直接メールで連絡することもできます。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode こんにちは、 @millerhughes さん。 残念ながらこのThreadには添付ファイルは見つかりませんでしたが、MBDTから入手したファイルでは、確かに私たちのチームの実装とは異なっていました。 MBDTの実装を私たちのバージョン(添付ファイル参照 - freemaster_s32k3xx_can.c とfreemaster_s32k3xx_can.hに対応しています)に置き換えてみてはどうでしょうか。 私が気づいた一つの矛盾点は、CAN割り込みハンドラのシグネチャです: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 対 void FMSTR_CanIsr(void); CANの詳細(バッファIDなど)がfreemaster_cfg.hで定義されていると仮定しますハンドラー内でそれらは必要ありません。当社もRTD（低ハードウェア層）を使用しており、お客様の設定を変更する必要はありません。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ファイルのアップロードリクエストに失敗しました。このThreadにファイルをアップロードする方法 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode ただし、CAN readバッファをリセットする関数を探す助けを求めてください。 また、MBD CANドライバーコードCan_43_FLEXCAN_Ipw.cに変更が加わったのではないかと疑っています MBD MCAL CANドライバーをRTD非MCALドライバーに統合すると、機能Can_43_FLEXCAN_Ipw_ProcessRxMesgBufferが強制的にMEMCPYに転送されます。 手動転送がなければ、RTD非MCALのCANドライバーを使うCan_43_FLEXCAN_Ipw_ProcessRxMesgBufferすべてのCAN情報を読み取れません。 オリジナルのMBD DEMON s32k3xx_fm_over_can_s32ct手動転送は不要です。なぜなら、demonはMCAL CAN 43ドライバを使用しているからです。 Freemasterの問題を引き起こす場合、関数Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer()での手動転送を回避する方法はありますか？ あるいは、あなたが知っている何らかの機能を使ってバッファを手動でリセットすることもできますか？ static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer （ const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig、 const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig、 uint8 u8MbIdx ） { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode フィードバック:RTD版Freemasterドライバーコードの提供ありがとうございます。 MBDのバージョン機能はFMSTR_CanIsr(*,*,*..*)はMCALドライバ freemaster_s32k3xx_canで、RTDドライバ freemaster_can_flexcanではFMSTR_CanIsr()によって使われています。 統合と実行時に、Freemasterがs32k312MINEVBとの接続に失敗しました。 フリーマスターがフリーズしたときにデバッグを始めました。S32K312N=MINEVBがメッセージを送信失敗したとき、SWが「読み取れる」状態になり、これが未完了のCAN読み取りを引き起こし、間接的には送信遅延が無制限になることがわかりました。 バッファがいっぱいになった場合にリセットするなど、読み取り用のバッファを手動でクリアする機能はありますか？

LX2160A上でVSC8254 PHYを1G SGMIIモードで起動するためのサポートが必要です こんにちは、みんな、 LX2160A Rev2 SoCをベースにしたカスタムボードに取り組んでおり、VSC8254 PHYがeMDIO1を通じてSoCに接続されています。現在、1G SGMIIモードでPHYを起動する際に問題が発生しています。 これまでのところ、DPCファイルとLinuxカーネルデバイスツリーの両方で固定リンクを設定することで、10G XFIモードでPHYを正常に起動できました。起動後、NXPが提供するmdio_cl45_writeスクリプトを実行して必要なClause 45レジスタをプログラムすると、リンクが確立され、正常に動作します。 しかし、構成を1G SGMIIモードに切り替える際には、以下の変更を行います。 DPCとLinuxデバイスツリーをXFIではなくSGMIIに更新してください。 1Gに対応するClause 45レジスタの初期化シーケンスを実行します。 新しい構成に合わせて、SERDESリファレンスクロックを125MHzから100MHzに更新してください。 これらの変更にもかかわらず、PHYリンクは確立されません。 参考までに： VSC8254 PHYはMAC3およびMAC4に接続SERDES1。 10G XFI構成にはRCW 6を使用しています。 1G SGMII構成にはRCW 4を使用しています。 1G SGMIIモードでPHYを起動するために追加の設定変更や初期化ステップがあれば教えていただけますか? お時間をいただき、サポートありがとうございます。 @yipingwan @chenyin_h Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. RCW[SRDS_PLL_REF_CLK_SEL_S1]を「00」に設定してください。 2. Linuxカーネルで「CONFIG_VITESSE_PHY」を設定してください。 3. Linux Kernel dts ファイル arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts にて、dpmac3とdpmac4の設定を以下のように変更してください。 &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "in-band-status"; }; aquantia_phy1: ethernet-phy@4 { /* AQR107 PHY */ 互換 = "イーサネット-Phy-IEEE802.3-C45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; 変更後: &dpmac3 { phy-handle = <&sgmii_phy1>; phy-connection-type = "sgmii"; managed = "in-band-status"; }; sgmii_phy1: イーサネット-phy@xx{ reg = <0xxx>;//dpmac3関連のMDIO PHYアドレスを指定         }; 4. dtc ファイル dpc-usxgmii.dts を以下のように変更してください。 掲示板情報 { ポルト mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; 変更後: 掲示板情報 { ポルト mac@3 { link_type = "MAC_LINK_TYPE_PHY";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY";                         };

FreeMaster Over CAN on interrupt fail to compile in polling mode I try to change those 3 mico for enabling polling mode from code generated from  "FreeMaster over CAN" and "s32k3xx_fm_over_can_s32ct"  FMSTR_SHORT_INTR, FMSTR_POLL_DRIVEN, and FMSTR_DEBUG_TX but end with compiling failed, reason is that transfer feature freemaster over can from "s32k3xx_fm_over_can_s32ct"  reply on interrupt, but if motor control case using many irq like least 10khz fast task and bctu and hall , wagtch dog, freemaster received no response from controllewr k312, polling mode is necessary. how to enable those 3 micros and open polling mode for "s32k3xx_fm_over_can_s32ct"  Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Communication modes are mutually exclusive options. That's exactly what the error message means. FreeMASTER Driver routine may require a significative processing time and those 3 settings try to help developers to balance the execution depending on use case as follows: FMSTR_POLL_DRIVEN - FreeMASTER routine is executed entirely in the FMSTR_Poll function - developers decides when it is called but has to make sure that it is invoked at such frequency that allows FreeMASTER to keep up with the communication speed FMSTR_LONG_INTR - FreeMASTER routine is executed entirely in the FMSTR_CanIIsr function - deveopers forces the system to executed it by assigning a higher priority (I assume this one was used as it fits best in case of big number of interrupts) FMSTR_SHORT_INTR - is a mix of the previous two: the communication is happening in the interrupt handler (FMSTR_CanIsr), but the processing - in (FMSTR_Poll) I think what you want to try is the last one (combination of polling + interrupt). Still, while the interrupt may guarantee that the CAN frames will be read, the board may not reply on time if FMSTR_Poll is not invoked frequently enough (due to interrupts with higher priority). As a result - FreeMASTER desktop tool will show timeout errors. The developer has to make sure that the system can allocate sufficient time for FreeMASTER Driver routines in compute intensive applications. Hope it clarifies FreeMASTER's communication modes. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I did try before using same setting as you: for example,  I changed FMSTR_POLL_DRIVEN as 1 (was 0.as interrupt mode) // Select interrupt or poll-driven serial communication #define FMSTR_LONG_INTR 1 // Complete message processing in interrupt #define FMSTR_SHORT_INTR 0 // Queuing done in interrupt #define FMSTR_POLL_DRIVEN 1/*0 */ 7 error: mainly because of #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !(FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* mismatch in interrupt modes, only one can be selected */ #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN #endif  3 error happen above for compile ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ one is not enough, but two even all also failed. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, To enable Polling mode you need to update the following macros: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 only one out of those 3 should be set to 1, overwise the code won't compile. Regarding FMSTR_DEBUG_TX - this is a debug macro that is meant to verify the TX line. Combined with previous definitions this one: #define FMSTR_DEBUG_TX 1 will instruct FreeMASTER Driver to continuously send a debug frame (note: this helps you inspecting the TX line and you won't be able to connect to the board using FreeMASTER tool while this functionality is enabled). Could you share your compilation error logs ? As far as I know, s32k3xx_fm_over_can_s32ct example is implemented by Model-Based Design Toolbox (MBDT) team. If you develop your application using Simulink, it may require updating block configuration instead of manual code changes. In this case, MBDT developers can provide better assistance for your use case through the dedicated MBDT community. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, I would try to troubleshoot the FMSTR_LONG_INTR mode, considering it is the only mode that works, even if only for a short time. The things I would look into are: Can you inspect the CAN bus with a logic analyzer and check whether the CAN messages are no longer being sent from the board, or if they are being sent but become corrupted? How many variables are you reading on the PC side? The number of variables is directly proportional to the amount of data exchanged between the PC tool and the board. If possible, I would start with a few variables and gradually increase the number to see when it breaks. Is the CAN instance used by any routines other than the FreeMASTER Driver? Did you start with a MATLAB/Simulink model or an S32 Design Studio example application? Depending on the original source, the FreeMASTER CAN driver implementation may differ. If possible, please attach the source files (they should be named freemaster_s32_flexcan.h and freemaster_s32_flexcan.c). Re: FreeMaster Over CAN on interrupt fail to compile in polling mode thanks for clarification, yes, combination of polling + interrupt is my target. restate issue: target k312 fail to send response after freeamster running a while. now feedback is following: interrupt mode: freemaster working, issue shown above, FMSTR_LONG_INTR only polling mode: compile,, freemaster not working ,  FMSTR_POLL_DRIVEN even if remove error message on freemaster_private.h:326:2: mixed: freemaster working, can compile  but traffic issue remain , all three of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN set as 1 and removing error message on freemaster_private.h:326:2: now I justify :Could be my CAN driver issue. which information do you need if your can provide further support? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1, I used peakcan view to monitor message flow, yes, CAN messages are no longer being sent from the board when freeamster smoothly working, message flashing very fast; when freeamaster freeze, CAN message sent from S32k312minEVB stopped apparently  but message read from freemaster still visible and slow; 2, totally less 20 variables, but amount is much smaller than demon fm project s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3.CAN instance solely used by freemaster; you are right,  our BSW use RTD ,to implement FM over CAN,  flexcan_43 and flexcan_ipw  layer from DEMON s32k3xx_fm_over_can_s32ct MCAL driver are integrated. but still working with issue above. by the way, due to CAN IP layer limit, our can driver can accept standard msg ID, so freeamster configue setting : send standard, receeive extension. please find atatched 4 files I have, which are close to you. do you need all CAN IP configure files? actually all 43/ipw configure same as demon s32k3xx_fm_over_can_s32ct. You can also directly email me. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, Unfortunately, I did not find any attachments on the this thread, but I got those files from MBDT and it indeed differs from the our team's implementation. Could you try replacing MBDT implementation with our version (see attachments - those correspond to freemaster_s32k3xx_can.c and freemaster_s32k3xx_can.h). One inconsistency I noticed is the CAN interrupt handler signature: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); vs void FMSTR_CanIsr(void); Assuming CAN details (such as buffer IDs) are defined in freemaster_cfg.h we do not need them in the handler. We also use RTD (low hardware layer) and  your configuration should not change. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I fail to upload files request, how to upload files into this thread Re: FreeMaster Over CAN on interrupt fail to compile in polling mode except request help to find any function to reset CAN read buffer, I  also suspect one change made for MBD CAN driver code Can_43_FLEXCAN_Ipw.c where, function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer are forced to memcpy to transfer when I integrate MBD MCAL CAN driver into RTD NON-MCAL driver. if no manual transfer, Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer fail to read all can information when using RTD NON-MCAL CAN driver. original MBD DEMON s32k3xx_fm_over_can_s32ct dont need manual transfer, because demon use MCAL CAN 43 driver. is any way to avoid manual trasnfer in function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() if it cause Freemaster issue? or manual reset buffer via some function you know? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig->Can_u8ControllerID][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode feedback: thanks for supply rtd version freemaster driver code, I did replace MBD version function FMSTR_CanIsr(*,*,*..*) in mcal driver freemaster_s32k3xx_can  by FMSTR_CanIsr() in rtd driver  freemaster_can_flexcan. integration and run, Freemaster fail to connect with s32k312MINEVB. I start to debug when freemaster freeze when S32K312N=MINEVB fail to send out message, I found out sw in status of busy to read, which cause unfinished CAN read ,indirectly cause can sent delay unlimited; is any functions to manually clear buffer for read like reset if buffer are full?

LX2160A 上的 VSC8254 PHY 在 1G SGMII 模式下启动需要协助 大家好， 我们正在开发一款基于 LX2160A Rev2 SoC 的定制电路板，其中 VSC8254 PHY 通过 eMDIO1 连接到 SoC。目前我们在 1G SGMII 模式下启动 PHY 时遇到问题。 到目前为止，我们已经通过在 DPC 文件和 Linux 内核设备树中配置固定链路，成功地在 10G XFI 模式下启动了 PHY。启动后，我们执行 NXP 提供的 mdio_cl45_write 脚本来对所需的 Clause 45 寄存器进行编程，之后链接建立并正常运行。 但是，当我们将配置切换到 1G SGMII 模式时，我们会进行以下更改： 更新 DPC 和 Linux 设备树，使其使用 SGMII 而不是 XFI。 执行 1G 对应的 Clause 45 寄存器初始化序列。 根据新配置的要求，将 SERDES 参考时钟从 125 MHz 更新为 100 MHz。 尽管做了这些更改，PHY 链路仍然无法建立。 供参考： VSC8254 PHY 连接到 SERDES1 MAC3 和 MAC4。 我们使用 RCW 6 进行 10G XFI 配置。 我们对 1G SGMII 配置采用 RCW 4。 关于在 1G SGMII 模式下启动 PHY 是否需要任何额外的配置更改或初始化步骤，请与我们联系。 感谢您的时间和支持。 @yipingwang @chenyin_h Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. 请将 RCW[SRDS_PLL_REF_CLK_SEL_S1] 配置为“00”。 2. 请在 Linux 内核中配置“CONFIG_VITESSE_PHY”。 3. 在 Linux 启动 dts 文件 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 中，请修改 dpmac3 和 dpmac4 的配置，使其与下面的配置类似。 &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "带内状态"; }; aquantia_phy1：以太网物理层@4 { /* AQR107 PHY */ 兼容 = "ethernet-phy-ieee802.3-c45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; 修改为： &dpmac3 { phy-handle = <&sgmii_phy1>; phy-connection-type = "sgmii"; managed = "带内状态"; }; sgmii_phy1：以太网物理层@xx{ reg = <0xxx>;//指定与dpmac3相关的MDIO PHY地址         }; 4. 请按如下方式修改 dtc 文件 dpc-usxgmii.dts。 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; 修改为： 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY";                         };

FRDM中的ISP调谐 我目前正在 Verdin iMX95 FRDM 套件中安装拜耳传感器，已经获得了信号流，即将开始 ISP 调优。这里的调音完全不同，与 iMX8M Plus 有很大的不同。有人用Verdin iMX95套件进行过调校吗？