LPC5514JBD64EはWS2812用です。 こんにちは、初心者LPC5514JBD64E WS2812の扱いに適していますか?もしそうなら、コードやその他の詳細はどこで入手できますか? よろしくお願いします。 LPC55xx Re: LPC5514JBD64E Use for WS2812. こんにちは、@Kishore02さん 投稿ありがとうございます！ LPC551x向けのWS2812の実装については情報がありませんが、プログラマブルロジックユニットを使うことができます。他のデバイスでは、アプリケーションコードハブのMCXA366 https://mcuxpresso.nxp.com/appcodehub?search=an-emulating-ws2812-bus-with-flexio-on-mcx366  また、Kinetisボード向けに実装した同僚の投稿もあります:NXP FlexIO Generator for the WS2812B LED Stripe Protocol( LED Stripe Protocol) この情報が参考になれば幸いです。

「MPC5777C-1b+2b_RAM_ECC_error_injection GHS614」のサンプルコードについて こんにちは。現在、MPC5777C MCUを基に開発中です。 開発プロセスに関して質問があります。 「MPC5777C-1b+2b_RAM_ECC_error_injection GHS614」というサンプルコードを基に、ECCチェックを実行するコードを設計しました。 通常の状況下では、このコードはECCチェックを正しく実行します。 しかし、MCUに接続されたTrace32のようなデバッガでECCチェックコードを実行すると、ビット誤りが検出されないエラーが頻繁に発生します。 「GHS614」例コード全体が、Trace32のようなデバッガに接続したときに正しく動作しない可能性はありますか? よろしくお願いします。 Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 Trace32デバッガが接続されていてダンプウィンドウが開かれ、カスタムアプリケーションコードが実行されていると仮定すると、GHS614を参照して設計されたECCチェック機能内でビットエラーが検出されないケースが発生する可能性はありますか? Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 あなたのシステム構成がどのようなものかは分かりませんが、トレースで開いているダンプウィンドウは常にメモリを読み取っており、ECC障害が検出されるとすぐに発生することに注意してください。 破損していないアドレスでは、ECCエラーは決して発生しません。ECC機構もEDCによって保護されている。それは到底不可能なことだ。 よろしくお願いいたします。 ピーター Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 ソフトウェアまたはデバッガによって読み取られるアドレスが破損している場合、例となるソフトウェアやその他の影響に関係なく、ECCは常に上昇します。 よろしくお願いいたします。 ピーター Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code こんにちは、 状況をもう少し詳しく説明します。 私のECCチェックコードの実行手順は以下のとおりです。 (void)FCCU_ClearNCF(); /* 1ビットRAMデータエラー注入 */ GenerateRam1bitEccError(); uiErmSR0 = ERM.SR0.R; uiErmSR1 = ERM.SR1.R; uiErmSR2 = ERM.SR2.R; /// 4. RAM 1ビットECCエラーが発生した場合は、以下を実行します。 if((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR)) { /// 4.1.ERM EARレジスタに格納されている値が、エラーが発生したアドレスと同じである場合は、以下の手順を実行してください。 if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R)) { ucStatus = OK; } /// 4.2.ERM EARレジスタに格納されている値が、エラーが発生したアドレスと一致しない場合は、以下の手順を実行してください。 そうでなければ、(UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R) の場合 { ucStatus = OK; } そうでない場合、 { ucStatus = NOT_OK }; } /// 5.RAM 1ビットECCエラーが発生しなかった場合は、以下の手順を実行してください。 そうでない場合、 { ucStatus = NOT_OK }; この構造は、1ビットのRAMデータエラーを強制的に挿入し、ECCエラーが正常に発生したかどうか、および発生アドレスが正確に検出されたかどうかを確認します。 上記のコードが実行中にTrace32のメモリダンプウィンドウを有効にした場合、ECCチェックの結果が異常に実行される可能性はありますか?（つまり、ECCエラーの検出失敗、またはECC発生アドレスでのエラー） よろしくお願いします。

S32K396 および FS26 REG_CORRUPT 皆様 FS26 の「REG_CORRUPT」フラグを解消しようとしています。添付の 2 枚のスクリーンショットは、関連するすべてのレジスタの読み取り結果を示しています。 最初の「AE」読み込みコマンドの直前に、ウォッチドッグのファーストキックを成功させてFSの状態をINIT_FSから外し、フェイルセーフレジスタの状態の正しさを評価しました。0x28回答から、REG_CORRUPTビットが設定されたデバッグモードに入っていることがわかります。 ウォッチドッグのキックが成功したことは間違いありません。キック直後にFS_DIAG_SAFETY1を読み取ったところ、戻り値は0x0103で、エラーフラグはなく、ABIST1_OKとLBIST_STATUS = OKでした。 0xAE コマンドの後、0xAF コマンドを発行してレジスタに 0x1800 を書き込んで OTP_CORRUPT ビットと REG_CORRUPT ビットをクリアし、その後レジスタ 0x41 から順に 12 個の FS レジスタすべてを読み取ります (シフトするとコマンドは 0x82 になります)。 これらのレジスタから返された値を確認しましたが、返された値に一貫性の問題は見当たりません(もちろん、書き込みしてはいけないビットや保持・保留・0/1のビットを考慮して)。 最後に読んだ『FS_STATES』を見ると、まだREG_CORRUPTが設定されていることがわかります。 こんな直接的な質問をして申し訳ないのですが、何か見落としている点があるのでしょうか？ よろしくお願いいたします。 Andrew    Re: S32K396 and FS26 REG_CORRUPT こんにちは！ REG_CORRPUT ビットについては、以下のようにアサートされます。これは、FS レジスタが構成される場合、NOT レジスタを XOR ルールとともに構成する必要があることを意味します。 このビットがアサートされる原因となっている、規則に従っていないレジスタ設定がないか確認してください。 Re: S32K396 and FS26 REG_CORRUPT エリカ様、 ご回答ありがとうございます。すでに何度も確認済みですので、最初の投稿でレジスタの状態を画像として掲載しました。これらの設定方法に問題があると思われる場合は、お知らせください。 私の知る限り、レジスタは正しい(データシートで書き込み可能なビットのみを考慮して)正しいようです。チップ自体が読み取り専用ビットが有効な状態であることを管理しているものと想定し、また「0」または「予約済み」と指定されているビットは書き込み不可であると想定します。 それらのビットのいずれかに書き込みをすると、REG_CORRUPTビットがアサートされたままになる可能性はありますか? よろしくお願いいたします。 Andrew

S32DS 许可证激活 ID 您好，当我打开S32DS时，我看到了以下信息： ARM 版 S32 设计工作室 激活ID：1A99-90A8-2F06-339B 评估天数：14天 功能版本：2.2 功能状态：评估中（14天） 延长许可证有效期需要哪些手续？祝您生意兴隆！

S32DS ARM 2018 R1 License Extension Request Hello, my license has expired, so I would like to apply for an extension. Re: S32DS ARM 2018 R1 许可证延期申请 Hello, It is extended now. Best regards, Peter Re: S32DS ARM 2018 R1 许可证延期申请 Thanks

iMX937的深度睡眠模式 我正在使用 iMX95lpddr5 evk，触发了深度睡眠模式，想知道 A55、M7 和 M33 中已暂停和未暂停核心的状态、时钟频率和功耗。 Re: Deep Sleep Mode of iMX937 在 i.MX95 LPDDR5 EVK 上，“深度睡眠”对应于 i.MX 95 Suspend / DSM 风格的低功耗模式。A55 处于挂起/断电状态；M33 未运行应用程序工作负载，通常显示为时钟门控/空闲状态；M7 的状态取决于您是否也将其挂起或将其保留为唤醒/实时核心。AN14449 中的功耗数据是SoC 轨/组的总功耗，而不是每个核心的功耗。 低功耗外壳 Cortex-A55 状态/频率 Cortex-M33 状态/频率 Cortex-M7 状态/频率 DDR状态 报告功率 DSM 系统中的系统 暂停；时钟检测不到 时钟门控；时钟无法检测 暂停；未提供时钟 保留 25.65 mW GROUP_SOC_FULL 总计 Linux 挂起 + CM7 WFI 暂停 / 0 时钟门控或空闲 / 0 WFI / 400 MHz 保留 178.48 毫瓦GROUP_SOC_FULL 总计 Linux 暂停 + CM7 CoreMark (TCM) 暂停 / 0 时钟门控或空闲 / 0 CoreMark / 400 MHz 保留 197.24 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + CM7 FlexCAN 事务 暂停 / 0 时钟门控或空闲 / 0 FlexCAN / 800 MHz 活跃，6400吨/秒 659.71 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + CM7 网络/以太网 暂停 / 0 时钟门控或空闲 / 0 NETC / 800 MHz 活跃，6400吨/秒 956.17 毫瓦GROUP_SOC_FULL 总计 Linux 挂起 + WoL A55 停运 M33 空闲/低功耗上下文 具备唤醒功能的配置；检索到的数据块中没有精确的核心表。 取决于 WoL 设置 342.72 毫瓦GROUP_SOC_FULL 总计 一些解读说明： i.MX 95 参考手册将Suspend描述为最大程度节省功耗的模式，其中不必要的时钟/电源被关闭，Cortex-A55 CPU 完全断电，可以断电的 PHY 被关闭，VDD_SOC 降低到挂起电压。 在DSM 系统中，AN14449 明确指出CA55=挂起，CM33=时钟门控，CM7=挂起，DDR=保持，并指出由于 CA55 和 CM33 不工作，因此无法检测到时钟。 对于 M7 保持活动的 Linux 挂起，未挂起的核心是 CM7 ；其时钟频率在 WFI/CoreMark 保持情况下为400 MHz ，在 FlexCAN/NETC 情况下为800 MHz ，而 A55 和 M33 在案例表中显示为0 MHz 。 已公布的功率数据并非针对每个 A55/M7/M33 核心单独列出的。AN14449 报告了诸如 GROUP_SOC_FULL 和 GROUP_DRAM 之类的轨/组测量结果；例如，DSM 报告 vdd_arm 为 0 mW，vdd_soc 为 3.85 mW，GROUP_SOC_FULL 总和为 25.65 mW，但这仍然是轨级功耗，而不是单个核心功耗。 结论：如果 M7 也处于挂起状态，则 DSM 功耗约为 25.65 mW；如果 M7 在 Linux 挂起期间保持运行，则 SoC 总功耗会从 400 MHz 时的约 178–197 mW 上升到 800 MHz 时的约 660–956 mW，具体取决于外围设备的工作负载。 Re: Deep Sleep Mode of iMX937 对于 I.Mx95，有几种电源模式，包括运行模式、低功耗运行模式、空闲模式、挂起模式和电池备份安全模块模式。有关详细的功耗数据，请参阅 IMX95AEC 数据表。对于 i.Mx937，该设备目前处于预生产阶段，目前只有产品说明书可供参考。 不太清楚测试数据的来源，以及你提到的深度睡眠模式是什么……

IMX8MP オンチップRAMメモリアクセス こんにちは、 OCRAMにアクセスしてデータを読み込み、メモリに取り込む方法を学びたいです。 Linux Cortex A-53でそれを実現するにはどうすればいいか、誰かアドバイスをいただけませんか? オンチップRAM - OCRAM (576 KB) 開始アドレス: 0x00900000 => ROM用に予約済み 開始アドレス: 0x00918000  =>OCRAMフリーエリア 終了アドレス: 0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM ご回答をお待ちしています。 IMX8MPLUS i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access こんにちは、ロマン・ルースさん。 このアドバイスはあなたにとって効果がありますか？ よろしくお願いいたします。 ステファノ・ジリ Re: IMX8MP On chip RAM memory access こんに ちは、@Roman_Loz、compatible = "shared-dma-pool"を含めるといいですよ;そして、それはうまくいくはずです。 ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 ご提案いただいた方法でOCRAMを使おうとしているのですが、memcpyを実行しようとするとカーネルパニックが発生します。 私が何を間違っているのか、あるいは見落としているのか理解する手助けをしてもらえますか? dtsi: resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... モジュール初期化: // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } コピー： memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 なお、NXPは他のドライバーが使用する448KBのOCRAM空間に対するノードの変更を推奨していません。 互換性のある=「shared-dma-pool」プロパティを用いて、0x970000後にメモリ領域をDMAサポートに利用できます。 ありがとうございます。よろしくお願いいたします。 サンケット・パレク Re: IMX8MP On chip RAM memory access こんにちは、 @Sanket_Parekh さん。 ご回答ありがとうございました。大変参考になりました！ もしユーザーアプリケーションで使えない場合、448KBのOCRAM空間内でDMAをサポートするようにデバイスツリーを変更することは可能でしょうか? よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 お元気でお過ごしでしょうか。   OCRAMやLinuxカーネルで自分専用にどれだけのメモリが割り当てられているかは、socのdtsiファイル(予約済みメモリノード)を調べることで判断できます IMX8MPの場合は448KBです。   resmem: 予約メモリ { #address-cells = <2>; #size-cells = <2>; 範囲; ocram: ocram@900000 { 地図なし; reg = <0 0x900000 0 0x70000>; };   ..... .....   }   ここで0x70000(448K)バイトがLinux使用用に予約されています。そして、no-mapプロパティで指定されているユーザースペースに仮想的にマッピングすることはできません。 さらに0x7000バイトを経て、他のアプリケーションにも使えます。 ただし、OCRAMを使わないM7コアアプリケーションは必ず確認する必要があります。これは特定のアプリケーションのリンカースクリプトを調べることで判別できます。   ありがとうございます。よろしくお願いいたします。 サンケット・パレク   Re: IMX8MP On chip RAM memory access こんにちは、サンケットさん。 Linuxがどれだけのメモリを消費し、残りはユーザーアプリケーションに使えるか確認することは可能でしょうか? もし可能なら、どうやって同じことを検証し、残りのメモリをアプリケーション用に割り当てればいいのでしょうか。 よろしくお願いいたします。 サムヒタ・カシャップ Re: IMX8MP On chip RAM memory access こんにちは、 @Samhitha_Kashyap さん。 お元気でお過ごしでしょうか。 OCRAM Firstにアクセスするには、ATFが使用している地域にアクセスしようとしないように注意する必要があります。 U-Bootの場合、md/mwコマンドを使ってOCRAMに直接アクセスできます。 Linux自体がOCRAMを使用しているため、ユーザースペースでのOCRAM使用は推奨されません。 ありがとうございます。よろしくお願いいたします。 サンケット・パレク

AAOS 15を使用したimx8qmでのディスプレイ解像度設定 チームの皆さん、こんにちは。 i.MX8QM MEK 上で AAOS 15.0.0_2.1.0 を 使用して い ます 。ボードに ファームウェアを書き込んだ 後 、 物理 ディスプレイの 解像度 は 常に 1024x600 に 設定されて います が 、 ディスプレイ を 1920x1080 で 動作させ たい と考えてい ます 。 また、マルチディスプレイのセットアップで、Androidのメインデフォルトディスプレイと乗客用のディスプレイがあります。 サポートされている 表示 モード で 1920x1080 が 利用可能 で ある こと を確認しました が 、 起動 後 の アクティブ な 表示 モードは 1024x600の ままです 。Android の 優先 表示 モード を 1920x1080 に 設定 してみました が、 再起動 後 も 表示 は 1024x600 の ま まです 。 CAN you please advise: 起動 時に デフォルト の 物理 ディスプレイ 解像度 を決定する要因は 何ですか ？ 起動 後に 物理 的なディスプレイ 解像度 を 1920x1080@60Hzに強制 するには どう すればいい ですか? ro.boot.displaymode に 必要な 設定 は あり ます か ？HAL、 HWC3、 または DRM を表示して 、 1920x1080を デフォルト の アクティブ モード に します か？ 何か アドバイスを いただけれ ば幸い です 。 Re: Display resolution setup on imx8qm with AAOS 15 こんにちは、 こちらで入手可能なAndroid オートモーティブのドキュメントをご参照ください。 https://www.nxp.com/docs/en/user-guide/UG10176.pdf 特に第8.3.4章を参照してください。上記ドキュメントのプライマリディスプレイ解像度を設定します。 よろしくお願いいたします。 アルド。

iMX937のディープスリープモード iMX95lpddr5 evkを使用していますが、ディープスリープモードがトリガーされました。A55、M7、M33のサスペンドコアと非サスペンドコアの状態、クロック周波数、消費電力について知りたいです。 Re: Deep Sleep Mode of iMX937 i.MX95 LPDDR5 EVKでは、「ディープスリープ」は i.MX 95 Suspend/DSMスタイルの低消費電力ケースに割り当てられます。A55は吊り下げ/電源ゲート式です。M33はアプリケーションワークロードを実行中ではなく、通常はクロックゲート/アイドルとして表示されます。M7は、それもサスペンションするか、ウェイク/リアルタイムコアとして保持するかによります。AN14449のパワー数値はSoCレール/グループの合計であって、コアごとのパワーではありません。 低消費電力ケース Cortex-A55 状態/周波数 Cortex-M33の状態/周波数 Cortex-M7状態/周波数 DDR状態 報告された電力 DSMのシステム 一時停止; 時計が検出できません クロックゲーティング; クロックが検出されません 一時停止; 時計は提供されていません 保持 25.65 mW GROUP_SOC_FULL 合計 Linux サスペンド + CM7 WFI 一時停止 / 0 クロックゲーティングまたはアイドル / 0 WFI / 400 MHz 保持 178.48 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 CoreMark(TCM) 一時停止 / 0 クロックゲーティングまたはアイドル / 0 CoreMark / 400 MHz 保持 197.24 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 FlexCANトランザクション 一時停止 / 0 クロックゲーティングまたはアイドル / 0 FlexCAN / 800 MHz 稼働中、6400 MT/s 659.71 mW GROUP_SOC_FULL 合計 Linux Suspend + CM7 NETC / イーサネット 一時停止 / 0 クロックゲーティングまたはアイドル / 0 NETC / 800 MHz 稼働中、6400 MT/s 956.17 mW GROUP_SOC_FULL 合計 Linux サスペンド + WoL A55号線が停止 M33アイドル/低電力コンテキスト ウェイクアップ対応構成。取得したチャンクに正確なコアテーブルが含まれていません。 WoLの設定によります 342.72 mW GROUP_SOC_FULL 合計 解釈に関するいくつかの注釈： i.MX 95リファレンスマニュアルでは、不要なクロックや電源がオフで、Cortex-A55 CPUが完全に電源ゲートされ、電源を切れるPHYがオフになり、VDD_SOCがサスペンション電圧にまで下げられる最大省電力モードとしてサスペンデントモードと説明されています。 DSMのSystem AN14449では、使用例がCA55=サスペンデント、CM33=クロックゲーティング、CM7=サスペンデント、DDR=保持、そしてCA55とCM33が動作していないためクロックを検出できないことも明記されています。 M7をアクティブに保ったLinuxのサスペンドの場合、非サスペンドコアはCM7です。WFI/CoreMarkの保持ケースではクロックが400 MHz、FlexCAN/NETの場合は800 MHzで、A55およびM33はケーステーブルで0 MHzと表示されます。 公開されている電力データは、 A55/M7/M33コアごとに個別に示されているわけではありません。AN14449は、レールやグループ、GROUP_SOC_FULLやGROUP_DRAMなどの測定値を報告します。例えば、DSMはvdd_arm 0 mW、vdd_socを3.85 mWと報告し、合計25.65 mWのGROUP_SOC_FULL合計を含みますが、これはレールレベルの電力であり、個々のコア電力ではありません。 まとめ:M7も停止している場合、DSMは約25.65mWです。Linuxのサスペンド中にM7が稼働し続けると、ペリフェラルのワークロードに応じて、SoCの総消費電力は400MHzで約178〜197mWから800MHzで約660〜956mWに上昇します。 Re: Deep Sleep Mode of iMX937 I.Mx95には、RUNモード、低電力RUNモード、IDLEモード、SUSPENDモード、バッテリーバックアップ付きセキュアモジュールモードなど、いくつかの電源モードがあります。詳細な消費電力データについては、IMX95AECのデータシートを参照してください。i.Mx937については、現在試作段階であり、現時点では製品仕様書のみが入手可能です。 テストデータの出所や、あなたが言及しているディープスリープモードが何なのかよく分かりません…。

CodeWarrior 的 LA1224 插件 你好， 我目前正在评估 LA1224-RDB，对于软件环境有一些疑问。据我了解，为了评估目的，我可以在 LX2160A 上现有的 NxP 镜像上运行 Linux 应用程序。此外，我推测 LA1224 是在裸机上运行 FreeRTOS。我发现 LX2160A 的 Linux 目录中可以找到 LA1224 的固件。这是NxP提供的吗？它支持哪些功能？我想，如果我想在给定的固件基础上进行进一步开发，我必须获得 CodeWarrior 许可证和 TAP。 我已经下载了 CW_ARMv8_v2020.06_b200629GA_Win_Setup.exe，但是 LP1224 不可用。在 NxP 网站上搜索后，我发现除了 CW_ARMv8 之外，还需要一个额外的工具链。插件的完整下载网址是什么？我阅读了CodeWarrior 上关于 LA1224 的文档，但只给出了部分 URL：“ com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip”。 欢迎提供关于如何使用这些处理器的更多信息。 亲切的问候 N. Alexopoulos Re: CodeWarrior for LA1224 plugin 请从以下链接下载软件包 com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip。 https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US 请准备一个干净的安装环境。请先安装 CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe。然后，在新工作区路径中打开 CodeWarrior IDE。然后从 CodeWarrior IDE 的“帮助->安装新软件->添加->归档”安装服务包 com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip。

S32DS ARM 2018 R1 ライセンス延長申請 こんにちは。私の運転免許証の有効期限が切れてしまったので、延長を申請したいのですが。 Re: S32DS ARM 2018 R1 许可证延期申请 こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター Re: S32DS ARM 2018 R1 许可证延期申请 ありがとう

S32K396 和 FS26 REG_CORRUPT 尊敬的各位， 我正在尝试消除 FS26 上的 REG_CORRUPT 标志 - 附件中的两张截图显示了对所有相关寄存器的读取。 在第一个“AE”读取命令之前，我已经成功地启动了看门狗，使 FS 状态机脱离 INIT_FS，以便评估故障保护寄存器状态的正确性，从 0x28 的响应可以看出，我们处于调试模式，并且 REG_CORRUPT 位已设置。 我确信看门狗启动成功了，因为我在启动后立即读取了 FS_DIAG_SAFETY1 - 返回值为 0x0103 - 没有错误标志，只有 ABIST1_OK 和 LBIST_STATUS = OK。 在执行 0xAE 命令后，我发出 0xAF 命令，尝试向寄存器写入 0x1800 以清除 OTP_CORRUPT 和 REG_CORRUPT 位，然后从寄存器 0x41 开始按顺序读取所有 12 个 FS 寄存器（显然，移位后的命令为 0x82）。 我已经查看了这些寄存器返回的值，并且没有发现返回值存在一致性问题（显然，考虑到我们不应该写入的位以及被保留/清零/0/1 的位）。 从最后读取 FS_STATES 可以看出，REG_CORRUPT 仍然处于设置状态。 很抱歉问这么直接的问题，但我到底漏掉了什么？ 此致， Andrew    Re: S32K396 and FS26 REG_CORRUPT 亲爱的艾丽卡， 感谢您的回复——我已经检查过很多次了，所以我才在最初的帖子图片中发布了完整的寄存器状态。如果您认为这些配置存在问题，请告诉我。 据我所知，寄存器是正确的（仅考虑数据手册中可写入的位）。我假设芯片本身会确保只读位处于有效状态，并且我假设指定为“0”或“保留”的位是不可写的。 写入这些位中的某一位是否有可能导致 REG_CORRUPT 位保持钳位？ 此致， Andrew Re: S32K396 and FS26 REG_CORRUPT 您好！ 对于 REG_CORRPUT 位，它将被置位，如下所示，这意味着当配置 FS 寄存器时，必须配置一个 NOT 寄存器以及异或规则。 请检查是否存在某些寄存器配置不符合规则，导致此位置位？

imx8qm 显示器分辨率设置（AAOS 15） 大家好， 我们 在 i.MX8QM MEK 上 使用 AAOS 15.0.0_2.1.0 。刷 写 板 后 ， 物理 显示屏 的 分辨率 始终 设置 为 1024x600 ， 而 我们 希望 显示屏 以 1920x1080 的 分辨率 运行 。 我们采用多显示屏设置，包括安卓主默认显示屏和乘客显示屏。 我们 已 验证 1920x1080 在 支持 的 显示 模式 下 可用 ， 但 启动 后的 活动 显示 模式 仍然 是 1024x600 。我们 也 尝试 在 Android 系统 中将 首选 显示 模式 设置 为 1920x1080 ， 但 重启 后 显示 仍然 以 1024x600 分辨率 显示 。 请问 您 能否 提供以下建议： What determines the default physical display resolution during 启动? 如何 强制 物理 显示 分辨率 在 1920x1080@60Hz 启动 后 ？ ro.boot.displaymode 需要 进行 任何 配置 吗 ？显示 HAL、 HWC3 或 DRM ，以 将 1920x1080 设置 为 默认 运行模式 ？ 任何指导都将不胜感激。 Re: Display resolution setup on imx8qm with AAOS 15 你好， 请参阅我们提供的 Android Automotive 文档： https://www.nxp.com/docs/en/user-guide/UG10176.pdf 请特别参阅第 8.3.4 节。配置上述文档的主显示分辨率。 此致敬礼/Saludos， 阿尔多。

CodeWarrior for LA1224プラグイン こんにちは、 現在、LA1224-RDBの評価の途中で、ソフトウェア環境についていくつか質問があります。私の理解では、評価目的で既存のNxPイメージ上でLinuxアプリを動かすことはLX2160A可能です。さらに、LA1224はFreeRTOSを搭載したベアメタル環境で動作していると思われます。LX2160AのLinuxディレクトリにLA1224のファームウェアを保存できるのを見ました。これはNxPから提供されたものですか?何をサポートしていますか？提供されているファームウェア以上のものを開発したい場合は、コードウォーリアーライセンスとTAPを取得する必要があると思います。 CW_ARMv8_v2020.06_b200629GA_Win_Setup.exeをダウンロードしましたが、LP1224が利用できません。NxPのサイトを検索したところ、CW_ARMv8の上にさらに別のツールチェーンが必要であることがわかりました。アドオンをダウンロードするための完全なURLは何ですか？LA1224用のCodeWarriorを読んだところ、部分的なURLしか与えられていません。com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip" これらのプロセッサーの扱い方について、さらなる情報があればぜひ教えてください。 敬具 N. アレクソプロス Re: CodeWarrior for LA1224 plugin 以下のリンクから、com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip パックをダウンロードしてください。 https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US クリーンなインストール環境をご用意ください。まず、CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe をインストールしてください。その後、新しいWorkapceパスでCodeWarrior IDEを開きます。次に、CodeWarrior IDEのHelp->Install New ソフトウェア->Add->Archiveからサービスパックcom.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zipをインストールします。

IMX8MP 片上 RAM 存储器访问 你好， 我想学习如何访问 OCRAM 来读取内存中的数据。 请问有人知道如何在Linux Cortex A-53上实现这个功能吗？ 片上内存 - OCRAM（576 KB） 起始地址：0x00900000 -> 保留给 ROM 起始地址：0x00918000 -> OCRAM 空闲区 结束地址：0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM 谢谢！ IMX8MPLUS i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access 你好，Roman Luz， 这个方法对你有用吗？ 问候， 斯特凡诺·吉利 Re: IMX8MP On chip RAM memory access 嗨@Roman_Loz ，你可以尝试添加 compatible = "shared-dma-pool"; 应该就可以了。 ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; 此致， 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好， 我尝试按照您建议的方式使用 OCRAM，但是当我尝试向其中进行 memcpy 操作时，出现了内核崩溃。 请问您能否帮我分析一下我哪里做错了或者漏掉了什么？ dtsi： resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... 模块初始化： // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } 复制： memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap ， 请注意，NXP不建议对节点进行448 KB OCRAM空间的修改，因为其他驱动已使用该空间。 可以通过兼容的 =“共享 dma-pool” 属性，在0x970000后使用内存区域支持 DMA。 谢谢 & 此致敬礼 桑凯特·帕雷克 Re: IMX8MP On chip RAM memory access 你好@Sanket_Parekh ， 谢谢你的回复，很有帮助！ 如果我不能将 448 KB OCRAM 空间用于用户应用程序，我是否可以修改设备树以支持 DMA？ 谢谢，此致敬礼！ 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap ， 希望你一切都好。   您可以通过查看SoC的dtsi文件（保留内存节点）来确定OCRAM中Linux内核为自身保留了多少内存。 以 imx8mp 为例，大小为 448 KB。   resmem：保留内存 { #address-cells = <2>; #size-cells = <2>; 范围； ocram: ocram@900000 { 无地图； reg = <0 0x900000 0 0x70000>; };   ..... .....   }   因此，这里保留了 0x70000 ( 448K) 字节供 Linux 使用。并且不能按照 no-map 属性指定的方式虚拟映射到用户空间。 在 0x7000 字节之后，您可以将其用于其他应用程序。 但您需要确保任何 M7 核心应用程序不使用 OCRAM。这可以通过查看特定应用程序的链接器脚本来确定。   谢谢 & 此致敬礼 桑凯特·帕雷克   Re: IMX8MP On chip RAM memory access 你好，Sanket， 能否查明 Linux 系统占用了多少内存，以及剩余的内存可供用户应用程序使用？ 如果可行，我该如何验证这一点，并为我的应用程序分配剩余内存？ 谢谢，此致敬礼！ 萨姆希塔·卡什亚普 Re: IMX8MP On chip RAM memory access 你好@Samhitha_Kashyap 希望你一切都好。 要访问 OCRAM，首先需要确保您不会尝试访问 ATF 使用的区域。 对于 u-boot，可以使用 md/mw 命令直接访问 OCRAM。 不建议在用户空间中使用 OCRAM，因为 Linux 本身就使用了它。 谢谢 & 此致敬礼 桑凯特·帕雷克

DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs Hi all, I'm evaluating NXP S32K3 family MCUs for a program that requires DFARS-compliant sourcing, and I'm hoping someone here can help point me in the right direction or has dealt with this before. Specifically, I'm trying to confirm: Country of manufacture/assembly (wafer fab and package/test locations) for specific S32K3 part numbers — compliance is generally tied to whether the part is manufactured in a DFARS "qualifying country" per DFARS 252.225-7002 (Qualifying Country Sources as Subcontractors), so I need this at the part-number/package level rather than a general "NXP is compliant" statement. Whether NXP can issue a Certificate of Origin (COO) or formal DFARS compliance statement for specific parts. Whether there's a TAA compliance letter available as well, since that may also apply to our program. Parts of interest (open to alternatives that fit the same tier): S32K344 S32K358 S32K314 We're targeting MCUs with ≥512 kB flash, ≥128 kB RAM, so I'm mainly looking at the higher-memory S32K3 variants, but happy to hear if other S32K3 family members (or the broader S32K1/S32K2 lines) are better documented for compliance purposes. Questions for the community: Has anyone successfully obtained COO/DFARS documentation directly from NXP for S32K3 parts? If so, who did you work with (FAE, distributor, quality team)? Is this something NXP publishes at all, or is it always a case-by-case request per part/date code? Are there specific S32K3 part numbers or packages known to be sourced from DFARS-qualifying countries vs. others that aren't? Given S32K3 is heavily positioned for automotive/industrial safety applications, has anyone had experience getting compliance docs for defense-adjacent programs specifically? I understand this may not be something community engineers have direct access to, so if there's a better channel (regional FAE, distributor compliance desk, etc.) I should be routing this to instead, please point me there. Appreciate any guidance! Thanks! Re: DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs Hi @dbow12, We do not have this information publicly available. For COO inquiries, you may contact [email protected]. For any export control inquiries, contact [email protected]. However, I would recommend contacting your local distributor first, they should be able to assist you in this regard. Regards, Daniel 

RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, I'm experiencing an issue with RTD 5 when configuring the LCU module. Specifically, when I select Instance -> 1 in LCU, it throws an error (please refer to the image below). There are no other changes made, and this configuration works fine in RTD 4. Additionally, after pressing "OK," it does not allow adding more than one LCU Output Physical — the "+" button in the peripherals section becomes unresponsive. I’ve verified this behavior in both S32 Design Studio v3.5 and v3.6, and the issue persists in both versions. Could you please look into this? Thank you. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Info: I am using S32DS 3.6.10 with RTD 7.0.1 Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Yeah, this is the same workaround I was using as well. I keep LCU_IP_HW_INST_0 in the configuration while setting everything up, even though it is not used, and then remove Instance 0 at the end. NXP did suggest updating/reinstalling the RTD, but that did not resolve this particular issue. The post was eventually closed, so I’m not sure if this was fixed in a later S32DS/RTD version. I saw the issue in both S32DS 3.5 and 3.6. Thanks for adding this to the community @Micha4566465 . It’s useful to have the workaround here so others can refer to it if they run into the same issue. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hi,  I have this issue, too. The issue only appears, when using LCU Hardware Instance LCU_IP_HW_INST_1 as only instance in "LCU Logic Instance"-Item. If you keep the LCU_IP_HW_INST_0 beside the LCU_IP_HW_INST_1, although it will not be used, there is no problem. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 this updated version works Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, here is what i see when configure Instance 1: I do not see any issue. Best regards, Peter Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Thanks for the responses! I tried the suggestions you provided — things are working better now. I'm able to add the LCU instance, which is good progress. However, I  the issue only occurs when selecting hardware instance 1(as mentioned before). In the image you shared, it shows instance 0, which doesn't seem to have the same problem. Occasionally, an error still pops up when working with instance 1, but it's not a blocker since I can exit it without any functional impact. Could you please confirm if this is a known issue in RTD v5, or if it might be related to something else? Also, if there's a fix or recommended workaround, that would be helpful. Re: RTD 5 LCU Instance Selection Issue in S32DS 3.5 & 3.6 Hello, I have just tried it in S32DS 3.5. with RTD 5.0.0. and I do not see such issue: The error seem to be tied to your installation. Since the issue is also present in S32DS 3.6 I suggest to reinstall the RTD pluggin and intall the latest update of RTD 5..0.0.HF1 But the fact is that I am using much older release and do not see the issues. It can also be linked to S32DS GUI. Maybe it is somehow corrupted or has restricted access to the configuration in LPC. Best regards, Peter

MPXM2053GS air leakage We have assembled MPXM2053GS pressure sensors onto our PCB. During initial testing, a number of units were found to have an output voltage of 0V, which we guess is due to air leakage. After removing the defective devices from the board, we inspected the bottom vent holes and found that they differ visibly from those of the good units. Specifically, the interior of the vent holes on the failed parts appears to contain melted or heat-damaged material. What is the possible root cause of this defect? Re: MPXM2053GS air leakage Hi David, The most effective prevention is to define a solder paste exclusion zone on your PCB stencil directly beneath the vent hole location. This ensures no paste is deposited in that area and cannot be drawn into the hole during reflow. Additionally, using a no-clean flux minimizes residue that could otherwise migrate into the opening. For further support, I would recommend contacting STMicroelectronics directly, as they are the current owner of the MPXM2053 and are best positioned to provide support. BRs, Tomas Re: MPXM2053GS air leakage Do you have any suggestion how to prevent solder paste or flux intrusion from entering the bottom vent? Re: MPXM2053GS air leakage Hi David, The melted/heat-damaged material inside the vent holes is most likely caused by solder paste or flux intrusion during reflow soldering or by exceeding the maximum permitted peak package body temperature of 250°C (max. 30 seconds). Since the MPXM2053GS is a vented gauge sensor that uses the bottom vent as its atmospheric reference, any blockage of that hole will cause a loss of reference and result in 0V output. One additional note for your awareness: as of February 2, 2026, NXP MEMS sensor products — including the MPXM2053 series — have been transitioned to STM. For formal failure analysis or ongoing product support, STM is the appropriate contact. BRs, Tomas

寻求培训资料 你好，我想学习关于EIS的课程，但是如何借助恩智浦eisBMS芯片更安全、更快速地为电池充电——软件支持/系统集成/激励这几部分目前都无法观看，也没有课程资料。 请问该如何学习这几部分呢

SC18IS606 - reading back issue Hello, We have I2C to SPI converter SC18IS606 manufactured by NXP. We are using Raspberry Pi to write and read data to SC18IS606 through I2C. The device SC18IS606 is shown listed in the Raspberry Pi OS terminal and is detected through “i2cdetect -y 1” command in the terminal with correct address. As a simple test, we tried write operation (set/clear) to the GPIO 0 to 2 and make them toggle in the loop with some delay in between. This part is working.  But when we read back from the SC18IS606, it reads 0x80 instead 0x00. Latter we tied the pins MISO and MOSI together making SPI loop back using a jumper wire. We are sending patterns 0x00 through 0x07 to SPI. The read back data we got is 0x80 through 0x87. The MSB is always 1 when we read back SPI in the loop back test. We have tested two SC18IS606 chips which we bought from Mouser and we got the same result.   Any idea what could be the issue ? How to fix ?  Re: SC18IS606 - reading back issue Hello johnpeter Good day! 1.- Please check the ORDER bit The SC18IS606 SPI configuration register contains an ORDER bit: ORDER = 0 → MSB first (default) ORDER = 1 → LSB first If the SC18IS606 is configured for LSB-first, but your software interprets the received byte as MSB-first, patterns can appear shifted and may look like the MSB is always set. Could you verify what value you are writing with the F0h Configure SPI Interface command? 2.- are you reading the buffer correctly? The SC18IS606 does not immediately return GPIO or SPI data after the command. The sequence is: Send GPIO Read (F5h) or SPI transaction. Wait for completion (poll device or use INT). Perform an I²C read of the buffer. For SPI operations, the received MISO data is stored in the internal buffer and must then be read back through an I²C read transaction. A protocol error when reading the buffer (for example treating the address byte as data, or reading one bit offset) could produce the exact "+0x80" I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.