Choosing the Right FRDM Board for MCX A Series Selecting the Right FRDM Platform for MCX A Series A technical guide for mapping application requirements to MCX A evaluation hardware The MCX A series spans a wide range of MCU variants optimized for real-time control, precision sensing, motor control, and industrial connectivity. Because peripheral combinations and acceleration features vary significantly across subfamilies, selecting the appropriate FRDM board is critical for accurate prototyping and performance validation. This guide provides a device-to-board mapping along with architectural considerations to help engineers align hardware selection with system requirements. Design Considerations for Board Selection When choosing a FRDM platform for MCX A devices, evaluate: 1. Compute and Real-Time Requirements Use of SmartDMA for offloaded data movement Deterministic latency requirements (motor control, control loops) Availability of hardware accelerators (e.g., MAU) 2. Analog and Sensing Capabilities 16-bit ADC resolution and sampling throughput Dual ADC configurations for simultaneous sampling Sensor interface (UART/I2C/I3C/SPI) 3. Connectivity and System Integration CAN-FD for industrial/automotive networks FS USB for host/device applications and debug access Emerging interfaces (e.g., I3C) for modern sensor integration 4. HMI and Security Requirements SLCD support for low-power display use cases Hardware-based security features for connected edge nodes MCX A to FRDM Board Mapping Supported MCU(s) Recommended Board Best Fit For Key Differentiators MCX A13, A142, A143, A152, A153 FRDM-MCXA153 Cost-sensitive smart sensing and motor control FS USB, 16-bit ADC, compact entry platform MCX A144, A145, A146, A154, A155, A156 FRDM-MCXA156 Connected control, smart sensing, industrial HMI 1 MB Flash, FS USB, CAN-FD, FlexIO, 2x 16-bit ADC, I3C MCX A173, A174 FRDM-MCXA174 Balanced real-time control and connected sensing CAN-FD, SmartDMA, ADC, compact mid-tier platform MCX A175, A176, A185, A186, A255, A256, A265, A266 FRDM-MCXA266 Industrial HMI, secure connected sensing, USB-enabled control FS USB, SLCD, CAN-FD, FlexIO, SmartDMA, advanced security MCX A343, A344 FRDM-MCXA344 Cost-optimized motor control and smart sensing CAN-FD, MAU, SmartDMA/LCD expansion MCX A345, A346 FRDM-MCXA346 Advanced motor control and high-performance real-time designs 2x FlexPWM, MAU, SmartDMA, CAN-FD MCX A355, A356, A365, A366 FRDM-MCXA366 Industrial HMI, secure connected sensing, high-performance control FS USB, SLCD, CAN-FD, MAU, SmartDMA, FlexIO, advanced security Not all MCX A devices expose the same combination of ADCs, SmartDMA, MAU, or connectivity interfaces—and choosing the wrong evaluation board can limit what you can prototype. This article provides a clear mapping between MCX A families and FRDM platforms, helping you align hardware capabilities with system requirements. FRDM-MCXA MCU

[入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 (日本語ブログ) *i.MX FRDMボードをベースに、Yocto Linuxのビルド方法を紹介します。 本記事ではFRDM-IMX93をベースに紹介しますが、他のi.MX FRDMボードでも同じ手順でビルドすることができます。 Yocto Linux BSPは、「Linux 6.12.49_2.2.0 (Yocto 5.2 “Walnascar”)」を例に記載しています。   Q: i.MX FRDMボードとは？   A: i.MX FRDMボードは、NXPが提供するフル機能のEVKボードに比べて、機能を絞り込み、より低価格かつコンパクトに設計された開発ボードです。基本的な評価やプロトタイプ作成を手軽に行えることを目的としています。 1. 環境＆事前準備 1.1. 環境 大項目 小項目 内容 備考 Document - IMX_YOCTO_PROJECT_USERS_GUIDE.pdf (主に使用します。BSPをビルドするための手順を記載) i.MX Linux® Release Notes  (サポート機能を一覧で確認できます) i.MX Porting Guide (実際に実装する際の注意点のまとめ) Yocto Linux全般資料のダウンロードはこちら Hardware FRDMボード FRDM-IMX8MPLUS FRDM-IMX91S FRDM-IMX91 FRDM-IMX93 FRDM-IMX95  本章では、FRDM-IMX93をベースに説明します Host PC Ubuntu環境 ・VMWare/Virtual Box等(on Windows) ・Native Linux のどちらか 推奨：Ubuntu22.04以上 SDカード＋リーダライタ 16GB以上のもの推奨   Hardware (Option) MIPI-Camera (Option) BSP対応のMIPIカメラ ( i.MX Linux® Release Notes参照) USBカメラでも代替可（遅延が発生する可能性があります） Display (Option) 表示用ディスプレイ   USB Device (Option) USBマウス、USBメモリ   Headphone (Option) 3.5mm イヤホン マイク付きイヤホン(旧iphone付属のイヤホン等)だとベター Software Yocto環境 Linux BSP (今回はLinux 6.12.49_2.2.0 (Yocto 5.2 “Walnascar”) を使用) インストール方法含め、本記事で説明します 1.2. 凡例 コマンド・プロンプトの凡例 =>           u-bootプロンプト $            BSPがインストールされているLinux PCのプロンプト 2. ホストマシン Ubuntu 22.04 Desktopを推奨します。 実運用上、ある程度快適なホストマシンのスペックは8スレッド、16GB以上です。 必要なストレージはターゲットとするレシピで変わってきますが、 小さいプロジェクトで50GB、大きなもので500GBほどかかります。 2.1. Yoctoに必要なパッケージ 以下の手順にて必要なパッケージをインストールしてください。 $ sudo apt-get install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3- jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xzutils zstd efitools curl 注釈 IMX_YOCTO_PROJECT_USERS_GUIDE.pdf に記載されている内容に加えて curl を追記しています。 2.2. スワップファイルの設定 32GBのスワップファイルを設定する場合の例です。 $ sudo fallocate -l 32G /swapfile $ sudo chmod 600 /swapfile $ sudo mkswap /swapfile $ sudo swapon /swapfile 注釈 すでに/swapfileが存在する場合は1行目のコマンドがFailします。サイズを変えて設定したい場合は、以下を実行してから再度上のコマンドを実行してください。 $ sudo swapoff /swapfile $ sudo rm /swapfile ホストマシンの起動時にスワップファイルを自動的にマウントさせるには、以下の行を/etc/fstabに追加してください。 /swapfile none swap sw 0 0 3. Yocto Linux BSP nxp.jpのEmbedded Linux for i.MX Applications Processorsから必要なLinux BSPのVersionを選択して、i.MX Yocto Project User's Guideを入手してください。 i.MX Yocto Project User's Guide (IMXLXYOCTOUG) の「4 Yocto Project Setup」の手順に沿ってイメージを作成します。 この資料は、以下の設定で生成されるイメージを前提として書いています。 　DISTRO = fsl-imx-xwayland 　MACHINE = imx93-11x11-lpddr4x-frdm 3.1. Yocto BSPのセットアップとビルド ホストマシンのセットアップは 2. ホストマシン を参照ください。 3.1.1. repoユーティリティのインストール $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo 3.1.2. repoのPATHを通す 以下の行を$HOME/.bashrcに追加します。   export PATH=~/bin:$PATH 3.1.3. Gitのセットアップ $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list 3.1.4. Yocto BSPのセットアップ $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-walnascar -m imx-6.12.49-2.2.0.xml $ repo sync 3.1.5. ビルドターゲットの設定、ビルド $ MACHINE=imx93-11x11-lpddr4x-frdm DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b build $ bitbake imx-image-full ＊ここでビルドが終了しますと、Linuxイメージが生成されます。 ＊生成されたイメージの書き込み方法については、以下ご使用のFRDMボードに合わせたスタート・ガイドのステップ１、２をご参考ください。 FRDM-IMX8MPLUSのスタート・ガイド FRDM-IMX91のスタート・ガイド FRDM-IMX91Sのスタート・ガイド FRDM-IMX93のスタート・ガイド FRDM-IMX95のスタート・ガイド 注釈 他のFRDMボード向けにLinux BSPをビルドしたい場合は、上記コマンドの"MACHINE="の部分を以下の名前に置き換えてください。 imx8mp-lpddr4-frdm   (FRDM-IMX8MPLUS) imx91-11x11-lpddr4-frdm   (FRDM-IMX91) imx91-11x11-lpddr4-frdm-imx91s   (FRDM-IMX91S) imx93-11x11-lpddr4x-frdm   (FRDM-IMX93) imx95-15x15-lpddr4x-frdm   (FRDM-IMX95) 注釈 グラフィック機能についても上記コマンドの"DISTRO="の部分にて、ディストリビューションを選択できます。 fsl-imx-wayland   (Wayland) fsl-imx-xwayland   (Wayland & X11 *EGLを使用するX11アプリには対応していません) 注釈 imx-setup-release.shスクリプトを使うセットアップは、プロジェクト1つに対して1回のみです。既存のプロジェクトに対して行うと、conf/local.confなどのファイルが新規で生成されるので、これまで設定した内容が失われます。既存プロジェクトを再度使う場合は 3.3.1. 既存のビルド・ディレクトリから作業を再開する を参照ください。 注釈 ホストマシンのスペックによりますが、ビルドには数十時間かかることも想定されます。またストレージも4~500GB消費することも想定してください。 注釈 マルチコア・マルチスレッドでのホストマシンでビルドを行う際、スレッド数に対してメモリが足りない場合にスワップが発生します スレッド数を制限するのは 3.4.2. ビルド時に走るスレッド数を制限する を参照ください。 注釈 Ubuntu22.04の初期状態だとスワップが設定されていないケースがあり、その場合は極端に遅くなったりクラッシュしたりします。スワップファイルの設定は 2.2. スワップファイルの設定 を参照ください。 ＊ここから先は参考用です。 3.2. ツールチェインのビルド、インストール クロスコンパイラなどのツールチェインをビルド、インストールすることができます。 ここで生成されるスクリプトを使うことで、クロスコンパイルのときにありがちなインクルードファイルやリンクさせるライブラリが見つからない、といった問題を避けることができます。 3.2.1. ツールチェインのビルド $ bitbake imx-image-full -c populate_sdk 3.2.2. インストール $ tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93-11x11-lpddr4x-pf0900-evk-toolchain-6.12-walnascar.sh ツールチェインの使い方については、ここでは説明しません。 3.3. よく使うYocto bitbakeコマンド、設定 3.3.1. 既存のビルド・ディレクトリから作業を再開する $ cd /path/to/imx-yocto-bsp $ source ./setup-environment build 注釈 ここでのパス、ディレクトリは 3.1.4. Yocto BSPのセットアップ 、 3.1.5. ビルドターゲットの設定、ビルド で設定したものです。 以下ではlinux-imxを例として、いくつかのコマンド例を挙げていきます。 "linux-imx"を別のパッケージ名にすれば、そのパッケージ毎に同様のことが可能です。 3.3.2. パッケージの再ビルド $ bitbake -c compile linux-imx -f $ bitbake -c install linux-imx $ bitbake -c deploy linux-imx 注釈 -fを付けない場合と手順がスキップされる可能性があります。 注釈 -c deployがエラーになるパッケージもありますが、ほとんどの場合はdo_deployコマンドが用意されていないだけですので、エラーは無視して構いません。 3.3.3. パッケージを消す あるパッケージで本来発生しないであろうエラーが発生する場合に、以下のコマンドでパッケージを消してやり直してみるとエラーが解消することがあります。 (ダウンロード時にパッケージが破損したり、ビルドを途中で強制的に終了した場合にゴミデータが残ったりしている場合があるためです。） $ bitbake -c cleansstate linux-imx 注釈 展開したソースコードごと削除されますので、編集しているファイルなどがある場合はご注意ください。 3.3.4. パッケージの展開 パッケージの展開だけを行い、コンパイルなどはまだやりたくない場合 $ bitbake -c patch linux-imx 3.3.5. configファイルの変更を反映させる configファイル（arch/arm64/configs/imx_v8_defconfigなど）を変更し、それを反映させたい場合 $ bitbake -c configure linux-imx $ bitbake -c compile linux-imx -f 3.3.6. linux-imx menuconfigを行う Linuxカーネルのビルドオプションを変更する場合 $ bitbake -c menuconfig linux-imx このようなウィンドウが起動するので、必要な変更を加えてSaveします。（十字カーソルキーで対象を選択し、スペースキーで決定） ビルド時のTIPSについては、以下の記事を併せてご参考ください。 Yocto Linux BSPのビルド時におけるTIPS集 - i.MX 8M Plus編 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） お手頃な値段で、コンパクトに組み込みLinuxを開始できるFRDM(フリーダム)ボードを用いて、Linux BSPのビルド手順を紹介します。 本記事ではFRDM-IMX93をベースに紹介しますが、他のi.MX FRDMボードでも同じ手順でビルドすることができます。 Yocto Linux BSPは、「Linux 6.12.49_2.2.0 (Yocto 5.0.4)」を例に記載しています。 i.MX Processors SW | Downloads 日本語ブログ

FXTH87xx 最低功耗 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大家好 我正在调试 FXTH870911 的功耗。 目前的最小电流为 98-115μA。 经过计算，目前的耗电量无法满足需求。 我想知道该芯片的最小工作电流是多少，以及它是如何实现的。 提前感谢！ Re: FXTH87xx minimum power consumption <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好， 下面是 25°C 时的典型电流消耗： 您可以在设备数据表中找到停止模式的详细描述。 在项目中，如果选择了 LF_COMMUNICATION（通信）模式，则在 STOP1 中启用 LF 块。   模式的选择应在项目的 user_configuration.h 文件中进行。 在该文件中，可以选择三种不同的模式，一种使用 LF（LF_COMMUNICATION），另两种不使用 LF。 我建议选择 NO_LF_PWU 模式：在该模式下，FXTH 会定期唤醒以发送 RF 帧，在两次发送之间，FXTH 会转到 STOP1 并禁用低频。在这种模式下，两次射频传输之间的功耗应为 500nA。 顺祝商祺！ 托马斯 PS：如果此答案有助于解决您的问题，请标记为"正确" 或 "有帮助"。谢谢。

S32K311 中的 JTAG 网络安全关于网络安全级别和大规模擦除 你好、 我想知道锁定和解锁过程的步骤。 能否在 S32K311 微控制器中实现大规模擦除和解锁机制？ Re: JTAG security in S32K311 about Security levels and Mass erase 你好@truptikavadi1、 谢谢您的帖子。 不，S32K1xx的工作原理与您描述的完全相同，但S32K3xx 并非如此。 如果您想获得与 S32K3xx 网络安全相关的更多信息，请注意，由于这是 K32L 频道，该产品不在我的支持范围内。 我建议在S32K - 恩智浦社区上创建一个新的帖子，那里的相关支持者将能为您提供进一步的帮助。 感谢您的理解。 BR 西莱斯特   ---------------------------------------------------------------------------------------------------------------------- 注：如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。Thank you! ----------------------------------------------------------------------------------------------------------------------

DMA MUX Currently I am using, S32 Platform 3.4 programming environment, RTD is 2.0.0 During my use of DMA I found that the RM module I created does not have a Dma Mux, how to solve this situation. Re: DMA MUX Thank you. Re: DMA MUX Hi @xuanming  The example was implemented using a newer RTD version than the one you are currently working with; therefore, changes were introduced to the driver implementation. As you are working with RTD 2.0.0, you should refer to the Dma_Ip driver. Starting from RTD 3.0.0, the DMAMux Source configuration was moved to the RM module at the MCAL layer, which explains the difference you are observing. Additionally, we recommend updating to the latest RTD version whenever possible. This helps avoid known issues and ensures you benefit from the most recent fixes, enhancements, and improvements. BR, VaneB

无法调试 i.mxrt1064 自定义板。 您好， 在尝试以调试模式运行我的代码时，我收到"Break at address"0x20d102" with no debug information available" 信息。 我正在使用 i.mxrt1064 自定义板并使用 LinkServer LPC-Link2 进行编程。 这个主板以前可以正常工作了，但现在突然间，出现了这个消息。 我试过版本模式。我可以成功地用版本代码刷新我的主板，但是程序似乎无法运行。无论是从串行终端还是从显示屏，我都看不到任何输出。 我还尝试过使用安全配置工具对这个板进行编程，但它仍然无法正常工作。 有谁能帮助我们找到这个问题的重点或线索？ Re: Unable to debug i.MXRT1064 custom board. 你好，MayLiu、 感谢您的回复。 早些时候，我确实按照你的建议尝试了这种设置，但在尝试调试时，集成开发环境提示错误（未能执行 MI 命令：-target-download）。我附上了该错误的快照供你参考。 回到上一条信息，我想补充的是，当我检查当前程序的执行地址时，显示代码位于 ROM 区域（地址 0x20E35A）。因此，不知何故，代码无法到达/启动应用程序代码，并被卡在 ROM 中。我的假设正确吗？会有这种情况吗？ Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 非常感谢您关注我们的产品并使用我们的社区。 1: 请尝试选择将应用程序链接到 RAM，然后重新调试。 如果您的应用程序可以从 RAM 成功运行，请将板设置为串行下载器模式，然后使用安全配置工具通过 UART1 或 USB1 对您的板进行编程。   如果你的应用程序无法运行，我建议你使用示波器来检查主板的开机顺序。   希望它能帮到你。 顺祝商祺！ MayLiu Re: Unable to debug i.MXRT1064 custom board. Hi MayLiu, 感谢您的建议。 我想检查一下 MCUXpresso 中是否有任何可以改变或影响启动 Conf 的设置/配置？只是为了排除 IDE 的可能性。 在串行下载模式下，链接服务器能够检测目标。 Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 感谢您提供的最新信息。 根据您提供的信息，CPU 当前可能正在执行来自启动 ROM 的代码，而不是您的应用程序代码。   我建议检查启动CFG和启动模式引脚设置，确保设备配置为从用户闪存启动。   你也可以尝试将板设置为串行下载器模式，然后通过J-Link进行连接以确认调试器是否可以检测到目标并与目标通信。   顺祝商祺！ MatLiu Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 我认为MCUXpresso IDE不会更改启动配置，恩智浦RT的启动行为由硬件启动配置和启动模式引脚决定。 由于可以在串行下载模式下检测到目标，这表明 ROM 仍在正常运行。下一步，您可以 执行全芯片擦除、 将板切换到内部启动模式，然后 尝试重新连接 MCUXpresso IDE 进行调试。 或者，您也可以使用 MCUXpresso 安全配置工具对应用程序映像进行编程。 顺祝商祺！ MayLiu

QSPI 1 で MGC アクセス制御を無効にするにはどうすればよいでしょうか? 私は、カスタム ドライバを使用して S32E2 評価ボードで QSPI を動作させることに取り組んでいます。EMMC からのブートから QSPI からのブートに切り替えるプロセス中であるため、JTAG を使用してコードをロードし、RAM が不足しています。評価ボードには、QSPI フラッシュが QSPI1 B に接続されています。主に SFAR などの特定のレジスタへの書き込みに問題があります。SFAR は MGC によって保護されているようなので、ビット 31 (GVLD) をクリアしてアクセス制御を無効にしたいと思います。ただし、リファレンス・マニュアルによると、MGC にアクセスできるのはバス・マスタ 0x1F のみであり、これが HSE コアです。QSPI0 のこれらのレジスタにアクセスできるバス マスターを変更できる HSE_QSPI0_DAT0 の形式で QPSI0 のバイパス メカニズムがあるようですが、QSPI1 に相当するものを見つけることができませんでした。 誰か助けてくれませんか？ Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 NXP サポートにお問い合わせいただきありがとうございます。ご質問に関してですが、おっしゃったレジスタにアクセスするための正しい方法を検索するのに少し時間が必要です。 現時点では、S32ZE RTD 2.0.1 で提供しているQspi_Ip_Example_S32Z2XX_R52またはMemAcc_Example_S32E2XX_R52サンプル プロジェクトを確認することをお勧めします。これらのプロジェクトでは RTD が使用されていますが、S32Z/E ファミリで QSPI を使用するために必要な手順を把握することができます。 よろしくお願いします。 Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 返信が遅くなり申し訳ありません。セクション65.1.6 QuadSPI_0とセキュリティレジスタの相互作用[ページ3349、S32Z2リファレンス・マニュアル、Rev. 5、2025-01-28]、セクション121.2.1.5 QuadSPI_0データ0 (HSE_QSPI0_DAT0) [ページ6674] の表もご確認ください。表の最初の行では、HSE_QSPI0_DAT0の値に応じて、MGCレジスタにアクセスできるマスターIDを設定する方法について説明しています。 問題を解決できたかどうか教えてください Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 混乱させてしまい申し訳ございません。さて、私が理解しているのは、元々の問題は克服されたということですが、それで正しいでしょうか? IP コマンドを送信するための最適なフローをチェックするには、サンプル プロジェクトMemAcc_Example_S32E2XX_R52を確認してください。特に、関数Qspi_Ip_StatusType Qspi_Ip_IpCommand ()と、それが静的 Qspi_Ip_StatusType Qspi_Ip_InitReset()およびQspi_Ip_StatusType Qspi_Ip_RunCommand() でどのように呼び出されるかを確認してください。 他にご質問があればお知らせください。 Re: How do you disable MGC access control on QSPI 1? 私はその部分をすでに見ていましたが、それは QuadSPI 0 のみをカバーしているようで、私はこれを QuadSPI 1 で実行しようとしています。その間に、MDAD および FRAD レジスタをプログラムしてすべてのアクセスを許可する方法を見つけ、IP コマンドを開始すると SFAR にデータが設定されるようですが、現在はビジー状態になっているため、MGC ですべてを無効にする必要はないかもしれません。 Re: How do you disable MGC access control on QSPI 1? MDAD/FRAD を設定し、LUT をプログラミングした後、IP コマンドを開始できるようになりました。フラッシュ通信の最初のステップとして、S32E288-975EVB 評価ボード上の Micron MT25QL256ABA8E12 からシリアル フラッシュ検出パラメータを読み取ろうとしています。スロット 8 に次の LUT シーケンスを設定しました。 コマンドパッド1 0x5A アドレスパッド1 24 ダミーパッド1 8 パッド1 16を読み取り 停止パッド1 0 シーケンスは開始しているようですが、その後、無限にビジーな状態に陥ってしまうようです。SFAR は 0x10000000 (設定された開始アドレス) に設定され、IPCR は 0x08000008 (スロット 8、8 バイト) に設定されます。BUFXCR レジスタは、バッファ 3 を除いてすべてサイズ 0 に設定し、バッファ 3 はすべてのマスターに設定しました (値 0x80004000)。金曜日に、オシロスコープで CS0/D0/D1 ピンを調べることができ、IP コマンドが開始されると CS がアサートされるものの、デアサートされないことが分かりました。コマンドとアドレスが送信され、その後にダミー サイクルが続き、その後 D1 がアクティブになってデータに応答するように見えます。しかし、読み取りは完了せず、ただノンストップでデータをクロックし続けているように見えます。フラッシュ チップが SFDP バッファを何度も繰り返して循環するため、D1 に繰り返しパターンが表示されます (少なくとも私はそう推測します)。 実行を一時停止すると、次の画面が表示されます。 読み取りが完了しない原因が何なのかはわかりません。QSPI 読み取りに関するデータシートのセクションを読みましたが、この動作を説明するものは見つかりませんでした。クロックを下げてみました (ビット タイミングを見ると最初は約 100 MHz のようでしたが、その後 CGM に /10 分周器を追加したところ、D1 のビット パターンが遅くなりましたが、ビジー動作は変わりませんでした)。 Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 メモリのデータシートを見ると、SFDP (0x5A) は「通常の」操作ではなく、コントローラが通信フローを意図的に停止する必要があるようです。 これにより、読み取りが完了しない理由を説明できます。私の見るところでは、QSPI ペリフェラルは動作しており、少なくとも通信は行われているので、現時点での問題は操作の種類にある可能性があります。もっと簡単な操作を試してみませんか？例えば、私が言及した例では、 Qspi_Ip_Cfg.c の MemCfg_0_SPI3ByteAddress_paInitOperations_0 と MemCfg_0_SPI3ByteAddress_paLutOperations_0 という LUT シーケンスが見つかります。初期化操作については、 Qspi_Ip.c の Qspi_Ip_InitOperation () でどのように使用されているかを確認してください。 別の操作を実行して、異なる動作が表示されるかどうかを教えてください。 よろしくお願いします。 Re: How do you disable MGC access control on QSPI 1? 結局、問題は DLL を適切に設定していなかったことにありました。私は S32DS の例に従って DLL バイパス モードの初期化シーケンスを実行し、それをコードに再実装したところ、読み取り操作が正しく完了するようになりました。次の課題は書き込み操作ですが、この問題はCANとして解決済みとしてマークできます。

Import and start developping Using Visual Studio Code (VSC) on KW47 As the support for MCUXpresso IDE as GUI and toolchain will be stopped and will be replaced by MCUXpresso for Visual Studio Code, I am sharing here some essential steps to start development on Visual Studio Code and MCUXpresso plugin. Preparation: - MCUXpresso for VS Code is installed as an extension inside Microsoft VS Code - see https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-for-visual-studio-code:MCUXPRESSO-VSC - The rest of the toolchain including ARMGCC, west and other tools which work with MCUX for VS Code installation is available via MCUXpresso SDK option of the MCUXpresso Installer: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-installer:MCUXPRESSO-INSTALLER - See also generic Getting Started Guide for MCUX SDK with MCUX for VS Code at: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/run_a_demo_using_mcuxvsc.html Here I will provide the procedure to import the loc_reader example from the repository. Import the repository: The recommended approach is to import REMOTE ARCHIVE which has a similar environment as the legacy MCUXpresso IDE. Here I will provide the procedure to import the loc_reader example from the repository From the MCUXpresso plugin, select "Import Repository", then in the "REMOTE ARCHIVE" tab, select the board, the SDK version and the location: Wait for the repository to be imported, this procedure can take several minutes. Once the import is succeed, it will appear here: Import demo projects and run: Once the repository is successfully imported, you can then import demo examples from the repo by selecting "Import Example from Repository": then select the demo example from "Template". "AppType" should be "Freestanding application" if you want a standalone project. "Location" is where the project will be located.  "Toolchain" should be the Arm GNU one that you installed in preparation steps Build and run the imported project:

高レベルの宣言型UIフレームワーク i.MX RT クロスオーバー MCU 用の高レベルの宣言型 UI フレームワークはありますか?Swift や JavaScript のような高級言語でコードを記述し、SwiftUI や React に似たものを使用して UI を作成できるようになりたいです。 Re: High level declarative UI framework こんにちは@MatthewRuzzi 、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 NXP は、LVGL を基盤フレームワークとして、お客様が UI ソフトウェアを迅速に開発できるようにするために、GuiGuider ツールを公式に提供しています。さらに、SDK には emWin および VGLite のサンプル プロジェクトが含まれています。高水準言語の実装は現在公式にはサポートされていませんが、次のアプローチを検討することをお勧めします。 1. https://doc.qt.io/QtForMCUs/qtul-zephyr-mimx1060-evk.html https://www.embeddedartists.com/wp-content/uploads/2023/06/QtMCUs_ProgramDevelopment.pdf 2 https://www.nxp.com/design/design-center/training/TIP-CREATE-USER-INTERFACE-QT 3. https://docs.microej.com/en/latest/GettingStarted/gettingStartedIMXRT1170.html 4. https://github.com/lvgl/lv_micropython 5. https://www.swift.org/blog/embedded-swift-examples/ これらのリソースがあなたの成長に刺激を与えることを願っています。 よろしくお願いします、 ギャビン Re: High level declarative UI framework 現在これに取り組んでいるプロジェクトはありますか?Swift や JavaScript のような言語を使用できるようになりたいです。将来的にこれを可能にするために私ができることはありますか?機能リクエストを送信または投票する場所、またはこれを投稿する他の場所はありますか?

i.MX93 M33 Core: How to get System Uptime (sec/nsec) for micro-ROS on Custom Board? Hi everyone, I am currently porting micro-ROS to the Cortex-M33 core of an i.MX93 (MIMX9352) using a custom SOM and the MCUXpresso SDK (v25.06.00).  have successfully established a UART transport and connected to the micro-ROS agent. My nodes and topics are created, but published data appears empty/invalid. After debugging, I’ve realized I need to provide high-resolution timestamps (seconds and nanoseconds) to the micro-ROS client to synchronize with the ROS 2 ecosystem. Screenshots, Debug terminal output, Codes are attached below. Micro-ros agent connection Micro-ros agent connectionMicro-ros agent connectionMicro-ros agent connection ROS Topic listing (Topic is emtpy (data not publishing)) ROS Topic listing (But topic is empty)ROS Topic listing (But topic is empty)ROS Topic listing (But topic is empty) Debug terminal output: Debug Console Init done Past lpuart init and custom trnsport open Past rclc support,node,publisher init Past rclc timer init Past rclc executor init, add_timer Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin The Problem: I am struggling to find a reliable "System Uptime" or "Tick" function in the SDK that provides the precision required for rmw_publisher_publish. I tried using the lptmr driver examples, but the code hangs during LPTMR_Init() My Questions: Is there a recommended SDK API for getting a high-resolution (nsec) monotonic timestamp since boot on the i.MX93 M33? For those who have implemented micro-ROS on i.MX9 series: Did you use a dedicated hardware timer, or is there a standard CMSIS/SDK "GetTime" function I should be using instead? Environment Details: Hardware: Custom i.MX93 SOM + EVB Baseboard Core: Cortex-M331 SDK: 25.06.00 Toolchain: MCUXpresso IDE / VS Code Extension2 Any insights or code snippets for a 64-bit nanosecond counter implementation on this platform would be greatly appreciated! Regards, Anandhu Re: i.MX93 M33 Core: How to get System Uptime (sec/nsec) for micro-ROS on Custom Board? Hi, I have tried the tstmr.c demo program in the SDK example. It's not working as expected, tried in two different boards one custom board and avnet osm93, both of them doesn't gave any output in the terminal. Upon debugging it's the TSTMR related functions are not working, the program's not going past "TSTMR_ReadTimeStamp()". SDK Used : MCUXpresso SDK (v25.06.00).

CSEC GenerateMACAddrMode アドレス範囲 メリークリスマス こんにちは CSECのGenerateMACAddrMode関数を使用していたところ、アドレス値が0x7DFFFを超えるとエラーが発生します。これは普通ですか？ Re: CSEC GenerateMACAddrMode address range 私のせい つまり512KBからCANができない CSEC_DRV_GenerateMACAddrMode(CSEC_RAM_KEY、(uint8_t *)0x0007FFFC、0x00000080、(uint8_t *)cmacout); ただし、addr = 0x0007FFFC、len = 0x00000080 を使用します エラーもありませんが、範囲外です Re: CSEC GenerateMACAddrMode address range こんにちは@SaLan これは、Addr モード（ポインター方法とも呼ばれます）の CMD_GENERATE_MAC コマンドの制限です。 パーティション（つまりブロックサイズは派生に応じて128KB、256KB、または512KBになります。 よろしくお願いいたします。 ルーカス

先进的电机控制协处理器 我希望对高级电机控制协处理器有更深入的技术了解。 能否请您向我提供详细描述该外围设备的相关文件和技术介绍？ 特别是，如果能说明该模块与双 eFlexPWM / NanoEdge PWM 模块（2×，各 8 个通道）的区别或连接，包括任何功能重叠、交互机制或预期用例，我将不胜感激。 由于高级电机控制协处理器被强调为提供 16 通道可编程 I/O 定时器，而 eflexPWM 代表一组专用的电机控制 PWM 定时器，我想更好地了解这两个子系统在整个电机控制架构中是如何相互补充的。 Re: Adv. MotorControlCo-Processors 你好 通常，参考手册中描述了诸如eTPU、flexPWM、eMIO之类的电机控制定时器的操作。 在S32K39/37/36设备上，恩智浦包括eTPU：一种可编程的微编码定时引擎，具有自己的指令和数据RAM，旨在减轻实时I/O定时任务（PWM波形整形、换向调度、传感器解码、捕获/测量等）。这就是恩智浦材料中所说的 "高级电机控制协处理器"。 在更广泛的 S32K3 系列中，恩智浦重点推出 eMIOS（增强型模块化 I/O 子系统）和 LCU 作为标准电机控制定时器/逻辑组合。eMIOS 是一个高度灵活的 16 位定时器子系统，具有多种通道和模式（缓冲 PWM、中心对齐、死区互补、单脉冲/DAOC、输入捕获等）。由于 eMIOS 每通道占用空间小，边缘处理灵活，因此许多社区文档将其非正式地称为 "NanoEdge PWM "式模块。 如果您使用的是 S32K39 并需要最大限度的确定性或复杂的时间表（解析器、多电机换向、自定义波形），请使用 etPU 作为监控器；将 eflexPWM 连接到功率级；使用 emIO 进行辅助定时/捕获；为 ADC 窗口连接 TRGMUX/BCTU。 如果你使用的是 S32K344/358（没有 eTPU），请为反向器选择 eflexPWM，然后使用 emiOS + LCU/TRGMUX/BCTU 来管理捕获/触发信号/辅助 PWM。RTD 的 PWM 驱动程序可让您在一个配置中混合 eFlexPWM 和 eMIOS 通道。 具体实施可参考以下文献： S32K3xx DS（Rev.13，2025-11-12），设有& 区块。[nxp.com] 用于 eTPU/eMIOS/LCU 的 S32K39/37/36 DS 时序部分。[nxp.com.cn] S32K396 LV MC 套件（明确的 "eTPU 电机控制协处理器"）。[nxp.com] S32K3 电机控制手册（名为 eMIOS、LCU、触发信号、ADC/CMP）。[nxp.com]、 S32K3 系列手册（注明 16 位 emiOS 计时器）。[nxp.jp] RTD PWM 驱动器讨论（eFlexPWM 包含在统一 PWM 中）。[community.nxp.com] emiOS 使用指南 & 示例（OPWMB/OPWMCB/DAOC/OPWFMB，捕获模式）。[community.nxp.com] 使用 eMIOS 的单脉冲 PWM（DAOC/OPWMB 示例）。[community.nxp.com] 致以最诚挚的问候， Peter

S32K358 基于 AUTOSAR 驱动程序的 HSE 随机数生成器 亲爱的支持者 客户 Aptiv 与 S32K358 合作 RTD 版本：Crypto_43_HSE_TS_T40D34M60I0R0 HSE FW 版本：HSE_FW_S32K358_9_2_72_0 在尝试在微控制器上集成加密RTD并刷新HSE固件后生成随机数时，我们观察到一个问题，即固件似乎停留在HSE_IP_ServiceRequest () 函数上，特别是在等待 mu_IP_isResponseReady () 时。请查看随附的调用堆栈屏幕截图以参考。 请您帮助我们理解： 固件卡在这一点上的可能原因是什么？ 解决此问题的建议方案或调试步骤？ PS: 我已在 BSWM 配置中配置了 CSM_Init、CriIf_Init 和 Crypto_Init 在 Vector Davinci 中配置的 CSM、CryIf，从 BSWM_Init 调用中调用的 CSM、CryIF、Crypto 的初始函数。使用 Demo APP 安装了 HSE，并通过读取版本号和 MU 状态寄存器进行了验证，如下图所示： 客户要求提供基于 AUTOSAR xdm 配置 CSM、CriIf 和 Crypto 驱动程序的 AUTOSAR 示例（而不是 DEMOAPP 的代码）。附上他们的 Crypto xdm 文件。 (到目前为止，恩智浦方面的 Sunny X 和 Dhan Raj 参与了一次调试呼叫，但我们尚未找到最终的根本原因......）。 顺祝商祺！ 维克托 板：S32K358 优先权：紧急 SW 变体：标准 Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 你好 Cuong、 我们得到了帮助和[email protected]创建了一个例子。 让我们把这张票保留到下周客户试用时。 我会允许你访问 Sharepoint 上的示例。 顺祝商祺！ 维克托   Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 你好@viktorfellinger ，我正在为你创建一个示例。 同时，您能否告诉我： 1.您多久会遇到这个问题？是经常发生还是偶尔发生 2.pRequest 的值 pRequest 和 pHseSrvDesc 的 值。 Hse_Ip_ServiceRequest() 时的 pRequest 和 pHseSrvDesc 值。 您能否尝试增加 pRequest中的超时值 ，看看能否解决这个问题？ Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 您好@viktorfellinger ，您收到反馈了吗？ 如果没有更新，我想关闭这个话题。 客户稍后可以提出另一个问题，然后您可以再次提及此主题

KW45 硬件设计建议 亲爱的恩智浦团队， 我想知道，如果我不将下图中给出的外部迹线从 CDD_CORE / VOUT_CORE 连接到 VDD_CORE，会出现什么问题。 我以为是一样的，所以没有从外部电路连接。会有问题吗？ 我遇到了一个奇怪的问题，能告诉我是什么原因吗？ 当电压从 3.1V 降到 3V 时，射频下降。 MCU 似乎能正常工作，因为我们实现了 LED 闪烁。 在某些情况下，如低于 2.5V 时，MCU 可以工作，但射频输出是错误的。 在某些情况下，例如电压低于 2.5V 时，MCU 会完全停止发送数据，我们可以看到大约 7/8/9/12mA 的持续功耗。 我无法理解，因为当我们降低电压或低电压时，总是会出现这种情况。 KW45B41Z-EVK KW45 BLE-NFC   如果两个引脚都是内部连接的，会有问题吗？ Kinetis K系列MCU Re: KW45 HW Design Recommendation 你好 希望你一切顺利。 您在设计中使用的电源配置是什么？您是如何为 VDD_RF 供电的？ 有关最常见的电源配置和注意事项，请参阅 AN13831 KW45/K32W148-电源管理单元硬件第 3 节 " KW45/K32W148 电源配置 "。 请注意，您的应用程序要求的任何电源配置都必须符合每个功率域的直流电压要求，该要求在第 2.2 节 " 电源域速率 " 中规定 内部稳压器输出由 VDD_CORE/VOUT_CORE 提供，稳压器输入由 VDD_CORE 提供。强烈建议在外部连接引脚以及适当的去耦电容，以提供反馈路径并保持电压稳定性。 您可以在这篇文章中找到我们的最低物料清单演示文稿，了解推荐的电容值和其他硬件建议：使用 KW 45（汽车）或 K32W1/MCXW71（物联网/工业）首次版本 PCB 的最佳方式 您还可以根据我们的 KW45-EVK 原理图来 确认您的 原理图 设计。 顺祝商祺！ 安娜-索菲亚

使用 “tk (密码块链接(CBC) (aes))” 进行文件系统加密时出现 imx8mm CAAM 错误 使用CAAM写入文件系统时使用`t k (密码块链接(aes)) `进行文件系统加密时出现以下错误。 caam_jr 30902000.jr：4000141c:DECO： desc idx 20：DECO看门狗定时器超时错误 这种情况只是偶尔发生，但在启用所有内核运行时似乎更为普遍。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 很抱歉延迟回复。 我们使用的是 Phytec 公司的 `linux-imx_5.15.71_2.2.2-phy5`，并打上了https://github.com/Freescale/linux-fslc/tree/5.15-2.2.x-imx至 5.15.183 的补丁。 不幸的是，这个问题只是偶尔出现（在跨多个单元的 CI 测试中，每 500 小时左右才会出现不到 1 个实例），而且我还无法创建一个简单的重现器。 最初尝试启用 “CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG” 会阻止我们的设备启动，因为我们正在使用 CAAM 加密根文件系统和各种数据分区，这会生成过多的日志记录。 我正在考虑将日志信息添加到循环缓冲区中，并在错误发生时发出。 由于这只会导致最后 1000 条左右的记录被发出，我想知道是否有任何设置信息是我们应该始终记录的，以支持分析。 谢谢！ 丹尼尔 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 你能否分享一下你正在使用的电路板支持包 版本以及出现问题时的步骤和日志？ 此致 哈维 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 不幸的是，我无法使用其他工具进行重现 😞 我已经添加了最后 2048 条 CAAM 故障日志信息的记录，现在我们正在等待故障在 CI 中再次发生。 我收到日志后会尽快发送给您。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 看门狗超时错误是由 DECO 暂停时触发信号的，但是有多种情况可以让 DECO 暂停，例如输入/输出缓冲区地址、长度等。 你能用 "dd" 或 "fio" 工具进行压力测试来重现这个错误吗？ 如果问题能够稳定重现，就能帮助我们找到根本原因。 此致 哈维 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 最后，记录失败。 这应包括 CAAM 子系统的最后 2048 条日志记录。 与标准日志记录的唯一区别是不包括 `src` 和 `dst` 缓冲区数据。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 请注意，出于省电的考虑，我们降低了 CPU 和 DDR 的运行速度，这可能会对结果产生影响。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 不，我无法用 dd 或 fio 进行重现。 在我捕获之前的日志的系统上，它只会偶尔发生（到目前为止每 2 个月一次）。 在另一个代码略有不同的系统上，这种情况每天至少发生一次。 我们认为这是在启动过程中加载大量共享库时造成的（在我获取日志的系统中并没有使用这些共享库）。 遗憾的是，我们无法轻易收集该版本的日志，但我们可以相对快速地测试补丁，看看问题是否得到解决。 以前的日志是否包含足够的调查信息？ 如果没有，还需要什么？ Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 简单查看我的日志后发现，在故障发生时，8 个队列请求中的第 8 个请求是产生 DECO 看门狗超时错误的原因。 在日志的早期部分，即使在处理其他偏移量序列时，似乎也很少有排队等待的请求（有时可能只有一个？ 这是线索吗？ 在此之前排队的 7 个请求似乎都能正确完成，因此可能是以下原因之一... 队列实际上只支持 7 个条目--在这种情况下，减少队列条目的数量可能会有帮助（在哪里可以更改？） DECO 看门狗超时从条目添加到队列时开始，由于处理 8 个条目所需的时间过长，超时也就结束了--在这种情况下，延长超时时间可能会有帮助（同样，如果可能的话，在哪里可以更改？） 这个具体请求实际上有问题，但在我看来，它与之前的 7 个请求等同，因此似乎不太可能出现这种情况 谢谢！ 丹尼尔 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 拿到日志后，我决定亲自深入研究。 当系统处于高内存负载但 DDR 仍以 400MT/s 的速度运行时（在我们的情况下有时为 100MT/s），CAAM 有时会产生看门狗错误。 eMMC 驱动程序会强制 DDR 达到 3000MT/s 的速度，但对于写入而言，这并不一定要等到加密完成后才会发生。 我们已经为我们的用例修复了这个问题，在 `caam_jr_enqueue () `中请求` BUS_FREQ_HIGH `，然后通过计划工作从 `caam_jr_dequeue () `再次将其释放。 这解决了文件系统访问问题，但在从网络堆栈调用时（例如通过 xfrm）会产生问题，因为 `request_bus_freq()` 最终会在原子上下文中被调用（从更高的网络堆栈调用），而且 `request_bus_freq()` 和 `clk_xxx()` 调用都使用了 mutex 我们已经解决了这个问题，在除文件系统之外的所有系统中禁用了 CAAM，但如果向上游推广，还需要更好的解决方案。

BD-SL-i.MX6 运行 Qt 5.4（Qt 公司出品） <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> BD-SL-i.MX6 以前称为 SABRE Lite 板，是一种低成本的 i.MX6 开发平台。该主板的最佳特性之一是其提供的强大软件支持。这篇文章介绍了 QT 公司的 Qt5.4。下面的视频展示了Qt 公司的企业设备创建产品，这是一个针对 Qt 优化的预构建软件堆栈，可让您立即开始在真实设备上进行嵌入式 Linux 和 Android 开发的原型设计。该演示运行 Qt5.4，并且该图像可用于 BD-SL-i.MX6 以及我们的 Nitrogen 系列产品。以下是一段简短的视频，展示了部分功能： 上面的视频展示了为嵌入式 Linux 创建的图像，更具体地说，是使用Yocto 项目和飞思卡尔社区 BSP 的工具构建的。因此，您的产品可以利用这些项目提供的软件包，并且您可以使用 Yocto 构建系统来集成您的组件并定制您的构建。 有关更多详细信息，请访问http://qt.io或http://boundarydevices.com/qt-for-device-creation/ 概述

【恩智浦微控制器简介】【电机控制】【实践篇 2】永磁同步电机的机理及控制方法（日文博客） [实验0_2] 环境搭建 + 运行电机示例代码②   目录   5. 软件安装 5-1。启动 MCUXpresso 5-2。从 SDK 导入示例演示 5-3。从调试模式切换到发布模式 5-4. 建设项目 5-5. Flash编程 6. 连接到实时调试工具 运行演示 7. 操作检查和故障经验 8. 调试 9. 部分软件代码的解释 10. 总结与预览   5. 软件安装 接下来，我们将从工程师的角度详细解释实际设置开发环境和运行示例代码的过程。 为了帮助即使是第一次来的游客也能避免迷路，我们将介绍一些常见的陷阱和有用的技巧。 5-1。启动 MCUXpresso 首先，启动 IDE（MCUXpresso）。 安装完成后，会立即出现“欢迎屏幕”，请从这里开始。 提示 ：首次启动可能需要一些时间，请耐心等待！ 5-2。从 SDK 导入示例演示 SDK（软件开发工具包）包含许多示例项目。 这次我们将使用名为“mc_pmsm_enc”的示例来控制带编码器的永磁同步电机。 选择“MCXA156” 选择“frdmmcxa156” 点击“下一步” 在“示例”列中搜索“pmsm”，并选中“mc_pmsm_enc”。 点击“完成”以完成导入！ 提示 ：如果您不确定样品名称，请尝试搜索“pmsm”或“motor”，以便更容易地找到它。   5-3。从调试模式切换到发布模式 项目导入完成后，首先切换到“发布”版本。 调试版本也能用，但发布版本优化得更好，更适合在真机上运行。 使用 USB 电缆将 MCU-Link 连接器连接到 PC。 点击“建造”图标开始建造！ 接下来，点击“GUI Flash Tool”图标 点击 在写入闪存之前，请确保调试器已被正确识别。 故障排除 如果调试器无法识别，拔下并重新插入 USB 电缆或重新启动电脑可能会解决问题。   5-4. 建设项目 构建完成后，将在项目的“Release”文件夹中生成一个二进制文件。 如果出现错误，请再次检查 SDK 版本和导入步骤。   5-5. Flash编程 使用“GUI Flash Tool”向目标板写入数据。 编写完成后，您终于可以在实际设备上运行示例了！ 6. 连接到实时调试工具 接下来，我们将使用 FreeMASTER (MCAT) 实时观察电机状态。 在 IDE 的“项目资源管理器”中，双击 motor_control 文件夹中的 pmsm_float_enc.pmpx 以启动 FreeMASTER。 体验 当我第一次看到波形实时移动时，我惊叹不已，脱口而出“哇！”   与董事会沟通 点击左上角的绿色“开始！”按钮即可开始通讯。 如果您无法正常沟通， 在“项目”菜单→“选项”→“通信”选项卡中选择正确的 COM 端口（115200bps）。 尖端 如果您不知道 COM 端口，请尝试“COM_ALL”，它可能会自动检测！ 运行演示 演示终于开始了！ 按下主机板上的SW2按钮，电机就会开始旋转。 速度屏幕以图表形式显示实际旋转速度，以便您可以一目了然地看到运动情况。 令人印象深刻的是 ：当马达第一次转动时，我忍不住大喊：“耶！” 实时观察图表的变化也很有趣！ 7. 操作检查和故障经验 关闭演示程序，然后断开电机电源（DC24V）。 MCAT屏幕将显示故障原因，主机板上的红色LED指示灯将闪烁。 重新接通电源，LED 停止闪烁后，点击“M1 故障清除”清除故障。 重要提示 ：如果故障仍然存在，电机将无法运转，因此请务必清除故障。 自由控制电机转速！ 当您在“速度”屏幕上打开“M1应用程序开关”时， 应用程序启动后，您可以根据需要更改速度。 如果你想朝相反的方向旋转，只需输入一个负值，例如“-1000”！ 玩法说明： 您可以尝试不同的速度和反转旋转，体验电机控制的乐趣！ 如果我与董事会沟通出现问题怎么办？ 如果您无法使用 FreeMASTER 与电路板通信， 转到“项目”菜单 → “选项” → “通信”选项卡，设置正确的 COM 端口和波特率 (115200bps)。 如果您不知道 COM 端口，可以尝试“COM_ALL”！ 8. 调试 调试功能允许您详细观察程序的运行情况。 设置断点以检查变量值和处理流程。 给初学者的建议 我们建议您从行为容易理解的区域开始调试，例如“主函数”或“中断处理”。 9. 部分软件代码的解释   项目详情 接下来，我们将向工程师们解释实际的项目结构和主要源代码。 项目结构 自由大师 一款实时调试监视器和数据可视化工具，支持运行时配置和调优。通过 UART/USB 通信，并包含 MCAT 插件。 电机控制 包括电机状态机、矢量控制代码、电机识别程序和底层驱动程序。 rtcesl 一系列用于复杂实时控制应用（包括电机控制）的数学库，涵盖从高级变换到观察器等各种功能。 来源 主要处理、初始化、配置等。 主处理和中断 main.c 执行初始化、中断设置和 FreeMASTER 通信等后台任务。 中断处理程序有两种类型：高速（ADC 同步）和低速（定时器同步）。 高速回路是矢量控制算法，低速回路是速度控制和 LED 状态管理。 要点 ： “motor_control” 文件夹包含电机控制逻辑。 如果您发现感兴趣的函数或变量，请务必查看注释和文档！ 10. 总结与预览 这次，我们有机会体验使用 NXP 的开发环境运行电机控制示例。 在下一期中，我们将深入研究示例代码，并尝试修改参数来创建您自己的电机控制系统！ （预计四月发布） 如果您有任何疑问或不理解的地方，请在评论区留言！ 这是一个汇总了有关恩智浦电机控制文章的网站： NXP电机控制 - 概要页面 - （日语博客） ============================​ 进行咨询时，请同时参考“如何就技术问题联系 NXP（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有业务往来，您可以直接联系负责人。） 本文将以浅显易懂的方式讲解如何使用NXP FRDM控制板“FRDM-MCXA156”进行电机控制。文章分为基础知识部分和实践部分，您可以先选择感兴趣的部分进行阅读。 ・基础知识①～⑦，实践①～③ 这次，作为实践部分的第二部分，我们将介绍从软件设置到实际运行电机控制示例代码的所有内容。 MCUXpresso 配置工具 MCUXpresso IDE MCUXpresso SDK MCX 电机控制 技术聚焦 日本博客

Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Running MCUXpresso IDE V25.6.136 + evkmimxrt685 board with SDK_25_12_00. When debug starts all debug tool (resume ..) are greyed out and cannot run the project.  Works fine with older SDK_25_03_00 but same problem with SDK_25_06_00 and SDK_25_09_00.  How can i restore the debug tools Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, Posting the screenshot> It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. It never get to the main() to start the run.  I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?.   Thanks  bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?. I do have a screenshot but how do i post it. Thanks @bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Could you please share which OS your compute has? Linux, Windows 10, Windows 11? Could you please review the BOOT_SEL of the EVK to be properly selected? Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing the details about your setup. Could you please do a mass erase of the flash, and retry to debug it?  To do it please change the link server action at the QuickStart Panel after that return it to Debug using LinkServer probes. Please share a screenshot if you have any error message in the process.  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 I am running Windows 11 on a Dell Alder Lake desktop. The boot jumper (JP1) is open which is the default according to the manual (MIMXRT685-AUD-EVKUM Rev 3 - 21 July 2023). I presume this is what you meant by "review BOOT_SEL of the EVK". Thanks bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos, Thanks. Before I do this i wanted to let you know that I have always used the SEGGER J-Link probes and there is "erase flash action using SEGGER J-Link probes" menu option. Should i erase using that or using the link server probes as you mentioned above. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos,  I tried to do a mass erase with the link server but got an error message - screenshot attached.  Thanks  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos,  I deleted the Flash using the Segger J-Link Probes (not the link server probes as that firmware was overwritten by the Segger firmware).  I understand I must use the Segger probes to debug both the ARM core and HiFi4 DSP.  I also updated the Segger firmware to the latest version 8.98.  I deleted the debug launch file,  deleted the workspace to generate a new one on bootup and also power cycled the board.  Still the same problem.  It says a debug session is running but I'm not able to debug.  As i said this happens with all versions after 03 (06, 09 and 12).  It stops at the startup_mimxrt685s.c file as before.    In the debugger console I do see a warning  message but this is probably harmless.  "warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report. monitor exec SetRestartOnClose=1 Please advise next steps. Thanks bobvr. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing that you are using. The issue persists if you try to debug with link server? Please share the error message in case you get one. 

S32K388CVB-Q289 Driving PTC21 Dear Team I am using S32K388CVB-Q289, and enabling the FlexCAN_0 along with the TJA1153 CAN0. I am connected a second node on the physical bus for testing porpose. But the FlexCAN_0 gets Ack errors upon transmission When I double check that the TJA1153 transceiver is enabled, I measure pin 5 in J95 But it reads ~2 Volts. And when I change the GPDO85 register between 0 and 1, the voltage read on the pin is not affected. Although I can see that pin is Set high in GPDO85 register, and that the Output driver is enabled in MSCR85 Configuration: Re: S32K388CVB-Q289 Driving PTC21 Hi, to check pin level simply remove J95.5-6 jumper and check MCU (5) and TJA1153 (6) side. Note TJA1153 has VIO connected to VDD_HV_B_PERH (VDD_HV_B 3.3V) using J804, while used MCU pins are on VDD_HV_A (5V) There is no need to drive EN pin, unless user want to switch between TJA1153 modes. Both EN and STB_N are pulled up to VIO by external resistors. STB_N should be driven low by MCU to allow local configuration if device is in Vanilla state. At the end of config TJA1153, STB is put back to Normal mode with EN, STB_N high. If you see message on the bus, but it is not ACKed, most probably it is due to inconsistent CAN bit timing between both nodes. Anyway, ready example for S32K388EVB is posted on  https://community.nxp.com/t5/S32K/Need-MCAL-working-CAN-Configuration-for-S32K388-EVB-bench/m-p/1923345/highlight/true#M38660   BR, Petr Re: S32K388CVB-Q289 Driving PTC21 Thanks for your response. The voltage levels seems now good. EN and nSTB go to high. Still I get Ack errors, with nothing appearing on the bus in my test measurement tool. Is it possible that my transceiver is in Vanilla state, and hence it is not operational till I configure it once? I read the example, but it would be way easier for my current setup to just send the CAN messages from test tool, rather than connecting the transceivers to each other. Can you share with me the initialization sequence, what I should send through CAN for a basic configuration that just send and receive (no security requirements needed)? Re: S32K388CVB-Q289 Driving PTC21 Hi, by default the device is in Vanilla state so must be configured, either from host or remotely. After configuration, the state can be changed, but in examples it is commonly kept in Vanilla state, so init is needed after each power on. If the posted example is working between FlexCAN modules on the board, it should work as well if just single one is connected to your CAN tool. In that example the ID being transmitted is added to the CAN0 transceiver's passlist, other configurations are left as default. You can refer to below example, done in IP level,  for another init sequence. https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K358-FlexCAN-TXRX-ISR-S32DS35-RTD400-500/ta-p/1981987 It expects transceiver in Vanilla state as well and set transceiver's passlist to pass all std and ext ID and do not block any message coming from bus. Finally leaving configuration mode without writing to non-volatile memory nor locking the transceiver (keeping Vanilla). BR, Petr

Understanding LPC55S6x Revisions and Tools At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                   NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will result in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:        Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1 Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer   LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect: For PRINCE encrypted region, partial erase cannot be performed Fixed Defect: For PUF based key provisioning, a reset must be performed Fixed Defect: Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect: Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect: PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:   The English and Chinese version documents are attached.   LPC Marketing LPC55xx 中国用户论坛