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

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

关于 encrypted_xip_platform_*.c（在 mcuboot 中）的文档 你好， 在 mcuboot 源代码中，可以找到恩智浦提供的许多文件来处理加密 xip：sdk_25_06_00_evk-mimxrt1020/中间件/mcuboot_opensource/启动/nxp_mcux_SDK/Encrypted_XIP/ 在我的项目中，我使用 RT117x、RT105x 和 RT102x，因此要处理 BEE 和 OTFAD 外设。 我搜索了这些文件的文档和示例，例如https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcuboot_opensource/README.html#，但没有找到我要找的东西。 我需要知道 特性 用法示例 API 参考 我的使用案例如下： 图像 0 是第二阶段引导加载程序。它实现了 USB 主机大容量存储堆栈，这是更新设备的唯一方法。 图片 1 是实际应用。 我认为两幅图像都需要加密，但我并不确定。 你能告诉我在哪里可以找到使用这些来源的参考设计吗？ 此外，由于有两个图像，我需要 mcuboot 2.2.0（2.1.0对多幅图像无效）。 如此处所示，2.1.0 版已集成到最后一个 SDK 中： 顺祝商祺！ 最大值 Re: doc about encrypted_xip_platform_*.c (in mcuboot) 你好@mastupristi 很抱歉延迟回复。 作为替代方案，目前我们有基于 MCUboot 的SBL，可以实现加密 XIP。不过，它是基于旧版本的 MCUBoot。 我一直在内部检查，我的 SDK 团队说 SDK 现在内置了最新版本的 MCUboot。 基本上，您希望获得的附加信息包括......： 特性 用法示例 API 参考 但用于加密应用程序，对吗？我们是否可以说，关于将片上 OTFAD 与 MCUBoot 结合使用的示例目前对您有用？ 迪亚戈

Probes Not Found Error when attempting to connect to FRDM46lz board Probes not found error M4 Pro Macbook Sequoia 15.6 while attempting to connect to FRDM46lz board in MCUXpresso. Fellow students with Macs have not encountered this issue. Have been working hard with university staff but not found a solution. Have already attempted plugging into difference ports, restarting device, changing privacy settings, creating a new project, and uninstalling and reinstalling MCUXpresso, among other things. Help would be greatly appreciated, thank you! Re: Probes Not Found Error when attempting to connect to FRDM46lz board Hello @ottofhalb , Thanks for your post. Please open Device Manager and check whether the serial port has been successfully enumerated. In addition, have you ever tried to update the OpenSDA? OpenSDA Serial and Debug Adapter | NXP Semiconductors You may refer to attached "Updating the OpenSDA Firmware.pdf". Hope it helps. BR Celeste

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

imx8mp アプリ実行時に m4 を停止 imx8mp の A53 コアでユーザー アプリケーションを実行しながら、M4 コアで実行中のプログラムを確実に停止するにはどうすればよいですか?再起動後に M4 コアが自動的に再起動するため、デバイス ツリーやその他の設定を変更せずに特定のテストを実行する必要があります。これにより、テストを行っていないときでも、M4コアは正常に動作し続けることができます。

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

如何在 MCUXpresso IDE 中切换 C/C++ 库 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MCUXpresso IDE 支持三个 C/C++ 库：Newlib、NewlibNano 和 Redlib。Newlib 是一个标准的 GNU C/C++ LIB，包含全面的功能。NewlibNano 在 Newlib 的尺寸上进行了优化。而且 Redlib 提供的应用程序要小得多，它不是 GUN C 库。 MCUXpresso SDK 演示默认使用 Redlib，一些客户希望切换库以平衡代码大小和功能。 特别是对于小内存嵌入式芯片，推荐使用Redlib。 本文档主要包含两部分内容： 一、 MCUXpresso IDE中使用的不同C/C++库 二． MCUXpresso IDE 中的 Switch C 库 有关详细信息，您还可以参考 。

AUT-N1925 UCODE DNA - 世界初のセキュリティ付きUHFタグIC <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXPの最新世代のパッシブUHF RFIDは、UCODE® DNAと呼ばれ、自動車両識別(AVI)システムで使用できるため、適切に登録されていない車両のドライバーの識別と収集が容易になります。車両登録用のAVIシステムでは、リーダーを道路の上、下、または脇に設置できます。また、ハンドヘルドデバイスに埋め込んで、政府関係者が使用することもできます。車両に取り付けられたタグは、リーダーのRFフィールドによって生成されたエネルギーを使用するため、バッテリーは必要なく、タグの寿命は非常に長いです。暗号化ベースのセキュリティにより、エラーが最小限に抑えられ、不正行為が実質的に排除されます。車両の所有者(および料金徴収者)は、読み取りが非常に正確で安全性が高いため、適切な人物に請求されていることを確信できます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXPの最新世代のパッシブUHF RFIDは、UCODE® DNAと呼ばれ、自動車両識別(AVI)システムで使用できるため、適切に登録されていない車両のドライバーの識別と収集が容易になります。車両登録用のAVIシステムでは、リーダーを道路の上、下、または脇に設置できます。また、ハンドヘルドデバイスに埋め込んで、政府関係者が使用することもできます。車両に取り付けられたタグは、リーダーのRFフィールドによって生成されたエネルギーを使用するため、バッテリーは必要なく、タグの寿命は非常に長いです。暗号化ベースのセキュリティにより、エラーが最小限に抑えられ、不正行為が実質的に排除されます。車両の所有者(および料金徴収者)は、読み取りが非常に正確で安全性が高いため、適切な人物に請求されていることを確信できます。 セキュアなコネクテッド&自動運転車

CRTOUCH GUIの一般的な質問 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このドキュメントでは、CRTOUCH GUI の使用に関する一部の問い合わせについて、テクニカル サポート チームから寄せられた一般的な質問の一部に対する回答を提供します。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このドキュメントでは、CRTOUCH GUI の使用に関する一部の問い合わせについて、テクニカル サポート チームから寄せられた一般的な質問の一部に対する回答を提供します。 タッチ・センサ

imx95 低電力モード 私は Linux 6.12 (Yocto ベース) を実行するカスタム i.MX95 ボードに取り組んでいます。USB3 ホスト コントローラに関連する RAM へのサスペンド (ディープ スリープ) 障害が発生しています。echo mem > /sys/power/state を実行すると、システムは xhci-hcd: WARN: xHC CMD_RUN タイムアウト、続いて PM: 非同期サスペンドに失敗しました: エラー -110 でサスペンドを中止します。USB ホスト モードが有効になっている場合、アクティブな USB トラフィックがない場合でも、この問題が継続的に発生します。私は GPIO によって制御される固定 5V VBUS レギュレータを使用しており、USB3 コントローラ、PHY、クロック、および電源ドメインは DTS (添付) で定義されています。私の要件は、システムが正常にディープスリープに入ることができるようにしながら、低電力モード中に USB VBUS の電源を完全にオフにすることです。参考までに、完全なサスペンド/再開 dmesg ログと関連する USB 関連の DTS ノードを添付しました。i.MX95 で xHCI サスペンド タイムアウトを回避するために必要な正しい DTS および/またはドライバ側の処理に関するガイダンスを希望します。 Re: imx95 low power mode CANを使ってEVKボードで再現するための詳細な手順を教えていただけますか?ありがとう Re: imx95 low power mode カスタム ボードでは fusb302 を使用していますが、usb3.0 としては有効になっていないため、usb2.0 として使用しています。 しかし、ディープスリープに入ると ( echo mem > /sys/power/state )、xhci-hcd ドライバでエラーが発生します。 テストのセットアップ: • SoC: i.MX95 • OS: Yocto Linux (カーネル 6.x、NXP BSP) • USBモード: ホスト (xHCI、USB3) • コネクテッドデバイス: USBフラッシュドライブ（大容量ストレージ） ボードを通常通り起動します。 USB ストレージ デバイスを USB3 ホスト ポートに接続します。 lsusb を使用して列挙を確認し、デバイスにアクセスできることを確認します。 次を使用して低電力モードに入ります: エコーメモリ > /sys/power/state このステップ自体の後にはエラーが表示されます。 設定されたウェイクアップ ソース (電源ボタン/ GPIO) を使用してシステムを再開します。 再開後、USB デバイスが次のいずれかの状態であることを確認します。 検出されない、または dmesgにxHCI / DWC3関連のエラーが表示される、または 再び動作させるには USB を再度差し込む必要があります。 エラーログ: エコーメモリ > /sys/power/state [ 117.057281] PM: 進入を一時停止（深部） [ 117.066009] ファイルシステムの同期: 0.005秒 [ 117.071209] ユーザー空間プロセスのフリーズ [ 117.076800] ユーザー空間プロセスの凍結が完了しました（経過時間 0.001秒） [ 117.083781] OOMキラーが無効になりました。 [ 117.087011] 残りの凍結可能なタスクを凍結しています [ 117.132725] 残りの凍結可能なタスクの凍結が完了しました（経過時間 0.041 秒） [ 117.140164] printk: コンソールを一時停止しています (デバッグするには no_console_suspend を使用してください) [ 117.156868] sd 0:0:0:0: [sda] SCSIキャッシュを同期しています [ 117.267552] xhci-hcd xhci-hcd.2.auto: 警告: xHC CMD_RUN タイムアウト [ 117.267611] xhci-hcd xhci-hcd.2.auto: PM: dpm_run_callback(): platform_pm_suspend は -110 を返します [ 117.267631] xhci-hcd xhci-hcd.2.auto: PM: 非同期サスペンドに失敗しました: エラー -110 [ 117.267702] PM: 一部のデバイスがサスペンドに失敗したか、早期ウェイクイベントが検出されました [ 117.268017] ハブ 1-0:1.0:hub_ext_port_status が失敗しました (err = -108) [ 117.268044] usb usb1-port1: 無効にできません (err = -108) [ 117.516365] PM: デバイスの再開に0.248秒かかりました [ 117.570639] OOMキラーが有効になりました。 [ 117.573777] タスクを再起動しています...完了しました。 [ 117.575261] sd 0:0:0:0: [sda] テストユニット準備失敗: 結果: ホストバイト=0x01 ドライババイト=DRIVER_OK [ 117.578423] ランダム: システム再開時にcrngが再シードされました [ 117.587117] sda: 容量が 120164352 から 0 に変更されたことを検出しました [ 117.598136] PM: 一時停止終了 -sh: echo: 書き込みエラー: 接続がタイムアウトしました Re: imx95 low power mode こんにちは@kannappanさん、 さて、元旦は休みになります。オフィスに戻ったら、ボードで試してみて、ご返答させていただきます。 良い一日をお過ごしください よろしくお願いいたします。 リタ Re: imx95 low power mode こんにちは@Rita_Wang 、 上記の問題に対する返答はありますか。 よろしくお願いします カンナパン Re: imx95 low power mode こんにちは@kannappanさん、 今週は忙しすぎて申し訳ありませんが、来週テストして結果を共有します。 良い一日をお過ごしください よろしくお願いいたします。 リタ

IMX8MP 处理器出现 HAB 错误 亲爱的大家，正在尝试验证 i.MX8MP 板上的 HAB 签名我遇到了这些错误 HAB配置：0xf0，HAB状态：0x66 --------- HAB 事件 1 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0f 0xc0 0x00 0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00 0x00 0x00 0x00 0x50 STS = HAB_FAILURE (0x33) RSN = HAB_INV_INDEX (0x0F) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) --------- HAB 事件 2 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x42 0x5a 0x00 0x00 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB 事件 3 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x40 0x40 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) 它们来自这个开发环境 U-Boot SPL 2023.04-lf_v2023.04+g1e5b6c6bf2 谁能就这个问题给我点建议？预先致谢 Re: HAB Error on IMX8MP processor 你有没有可能解决这个问题，我也遇到了同样的问题，当我试图从 Srk1 转到 Srk2 时。 Re: HAB Error on IMX8MP processor 您好， RSN = HAB_INV_INDEX (0x0F) 表示给定索引中的密钥错误，或已安装密钥的目标索引不可用。检查 csf 文件。 请参阅 HAB API，您可以在其中找到有关这些错误的更多详细信息。API 与您下载的 CST 工具一起用于签名。 此致 哈维

LPC55xx：启用柔性通信接口 USART CMSIS 的时钟源 你好 运行 MCUXpresso IDE 25.06 和用于 LPC5536 的 SDK 25.06。我使用配置工具来配置通过"新项目向导" 创建的新项目的硬件接口。 我首先使用时钟 工具将 CPU 时钟配置为 100 MHz。 接下来，我使用外设工具将 Flexcom0 配置为 USART（CMSIS 通用驱动程序）。当我添加该接口时，配置页面正确显示了一个错误："clock source is not configured" 。 它还快速提示我可以启用 FXCOM0 时钟： 我选择"启用 FXCOM0 时钟" ，然后错误指示灯就消失了。 我点击"更新代码" 。然后关闭 "外设 "窗口，返回 "显影 "视图。 现在我打开 Clocks Tool（时钟工具），以更改 FXCOM0 时钟的路由。 可以看到"FXCOMCLK0" 时钟已启用： 在这里，我将 FCCCLKSEL0 从"main_clk" 改为"system_pll_divided_clock。这将禁用 FXCOMCLK0。 点击"更新代码" 后，我再次打开外设工具。 在那里，我看到了与之前相同的错误指示器，即断言 Flexcom0 时钟未配置（正确）。 现在，我再次使用之前的"快速修复" ，让外设工具为我启用时钟。 我打开时钟工具，发现时钟路径上的一些元器件现在已启用，但以前曾被禁用： 和以前一样，我不想使用"main_clk" 的时钟路由，而是使用"pll_clk_div" 的时钟路由。 当切换到"pll_clk_div" 时，FXCOMCLK0 会再次禁用。Arrrgghh. 我到此为止。这显然不是将时钟路由到硬件接口的有效工作流程。在不同的配置工具之间来回切换需要太多的麻烦。 因此，我从振荡器开始为时钟布线。这在我按下 PLLDIV 之前一直有效。 该元素已禁用，我不知道如何启用它。我尝试双击它、名称、分频器、" 处于非活动状态的 " 文本，但无济于事。 最后，我右键单击元素，选择"编辑设置：PLLDIV" 。在这里，我尝试输入"PLLDIV Frequency" ，但弹出的错误窗口称该元素已禁用。我绝望地点击了 " 暂停分频器计数器 " 然后选择了 " 启用分频器计数器 "。 你能相信吗？🤷‍♂️ 时钟工具在这方面确实很不方便，也不直观。它应该提供 " 快速修复 " 以轻松启用任何元器件。这将很有帮助。 Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS 你好@marek_neuzil、 真聪明非常感谢你花时间写出如此详细和全面的回答。我非常欣赏你的深入研究。 在我的下一个项目中，我一定会尝试你描述的步骤。 致以最诚挚的问候， Daniel Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS 你好@danielholala、 我检查了您的使用案例和您报告的问题。外设工具中提供的启用 FXCOM0 时钟功能只是时钟工具的快捷方式。时钟工具为时钟图中的每个电平输出提供相同的功能： 您的用例可以在时钟工具中处理，无需切换工具。每个电平输出的快捷菜单都包含 “启用” 命令。此功能只是通过启用时钟路径上的时钟门、分频器和其他元件来启用时钟。您的特定要求必须通过手动选择时钟源和选择 PLL 模式、配置外部时钟源（还必须根据板的连接手动指定外部时钟源/晶体）来处理。 例如，如果您想使用启用 FXCOM0 时钟命令，可以这样做： 选择 FCCLKSEL0 的main_clk时，选择系统 PLL 分频 ，然后点击启用 FXCOM0 时钟。 然后选择main_clk（因为这是 FRGCLKSEL0 的唯一有效时钟源），然后必须选择pll_clk_div ，因为要使用 PLL 输出。 再次处理启用 FXCOM0 时钟命令时，请参阅下文： PLLDIV 分频器已启用： 请注意，PLL 本身不使用，PLL 被旁路，因为 PLL 未配置。它提供两种功能模式和其他必须指定的设置。 例如，选择 "正常 "模式时，将启用 PLL 并设置 384 MHz 频率。 如果板使用晶体，例如 16 MHz，则必须在 XTAL 时钟源详细信息设置中将其设置为包括电容和工作模式： 您可以为 PLL 选择外部时钟源和源时钟： 时钟门是禁用的，因此您可以在 "细节 "视图设置中手动启用它（单击元素）。 选择启用和时钟值： 您还可以在时钟图中指定输出频率： 时钟工具会选择可能的时钟分频器并提供满足要求的设置： 选择所需频率也会导致频率输出锁定（图中频率附近的锁定图标）。 如果您需要的频率无法通过现有时钟路径实现（例如 FXCOMCLK2 的 30 MHz），则可以使用 FXCOM2 时钟的高级解析器： 它对可能的时钟路径进行了更复杂的分析，并尝试为所有要求和锁定设置找到可能的解决方案。在这种情况下，它会更改主时钟和 PLL 频率的设置： 时钟工具为现代 MCU 的复杂时钟模型提供高级支持，这些模型为所有外设和系统模块提供多种时钟路径设置，有时还需要更高级的用户配置以满足特定要求。 如果您还发现任何问题或需要改进，请随时与我联系。我们仍在开发新功能，并在下一版配置工具中为客户做出改进。 顺祝商祺！ 马雷克-诺伊齐尔 Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS @danielholala 你好、 我使用的是 MCUXpresso IDE 最新版本的 ConfigTools，即 25.6.136。 尽管如此，我会将您的信息作为宝贵建议转发给 ConfigTools 团队。 Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS 亲爱的 EdwinHz，感谢您的回复。 你的时钟工具版本和我的不一样吗？禁用 CTIMER4CLKDIV 时无法启用 CTIMER4 时钟。这对我来说是有感知的。我认为将时钟从源（振荡器）路由到目标元器件（例如 CTIMER4 时钟）是一种很好的做法。大图中，从左到右依次为 我坚信，当我为时钟分频器选择频率或更改 " Clocks 图 " 中的分频器值后自动启用时钟分频器时，用户体验可以得到明显而关键的改善。 希望您能将我的建议转达给 ConfigTools 团队。 谢谢。 丹尼尔 Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS @danielholala 你好、 在这种特殊情况下，需要先启用 CTIMER4 时钟，才能修改 CTIMER4CLKDIV 的值： 考虑到分频器的输出直接是 CTIMER4 时钟，正如你所提到的，也许它还应该从 CTIMER4CLKDIV 的配置中启用它。我将把这一请求转达给 ConfigTools 团队，以便他们对实施情况进行评估。 BR, Edwin. Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS 亲爱的@EdwinHz、 你建议输入一个频率来启用分频器。这很直观，我同意。 我试过这个，但对我不起作用。如果我输入频率，会弹出一个警告窗口，告诉我分频器已禁用，请参见屏幕截图： 我认为在我输入频率或修改分频器值时启用分频器会很直观（例如，只需点击文本 " /1 " 上的元素下方）。 我希望配置工具团队能在今后的更新中解决这个问题。 Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS @danielholala 你好、 当点击这些分频器中的任何一个方块时，你会看到右边的 " Details " 窗口将发生变化，以反映该方块可能发生的变化。因此，编辑过程是点击区块，然后通过在"Details" 窗口设置频率来启用它： 此外，您还可以右键单击程序块，然后选择"编辑其设置：在这种情况下，PLDIV" ，就像你之前在帖子中提到的那样。这样，就会出现一个弹出窗口，其中的所有设置与之前的 "详细信息 "窗口相同： BR, Edwin Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS 谢谢@EdwinHz 的回复。我知道"quick fix" 无法知道我要使用哪个时钟源。因此，这不是我的主要不满。 我的主要抱怨是关于启用时钟分频器，例如PLLDIV： 我找不到用鼠标在时钟图上启用它的方法。这是一次令人沮丧的经历。 有没有办法通过鼠标操作来启用它？ 如果没有，我建议添加一个。 谢谢 Daniel Re: LPC55xx: enable clock source for flexcomm interface USART CMSIS @danielholala 你好、 我理解 ConfigTools 带来的挫败感，有时，当"修补" 某个东西时，可能会"破坏" 其他东西。问题是，在这种情况下，使用 ConfigTools 提示的"快速修复" 选项就能快速、轻松地解决时钟初始化问题。我知道您不希望在这种情况下使用主 CPU 时钟，但在这种情况下，这是 ConfigTools 可以提供的最快速、最简单的修复方法。如果要进行更细微的配置，则需要手动设置。 BR, Edwin.

VS Code の MCUXpresso: SDK サンプルの操作 このガイドでは、次の内容について説明します。 スタンドアロン SDK からサンプル プロジェクトをインポートする方法 ビルド、フラッシュ、デバッグの方法 シリアルモニターの使い方 (マイビデオで視聴) MCUXpresso for VS Code

[i.MX] Dual Wi-Fi(5GHz, 2.4GHz) + BLEによるheart Beatソフトデモ コンテンツ： - i.MX 2台を使用してデュアルバンドWi-Fi（5GHz、2.4GHz）とBLEをテストできます。 - 上記の手作業の分析 詳細については、readmeを参照してください。 テスト環境: 2 台の i.MX 8M Plus EVK または 2 台の i.MX 8M Quad EVK。 試し済みBSP: imx-image-full、LF6.12.20_2.0.0 ローカル conf 設定: IMAGE_INSTALL:append = "bluez5 bluez5-noinst-tools bluez5-obex openobex obexftp glibc-gconv-utf-16 glibc-utils python3-pybluez bluez-tools ppp" 以下は分析結果の例です コンテンツ： - i.MX 2台を使用してデュアルバンドWi-Fi（5GHz、2.4GHz）とBLEをテストできます。 - 上記の手作業の分析 i.MX プロセッサ SW | ダウンロード 日本語ブログ

ST7701ドライバ Hello ST7701 ディスプレイ コントローラと通信しようとしています。 いくつか例はありますか?可能であれば、共有していただける方はいらっしゃいますか? i.MX RT1170 ボードを使用しています。SDK のサンプルには、HX8394、RM68191、および RM68200 ディスプレイ コントローラ用のドライバが見つかりました。ST7701 に似たものを見つけたいと思います。 誰か助けてくれませんか？ ありがとうございます。 フランチェスコ・ソリート Re: ST7701 drivers こんにちは、 @SolitoFrancescoさん、 現時点では、 ST7701 ディスプレイ コントローラ用の SDK にはドライバ サポートがありません。このコントローラとの統合は手動で行う必要があります。 ディスプレイ コントローラとの互換性を保つには、LCDIF モジュールの解像度値、同期信号、クロック周波数を調整することが重要です。EVK を使用する場合は、SDK ドライバを使用して次の関数の値を調整できます。 BOARD_InitLcdifClock() BOARD_InitMipiDsiClock() BOARD_SetMipiDsiConfig () これらの関数は同期値のマクロとともにすべて「display_support.c」で参照されています。このファイルは、ディスプレイ コントローラ のサポートを調整するときに重点的に扱うファイルになります。   また、次のアプリケーションノートも必ずご覧ください。LCDディスプレイのセットアップ方法やその他の役立つ考慮事項について、さらに詳しく説明しています。i.MX RT eLCDIF RGBモードの使用例（NXP.com）   BR、 エドウィン。 Re: ST7701 drivers おはよう ディスプレイ製造元とドライバ製造元から受け取った指示に従って、ご指摘のファイルを変更しました。MIPI を介してドライバ レジスタに書き込み、読み取ることができます。オシロスコープで差動 MIPI 波形を見ることはできますが (「構成」フェーズ後も)、ディスプレイにはまだ何も表示されません。私は「mipi_dsi_compiance_test」というNXP SDK のデモ例を使用しています。 もっと助けていただけますか？ ありがとうございます。 フランチェスコ・ソリート Re: ST7701 drivers こんにちは、 @SolitoFrancescoさん、 実行中にコードをデバッグできましたか?何かエラーメッセージが印刷されていますか?データ ラインにはどのようなデータ パターンが表示されますか?これらのパターンは、readme.md ファイルに記載されている予想されるパターンと一致していますか? BR、 エドウィン。 Re: ST7701 drivers こんにちは。サンプル プロジェクトは、ディスプレイ DEMO_PANEL_RK055MHD091 で正常に動作します。次に、最終的なアプリケーションで使用するパネルに切り替えました。解像度が異なる (480x800) ため、定義を調整しました。その後、ドライバを変更しました（fsl .hおよび.cファイル) を読み込み、ディスプレイと通信できるようになりました。レジスタへの書き込みと読み出しが可能です。しかし、ディスプレイの構成後、サンプル プロジェクトがイメージ バッファーの送信を開始すると、オシロ スコープ上で MIPI 波形が表示されますが、ディスプレイには何も表示されません。専用コマンドを使用してすべてのピクセルをオンにしてみたところ、画面が完全に白く表示されるため、ディスプレイは壊れていないと考えられます。私が理解できないのは、問題がディスプレイの構成にあるか、またはサンプル プロジェクトで適応させる必要がある他の何かにあるかということです。ディスプレイメーカーとコントローラメーカーに問い合わせましたが、各方面からの可能な限りの支援が必要です。ディスプレイに搭載されているコントローラー用の fsl ドライバーを入手することは可能ですか?Sitronix ST7701 です。私にお知らせください。ありがとう、そしてよろしく。フランチェスコ Re: ST7701 drivers こんにちは、 私も同じ状況です (同じドライバと解像度、ベースは開発ボードで動作したテスト例です)。コントローラーは構成されており、ステータスも読み取ることができ (エラーなし)、DSI ラインにデータも存在しますが、画面には何も表示されません。 dsi_dpi_config の videoMode を kDSI_DpiBurst から他のモードに変更しても効果はありません。 画面がビデオストリームを受け入れていないようですね？ Re: ST7701 drivers こんにちは、フランチェスコさん。 ディスプレイを動作させることができました。 DisplayTFT_SetMipiDsiConfig 関数に次の行を追加します。 dsiConfig.enableNonContinuousHsClk= 真; たとえば、次の行の後: DSI_GetDefaultConfig(&dsiConfig); dsiConfig.numLanes = DISPLAY_MIPI_DSI_LANE_NUM; dsiConfig.autoInsertEoTp= 真; ディスプレイ IC が正しく構成されており (必要な場合は、画面の構成を共有できます)、ディスプレイ クロック (私の設定は約 26 MHz) も正しく構成されていることを前提としています。 よろしくお願いいたします、クリス Re: ST7701 drivers こんにちは、リノ ご提案ありがとうございます。私のアプリケーションでも動作するようです。素晴らしい。おそらく何かをより適切に設定する必要があると思いますが、今は画面に画像が表示されるようになりました。 可能であれば、設定を共有していただければ、私の設定と比較して、より改善することができます。何か違うことが分かったらここでお知らせします。 改めて感謝申し上げます。enableNonContinuousHsClk 設定はどこで思いつきましたか? 敬具、 フランチェスコ Re: ST7701 drivers こんにちは、リノ 私の設定とあなたの設定を比較しています（最後にここにアップロードします）。 その間、私が気づいたのは、私が使用しているのは ST7701 ですが、おそらくあなたは ST7701S (末尾に S が付く) を使用しているということです。似ていると思いますが、よく分かりません。 気づいたことは、初期化をまったく行わなくてもディスプレイが機能するようになったことです。起動は「ゆっくり」で明るさも低いですが、動作します。次に、0xE0 から 0xEF までの設定 (ST7701 データシートに記載されていない) のみを送信すると、ディスプレイが非常に高速に起動し、正しい色で表示されます。その他の設定はすべて必要ないようです（奇妙に聞こえます）。 連絡を取り合いましょう。終わったら比較を共有します。 改めてお礼申し上げます。 敬具、 フランチェスコ Re: ST7701 drivers こんにちは、 ファイルは SDK 内の他のドライバに基づいて作成されました。 遅延を短いものに変更することもできます。 今朝、設定手順を確認し、ディスプレイメーカーの推奨に従っていくつか変更してみましたが、それ以上の改善が見られなかったため、DSI 設定自体を詳しく調べ始めました。クロックは正常で、ビデオ モード (バースト モード) も正常であることはわかっているので、残されたオプションは DSI 自体のオプションのみでした。 以下の内容（およびドキュメントの他の部分）を理解します。 https://docs.nxp.com/bundle/AN13573/page/topics/連続クロックと非連続クロック.html BR、クリス Re: ST7701 drivers こんにちは、リノ お約束どおり、あなたと私の設定の比較を添付ファイルでご覧ください。詳しくは触れませんでしたが、私や皆さんが相違点の中に何か興味深いものを見つけたら、ぜひここに書き続けましょう。 敬具 フランチェスコ Re: ST7701 drivers こんにちは、フランチェスコさん。 遅れてごめんなさい。 あなたの比較を見て、多くの違いに気づきました。それは、一部は画面自体によるものです（私たちはガラス/タッチ/スクリーンのサンドイッチを使用しており、それに対する構成修正がありました - 少なくともサプライヤーはそう説明していました） 🙂 ) が表示されます。 電源制御などの一部の設定は起動には必要ありませんが、品質の向上（コントラスト/ガンマ設定）に必要です。 面白いのは、それを実行しているかどうかに関係なく、この「Sunlight Readable Enhancement」と呼ばれる機能全体が必須だということです。このデータに基づいて、最適なパラメータを自動的に設定します。これらが間違っているか欠落している場合（デフォルト値）、自動的に設定されるまでに時間がかかります -> そのため、お気づきのとおり、起動が遅くなります。 ドキュメント自体はかなりイライラさせるもので、多くのコマンドはドキュメント化されておらず、それらなしでは画面を完全に起動することが不可能な場合がよくあります。これはこのモデルに限ったことではなく、他のいくつかの Sitronix モデルでも同様の現象が発生しました。 敬具、 クリス

eIQ and MCUXpresso SDK 26.03 with VSCode There are some items to be aware of when using eIQ projects in VSCode with MCUXpresso SDK 26.03 Debugger hangs when debugging eIQ examples on i.MX RT700 in VSCode There are two work-arounds available: 1) Use a JLink to debug the project instead of the default CMSIS-DAP interface. To do this: Install LinkServer Put a jumper on JP20 on the i.MX RT700 EVK, Update the MCULink firmware to use JLink by running C:\NXP\LinkServer_25.12.83\MCU-LINK_installer\scripts\program_JLINK.cmd Take off the jumper on JP20.  2) Alternatively update the linker file in the eIQ project:  Open the MIMXRT798Sxxxx_cm33_core0_flash.ld linker file in Repository->mcusdk->examples->_boards->mimxrt700evk->eiq_examples->tflm_label_image->cm33_core0->gcc  (use the path based on the eIQ project name that you are trying to use) In that linker file go to line 198 to 203 and replace the .ncache section with the code below:   .npu_ncache (NOLOAD) :   {       KEEP(*(.npu_ncache_data))       KEEP(*(.npu_ncache_data*))   } > m_ncache   ASSERT(. < 0x20580000, "Error: .npu_ncache cannot go beyond SRAM P18")   .ncache (NOLOAD) :   {     *(NonCacheable)     . = ALIGN(4);     __noncachedata_end__ = .;     /* define a global symbol at ncache data end */   } > m_ncache i.MX RT700 eIQ HiFi4 and HiFi1 projects cannot be imported or compiled in VSCode or command line GCC. In VSCode use the "Repository" import option. To compile the projects you must install Xtensa Xplorer, the RT700 license, and RT700 NewLib DSP Configuration file. Then add the following environmental variables: XCC_DIR=/ /XtDevTools/install/tools/RI-2023.11-win32/XtensaTools XTENSA_CORE=rt700_hifi4_RI23_11_nlib The project can then be compiled with command-line GCC with: west build -p always --sysbuild examples/eiq_examples/tflm_cifar10_hifi4/cm --toolchain armgcc --config flash_debug -b mimxrt700evk -Dcore_id=cm33_core0 Note that if using HiFi1 projects then XTENSA_CORE should be set to rt700_hifi1_RI23_11_nlib Also an additional compile option called -mlongcalls needs to be used to avoid issues when adding additional operators the ops list. Inside \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4\hifi4 edit the reconfig.cmake file in the mcux_add_xtensa_configuration options: mcux_add_xtensa_configuration( CC "-DXOS_CLOCK_FREQ=237500000 -std=c99 -mlongcalls" CX "-stdlib=libc++ \ -mlongcalls \ -std=c++17" ) A warning message comes up in eIQ Neutron SDK 3.1.2 If using eIQ Neutron SDK 3.1.2 then the follow warning will appear on the serial terminal during the model initialization: Unable to save model handle, call neutronModelUnprepare() when done This warning is not relevant for Neutron C devices like RT700 and MCX N and can be ignored as it does not impact inference time or accuracy. It will be fixed in the next eIQ Neutron SDK release. Some eIQ files that are commonly modified are shared among all eIQ examples For example, the Neutron libraries are shared among all eIQ examples. This can cause version compatibility issues with the default eIQ examples if the eIQ Neutron libraries are updated with eIQ Neutron SDK. This is because the eIQ projects in MCUXPresso SDK were converted using Neutron Converter 3.0.0 and the Neutron libraries in the SDK are shared among all eIQ projects.  To work around this, either revert the Neutron libraries back to version 3.0.0 or else download a separate repository to use the default eIQ examples. 

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

需要澄清 MK70 DDR 控制寄存器 21 规范 大家好， 我在 MK70FX512VMJ12 控制旧版板上的 DDR 时遇到了问题。 我们正在使用 MQX。问题来自引导加载程序中的以下一行： ddr->CR21 = 0x00060232; 我假设该行将 DDR_CR21 寄存器（如 K70 参考手册第 34.4.22 节所述）设置为 0x00060236。 参考手册指出，注册字段分为 2 个字段。 31–16 MR1DAT0 Data to program into memory mode register 1 for chip select . 15–0 MR0DAT0 Data to program into memory mode register 0 for chip select . 大多数 DDR 制造商将这些寄存器称为模式寄存器（MR 或 MRS）和扩展模式寄存器（EMR1、EMR2、EMR3）。我是否应该假定，字段 15-0 的数据将由状态机写入 DDR 的 MR（模式寄存器），字段 31-16 的数据将写入 EMR？ 我怀疑，无论 DDR_CR21 中设置的值是多少，状态机都会发出必要的控制信号，这一点需要得到支持工程师的确认。这是因为考虑到我在 DDR_CR21 (0x0006) 的第 31-16 位写入的数据为 3 个 MSB 位分配了 000，为了正常运行，这些位应按照 DDR 规范的要求设置为 001。 DDR 规格说明："写入扩展模式寄存器的方法是将 CS#、RAS#、CAS#、WE#、BA1 置低，将 BA0 置高，同时控制地址引脚 A0 ~ A12 的状态。" BA2、BA1 和 BA0 所需的设置为 "001"，而我写入 DDR_CR21 的值为 "000"。 DDR 同步动态随机存取存储器(SDRAM) 控制器是否会将在 DDR_CR21 中设置的值覆盖为正确的值？ 谢谢， dodocolby Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 感谢您使用我们的社区。我注意到了你的问题。 我需要一些时间进行研究，然后再给您答复。如果在此期间有任何更新，请随时与我们分享。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 能否请您告诉我芯片的掩码集？ 据我所知，掩膜组 3N96B 零件有勘误表e10521。   另外，您使用的是哪个版本的 MQX？我知道 MQX 4.x 存在与 SIM_MCR DDRDQSDIS RESET 状态有关的问题，这一点需要清除。   虽然 MQX 已不再受支持，但我注意到在以前的案例中，它们都使用了 ddr->CR21 = 0x00040232；而不是您提到的值： 0x00060232.   例如，随着温度升高，K70 DDR2 读取失败 - NXP Community K70 DDR2 温度影响读取数据 - NXP Community   这就是我提出上述问题的原因。   BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好， ，我使用的是MQX 4.2 和 5N96B。 随着温度的升高，我们实现了 " K70 DDR2 读取失败——恩智浦社区 K70 DDR2 温度会影响读取数据——恩智浦社区 "，看来该设备对温度不再敏感了。 谢谢   Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 是的，我之所以引用这两个链接，是因为我注意到他们提到的代码使用 ddr->CR21 = 0x00040232 而不是 60232 。我只是想确认这一点，因为我这边无法访问 MQX 代码，它已不再受支持。此外，我已经联系了内部团队，以帮助进一步解决您的问题。一有回音，我就告诉你们。感谢您的理解。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 抱歉让您久等了。我还没有收到我们内部团队的任何更新，可能是因为圣诞假期的缘故。 请注意，由于欧洲、中东和非洲地区以及 AMEC 时区的假期，我们的回复时间可能会比平时长。我也将从明天开始休假，直到 1 月 5 日。 如果此事很紧急，您可以考虑创建一个新的案例并提及此链接。其他同事将能通过此案例找到我的内部联系人，您有可能在 1 月 5 日之前收到更新信息。 如果不紧急，我回去后会继续跟进。我们衷心感谢您的理解和耐心。 祝您愉快 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 希望你一切顺利。对不起，我的回复晚了。请参阅我们内部团队的答复： " 由于 DDR 控制器可支持多种不同内存大小和配置，且地址引脚总数各不相同，因此加载到 MRnDATA 字段的模式寄存器数据不应包括组地址值。控制器将自动驱动正确的银行地址值（以及模式寄存器写入命令的其他控制信号）。寄存器值只需包括地址行部分。 " 希望对你有所帮助。如果您有其他问题，请告诉我。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 感谢您的确认。

linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx linux6.12+imx8mp内核启动时报告： [ 0.057737] /soc@0: 固定了与 /soc@0/bus@30000000/efuse@30350000/unique-id@8 的依赖循环 [ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环 [ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000：修正了与 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环 [ 0.059239] /soc@0/interrupt-controller@38800000: 修正了与 /soc@0/interrupt-controller@38800000 的依赖循环 [ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: 修复了与 /soc@0/bus@30000000/pinctrl@30330000/miscgrp 的依赖循环 [ 0.061986] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/hoggrp [ 0.062566] imx8mp-pinctrl 30330000.pinctrl：initialized IMX pinctrl driver [ 0.063301] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.064431] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.065497] /soc@0/bus@30000000/clock-controller@30380000: 修正了与 /soc@0/interrupt-controller@38800000 的依赖循环 [ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环 [ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000：修复了 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环 [ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环 [ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000：修正了与 /soc@0/bus@32c00000/hdmi@32fd8000 的依赖循环 [ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000：修正了与 /soc@0/bus@32c00000/lcd-controller@32fc6000 的依赖循环 原因是什么？需要处理吗？ Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao  这是正常的，不用处理。 Best Regards, Zhiming Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao  这是内核上游引入得补丁，具体commit信息是： driver core: fw_devlink: Stop trying to optimize cycle detection logic commit bac3b10b78e54b7da3cede397258f75a2180609b upstream. In attempting to optimize fw_devlink runtime, I introduced numerous cycle detection bugs by foregoing cycle detection logic under specific conditions. Each fix has further narrowed the conditions for optimization. It's time to give up on these optimization attempts and just run the cycle detection logic every time fw_devlink tries to create a device link. The specific bug report that triggered this fix involved a supplier fwnode that never gets a device created for it. Instead, the supplier fwnode is represented by the device that corresponds to an ancestor fwnode. In this case, fw_devlink didn't do any cycle detection because the cycle detection logic is only run when a device link is created between the devices that correspond to the actual consumer and supplier fwnodes. With this change, fw_devlink will run cycle detection logic even when creating SYNC_STATE_ONLY proxy device links from a device that is an ancestor of a consumer fwnode. 6.12上面的fw_devlink框架相比以前更健壮，Fixed dependency cycle(s) with表示 fw_devlink 检测到环，并通过调整链接策略（例如降级某些 link 类型或不创建某些 link）来解决问题。这不是错误，而是信息提示，说明系统在启动时处理了潜在的死锁风险。 driver core: fw_devlink: Make cycle detection more robust fw_devlink could only detect a single and simple cycle because it relied mainly on device link cycle detection code that only checked for cycles between devices. The expectation was that the firmware wouldn't have complicated cycles and multiple cycles between devices. That expectation has been proven to be wrong. For example, fw_devlink could handle: +-+ +-+ |A+------> |B+ +-+ +++ ^ | | | +----------+ But it couldn't handle even something as "simple" as: +---------------------+ | | v | +-+ +-+ +++ |A+------> |B+------> |C| +-+ +++ +-+ ^ | | | +----------+ But firmware has even more complicated cycles like: +---------------------+ | | v | +-+ +---+ +++ +--+A+------>| B +-----> |C|<--+ | +-+ ++--+ +++ | | ^ | ^ | | | | | | | | | +---------+ +---------+ | | | +------------------------------+ And this is without including parent child dependencies or nodes in the cycle that are just firmware nodes that'll never have a struct device created for them. The proper way to treat these devices it to not force any probe ordering between them, while still enforce dependencies between node in the cycles (A, B and C) and their consumers. So this patch goes all out and just deals with all types of cycles. It does this by: 1. Following dependencies across device links, parent-child and fwnode links. 2. When it find cycles, it mark the device links and fwnode links as such instead of just deleting them or making the indistinguishable from proxy SYNC_STATE_ONLY device links. This way, when new nodes get added, we can immediately find and mark any new cycles whether the new node is a device or firmware node. Best Regards, Zhiming