Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
SMI-N2003 Make Your Own 3D Printer with NXP Technology This class will show the benefits of NXP devices for 3D printing technology. The lecture will look at using microcontrollers, analog products, MOSFETs and other standard products as well as software algorithms like BLDC motor control to create a 3D printer. This class will show the benefits of NXP devices for 3D printing technology. The lecture will look at using microcontrollers, analog products, MOSFETs and other standard products as well as software algorithms like BLDC motor control to create a 3D printer. Smart Machinery & Industrial Automation
記事全体を表示
AUT-N1888 功率 MOSFET 在汽车应用中增强可靠性,提高效率 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次培训将讨论分立式功率MOSFET在动力总成、安全、底盘和车身控制等汽车应用中的使用,向将参会者介绍恩智浦最佳、最新的硅片和封装技术。 重点介绍采用电机控制燃料、机油和水泵的解决方案。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次培训将讨论分立式功率MOSFET在动力总成、安全、底盘和车身控制等汽车应用中的使用,向将参会者介绍恩智浦最佳、最新的硅片和封装技术。 重点介绍采用电机控制燃料、机油和水泵的解决方案。 观看视频演示 安全互联汽车和自动化汽车
記事全体を表示
USB ホスト大容量記憶クラス (MSC) の例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP SemiconductorsとOnChip Technologiesは提携して、USBホスト機能を備えたLPC1000、LPC2000、およびLPC3000ファミリのマイクロコントローラにUSBHostLiteソフトウェアを提供しています。これらには、LPC17xxシリーズ、LPC23xxシリーズ、LPC24xxシリーズ、LPC29xxシリーズ、LPC31xxシリーズ、およびLPC32xxシリーズのマイクロコントローラのメンバーが含まれます。USBHostLite は、OS レス環境で実行するための最小限のコードで USB 大容量ストレージ クラスのサポートのみを含む、簡素化された USB ホスト スタックです。USBHostLiteは、USBホストポートに接続されたUSBペンドライブ、USBハードディスクドライブなどのUSB大容量ストレージデバイス上のファイルにアクセスするための簡単なソリューションを提供します。 特長 USBHostLite は、次の機能をサポートしています。 オペレーティングシステムなしで動作 小さなメモリフットプリントが含まれています ソースコードはANSI Cで書かれており、IDEから独立しています 制御および一括転送をサポート FAT16ファイルシステムをサポート シンプルなファイルAPIにより、ファイルの読み取りおよび書き込み操作が可能 よく構造化され、理解しやすいソースコード 制限 NXPの無料のUSBHostLiteソフトウェアには、次の制限があります。 USBHostLiteは現在、Embedded ArtistsのLPC2468 OEMボードとKeilのMCB1760ボードにのみ移植され、テストされています。 大容量ストレージ以外のクラスはサポートされていません。 大容量記憶装置インターフェースは、最初の構成に存在する必要があります。 0 より大きい最大論理ユニット番号 (LUN) はサポートされていません。 FAT16 以外のファイルシステムはサポートされていません。 長いファイル名はサポートされていません。 ルートディレクトリ以外のフォルダにあるファイルにはアクセスできません。 アプリケーションで使用するバッファ・サイズは、4 KB を超えてはなりません。 注:このアプリケーションノートでは、USBHostLiteスタック全般と、特にEmbedded Artists LPC2468 OEMボードでのアプリケーションについて説明します。 ソフトウェア LPCソースコード用のUSBHostLiteは、NXPのお客様が無料で使用でき、NXPのLPC2000およびLPC3000ファミリのマイクロコントローラでのみ使用できます。USBHostLiteソフトウェアをダウンロードまたは使用することにより、これらのNXPマイクロコントローラーでのみ使用することに同意したことになります。Hitex LPC2939ボード上の LPC293x デバイスに移植されたUSBHostLiteスタック: LPC293x用のUSBHostLite VBeta 0.01 (2009/07/28) - 添付 Embedded Artists LPC2468 OEM ボード上の LPC2468 デバイスに移植された USBHostLite スタック: LPC23xx/LPC24xx用USBHostLite V1.00 (2010年1月4日) Keil MCB1760評価ボード上の LPC1768 デバイスに移植されたUSBHostLiteスタック: LPC17xx用のUSBHostLite VBeta 0.01 (2009/07/14) - 添付 OnChip Technologies LLCは、フル機能と量産品質の組み込みUSBスタックを必要とするお客様のアプリケーション向けに、USB仕様に完全に準拠し、優れた安定性と構成可能性を提供する組み込みUSBホスト/デバイス/OTGスタックを提供しています。 詳細情報 免責事項 このソフトウェアは、NXP Semiconductorsから現状のまま提供されます。NXP Semiconductorsは、情報提供以外の目的で、ここに含まれるソフトウェアをサポートまたは保証しません。サポートオプションやその他の組み込みUSBホスト/デバイス/OTGスタックなど、さらなる支援についてはOnChip Technologies LLCにお問い合わせください。 さらにサポートが必要な場合 オンチップテクノロジーズLLC LPC3000、LPC2000、およびLPC1000ファミリー向けのその他のプロフェッショナルUSBホストスタックソリューション CMXシステムCMX-USBホスト HCC組み込みUSB(EUSB)HostLiteスタック micrium μC/USBホスト マイクロデジタル smxUSBH Quadros RTXCusb ソフトウェア Thesycon組み込みUSBホストスタック
記事全体を表示
USBウェイクアップを備えた低電力モード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetisファミリには、豊富な低消費電力モードがあります。お客様は、低電力モードからウェイクアップする別の方法を理解するのに混乱する可能性があります。 1) VLPR では、VLPW: NVIC は割り込みの影響を受け続けるため、割り込みはすべて処理されます。 2)停止、VLPSでは、デバイスは USB ウェイクアップ割り込みによってのみウェイクアップできます。 3)LLSでは、VLLSx:デバイスはどの USB ソースから もウェイクアップ できません。 4) LLWUは ウェイク アップに使用されるため、お客様は利用可能なLLWU ウェイク アップソースのいずれかから ウェイク アップできます。 USBモジュールに関しては 、 USB 再開イベントには2つの異なる割り込みがあります。1つは、 USB ライン の状態の変化によって トリガーされる低電力モードから ウェイクアップ できるようにするための非同期です。もう 1 つは同期しており、K 状態 (フル スピードの場合は D+ = 0、D- = 1) を検出してから 2.5 us 後にのみトリガーされます。アプリケーションは、必要なときにいつでも低電力モードに移行する責任があり、この目的のために 、USB スタックによって報告されたデバイスの状態を確認する必要があります。バス で サスペンド状態が検出されると、SLEEP割り込みがトリガーされ、スタックの状態がサスペンドに変わります。その後、アプリケーションは低電力モードに移行します。この SLEEP 割り込みが発生すると、非同期 ウェイク 割り込みが有効になり、トリガーされると無効になります (これは、モジュールが割り込みをクリアするために必要です)。通常の状態では、同期再開割り込みまたはリセット割り込みが後でトリガーされ、スタックの状態が中断以外に遷移します。その後、アプリケーションは通信が再びアクティブになったことを認識し、再び低電力モードに入るのを回避できます。
記事全体を表示
FlexIOによるLEDパネル制御 [1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このプロジェクトの目的は、Kinetis K82マイクロコントローラに搭載されているFlexIOペリフェラルを使用してRGB LEDパネルを制御することです。 FlexIOペリフェラルは、GPIOビットバンギングやPWM + DMAを使用した他の制御方法と比較して、LEDの色と輝度情報を更新する過程で CPUをアンロード するという大きな利点を提供します。私は別の方法を使用します。 パネルは、WS2812BコントローラーとLEDストライプを使用します。また、アプリケーションを開発するためのシミュレーションプラットフォームも用意します。 ハードウェア: 30 x16 LED WS2812Bパネル マルチプレクサボード FRDM-K82の Uctronics QVGAディスプレイ ソフトウェア: IAR Workbench 7.50.1 (英語) SDK 1.3 for the Kinetis K82 FreeRTOS eGUIグラフィックライブラリ LEDパネルが機能している状態でビデオを見ることができます。 ビデオリンク : 4707 パート1:LEDパネルの構築 パート2:FlexIOを使用したLED制御方法 パート3:LEDパネルエミュレーション用ソフトウェア パート4:パネル制御用ソフトウェア モバイル Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 親愛なるグレイ、 ページが更新されましたので、ぜひご覧ください。 Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 親愛なるグレイ、 私たちは、ここで共有できるようにソフトウェアの更新に取り組んできましたが、現時点では、適切なライセンスを追加するまで、ソフトウェア以外のバージョンのみを共有することができます。更新されたソフトウェアが手に入り次第、オンラインにします。 参考までに、ここでも同様のプロジェクトがありますが、FlexIO:Kinetis K20によって駆動されるLEDビデオパネルは使用していません Re:FlexIOによるLEDパネル制御[1] <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは。このプロジェクトに感謝します。さまざまなドキュメントにアクセスできないようです。私は得ています: 不正 この場所またはコンテンツへのアクセスが制限されています
記事全体を表示
テクニカルレポート 裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ブラジル代表の浦野チームによるフリースケールカップWWファイナルズのテクニカルレポート <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ブラジル代表の浦野チームによるフリースケールカップWWファイナルズのテクニカルレポート Re:テクニカルレポート裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちはルーカス、私たちはそれらを強制するために最善を尽くしています...確かに、英語が一番です。 Re:テクニカルレポート裏野Brazil.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> テクニカルレポートは英語でなければならないと思いましたか? ルールは明確ですが、尊重されていませんか? それともエラーですか? よろしくお願いいたします
記事全体を表示
Microwave Heating at 915 Mhz Presented by tiefengshi Presented at DwF RF Solutions - Chengdu - 9 April 2015 Presented by Tiefeng Shi Presented at DwF RF Solutions - Chengdu - 9 April 2015 RF
記事全体を表示
下载 .sdcard使用 MFGTool 的 i.MX6sx SabreSDB 图像 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我遵循 Yocto 培训直到任务#4 - 部署和测试......但我被困在这里。 我无法下载 .sdcard图像到我的 SD 卡。我需要先格式化它吗?它是全新的。 由于sudo dd if=core-image-base -imx6solosabresd .sdcard of=/dev/sdb1 bs=1M对我不起作用,我无法从主板上的 SD 卡启动。主板开关设置为从 SD4 卡启动。imx6solosabresd 是用于 solox 的正确 MACHINE 吗?我尝试在 local.conf 文件中设置 MACHINE=imx6sxsabersd,但收到了错误消息(任务 #2)。 这就是我想要尝试 MFGTool 的原因。我已将主板设置为从 SD3 启动,以便它可以进入“下载模式”。当我浏览 MFGTool 时,它显示没有设备连接,尽管出现了符合 HID 的供应商定义的设备。 本文件是根据以下讨论生成的:
記事全体を表示
I2C NCSWの使用例 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NCSW(NetCommソフトウェア)は、フリースケールのPowerQUICCおよびQorIQプロセッサ・プラットフォームでの開発を迅速化するためのパッケージです。これには、NCDD(NetComm Device Drivers)およびその他のコンポーネントが含まれています。ここでは、バージョンGA_4.7でサポートされているP3041 I2Cを例にとり、NetCommソフトウェアの構造とデバイスドライバの使用状況を分析します。CW PA 10.3 は、ユースケースコードと互換性を持つために使用されます。
記事全体を表示
APF-ACC-T1551の <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、オートモーティブ・アプリケーションに最適なFreescale i.MX 6シリーズのアプリケーション・プロセッサの多くのインタフェースについて説明します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、オートモーティブ・アプリケーションに最適なFreescale i.MX 6シリーズのアプリケーション・プロセッサの多くのインタフェースについて説明します。
記事全体を表示
启动 LS1046A 当闪存为空或镜像损坏时,如何启动板卡?当根据需求修改 RCW 后,如何从各种启动模式启动板卡?本文档将以全新的 LS1046ARDB 板卡为例介绍相关功能(文档中所有目标板均为 LS1046ARDB)。 内容 通过 CodeWarrior TAP 启动 LS1046A 从 SD 卡启动 从 RCW 源文件编译 PBL 二进制文件 将 PBL 二进制文件编译为固件 将固件编程到目标板(LS1046ARDB) 从QSPI启动 从 RCW 源文件编译固件 将固件编程到目标板(LS1046ARDB) 从eMMC启动 启用板载 eMMC 从 RCW 源文件编译固件 将固件编程到目标板(LS1046ARDB) QorIQ LS1设备
記事全体を表示
[Sharing/i.MX8MP]Download image via USB OTG2 on i.MX8MP On i.MX8MP EVK, image is downloaded into eMMC/SD via OTG1, if customer wants to enable USB OTG2 on i.MX8MP for uuu tool. Pls find modification as attached. Linux Re: [Sharing/i.MX8MP]Download image via USB OTG2 on i.MX8MP How to use the files?
記事全体を表示
Porting PN7160 to Android 14 on i.MX8M Nano board Recently NXP released a combined NCI stack for both PN7160 and Pn7220. The newest Android 14 porting guide AN14430 brings the two (PN7160 and PN7220) together.   The pros are it is easy to maintain, and faster integration and switching between products.  The cons are when you are using PN7160, you will see for APIs for PN7220, including EMVCo and TDA API. When you are using PN7220 also APIs for PN7160 can be seen (card emulation on PN7160).  This article is a step-by-step guide on how to build AOSP for PN7160 with the new combined NCI stack.  1  Hardware setup   i.MX 8M Nano Evaluation Kit | NXP Semiconductors 8mn.jpg  OM27160| Development Kits for PN7160 Plug’n Play NFC Controller | NXP Semiconductors   7160.jpg The connection between i.MX8M Nano and PN7160 OM29110ARD-B i.MX8M Nano EVK pin PN7160  OM29110ARD-B 3.3V J1003-1 VDD(3.3v) J1-4 5V J1003-2 VBAT (5v) J1-5  SDA.1 J1003-3 SDA J2-2 SCL.1 J1003-5 SCL J2-1 GPIO.25 J1003-37 IRQ J2-10 GPIO.28 J1003-38 REQ J4-2 GND J1003-39 GND J1-6 GPIO.29 J1003-40 VEN J4-1 2    Get AOSP for i.MX Nano Follow Android porting guide. https://www.nxp.com/docs/en/user-guide/ANDROID_USERS_GUIDE.pdf .2.1  Download i.MX Android BSP (Android14.0.0_1.2.0) from below link.  Android OS for i.MX Applications Processors | NXP Semiconductors   danielchen_23-1738394964705.png You will get the package imx-android-14.0.0_1.2.0.tar.gz    .2.2 Decompressing android BSP # tar -xvzf imx-android-1c4.0.0_1.2.0.tar.gz  When decompression is done, imx-android-14.0.0_1.2.0 subdirectory is created, in the folder, we can find imx_android_setup.sh, which is script for downloading android source code and commands for patching i.MX android bsp to AOSP. .2.3 Downloading Android source code # source ./imx-android-14.0.0_1.2.0/imx_android_setup.sh  The folder structure after AOSP downloading complete. danielchen_24-1738395033337.png  3     AOSP Adaptation NXP adds modifications to the AOSP code. Next, we add them step by step according to AN14430, move the content of them into correct folder in AOSP code base. danielchen_1-1732538499804.png .3.1  nxp_nci_hal_nfc #git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_nfc.git" #cd nxp_nci_hal_nfc #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/packages/apps/Nfc/ #cd .. danielchen_9-1738393932366.png .3.2 nxp_nci_hal_libnfc-nci #git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_libnfc-nci.git" #cd nxp_nci_hal_libnfc-nci #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/system/nfc/ #cd .. danielchen_10-1738393932389.png .3.3 nfcandroid_nfc_hidlimpl #git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" #cd nfcandroid_nfc_hidlimpl #git checkout br_ar_14_comm_infra_dev #cp -rf *  ../android_build/hardware/nxp/nfc #cd .. danielchen_11-1738393932410.png .3.4 nfcandroid_frameworks #git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" #cd nfcandroid_frameworks #git checkout br_ar_14_comm_infra_dev #mkdir ../android_build/vendor/nxp/frameworks #cp -rf * ../android_build/vendor/nxp/frameworks #cd .. danielchen_12-1738393932434.png .3.5 nfcandroid_emvco_aidlimpl #git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" #cd nfcandroid_emvco_aidlimpl #git checkout br_ar_14_comm_infra_dev #mkdir  ../android_build/hardware/nxp/emvco #cp -rf *  ../android_build/hardware/nxp/emvco #cd .. danielchen_13-1738393932472.png .3.6   nfcandroid_platform_reference #git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" #cd nfcandroid_platform_reference #git checkout br_ar_14_comm_infra_dev #cp -rf vendor/nxp/*   ../android_build/vendor/nxp/ #cd .. danielchen_14-1738393932494.png .3.7 nfcandroid_infra_test_apps # git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git # cd nfcandroid_infra_test_apps/ # git checkout br_ar_14_comm_infra_dev # cd test_apps/ # cp -rf SMCU_Switch/  ../../android_build/packages/apps/ # cp -rf EMVCoModeSwitchApp/  ../../android_build/packages/apps/Nfc/ # cd ../.. danielchen_15-1738393932522.png .3.8  nfcandroid_infra_comm_libs #git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" #cd nfcandroid_infra_comm_libs #git checkout br_ar_14_comm_infra_dev #cp -rf nfc_tda/  ../android_build/system/ #cp -rf emvco_tda/ emvco_tda_test/  ../android_build/hardware/nxp/emvco/ #cp -rf NfcTdaTestApp/  ../android_build/packages/apps/Nfc/ #cd .. danielchen_16-1738393932548.png After AOSP adaptation, folder is like below. danielchen_17-1738393932554.png  4   Apply AOSP patches please see AN14430, page10   danielchen_2-1732538683728.png # patch -p1 <  ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_bazel.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_make.patch # patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_soong.patch # patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_base.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_native.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_proto_logging.patch #patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch #patch -p1 < ../../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_packages_modules_Bluetooth.patch danielchen_4-1732538759932.png  5    Adding the driver support. .5.1  get nfcandroid_platform_drivers from github #git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" #cd nfcandroid_platform_drivers #git checkout br_ar_14_comm_infra_dev #cd .. danielchen_22-1738394453607.png .5.2Create a folder named pn7160 under android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc danielchen_5-1732538861565.png Copy below kernel drivers file from “nfcandroid_platform_drivers/drivers/pn7160/nfc/nfc “ into  “android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7160/” Common.c  common.h   i2c_drv.c  i2c_drv.h spi_drv.h  spi_drv.c  Makefile  Kconfig Result of copying: danielchen_6-1732538987249.png .5.3 Modify makefile Replace Makefile default code with following code,  only add i2c for simplifying. danielchen_7-1732539043196.png  Now we need to add pn7160 Makefile and Kconfig to main Makefile and Kconfig danielchen_8-1732539089136.png Makefile danielchen_9-1732539136098.png Kconfig danielchen_10-1732539167244.png 6   Adding device tree Device tree is important since we need to tell our controller which pins we want to use for communication (this is always different between host controllers) The device tree need to be added into: “vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale” Create file with name “imx8mn-evk-pn7160.dts”, open the file and add following lines: danielchen_11-1732539249939.png Next task is to add .dts file into Makefile in the following location: . vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale Open Makefile and add: danielchen_12-1732539303166.png Final step is to add NXP_NCI_I2C as module in following file: . vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx8mn_gki.fragment Open imx8mn_gki.fragment and add: danielchen_13-1732539339523.png 7    Add device specific changes          The location of the device specific changes in under folder            . device/nxp/imx8m/evk_8mn 7.1 BoardConfig.mk   danielchen_14-1732539411816.png    danielchen_15-1732539466661.png   danielchen_16-1732539510369.png 7.2 ShareBoardConfig.mk danielchen_17-1732539566160.png danielchen_19-1732539662019.png  7.3 compatibility_matrix.xml danielchen_20-1732539715434.png  7.4 device_framework_matrix.xml danielchen_21-1732539759365.png  7.5 evk_8mn.mk Add .mk files to specific device.mk and some product package directly to device.mk file so everything is build together with Android.   danielchen_22-1732539833373.png danielchen_23-1732539859881.png 7.6 init.rc danielchen_24-1732539894988.png 7.7manifest.xml danielchen_25-1732539940498.png 7.8 ueventd.nxp.rc        Add permissions for drivers   danielchen_26-1732540013940.png  8    Additional change in compatibility matrix Put changes into hardware/interfaces/compatibility_matrices Compatibility_matrix_8.xml danielchen_27-1732540098909.png  9    add changes into NXP mk files . android_build/vendor/nxp/nfc/device-nfc.mk danielchen_28-1732540184997.png danielchen_29-1732540215144.png  .android_build/vendor/nxp/emvco/device-emvco.mk   danielchen_30-1732540257962.png  10    Build Android First , the source build/envsetup.sh command is executed to import shell functions that are defined in ${MY_ANDROID}/build/envsetup.sh. Then, the lunch evk_8mn-userdebug command is executed to set up the build configuration. #source build/envsetup.sh #lunch evk_8mn-userdebug   Possible build failures danielchen_31-1732540449014.png This error resulted from the incompatibility of file Kconfig, please use dos2unix command to fix it. danielchen_32-1732540505205.png  For some other redefine issues, please do the following. Go into file hardware/nxp/nfc/snxx/ Name Android.bp to _Android.bp Go into hardware/nxp/nfc/snxx/halimpl/power-tracker/ Name Android.bp to _Android.bp Go into file hardware/nxp/secure_element/snxxx/aidl/ Name Android.bp to _Android.bp Remove : pn8xx from hardware/nxp/ Remove : frameworks/base/core/res/res/values/config.xml.orig 11   Download build and flash images Go into “android_build/out/target/product/evk_8mn” and download all files without folders . When downloaded, open following two files and add: .in fastboot_imx_flashall.bat   danielchen_34-1732540724837.png .in uuu_imx_android_flash.bat   danielchen_35-1732540776703.png Change switches on i.MX8M Nano danielchen_36-1732540836787.png .    Flashing Android: when flashing Android images .    Running Android:  when images are flashed, put switches to Running Android and Android OS will start. Flash images .  Put i.MX8 to “Flash Android” .  Open a PowerShell as admin in the location where download images are .  Running following command .  ./uuu_imx_android_flash.bat -f imx8mn -a -d pn7160 danielchen_37-1732540883865.png 12  Firmware update Download the FW from Github Open terminal at the FW location Run the following commands • adb push libpn7160_fw.so vendor/lib64/libpn7160_fw.so (for 64-bit version) and adb                  push libpn7160_fw.so vendor/lib/libpn7160_fw.so (for 32-bit version) • adb shell svc nfc disable • adb shell svc nfc enable    danielchen_38-1732540976369.png References: PN7160/PN7220 – Android 14 porting guide UG10156 : Android User’s Guide  Build Andriod image for PN7160 on i.MX8M Nano:  Andraz this is a step by step guider to port PN7160 to Android 14 on i.MX 8M Nano board NFC Controller Solutions
記事全体を表示
[Zephyr ®系列] 第 4 部分:Kconfig 和设备树的概述及实际应用(日语博客) Zephyr-series-4-title.png   从现在开始,我们将进入 Zephyr 的高级主题学习。 本次课程将概述 Kconfig 和设备树,然后进行实践编程练习,帮助您有效地使用它们。   如前所述,Zephyr RTOS 的一个关键特性是其软件可扩展性(可重用性),这使得在其他项目或衍生产品中重用一次开发的软件变得容易,从而实现快速开发。   此外,为了支持各种硬件平台,Zephyr 采用了名为“Kconfig”和“Devicetree”的强大配置系统。   这样,您只需更改配置文件,即可将程序移植到不同的微控制器板,而无需使用相同的 C/C++ 语言重写源代码。 本文解释了Kconfig和设备树的基本机制。作为实际应用,我们将修改第三部分中创建的与硬件无关的LED闪烁程序,使其能够在两种不同的微控制器板“ FRDM-MCXA153 ”和“ FRDM-MCXN947 ”上运行。   为了在不同的电路板(微控制器和处理器)上运行同一个应用程序,我们将解释使用 Kconfig 和设备树的实用编程方法。     目录   准备 Kconfig基础知识 设备树基础知识 提高软件重用性的最佳实践 Kconfig 和设备树的实际应用 创建一个简单的程序(动手实践) 1. 程序规范 2. 目录结构 3. 创建 Kconfig 和 prj.conf 文件 4. 创建设备树覆盖层和板级特定设置 5. 与硬件无关的通用代码(main.c)创造 6. 构建并运行 总结 准备   硬件准备   本文将主要使用以下开发板来创建和测试程序。 FRDM-MCXA153 (主要用途) 此外,以下电路板将作为辅助工具,用于验证您所创建的程序的可移植性。 FRDM-MCXN947   SW 准备   本指南假设您已搭建好 Zephyr 开发环境(Zephyr SDK、West 命令等)。如果您尚未搭建,请参阅第二篇关于环境搭建的文章。 【Zephyr ®系列】第二部分:首次构建与测试(日语博客)   我们将使用在 Zephyr 系列第三篇文章中创建的 LED 闪烁程序。如果您尚未创建该程序,我们建议您参考上一篇文章进行创建。 【Zephyr ®系列】第三部分:LED 闪烁和软件复用的第一步(日语博客)   Kconfig基础知识     Kconfig 是 Linux 内核中使用的一种配置系统。在 Zephyr 中,它用于管理是否“启用或禁用”软件功能,或者“设置哪些参数”,例如内核函数、设备驱动程序、子系统和应用程序特定的设置。 以下两个文件对 Kconfig 很重要: “Kconfig”文件定义了可选的配置项(符号)、它们的默认值和依赖关系。 "prj.conf" 文件*:应用程序开发人员在此文件中指定他们想要为 "Kconfig" 中定义的项目设置的值(例如,使用 "y" 启用它们或提供特定的数值)。 使用 Kconfig,您可以排除编译中不必要的代码并优化内存使用。 此外,Kconfig 和 prj.conf 文件都是以文本格式编写的。 如何启用此功能 prj.conf 文件启用整个项目的功能。 例如,ADC、DAC 和 OPAMP 驱动程序在 Kconfig 中定义。使用 Kconfig 中定义的函数时,需要在 prj.conf 文件开头添加“CONFIG_”来声明它们。 Kconfig:ADCの定義Kconfig:ADC定义 prj.conf例prj.conf 示例   设备树基础知识   Devicetree例设备树示例   设备树是一个文本文件,它描述了微控制器支持的硬件(CPU、内存、外设、引脚设置等),以及这些硬件的设置和配置。 然后将这些设置和配置展开成宏。   Zephyr 宏可以读取设备树中描述的信息,而不是直接将硬件地址写入 C 代码(硬编码),从而实现与硬件无关的编程。 节点和属性:硬件的每个元素在层次结构中都表示为一个“节点”,寄存器地址、中断号等则被描述为“属性”。 ".dts" 和 ".dtsi":每个微控制器和电路板的标准硬件配置都在 Zephyr 存储库中的 ".dts"(设备树源)和 ".dtsi"(包含)文件中预定义。 dts:被描述为电路板的设备树。 dtsi:描述 SoC/微控制器的设备树,由设备制造商提供。 ".overlay" 文件:当您想要覆盖特定应用程序的接线(例如,将 LED 连接到特定的 GPIO 引脚)或默认设置时,将创建此文件。   提高软件重用性的最佳实践   为了提高 Zephyr 软件的可重用性,遵循以下设计原则非常重要: 硬件相关部分与硬件无关部分的分离: C 代码(`main.c`)例如,避免直接描述具体的微控制器寄存器操作或引脚编号。 利用设备树别名:应用程序不应直接引用实际的硬件节点(例如 `&red_led` 或 `&gpioa`),而应引用在 `aliases` 节点中定义的抽象名称(例如 `led0`)。这样,只需更改别名指向的内容,即可轻松适配不同的开发板。 准备特定于电路板的设备树(覆盖) :当某些功能存在差异时,例如在衍生产品中,您可以仅对每个电路板上硬件不同的部分进行覆盖(覆盖)。 使用 Kconfig 切换功能:应用程序行为参数和特定功能的开/关状态使用 Kconfig 符号而不是 C 语言“#define”进行控制。   Kconfig 和设备树的实际应用   接下来,我们将通过创建一个简单的程序来学习如何使用 Kconfig 和设备树,以便我们能够在实践中实际使用它们。     创建一个简单的程序(动手实践) 该程序将通过修改我们上次创建的 LED 闪烁程序来创建,并将具有以下规格。   在这里,作为一项实践练习,我们将创建一个可以在“FRDM-MCXA153”和“FRDM-MCXN947”上运行的通用应用程序。 1. 程序规范 源代码:使用“第 3 部分:你的第一个 LED 闪烁程序”中的代码,并进行以下修改。 LED闪烁速度:可以使用Kconfig设置闪烁间隔。 按钮功能(启用/禁用):可通过 Kconfig 设置启用或禁用按钮功能。启用后,按下按钮可在 LED 闪烁和常亮之间切换。 输出板卡名称:启动时,Kconfig 中配置的“设备(板卡)名称”将输出到标准输出(终端)。 2. 目录结构   项目目录结构应如下所示:   将 Kconfig 文件和 boards 文件夹添加到上次创建的 LED 闪烁程序的“my_hello”文件夹中。添加文件的方法不限。 在 Windows 系统中,使用 PowerShell `ni` 命令或文本编辑器创建一个新文件,并将其保存在 `my_hello` 文件夹中。 在 Linux 系统中,可以使用 `touch` 命令创建一个新的空文件。   “boards/”目录下的文件用于处理硬件差异以及每个主板特有的独特设置。     my_hello/ ├── CMakeLists.txt ├── Kconfig <- 新規追加:アプリ独自のKconfig ├── prj.conf <- アプリの共通設定 ├── src/ │ └── main.c <- ハードウェア非依存の共通コード └── boards/ <- 新規作成フォルダ  ├── frdm_mcxa153.overlay <- 新規作成:FRDM-MCXA153用のデバイスツリー設定  ├── frdm_mcxa153.conf <- 新規作成:FRDM-MCXA153用のKconfig設定  ├── frdm_mcxn947_cpu0.overlay <- 新規作成:FRDM-MCXN947用のデバイスツリー設定  └── frdm_mcxn947_cpu0.conf <- 新規作成:FRDM-MCXN947用のKconfig設定   注意:通过在应用程序目录中创建特定文件,Zephyr 的构建系统(West)将自动识别它们并应用设置。 添加 Kconfig:您可以通过在应用程序文件夹中放置“Kconfig”文件来添加自己的配置符号。 板级特定设置(“boards/”目录):通过在应用程序中创建“boards”目录并将“[板级名称].overlay”或“[板级名称].conf”文件放置于其中,overlay和Kconfig覆盖将仅在以该板级为目标进行构建时自动应用。   3. 创建 Kconfig 和 prj.conf 文件 首先,在应用程序根目录中创建您自己的“Kconfig”文件,并定义特定于应用程序的参数。 my_hello/Kconfig   mainmenu "my LED blink" config CUSTOM_BLINK_RATE_MS int "LED blink rate in milliseconds" default 1000 help Set LED blink frequency. #LEDの点滅周期(ミリ秒)を設定します config ENABLE_BUTTON_TOGGLE bool "Enable button to toggle LED state" default y help Enable button to toggle LED state. # ボタン入力によるLEDの点滅/点灯状態>の切り替え機能を有効にします。 config BOARD_NAME_STRING string "Board Name String" default "Unknown Board" help Set board name for printf. # 標準出力に表示するボード名を設定します。 source "Kconfig.zephyr"     其次,作为整个应用程序的通用设置,还有“prj.conf”。这件事将会被写下来。 在 prj.conf 文件中,使用您刚刚创建的 Kconfig 符号按如下方式进行配置: my_hello/prj.conf   # GPIOの有効化 CONFIG_GPIO=y # アプリケーションの共通設定 CONFIG_CUSTOM_BLINK_RATE_MS=500 CONFIG_ENABLE_BUTTON_TOGGLE=y   4. 创建设备树覆盖层和板级特定设置 创建一个名为“boards”的目录,并为每个电路板准备必要的文件。 FRDM-MCXA153主板     我们将电路板上的按钮(`sw2`)映射出来,以便应用程序可以使用标准别名`sw0`访问它。`led0`已经在电路板定义中,因此这里可以省略,但如果需要,也可以显式地覆盖它。   my_hello/boards/frdm_mcxa153.overlay / { aliases { sw0 = &user_button_2; /* FRDM-MCXA153のユーザーボタン */ }; };   my_hello/boards/frdm_mcxa153.conf   CONFIG_BOARD_NAME_STRING="FRDM-MCXA153 Board"   通过在应用程序 (main.c) 中引用此 .conf(特定于板的 Kconfig)中的符号,可以使用 printf 函数将板名称输出到标准输出。 适用于 FRDM-MCXN947 同样,我们在 FRDM-MCXN947 中定义了“sw0”。这可以处理按钮硬件名称的任何差异。   事实上,如果硬件名称(因外围设备或实例而异)在不同电路板之间有所不同,则需要将实际硬件分配给设备树中的别名节点。 my_hello/boards/frdm_mcxn947_cpu0.overlay   / { aliases { sw0 = &user_button_3; /* FRDM-MCXN947のユーザーボタン */ }; };   my_hello/ boards/frdm_mcxn947_cpu0.conf   我将尝试仅在使用 MCXN947 构建时将 LED 闪烁速度设置为 250ms。   CONFIG_BOARD_NAME_STRING="FRDM-MCXN947 Board" CONFIG_CUSTOM_BLINK_RATE_MS=250 FRDM-MCXA153 和 FRDM-MCXN947 的应用程序代码相同,但您可以在此处单独配置 LED 的闪烁行为。 5. 与硬件无关的通用代码(main.c)创造 在“my_hello/src/main.c”中写入以下内容:   LED 控制部分重用了上一篇文章中创建的硬件无关代码(使用“led0”别名),并将 Kconfig 和按钮控制集成到其中。 my_hello/ src/main.c   #include #include #include /* Devicetreeのエイリアスを参照する */ /* どのボードでも、一番目のLEDは通常 "led0" と定義されています */ #define LED0_NODE DT_ALIAS(led0) #define SW0_NODE DT_ALIAS(sw0) /* エイリアスからGPIO仕様(ポート、ピン、フラグ)を取得 */ static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios); /* ボタン機能がKconfigで有効化されている場合のみコンパイルされる部分 */ #ifdef CONFIG_ENABLE_BUTTON_TOGGLE static const struct gpio_dt_spec sw = GPIO_DT_SPEC_GET(SW0_NODE, gpios); static struct gpio_callback button_cb_data; static bool is_blinking = true; void button_pressed(const struct device *dev, struct gpio_callback *cb, uint32_t pins) { is_blinking = !is_blinking; if (!is_blinking) { /* 点滅オフ時はLEDを点灯させた状態にする */ gpio_pin_set_dt(&led, 1); } } #endif //CONFIG_ENABLE_BUTTON_TOGGLE int main(void) { int ret; /* Kconfigで設定されたボード名を出力 */ printf("Starting application on %s\n", CONFIG_BOARD_NAME_STRING); /* デバイスの準備確認 */ if (!gpio_is_ready_dt(&led)) { return -1; } /* ピンの設定 (Devicetreeで定義された初期状態などを考慮して設定) */ ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE); if (ret < 0) { return -1; } #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (!gpio_is_ready_dt(&sw)) { return -1; } ret = gpio_pin_configure_dt(&sw, GPIO_INPUT); if (ret < 0) { return -1; } ret = gpio_pin_interrupt_configure_dt(&sw, GPIO_INT_EDGE_TO_ACTIVE); if (ret < 0) { return -1; } gpio_init_callback(&button_cb_data, button_pressed, BIT(sw.pin)); gpio_add_callback(sw.port, &button_cb_data); #endif //CONFIG_ENABLE_BUTTON_TOGGLE while (1) { #ifdef CONFIG_ENABLE_BUTTON_TOGGLE if (is_blinking) { ret = gpio_pin_toggle_dt(&led); } #else /* ピンの状態を反転 (ボタン機能が無効な場合は常に点滅) */ ret = gpio_pin_toggle_dt(&led); #endif //CONFIG_ENABLE_BUTTON_TOGGLE /* Kconfigで設定された点滅間隔で待機 */ k_msleep(CONFIG_CUSTOM_BLINK_RATE_MS); } return 0; }     6. 构建并运行 现在,让我们实际测试一下它的功能。请参考上一篇文章,了解如何设置构建环境和启用 west 命令。 首先,按照下面的命令说明导航到已安装的 zephyrproject 存储库目录,并在继续操作之前启用 west。 已确认 FRDM-MCXA153(主)运行正常 使用以下命令构建并将其写入 FRDM-MCXA153。   ## ホームディレクトリからZephyrprojectディレクトリに移動 cd ~/zephyrproject ## west環境を有効化 source .venv/bin/activate ## zephyr v4.3をチェックアウトしていない場合は、前回(第3回 初めてのLチカとソフトウェアの再利用性)を参考にv4.3をチェックアウトしてください。 west build -b frdm_mcxa153 my_hello west flash     执行结果   コンソール出力控制台输出   LED点滅、点灯モード切り替えLED闪烁和常亮模式切换   终端上将显示“正在FRDM-MCXA153板上启动应用程序”的消息。 LED 灯以500 毫秒的间隔闪烁(“prj.conf”)。(设置)。 按下 SW2(“自定义开关”)即可将其打开,再按下即可使其恢复闪烁状态。 已确认FRDM-MCXN947运行正常 我们将使用完全相同的 C 源代码来构建该项目,只更改电路板规格。   # -pオプションを使用し、frdm_mcxa153のビルド情報をクリーンしてビルドします。 west build -p -b frdm_mcxn947//cpu0 my_hello west flash   执行结果   “boards/frdm_mcxn947_cpu0.conf”的内容将自动应用,终端将显示“在FRDM-MCXN947板上启动应用程序”。 LED 灯以250 毫秒的间隔快速闪烁(在“prj.conf”中配置)。 按下 SW3(MCXN947 上映射到“user_button_3”的按钮)同样可以在 LED 点亮和闪烁之间切换。 虽然 FRDM-MCXA153 和 FRDM-MCXN947 使用不同的 GPIO 来控制 LED 和开关按钮,但设备树有效地吸收了这些差异,这表明应用程序和硬件是如何清晰分离的。   总结     在本节课中,我们学习了 Zephyr 中 Kconfig 和设备树的基础知识,并练习了如何利用它们将硬件相关的部分与 C 代码分离。   我相信您已经体验到了一种强大的机制,可以在多个不同的电路板上重用相同的源代码,其中硬件设置被设备树覆盖(“overlay”)吸收,应用程序参数可以灵活地更改,并且可以使用特定于电路板的 Kconfig 文件(“conf”)轻松启用或禁用功能。   ========================== 我们目前无法回复此帖子“评论”部分留下的评论。 由此给您带来的不便,我们深表歉意。如有任何疑问,请参考“NXP 技术问题 - 如何联系我们(日语博客)”。 (如果您已经是恩智浦的分销商或与恩智浦有合作关系,您可以直接咨询您的代表。) Zephyr-series-4-title.png 本文档概述了设备树和 Kconfig,这两项功能旨在增强 Zephyr 的软件重用性。随后,本文档详细介绍了在实践中使用这些功能所需的步骤。 读完 Zephyr 系列的第一册到第四册后,你将能够使用 Zephyr 实时操作系统编写程序。 通用微控制器 MCX 日本博客
記事全体を表示
MC33777B データシート BMSを設計しているのですが、 MC33777BのデータシートがNXPのウェブサイトの公開ファイルとセキュアファイルの両方に見当たりません。MC33777Bの完全なデータシートを提供していただけないでしょうか? Re: MC33777B Datasheet 私の回答は以下のとおりです。   1: MC33777B データシート:   これは、機密保持契約(NDA)に基づき、安全なファイルを通じてのみ提供されます。 セキュリティファイルは製品ページからアクセスできます。   https://www.nxp.com/products/MC33777   LinaHou_0-1780285320974.png 2:弊社のセキュアファイルシステムで確認したところ、お客様はセキュアファイルへのアクセス権を取得済みです。こちらのガイドを参照して、お客様側からダウンロードしてください: https://www.nxp.com/docs/en/user-guide/nxp-docstore-migration-guide.pdf 申請が完了すると、docstore が申請をサポートします。 MC33777B [DS1110110]のデータシートは、製品マネージャーの承認後、お客様向けに提供されます。 ダウンロードリンクが記載されたメールが届きますので、そこからデータシートを直接ダウンロードできます。 手順を理解するには、よくある質問(FAQ)をご確認ください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS もし あなた は 直面している どれでも 問題 に アクセス の 安全な ファイル または さらに遠く 支援 必要、 お願いします ただ 使用 あなたの 会社 メール、提供 あなたの NDA# または 秘密保持契約 コピー、 プロジェクト 詳細、 接触 私たちの ドキュメントストア チーム 直接 で これ メール 住所: [email protected] 彼らはきっと喜んであなたをサポートしてくれるでしょう。 この情報が少しでもお役に立てば幸いです。   ありがとうございました。良い一日をお過ごしください。
記事全体を表示
Booting a Non-XIP Application from SEMC NAND on MIMXRT1170-EVKB Software Prerequisites MCUXpresso IDE Tera Term (serial terminal) Secure Provisioning Tool 1 Introduction This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB. Because NAND memory is block-oriented and cannot be executed in place, the application image must be linked to internal or external RAM (ITCM, DTCM, OCRAM, or SDRAM) and copied from NAND into RAM by the i.MX RT1170 BootROM prior to execution. The guide covers the required board rework, hardware validation using the MCUXpresso SDK, project configuration for RAM-linked builds, bootable image generation using the MCUXpresso Secure Provisioning Tool (SEC), one-time fuse programming for ECC, image programming to NAND, and final boot verification. Readers are strongly encouraged to review Section 2 (Bootable Image Layout) of application note AN14069 before proceeding, as familiarity with the image layout is essential for understanding the steps that follow. swetha_v_0-1779206877689.png RT1170 Bootable image layout 2 Hardware Rework The EVKB ships with the SEMC NAND data-line 0-ohm resistors depopulated (DNP) because those SoC pins are muxed with other functions on the board. You must solder them in before NAND is usable. 2.1 Resistors to Populate Solder R1872 through R1879 (eight 0-ohm resistors) on NAND data lines DATA0-DATA7. Before soldering, cross-check against your specific EVKB revision’s schematic. Open the board schematic PDF and search for the SEMC NAND section, the reference designators can shift by a digit or two between revisions. The relevant schematic is downloadable from the NXP product page. swetha_v_0-1779205885596.png 2.2 Hardware Validation via SDK Examples After populating the resistors, validate the rework by running the SDK example mentioned below in the default QSPI NOR boot configuration (no changes to SW1/SW2 from factory settings yet). This isolates hardware issues from boot-configuration issues and gives clean signal before attempting SEC flashing. 2.3 Recommended Validation Sequence Run the semc_nand component example. Path: \boards\evkbmimxrt1170\component_examples\flash_component\semc_nand. Import via File → Import → MCUXpresso SDK Examples → MIMXRT1170-EVKB → component_examples\flash_component\semc_nand Build and flash to QSPI NOR (default boot configuration). Open a serial terminal on the MCU-Link VCOM port at 115200 baud 8N1. Press reset. The example will read the NAND ID, erase a block, program a page, read it back, and print the results. Pass criteria: all operations complete without errors and the read-back data matches the written data. If this passes, the hardware rework (R1872–R1879) is electrically correct and the NAND software layer that SEC depends on works. Please proceed to SEC flashing. swetha_v_1-1779205885702.png   3 Build a NAND-Bootable Application in MCUXpresso IDE NAND is block-oriented; the CPU cannot execute directly from it. The application must be RAM-linked (non-XIP), and the ROM will copy it into RAM before jumping. 3.1 Import the SDK Example Install SDK_26.03.00_MIMXRT1170-EVKB into MCUXpresso IDE (drag the ZIP into “Installed SDKs”). File → Import → MCUXpresso SDK Examples. Board: MIMXRT1170-EVKB; core: CM7. Select the iled_blinky example for initial bring-up. Click Finish. 3.2 Configure Project for RAM-Linked (Non-XIP) Build Right-click project → Properties → C/C++ Build → MCU settings: In Memory details, set default RAM to ITCM/OCRAM/SDRAM as shown in below images. Move the corresponding RAM to the lower line of the Flash item, below BOARD_FLASH using the arrows on the right. Since the BootROM uses the first 8K of the linked RAM during image copying, in this step, the start address is offset by 0x2000 and the size is modified accordingly. Setting default RAM to ITCM: swetha_v_2-1779205885730.png Setting default RAM to OCRAM: swetha_v_3-1779205885759.png Note: There is no limitation when linking the image text section to ITCM, DTCM, or SDRAM for non-XIP boot. However, when linking the image text section to OCRAM (0x2020_0000 – 0x203F_FFFF), one limitation applies: the region 0x2024_0000 – 0x2024_BFFF must be reserved as this is the ROM RW region. If the image text section is linked into the ROM RW region, the ROM routine will be corrupted during image copying. swetha_v_4-1779205885777.png Setting default RAM to SDRAM: swetha_v_5-1779205885807.png Note: This option requires an XMCD (External Memory Configuration Data) block in the boot image. Then C/C++ Build → Settings → MCU C Compiler → Preprocessor, add or change: XIP_BOOT_HEADER_ENABLE=0 XIP_EXTERNAL_FLASH=0 In the project’s Settings tab (project root), check “Link application to RAM”. swetha_v_6-1779205885863.png   4 Build the Bootable Image in the SEC Tool 4.1 Create the SEC Workspace Launch MCUXpresso Secure Provisioning Tool File → New workspace → choose a folder Processor: MIMXRT1176 (RT1170-EVKB) Boot type (toolbar): Unsigned Boot device (toolbar): SEMC NAND LC: Open, HAB disabled swetha_v_7-1779205885887.png 4.2 Configure SEMC NAND device parameters for Micron MT29F2G08ABAGAH4-IT:G Select Target → Boot Memory … to open Boot Memory Configurations swetha_v_8-1779205885915.png Based on MT29F2G08ABAGAH4 datasheet, its default ECC is off, so we need to do the below ECC settings: swetha_v_9-1779205886059.png 4.3 Build the bootable image Go back to the MCUXpresso IDE and build the iled_blinky project. Upon successful build, an axf file will be generated. You may find it in …\MCUXpressoIDE_25.6.136\workspace\evkbmimxrt1170_iled_blinky_cm7\Debug Navigate back to Secure Provisioning Tool → Build image Source executable image → Browse → …\MCUXpressoIDE_25.6.136\workspace\evkbmimxrt1170_iled_blinky_cm7\Debug\evkbmimxrt1170_iled_blinky_cm7.axf Start address: Needs to correspond to the start address set in Memory Configurations in Part 3.2 If linking the application to SDRAM, check XMDC → SEMC SDRAM DCD (binary): None Click Build Image Status of the command is shown in the log and the bottom of the screen: swetha_v_10-1779205886160.png   5 Put the Board in Serial Downloader Mode Before SEC can write to NAND, the RT1176 ROM must be in SDP mode. 5.1 Boot Mode for Serial Downloader SW1 = OFF-OFF-OFF-ON (BOOT_MODE[1:0] = 01) The boot mode is selected based on the binary value stored in the internal BOOT_MODE register, and switch SW1-3 and SW1-4 are used to select the boot mode on the MIMXRT1170 EVKB board. SW1-1 SW1-2 SW1-3 SW1-4 BOOT_MODE Mode OFF OFF OFF ON 01 Serial Downloader OFF OFF ON OFF 10 Internal Boot   5.2 Connect and Verify Power off the board (SW5 OFF). Set SW1 as shown above. Connect a USB cable to J20 (USB OTG1, primary USB per the schematic) Power on (SW5 ON) and press SW4 (reset). Windows Device Manager should show an HID device with VID=0x1FC9, PID=0x013D. This is the RT1176 ROM’s SDP interface.   6 Burn Fuse for the EVKB’s NAND This step is NAND-specific. Per RM Table 10-20 (Fuse definition for Parallel NAND over SEMC), for the RT117x ROM to load an image from this NAND with ECC protection and valid bad-block detection, one fuse must be burned for reliable NAND boot on the EVKB’s Micron NAND. 6.1 The Fuse Attribute Value Register BOOT_CONFIG_MISC2[31:0] Offset 0x0C80 Bit to burn Bit 24 Bit value 1 Value to burn for EVKB 1 (register = 0x01000000) Without this burn, the ROM reads pages without ECC correction. Because the Micron NAND writes ECC-protected data only when ECC is enabled, any data written via the SDK with ECC enabled would appear as uncorrected bytes + parity. With ECC off, even small bit-errors become uncorrectable read failures, and bad-block detection via ECC status is unreliable. 6.2 Test Connection Click Test connection. The expected result is shown in the screenshot below. swetha_v_11-1779205886273.png 6.3 How to Burn the Fuse via SEC Ensure the board is in SDP mode, with USB connected to J20. In the SEC workspace, open Build image → OTP configuration. Read the current values from the processor. Locate BOOT_CONFIG_MISC2[31:0] at offset 0x0C80. In the Required value column, enter 0x01000000. Ensure there is no “*” (unknown) in any bit of the current or required value. Select Advanced Mode → Generate script, to confirm that only MISC2 bit 24 will be written. Select Advanced Mode → Burn to execute the burn. Read the fuses back and verify that BOOT_CONFIG_MISC2 = 0x01000000 and that other fuses remain unchanged. Click OK. swetha_v_0-1779206602330.png swetha_v_13-1779205886328.png swetha_v_14-1779205886431.png   7 Write the Bootable Image to NAND via SEC At this stage, every item in the Build image tab should be checked green. swetha_v_15-1779205886625.png Switch to the “Write image” view. Use built image: checked. Connection type: USB (ensure that the device remains in SDP mode and is connected). Click Write image. swetha_v_16-1779205886676.png   8 Configure Boot Switches for Internal Boot from SEMC NAND 8.1 Power Off Slide SW5 to OFF. 8.2 Set BOOT_MODE to Internal Boot SW1 = OFF-OFF-ON-OFF (BOOT_MODE[1:0] = 10) 8.3 Set BOOT_CFG1 for SEMC Parallel NAND SW2 = OFF-OFF-OFF-OFF-ON-OFF-OFF-OFF SW2 position BOOT_CFG1 bit Value SW2-1 BOOT_CFG[0] 0 (OFF) SW2-2 BOOT_CFG[1] 0 (OFF) SW2-3 BOOT_CFG[2] 0 (OFF) SW2-4 BOOT_CFG[3] 0 (OFF) SW2-5 BOOT_CFG[4] 0 (OFF) SW2-6 BOOT_CFG[5] 1 (ON) SW2-7 BOOT_CFG[6] 0 (OFF) SW2-8 BOOT_CFG[7] 0 (OFF) SW2-9 BOOT_CFG[8] 0 (OFF) SW2-10 BOOT_CFG[9] 0 (OFF) This is the EVKB-specific setting that selects SEMC Parallel NAND as the boot device.   9 Boot and Verify Slide SW5 to ON. Press SW4 (reset). The on-board user LED should blink, confirming that the application has booted successfully from SEMC NAND.   References AN14069 — How to Enable Non-XIP Boot on i.MX RT Series EVK Board. IMXRT1170RM — i.MX RT1170 Reference Manual. MIMXRT1170-EVKB Hardware Development User Guide and Board Schematic. Micron MT29F2G08ABAGAH4 NAND Flash Datasheet. MCUXpresso Secure Provisioning Tool User Guide. This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.
記事全体を表示
S32K314 FreeRTOS Standby Transition and Return to Run Mode I am developing a project that combines interrupts and tasks using the S32K314, RDT 7.0.0, and FreeRTOS 7.0.0. The interrupts and tasks are functioning properly. I have implemented code that transitions from Run mode to Standby mode and returns to Run mode after a specified time has elapsed as measured by the RTC. I have confirmed that the system transitions from Run mode to Standby mode, and that a reset occurs afterward, causing the MCU bootloader to run again.  However, an error occurs during the process of distributing the clock to the MCU peripherals after the MCU initialization begins and the PLL locks. Since it works during P.O.R., I believe there is some error in the process that transitions the system to Standby mode. Could you please help me? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Additional Information: This project defines Standby RAM. The RAM is allocated as a 32-kilobyte region starting from the beginning of the BSS. This region stores the necessary data after resuming from Standby. /*--- Transition to Standby Mode ---*/ /* Set the timeout for the RTC timer to wake up WKPU0 */ Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds); /* Suspend all OS tasks */ vTaskSuspendAll(); /* Initialize the clock mode to Standby */ Mcu_InitClock(McuClockSettingConfig_Standby); /* Set the clock mode */ Mcu_SetMode(McuModeSettingConf_Standby); ..... (Reset Occur) /*--- MCU Initialization ---*/ /* Set the Standby RAM area to non-cacheable */ MpuConfigurator_AllocateStandbyRamToNonCacheable(); /* Enable non-cacheable mode */ MpuConfigurator_Enable(); /* Initialize the MCU module */ Mcu_Init(NULL_PTR); /* Initialize clock settings in Run mode */ if (E_OK == Mcu_InitClock(McuClockSettingConfig_Run)) { /* Wait for PLL lock via polling */ while (MCU_PLL_LOCKED != Mcu_GetPllStatus()) { /* Wait until the PLL locks */ } /* Distribute the PLL clock to the system */ Mcu_DistributePllClock();  ← An error occurs here Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi @Teruhiko, Could you find more information about the error? What type of fault exception is it? https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 You could also step through the code to identify the exact location where the exception is triggered. Check the DCM_GPR registers for any error. RM, Table 231. DCM controlled features and availability in product family. It could be because of incorrect SRAM initialization after the reset. There is ERM that monitors that, but the clock of the module is gated of by default. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi danielmartynek-san, I apologize for the delayed response. Since communication with J-TAG is lost when the system transitions to Standby mode, I have not yet been able to obtain the detailed error information. I am currently writing debugging code. I would like to share what we currently know. I have investigated the reset causes under the following conditions: ・ Automatic reset recovery after an RTC timeout following a transition to Standby mode  → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt while in Standby mode after entering Standby  → Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt after the RTC times out following a transition to Standby mode  → Reset cause: MCU_POWER_ON_RESET I believe the reset factor is correct. I suspect that the differences in the boot sequence for each reset factor are related. Once I have more details about the error, I will respond separately. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, After the MCU exits Standby mode, it should be possible to attach the debugger. For easier debugging, consider adding an infinite loop at the start of the application so you can connect the debugger and step through the execution from there. volatile int var = 1; while(var){} If MCU_POWER_ON_RESET is observed instead of MCU_WAKEUP_REASON, please check the following registers: DCMROPP1–4. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, The clocks looks good. One question: when you run the MCU standalone after a POR (without the debugger), does the application work? The reason I’m asking is that when the application is started via the debugger, the debugger performs part of the system initialization. In standalone operation, the application must handle this initialization itself. After exiting standby, the MCU goes through a reset and the debugger is disconnected, so the behavior is effectively the same as a standalone startup. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, I apologize for the delayed response. I had some questions regarding our circuit design, so I was investigating how it related to this issue. As a result, I discovered that there was a problem with the port assignments in the circuit. When a reset occurred upon waking from standby, the supply voltage applied to the MCU became unstable. I greatly appreciate all the support you’ve provided so far. Thank you very much. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, What is the Mcu_InitClock(Standby) configuration? It still should be one of the Clock options e.g. Table 157. Option A - High Performance mode (CORE_CLK @ 160 MHz). What exactly do you mean when you say it behaves erratically or is unstable? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi daniel-san Thank you for your advice. I was able to reattach after resetting. When I step through the code, the MCU peripheral initialization succeeds, but the program behaves erratically when I call “xSemaphoreCreateRecursiveMutex()” during the process of starting the OS task. Furthermore, when stepping through this function, the behavior becomes unstable at the following section of the function `void * pvPortMalloc( size_t xWantedSize )` in `heap_4.c`. 2026-05-21 190438.png It appears that heap allocation is failing. Are there any steps I should take before transitioning to Standby mode? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, The settings for “Run” and “Standby” modes in this project are shown below. I believe the settings in Table 157 that you provided have been applied to Run mode. I also believe the clock values in Table 160 have been applied to Standby mode. I am setting a clock to these blocks so that the RTC can measure time and the WKPU can trigger a reboot. As I step through the code, the current information is displayed on the IDE console screen. When you execute the aforementioned “heapVALIDATE_BLOCK_POINTER()”, the console screen begins to scroll, and step execution becomes impossible . K314_StandbyMode.png K314_RunMode.png   Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Here’s how to transition to Standby mode. ・In the MCAL MCU module settings, “STANDBY” has already been selected as the Operation Mode for Standby mode. ・In the Clocks tool of Design Studio, I have already created separate Functional Groups for “Run” and “Standby.” 1. In normal operating mode, call the functions in the order “Mcu_InitClock(Run)” and “Mcu_SetMode(Run)” to operate in Run mode. ... 2. To transition to Standby mode, call “Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds)” to start the timer, which will automatically wake the system up in Run mode after a specified time via the RTC. 3. Call “vTaskSuspendAll()” to suspend all running OS tasks. 4. Call “Mcu_InitClock(Standby)” followed by “Mcu_SetMode(Standby)” to transition to Standby mode. The reason for calling vTaskSuspendAll() is based on the information in the link below. https://community.nxp.com/t5/S32K/S32K312-Does-FreeRTOS-need-to-be-shut-down-before-entering/m-p/1756857
記事全体を表示
针对 JN5169 异常处理的堆栈推送和弹出 HI 客户遇到异常情况,想分析堆栈内容,但找不到 JN5169 的 RISC 内核文档,因此不知道推送内核寄存器的顺序。 谁能帮助提供推送注册异常处理的顺序? 客户希望找到相关文件。 谢谢您! 德里克 优先级:正常 - 重要但不紧急 产品 JN5189 地区:亚太地区 主题:SW 工具(IDE | SDK | MCUXpresso 工具) 类型:文档 Re: stack pushing and popping for JN5169 exception processing @hiwave 你能告诉我们与此案相关的客户名称吗? @amigoo_li你能帮忙吗? Re: stack pushing and popping for JN5169 exception processing 你好@hiwave 如果客户启用调试日志,当设备崩溃时,它将打印如下所示的消息: 应用程序启动:切换开机启动 应用程序启动:看门狗计时器已RESET设备!EPCR = 9dcf2 : EEAR = 9dcf2 堆栈转储:  4007fc4 : 00080fe2  4007fc8 : 0009cec0  4007fcc : 1bf887c9  4007fd0 : 000882c6  4007fd4 : 00088ef1  4007fd8 : 00088f37  4007fdc : 00085df7  4007fe0 : 00084940  4007fe4 : 00080fe2  4007fe8 : 00001a12  4007fec : 00000000  4007ff0 : 00000000  4007ff4 : 0009cbfe  4007ff8 : 76543210  4007ffc : fedcba98 然后我们可以使用工具:arm-none-eabi-addr2line-e app.elf 0x00088f37 你可以在 AN1189 中查看源代码,当监视器 RESET 时,会打印堆栈转储消息。 顺祝商祺! Amigo Li
記事全体を表示
在下载模式下使用 UUU 无法成功为 i.MX93EVK 上的 eMMC 编程 WSL ubuntu 20.04 LF_v6.12.49-2.2.0_images_IMX93EVK.zip sudo uuu uuu.auto uuu(通用更新实用程序),用于 nxp imx 芯片 -- libuuu_1.5.243-4-ga377d1e 成功 0 失败 0 1:1-6458439E 1/ 1 [=================100%=================] SDPS: 启动 -f imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot Uboot 信息 U-Boot 2025.04-g4ddbad60eff3(Nov 19 2025 - 07:56:58 +0000) RESET 状态:POR CPU:1700 MHz 时的恩智浦 i.MX93 (52) Rev1.1 A55 CPU:40 摄氏度的工业温度等级(-40 摄氏度至 105C) 型号:恩智浦 i.MX93 11X11 EVK 主板 DRAM:2 GiB TCPC:供应商 ID [0x1fc9],产品编号 [0x5110],地址 [I2C2 0x52] snk.P ower3.0 on CCC1 _ pd_receive_message:轮询警报寄存器,TCPC_ALERT_RX_STATUS 位失败,ret = -62 TCPC:供应商 ID [0x1fc9],产品 ID [0x1fc9],地址 [I2C2 0x51] TCPC:供应商 ID [0x5110],地址 [I2C2 0x50] 核心:251 台设备,38 个 u 类,设备树:单独的 MMC:FSL_SDHC:0, FSL_SDHC: 1 无处 加载环境...好的 [*]-Video Link 0adv7535_mipi2hdmi hdmi @3d:找不到 cec 设备 id=0x3c 无法探测面板设备 hdmi @3d 无法获取显示时机探测视频设备 失败,ret -19 [0] 液晶显示器控制器 @4ae30000,视频 [1] dsi @4ae10000,video_bridge [2] hdmi @3d,面板 adv7535_mipi2hdmi hdmi @3d:找不到 cec 设备 id=0x3c 无法探测面板设备 hdmi @3d 无法获取显示时机探测视频设备 故障,ret -19 输入:串行输出:串行错误:串行错误:串行错误 BuildInfo: - ELE 固件版本 2.0.4-e804f3c9 MMC:没有卡 UID:6458439e25d046af8f8f67 4c2455dfa2dd 检测 USB 启动。将进入快速启动模式! Net: eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME] Fastboot:正常 从 USB 启动 mfgtools *** 警告-使用 mfgtools 的默认环境,使用默认环境 运行 bootcmd_mfg:运行 mfgtool_args; if iminfo${initrd_addr}; then if test${tee} = yes; then bootm${tee_addr} ${initrd_addr} ${fdt_addr} ; else${kboot} ${loadaddr} ${initrd_addr} ${fdt_addr} ; fi; else echo Run fastboot ...;${fb_cmd}; fi; 点击任意键停止自动启动:0 ## Checking Image at 83800000 ... 未知图像格式! 运行 fastboot... auto usb 0 无法配置默认 pinctrl 无法为 USB 初始化主板无法配置默认 pinctrl 无法为 USB 初始化主板未找到 USB 设备 未找到 USB 设备 USB 初始化 失败:-19 u- boot= > 非常感谢你的回答 Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode Hi @weiyi  在Windows下面烧写也会有这个错误吗? Best Regards, Zhiming Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode 我已经通过SD卡进入Linux,随后dd写入flash wic镜像修复了这个问题。 Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode 我的 FRDM-imx93 也遇到过同样的问题。从 Linux 系统刷写固件或许是一种解决方案,但如果其他人也遇到这个问题,以下方法对我有用。 当你获得 U-Boot shell 时: 未找到 USB 设备 USB 初始化失败:-19 u-boot=> 您可以尝试: => usb stop => usb start => fastboot usb 0 如果失败,请仅拔下/重新插上(板端)专用于串行下载的 USB 线,然后重复这些命令。这时,uuu 应该可以发现 USB,所以 uuu 可以继续进行。 请注意,uuu 将继续运行(等待 USB 设备出现)。
記事全体を表示
获取 TapLinx 许可证密钥时遇到的问题 我正在尝试使用 TapLinx SDK,需要离线 TapLinx 许可证密钥。 项目模式: 11823812 在 "我的项目 "页面,我刚刚创建了一个项目,但忘记将项目名称与应用程序 ID 应用程序 ID。 我把名称改回来了,但还是看不到许可证密钥。然后,我尝试删除文件并创建一个新文件。即使我是单独开发者,它也会提示:"You do not have access to delete the owner's detail record" 。 如何解决这些问题? 我需要什么? 1.验证我的账户为所有者 2. 给我基于项目模式: 11823812 的离线 TapLinx 许可密钥;或帮我删除项目模式: 11823812,让我创建一个新项目 谢谢!
記事全体を表示