KW47ナレッジハブ KW47 ファミリでは、96 MHz Arm® Cortex®-M33コアをBluetooth LEサブシステムとカップリングしています。この無線サブシステムは独立しており、コアやメモリも専用で、メインCPUの負荷を軽減するので、プライマリ・アプリケーションの分が保持され。また、ファームウェア・アップデートによる将来のワイヤレス標準のサポートも可能です。EdgeLock® Secure Enclave Core Profileを統合した高度なセキュリティのKW47は、NXPのEdgeLock 2GOクラウド・サービスによるサポートで認証情報の共有にも対応します。 KW47ファミリにはBluetoothのチャネル・サウンディング機能が搭載されており、オンチップの専用Localization Compute Engineで測距遅延を短縮します。アプリケーション固有のコード、コネクティビティ・スタック、OTA（Over-The-Air）ファームウェア・アップデートをサポートするための追加メモリも搭載されています。これにより、無線のリアルタイム動作がアプリケーションとは別のコアで実行されるため、信頼性の高いワイヤレス性能が得られます。 オートモーティブ・ソリューションを提供してきたNXPの豊富な経験に基づくKW47ファミリは、-40°C～125°Cの幅広い動作温度範囲と、車載アプリケーション向けペリフェラルを備えるほか、KW47は、長期使用をサポートするNXPの15年間の長期製品供給プログラムの対象ともなっています。 KW47シリーズは、MCUXpresso開発者エクスペリエンスによってサポートされ、組込みシステム開発の最適化、簡素化、迅速化に役立ちます。 KW47は製造開始前ですが、開発者はピンやソフトウェアの互換性があるKW45なら今すぐ使用を開始できます。   joseAntonio_ruiz_0-1739544574098.png   joseAntonio_ruiz_1-1739544610236.png   早期アクセスプログラム KW47早期アクセスプログラムはこちらKW47 Early Accessから参加できます。 アクセスのリクエストはNXPセールスチームまでご連絡ください。   チャネル・サウンディング チャネル・サウンディングご紹介プレゼンテーション CCC CS消費電力計算ツールあり（Excelファイル添付）   Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   トレーニング Bluetooth Low Energy 6.0 NXPご紹介 RFスイッチの比較 吸収型と反射型 規格の比較 ETSI/FCC/ARIB要件 BLEチャネルサウンディング - 概要 BLEチャネル・サウンディング - RFハードウェア BLEチャネル・サウンディング - ANSYSモデリング・ツール BLEチャネル・サウンディング - アンテナのプロトタイプの検証測定 機器 ワイヤレス機器：この記事には、プロジェクト策定に役立つ機器へのリンクが掲載されています。 便利なリンク リファレンスデザイン - NXP Community KW45/KW47/MCXW71/MCXW72でのSignal Frequency Analyzer（SFA）モジュールを使用したクロック測定 - NXPコミュニティ：このコミュニティでは、Signal Frequency Analyzerの使用方法に関する手順を提示しています。 ［MCUXSDK］KW4x、MCXW7x、MCXW2xにGitHub SDKを使用する方法 - NXPコミュニティ GitHub SDKの使用方法をステップ別に紹介しています。 ［MCUXSDK］GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティ BLEプラットフォーム用ドキュメントを提供しています。  KW47（オートモーティブ）またはMCXW712（IIoT）を使用してPCBを初めて正しく構築するための最適な方法 - コミュニティ：このコミュニティには、KW45またはK32W148/MCXW71を使用してPCBを構築するための重要なリンクと、無線性能、低電力、無線認証（CE/FCC/ICC）に関するあらゆる情報があります。 HCI_bbをKinetisファミリ製品で使用してDTMモードにアクセスする方法：この記事は次の2つの部分に分かれています。 HCI_bbバイナリを Kinetis製品へフラッシュする方法。 R&S CMW270を使用してRF測定を行う BLE HCIアプリケーションによるトランスミッタ/レシーバテストコマンドの設定：この記事では、ユーザーはどのようにすればシリアルコマンドをデバイスに送信できるかを示す手順を説明します。 Bluetooth LE HCI Black Boxクイックスタートガイド：この記事では、ユーザーが無線をシリアルコマンドで制御できるようにするためのシンプルなプロセスを説明します。 Kinetis（K32/38/KW45およびK32W1/MCXW71）パワー・プロファイル・ツール：Kinetis（KW35/KW38/KW45）およびMCX W7x（MCX W71）パワー・プロファイル・ツールに的を絞ったページです。お使いのアプリケーション（自動車またはIoT）での電力消費量を試算したり、ソリューションのバッテリ寿命を評価したりするのに役立ちます。  

PN7642 RF 设计导入使用技巧和窍门 先决条件： PN7642 设计导入建议   1// 阻抗调谐 PN76系列天线设计指南 目标阻抗是根据目标应用来选择的。如果需要全功率（如 POS 终端）。建议目标阻抗为15-17 Ω 。 对于使用ULPCD的低功率应用，通常偏好较高阻抗，30-50 Ω（对称调谐）。   2// 动态功率控制 PN7642 - 使用 DPC 进行基本射频功率限制   3// H场检查 存在规定的极限值，尤其是读取器辐射的最大 H 场。超过这些限制可能会导致 NFC 卡或 NFC 标签损坏。 可以借助测试设备测量 H 场，例如： ISO 10373-6测试PICC EMVCo 3.0 测试 PICC 仅供参考，客户可使用如下所示的“智能”场强度探头：   Tomas_Parizek_0-1764148815270.jpeg   4// 高频衰减器值 请开启 RF 场，并确保 DPC 已在上一步设置并启用 请读取 CLIF_RXCTRL_STATUS 寄存器，并查看 HF_ATT_VAL，如下所示。 Tomas_Parizek_1-1764147827990.png 满功率下“无载”状态的值应约为 35-45dec。 如果该值超出此范围，客户需调整 Rx 电阻以达到目标值。 5// 接收器设置 使用 NXP 提供的默认设置，检查“功率”范围和通信范围。 功率范围 -> NFC 标签仍能生成响应信号，但 NFC 读卡器无法接收到它的距离。 通信范围 -> NFC 标签仍能与 NFC 读卡器通信的距离 理想情况下，功率范围 ≈ 通信范围 此外，NFC 读卡器不应产生任何错误通信，例如 “HAL COLLISION ERROR”。 接收机的优化可以通过以下方式进行： 进入 DPC 校准 进入 “ARC” 菜单，选择“禁用”ARC 算法。 Tomas_Parizek_0-1764153827503.png 这将强制IC使用以下寄存器/EEPROM中的RX设置 SIGPRO_RM_TECH_REG DGRM_RSSI_REG   5.1// SIGPRO_RM_TECH_REG（RM_MF_GAIN 参数） 该参数主要用于定义输入放大器的增益。 选择 SIGPRO_RM_TECH_REG 将“操作”切换至 EEPROM，并选择所需的技术。 将 RM_MF_GAIN 增加至 0x021（具体数值视设置而定）。   Tomas_Parizek_0-1764154133976.png   5.2// DGRM_RSSI_REG（DGRM_SIGNAL_DETECT_TH_OVR_VAL 参数） 该参数定义了内部逻辑开始解码输入信号的阈值。 如果阈值过低或非常接近噪声底，系统可能会将噪声检测为NFC通信。 因此，阈值 + 裕量 > 噪声底限 最佳做法是执行“信号检测阈值”分析。此操作可借助 NFC Cockpit 实现（详见 PN7642 设计导入建议） 因此，用户可以根据插入的"边界值"，获得"噪声"的平均值，并建议的"DGRM_SIGNAL_DETECT_TH_OVR_VAL"门限。 标记 (m) + 噪声平均值 (μ) = 阈值 6+16=23 然后，将该数值按如下方式写入 “DGRM_RSSI_REG” EEPROM。   Tomas_Parizek_0-1764155707250.png 6// ULPCD 设置 默认值通常是很好的起点。在第一阶段，用户需要注意 RSSI 阈值和 ULPCD VDDPA。 ULPCD VDDPA 的选择应确保高频衰减器值不为0x00！ULPCD 中高频衰减器的典型值约为0x05-0x0B。   6.1// RSSI阈值评估 为了正确选择 RSSI 阈值，建议执行 ULPCD 校准，例如 20 次，并检查设备的 RSSI 信号的“抖动”情况。 Tomas_Parizek_0-1764168768113.png 如果您发现 RSSI 值出现抖动，例如如上所示抖动5 个单位。这种情况下的绝对最小阈值为6 。一般来说， 2个单位的裕量就足够了。因此，在这种情况下，最佳阈值为7 。

MX95 on DT8MCustomBoard MIPI-DSI out Hi, I have a MX95 on DT8MCustomBoard and custom LVDS connected in dual channel mode to LVDS connectors on board. Display is working nicely and all the other peripherals. Now I want to get an external HDMI display connected and thought I would use MIPI-HDMI converter on DT8MCustomBoards's J11 (MIPI-CSI) connector. Then I would just route video from in to midi_dsi and it would eventually be routed out of J11 connecter on onwards to the MIPI-HDMI bridge. Bridge is adv7535 based thus readily supported by the kernel. However, I'm seeing following in kernel logs: root@imx95-var-dart:~# dmesg|grep mipi [ 0.482259] platform 4ad30000.csi: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@42530000/ov5640_mipi0@3c [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so clearly there is an issue in display_pixel_link <-> mipi_dsi connection. Has anyone here succesfully demonstrated MIPI-DSI on MX95 + DT8MCustomBoard v3.0 combo? I'd like to see device tree samples as the ones provided in kernel tree are not directly meant for DT8MCustomBoard but to some other EVK. How should I map dpu ports to further in chain if they need customization, any fixed clocks to set etc. So are there some pins to pull down, up or anything? As DSI is muxed with CSI then does CSI need explicit disabling or is it enough to enable mipi_dsi in device tree? Thanks for any pointers and cheers from Finland. Re: MX95 on DT8MCustomBoard MIPI-DSI out Based on our analysis of the kernel code there are exactly two output ports on i.MX 95 and if dual channel LVDS is used, in a mode where even and off pixel rows are routed to different channels, then LVDS reserves both of the ports and MIPI-DSI cannot possibly work. However, datasheets state that i.MX 95 can handle up to three independent displays. What does this mean? Based on our tests we can run one single channel LVDS and MIPI-DSI which makes up two displays or we can run one dual channel LVDS only which kind of makes two displays. So what is the configuration where i.MX 95 can have three independent displays? What ports and connectors should be used? Does dual channel LVDS count as two displays already? Re: MX95 on DT8MCustomBoard MIPI-DSI out Ok, it is now evident (based on the kernel source code) that i.MX 95 SoC has two, and only two, independent output ports in its display processing unit. Dual channel LVDS needs both of these leaving MIPI path disconnected. This means that dual channel LVDS + MIPI-HDMI is not possible on i.MX 95. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, an update. I've managed to get MIPI-DSI working so video is routed on MIDI-DSI bus, out from J11 connector on DT8MCustomBoard, over to ADV7535 bridge and in to external HDMI display. However, I'm not able to enable internal LVDS display at the same time with MIPI-DSI. If I enable LVDS display, the ldb node in device tree, it seems to hijack video stream so that it displays on LVDS but not on external display. When this happens I get errors in kernel log stating that imx95-mipi-dsi could not get valid input. I can get either internal LVDS enabled or external HDMI over MIPI-DSI but not both at the same time. This must be something with the device tree but the endpoints I'm using are the ones provided in kernel tree. Device. tree I'm using is imx95 + adv7535 additions with mipi and hdmi nodes. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, Did you try to use only MIPI-DSI out? It can handle up to 3 simultaneous displays: 1x 350 MHz MIPI-DSI (4-lane, 2.5 Gbps/lane) supporting 4kp30 or 3840 x 1440p60. Up to 1080p60 LVDS Tx (2x 4-lane or 1x 8-lane). 16 kByte of SRAM, but it is available for other SoC usage when not using for 2D blitter purposes. Best regards. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, and thanks for the quick reply. It seems that just enabling mipi_dsi in device tree leads to [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so I was wondering is it possible to enable MIPI-DSI functionality and at the same time run LVDS in dual channel mode? mipi_dsi inputs are connected exactly as in device tree samples. What we have here is a custom LVDS panel that needs dual channel (lvds-0 and lvds-1) input and at the same time we want to have external display on MIPI-DSI. So LVDS panel would show desktop 1 and MIPI-DSI, via adv7535 converter, would show desktop 2. Or is it so that MX95 is only capable of one channel LVDS if MIPI-DSI is used at the same time? I've looked all the possible .dts samples in the kernel tree, read documentation and it is not clear to me is dual channel LVDS and MIPI-DSI possible at the same time. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, You can use our EVK as reference: linux-imx/arch/arm64/boot/dts/freescale/imx95-19x19-evk-adv7535.dtso at dfaf2136deb2af2e60b994421281ba42f1c087e0 · nxp-imx/linux-imx Best regards.

S32 Design Studio での S32K344 SDK のインストール 「S32 Design Studio に S32K344 SDK をインストールしましたが、S32DS アプリケーション プロジェクトを作成するときに SDK を選択できません。なぜ？" Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 @DirkEtzler さんは正しいです。 例えばS3K3 RTD 7.0.0 は、NXP GCC 10.2.0 20200723 を使用して開発およびテストされています (SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf の第 2.7 章に記載されているとおり)。したがって、GCC10.2を使用する必要があります。 よろしくお願いいたします、 パベル Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 どのようなツールチェーンを使用していますか?「NXP GCC 10.2 for Arm 32-bit Bare Metal」を選択した場合、SDK が表示されます (下記参照)。ツール チェーンとして「NXP GCC 11.4 for Arm 32 ビット ベア メタル」を選択した場合、SDK は表示されません。 DirkEtzler_0-1770640150586.png DirkEtzler_1-1770640164331.png

S32K5 RTD configuration does not allow to set initial value in some pins Hello, Some pins as the ones listed below don't allow to set the initial value when being configured. Is there a reason for that? Regards RTD Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi @nxp52415, As I said, with pins that you selected, they are not supported this function. So, the "the initial value" is not necessary for these pins. Default, RTD driver disabled "the initial value" on "pins were not supported RCVR", and these pins will be generated "the initial value" as 0. Even when driver allow user configures RCVR for these pins, then it doesn't have any effection because it has not support RCVR. Best regards, Dan Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi Dan, I was talking about the initial value and not the RCVR. Can you explain why the initial value cannot be set in these pins? Regards  Re: S32K5 RTD configuration does not allow to set initial value in some pins Hi @nxp52415, This is the information about "Receiver Select" bit in S32K5 RM: You can find the pins support the RCVR in the "IO Signal Table" sheet in the S32K56x_IOMUX.xlsx (attached file in S32K5RM). And based on this files, pins that you showed as not support RCVR. Best regards, Dan

KW47 Knowledge Hub KW47 family features a 96 MHz Arm® Cortex®-M33 core coupled with a Bluetooth LE subsystem. The independent radio subsystem, with a dedicated core and memory, offloads the main CPU, preserving it for the primary application and allowing firmware updates to support future wireless standards. The KW47 also offers advanced security with an integrated EdgeLock® Secure Enclave Core Profile and will be supported by NXP's EdgeLock 2GO cloud services for credential sharing. The KW47 family includes Bluetooth Channel Sounding capabilities, with a dedicated on-chip Localization Compute Engine to reduce ranging latency. It incorporates additional memory to support application-specific code, connectivity stacks and over-the-air firmware updates. This delivers reliable wireless performance, as the real-time activities of the radio run on a separate core from the application. Building on NXP's strong history of providing automotive solutions, the KW47 family offers a wide operating temperature range from -40 °C to 125 °C and peripherals for automotive applications, KW47 will be part of NXP's 15-year Product Longevity program to support long-term use. The KW47 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. Slide1.JPGSlide1.JPG  KW47 boards KW47-EVK Getting Started with the KW47 EVK KW47-EVK Board User Manual KW47-M2 Board User Manual  KW47-EVK Quick Start Guide KW47-M2 Quick Start Guide   KW47-LOC Getting Started with the KW47-LOC KW47-LOC Board User Manual KW47-LOC Quick Start Guide KW47: Bluetooth Channel Sounding MCU with On-Chip Localization Compute Engine the KW47 Security Certifications  PSA Certified Level 2 SESIP Level 2 Security Target  SESIP Level 2 KW47/MCXW72 SESIP certificate and ST are on TrustCB website  Regulatory Certifications European Union Declaration of Conformity - KW47-EVK MIC Radio Certificate - KW47-EVK European Union Declaration of Conformity - KW47-LOC MIC Radio Certificate - KW47-LOC  Bluetooth Qualifications Qualified Products | Bluetooth® Technology Website Q360996: KW47 / MCX W72 Bluetooth LE 6.0 (Channel Sounding) Controller Q332147: KW47 / MCX W72 Bluetooth LE 6.0 (Channel Sounding) Host Documents  KW47 Product Family Data Sheet KW47 Reference Manual Errata for KW47 KW47 Hardware Design Guide Bluetooth Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology, like NXP! 2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview Application Notes Software, Hardware and Peripherals: AN14884 32kHz Cristal-less mode on KW47: This application note provides information on the 32 kHz Crystal-less mode on the KW47 device. This mode allows you to reduce the cost of the system, without compromising the 32 kHz clock accuracy.  AN14846 Boosting Application Performance with the KW47 Dual-Core Architecture: This application note describes how to use the dual-core architecture in the KW47 microcontroller to improve performance in generic embedded applications AN14796 Migration Guide from the KW45 to the KW47:  This document describes the procedure to migrate from KW45B41Z to KW47 with emphasis on the connectivity software. The document is intended for software engineers, software testers, software integrators, and customers designing their own hardware. Power Management: AN14709 Power Management Hardware for the KW47: This application note describes the usage of the different modules dedicated to power management in the KW47microcontroller. TheKW47integrates a DC-DC buck converter, a couple of low-dropout regulators, and a programmable solid-state switch to turn on/off theKW47power domains AN14684 Features, Usage, and Capabilities of Smart Power Switch on the KW47 Microcontroller: This application note describes the use of the smart power switch in the KW47 microcontroller. The KW47 integrates a programmable solid-state switch that turns connected components on or off, including KW47 power domains AN14664 Coincell Hardware Recommendations for Kinetis BLE Applications: his document describes some hardware and software solutions to minimize the peaks of current at the coin cell level AN14554 KW47 Bluetooth Low Energy Power Consumption Analysis:  This document provides the power consumption analysis of the Kinetis KW47 (automotive) wireless MCU using the KW47-EVK board RF: AN14719 Integrating the OTAP Client Service into a KW47 BLE Peripheral Device: This application note outlines the use of the NXP Over the Air Programming (OTAP) custom Bluetooth Low Energy (Bluetooth LE) service to upgrade software on a Microcontroller Unit (MCU) without using physical cables. AN14940 KW47 Coexistence with RF System Evaluation Report for the Bluetooth LE Applications: This document provides the coexistence RF evaluation test results of the KW47-EVK for Bluetooth LE applications (2FSK modulation). It includes the test setup description and the tools used to perform the tests on your own. For the KW47 radio parameters AN14461 KW47-EVK RF System Evaluation Report for Bluetooth LE Applications: This document provides the RF evaluation test results of the KW47-EVK board for Bluetooth LE (2FSK modulation) applications. It includes the test setup description and the tools used to perform the tests. AN14826 KW47-LOC System Evaluation Report for BLE Applications: This document provides the RF evaluation test results of the KW47 Localization board (KW47-LOC) for Bluetooth LE (2FSK modulation) applications. It includes the test setup description, and the tools used to perform the tests on your own. AN14696 Loadpull Test Report for KW47: This document explains the purpose of measuring the supply current, the transmit power, and the harmonics level. These measurements are monitored while the complex output load seen by the device under test (DUT) is tuned in amplitude and phase. AN14628 KW47 CCC Channel Sounding Power Profile Analysis:  this document explains power consumption measurement at each step of the full distance measurement procedure, changing of the code to set the different option in the SDK software, and usage of the associated power profile estimator tool. AN14865 Channel Sounding Fundamentals for the KW47 and MCX W72: This document provides an overview of the fundamentals for CS technology and how it can be used for custom solutions and applications. AN14832 Fundamental Steps to Design a Channel Sounding Board - Creating a Simple PCB without Diversity: In this document, an example of a minimalistic CS subsystem is presented. Attention is paid to the Radio-Frequency (RF) path, since RF circuitry strongly influences the properties of the whole CS application. AN14779 Printed Channel Sounding Antennas for the KW47 and MCX W72: his application note is focused on printed antennas implemented on printed-circuit boards (PCB), designed by NXP for the KW47 and MCX W72 controllers AN14720 Creation of Firmware Update Image for KW47 using Over the Air Programming Tool: This document outlines the steps to create and upgrade the image on the KW47–EVK board AN14868 RF Modeling of Channel Sounding in ANSYS: focuses on techniques for simulating and analyzing channel sounding in wireless communication systems using ANSYS tools AN14855 Channel Sounding Tests in Different Environments: This application note is about Bluetooth Channel Sounding (CS), a technique for measuring the distance between two devices in the Bluetooth frequency band. It explains key factors affecting accuracy AN14869 Fundamental Steps to Design a Complex Channel Sounding Board:  It focuses on creating hardware that supports advanced CS features, including antenna diversity and optimized RF paths, to improve accuracy and mitigate issues like multipath propagation. AN2731 Compact Planar Antennas for 2.4 GHz Communication: This document is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays Security: AN14727 KW47 Flash Encryption using NPX: There is an increasing requirement to protect the application code and data stored in flash memories in an encrypted form due to security reasons. The NVM PRINCE XEX (NPX) is a module inside the Flash Memory Controller (FMC) that allows customers to protect the contents of flash regions (up to four regions). It performs on-the-fly, low-latency encryption and decryption of flash contents, and it is transparent to the developer and to the Cortex-M33 platform. No special handle is needed from the perspective of the developer. AN14607 KW47 Secure Boot using SEC tool: The KW47 is a low-power, highly secure, single-chip wireless MCU, the contents of flash memory can be saved as encrypted data, which can be decrypted instantly. It helps in protecting the sensitive data and algorithms. AN14647 KW47-LOC In-System Programming Utility: The document provides steps to boot the KW47 MCU in ISP mode and establish various serial connections to communicate with the MCU AN14653 Debug Authentication on KW47: This application note describes the steps for debug authentication using the MCUXpresso Secure Provisioning Tool (SEC). AN14649 KW47-EVK In-System Programming Utility: This document provides steps to boot the KW47 MCU into ISP mode and establish various serial connections to communicate with the MCU. AN14643 KW47 Managing Lifecycles: This document describes the following: Lifecycle stages that are available to the user, how to access the lifecycles, limitations of the lifecycles, how to transition to the next lifecycle Training Bluetooth Low energy 6.0 NXP Introduction KW4x: Automotive Bluetooth Low Energy MCUs for Secure Car Access RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Useful Links How to run KW47-M2 standalone - NXP Community How to generate a Standalone IAR toolchain project from MCUXSDK application example - KWX/MCWX  Debug probe firmware installation for the KW47-EVK and FRDM-MCXW72 This post will cover how to install the CMSIS-DAP/SEGGER J-link firmware for the KW47-EVK and FRDM-MCXW72 using NXP’s MCU-LINK installer. Updating NBU for Wireless Examples on KW47/MCXW72This post will cover how to update the NBU firmware How to import and run demo examples with MCUXpresso for Visual Studio Code: This article gives information on how to import and run demo examples from the new SDK with ARM GCC toolchain, in MCUXpresso for Visual Studio Code. [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial) - NXP Community : In this community provides the important link to build a PCB using a KW47 and MCX W72 and all concerning the radio performances, low power and radio certification (CE/FCC/ICC). Workaround implementation for DCDC failure during drive strength change a DCDC failure can occur infrequently during a drive strength change to low, and the DCDC output voltage becomes greater than or equal to the current output voltage. How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide : This article describes a simple process for enabling the user controls the radio through serial commands. Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization):  This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47/KW43) and MCX W7x (MCX W71/W72/W70) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery lifetime of your solution. KW47/MCXW72 32MHz & 32kHz Oscillation margins: this article provides the properly configuration for the Oscillation margins for the circuit. Changing CAN interface configuration on KW47-EVK while using serial terminal:Most available example applications use UART as the serial interface for terminal communication. This approach is commonly chosen because a terminal provides a simple and efficient method for interacting with the application during development and debugging. Errata ERR053377: Use Cases for Different Message Buffer ConfigurationsThis article discusses the different use cases and configuration of the errata "ERR053377: FlexCAN: Message Buffer (MB) and Enhanced RX FIFO Filter Element (ERFFEL) Memory Corruption" Reference Designs Bluetooth Ranging Access Vehicle Enablement System - NXP Community Blue Ravens (Bluetooth Ranging Access Vehicle Enablement System) is a system solution developed by NXP to assist customers in designing their own BLE-based car access solutions using NXP products. Videos NXP Channel Sounding technology interfacing with Google Pixel 10 This is a demo showing the MCX W72 LOC board interacting with Google Pixel 10 phone using channel sounding

S32K144 CSEc 安全启动-设备处于安全状态，无法解除安全保护 硬件 ：S32K144 开发板 IDE ：S32 设计工作室 编程 ：直接通过 S32DS 问题描述： 我通过以下步骤成功在 S32K144 上实现了 cSec 安全启动： 配置密钥 -安装 MASTER_ECU_KEY 和 BOOT_MAC_KEY 闪存区域中的闪存应用程序 - 通过 S32DS 使用 Debug_FLASH 配置 设置安全启动 -通过 S32DS 使用 DEBUG_RAM 配置来存储 BOOT_MAC 重置后 -安全启动工作正常 应用程序工作 - 通过 LED 指示灯确认，BOK=1 问题： 在测试否定情况（失败情景）时： 尝试在闪存区域刷新不同的应用程序 → " 设备是安全的。擦除到不安全？"出现对话框 点击"是" 删除 → 同一对话框不断重复出现 尝试恢复出厂设置 → 还是同样的错误 无法闪存任何新应用程序 问题 点击"Yes" 是否应该自动执行批量删除？ 为什么对话框总是重复出现？ 如何仅使用 S32DS 正确解除设备的安全？正确的程序是什么？ 可以在 S32DS 中使用大量擦除命令吗？ 如果是，具体程序是什么？ 设备永久锁定了吗？或者有通过 S32DS 恢复的方法吗？ 当前状态： 设备似乎处于安全状态。无法使用 S32DS 闪存任何应用程序。需要逐步恢复程序才能解除设备的安全。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 答： 使用 来自 an5401SW 的 s32k144_csec_secure_boot_boot_boot_mac_mac_mac_mac_mac_mac_manual 示例，我们在 BOOT_DEFINE () 函数中将串行安全启动配置为 启动模式。如果启动模式 1 对应 于严格的顺序启动模式 ，这将解释我们遇到的永久 RESET 行为。 " /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE(128*1024*8,1)； " 你检查过RESET信号了吗？它是在开机后版本吗？ 答：是的，我已经检查了 RESET 信号。开机后 RESET 信号保持活动状态（RESET LED 保持亮起），表明设备仍处于 RESET 状态 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： Kishore_14_0-1764067663149.png 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 答： 尝试刷新 an5401_s32K144_csec_resetting_flash_to_flash_to_factory_State 时 ，我收到 " 设备是安全的。擦除到不安全？" 对话框。即使在单击 " 是 " 之后，同样的对话框仍会重复出现 S32DS 有 " 通过全芯片擦除进行紧急 Kinetis 设备恢复 " 选项。我们应该用它来恢复设备吗？ Kishore_14_2-1764069429876.png 注： 我们没有设置闪存和擦除的调试器。我们使用 S32DS 进行闪存和调试。因此，需要在大规模擦除方面得到帮助。   Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好@Kishore_14 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 你检查过RESET信号了吗？它是在开机后版本吗？ 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： lukaszadrapa_0-1764055246465.png 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 此致， Lukas Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 当 Boot Flavor 参数设置为 0 时，将配置严格的顺序启动模式： image.png 但是，如果你保留原来的顺序启动，那就没有意义了： /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE (128*1024*8, 1); 即使顺序启动失败，也绝对不会导致永久RESET。您是用示波器检查信号，还是只观察 LED 指示灯？RESET信号不是在切换吗？ 如果永久断言重置信号，恐怕就无法恢复。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 直接观察，LED 并非切换，而是常亮。 如果是顺序启动模式，刷新应用程序时设备持续处于 RESET 状态的可能性有多大？ 当示例中的所有 Flashconfig 设置如下所示时，设备将如何获得安全保护： /* 闪存配置 */ .section.FlashConfig,"a" .long0xFFFFFFFF /* 8 字节后门比较密钥 */ .long 0xFFFFFFFF /* */ .long0xFFFFFFFF /* 4 字节程序闪存保护字节 */ .long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = 无担保) */ 由于无法使用直接调试器闪存，我能否尝试使用 Kinetis 选项进行大量擦除？ 注意：我们还在另一块板上也观察到了这种情况，并发布在下面的链接中： 错误：设备是安全的。擦除到不安全-恩智浦社区 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 切换 RESET 引脚可能非常快，以至于肉眼可能看不见。所以我才问你是否用示波器试过。 我只能看到永久RESET的两个原因： 1.严格的顺序启动模式失败。 2。硬件问题-通常电压不足，因此电压监测器不允许启动设备... 无法通过（错误的）应用程序强制设备永久RESET。这只能通过某种自毁方式来实现，例如将GPIO设置为短路或类似的方式。 消息 " 设备是安全的。" 。大多数情况下，这通常意味着调试器无法建立连接。在这种情况下，即使设备处于安全状态，也无法对其进行解除保护，因为启用的 CSec 模块会阻止大规模擦除操作。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好， 切换 RESET 引脚可能太快了以至于肉眼可能看不见。所以我才问你是否用示波器试过。 你检查过RESET信号了吗？它是在开机后版本吗？ 答：我们观察到 RESET 引脚正在切换。 Kishore_14_2-1764229793234.png 这是否意味着先前闪存的应用程序在任何 SW /WDG RESET 中都卡住了？ 能否通过 SWD 调试器闪烁恢复？     Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 遗憾的是，我们没有用于闪存的 JLink 或 PE Micro。 我们使用 S32DS OpenSDA 进行调试。 下面是 AN12130 中提到的 在启动程序分区命令 (PGMPART) 时，请务必将 CSEc 键的大小分配为不同于零的值。 - 编程 CSEc 键，至少是 MASTER_ECU_KEY。 - 通过发出 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除密钥。CMD_DBG_AUTH 命令将擦除 数据 IFR，从而擦除分区代码并允许再次进行大规模擦除。 如果任何 CSec 密钥受到 “写保护”，则上述步骤将不起作用，因此无法用上市大规模擦除。 问题：当我们闪存不同的应用程序时，第一次尝试就闪存成功了。 由于没有遵循上述顺序，下次 RESET 时，新应用程序可能会进入连续 RESET 状态吗？这样做对吗？ Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您有读取 MDM-AP 的 Segger J-Link 探头或劳特巴赫调试器吗？遗憾的是，Pemicro 无法做到这一点。 在极少数情况下，设备可以被锁定。请查看此主题： https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227 要确认这一点，有必要阅读 MDM-AP。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure OpenSDA 也来自 Pemicro。 通常情况下，即使启用了 CSEc，即使某些键受写保护等，也可以通过 OpenSDA 对新应用程序进行编程。这是因为它是逐块擦除闪存，而不是通过大规模擦除。我的意思是，AN12130 谈到了这样的问题： lukaszadrapa_0-1764582832674.png lukaszadrapa_1-1764582841459.png 因此，当编程过程中出现问题时（意外RESET或类似的情况），这些都是相当大的问题。 遗憾的是，确认这种状态的唯一方法是读取提及的 MDM_AP 寄存器。然后我们可以说出设备是否被永久锁定。但 OpenSDA 无法读取寄存器。 此致， Lukas

Ara240 Run Time Environment (rt-sdk-ara2) The Runtime SDK for AI/ML acceleration using the Ara240 NPU on NXP i.MX SoCs, provides the runtime environment for the Ara‑2 NPU.   Main Purpose of the Package    1. Provide the runtime environment for the Ara‑2 NPU This runtime sdk package installs everything needed for an i.MX system to communicate with and utilize the Ara240 NPU hardware, including: NPU drivers  Low‑level utilities (metrics, hardware bring‑up, flash tools) Proxy services that interface applications with the NPU Firmware loaders and NPU configuration files 2. Allow users to run AI/ML inference models on the NPU The Ara240 runtime environment includes tools for: Downloading pre‑compiled AI/ML models Running performance tests on the NPU Running classification, detection, pose, and segmentation models Inspecting HW IPS (inference/second) and real hardware performance   Scripts such as: fetch_models.sh ara_metrics.sh chip_info.sh program_flash.sh run_models_perf.sh 3. Automatically configure and optimize the i.MX system Installation does the following automatically: Expands system partition to handle large models (LLMs/VLMs) Sets up an 8GB SWAP for devices with limited RAM Prepares the runtime environment for AI workloads 4. Manage and update Ara‑2 firmware The package contains scripts to: Check the installed firmware version ( chip_info.sh ) Update firmware if needed ( program_flash.sh ) 5. Provide systemd service for automatic startup The SDK installs: A systemd service: rt‑sdk‑ara2.service   Walkthrough Video Below is the walkthrough video for this package (function() { var wrapper = document.getElementById('lia-vid-6396594498112w960h540r402'); 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) ARA2-M2-16G-GT ARA240 Hands-On Training

Motor synchronous control demonstration using EtherCAT with i.MX RT1180 (Japanese blog) We will demonstrate an integrated EtherCAT and motor control system, and introduce the high-performance microcontroller i.MX RT1180 that makes this possible. This demonstration showcases the synchronization capabilities of EtherCAT and the high-precision motor control that accompanies it. Motor synchronous control demonstration using EtherCAT Explanation of how the demo works EtherCAT_MotorControl_1.png The board configuration consists of three boards: one EtherCAT master board and two EtherCAT slave boards, which together achieve EtherCAT synchronization. The slave boards are equipped with motor drivers, and each slave board controls two motors, for a total of four motors. The two motors at each end are controlled by slave board 1 and slave board 2 respectively, which adjust the left-right position of the two motors in the center. The two motors in the center are also controlled by slave board 1 and slave board 2 respectively, and are responsible for meshing the gears together . Initially, the two central motors rotate synchronously with their gears meshed together, and then gradually separate to disengage. After the deactivation, the two central motors rotate at different speeds and approach each other again. The moment the gears mesh again, the two motors rapidly synchronize, achieving precise gear engagement. At the same time, the motors on both sides adjust the position of the two central motors to prevent them from colliding. After that, the separation, approach, and interlocking process is repeated. Now, let me explain why such advanced control is possible with the RT1180 microcontroller. i.MX RT1180 behavior EtherCAT_MotorControl_2.png First, within the i.MX RT1180 microcontroller, each core has a specific role. The M33 core (300MHz) is responsible for EtherCAT communication, and the M7 core (800MHz) is responsible for motor control. The M33 core runs on an EtherCAT stack, achieving faster read/write speeds, lower costs, energy efficiency, and higher communication and response speeds compared to external devices. The M7 core performs motor calculations (PWM) within 1.4 μs. This completes the update + ADC sample + closed loop vector control. The dual-core cooperative operation of the M33 and M7 ensures superior point control performance and guarantees the operation of high-performance motors. Furthermore, the generous 1.5MB of RAM memory improves work efficiency and leaves room for further customization by the user. EtherCAT_MotorControl_3.jpg   summary Based on these points, we believe the i.MX RT1180 is an optimal choice for those considering servo applications. The source code for this demo is available on NXP's Application Code Hub. Please see the link below for details. How to set up the motion control reference design on iMX.RT1180 =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) We will demonstrate an integrated EtherCAT and motor control system, and introduce the high-performance microcontroller i.MX RT1180 that makes this possible. This demonstration showcases the synchronization capabilities of EtherCAT and the high-precision motor control that accompanies it. (Reading time: 10 minutes) i.MX RT Processors MCUXpresso Motor Control Technology Focus Japanese Blog

S32DS v3.6.6 S32K5 development package missing pins in package view for S32K566_437BGA In the S32DS Configuration Tool for the Pins, the S32K566_437BGA view is missing a number of pins in the package view. DirkEtzler_1-1771116409587.png Is this my installation or a general issue?  Is there a plan to fix that? Re: S32DS v3.6.6 S32K5 development package missing pins in package view for S32K566_437BGA Hello @DirkEtzler , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, they will not be equipped to provide the desired assistance. We appreciate your understanding in this matter and look forward to further enhance our partnership with you. Should you have any questions, please feel free to connect with your field engineer, or contact my team and me directly. Thank you for your understanding. Best regards, Pavel

MPX4115AP 端口 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MPX4115 系列的数据表将MPX4115AP 列为"端口元件"。谁能帮我弄明白这意味着什么，端口的具体用途是什么。 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 非常感谢您！ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 零件号中的字母 “A” 表示 “绝对”，因此施加在 P1 上的压力是根据密封在 P2 侧的真空参考测量的： 我们的压差传感器可通过部件编号中的字母 "D "来识别（例如MPX5100DP）和两个输入端口： 请仔细阅读这篇文章，以便更好地了解恩智浦压力传感器的压力测量和集成水平。 顺祝商祺！ 托马斯 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，托马斯、 非常感谢你的答复。再澄清一点。与软管/导管连接的接口是否意味着传感器可以用作差分传感器？ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 移植版本（带有 AP、AS 或 ASX 后缀）允许通过软管/管道连接将压力连接到设备。 顺祝商祺！ 托马斯

imx93 m33 rpmsg hello_world 测试 板/设置 CPU：i.mx93 启动媒体：SD (mmc 1) 目标：运行 CM33 RPMSG-Lite 字符串回声演示并从 Linux (A55) 进行通信 问题摘要我也想启动 Cortex-M33 RPMSG 演示： ： 当尝试访问某些 CM33 别名地址（例如0x1ffe0000 / 0x0ffc0000) Linux remoteproc 试图加载 rpmsg_lite_str_echo_rtos_remote.bin，但以错误 -2 失败（未找到文件），然后退回到 sysfs 回退。 我不确定 i.MX93 上的 CM33 的正确内存复制地址和启动地址应该是多少（系统地址与别名地址），以及如何使 U‑Boot boot bootaux 流程与 Linux remoteproc 流程保持一致。 我测试的 SD 分区布局和启动文件 U‑Boot 显示 SD 是 mmc 1： u-boot= > mmc 列表 FSL_SDHC：0 (eMMC) FSL_SDHC：1 (SD) 分区表： u-boot= > 零件清单 mmc 1 MMC 设备 1 的分区图-分区类型：DOS 部件起始扇区号扇区 UUID 类型 1 16384 681574 076c4a2a-01 0c 启动 2 704512 5769534 076c4a2a-02 83 启动分区内容包括 DTB 和 mcore-demos/ 目录： u-boot= > fatls mmc 1:1... mcore-demo/... 我可以加载演示版： u-boot= > fatload mmc 1:1 ${loadaddr} mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 3 毫秒内读取 39004 字节 u-boot= > echo ${loadaddr} 0x80 400000 u-boot= > echo ${filesize} 985c 前两个字看起来像一个有效的 CM33 向量表： u-boot= > md.l ${loadaddr} 2 80400000：2001e000 0ffe0595 读取 0x1ffe0000 会导致中止： Linux 端：remoteproc 固件加载失败 在 Linux 中，remoteproc0 开机后会尝试加载固件： [ 84.714629] remoteproc remoteproc0: powering up imx-rproc [ 84.721926] remoteproc remoteproc0: Direct firmware load for rpmsg_lite_str_echo_rtos_remote.bin failed with error -2 [ 84.732549] remoteproc remoteproc0: Falling back to sysfs fallback for: rpmsg_lite_str_echo_rtos_remote.bin 这里是预留内存： reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reg = <0 0x88000000 0 0x04000000>; /* 64 MB @ 0x8800_0000 */ reusable; linux,cma-default; }; /* Ethos-U: move away from the kernel boot (32 MB) */ ethosu_mem: ethosu_region@8c000000 { compatible = "shared-dma-pool"; reg = <0 0x8c000000 0 0x02000000>; no-map; }; vdev0vring0: vdev0vring0@84000000 { reg = <0 0x84000000 0 0x00008000>; no-map; }; vdev0vring1: vdev0vring1@84008000 { reg = <0 0x84008000 0 0x00008000>; no-map; }; vdev1vring0: vdev1vring0@84010000 { reg = <0 0x84010000 0 0x00008000>; no-map; }; vdev1vring1: vdev1vring1@84018000 { reg = <0 0x84018000 0 0x00008000>; no-map; }; rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x00001000>; no-map; }; /* OCRAM */ vdevbuffer: vdevbuffer@84020000 { compatible = "shared-dma-pool"; reg = <0 0x84020000 0 0x00100000>; /* 1 MB */ no-map; }; ele_reserved: ele-reserved@90000000 { compatible = "shared-dma-pool"; reg = <0 0x90000000 0 0x00100000>; /* 1 MB @ 0x9000_0000 */ no-map; }; }; ethosu { compatible = "arm,ethosu"; fsl,cm33-proc = <&cm33>; memory-region = <&ethosu_mem>; power-domains = <&mlmix>; }; 从 U-Boot 在 i.MX93 上启动 CM33 RPMsg 演示的正确步骤是什么？ 如果 CM33 由 U-Boot (bootaux) 启动，建议的 Linux 配置是什么？ Re: imx93 m33 rpmsg hello_world test 你好，电路板支持包 版本是 VERSION= " 6.6-scarthgap(scarthgap)" 我使用内存为 512MB 的 imx93 自定义板但没有 hello_world .elf 这些都在 /lib/firmware 下 imx93-11x11-evk_m33_TCM_low_power_wakeword.elf imx93-11x11-evk_m33_TCM_power_mode_switch.elf imx93-11x11-evk_m33_TCM_rpmsg_lite_pingpong_rtos_linux_remote.elf imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf imx93-11x11-evk_m33_tcm_sai_low_power_audio.elf 经过测试 u-boot= > fatload mmc 1:1 80000000 mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 在 3 毫秒内读取 39004 字节 (12.4 MiB/s) u-boot= > cp.b 0x80000000 0x201e0000 0x10000 u-boot= > bootaux 0x1ffe0000 0 ## 启动辅助内核 addr = 0x1ffe0000... 它无法启动，它会冻结。 Re: imx93 m33 rpmsg hello_world test 您好， 感谢您对恩智浦半导体产品的关注， 使用预建的 Cortex-M 演示版是一个很好的起点，你使用的是 i.MX 93 EVK 还是带有预建映像的自定义板？ 你在用什么电路板支持包？ 要在 u-boot 中运行 Cortex-M 演示，你可以使用以下代码片段： u-boot=> fatload mmc 1:1 80000000 sdk20-app.bin u-boot=> cp.b 0x80000000 0x201e0000 0x10000 u-boot=> bootaux 0x1ffe0000 0 RPMSG 必须在 Linux RPROC 框架下运行，因为您必须在 DTB 中为 RPMSG 预留内存，而且 Cortex-A RPMSG 通信是通过 Linux 驱动程序进行的。 root@imx93evk:~# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/ firmware root@imx93evk:~# echo start > /sys/class/remoteproc/remoteproc0/state 此致 Re: imx93 m33 rpmsg hello_world test 你好，@bora、 请尝试使用 imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf 这是你正在测试的二进制文件，请参阅 SDK 中的可用示例： SDK_24_12_00_MCIMX93-EVK\板\mcimx93evk\多核_示例 - rpmsg_lite_pingpong_rtos_linux - rpmsg_lite_str_echo_rtos 此致 Re: imx93 m33 rpmsg hello_world test 您好， 我试过了结果就是这样， root @imx93 -11x11-lpddr4x-evk：~# echo start > /sys/class/remoteproc/remoteproc0/state [105.274513] remoteproc remoteproc remoteproc 0/state [105.274513] remoteproc remoteproc remoteproc 0/state [105.274513] remoteproc remoteproc remoteproc 0：启动 imx93-11x11-EVKK _m33_tcm_rpmsg_lite_str_echo_ rtos.elf， size 59028 [ 105.294019] remoteproc remoteproc0: Registered carveout doesn't fit len request [ 105.301405] rproc-virtio: probe of rproc-virtio.1.auto失败，错误 -12 [ 105.309101] remoteproc remoteproc0: 注册的分割不适合 len 请求 [ 105.316561] rproc-virtio: probe of rproc-virtio.2.auto failed with error -12 [ 105.830361] remoteproc remoteproc0: 远程处理器 imx-rproc 现在已启动 Re: imx93 m33 rpmsg hello_world test 您好， 我可以在 LF-6.12.49 EVK 上通过以下步骤重现该功能 Cortex-A U-启动 Hit any key to stop autoboot: 0 u-boot=> fatload mmc 0:1 ${loadaddr} mcore-demos/imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.bin 19816 bytes read in 18 ms (1 MiB/s) u-boot=> cp.b ${loadaddr} 0x201e0000 0x20000 u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... u-boot=> pri mmcargs mmcargs=setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} u-boot=> editenv m mfgtool_args mmcargs mmcautodetect mmcboot mmcdev mmcpart mmcroot u-boot=> editenv mmcargs edit: setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} clk_ignore_unused u-boot=> boot Cortex-A Linux root@imx93evk:~# lsmod | grep -i imx_rpmsg_tty root@imx93evk:~# modprobe imx_rpmsg_tty 从 U-boot 到 Linux 的 Cortex-M RPMSG String Echo FreeRTOS RTOS API Demo... Nameservice sent, ready for incoming messages... Get Message From Master Side : "hello world!" [len : 12] 此致 Re: imx93 m33 rpmsg hello_world test 我也进行了测试，但没有结果，我仍然无法与 m33 通信。我用的是自定义板而不是 imx93-11x11-evk，我用 uart1 没有 uart2，对于 m33 我有 JTAG。 Re: imx93 m33 rpmsg hello_world test 我也没有在 /dev 下看到任何 ttyRPMSG 文件 Re: imx93 m33 rpmsg hello_world test 在 u-boot 上我开始工作了但是在 linux 中是通过 .elf文件，我得到 imx_rproc_kick：失败 (0, err:-62)

ICODE SLIタグはwrite_single_blockコマンドに対して64 01エラーを返します 私は Windows 11 ノートPCと ACS ACR1552 リーダーを使用しています。 ACS スクリプト ツール (v5.02) を使用して、APDU を NXP ICODE SLI タグに送信しています。 透過セッションを作成し、プロトコルを 15693/Layer3 に設定し、透過交換カプセル化を使用して APDU をタグに送信します。 GET_SYSTEM_INFO と READ_SINGLE_BLOCK は正常に動作するようです。 WRITE_SINGLE_BLOCK は「64 01」エラーを返しますが、実際にデータを書き込んでいるように見えます。 この 64 01 応答の意味や原因に関する情報は見つかりませんでした。 誰かこれについて説明できますか? 私が使用している APDU のシーケンスは次のとおりです。 APDU #4はブロック0のデータを11 22 33 44として読み取ります。 APDU #5はブロック0のデータを12 34 56 78に書き込みますが、64 01エラーが発生します。 APDU #6 はブロック 0 のデータを 12 34 56 78 として読み取ります。これは、前の書き込みが実際に機能したことを示しています。 （１）透過的なセッションを確立する < FF C2 00 00 02 81 00 00 > C0 03 00 90 00 90 00 ; （2）透過的な交換 - スイッチプロトコルをSwitchProtocolRf::ISO15693 SwitchProtocolLayer::PART3へ < FF C2 00 02 04 8F 02 02 03 > C0 03 00 90 00 8F 01 00 90 00 ; （3）システム情報を取得する < FF C2 00 01 04 95 02 02 2B 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 0F 00 0F 2E 98 5C 8A 00 01 04 E0 00 00 1B 03 01 90 00 ; （4）セキュリティステータスを含むユーザーブロック0の読み取り < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 00 11 22 33 90 00 （５）ブロック０に１２３４５６７８を書き込む < FF C2 00 01 09 95 07 02 21 00 12 34 56 78 00 > C0 03 01 64 01 90 00 ; （6）セキュリティステータス付きユーザーブロック0の読み取り < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 12 34 56 78 90 00 （７）透過セッションを終了する < FF C2 00 00 02 82 00 00 > C0 03 00 90 00 90 00 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command icode SLIX/SLIX2 タグの読み取り/書き込み時にもまったく同じ問題が発生しました。書き込みは機能していましたが、64 01 タイムアウトが発生しました。 書き込みと同じトランザクション内にタイマー オプションを含めることで、コマンドのタイムアウトを調整することで、この問題を解決できました。 例: ブロック0に「00 01 02 03」を書き込む > ff c2 00 01 10 5f 46 04 40 42 0f 00 95 07 02 21 00 00 01 02 03 00 透過コマンド コマンドのサイズ（0x10 = 16バイトが続く） タイムアウトコマンド デバイスへのコマンド ご覧のとおり、応答は正しくなりました。 このコマンドは、基本的に元の投稿者の質問に示されているものと同じですが、緑のセクションが追加されています。ドキュメントに従って、1 秒のタイムアウトを設定します (これはおそらく過剰です)。 5f 46 = タイマーデータオブジェクト 04 = 長さ 40 42 0f 00 = 1,000,000 (マイクロ秒、LSBが先頭)、つまり 000f4240h = 1,000,000 おそらく元の投稿者にとっては役に立たないかもしれませんが、これによって私が費やした 2 ～ 3 時間を他の誰かが節約できるかもしれません。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command ありがとう@jimmychan 。はい、6401 を含むエラー コードと説明のリストを確認しました。元の投稿に記載した APDU シーケンスを考慮して、このエラーの原因を理解しようとしています。   タグがユーザーメモリへの単一ブロック書き込みコマンドに応答しない理由をご存知ですか?私が考えた例としては、書き込み操作にリーダーが待機している時間よりも時間がかかる可能性があるということです。リーダーをより長く待機するように設定してみましたが、これまでのところ、この方法で問題を解決することはできませんでした。また、SLI または DNA の仕様書にはこれに関する言及がないので、これが問題であるとは思えません。   繰り返しになりますが、タグが応答しない理由を理解するためのご助力いただければ幸いです。   ありがとう - ドリュー Re: ICODE SLI tag returns a 64 01 error for a write_single_block command リファレンス・マニュアル REF-ACR1552U-Series-1.06.pdf を確認してください。43ページ。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command こんにちは@jimmychan - リーダーのドキュメントを読みました。そのドキュメントから、私が使用しているコマンド構文を取得しました。私の知る限り、コマンド構文は正しいです。6401 エラーはリーダーから発生しているということですか?ドキュメントの中で、特に確認すべき部分はありますか? ご協力に感謝します。 ドリュー Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 読者の方はドキュメントをお読みください。 ACR1552U - USB NFCリーダ IV | ACS

ICODE SLI 标签在执行 write_single_block 命令时返回 64 01 错误 我使用的是 Windows 11 笔记本电脑和 ACS ACR1552 阅读器。 我正在使用 ACS 脚本工具（v5.02）向恩智浦 ICODE SLI 标签发送 APDU。 我正在创建一个透明会话，将协议设置为 15693/Layer3，然后使用透明交换封装向标签发送 APDU。 GET_SYSTEM_INFO 和 READ_SINGLE_BLOCK 似乎工作正常。 WRITE_SINGLE_BLOCK 返回"64 01" 错误，但似乎确实写入了数据。 我没有找到任何关于 64 01 响应的含义或原因的信息。 有谁能对此提供一些信息？ 以下是我正在处理的 APDU 序列。 APDU #4 读取数据块 0 的数据为 11 22 33 44 APDU #5 将数据块 0 的数据写入 12 34 56 78 - 但收到 64 01 错误 APDU #6 读取的 0 号数据块数据为 12 34 56 78 --这说明之前的写入实际上起了作用？ ; (1) 建立透明会话 < FF C2 00 00 02 81 00 00 > C0 03 00 90 00 90 00 ; (2) 透明交换 - 将协议切换到 SwitchProtocolRf::ISO15693 SwitchProtocolLayer::PART3 < FF C2 00 02 04 8F 02 02 03 > C0 03 00 90 00 8F 01 00 90 00 ; (3) get sys info < FF C2 00 01 04 95 02 02 2B 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 0F 00 0F 2E 98 5C 8A 00 01 04 E0 00 00 1B 03 01 90 00 ; (4) 读取具有安全状态的用户屏蔽 0 < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 92 01 00 96 02 00 00 97 06 00 00 00 00 97 06 00 00 00 11 22 33 90 00 ; (5) 用 12 34 56 78 < FF C2 00 01 09 95 07 02 21 0012 34 56 7800 > C0 03 01 64 01 90 00 ; (6) 读取具有网络安全状态的用户屏蔽 0 < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 92 01 00 96 02 00 00 97 06 00 00 97 06 00 00 12 34 56 78 90 00 ; (7) 结束透明会话 < FF C2 00 00 02 82 00 00 > C0 03 00 90 00 90 00 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 我在读取/写入 icode SLIX/SLIX2 标签时也遇到了同样的问题，写入正常，但出现了 64 01 超时。 我通过在写入的同一事务中加入计时器选项，调整命令的超时时间，从而解决了这个问题。 例如将"00 01 02 03" 写入 0 号区块 > FF C2 00 01 10 5F 46 04 40 42 0F 00 95 07 02 21 00 01 02 0300 透明命令 命令 大小（0x10 = 接下来是 16 字节） 超时 命令 到 设备 可以看出，现在答案是正确的。 该命令与原作者问题中的命令基本相同，只是增加了绿色部分，根据文档，该部分设置了 1 秒超时（可能过长）。 5f 46 = 计时器数据对象 04 = 长度 40 42 0f 00 = 1,000,000（微秒，LSB 优先），即 000f4240h = 1,000,000 可能太晚了，对最初的发帖人没用，但也许这能帮其他人省下我花费的两三个小时。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 谢谢@jimmychan。 是的，我见过错误代码和描述列表，包括 6401。 鉴于我在原帖中提供的 APDU 序列，我想弄明白是什么原因导致该错误。   您知道标签不响应向用户内存写入单块命令的原因吗？ 我想过的一个例子是，写入操作可能比读者等待的时间更长。 我曾尝试配置阅读器，让它等待更长的时间，但到目前为止，我还没能解决这个问题。 另外，我在 SLI 或 DNA 规格表中没有看到任何参考，所以我怀疑这是问题所在。   如果您能帮助我们了解标签为何没有反应，我们将再次不胜感激。   谢谢 - 德鲁 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 你可以查看参考手册 ref-ACR1552U-Series-1.06.pdf。第 43 页。 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 你好@jimmychan- 我已经阅读了阅读器的文档，这就是我使用的命令语法。据我所知，我的命令语法是正确的。你是说 6401 错误来自读卡器？您有什么具体的文件需要我查看吗？ 感谢您的帮助。 德鲁 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command 请阅读读者文件。 ACR1552U - USB NFC 阅读器 IV | ACS

シングルチャネルABS SB0401監視モジュールの問題 こんにちは@nxp 、 私は SPI マスターとして NXP S32K31xEVB-Q48 MCU を搭載した SB0401 シングル チャネル ABS モジュール IC を使用しています。監視/モジュール データを 10 ミリ秒ごとに送信していますが、SB0401 監視モジュールは繰り返しリセット/再起動しているように見えます (約 50 ミリ秒ごとに 1 回)。これに伴い、SPI 転送ごとに SPI「エラー数」が増加します。 以下にセットアップと具体的な質問を示します。 ハードウェア/ソフトウェアのセットアップ MCU（SPIマスター）：S32K31xEVB-Q48（S32K31xファミリ） デバイス: SB0401 (シングルチャネルABSモジュールIC) インターフェース: SPI (LPSPI) (DMA ベースの転送) 定期送信: 10 ミリ秒ごと 観察された問題: SB0401 監視モジュールが約 50 ミリ秒ごとにリセット/再起動する (添付のログを参照) 観察された行動 エラー カウンターは、SPI バイト/ワード転送ごとに増加します。 SB0401 メッセージ 18 から AR (シード) を読み取り、その AR に基づいて MR を計算します。 定期的にフレームを送信しているにもかかわらず、SB0401 監視モジュールはリセット/再起動します。 質問 MR計算とAR計算（メッセージ18） SPI 転送ごとにエラー数が増加します。 SB0401 メッセージ 18 から受信した AR 値を使用して MR を計算します。 この状況では、転送ごとにエラー カウンターが増加することが予想されますか、それとも MR/AR ロジックが正しくないことを示しているのでしょうか。 AR (メッセージ 18) に対する正しい MR 計算フロー/タイミングと、よくある落とし穴 (古い AR の使用、間違ったバイト/ビット抽出、タイミング ウィンドウ、カウンター アライメントなど) を確認してください。 メッセージ0を書き込むときのACK位置 TxBuf[0] の メッセージ0 にデータを書き込む場合 、確認応答をどこで確認すればよいですか？ 例: TxBuf[0] への書き込みの場合 、ACKは RxBuf[0](同じワード) に表示されますか、それとも RxBuf[1](次のワード) に表示されますか? 「次の SPI ワード/フレームで ACK が発生する」というルールが定義されている場合は、正確なマッピングを共有してください。 リファレンスSW / CDDドライバ SB0401 のリファレンス CDD / サンプル ドライバ (C ソースまたは AUTOSAR スタイルの CDD 統合) があり、ガイダンスとして共有できますか? 共有できない場合は、公式の SB0401 ソフトウェア パッケージ / アプリケーション ノート / リファレンス実装の詳細を推奨していただけますか? Re: Single channel ABS SB0401 Monitoring Module Issue こんにちは@guoweisun はい、わかりました。 NXPについて: Ettiksoft technologies Pvt ltd. プロジェクト: 二輪車用シングルチャネル ABS。 Re: Single channel ABS SB0401 Monitoring Module Issue ハイ ここであなたの会社やプロジェクトの情報を表示することは可能ですか? Re: Single channel ABS SB0401 Monitoring Module Issue こんにちは@guoweisun わかりました。このモジュールの動作のような他の参照コードも存在します。 Re: Single channel ABS SB0401 Monitoring Module Issue この特殊部品に関する参照コードをもう一度確認してみましょう。 Re: Single channel ABS SB0401 Monitoring Module Issue この部品には CDD やその他のソフトウェア ドライブがないため、参照回路図もお客様が NDA に署名してから共有する必要があります。 Re: Single channel ABS SB0401 Monitoring Module Issue ここに投稿できないサンプルコードについては、CASEポートからチケットを送信していただけますか? 家庭用

FTM 定时器混乱 我试图启动 FTM0/FTM1 定时器，但在运行定时器代码时却出现了 HardFault 故障，为什么？ 无法运行的代码 #include "MKE02Z4.h" /* ================= GLOBALS ================= */ volatile uint8_t uartFlag = 0; /* ================= PROTOTYPES ================= */ void init_clock(void); void init_uart0(void); void init_FTM1(void); void UART_Send(const char *s); /* ================= FTM1 ISR ================= */ void FTM1_IRQHandler(void) { /* Clear overflow flag (write 0 while set) */ FTM1->SC &= ~FTM_SC_TOF_MASK; uartFlag = 1; } /* ================= MAIN ================= */ int main(void) { init_clock(); init_uart0(); init_FTM1(); UART_Send("FTM1 Initialized\r\n"); while (1) { if (uartFlag) { uartFlag = 0; UART_Send("A\r\n"); } __WFI(); /* wait for interrupt */ } } /* ================= CLOCK INIT ================= */ void init_clock(void) { /* * Assume internal clock already configured by SDK startup * Bus clock = 32 MHz */ SIM->BUSDIV = 0x01; /* divide by 1 */ } /* ================= UART0 INIT ================= */ void init_uart0(void) { /* Enable UART0 clock */ SIM->SCGC |= SIM_SCGC_UART0_MASK; /* UART0 pin select (TX/RX) */ SIM->PINSEL |= SIM_PINSEL_UART0PS_MASK; /* Disable TX inversion (important!) */ SIM->SOPT &= ~SIM_SOPT_TXDME_MASK; /* * 9600 baud @ 32 MHz * SBR = 32e6 / (16 * 9600) ≈ 208 */ UART0->BDH = 0x00; UART0->BDL = 53; UART0->C1 = 0x00; UART0->C2 = UART_C2_TE_MASK | UART_C2_RE_MASK; } /* ================= FTM1 INIT ================= */ void init_FTM1(void) { /* Enable FTM1 clock */ SIM->SCGC |= SIM_SCGC_FTM1_MASK; __DSB(); /* ---- VERY IMPORTANT ORDER (KE02 SAFE) ---- */ /* Stop counter completely */ FTM1->SC = 0; /* Disable write protection (WRITE ONCE) */ FTM1->MODE = FTM_MODE_WPDIS_MASK; /* Reset counter */ FTM1->CNTIN = 0; FTM1->CNT = 0; /* * 32 MHz / 128 = 250 kHz * 250000 ticks = 1 second */ FTM1->MOD = 249999; /* Enable overflow interrupt, prescaler = 128 */ FTM1->SC = FTM_SC_PS(7) | FTM_SC_TOIE_MASK; /* Enable NVIC */ NVIC_EnableIRQ(FTM1_IRQn); /* START TIMER (LAST STEP ONLY) */ FTM1->SC |= FTM_SC_CLKS(1); } /* ================= UART SEND ================= */ void UART_Send(const char *s) { while (*s) { while (!(UART0->S1 & UART_S1_TDRE_MASK)); UART0->D = *s++; } } 工作代码 #include "MKE02Z4.h" /* ================= GLOBALS ================= */ volatile uint8_t uartFlag = 0; /* ================= PROTOTYPES ================= */ void init_clock(void); void init_uart0(void); void init_FTM2(void); void UART_Send(const char *s); /* ================= FTM2 ISR ================= */ void FTM2_IRQHandler(void) { /* Clear overflow flag (write 0 while set) */ FTM2->SC &= ~FTM_SC_TOF_MASK; uartFlag = 1; } /* ================= MAIN ================= */ int main(void) { init_clock(); init_uart0(); init_FTM2(); UART_Send("FTM2 Initialized\r\n"); while (1) { if (uartFlag) { uartFlag = 0; UART_Send("A\r\n"); } __WFI(); /* wait for interrupt */ } } /* ================= CLOCK INIT ================= */ void init_clock(void) { /* * Assume internal clock already configured by SDK startup * Bus clock = 32 MHz */ SIM->BUSDIV = 0x01; /* divide by 1 */ } /* ================= UART0 INIT ================= */ void init_uart0(void) { /* Enable UART0 clock */ SIM->SCGC |= SIM_SCGC_UART0_MASK; /* UART0 pin select (TX/RX) */ SIM->PINSEL |= SIM_PINSEL_UART0PS_MASK; /* Disable TX inversion (important!) */ SIM->SOPT &= ~SIM_SOPT_TXDME_MASK; /* * 9600 baud @ 32 MHz * SBR = 32e6 / (16 * 9600) ≈ 208 */ UART0->BDH = 0x00; UART0->BDL = 53; UART0->C1 = 0x00; UART0->C2 = UART_C2_TE_MASK | UART_C2_RE_MASK; } /* ================= FTM2 INIT ================= */ void init_FTM2(void) { /* Enable FTM2 clock */ SIM->SCGC |= SIM_SCGC_FTM2_MASK; __DSB(); /* ---- VERY IMPORTANT ORDER (KE02 SAFE) ---- */ /* Stop counter completely */ FTM2->SC = 0; /* Disable write protection (WRITE ONCE) */ FTM2->MODE = FTM_MODE_WPDIS_MASK; /* Reset counter */ FTM2->CNTIN = 0; FTM2->CNT = 0; /* * 32 MHz / 128 = 250 kHz * 250000 ticks = 1 second */ FTM2->MOD = 249999; /* Enable overflow interrupt, prescaler = 128 */ FTM2->SC = FTM_SC_PS(7) | FTM_SC_TOIE_MASK; /* Enable NVIC */ NVIC_EnableIRQ(FTM2_IRQn); /* START TIMER (LAST STEP ONLY) */ FTM2->SC |= FTM_SC_CLKS(1); } /* ================= UART SEND ================= */ void UART_Send(const char *s) { while (*s) { while (!(UART0->S1 & UART_S1_TDRE_MASK)); UART0->D = *s++; } }   Re: FTM Timer Confusion 你好@Jana_muralidharan 请调试检查 FTM1 时钟是否启用，并验证计数寄存器是否正常工作。   BR 爱丽丝 Re: FTM Timer Confusion 实际上，我发现了错误 这是因为我使用了仅适用于 FTM2 的寄存器、 因此，在删除不需要的寄存器后，它就能正常工作了。 我发现HardFault Error 只有在以下情况下才会发生、 我们使用了原本不存在的寄存器。 嘿，感谢您对这个问题的关注，谢谢.....。

互換性のある圧力センサを探しています 皆さんこんにちは オリジナルの 125pc05d1 と交換できる互換性のある圧力センサを探しています。 125pc05d1はオリジナルの圧力センサです。差圧タイプです。 オリジナルの圧力センサの外形図と技術仕様を添付しました。 125pc05d1 の感度はおよそ Δmv/Δp ≈ 70mv/5psi ≈ 14 に等しいですが、後続の増幅回路が複雑なので、どのように調整すればよいか分かりません。同じ感度を持ち、互換性のある新しいモデルの圧力センサがあれば理想的です。 より詳細なテストについては、以下のリンクを参照してください。 https://www.eevblog.com/forum/repair/replacing-the-pressure-sensor-requires-assistance/ ご協力ありがとうございます。 Re: Seeking a compatible pressure sensor こんにちは、 形状と機能の両方においてオリジナルの 125pc05d1 に最も近い MPX10DP の使用を検討してください。より高い解像度を得るために、より広い圧力範囲やより高い出力電圧が必要な場合は、追加の信号調整が必要になりますが、MPX5010DP を検討してください。 BRs、トーマス Re: Seeking a compatible pressure sensor よろしくお願いします。

8x DPDMUXで静的DPLをロードできませんでした こんにちは、コミュニティの皆様 DPDMUX と DPNI の動的作成を正常に使用し、次のコマンドで DPL を生成します。 8x ls-addni --fs-entries=8 --num-queues=8 -n ソース /usr/local/dpdk/dpaa2/dynamic_dpl.sh ... 8x restool dpdmux create 8x restool dprc connect dprc.1 --endpoint1= .n.0/1/2 --endpoint2= / /dpni.k> dprc を復元して、dpl dprc.1 > dpl-8-dpdmux.dts を生成 uboot が MC レイアウトを開始できるように、静的 DPL を dpl-8-dpdmux.dtb (dtc ツールによって生成) で更新します。 エラーは次のように表示されます: [E, mem_mng_get_phys_mem:655] メジャー メモリ。マネージャーのメモリ割り当てに失敗しました [E, mem_mng_get_phys_mem:658] 必要なサイズ 0x000040000、アライメント 0x000000100 は、パーティション ID 7 の使用可能なメモリを超えています [E, init_bman_bp:399, DPDMUX] ID[6] - dpbp_allocate_buffers()、dpbpバッファの割り当てに失敗しました [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure: -12 [E, mem_mng_get_phys_mem:655] メジャー メモリ。マネージャーのメモリ割り当てに失敗しました [E, mem_mng_get_phys_mem:658] 必要なサイズ 0x000040000、アライメント 0x000000100 は、パーティション ID 7 の使用可能なメモリを超えています [E, init_bman_bp:399, DPDMUX] ID[7] - dpbp_allocate_buffers()、dpbpバッファの割り当てに失敗しました [E, init_infrastructure:3750, DPDMUX] swlib_init_bman_bp : -12 [E, dpdmux_init:4487, DPDMUX] init_infrastructure: -12 [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpmac@9 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpni@15 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@6 と dpni@7 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpmac@10 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpni@16 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。dpl プロセッシングを続行します... [E, resman_is_link_permitted:6375, RESMAN] オブジェクトが見つかりませんでした [E, linkman_probe_cb:205] 共通の祖先がありません - dpdmux@7 と dpni@8 の接続に失敗しました [E、subnode_process:155] プローブモジュール「接続」がエラーコード -1 を返します。プロセッシングを続行します... [E, dpl_process:527] 「接続」の解析中にエラーが発生しました。DPL の残りのプロセッシングをスキップします。 [E、メイン:198] DPL プロセッシングに失敗しました。続行中... 動的な方法と同じレイアウトをサポートするために、静的 DPL には何か制限がありますか? QorIQ LS2デバイス Re: Failed to load static DPL with 8x DPDMUX こんにちは、イーピンワンさん 動的レイアウト作成で '--max-dmat-entries' を使用すると、 'restool dprc generate-dpl dprc.1' によって最終的な dts は変更されません。 SO、.dts に次の要素「mem-size」と「 max-dmat-entries」を追加して試してみます。手動で: dpdmux@0 { 互換性 = "fsl,dpdmux"; オプション = "DPDMUX_OPT_CLS_MASK_SUPPORT", "DPDMUX_OPT_AUTO_MAX_FRAME_LEN"; 方法 = "DPDMUX_METHOD_CUSTOM"; マニピュレータ = "DPDMUX_MANIP_NONE"; num_ifs = <0x2>; mem-size = <0x100>; // これは私が手動で追加したものです max-dmat-entries = <0x8>; // これは私が手動で追加したものです }; 残念ながら、これでは問題は解決せず、MC デバッグから同じエラー メッセージが表示されます。 同封の私のDPLもご確認ください。 Re: Failed to load static DPL with 8x DPDMUX 以下の方法が出来るかお試しください。 DPDMUX を作成するときは、リソース割り当てを減らすために「--max-dmat-entries=8」を指定してください。 --max-dmat-entries= DPDMUX アドレス テーブルの最大エントリ数。デフォルトは 64 です。 問題が解決しない場合は、コンソール ログ全体を共有して DPDMUX を作成し、DPL ファイルを生成します。 また、どのプロセッサを使用していますか? Re: Failed to load static DPL with 8x DPDMUX こんにちは、 DPL パラメータ名を修正することでこの問題を解決できました。

bl2でのseclogging こんにちは、 A-core (BSP43) に安全なログ記録を実装しようとしています。目標は、セキュア ブートの失敗、Wi-Fi/TLS の失敗など、セキュリティ関連の失敗を記録することです。 現在、BL2 ステージでのセキュア ブートの失敗を記録しようとしています。私の最初のアプローチは、これらのログを NOR フラッシュに直接書き込み、HSE を使用して暗号化することでした。ただし、S32G の BL2 レベルでは次の制限に遭遇しています。 BL2 には、NOR フラッシュの読み取りや書き込みに使用できる定義済み API はありません。 BL2 ステージでは永続的または追加形式のログ記録を実装することはできません。 これらの制約のため、このようなセキュア ブートの失敗ログを、後でLinuxからアクセスできるようにBL2のどこにどのように保存すればよいかはわかりません。 Wi-Fi および TLS 関連の障害については、Linux レベルで NetworkManager ベースのログを使用する予定です。 BL2 に起因するセキュア ブートの失敗をログに記録するための実行可能なアプローチについてアドバイスをいただけませんか。また、このシナリオで安全にログに記録するための推奨メカニズムを提案していただけますか。 Re: seclogging at bl2 こんにちは、 @Jayashree ご投稿ありがとうございます。 これはユーザー定義のソフトウェア実装であり、このようなトピックに関して当社側から正式な推奨がないことを残念に思います。 BL2 ステージに記録されたセキュア ブートの失敗に関しては、BL2 が BL3x バイナリの認証に失敗し、関連情報を記録したいということでしょうか? 私の経験からすると、上記のログはコンソールから見つけることができます。それらを QSPI に保存したい場合は、BL2 が QSPI からイメージをロードして DDR に格納し、QSPI にアクセスできるようになるため、関連するコード/API をチェックして、要件を満たすことができるかどうかを確認していただけますか? BR チェイン Re: seclogging at bl2 こんにちは、Chenyinさん ご提案に従って、BL2 の MMIO 読み取り/書き込み API を使用しようとしましたが、API 呼び出しの直後にブート プロセスが停止するようです。 mmio.png FSPI 読み取り/書き込み API の使用も試みましたが、この場合、Yocto ビルド自体を完了できません。 Jayashree_0-1766732142440.png セキュア ブートが有効な場合、BL2 からの読み取り/書き込みアクセスがサポートされているかどうかを確認してください。サポートされている場合、このCASEに推奨されるAPIを教えていただけますか?あるいは、BL2 からのログ記録やデータの永続化に関して実行可能なアプローチや推奨される代替方法についてご指導いただければ幸いです。 よろしくお願いします、 ジャヤシュリー  

LVGL基准测试性能优化   1 背景 2 开发设置 2.1 软件 2.2 硬件 3 性能优化 3.1 基准性能 3.2 优化 1：编译器优化 3.3 优化 2：外部同步动态随机存取存储器(SDRAM) 3.4 优化 3：VGLite 加速 3.5 优化比较 4 结论 5 参考 1. 背景 LVGL（轻量级通用图形库）是一个高性能、低资源的嵌入式图形库。由于其强大的开源生态系统和广泛的操作系统兼容性，它支持从低功耗的 ARM Cortex-M 微控制器（时钟速度低至 100 MHz）到运行 Linux 的高性能 MPU 的各种硬件平台，使其成为嵌入式开源解决方案的首选。许多芯片供应商现在提供对 LVGL 的“开箱即用”支持。 NXP 为其主流平台（包括 MCX、i.MX RT 和 LPC 系列）提供了现成的软硬件示例，并将 LVGL 示例集成到 MCUXpresso SDK。这些示例包含不同场景下的量化基准指标。然而，由于软硬件配置和规格存在差异，实际性能可能会显著不同，通常需要针对具体场景进行调优。 本文档基于 i.MX RT1170 平台的实际经验，旨在帮助 NXP 用户快速掌握并应用合适的优化策略，以提升 LVGL 应用性能。 Sam_Gao_0-1764584255540.png@Smartling Language Service   cpu-usage.png FPS.png 4. 结论 本文档对 NXP 官方 LVGL 基准测试示例进行了逐步优化，并在 CPU 使用率、FPS、渲染时间和刷新时间方面进行了量化提升。以Widgets 演示为例： CPU使用率从96%→12%下降 FPS 从 2 提升至 59 这些优化技术（不仅限于 LVGL）广泛适用于 i.MX RT 平台上的系统级性能调优。