Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
System Controller Firmware 101-はじめに 評価キットを使用する際には、BSPに含まれるSystem Controller Firmware(SCFW)バイナリが提供されます。このscfwバイナリはそのボード専用に調整されており、ご使用のハードウェアに合わせてボード依存部分を変更する必要がある場合があります。 本書ではSCFWのポーティング手順の概要を説明します。詳細についてはSystem Controller Porting guide(sc_fw_port.pdf)を参照してください。 システムを設定する SCFWはLinuxホスト上でビルドされます。システムをセットアップする手順は次のとおりです: GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017をARM websiteからダウンロードします: ファイルを展開するディレクトリを選択します。例: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ツールチェーンを含むディレクトリ(上記例では"~/gcc_toolchain")を指すようTOOLS環境変数を設定します。.bash_profileを編集してこの環境変数をexportすることもできます: export TOOLS=~/gcc_toolchain/ srec_catもビルドに必要です。これは通常srecordパッケージに含まれており、ubuntuでは次のように実行します: sudo apt-get update sudo apt-get install srecord これでポーティングキットのディレクトリ(例:scfw_export_mx8qm)に移動し、scfwをビルドできます。 System Controller Firmwareポーティングキット SCFW 移植キットには、SCFW をお客様のボードで動作するように変更できるソースファイルとオブジェクトファイルが含まれています。 最新のSystem Controller Firmwareポーティングキットは i.MX Software and development webpageから入手できます: ポーティングキットを入手したら展開します: tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ 次のようなファイル構成が表示されます: ポーティングキットはpackages以下に含まれており、READMEに展開手順が記載されています。基本的には: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ エンドユーザーライセンス契約の同意を求められます: 同意するとポーティングキットは新しいフォルダに展開されます。フォルダ構成は次のとおりです: SCFWに関するドキュメントはdoc/pdfにあるか、html形式で提供されています。sc_fw_port.pdfに目を通すことを推奨します。 異なるSoCバリアント(QM A0、QM B0、QXP B0)のポーティングキットはsrcにtar.gzとして格納されています。その他のファイルはLinux、QNX、FreeRTOS、U-boot、ARM Trusted Firmwareなど向けのSCFWライブラリです。 複数のSoCバリアント(QXPとQMの両方など)で作業する場合は、すべてのポーティングキットを1つのディレクトリに展開することを推奨します。これにより、そのディレクトリから任意のバリアント向けにビルドできます。実行コマンドは次のとおりです: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ scfw_export_mx8フォルダが作成され、ここからサポートされている任意のバリアント向けにSCFWをビルドできます。または、目的のバリアントのパッケージだけを展開して使用することもできます。 cd scfw_export_mx8/‍ すべてのビルドフォルダーには、SCFWのビルド結果が含まれており、プラットフォームにはSCFWのソースが保存されています。 ボード固有のコードはすべて「platform/board/mx8_」にあります。ここでderivativeはQXPやQMなどのi.MX8シリコンファミリ、board_nameはSCFWパッケージの対象ボード名です。 SCFWをお使いのボードにポーティングする最初のステップは、i.MX8のderivativeとボード用のフォルダを作成することです。既存のボード例をコピーしてフォルダ名を変更すると、すぐに開始できるプロジェクトが得られます。例: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ この例のボードは「myBoard」と呼ばれ、i.MX8QM B0 デバイス用です。このボード用の SCFW を構築するには、単に次のコマンドを呼び出してください。 make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ ターゲットがi.MX8QXPの場合は、このデバイスをベースにしたボードを選び、「make qx」を実行するだけです。 ビルドオプションや詳細なブート情報などの追加情報はSCFWポーティングガイド(sc_fw_port.pdf)に記載されています。本書の第2章はポーティングプロセスの優れた入門です。 概要と有用な情報 PMICの設定概要およびboard.c一般的な修正 変更が必要な主なファイル(場合によっては唯一)は「board.c」で、場所は「platform/board/mx8X_board/」です。board.cファイルにはSCU UARTポート、PMIC初期化ルーチン、PMIC温度アラーム設定などボード関連情報のほとんどが含まれており、LDO電圧を設定したりPMICと通信するように変更することもできます。board.c内のすべての関数はSCU自身によって実行されるため、PMICとの通信に使用されるI2Cインターフェースにアクセスできます。 外部電源(たとえばPMIC LDO)で駆動されるSoCリソース(APコアやGPUなど)はboard_set_power_modeによってオン/オフされ、リソースを特定のPMIC電源にマッピングする処理はboard_get_pmic_infoで行われます。例としてi.MX8QMバリデーションボードでは、A53サブシステムがPF100 PMICカードの3番目のPMIC(PMIC_2_ADDR、アドレスはPMIC_0から開始)のSW2とPF8100 PMICカードの1番目のPMIC(PMIC_0_ADDR)のSW5により給電されます。 case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 外部電源で駆動されるSoCリソース(APコア、GPUなど)の電圧はboard.c内のboard_set_voltageで管理されます。リソースと電源のマッピングは前述のとおりboard_get_pmic_infoで行われます。 8個の「ボードリソース」(SC_R_BOARD_R0〜SC_R_BOARD_R7)が利用可能で、これらを用いてSCUが管理できるボード上のコンポーネントを定義できます。たとえばPMICのLDOの1つで駆動されるセンサをボードリソースにマッピングし、board.cを変更してセンサの電源オン/オフや電圧変更を行えます。 ボードリソースの電圧変更は、board_trans_resource_powerで電圧を設定するか、実行時に電圧を変更する必要がある場合はboard_set_controlを修正して、Miscellaneous Service 101で説明されているミスレニアスコールがそのリソースに対して発行されるたびに電圧を変更します。たとえばSC_R_BOARD_R7の電圧を変更する場合、board_set_controlに以下のcaseを追加します: case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 上記のcaseはアプリケーションが次の関数を呼び出すたびにSCUによって実行されます。 sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ ボードリソースの電源オン/オフはboard.c内のboard_trans_resource_powerで行われます。例えばNXPのバリデーションボードでは、ボード上のPTN5150はボードリソース0で管理され、電源のオン/オフは次のように制御されます: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ アプリケーション側で以下の関数が呼び出されるたびに、SCUは上記のコードを実行します: sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_scは、I2CモジュールやPMICとの通信に使用されるパッドなど、SCUが必要とするリソースをマーキングするために使用します。board.cの関数が動作するために必要なリソースは、本関数で移動不可に設定する必要があります。例えばSCUのI2Cモジュールを保持するには、次の行を追加します: rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ 以下のパッドはSCUに属しており、アプリケーションからはアクセスできません: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0〜SC_P_SCU_BOOT_MODE5 board_system_configは初期リソース管理を行う関数で、イメージ内でalt_configフラグが設定されている場合にのみ呼び出され、パーティションを作成してリソースを割り当てることができます。詳細はResource Management Service 101を参照してください。 board_get_pcie_clk_srcはPCIeが使用するクロックを定義し、BOARD_PCIE_PLL_EXTERNALまたはBOARD_PCIE_PLL_INTERNALのいずれかを指定できます。 board_printは変更内容のデバッグに非常に便利で、構文は次のとおりです: board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ 最初のパラメータがデバッグレベルで、それ以降は標準printfと同様に動作します。出力はSCUが対応するデバッグレベルでビルドされている場合にのみSCUのデバッグ出力で確認できます。上記の例では出力を表示するためにSCFWを次のようにビルドする必要があります: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍ 使用例 以下のユーティリティはSystem Controller Firmwareリクエストの方法を示し、QNXとLinuxの両方でコマンドラインからリクエストを行う手段を提供します。 System Controller Firmware Command Line Utility for Linux and QNX System Controller Firmware 101 i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus
View full article
KW47 知识中心 KW47 系列具备 96 MHz Arm® Cortex®-M33 内核,并搭载蓝牙低功耗(LE)子系统。独立的无线子系统具有专用核心和存储器,可减轻主CPU的负载,将其留给主要应用,并允许固件更新以支持未来的无线标准。KW47 还通过集成的 EdgeLock® 安全飞地核心配置文件提供高级安全性,并将由 NXP 的 EdgeLock 2GO 云服务支持凭证共享。 KW47 系列具备蓝牙信道探测功能,以及专用的片上定位计算引擎,可降低测距延迟。它集成了额外的内存,可支持特定应用代码、连接协议栈和无线固件更新。这意味着无线电子系统的实时活动在能够与应用程序不同的核心上运行,实现可靠的无线性能。 基于 NXP 在汽车解决方案领域的深厚历史,KW47 系列提供从 -40 °C 到 125 °C 的宽操作温度范围以及用于汽车应用的外围设备。KW47 将成为 NXP 15 年产品寿命计划的一部分,以支持长期使用。 KW47 系列配备 MCUXpresso Developer Experience 支持,可优化、简化和加速嵌入式系统的开发工作。 KW47 处于试生产阶段,开发人员可以立即开始使用与其引脚和软件兼容的 KW45。   joseAntonio_ruiz_0-1739544574098.png   joseAntonio_ruiz_1-1739544610236.png   早期访问计划 立即加入KW47早期访问计划:KW47 Early Access 您可以通过联系 NXP 销售团队来申请访问权限。   信道探测 信道探测简介 演示文稿 CCC CS 功率估算工具可用(附有 Excel 文件)   蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   培训 蓝牙低能耗 6.0 NXP 简介 射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备: 本文提供了有助于项目开发的设备链接  有用链接 参考设计 - NXP 社区 使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区:该社区提供了如何使用信号频率分析仪的步骤 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  首次正确构建 PCB 的最佳方法,使用 KW47(汽车)或 MCXW712(IIoT)…… 社区:在此社区中,提供了使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接,以及所有关于无线性能、低功耗和无线认证(CE/FCC/ICC)的内容。 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式:本文分为两部分: 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序用于设置发射机/接收机测试命令:本文提供了步骤,展示用户如何向设备发送串行命令 。Bluetooth LE HCI Black Box Quick Start Guide:本文介绍了一个简单的过程,用户可以通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具: 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序(汽车或物联网)的功耗,并评估您解决方案的电池寿命。  
View full article
通过 LPC 54018 中的 USB 通信在挂机中读写 如何在 LPC 54018 中通过 USB 通信写入和读取 Pendriver。 我使用的是 USB1 主机? LPC54xxx Re: read and write in pendriver through USB communication in lpc 54018 微控制器必须在 USB 主机模式下工作,因为笔式驱动器是 USB 大容量存储类 (MSC) 设备。 LPC54018 支持USB 2.0 全速主机,足以满足标准笔式驱动器的需求。 实施概述: 硬件要求 USB Type-A 接口 笔式硬盘的外部5V VBUS 电源 正确的 D+ 和 D- 连接 建议使用 VBUS 检测 USB 主机堆栈 使用恩智浦 MCUXpresso SDK 启用 USB 主机 + MSC 类驱动程序 使用FATFS处理文件系统 列举 插入时,USB 主机会枚举笔式驱动器 该设备被识别为大容量存储设备 大容量传输用于数据传输 文件系统访问 大多数笔式硬盘的格式为FAT32 挂载后,可执行标准文件操作 使用 f_open()、f_read() 和 f_write() 等应用程序接口 用例示例 这种 USB 存储访问通常用于嵌入式系统,以存储日志、媒体文件或缓存数据。 例如,嵌入式媒体播放器可从以下平台流式传输内容 HDOBOX等平台流式传输内容的嵌入式媒体播放器,就可以使用这种方法将配置文件、字幕或播放日志存储在 USB 闪存盘上。 重要说明 默认情况下不支持 exFAT 和 NTFS USB 主机 + FATFS 需要足够的内存 安装前在设备连接后添加延迟 Re: read and write in pendriver through USB communication in lpc 54018 观影应用程序 HDO Box 电影 我使用这种方法进行管理,效果很好、 Re: read and write in pendriver through USB communication in lpc 54018 Pendriver 中的 USB 通信相当难用。 Re: read and write in pendriver through USB communication in lpc 54018 你好,@Arularasan、 为了再次确认,能否请您检查一下 USB1 端口是否正常工作?你可以尝试像使用其中一个 USB 示例的设备一样使用它。 另外,能否请您检查一下您的硬盘?将磁盘驱动器输入计算机时,计算机会检测到它吗?你能不能试试用另一个 pendrive 或 USB 设备的 USB 主机示例? 最后,能否请您用挂盘测试另一个 USB 主机示例?使用以下示例进行尝试可能会有所帮助:usb_host_cdc和/或usb_host_msd_command。 致以最诚挚的问候,劳尔。 Re: read and write in pendriver through USB communication in lpc 54018 你需要一个 JTAG 调试器来上市和调试在恩智浦 LPC54018 板上运行的代码。FreeRTOS 使用 OM40006 物联网模块进行了测试。有关支持的调试器的更多信息,请参阅 《恩智浦 LPC54018 物联网模块用户手册 》,该手册可从以下网站获取 OM40007 LPC54018 物联网模块 产品页面。 如果您使用的是 OM40006 物联网模块调试器,请使用变流器电缆将调试器的 20 针连接器连接到恩智浦物联网模块上的 10 针连接器。 使用迷你 USB 转 USB 电缆将恩智浦 LPC54018 和 OM40006 物联网模块调试器连接到计算机的 USB 端口。   filmplus 应用程序 Re: read and write in pendriver through USB communication in lpc 54018 @RaRo感谢您的回复。 SDK 示例代码下的 USB HOST 演示 ("host_msd_fatfs_bm") 我已下载,但无法使用! 我 想通过 USB 通讯读写笔式驱动器,我使用的是 USB1。 请帮助我@RaRo Re: read and write in pendriver through USB communication in lpc 54018 你好,@Arularasan、 您试过 host_msd_fatfs_bm 示例吗?该示例似乎使用了 f_write() 和 f_read(),它们用于通过 FATFS 和 USB 进行写入和读取。 您能否查看以下参考手册,了解有关 USB + FATFS 应用程序的更多信息? MSDFATFSAPIRM、飞思卡尔 MSD FATFS API-参考手册和 USBHOSTAPIRM,飞思卡尔 USB 堆栈主机 API-参考手册。 致以最诚挚的问候,劳尔。 Re: read and write in pendriver through USB communication in lpc 54018 @RaRo是的,我已经在MCUXpresso IDE的帮助下完成了 lpc 54018 中的所有程序。 MCUXpresso IDE 生成的示例代码。没有创建读写功能,请帮助我通过 USB 通信在 lpc 54018(我使用的是 USB1 主机)中读写 Pendriver 的步骤。 Re: read and write in pendriver through USB communication in lpc 54018 你好,@Arularasan、 能否请您查看以下有类似问题的主题?已解决:我想使用 USB 连接从笔读取文件...- 恩智浦社区 此外,您还可以尝试使用 LPC54018 SDK 中的 USB 示例,如果使用的是 MCUXpresso IDE,请单击 "导入 SDK 示例... "并搜索 USB。您可以通过集成开发环境或以下链接下载 SDK:MCUXpresso SDK Builder。 RaulRomero_0-1675443213979.png [MCUXpresso IDE 快速启动面板和 SDK 导入向导] 可能需要定义您要使用的 USB:USB1 或 USB0。 致以最诚挚的问候,劳尔。
View full article
将 EdgeLock® SE05X 集成到 MIMXRT1180-EVK 本文档内容免责声明: NXP 提供的任何支持、信息和技术(“材料”)均按“现状”提供,不附带任何明示或暗示的保证,且 NXP 在适用法律允许的最大范围内,否认与材料相关的所有直接或间接责任和损害。NXP 对任何与应用或产品设计相关的协助不承担任何责任。材料仅可用于与 NXP 产品相关联。NXP 可以不受限制地使用您对材料提供的任何反馈。 摘要 本文档旨在指导开发人员在 NXP MIMXRT1180EVK 开发板上集成 EdgeLock® SE050 安全芯片,以实现硬件级别的安全增强。安全元件可以轻松连接到任何系统,要求极低——只需电源和两个 I2C 引脚。此外,由于主机软件支持 Plug&Trust 中间件,因此集成起来非常容易。 硬件先决条件 主机平台:MIMXRT1180EVK 扩展板: OM-SE050X 硬件设置 1. 按如下方式配置 OM-SE05xARD 跳线[1]: Kan_Li_0-1764213231765.png 2. 将 MIMXRT1180-EVK 上的跳线配置为默认[2]: Kan_Li_0-1764227605616.png 3.将 OM-SE05xARD 安装到 MIMXRT1180-EVK 上 2025-11-27_14-28-40.png 软件集成 有两种方法将 OM-SE05xARD 集成到 MIMXRT1180-EVK:一种基于 SDK,另一种基于 Zephyr。用户可以根据自己的需求选择其中任一。 SDK集成: 平台文件生成。 nano 软件包为在任意 MCU 平台上集成 MW 提供了非常简便的方式。用户只需在 simw-nanopkg/lib/platform 文件夹中添加或修改对应平台的特定文件即可。 Kan_Li_0-1764229140781.png 应用随附的补丁后,您即可轻松实现上述配置。 导入I2C演示项目作为起点 我们建议以 SDK 的 I2C 演示项目为集成起点,因为该项目已包含 SDK 所需的 I2C 驱动代码。以 RT1180 为例,我们导入:evkmimxrt1180_lpi2c_polling_b2b_master_cm33。 Kan_Li_1-1764229777439.png 然后排除板级文件,并改用 nano 软件包中的对应文件。 Kan_Li_2-1764229952040.png 接着导入 nano 软件包中的源文件, 2025-11-27_15-54-39.png 并加入示例代码,这里选择:ex_se05x_crypto.c和 main.c。 Kan_Li_1-1764230886605.png 添加如下定义用于 nano 软件包构建,以及包含路径。 Kan_Li_2-1764231224106.png Kan_Li_4-1764231910613.png 正在构建项目: Kan_Li_5-1764232010295.png 调试: Kan_Li_6-1764232173014.png Kan_Li_7-1764232273747.png Zephyr 集成: 集成比 SDK 集成简单得多,因为平台特定文件已经存在,用户只需手动添加 MIMXRT1180-EVK 的板覆盖文件。附加的覆盖文件应放在类似于“workspace/modules/crypto/nxp-plugandtrust/examples/se05x_crypto/zephyr/boards/”的文件夹中。 请注意:Zephyr 集成指南已在 https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rst 上发布,而测试的 Zephyr 版本仍停留在 v3.7.0,尚未支持 MIMXRT1180-EVK。为了支持 MIMXRT1180-EVK,我们必须使用最新的 Zephyr,并修改过 west.yml 文件。 以下是我们需要执行的步骤: $ rm workspace/ -rf $ mkdir -p workspace $ cd workspace/ $ git clone https://github.com/NXPPlugNTrust/nano-package.git //Edit ~/workspace/nano-package/zephyr/west.yml as below $ cd .. $ west init -m https://github.com/NXPPlugNTrust/nano-package.git --mf ~/workspace/nano-package/zephyr/west.yml ~/workspace/ $ cd workspace $ west update Kan_Li_0-1764233305101.png 版本示例: $ cd workspace/ $ west build -b mimxrt1180_evk/mimxrt1189/cm33 modules/crypto/nxp-plugandtrust/examples/se05x_crypto/zephyr/ --pristine 编程和运行:   Kan_Li_2-1764233550088.png 参考资料: [1]基于树莓派的 EdgeLock SE05x 快速入门指南 [2]i.MX RT1180 EVK 快速入门指南
View full article
Clock Measuring using the Signal Frequency Analyzer (SFA) module for KW45/KW47/MCXW71/MCXW72 Using the Signal Frequency Analyzer (SFA) to Measure the FRO 6M Frequency Overview The Signal Frequency Analyzer (SFA) is a specialized hardware peripheral available in NXP’s KW45, MCXW71, KW47, and MCXW72 microcontrollers. It is designed to provide precise, real-time measurement and analysis of digital signal characteristics, including frequency, period, and timing intervals. This makes it a valuable tool for applications requiring accurate timing diagnostics, signal validation, and system debugging. By utilizing internal 32-bit counters and configurable trigger mechanisms, the SFA enables high-resolution capture of signal transitions, supporting robust system monitoring and fault detection. Functional Capabilities of the SFA The SFA module supports the following measurements: Clock signal frequency of a Clock Under Test (CUT) Clock signal period It operates using two 32-bit counters: One for the Reference Clock (REF) One for the Clock Under Test (CUT) Measurement is performed by comparing the counts of both clocks until predefined target values are reached. FRO 6M Frequency Failure Scenarios The 6 MHz Free Running Oscillator (FRO6M) may occasionally output an incorrect frequency under certain conditions: When the device exits reset When the device wakes from low-power modes To mitigate potential issues caused by incorrect FRO6M output, it is the application developer’s responsibility to verify the oscillator’s frequency and apply corrective measures as needed. Monitoring the FRO 6M Using the SFA To monitor the FRO6M signal, the following configuration is recommended: SFA Configuration Parameters Reference Clock (REF): CPU Clock (e.g., 96 MHz) Clock Under Test (CUT): FRO6M routed via CLKOUT Interrupt Mode: Enabled for asynchronous measurement completion Code Implementation The presented functions are meant to be implemented in users application, the inner functions are part of the implementations of the SFA driver from the NXP’s SDK. It can be used on MCXW71, MCXW72, KW45, kKW47, just make sure SFA Peripheral Initialization  void init_SFA_peripheral(void) { /* Enable SFA interrupt. */ EnableIRQ(SFA_IRQn); /* Set SFA interrupt priority. */ NVIC_SetPriority(SFA_IRQn, 1); SFA_Init(DEMO_SFA_BASEADDR); SFA_InstallCallback(DEMO_SFA_BASEADDR, EXAMPLE_SFA_CALLBACK); } SFA Callback Function void EXAMPLE_SFA_CALLBACK(status_t status) { if (status == kStatus_SFA_MeasurementCompleted) { SfaMeasureFinished = true; } sfa_callback_status = status; } Frequency Measurement Function This function sets up the measurement of the FRO6M signal using the CPU clock as the reference. uint8_t SFA_freq_measurement_6M_FRO(void) { uint8_t ratio = 0; uint32_t freq = 0UL; sfa_config_t config; CLOCK_SetClkOutSel(kClockClkoutSelSirc); //set clokout to SIRC SFA_GetDefaultConfig(&config); //Get SFA default config config.mode = kSFA_FrequencyMeasurement0; config.refSelect = kSFA_REFSelect1; //Set CPU clk as ref clk config.cutSelect = kSFA_CUTSelect1; //Set clkout as CUT config.refTarget = 0xFFFFFFUL; config.cutTarget = 0xFFFFUL; config.enableCUTPin = true; freq = get_ref_freq_value(CPU_CLK); SFA_SetMeasureConfig(DEMO_SFA_BASEADDR, &config); SFA_MeasureNonBlocking(DEMO_SFA_BASEADDR); while (1) { if (SfaMeasureFinished) { SfaMeasureFinished = false; if(kStatus_SFA_MeasurementCompleted == sfa_callback_status) { freq = SFA_CalculateFrequencyOrPeriod(DEMO_SFA_BASEADDR, freq);//Calculate the FRO freq if(FREQ_6MHZ + TOLERANCE <= freq ) { ratio = 1; } else { if(FREQ_3MHZ + TOLERANCE <= freq) { ratio = 2; } else { if(FREQ_2MHZ + TOLERANCE <= freq) { ratio = 3; } else { ratio = 4; } } } break; } } else { __WFI(); } } return ratio; } Result Interpretation and Usage To test the FRO 6M after adding the above functions the FRO can be tested after executing: init_SFA_peripheral(); SFA_freq_measurement_6M_FRO(); The measured FRO6M frequency ratio is returned by the function SFA_freq_measurement_6M_FRO(), with the ratio you can know the current frequency output of the 6M FRO, ration 1 means 6M are being output by the FRO, ratio 2 means the frequency output of the FRO it's being cut in half meaning the FRO is outputting 3 Mhz, ration 3 means the FRO output frequency is being cut by a third part, this results in 2MHz frequency output. With this information you can: Adapt peripheral clocking if the FRO6M frequency is incorrect (This can be achieve by modifying the peripheral dividers if dividers are being used). Trigger corrective actions such as  switching to an alternate clock source Steps to Reconfigure Peripheral Clocking When FRO6M output frequency is lower Detect the Faulty FRO6M Output Use the SFA measurement as described earlier to determine if the FRO6M is operating below its expected frequency (6 MHz). If the result is significantly lower, proceed to reconfigure. Choose an Alternative Clock Source Most NXP MCUs offer multiple internal and external clock sources. Common alternatives include: FRO 192M OSC RF 32M Sys OSC RTC OSC Choose one that is: Stable Available in your current power mode Compatible with the peripheral’s timing requirements You can add more clock divers if needed to make a higher frequency clock reach a certain lower frequency. Reconfigure the Peripheral Clock Source Use the SDK’s CLOCK_Set... APIs to change the clock source. You may also need to: Adjust dividers to match the required baud rate or timing Reinitialize the peripheral with the new clock settings Example Scenario: Measuring the FRO and Adjusting UART Based on Frequency Ratio Imagine your application relies on the 6 MHz Free Running Oscillator (FRO), and its accuracy directly affects UART communication. To ensure reliable operation, you can use the System Frequency Adjustment (SFA) feature to monitor the FRO output and dynamically adjust the UART configuration. After measuring the 6 MHz FRO using the recommended method, the system returns a frequency ratio value. This value ranges from 1 to 4, where: 1 indicates the frequency is within expected limits (no issues), 2 to 4 represent varying degrees of deviation from the expected frequency. Using this ratio, you can initialize and configure the UART peripheral and its driver to compensate for any frequency variation, ensuring stable and accurate communication. */ int main(void) { BOARD_InitHardware(); uint8_t ch = 0; uint8_t FRO_ratio = 0; init_SFA_peripheral(); /*Measure FRO6M output frequency*/ FRO_ratio = SFA_freq_measurment_6M_FRO(); /*Init debug console and compensate in case a different frequency is output */ if(0 == FRO_ratio) { assert(0);//this user defined return value means something went wrong while measuring 6Mz FRO } uint32_t uartClkSrcFreq = BOARD_DEBUG_UART_CLK_FREQ/FRO_ratio;//Compensate the src frequency set for uart module CLOCK_EnableClock(kCLOCK_Lpuart1); CLOCK_SetIpSrc(kCLOCK_Lpuart1, kCLOCK_IpSrcFro6M); DbgConsole_Init(BOARD_DEBUG_UART_INSTANCE, BOARD_DEBUG_UART_BAUDRATE, BOARD_DEBUG_UART_TYPE, uartClkSrcFreq); ...... } SDK 25.0.00 Enhancements for FRO6M Calibration To address known reliability issues with the 6 MHz Free Running Oscillator (FRO6M), particularly during transitions from low-power modes, SDK version 25.06.00 introduces a set of software enhancements aimed at improving oscillator validation and calibration. Key Features Introduced FRO6M Calibration API Two new functions have been added to facilitate runtime verification of the FRO6M frequency: PLATFORM_StartFro6MCalibration() Initializes the calibration process by enabling the cycle counter, capturing a timestamp, and preparing the system to measure elapsed time using both the CPU and the FRO6M-based timestamp counter. PLATFORM_EndFro6MCalibration() Completes the calibration by comparing the time measured via CPU cycles and the FRO6M timestamp counter. This comparison determines whether the oscillator is operating at the expected 6 MHz or has erroneously locked to a lower frequency (e.g., 2 MHz). The result is stored in a global ratio variable (fwk_platform_FRO6MHz_ratio) for use by the system. These functions provide a lightweight and efficient mechanism to detect and respond to oscillator misbehavior, ensuring system stability and timing accuracy. Configuration Macro gPlatformEnableFro6MCalLowpower_d This macro enables automatic FRO6M frequency verification upon exiting low-power modes. When defined, the system will invoke the calibration functions to validate the oscillator before resuming normal operation. Default Integration The calibration mechanism is enabled by default in the SDK configuration file fwk_config.h, ensuring that all applications benefit from this safeguard without requiring manual setup. Use Case and Benefits These enhancements are particularly valuable in applications where: Precise timing is critical (e.g., wireless communication, sensor sampling). The system frequently enters and exits low-power states. Clock source integrity must be guaranteed to avoid peripheral misbehavior or timing faults. By integrating these calibration routines, developers can proactively detect and correct FRO6M frequency anomalies, improving overall system robustness and reducing the risk of runtime errors due to clock instability.
View full article
TCP Client & Server Implementation on MCUXrpesso SDK --- part I--using LwIP Netconn API Introduction TCP Client & Server establishes a two-way connection between a server and a client. It is the most common communication model used by applications such as HTTP, Telnet, FTP, SSH and others LwIP is a free light-weight TCP/IP stack in MCUXpresso SDK. It has three application programming interfaces (API): RAW API:  it is the native API of LwIP. It enables the development of applications using event callbacks. Netconn API:  it is a high level sequential API that requires the services of a real-time system (RTOS), The Netconn API enables multi-threaded operations BSD Socket API: it is developed on top of the Netconn API. In this article, I will introduce how to implement a TCP client & Server demo with LwIP Netconn API.  One EVK-RT1060 acts as TCP server, and others boards act as TCP clients.  They are connected through an Ethernet router.  They communicate via TCP protocol. If you press SW8 on the client board, it will toggle a LED on the Server board. danielchen_0-1635259175564.png This article is for beginners to understand the Netconn API on NXP MCUXpresso SDK. 2. Hardware configuration PHY settings: In this demo, we use phyksz8081, that is the default PHY in EVK-RT1060 board.  ENET port 0. /*! @brief The ENET PHY address. */ #define BOARD_ENET0_PHY_ADDRESS (0x02U) /* Phy address of enet port 0. */ /* Address of PHY interface. */ #define EXAMPLE_PHY_ADDRESS BOARD_ENET0_PHY_ADDRESS /* MDIO operations. */ #define EXAMPLE_MDIO_OPS enet_ops /* PHY operations. */ #define EXAMPLE_PHY_OPS phyksz8081_ops /* ENET clock frequency. */ #define EXAMPLE_CLOCK_FREQ CLOCK_GetFreq(kCLOCK_IpgClk) Configure the external PHY, pull up the ENET_INT before RESET.     GPIO_PinInit(GPIO1, 9, &gpio_config);     GPIO_PinInit(GPIO1, 10, &gpio_config);     /* pull up the ENET_INT before RESET. */     GPIO_WritePinOutput(GPIO1, 10, 1);     GPIO_WritePinOutput(GPIO1, 9, 0);     delay();     GPIO_WritePinOutput(GPIO1, 9, 1); MAC settings: In this demo, MAC address is defined in Macro configMAC_ADDR /* MAC address configuration. */ #define configMAC_ADDR                     \     {                                      \         0x02, 0x12, 0x13, 0x10, 0x15, 0x11 \     }  3. Starting a network interface To create a new network interface, the user allocates space for a new struct netif (but does not initialize any part of it) and calls netifapi_netif_add:     IP4_ADDR(&fsl_netif0_ipaddr, configIP_ADDR0, configIP_ADDR1, configIP_ADDR2, configIP_ADDR3);     IP4_ADDR(&fsl_netif0_netmask, configNET_MASK0, configNET_MASK1, configNET_MASK2, configNET_MASK3); IP4_ADDR(&fsl_netif0_gw, configGW_ADDR0, configGW_ADDR1, configGW_ADDR2, configGW_ADDR3);     netifapi_netif_add(&fsl_netif0, &fsl_netif0_ipaddr, &fsl_netif0_netmask, &fsl_netif0_gw, &fsl_enet_config0,                        ethernetif0_init, tcpip_input); Pass tcpip_input API to netif_add API as input callback function that is called to pass ingress packets up in the protocol layer stack next we need to bring the interface up An interface that is “up” is available to your application for input and output, and “down” is the opposite state. Therefore, before you can use the interface, you must bring it up. This can be accomplished depending on how the interface gets its IP address.  We can use static IP address  or DHCP. Set the network interface as the default network interface netifapi_netif_set_default(&fsl_netif0); Bring the interface up, available for processing     netifapi_netif_set_up(&fsl_netif0); 4. LwIP Initialization Call tcpip_init to create a tcpip_thread, this thread has exclusive access to LwIP core functions. Other threads communicate with this thread using message boxes. It also starts all the timers to make sure they are running in the right thread context. tcpip_init(NULL, NULL); 5. TCP Client & Server Implementation For TCP communications, one host listens for incoming connection requests. When a request arrives, the server accepts it and data is transferred between the server and the client. The sequence of function calls for the client and a server participating in a TCP connection is show in below picture. danielchen_1-1635259600410.png The steps for establishing a TCP connection on the client side are the following: Create a netconn using the netconn_new() function. Connect the connection to the address of the server using the netconn_connect() function. Send and receive data by means of the netconn_recv() and netconn_send() functions. Close the connection by means of the netconn_close() function. The steps in establishing a TCP connection on the server side are as follows Create a connection with netconn_new() function; Bind the connection to an address using the netconn_bind() function. Listen for connections with the netconn_listen() function. Accept a connection with the netconn_accept() function, this blocks until a client connects. Send and receive data by means of netconn_send() and netconn_recv(). Close the connection by means of the netconn_close() function. 5.1 TCP SERVER IMPLEMENTATION netconn_new() is used to create a new connection.   conn = netconn_new(NETCONN_TCP); netconn_bind() binds a connection to a local IP address and port.   netconn_bind(conn, IP_ADDR_ANY, TCP_CUSTOM_PORT); netconn_listen() function sets a TCP connection into a listening TCP connection.   /* Tell connection to go into listening mode. */   netconn_listen(conn); netconn_accept() function accepts an incoming connection on a listening TCP connection.    err = netconn_accept(conn, &newconn); netconn_recv() function receives a message from a netconn. netconn_send() function sends data to the currently connected remote IP/Port. In this demo, if server board receives a ‘TOGGLE’ message from the client board, it will toggle a LED. (GPIO1/3,  need to connect a LED manually)           while ((err = netconn_recv(newconn, &buf)) == ERR_OK) {         PRINTF("Received  %s\n", buf->p->payload);         do {              netbuf_data(buf, &data, &len);              tcp_rx_buf = (void *)data;              if (tcp_rx_buf[0] == 'T')              {                  PRINTF("LED was toggled from client\r\n");                 GPIO_PortToggle(EXAMPLE_LED_GPIO, 1u << EXAMPLE_LED_GPIO_PIN);                 netconn_write(newconn, TcpReply, sizeof(TcpReply) , NETCONN_COPY );              }         } while (netbuf_next(buf) >= 0);         netbuf_delete(buf);       } //end of while(( err   5.2 TCP CLIENT IMPLEMENTATION For the client side, the netconn structure is created:   conn = netconn_new(NETCONN_TCP); netconn_connect():  when a user issues a connect command, the stack creates a connection with another host. Before connect can instruct the stack to establish a connection, the user must pass a netconn and a sockaddr_in structure containing the destination IP address and port. In TCP, the handshaking packets will be exchanged.   memset(&server_addr, 0, sizeof(server_addr));   server_addr.sin_family = AF_INET;   server_addr.sin_port = PP_HTONS(TCP_CUSTOM_PORT);   server_addr.sin_addr.s_addr = server_ip_addr.addr;   err = connect(client_sock, (struct sockaddr *)&server_addr, sizeof(server_addr));   LWIP_ASSERT("connect fail, please start TCP server first !  ",  err == 0); In this demo, a GPIO is initialized and interrupt is enabled. When SW8 is pressed, the client board will send ‘Toggle’ command to the TCP server.   while (1)   {       if (g_InputSignal)       {           delay();           if (1 == GPIO_PinRead(EXAMPLE_SW_GPIO, EXAMPLE_SW_GPIO_PIN))           {               PRINTF("%s is turned on.\r\n", EXAMPLE_SW_NAME);               err = send(server_sock, Sendtext, sizeof(Sendtext) / sizeof(Sendtext[0]), 0);           }           /* Reset state of switch. */           g_InputSignal = false;       }  //end of if (g_InputSignal)   }  
View full article
Keil MDK/uVision を使用したデモの実行 CMSISデバイス・パックのインストール MDK ツールをインストールした後、デバッグの観点からデバイスを完全にサポートするには、Cortex ®マイクロコントローラ ソフトウェア インターフェイス標準 (CMSIS) デバイス パックをインストールする必要があります。これらのパックには、メモリ マップ情報、レジスタ定義、フラッシュ プログラミング アルゴリズムなどが含まれています。適切な CMSIS パックをインストールするには、次の手順に従います。MDK-Arm マイクロコントローラ開発キット (Keil) ®バージョン 5.38.1 以上を使用してください。 µVision と呼ばれる MDK IDE を開きます。IDE内で「Pack Installer」アイコンを選択します Sabina_Bruce_0-1767115848769.png パック インストーラー ウィンドウで、「MCXW」を検索して、MCXW71 ファミリを起動します。MCXW7XX の名前をクリックすると、右側に NXP が表示されます。  MCXW71_DFP  パック。パックの横にある「インストール」ボタンをクリックします。このプロセスを正常に完了するにはインターネット接続が必要です インストールが完了したら、[Pack Installer(パック・インストーラ)]ウィンドウを閉じて、µVision IDEに戻ります サンプル・アプリケーションのビルド 以下の手順に従って、  hello_world  応用。一部のアプリケーションではパス内に追加のフォルダー層が存在する可能性があるため、他のサンプル アプリケーションではこれらの手順が若干異なる場合があります。 目的のデモ・アプリケーション・ワークスペースをまだ開いていない場合は以下で開きます。 /boards/ / / /mdk デバッグ構成を選択 Sabina_Bruce_1-1767115880908.png プロジェクトを右クリックして、プロジェクト オプションを選択します。 Sabina_Bruce_2-1767115902529.png 次に、デバッグ オプションに移動し、CMSIS-DAP ARMv8-M デバッガーを選択します。OKボタンをクリックします Sabina_Bruce_3-1767115924146.png デモプロジェクトをビルドするには、赤くハイライトされた「リビルド」ボタンを選択します。 Sabina_Bruce_4-1767115960650.png ビルドが正常に完了します
View full article
i.mx93 上の m33 コアに対する OpenAMP サポート おい、 この質問は既にここで聞かれていると思います 解決済み: Re: i.mx93 上の m33 コアに対する RPMsg サポート - NXP コミュニティ しかし、私は受け入れられた答えを理解していません。NXP のリアルタイム エッジ ソフトウェア フレームワークでは、RPSMG サポートは FreeRTOS に対してのみリストされています。 ただし、i.mx95 A7 コアは最近すでに追加されていますhttps://github.com/zephyrproject-rtos/zephyr/pull/86923 私の質問は、NXP が m33 のサポートも追加する予定があるかどうかです。そうでない場合、手動でサポートを追加するには何が必要ですか? Re: OpenAMP support for m33 core on i.mx93 Linux (A コアで実行) と Zephyr (M33 コアで実行) 間のコア間通信を有効にするには、Zephyr のopenamp_rsc_tableサンプルを出発点とすることをお勧めします。 このサンプルでは以下を活用しています: - Zephyr 上の OpenAMP - Linux上のremoteprocとrpmsg 前提条件 Linuxのセットアップ Linux BSP: NXP の公式 BSP を使用しますhttps://github.com/nxp-imx/linux-imx/tree/lf-6.12.y デバイスツリー: `-rpmsg` バリアントを使用します。例:imx93-11x11-evk-rpmsg.dts U-Boot: Linux を起動する前に `prepare_mcore` を実行する Zephyr セットアップ(M33 コア) openamp_rsc_table サンプルを正常に実行するには、DTS オーバーレイの `zephyr,ipc_shm` プロパティを使用して、ホスト コアとリモート コア間の共有メモリを定義する必要があります。 次に、 nxp_imx93_m33.dtsiに MU ノードを追加します。 「」 mu1: mu1@44220000 { 互換性 = "nxp、imx-mu"; reg = <0x44220000 DT_SIZE_K(64)>; 割り込み = <21 0>; }; 「」 次に、リンカー スクリプトを更新し、`linker.ld` にリソース テーブル セクションを追加します。 「」 #定義されている場合(CONFIG_OPENAMP_RSC_TABLE) セクション { SECTION_PROLOGUE(.resource_table,,サブアライン(8)) { KEEP(*(.resource_table*)) } GROUP_LINK_IN(ROMABLE_REGION) } #endif 「」 i.MX93の設定調整 i.MX93 の RX および TX ID は他のボードとは異なります。`.conf` オーバーレイ ファイル内のデフォルト値を上書きする必要があります。 「」 CONFIG_IPM_IMX_MAX_DATA_SIZE_16=n CONFIG_IPM_IMX_MAX_DATA_SIZE_4=y CONFIG_OPENAMP_WITH_DCACHE=y CONFIG_LOG=y CONFIG_OPENAMP_RSC_TABLE_IPM_RX_ID=1 CONFIG_OPENAMP_RSC_TABLE_IPM_TX_ID=0 「」 サンプルPR https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards https://github.com/zephyrproject-rtos/zephyr/pull/86923 https://github.com/zephyrproject-rtos/zephyr/pull/79220/commits Linuxパッチ要件 i.MX93 で適切に動作させるには、次の Linux パッチを適用してください: https://lore.kernel.org/imx/CAEnQRZDoYvK-YXLjqbXsRAWDkHrWNOoR1OCCWxs+AfNUDuPB_w@mail.gmail.com/T/ 実行前の最終ステップ アプリケーションを起動する前に: U-Boot で `prepare_mcore` を実行します。 `-rpmsg` デバイス ツリー BLOB を使用します。 アプリケーションノート AN5317の手順に従ってください。 関連リソース i.MX Linux ユーザーガイド - https://www.nxp.com/docs/en/user-guide/UG10163.pdf アプリケーションノート AN5317 - https://www.nxp.com/docs/en/application-note/AN5317.pdf remoteproc、rpmsg、mailbox、OpenAMP フレームワークの詳細。DTS および構成オーバーレイを作成する方法の例が含まれています。これはi.MX 8M PlusのHiFi4コアの例であることに注意してください。 https://www.youtube.com/watch?v=JqwPljnm2_k&t=14s DTS API、`zephyr,ipc_shm` 上 - https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/build/dts/api/api.rst?plain=1#L421 Re: OpenAMP support for m33 core on i.mx93 すべての Zephyr IPC サポートはここにあります (メイン プロセッサ上の Linux カーネル OS とコプロセッサ上の Zephyr アプリケーション) https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards 社内チームから確認したところ、現時点では MPU cm33 をサポートする予定はありません。 ただし、お客様の要件を社内チームに送信しましたので、更新があればお知らせいたします。 それは申し訳ありません。
View full article
KW43 Knowledge Hub The KW43 product family is a low-power, secure, single-chip wireless MCU that integrates a high performance, Bluetooth Low Energy, Bluetooth Channel Sounding, EdgeLock Secure Accelerators, and various MCU peripherals targeted for Automotive applications. The KW43 family utilizes an Arm® Cortex®-M33 core (Armv8-M architecture) running up to 96 MHz for customer applications. The family includes memory configurations of up to 1.5MB flash and 256 KB SRAM across all listed part numbers. All devices in the family integrate a state-of-the-art, scalable security architecture including Arm’s TrustZone®-M, a resource domain controller and an isolated EdgeLock Secure Accelerators supporting hardware cryptographic accelerators, random number generators and key generation, storage, and management along with secure debug. All members of the KW43 family are designed to be compliant to a SESIP Level 3 certification following the Arm PSA Level 3 profile. KW43 uses dual Arm Core Cortex-M33 (‘CM33’) and supports multiple interfaces and security features. One is for application and system use and other is for radio link layer and both cores share a common flash of 1.5 MB. The devices include a full certified Bluetooth LE 6.x controller stack with support for up to 10 simultaneous connections in any controller/peripheral combination. The multiprotocol radio subsystem integrated in the KW43 Family is energy efficient and is designed for Wi-Fi coexistence. The radio is supported with tested software stacks for Bluetooth Low Energy for standalone and hosted applications to enable a range of Automotive, IoT and industrial applications. There is also software and hardware support for 2.4 GHz proprietary protocols. To address ranging requirements, the Localization Engine (LCE) is integrated into the system for enhanced localization performance. The KW43 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. Early access program The KW43 is in pre-production, developers can get started today with the KW45/KW47, which is pin and software compatible.   you can request access contacting NXP sales team - Pascal Bernard ([email protected]) Join KW47 early access program here: KW43 Early Access Training Bluetooth Low energy 6.0 NXP Introduction 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.  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 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 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.  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.
View full article
无法在 i.MX 8M Plus EVK 上将 OV5640 路由至 ISP(仅适用于 ISI) 你好, 我正在使用 imx8M Plus EVK 和 OV5640 MIPI-CSI2 摄像头模块(MIPI-CSI 摄像头模块),正在尝试使用集成的 isp 来代替 ISI。 现在,传感器在路由到 ISI 时可以正常工作(我可以通过 /dev/VideoX 捕获 UYVY/NV12),但我想将拜耳的原始数据提供给 SoC 互联网服务提供商,然后从 ISP 视频节点获得经过处理的输出(demasic、AWB 等)。我在媒体/格式方面遇到困难,希望能得到指导,了解实际支持哪些格式,以及如何正确配置管道。 我想禁用 ISI 改用 ISP 管道: 我使用 imx8mp-lpddr4-evk 作为版本配置,使用 imx-image-full 作为 Yocto Project 映像。 Re: Unable to route OV5640 to ISP on i.MX 8M Plus EVK (works only with ISI) 你好 根据您的要求,您需要将 OV5640 的 RAW Bayer 数据通过 SoC 的 ISP 传输,而不是使用 ISI 模块。以下是你面临挑战的原因: i.MX 8M Plus 有两个不同的摄像头接口: 1. ISI(图像感知接口):对 YUV/RGB 格式执行基本处理(缩放、裁剪、翻转、色彩空间转换) 2. ISP(图像信号处理器):处理 RAW 拜耳数据处理(demosaic、AWB 等) 目前,您的 OV5640 配置为使用其内置 ISP 并将 YUV/RGB 数据直接输出到 ISI 模块,这就是为什么你可以通过 /dev/videoX 捕获 UYVY/NV12 的原因。不过,要使用 SoC 的 ISP 功能,您需要不同的配置。 要将原始拜耳数据路由到 SoC ISP,请执行以下操作: 1. 修改您的设备树以禁用 ISI 并启用 OV5640 2. 将 OV5640 配置为输出 RAW 拜耳格式,而不是经过处理的 YUV 3. 安装 ISP 管道以进行正确处理 作为实现参考,您可以查看演示 RAW 摄像机移植到 ISP 的 GitHub 存储库:https://github.com/nxp-imx-support/meta-imx8mp-isp-imx219 还有一个社区帖子涉及类似的集成挑战: https://community.nxp.com/t5/Other-NXP-Products/Integrating-OV5695-RAW10-with-ISP-on-i-MX8MP-ISP-Enablement-and/td-p/2115003 ISP 模块需要特定于传感器的校准文件(.drv、.xml、.cfg)以优化 OV5640 在 RAW 模式下的性能。 此致
View full article
从 STM32Cube IDE 到 MCUXpresso IDE 移植ST应用程序 本节概述了使用恩智浦目标MCU的兼容SDK将在STM32Cube IDE中开发的应用迁移到恩智浦MCUXpresso IDE的过程。 对于熟悉STM32Cube IDE的用户来说,保持类似的开发环境可以简化过渡并降低学习曲线。在本例中,最初为STM32设备开发的I2C应用将重新创建并适配恩智浦MCU。 要完成迁移,首先应在MCUXpresso IDE中创建包含必要I2C驱动程序的最小项目。原始ST应用使用两个I2C实例实现同一块开发板中元器件间的通信。要复制此功能,必须初始化两组I2C引脚。此外,该应用使用按钮输入和LED输出来演示行为变化,需要借助MCUXpresso引脚配置工具配置相应的GPIO。 要开始迁移,原ST项目的主源文件以及任何不属于标准ST驱动集的自定义源文件应被整合进新的NXP项目中。 以下步骤概述了MCUXpresso IDE中的初始项目设置: 选择“创建新的C/C++项目”。 选择目标MCU(例如,MCXA156)。 单击“下一步”。 展开驱动程序部分。 选择 I2C。 单击“下一步”。 单击“完成”。 项目创建时会包含一个基本的“Hello World”示例。此模板可用作起点。主源文件中的所有内容(除初始宏定义外)可以逐步替换以集成应用逻辑,从而实现模块化且受控的迁移过程。 Sabina_Bruce_1-1763569353713.png 下一步是将原始ST项目中的主源文件传输到新创建的MCUXpresso项目中。在此过程中,除非需要自定义头文件,否则将包含标准ST和驱动程序引用。此时不会使用自定义标头,因此仅迁移核心应用逻辑。 ST源文件中的许多函数调用都依赖于STM32特定的HAL API。请对这些功能进行审查,并使用恩智浦SDK中的同等功能进行替换。此方法包括分析main()例程中的每个函数以理解其目的,然后利用恩智浦环境中的相应实现进行替换。   Sabina_Bruce_2-1763569353730.png ST项目功能快速概览: 中断优先级配置 配置微控制器的中断系统,以便在多个中断同时发生时管理优先级。 电源外设时钟实现 激活电源(PWR)外设的时钟,这是配置电源管理设置的前提条件。 电源管理设置 初始化STM32U5xx微控制器的电源管理功能,以优化内部元器件的能效和性能。 系统时钟配置 设置微控制器的定时系统,将其配置为以160MHz的频率运行。 外设初始化 确定外设的引脚配置和功能设置。在此应用中,I2C1会配置为从机,I2C3则配置为主机。 LED初始化 将LED配置为低电平有效状态,并开启LED以指示初始状态或通信反馈。 GPIO轮询按钮按下 持续监测GPIO输入引脚的状态。如果未按下按钮,LED将快速闪烁。按下按钮后,环路会退出,LED则保持点亮状态。 I2C通信启动 从主端发起I2C通信流程,触发两个I2C接口间的数据传输。 恩智浦SDK如何处理这一流程? 中断优先级配置 此功能由CMSIS核心NVIC功能支持,且可直接重复使用。它需要定义宏来确定所需的抢占优先级。 时钟与电源配置 这些功能都会整合至BOARD_InitBootClocks函数(位于开发板文件夹的clock_config.c下)。此函数可初始化恩智浦MCU的系统时钟和电源设置。 外设和引脚初始化 外设设置分为两个函数: BOARD_InitBootPins(位于pin_mux.c中)负责处理I2C和GPIO的引脚配置。 BOARD_InitBootPeripherals(位于peripherals.c中)则负责管理I2C外设初始化和GPIO中断设置。 LED 初始化 GPIO 引脚可根据所需的初始状态配置为高电平或低电平输出。可以使用 GPIO_PinWrite 来切换或设置 LED。 GPIO轮询按钮按下 此行为可以借助自定义轮询函数来复制,该函数利用GPIO_PinRead监测按钮状态。 I2C通信开始 I2C主通信通过LPI2C_MasterStart启动,开始与指定从设备的数据传输过程。 使用时钟配置工具解决时钟初始化问题 MCUXpresso IDE包含集成的配置工具,可通过项目浏览器从界面右上角的下拉菜单中选择相应选项进行访问。 Sabina_Bruce_3-1763569353733.png 要配置系统时钟,请在 MCUXpresso IDE 中打开 Clocks 工具。 时钟图显示了所选 MCU 支持的配置。在此示例中,设备的最大核心时钟频率为 96 MHz。由于这符合应用程序的要求,因此不需要修改默认时钟设置。 Sabina_Bruce_4-1763569353743.png 要启用I2C实例的外设时钟,请在MCUXpresso配置工具中导航至时钟配置图。滚动浏览图表以定位可用的外设,并选择适当的时钟源来激活I2C模块。 Sabina_Bruce_5-1763569353757.png 要配置I2C0和I2C3外设的时钟源,请双击时钟配置图中与每个实例关联的CLKSEL字段。在此设置中,请选择FRO_HF_DIV作为I2C0和I2C3的时钟源。 Sabina_Bruce_6-1763569353761.png 接下来,在时钟配置图中选择相应的字段以配置时钟分频器。详细信息将显示在界面的右上角面板中。要启用通往I2C外设的时钟路径,请确保选择 “分频器时钟正在运行” 选项。 Sabina_Bruce_7-1763569353764.png 此时,I2C外设时钟已成功启用。 Sabina_Bruce_8-1763569353777.png 要应用配置更改并将其集成到项目中,请点击“更新代码”。此操作将生成相应的源文件,并确保新设置反映在项目结构中。 使用引脚配置工具解决引脚初始化问题 MCUXpresso IDE 包含集成的配置工具,可通过项目浏览器从界面右上角的下拉菜单中选择相应选项进行访问。 Sabina_Bruce_9-1763569353780.png 要开始配置I2C引脚,请从MCUXpresso IDE的配置工具菜单中选择“打开引脚”。 利用筛选功能,搜索与I2C实例0兼容的可用引脚。在查看开发板原理图后,选择P0_16和P0_17引脚,因为这两个引脚可以通过标头访问。在配置选项中选择LPI2C0:SDA和LPI2C0:SCL,为这些引脚分配相应的I2C功能。 Sabina_Bruce_10-1763569353815.png 重复I2C实例3的配置过程。根据开发板电路图,为此实例选择引脚P3_27和P3_28。在引脚配置工具中选择LPI2C3:SDA和LPI2C3:SCL来分配相应功能。 Sabina_Bruce_11-1763569353825.png 一旦选择了引脚,就会生成一个配置表,显示每个引脚的布线和设置。根据此表中的布线详情,按需配置引脚。对于I2C引脚,启用内部上拉电阻,以确保通信过程中信号的完整性。 Sabina_Bruce_12-1763569353838.png 除了配置I2C引脚外,还需要安装两个GPIO引脚——一个用于输入,一个则用于输出。在此开发板中, SW2 (P1_7)指定为按钮输入功能,而P3_0则指定为LED输出。 Sabina_Bruce_13-1763569353842.png Sabina_Bruce_14-1763569353845.png 在引脚配置表的路由详情中,定义输入和输出GPIO的行为。根据应用需求,输出引脚应初始化为逻辑低电平状态(选择逻辑0)以激活LED。对于输入引脚,在下降沿启用中断检测以准确记录按钮按下操作。 Sabina_Bruce_15-1763569353848.png 要完成配置并将更改集成到您的项目中,请点击“更新代码”。此操作将生成必要的源文件,并将所选设置应用于项目结构。 使用外设配置工具解决外设初始化问题 MCUXpresso IDE包含集成的配置工具,可通过项目浏览器访问。要启动这些工具,请使用位于界面右上角的下拉菜单。 Sabina_Bruce_16-1763569353851.png 要开始外设配置,请在MCUXpresso IDE的配置工具菜单中选择 “打开外设” 。 在此视图中,重点是初始化每个实例的GPIO和I2C设置。要继续操作,请选择“外设驱动程序”以访问目标设备支持的驱动程序列表 Sabina_Bruce_17-1763569353857.png GPIO1 配置 要筛选可用的外设选项,请在外设驱动程序视图的搜索栏中输入“GPIO”。显示相关选项后,点击“确定”以继续进行GPIO配置。 Sabina_Bruce_18-1763569353865.png 要启用分配给按钮输入的P1_7 的中断功能,首先要选择一个新的外设驱动程序。使用过滤器搜索GPIO,然后选择适当的驱动程序激活GPIO1 中断处理程序。 Sabina_Bruce_19-1763569353875.png I2C3主机/主设备配置 要配置I2C外设,请在外设驱动程序视图的搜索栏中输入“I2C”来筛选可用选项。显示相关驱动程序后,为您的应用选择合适的驱动程序,然后点击“确定”以继续操作。 Sabina_Bruce_20-1763569353885.png 将I2C3配置为主设备(主机),并启用中断驱动的数据传输。此设置允许I2C3实例发起通信并通过中断机制处理数据传输,以提高响应速度和效率。 Sabina_Bruce_21-1763569353900.png 此外,启用 I2C3 外设的中断处理程序。配置相应的优先级并激活传输数据就绪标志,以支持中断驱动的数据传输。 Sabina_Bruce_22-1763569353910.png I2C0从机/从设备配置 要配置I2C从机外设,请在外设驱动程序视图的搜索栏中输入“I2C”来筛选可用的驱动程序。显示相关驱动程序后,选择合适的驱动程序,然后点击“确定”以继续进行配置。 Sabina_Bruce_23-1763569353920.png 将I2C0配置为从设备(从机)。启用中断驱动的传输方式,并指定用于通信的从设备地址。此设置允许I2C0实例响应主设备请求,并通过中断处理数据接收。 Sabina_Bruce_24-1763569353944.png 此外,启用I2C0外设的中断处理程序。配置适当的优先级,验证分配的从机地址,并激活接收数据就绪标志,以支持中断驱动的数据接收。 Sabina_Bruce_25-1763569353954.png 要应用配置的设置并将其集成到项目中,请点击 “更新代码”。此操作将生成必要的源文件,并确保所有外设和引脚配置都反映在项目结构中。 配置工具生成的文件 MCUXpresso配置工具会根据所选设置自动生成源代码,从而简化与主应用的集成。生成的代码包括在前几个步骤中配置的时钟、引脚和外设的初始化例程。所有生成的文件都会放入项目结构的开发板目录下。 Sabina_Bruce_26-1763569353958.png board.c 使用恩智浦开发板创建项目时,默认配置包括调试UART引脚的初始化以实现串行终端通信。在这种情况下,无需使用UART功能以及board.c中的对应函数。 clock_config.c 此文件包含所有系统时钟配置。使用BOARD_InitBootClocks函数来初始化时钟频率和电源模式设置。对于此应用,系统会配置为以96MHz的频率运行。 peripherals.c 此文件包含通过配置工具配置的外设初始化代码。在本例中,它包含I2C实例和GPIO中断的设置例程。虽然可以使用BOARD_InitPeripherals函数,但有选择性地将生成的代码集成到应用的特定位置,以匹配所需的执行顺序,往往更为有效。 pin_mux.c 该文件可定义为应用选择的所有引脚配置,包括I2C和GPIO分配。虽然默认情况下包含UART引脚,但本项目中并未使用这些引脚。使用BOARD_InitBootPins函数应用引脚设置。 此外,原始ST应用包含缓存初始化函数(MX_ICACHE_Init)。在恩智浦SDK中,缓存配置由启动代码处理。具体信息可通过设备文件夹下system_MCU.c中的SystemInit函数查看。 替换初始化函数 Sabina_Bruce_41-1763577157030.png 时钟和引脚初始化 在恩智浦项目的主函数中,系统时钟和引脚配置使用配置工具生成的函数进行初始化: BOARD_InitBootClocks BOARD_InitBootPins 外设初始化 外设初始化代码来源于peripherals.c文件(该文件由配置工具生成)。第一段代码可设置GPIO中断处理程序,包括其优先级和NVIC配置。 随后,对I2C主设备和从设备实例及其对应的中断处理程序和优先级进行初始化。在此阶段,中断标志尚未启用;它们将在数据传输函数内部稍后激活,以确保正确的执行顺序并避免过早触发中断。 peripherals.c文件中包含一个代码片段,专门用于初始化LPI2C0外设以进行从设备操作。这段代码可以选择性地集成到主函数或应用内的其他适当位置,以匹配所需的执行流程。 Sabina_Bruce_28-1763569353988.png 虽然MCUXpresso IDE中的配置工具能够有效生成必要的初始化代码,但开发人员仍应负责确定此代码在应用中最合适的位置。这一决策应依据所实现的特定协议或外设所需的操作顺序来指导。 例如,在I2C通信中,数据传输通过中断进行管理。如果在使用LPI2C0_Init函数时不考虑时序,中断可能会过早触发,导致事务不完整或管理不善。 为确保正确执行,建议的顺序如下: 初始化外设及其相关的中断处理程序。 启动I2C事务。 启用主设备和从设备操作的中断。 在此应用中,初始化在main()函数内执行,中断标志则在稍后的Handle_I2C_Master函数中选择性启用,以保持正确的时序和控制。 Sabina_Bruce_29-1763569353999.png 替换操作函数 Sabina_Bruce_43-1763577293016.png SYSTICK初始化 SYSTICK定时器会配置为支持应用内的延迟操作,例如控制LED闪烁率。有关初始化SYSTICK的详细说明,请参阅以下小节。 按钮轮询和LED控制 此功能是通过一个自定义函数实现的,该函数会不断轮询按钮输入。在等待用户交互时,LED会切换以显示准备就绪。按下按钮后,LED保持稳定亮起,提示进入I2C数据传输阶段。 I2C主设备处理 Handle_I2C_Master函数通过恩智浦SDK中为I2C外设提供的驱动程序API实现。此函数可启动I2C事务并管理通信序列。 主设备和从设备I2C实例的中断处理程序均来自外设初始化代码。在此阶段,相关中断标志会选择性启用,以支持应用所需的具体行为。 WaitForUserButtonPress函数 要开始自定义GPIO中断处理程序,请在MCUXpresso IDE中打开外设配置工具。然后,你可以复制GPIO自动生成的IRQ处理程序,作为可靠的起点。然后可以修改此代码以满足您应用程序的特定要求。 Sabina_Bruce_31-1763569354026.png 配置完外设后,点击位于 MCUXpresso IDE 右上角的 “开发” 按钮,返回代码编辑器。在开发环境中,将复制的 IRQ 处理程序代码粘贴到主源文件中——最好放在顶部——以便更容易访问和组织。 Sabina_Bruce_32-1763569354031.png 已进行修改,在while循环中加入控制变量,确保此应用能够暂停执行,直至检测到按钮按下。此操作可确保程序仅在用户交互后才能继续进行,以匹配应用的预期流程。 Sabina_Bruce_33-1763569354037.png WaitForUserButtonPress 函数利用 GPIO 切换和写入操作来控制 LED 状态,并通过延迟机制管理轮询循环期间的闪烁间隔。为了实现延迟,SYSTICK 定时器被初始化并进行相应配置。 此外,引入了一个全局计数器变量,以及相应的SYSTICK中断处理程序,以支持应用程序内的基于时间的操作。 Sabina_Bruce_34-1763569354042.png 在main()函数中,SYSTICK定时器初始化应在按钮轮询逻辑之前添加。此操作可确保在进入等待用户输入的循环之前,延迟机制已完全运行。 Sabina_Bruce_35-1763569354044.png 最终版的 WaitForUserButtonPress 函数将包含: GPIO操作可切换和控制LED状态。 持续检查按钮状态的while循环,只有在检测到按键事件时才会继续执行。 Sabina_Bruce_36-1763569354052.png GPIO_* API是恩智浦GPIO驱动程序库的一部分,用于执行初始化、引脚控制和中断处理等各种操作。代码中高亮显示的宏(通常在IDE中以粉红色显示)由配置工具生成,并在pin_mux.h头文件。 应用中使用的延迟功能通过基于SYSTICK的自定义函数实现,如前所述。 要了解所有可用的GPIO API,请参阅fsl_gpio.h头文件。此文件为GPIO操作提供全面支持,包括端口和引脚级控制、配置以及中断管理。 自定义I2C中断处理程序 要以类似 GPIO 处理程序的方式定制 I2C 中断处理程序,首先要在 MCUXpresso IDE 中打开外设配置工具。从中找到并复制自动生成的I2C0 IRQ 处理程序。这是一个基础模板,可根据应用的具体要求进行修改。 Sabina_Bruce_37-1763569354056.png 要返回代码编辑器,请点击位于MCUXpresso IDE右上角的“开发”按钮。进入开发环境后,将复制的I2C中断处理程序代码粘贴到主源文件中(最好放在顶部),以便整理和访问。 Sabina_Bruce_38-1763569354061.png 复制外设配置工具中自动生成的中断处理程序,对I2C3重复同样的过程。然后,此处理程序可用作定制基础,类似于I2C0采用的方法。 整合I2C中断处理程序 在原始ST项目中,每个I2C实例都使用两个独立的中断处理程序:一个用于执行标准操作,另一个则用于处理错误。然而,此次迁移中使用的恩智浦MCU会为每个I2C实例提供单一中断向量,用于处理标准和错误状态。 因此,必须将原始的四个处理程序功能合并为两个,每个I2C实例各分配一个功能。此操作需要仔细审查原始中断逻辑,以确保所有相关标志和行为在合并实现中得以保留。 例如,原始项目中的从设备处理程序可检查地址匹配标志,并在检测到标志后验证就绪度以接收数据。在恩智浦环境中,等效行为通过监测统一中断处理程序内的相应状态标志来实现,以确保正确处理地址识别和数据接收。 从设备处理程序 Sabina_Bruce_39-1763569354077.png 当主设备以0x7E寻址从设备时,就会触发I2C从设备中断处理程序。检测到此地址匹配后,从设备会确认请求并准备接收传入数据。 处理程序的第二部分负责管理数据接收过程。它能处理主设备传输的每个字节,监测NACK(未确认)状态以指示传输结束,并将接收的数据存储到指定的缓冲区。此操作可确保从设备正确处理通信序列,并在所有数据接收完毕后轻松终止传输。 主设备处理程序 Sabina_Bruce_40-1763569354092.png I2C主设备中断处理程序可监测主设备传输就绪标志,此标志用于指示外设已准备就绪,可传输下一个字节的数据。检测到此条件后,处理程序会检查传输缓冲区,以确定是否还有其他数据需要发送。计数器用于跟踪传输进度。 处理程序会使用适当的主设备发送操作,发送下一个字节并推进缓冲区指针。当最后一个字节发送后,处理程序会发出终止条件,以指示数据传输序列完成。 Handle_I2C_Master 函数 Handle_I2C_Master函数负责启动和管理I2C通信过程。它首先发出MasterStart命令,以启动与指定地址从设备的通信。从设备成功确认后,数据传输将通过相应的中断例程进行处理。 Sabina_Bruce_0-1763577716125.png 此函数还会初始化主设备和从设备I2C实例的中断处理程序。如前所述,必须在主设备发起通信后启用中断,以防止过早触发中断,从而干扰事务序列。 数据传输完成且从设备接收到所有预期的字节后,此函数会将LED设为稳定状态:表示执行成功,应用流程结束。 结束语 使用MCUXpresso IDE将应用从STM32开发环境迁移到恩智浦MCX平台,需要采用条理清晰的结构化方案。借助集成的配置工具并理解STM32与恩智浦SDK元器件间的功能等效性,开发人员可以在维持性能和功能的同时有效过渡其应用。 本指南概述了复制I2C应用的关键步骤,包括项目设置、外设配置、引脚和时钟初始化以及中断处理。虽然这些工具通过自动生成代码提供了坚实的基础,但必须谨慎考虑初始化和运行时逻辑的序列和集成,以确保稳定运行。 通过清晰理解两种环境并审慎调整应用逻辑,开发人员可以简化迁移流程,同时充分利用恩智浦MCX平台所提供的功能。
View full article
[RTD600 MCAL] S32K3X4EVB-T172 RTC API Wake-up This example project will show user how to use and configure the basic functionalities of WKPU + GPT RTC API.  ------------------------------------------------------------------------------ * Test HW: S32K3X4EVB-T172 (SCH-53148 REV B2) or S32K344MINI-EVB * MCU: S32K344 * IDE: S32DS3.5 & S32DS3.6 * SDK release: RTD 6.0.0 * Debugger: PE Micro * Target: internal_FLASH  ------------------------------------------------------------------------------ This example routine configures the WKPU & RTC units for wake-up. The RTC is present in always ON domain, hence available in RUN mode as well as in STANDBY mode. Julin_AragnM_0-1771625665539.png The chip contains one instance of RTC (Real Time Clock) timer and API (Autonomous Periodic Interrupt) timer, where both can perform 32-bit comparisons. Both RTC and API timers can generate interrupts as well as wake-up from low power modes. The following figure highlights the path for RTC API wake-up. Please refer to Chapter 69.3.2 API functional description from the S32K3XX reference manual (Rev. 12) for further information. Julin_AragnM_1-1771625661011.png The routine waits for SW5 to be pressed, then: Turns off the green LED Switches CORE_CLK to Option C - Boot Standby mode (CORE_CLK @ 24 MHz). Initializes the ICU driver. Configures RTC_API channel (WKPU0) Initializes GPT module. Starts timer and sets RTC_API_TIME. Enters standby. After the period defined, RTC API generates an interruption and MCU wakes up. After wake-up, MCU resets and polls for SW5 to be pressed again. The RTC API value can be changed with RTC_API_TIME definition. This example is provided as is with no guarantees and no support.
View full article
RT685: SDK 25.12 no HASHCRYPT acceleration Hello, We recently updated to SDK 25.12 and noticed that our TLS decryption rate has been cut in half. mbedTLS v3.x is no longer accelerated using the fsl_hashcrypt hardware features. Here is the callstack of calling mbedtls_ssl_read using the previous SDK 25.09. As you can see, HASHCRYPT_AES_EncryptEcb is eventually used. hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> Here is the callstack of SDK 25.12 with MBEDTLS_USE_PSA_CRYPTO defined. In this version, mbedtls_internal_aes_encrypt is all C code with no HW acceleration. mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> And here is the callstack of SDK 25.12 withoutMBEDTLS_USE_PSA_CRYPTO defined. In this version,  mbedtls_internal_aes_encrypt is all C code with no HW acceleration and PSA is not involved. mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Are there plans to restore RT685 HASHCRYPT hardware acceleration to mbedTLS? It seems certain PSA Crypto drivers are not implemented. Thank you. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, I reproduced the issue on the EVK. I modified two samples by adding a loop of 200 iterations of mbedtls_gcm_self_test and timed the overall execution using the RTC clock. evkmimxrt685_mbedtls_selftest_cm33 from SDK 25.09 executed the tests in 1087ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 executed the test in 8990ms with this callstack: mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES defined executed the test in 8744ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 The gist of the modifications to the examples is the following: BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... where test_rtc_get_msecs returns the current RTC time using subsecond accuracy. As you can see, there is an ~8x slow down for encrypting GCM/AES with the new SDK. I can attach the modified examples if you'd like. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, We have looked over the migration guide. However, we don't see how mbedTLS 2.x or mbedTLS 3.x without PSA would be hardware accelerated in this version of the SDK. Since aes_alt.c was removed and HASHCRYPT functionality is only supported by the PSA drivers. Everything works in our app with SDK 25.12, and we would definitely like to use TLS 1.3 for our connections, but we would suffer a large performance loss as it is. We will continue to look into this. I will modify one of the examples to see if I can reproduce the performance loss. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Thanks for your patience with this question. I just received the response from the internal team, please see below. From the call stack I can see you are using legacy mbedtls_xxx crypto API. Indeed, it is not HW accelerated. MbedTLS3.x introduced new API for Crypto, and it is PSA. mbedtls/docs/psa-transition.md at v3.6.5 · Mbed-TLS/mbedtls · GitHub and it is accelerated. Legacy crypto API is further removed in MbedTLS4.x. I checked our psa_crypto_examples in SDK for RT600 and HASHCRYPT HW acceleration is enabled by default by having the PSA_CRYPTO_DRIVER_HASHCRYPT defined which enables crypto driver wrappers to offload crypto computation to HW. On the other hand, MbedTLS3.x+ is more complex and aligned with PSA API specification so it may happen that some use-cases are indeed producing lower performance. In case of TLS I would expect rather asymmetric cryptography (CASPER HW IP) to be bottleneck of performance, since this IP can support only bignum acceleration and it is not well compatible with PSA API that expect HW IP to implement whole algorithm. We did our best to accelerate at least some ECC operations (sign, verify) but it may happen that other operation like keygen during ECDHE key exchange may be worse. Now it would be good if you can use the PSA API for performance measurement and confirm that PSA_CRYPTO_DRIVER_HASHCRYPT is defined and call stack uses it. FYI: Hashcrypt did not offer AES-GCM acceleration natively, so it is better to benchmark AES-CBC or AES-CTR to see real gain of HW IP. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Migrating from mbedTLS 2.x (without PSA) to mbedTLS 3.x (with PSA) is bound to have performance drops, considering that: "The PSA Driver Interface has only been partially implemented. As a result, the deliverables for writing a driver and the method for integrating a driver with Mbed TLS will vary depending on the operation being accelerated." (https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) At the moment, the best I can recommend is to follow the guidelines on how to properly migrate from 2.x to 3.x: Migrating from Mbed TLS 2.x to Mbed TLS 3.0 — MCUXpresso SDK Documentation As well as the guide to properly transition to the PSA API: Transitioning to the PSA API — MCUXpresso SDK Documentation I apologize for the inconvenience. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Did you make any changes after updating the SDK? Do you also see this behavior with the SDK's example code? Are you using the standalone IDE or the VS Code extension? BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration I defined MBEDTLS_PSA_ACCEL_KEY_TYPE_AES in our mbedTLS configuration file and now it's calling through to HASHCRYPT, but our mbedtls_ssl_read read rate is even slower now. I wonder if there are other missing defines or the PSA layer is adding extra overhead.   Rates downloading 4KB packets from WiFi via a TLS socket: SDK 25.09: 205KB/sec (mbedTLS 2.x without PSA and with ksdk port files) SDK 25.12: 138KB/sec (without MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) SDK 25.12: 125KB/sec (with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) Here's the new callstack using MBEDTLS_PSA_ACCEL_KEY_TYPE_AES: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @EdwinHz, We're using MCUXpresso IDE. No extra changes after updating the SDK: When we update the SDK, we re-run the "SDK Management" -> "Refresh SDK components" to get new and updated files. Then we compare the .cproject configuration to one of the samples that has similar features enabled (e.g. evkmimxrt685_wifi_wpa_supplicant_cm33) PSA_CRYPTO_DRIVER_CASPER=1 PSA_CRYPTO_DRIVER_HASHCRYPT=1 CONFIG_WPA_SUPP_CRYPTO_MBEDTLS_PSA=1 etc... We're using the default mcux_mbedtls_config.h as the main mbedTLS configuration header and our own user configuration file that is nearly identical to wpa_supp_mbedtls_config.h from the evkmimxrt685_wifi_wpa_supplicant_cm33 example. I will try the mbedtls3x_examples to see how they behave. Perhaps we're missing some defines. As I was stepping through the code, I noticed that perhaps MBEDTLS_BLOCK_CIPHER_C needs to be defined so that the gcm operation can be accelerated. It looks like the header mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h is responsible for this but doesn't end up defining that macro for some reason. Re: RT685: SDK 25.12 no HASHCRYPT acceleration For others' benefit... It appears that mbedtls_xor from mbedTLS 3.x is looping over data 4-bytes at a time and calling mbedtls_get_unaligned_uint32 and mbedtls_put_unaligned_uint32 which both use memcpy for a single uint32. I recognize that the authors of mbedTLS are trying to improve performance by calculating blocks of XOR 4-bytes at a time (with a remainder loop), but the full calls to memcpy are actually making the code slower. After some investigation into the disassembly, it turns out that our project was being compiled with -fno-builtin, preventing small memcpys from getting inlined by the compiler. Removing that option restored much of the performance loss of HASHCRYPT hardware not being used for AES-GCM operations. So, the example I posted went from executing in 8600ms down to 2100ms. Not quite at the level of mbedTLS 2.x + ksdk alt (at 1087ms). But the restored performance is good enough. -Amilcar
View full article
PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hi, We are using an ATH12K Wi‑Fi module on an i.MX95‑based system, connected via the PCIe2 instance. On a kernel based on linux-imx lf‑6.12.y this setup fails, whereas with a kernel based on lf‑6.6.y it works as expected. The kernel driver successfully requests and receives 16 MSI interrupts. However, it subsequently fails to bring up the Wi‑Fi module: [ 5.888139] ath12k_pci 0001:01:00.0: Adding to iommu group 5 [ 5.888506] ath12k_pci 0001:01:00.0: BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0: enabling device (0000 -> 0002) [ 5.889315] ath12k_pci 0001:01:00.0: MSI vectors: 16 [ 5.889334] ath12k_pci 0001:01:00.0: Hardware name: wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0: fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0: failed to receive control response completion, polling.. [ 8.675241] ath12k_pci 0001:01:00.0: Service connect timeout [ 8.681002] ath12k_pci 0001:01:00.0: failed to connect to HTT: -110 [ 8.692180] ath12k_pci 0001:01:00.0: failed to start core: -110 There was a related discussion on the kernel mailing list [1] with a different PCIe device, but it has not yet led to a working configuration for our system. What would be the best way to proceed? Thank you for your support. Max [1] https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hello, The i,MX95 is in early stage and some configuration are not in design. However your i.MX95 with ATH12K via PCIe2 failing on lf-6.12.y but working on lf-6.6.y suggests a regression or driver interaction change in newer kernel's PCIe or Wi-Fi stack, likely involving PCIe power management (ASPM), MSI mapping, or specific PCIe endpoint quirks for the ATH12K, often resolved by kernel patches or disabling ASPM in boot args for newer kernels; check dmesg for PCIe errors, compare devicetree, and look for related commits in NXP/Linux kernel mailing lists.  Here's a breakdown of potential causes and troubleshooting steps: 1. Check Kernel Logs ( dmesg ) Look for PCIe Errors: Search for "PCI", "MSI", "ATH12K", "Error", "Firmware", or "Timeout" messages in dmesg on the failing lf-6.12.y kernel. Firmware Loading: Verify the ath12k firmware is loaded correctly and if there are any errors during initialization.  2. PCIe Power Management (ASPM) Common Issue: Newer kernels often enable Active State Power Management (ASPM) by default, which can cause issues with PCIe devices like the ATH12K on embedded systems, especially older firmware/hardware. Try Disabling ASPM: Add pcie_aspm=off to your kernel boot arguments (e.g., in U-Boot or GRUB) and test again.  3. Devicetree/DTB Differences Compare DTBs: Generate and compare the Device Tree Blobs (DTBs) used with both kernels ( .dtb files). Look for changes in the PCIe node for pci2 , especially related to interrupts, power domains, or compatibility properties.  4. Kernel Driver/Firmware Regressions Specific Commits: The ATH12K driver ( ath12k ), mac80211 , or core PCIe/ARM code in lf-6.12.y might have introduced a change breaking your setup. Search Mailing Lists: Check the Linux Kernel Mailing Lists (LKML) and NXP's lists for related patches or discussions around ath12k , i.MX95 , and newer kernels (6.12+).  5. MSI Handling Interrupt Remapping: While you receive interrupts, the way they are handled (MSI-X vs. MSI, interrupt remapping) might have subtle changes. Check Interrupts in proc/interrupts : See if the interrupt distribution or count differs between kernels.  6. Firmware Blobs Firmware Version: Ensure you are using the correct firmware for the ATH12K, compatible with the newer kernel's driver. Sometimes newer drivers require newer firmware.  In summary, start with dmesg and try disabling ASPM; these are the most frequent culprits for PCIe Wi-Fi failures in newer kernels on embedded platforms   Regards Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors While the suggestions were good pointers to debug the issue I couldn't find the solution, i.e. not all MSI IRQ vectors triggered the IRQ routines in the driver. I ended up working around the issue by changing the ath12k driver to only request one MSI IRQ. Note that current Linux master does not have the issue. Regards Max
View full article
One Time Programable (OTP) Memory Legacy 8-bit MCUs Understanding EPROM Erasure and Package Types If a microcontroller (MCU) does not have a quartz window, its EPROM cannot be erased and effectively functions as OTPROM (One-Time Programmable ROM). This is because the quartz window is essential for allowing ultraviolet (UV) light to erase the EPROM contents. How to Identify Erasable EPROMs You can determine whether an EPROM is erasable by checking the part number and package type: If the package has a windowed ceramic dual in-line package the EPROM can be erase. For example, on the HC05 family you can see this window being mentioned on the order numbers of the datasheet Pablo_Ramos_0-1765382553460.png
View full article
MIMXRT1170-EVKBでJ-Linkを使用する 注:類似のEVKについては、以下を参照してください。 MIMXRT1060-EVKBまたはMIMXRT1040-EVKでJ-Linkを使用します MIMXRT1060-EVK または MIMXRT1064-EVK で J-Link を使用する MIMXRT1160-EVK または MIMXRT1170-EVK で J-Link を使用する この記事では、この EVK で J-Link デバッグプローブを使用する方法の詳細を説明します。  2つの方法があります:オンボードの MCU-Link デバッグプローブを Segger J-Link ファームウェアで更新する方法と、外部の J-Link デバッグプローブを EVK に接続する方法です。  他のデバッグプローブは必要ないので、オンボードデバッグ回路を使用すると便利です。  この記事では、J-Link を使用する2つの手順を詳しく説明します。 MIMXRT1170-EVKB jumper locationsMIMXRT1170-EVKB ジャンパの位置 外部J-Linkデバッグ・プローブを使用する セガーはいくつかの J-Linkプローブ オプションを提供しています。これらのプローブのいずれかをこれらのEVKで使用するには、EVKを次の設定で構成してください。 JP5 にジャンパを取り付け、SWD 信号をオンボードデバッグ回路から切り離してください。  このジャンパはデフォルトでは開いています。 EVK の電源を入れるには、デフォルトのオプションとして、電源をバレルジャック J43 に接続し、電源スイッチ SW5 をオン位置(3-6)に設定します。EVK が適切に電源供給されると、SW5 の隣にある緑色の LED D16 が点灯します。 J-Linkプローブを、J1、20ピン、2列0.1インチ・ヘッダーに接続します。 J-Link ファームウェアで更新してオンボード MCU-Link を使用 ドライバおよびファームウェア更新ツール用のMCU-Link インストーラをインストール EVKからUSBケーブルをすべて取り外します EVK の電源を入れるには、デフォルトのオプションとして、電源をバレルジャック J43 に接続し、電源スイッチ SW5 をオン位置(3-6)に設定します。EVK が適切に電源供給されると、SW5 の隣にある緑色の LED D16 が点灯します。 JP3 にジャンパを取り付け、ISP モードを MCU-Link に強制する USB ケーブルを J86 に、また MCU-Link デバッガに接続 MCU-Link ソフトウェアパッケージのインストール先のスクリプトディレクトリに移動し、program_JLINK.cmd(Windowsの場合)またはprogram_JLINK(Linux/MacOSの場合)のスクリプトをダブルクリックして実行します。画面上の指示に従います。Windowsでは、このスクリプトは通常C:\nxp\MCU-LINK_installer_3.122\scripts\program_JLINK.cmdにインストールされます。 J86 の USB ケーブルを取り外します JP3 のジャンパを取り外します USB ケーブルを J86 に接続し直します。  これで MCU-Link デバッガは JLink として起動するはずです。 ジャンパ JP5 を取り外し、MCU-Link デバッガの SWD 信号を接続します。このジャンパはデフォルトでは開いています。
View full article
CI/CD 最佳实践 以前也有过几个类似的帖子,但答案都有点过时了,而且我的问题也略有不同,所以也许值得再问一次。我有两个问题: 1。每隔一段时间,在 S32DS (v 3.6.2) 中进行版本时,操作系统是 Windows 11),版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件,执行 "更新代码"(尽管实际上不应该更新任何内容)并重建后,问题就解决了。我的问题是:为什么会出现这种情况?这种情况似乎是随机发生的,所以我无法提供任何 "重现步骤",但这种情况经常发生,如果你至少没有意识到这一点,我会很惊讶。我看到其他一些人也在论坛上提到这个问题。 2。我们正在努力将要编程到闪存的整个代码库(而仅限于我们的应用程序代码)放入 git 中,并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议?特别是,由于 RTD、C 标准库等都在项目之外,而且 IDE 安装了很多连接,因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链? Re: Best practices for CI/CD 谢谢@petervlna提供的提示。关于 CI/CD 管道,我还有一个问题: 如何在 Linux 环境中安装独立于 IDE 的版本工具链? Re: Best practices for CI/CD 你好 1。每隔一段时间,在 S32DS (v 3.6.2) 中进行版本时,操作系统是 Windows 11),版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件,执行 "更新代码"(尽管实际上不应该更新任何内容)并重建后,问题就解决了。我的问题是:为什么会出现这种情况?这种情况似乎是随机发生的,所以我无法提供任何 "重现步骤",但这种情况经常发生,如果你至少没有意识到这一点,我会很惊讶。我看到其他一些人也在论坛上提到了这个问题。 这个问题在 S32DS 等基于 Eclipse 的集成开发环境中比较常见。以下是最可能的原因: 索引/路径解析故障 S32DS 依赖 Eclipse 的 CDT 索引器和项目元数据来解析包含路径。有时,索引器或内部版本配置会不同步,尤其是在更改.mex 或环境变量之后。重新打开 .mex文件和重新生成代码会强制集成开发环境刷新路径并重建索引。 临时工作区损坏 集成开发环境在工作区中存储了大量状态。如果工作区缓存变得不一致(例如,在版本中断或 IDE 崩溃之后),则在刷新之前可能无法识别包含路径。 Windows 文件系统定时 在 Windows 上,防病毒或文件锁定会在并行版本步骤中延迟对头文件的访问,从而导致间歇性故障。 2。我们正在努力将要编程到闪存的整个代码库(而仅限于我们的应用程序代码)放入 git 中,并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议?特别是,由于 RTD、C 标准库等都在项目之外,而且 IDE 安装了很多连接,因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链? 处理 RTD 和外部 SDK 版本控制或工件库: 将 RTD 和 SDK 代码包存储在 Git(如果允许)或 Nexus/Artifactory 等工件存储库中。 环境变量: 在 CI/CD 管道中定义 RTD_PATH 和 SDK_PATH 等变量。 在 Makefile 或版本脚本中使用这些变量,而不是硬编码路径。 导出项目以进行无头版本 在 S32DS 中,将项目导出为 Makefile 项目(项目 → 生成 Makefile)。 这样,您就可以得到一个可以在集成开发环境之外使用的 Makefile。 或者,使用 s32ds.exe --build 进行基于 Windows 的无头版本,但对于 Linux CI/CD,首选 Makefile。 避免集成开发环境依赖性 不要依赖 .mex在 CI/CD 中再生。 确保在 Makefile 或 CMake 配置中捕获所有包含路径和编译器标志。 我不知道除了一般性建议之外还有没有其他建议。 顺祝商祺! Peter Re: Best practices for CI/CD 你好@petervlna 谢谢您的建议。我需要更多这方面的信息。在 S32 Design studio 页面上,我看到了整个集成开发环境的下载选项,似乎工具链已作为集成开发环境安装的一部分安装。我没有看到工具链作为单独的下载提供。 我确实看到,在 Windows11(我目前使用的操作系统)上,工具链安装在 C:\NXP\S32DS.3.6.2\S32DS\build_tools 你的意思是 1.在 Linux 桌面上安装 Linux 版本的集成开发环境 2.将已安装的工具链从本机复制到无头 CI/CD 服务器 3.按照上述步骤操作 请予以澄清。 Re: Best practices for CI/CD 你好 如何在 Linux 环境中安装独立于 IDE 的版本工具链? 遗憾的是,我不了解 Linux 环境,所以只能提供一般性的帮助: 官方步骤摘要: 从 S32DS 下载页面下载适用于 ARM 的恩智浦 GCC 工具链(Linux 版本)。 将压缩包解压缩到 /opt/armgcc 等目录。 将工具链 bin 目录添加到 PATH。 在 Linux 系统上安装编译工具(make、cmake)。 使用从 S32DS 导出的 Makefile 进行无头版本。 我建议有关 Linux 的问题另起一个主题。 顺祝商祺! Peter Re: Best practices for CI/CD 你好、 你可以从恩智浦页面下载独立组网 \(SA\) gcc 例如这个 https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 或任何其他版本 https://www.nxp.com/search?keyword=gcc% 2520 &start=0 Re: Best practices for CI/CD 你好@petervlna @jiri_kral 很抱歉延迟回复已关闭的单子,但我终于有机会解决这个问题了。 彼得的建议对我来说非常合理;但是,我在 S32 IDE(v3.6.6)中找不到 “项目 → 生成 Makefile” 选项。我可以尝试复制生成的生成文件,但是它有一些不太好的地方: 1.这不是一个独立的 makefile,它依赖于其他 .mk文件也会生成。 2。生成文件是按版本目标生成的(与 .cproject 不同)文件),这使得它有点笨重。理想情况下,我想要的是一个Makefile,其中版本目标是 “制作” 的参数。 我有点惊讶其他人以前没有问过这个问题,或者你没有关于这个问题的 “操作方法” 文档;鉴于该处理器非常受欢迎并且对功能安全至关重要,我本以为在 CI/CD Linux 环境中进行版本会很常见。
View full article
s32k3 eMIOS IMPモード こんにちは、 現在、s32k3 マイクロの eMIOS IPM モードを使用して入力信号周波数を読み取ろうとしています。ステータス レジスタが測定値をキャプチャしたことを通知するまで待機した後、最初に A レジスタを読み取り、次に B レジスタを読み取り、両方のケース (通常のケースとオーバーフローのケース) の周期計算を実行します。ただし、計算では信号の周期ではなく、「High 時間」または「Low 時間」のいずれかが得られます。IPM モードでは、周期ではなく、高/低デューティ サイクルが提供されるようです。これを理解するための考えはありますか?制御レジスタが正しいモードを使用していることを確認しました。 よろしくお願いします。 Re: s32k3 eMIOS IMP Mode @VaneBこんにちは、 私も同様の問題に直面しています。周波数を測定するために EMIOS をどのように構成すればよいかなどの構成を共有していただけますか。 Re: s32k3 eMIOS IMP Mode こんにちは@jfranklin 可能であれば、設定を共有していただけますか? Re: s32k3 eMIOS IMP Mode こんにちは。これは当社独自のソフトウェアです。私たちの目標は、提供されている GUI を使用しないことです。基本的には、周波数入力の周期を読み取ろうとしているだけです。IPM モードでは立ち上がりエッジのみ、または立ち下がりエッジのみで更新されるはずですが、立ち上がりと立ち下がりの両方で更新されているようです。 Re: s32k3 eMIOS IMP Mode こんにちは@jfranklin RTD コントローラまたはカスタム ソフトウェアを使用していますか?あなたのアプリケーションについてさらに詳しい情報を教えていただけますか? BR、ヴェインB
View full article
RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hello, Do you have any reference designs, application notes, or example projects demonstrating the use of a camera module outputting YUV422 (8-bit) with the i.MX RT1170 MIPI-CSI interface? I have reviewed the RT1170 errata (https://www.nxp.com/docs/en/errata/IMXRT1170ACE.pdf) and understand that YUV422 10-bit formats are not supported, but I have not been able to find any published examples or confirmation specifically showing YUV422 8-bit operation. Any guidance, known-working configurations, or example camera modules would be greatly appreciated.  Re: RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hi @mtreloar , Thanks for your interest in NXP MIMXRT series! RT1170 MIPI-CSI supports YUV422 (YUYV 8-bit) format. You can refer to this sample project in the SDK: Gavin_Jia_0-1768188511422.png Best regards, Gavin
View full article
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)での電力消費量を試算したり、ソリューションのバッテリ寿命を評価したりするのに役立ちます。  
View full article