i.MX用設定ツール このツールの i.MX 26.06 設定ツール i.mx952 も動作しません。エラー:プロセッサデータベースをダウンロードできません。 Re: Config Tools for i.MX こんにちは、 @onkarbhalerao さん。 NXPサポートまでご連絡いただきありがとうございます。 こちら側でテストしてみましたが、特に問題は確認されませんでした。 インターネット接続をもう一度確認して、もう一度お試しいただけますか? 問題が続く場合は、MCUXpresso SDK Builderを使って必要なファイルを手動でダウンロードできます よろしくお願いします、 チャビラ

I.MX6 VPU 编码特性 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们正在评估 i.mx6 VPU 对从摄像头图像流编码为 H.264 的性能。 由于我对 i.MX6 的流媒体编码完全不熟悉，所以在选择传感器时遇到了困难。我对此有些疑问。 1. VPU 对 H.264 编码支持的最大分辨率是多少？ 2. H.264 编码在最高分辨率下支持的最大帧速率是多少？ 3. VPU 支持的 H.264 编码输入色彩空间有哪些？ 4. 如果分辨率较低，例如 640*480 像素，与 1920*1080 像素相比，H.264 编码能否获得更高的帧速率？ 5. 帧速率是否受比特率限制？ 6.是否可以将流从IPU路由到VPU进行编码？ 谢谢！ 古纳 图形与显示 i.MX6 四核 Linux 多媒体 Yocto Project Re: I.MX6 VPU Encoding Features 你好，Artur 是否可以在解码 1920x1080 30FPS 视频的同时，对 1920x1080 30FPS 视频进行编码？此外，也没有任何文件说明此信息是否属实？ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 太感谢了 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.水平分辨率限制为 1080 像素，但 MJPEG BP 配置文件的最大图像尺寸可达 8192x8192 像素。 2. 没有直接的像素/秒与工作频率的关系规范。此外，VPU 的吞吐量对于编码和解码操作是不同的。它可以编码一个 1920x1080@30fps 流，并解码一个 1920x1080@30fps 流和一个 D1@30fps 流。 阿图尔 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 阿图尔·佩图霍夫 谢谢你的回复。 为了澄清一下，这是否意味着即使 VPU 运行频率为 352MHz，我也无法使用 VPU 进行 1600 x 1200 (UXGA) h264 编码？ 如何计算VPU工作频率下的吞吐量？我查阅资料得知，266MHz 运行频率下的吞吐量约为72,576,000像素/秒。你能帮我解决这个问题吗？ Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Q1.VPU对H.264编码支持的最大分辨率是多少？ Q2.H.264编码在最高分辨率下支持的最大帧速率是多少？ A1-2。i.MX6系列处理器的视频处理单元（VPU）可以 以最高 1920x1080@30fps 分辨率/帧速率对视频流进行编码/解码。 Q3.VPU支持的H.264编码输入色彩空间有哪些？ A3. 支持的输入色彩空间为 YUV4:2:0，但 MJPEG 编解码器除外。 支持 4:2:0、4:2:2、2:2:4、4:4:4 和 4:0:0。 第四季度。如果分辨率较低，例如 640*480 像素，与 1920*1080 像素相比，使用 H.264 编码能否获得更高的帧速率？ A4。是的。 Q5.帧速率是否受比特率限制？ A5. 您指的是编码视频流的比特率吗？如果真是这样，答案是：帧速率和比特率之间没有直接关系，最终的比特率主要取决于所使用的编解码器和编码配置文件。 Q6.是否可以将流从IPU路由到VPU进行编码？ A6. 是的，可以使用系统内存中的帧缓冲区。例如，IPU 使用双缓冲方案将摄像头捕获的帧存储到系统内存中，然后 VPU 从那里获取帧进行编码。 祝你有美好的一天， 阿图尔 ----------------------------------------------------------------------------------------------------------------------- 注：如果此回复解答了您的问题，请点击“正确答案”按钮。谢谢你！ ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢。我开始玩那个了。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我无法给你答案，你可以联系http://www.chipsnmedia.com/ 。 我查阅的所有资料都无法解答这个问题。 http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http %3A% 2F %2Fwww.chipsnmedia.com% 2Fsupport %2Fdown% 2Fcnm-codadx6-datashe… 我建议你在船上试试。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武， 如果真是这样，那么有可能实现 640 x 480 @ 90 fps 的分辨率吗？ 谢谢！ 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> #1 我不在乎最大比特率或最大时钟频率。 我认为任何小于“1920*1080*30”的常规“宽度*高度*帧率”都适合h264编码。 #2 i.MX 平台必须具有“物理内存分配器 API”，该 API 可处理 DMA 和缓存一致性。 如果“IPU 输出”和“VPU 输入”共享同一内存和同一图像格式，则无需复制或转换。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武， 感谢您的回复。 我有些疑问。 1.对于 4 和 5， 如果限制条件是宽度*高度*帧率，那么VPU支持的最大比特率是多少？我在他们的文档中找不到相关信息。据我所知，VPU 的运行速度最高可达 352MHz。 2. 对于 6， SDMA 可以用于此吗？如果答案是肯定的，那么这样做有什么限制吗？ 谢谢！ 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 简称： #1,2 1920x1080@30fps #3 YUV422(NV12)、YUV420 #4,5 我认为限制条件是“宽度*高度*帧率”。 # 6 我认为你可能需要进行格式转换或使用 memcpy 命令。 详情如下： http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…

Python で ReadPipeUIntArray を使用するとセグメンテーション違反が発生します こんにちは、 現在、パイプを使用してターゲットからホストへデータパケット（ヘッダー＋ペイロード）をストリーミングしようとしていますが、問題が発生しています。 ReadPipeUIntArrayを使用してバイナリデータを読み込む際に、fmliteが頻繁にクラッシュします。参考として、Pythonのサンプルコードとfmliteの出力結果を添付しました。 前もって感謝します Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @tschue-nxt さん。 現在この問題について調査中です。進展があり次第、ご連絡いたします。 Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、@tschue-nxt さん。 添付のFMLITEバイナリを確認して、あなたのケースで動作するか教えてもらえますか? Re: Segmentation fault when using ReadPipeUIntArray via Python こんにちは、 @iulian_stan さん。 見た目も良く、ここ数分間はスムーズに動作しています。迅速な対応ありがとうございました！

S32K358 SWAP AB的MCAL-XDRC配置 有3个问题请帮忙解答一下： 1. 目前我需要使用SWAP功能。在RM模块里的XDRC的memory congfig中还需要对flash B-block：0x800000-0xbfffff进行定义吗？ 2. HSE占用的flash空间0x7D4000-0x7FFFFF需要在memory congfig里删除吗？ 3. 我把core0定义为主核，跑OS。把core2定义为副核，跑算法。那么我在Domain_Assgnment_0里分配了CM7_0,CM7_1,GMAC,uSDHC,eDMA内容;在Domain_Assgnment_1中分配了CM7_2;这样对吗？实际应用中没有使用的master是不是可以不用出现在配置里？ Re: S32K358 SWAP AB的MCAL-XDRC配置 嗨@scott071209 1.应用程序或引导加载程序需要：擦除、编程、验证和读取被动分区中映像的详细信息。这意味着被动分区也应该由 XRDC 覆盖。 2. 对于 AB_SWAP 固件，RESET 期间会自动配置 XRDC，以保护 HSE FW 活动闪存区域、HSE FW 无源闪存区域、HSE FW 数据闪存和 HSE UTEST 区域。描述符 12-15 用于此目的，并且此配置已锁定，因此用户无法修改。详细信息请参阅 HSE 固件参考手册的以下章节： “14.6.3.3默认 MRC 0 配置 (AB_SWAP)” 因此，您无需通过自己的 XRDC 配置来涵盖 HSE 资源。 3. 是的，您可以使用这样的设置。如果未使用主服务器，则可以在配置中省略它。 但是，如果您使用 HSE，则还需要为 HSE 配置功能域 3。这不是为了保护 HSE 资源，而是为了赋予 HSE 访问用户数据的权限，以便能够执行加密操作。 S32K358 有四个功能域，HSE 总是被分配到最高可用功能域。以 S32K358 为例，它是功能域 3。这是硬编码的，无法更改。在新版本的 RTD 中，HSE 主站甚至不在 XRDC 配置的列表中，因为它无法重新配置。如果您只想在功能域 3 中拥有 HSE，则无需为此功能域分配任何主服务器。HSE（健康、安全和环境）功能已自动启用。 在较早的 RTD 版本中，可以将 HSE 分配给其他域，但这种配置没有任何效果。因此它被移除了。 问候， 卢卡斯

S32K358 + FreeRTOS：PendSV_Handler 期间出现随机硬故障 大家好， 我在运行 FreeRTOS 的S32K358上遇到了随机硬故障问题。 应用程序长时间正常运行后突然卡死。系统停止运行后，软件看门狗（SWT）得不到服务，最终导致控制器重置。 故障并非立即发生，而是在连续执行约1 至 2 小时后出现。 故障停止后，调用堆栈显示： PendSV_Handler() ↓ HardFault_Handler() 寄存器值： LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5看起来像是内存初始化模式，而不是有效的返回地址。 其他登记簿： R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 任何建议或调试技巧都将不胜感激。 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@nirmal_masilamani ， 看起来在 FreeRTOS 上下文切换期间保存的任务上下文已损坏。 PendSV 被 FreeRTOS 用于上下文切换，因此，如果在 PendSV_Handler() 内部发生 HardFault，通常意味着调度程序正在尝试恢复无效的任务上下文。 一个可能的根本原因是任务堆栈溢出。我建议增加任务的堆栈大小并启用 FreeRTOS 堆栈溢出检测： configCHECK_FOR_STACK_OVERFLOW 实现： vApplicationStackOverflowHook()。 此外，您可以使用 uxTaskGetStackHighWaterMark() 定期监测每个任务的剩余堆栈空间。这有助于在故障发生之前识别出接近堆栈限制运行的任务。 此致， 丹尼尔 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@danielmartynek ， 感谢您的回复。 我已经尝试过增加堆栈大小，启用堆栈溢出钩子。 我在溢出钩子中添加了调试 CAN 消息，但发生故障时没有收到该消息。 同时监控uxTaskGetStackHighWaterMark()，当发生故障时 任务 1：1977 × 4 ≈ 7908 字节可用空间 任务 2：1971 × 4 ≈ 7884 字节可用空间 任务 3：3988 × 4 ≈ 15952 字节可用空间 Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler 你好@nirmal_masilamani ， 因此，我们大概可以排除堆栈溢出是根本原因的可能性。 然而，任务上下文仍然会遭到破坏。处理器正在恢复 LR = 0xA5A5A5A5，这导致了 UsageFault。0xA5A5A5A5 是由 tskSTACK_FILL_BYTE (0xA5U) 生成的模式，FreeRTOS 使用该模式在创建任务堆栈时填充任务堆栈。 因此，如果 LR 变为 0xA5A5A5A5，则上下文将从仍然包含原始堆栈填充模式的位置恢复，而不是从有效的寄存器值恢复。 如果存储过程损坏，就可能发生这种情况。在这种情况下，PendSV_Handler() 会从 RAM 中的错误位置恢复任务上下文。 你应该能够根据堆栈指针地址识别出 SRAM 区域。 我建议您使用 MPU 和 XRDC 对该区域进行适当保护。 另外，是否有任何中断调用 FreeRTOS API？如果是这样，他们是否使用了 FromISR() 变体，并且他们的优先级是否根据 configMAX_SYSCALL_INTERRUPT_PRIORITY 正确配置？ 此致， 丹尼尔

使用 Python 的 ReadPipeUIntArray 时出现段错误。 您好， 目前我遇到的问题是，我想使用管道将数据包（头部+有效载荷）从目标流式传输到主机。 使用 ReadPipeUIntArray 读取二进制数据时，我经常遇到 fmlite 崩溃的情况。我附上了一个 Python 示例和 fmlite 输出作为参考。 提前致谢 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@tschue-nxt ， 我们正在调查此事，一旦有最新进展，我们会立即通知您。 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@tschue-nxt ， 请您检查一下附件中的 fmlite 二进制文件，并与我们联系它是否能在您的设备上正常运行。 Re: Segmentation fault when using ReadPipeUIntArray via Python 嗨@iulian_stan ， 看起来不错，已经流畅运行好几分钟了。感谢你们快速修复！

Segmentation fault when using ReadPipeUIntArray via Python Hi, I am running into issues currently where I want to use a pipe to stream data packets (header+payload) from target to host. When using ReadPipeUIntArray to read the binary data I am running into fmlite crashes frequently. I attached a python example and fmlite output as reference. Thanks in advance Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, We are looking into this issue and will get back to you once we have an update. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, Could you check the attached fmlite binary and let us know if it works in your case. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @iulian_stan, looks good, working smoothly for quite some minutes now. Thanks for the fast fix!

Radar – Processing Chain – NXP Radar SDK 1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.

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. 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. 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. 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実装）のスクリーンショット 実行後 注：電力に-1を使用するとデフォルト値が使用されることがわかりましたが、異なる値も実験しました。 NXPスクリプト: 定番のBluetoothテストのスクリーンショット： ご覧の通り、波形は生成されません BLEテスト実行時のスクリーンショット： BLEテスト後のスクリーンショット（波形が途切れています）： 下の図で、テスト終了時に波形が中断されたことがわかります 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レジスターの位置が変わっていないことが確認でき、以下のメッセージが表示されました: したがって、ファイル *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では波形は見えましたが、振幅が小さい(ほとんど見えないほどです) 下の写真でフレーム生成の様子を見ることができます: 連続音をトリガーしようとしたとき、波形は見えましたが、とても滑らかでした 上記の設定を使用しました。 チャネルの波形が見えない問題は、機器内のノイズが波形自体よりも大きいからだと思います。私はハードウェアチームに、より高性能なスペクトラムアナライザを使用して検証するよう依頼しました。生成されていない波形に関する質問を閉じるために、その回答を待っています。 では、領域についてですが、なぜ一部の波形が生成されないのか説明できると思いますか?   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 的实现） 修改后 注意：我们发现，当功率值为 -1 时，我们使用默认值，但也尝试了不同的值。 NXP脚本： 经典蓝牙测试的屏幕截图： 如图所示，没有生成波形。 BLE测试运行中的屏幕截图： BLE测试后的屏幕截图（波形中断）： 从下图可以看出，测试结束时波形中断了。 模块信息日志： 已测试的 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 并没有改变它的位置，并显示了以下消息： 因此，当使用文件 *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，我可以看到波形，但幅度很低（几乎看不见）。 您可以在下图查看帧生成过程： 尝试触发连续信号时，我可以看到波形，但波形非常平滑。 我使用了上述配置。 我认为无法看到通道波形的问题是，我们设备中的噪声比生成的波形要大。我要求硬件团队使用功能更强大的频谱分析仪进行验证。我正在等待他们的回复，以便结束关于非生成波形的问题。 但是关于区域的问题，你认为这可以解释为什么有些波形没有生成吗？   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) after Note: it was found that using -1 for power, we use the default value, however different values was experimented too. NXP script: Screenshot with the classic Bluetooth test: As you can see, there is no waveform generated Screenshot with the BLE test running: Screenshot after the BLE testing (waveform interrupted):   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: 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: When trying to trigger the continuous, I could see the waveform, but very smoothly 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.   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   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 UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123 和 PCA21125 用户手册 Re: Help finding capacitor for PCF8563TS/5,118 亲爱的戴维： db16122 正确地指出了UM10301 中的表 3。如果您的目标负载电容为 12.5pF，则需要在 OSCI 引脚上连接一个 25pF 的中间值的微调电容。 这个 25pF 值可以通过表 30 下方的公式计算得出。在PCF8563 数据手册中。 其中 CL 为目标负载电容，在本例中为 12.5pF。 Cosco 是已知的内部电容，25pF。 根据公式，可以推导出 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 之间波动。 最诚挚的问候， 约瑟夫

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 UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123、PCA21125のユーザーマニュアル Re: Help finding capacitor for PCF8563TS/5,118 親愛なるデイビッド、 db16122さんが正しく表3を案内してくれました。UM10301で。目標負荷静電容量が12.5pFなら、OSCIピンに25pF中間値のトリムコンデンサを接続する必要があります。 この25pF値は表30の下記式から計算できます。PCF8563のデータシートに記載されています。 ここでCLは目標負荷静電容量、あなたの場合は12.5pFです。 コスコは既知の内部静電容量、25pFです。 この式から、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の範囲で変動する場合があります。 敬具、 ヨゼフ

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 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.  This 25pF value can be calculated from the formula below the Table 30. in the PCF8563 datasheet.  Where CL is the target load capacitance, in your case 12.5pF.  Cosco is the known internal capacitance, the 25pF.  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.  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 你好， 遗憾的是，相关文档和使用示例仍在开发中。我希望它能尽快对外发布，但不知道具体日期。