Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB Can we replace MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB The replacement is practical if the design does not use the QuadMax-only compute/DSP resources and the QP-specific software and hardware checks pass.

ubuntu では、mcuxpresso-secure-provisioning パッケージを使用して、固 定ファイルに名前を付けて、コアシートに書き込みます。 まず、私が使用したチップはMCXN947です。 mcuxpresso-secure-provisioning-26.09-1_amd64-ubuntu26.debパッケージをUbuntuシステムにダウンロードしてインストールしました。 では、このソフトウェアを使って署名され暗号化されたSBフォーマットファイルをどうやって生成すればいいのでしょうか? 私はビデオを見て、bin ファイルに署名と暗号化を行い、Windows システムで sb ファイルをチップに正常に書き込みました。 Ubuntuシステムを操作する方法に関するビデオはありますか？バイナリファイルに署名および暗号化するためのコマンドラインに関するドキュメントはありますか？ よろしくお願いします。 Re: 在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 こんにちは、 @justdomyself ドキュメント:https://docs.mcuxpresso.nxp.com/secure/latest/ MCXNデバイスのワークフローを説明する章： https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#n23x-n24x-n52x-n53x-n54x-n94x-device-workflow コマンドラインサポート:https://docs.mcuxpresso.nxp.com/secure/latest/08_command_line_operations.html 関連項目 securep.exe print - cli - examples UbuntuとWindowsのユーザー体験は非常に似ています。問題が発生した場合は、トラブルシューティングのセクションを参照してください。https: //docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html

FreeRTOSシステムは実行できません（作成直後は実行できません）。 仕様書に従ってプロジェクトプログラムを作成した後、FreeRTOSシステム上で実行できないことがわかりました（調査の結果、メモリ不足の問題ではなく、優先度の高い問題でもないことがわかりました）。S32DSコンパイラのバージョンは、以下の画像に示されています。 タスクの作成に失敗しました。このバージョンはFreeRTOSをサポートしていないのでしょうか？それとも、特別な設定要件があるのでしょうか？ Re: freertos 系统跑不通问题（创建即跑不通） こんにちは、@sunshine88 さん。 申請が sys_msleep(5000) コール自体のせいで止まっているわけではありません。この動作は、 sys_now() で使用されている時間ベースが増加していないことを示しています。したがって、 sys_msleep() 内のタイムアウト条件には決して到達できません。 OSIF構成のスクリーンショットでは、 OsIfUseSystemTimer が有効になっており、オペレーティングシステムの種類はFreeRTOSに設定されています。しかし、 OsIfCounterConfig_0 の下の参照、カウンタとシステムタイマークロックの参照を含め、不完全または空であるようです。PITコンポーネントを追加するだけでは、OSIFタイムベースが正しく構成および初期化されることを保証するものではありません。 現時点では、TCP/IPスタックのソースコードを変更したり、別の遅延回避策を実装したりしないでください。代わりに、私は以下のことをお勧めします。 インストールされたTCP/IPスタックパッケージから元の lwip_FreeRTOS_s32K358 例をインポートしてください。 元のサンプルを一切変更せずにビルドして実行してください。 元の例で sys_now() が増加するかどうかを確認してください。 FreeRTOS、BaseNXP/OSIF、PIT、クロック、割り込み、およびTCP/IPスタックの設定を、カスタムプロジェクトと比較してください。 生成された初期化シーケンスに、必要なBaseNXP/OSIFおよびタイマーの初期化が含まれていることを確認してください。 カスタムプロジェクトを正しく分析するためには、以前にご依頼した情報が引き続き必要です。 正確なMCU部品番号; 正確な評価ボードまたはカスタムボード; 出発点として使用された元の事例またはプロジェクトの種類。 変更されていない lwip_FreeRTOS_s32K358 の例が同じハードウェアで動作するかどうか。 sys_now() の生成された実装。 xTaskGetTickCount() によって返される FreeRTOS ティック カウントが増加しているかどうか。 まず xTaskGetTickCount() を確認してください。 sys_now() が一定のままでが増加する場合、FreeRTOSスケジューラとティック割り込みが実行されており、問題は具体的にはOSIFタイムベースの設定または初期化にあります。 xTaskGetTickCount() も一定のままであれば、問題はより根本的なものであり、FreeRTOSのティック割り込みまたはスケジューラ構成を調査する必要があります。 可能であれば、構成スクリーンショットだけでなく、プロジェクト全体のアーカイブも提供してください。生成された構成コードと初期化コードがないと、 sys_now() が実際にどのタイマーまたはクロックソースを使用しているかを判断することはできません。 よろしくお願いいたします。 パベル Re: freertos 系统跑不通问题（创建即跑不通） こんにちは。LWIPプログラムルーチンを作成しましたが、Ethernet mainLoopTaskタスクがsys_msleep(5000);で停止してしまい、遅延させることができません。この関数をステップ実行すると、startTime = sys_now(); と表示されますが、sys_now()関数はカウントできません。現在の設定ページは以下のとおりです。何が原因でしょうか？非常に困惑しています。 Re: freertos 系统跑不通问题（创建即跑不通） こんにちは、@sunshine88 さん。 スクリーンショットに表示されているバージョンはFreeRTOSをサポートしているはずです。S32 Design Studio 3.5 アップデート14、RTD 4.0.0、FreeRTOS 4.0.0、およびTCP/IPスタック1.0.4これは予想されるパッケージの組み合わせのようで、一般的なバージョン互換性の問題とは思えません。 示されているコードによると、エラーはxTaskCreate()関数内で直接発生しています。以下の情報を教えていただけますか? 正確なMCU部品番号と評価ボード、またはカスタムボードが使われているのです。以前S32K358とおっしゃっていましたが、正確なデバイス名と基板名をお知らせください。 出発点として使用された元の例の名前。 xTaskCreate() によって返される値。 xTaskCreate() 呼び出しの前後で xPortGetFreeHeapSize() によって出力される値。 configTOTAL_HEAP_SIZE、configSUPPORT_DYNAMIC_ALLOCATION の設定値、および選択された FreeRTOS ヒープ実装 (例: heap_4.c)。 アプリケーションが停止する正確なポイント、特にアサーション、例外、ハードフォールハンドラに入るデバッガ呼び出しスタックも含まれます。 十分なMCU RAMがあっても、必ずしも十分なFreeRTOSヒープが利用できるとは限りません。xTaskCreate() は、FreeRTOS ヒープからタスク制御ブロックとタスクスタックの両方を動的に割り当てます。また、1024Uのスタック深度引数は通常、バイトではなくスタック要素を表すため、Cortex-M7の実際の割り当ては1024バイトより大きいです。 ベースラインテストとして、オリジナルのlwIP FreeRTOSサンプルを修正せずにインポートして実行することをお勧めします。元のサンプルが正常に動作したら、小さなスタックサイズ、通常の優先度、そしてループ内にvTaskDelay()呼び出しを含む追加タスクを追加してください。これにより、環境やボード構成の問題と、追加タスクによって引き起こされた問題を区別するのに役立ちます。 また、あなたの xTaskCreate() 呼び出しではスタック深度が 1024U であるのに対し、元の動作例では 256U を使用していることに気づきました。まず、元の値である256Uに戻し、変更を加えていないサンプルをテストしてください。このパラメータはバイト数ではなくスタック要素数を指定するため、1024Uを使うには大幅に多くのFreeRTOSヒープが必要です。   よろしくお願いします、 パベル

ベンダーのツールに関する経験 皆さん、こんにちは。ベンダーのハードウェアを扱う際に、ベンダーのツールを使った経験についてお聞かせください。例えば、NXPのLayerscapeシリーズやSTM32MP1シリーズのような製品について話してみましょう。私はNXPのLayerscape SoCの一つをベースにしたボードを作っていましたが、唯一提供されているツールが例えば、DDRはEclipseをベースにした**ピー音**IDEです。このツールの品質を考えれば、無料で提供しても文句は言わないでしょうが、ライセンス料はかなり高いです。IDEを使ってこれやあれをやりたいですか?頑張ってください。「私にできる精一杯」は、ほとんど100%正確ではなく、古い部分的なドキュメント、必ず答えが得られるフォーラム、誰かが対応してくれる、そして画面の内容がほとんど見えない240p動画です。DDRの立ち上げと検証にのみ使用し、残りの作業はこのツールなしで済ませたいと思っています。他のベンダーとの取引経験はいかがですか？TIはどうでしょうか？STのツールもいくつか見たことがありますが、確かにずっとシンプルに見えました。ただ、実際に使った経験はありません。 Re: Experience with vendor's tools こんにちは、 Eclipse ベースは老朽化しており、DDR ツール (DDR ストレス テスト ツール) は機能的ですが扱いにくく、ライセンス コストとの比較。品質比率は組み込みコミュニティでよく見られる不満です。ドキュメントのギャップは現実的で、AN(アプリケーションノート)は公式のツールドキュメントよりも優れたリソースであることが多いです。多くのエンジニアは、計画通りDDR PHYの開始やトレーニングに専念して使い、その後は次に進みます。   NXP Layerscape DDRの立ち上げに関する実践的なヒント 今のところはこれしか選択肢がないので： DDRストレステストツールのスタンドアロンバイナリ（CodeWarriorとは別）が利用可能な場合があり、そちらの方が軽量です。 NXPの i.MX/Layerscape コミュニティ(GitHub)には、ツール誘導作業を省略できるリファレンスDDR設定があります。 LSDK(Layerscape SDK) スクリプトは、DDR initパラメータをIDEよりも透明に公開することがあります。 よろしくお願いします。

Ibis model for Lx2160a Hi guys  I'd like to know  how can i get a ibis model for lx2160a, can anybody can help me with it ? Thanks a lot Yuan Re: Ibis model for Lx2160a IBIS models are not public, please create case here:  https://support.nxp.com/s/?language=en_US  And share your NDA. Thanks

在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 First, the chip I used is  MCXN947. I  have  downloaded and installed mcuxpresso-secure-provisioning-26.09-1_amd64-ubuntu26.deb  package in my ubuntu system。 So how to use this software  to  generare a sb formate file which has been signed and encrypted ? I  have watch the video  and  signed and encrypted  the  bin file ,   and write the sb  file  to the  chip sucsessfuly in windows system. Is there have  video to  operate on  ubuntu system?  Is there have the document about the  cmd line  to  signe and encryt  bin file   ? Thanks Re: 在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 Hi @justdomyself  Documentation: https://docs.mcuxpresso.nxp.com/secure/latest/ Chapter describing workflow for MCXN devices: https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#n23x-n24x-n52x-n53x-n54x-n94x-device-workflow Command line support: https://docs.mcuxpresso.nxp.com/secure/latest/08_command_line_operations.html See also  securep.exe print-cli-examples User experience on Ubuntu and Windows are very similar. If you find any problem, refer to Troubleshooting section: https://docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html

MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Ladies and Gentlemen, I am experiencing a reproducible problem with MCUXpresso IDE v25.6 Build 136 on Linux and an LPC-Link2 debug probe. When the LPC-Link2 is connected, it initially appears in DFU mode: 1fc9:000c NXP Semiconductors LPC4330FET180 (device firmware upgrade mode) Linux detects the DFU device correctly. For example: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ver=0100, devnum=19, cfg=1, intf=0, path="1-6", alt=0, name="DFU", serial="ABCD" The important observation is that the LPC-Link2 boot process itself works correctly. Running the LinkServer boot command manually from a terminal successfully boots the probe. It then re-enumerates as: 1fc9:0090 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.460 I can also boot the probe successfully using LinkFlash. However, if I start a debug session with the green Debug button while the LPC-Link2 is still in DFU mode, MCUXpresso IDE fails to boot the probe and reports: No bootable LPC-Link2 found The IDE's pre-launch command is: /usr/local/LinkServer_26.9.130/binaries/boot_link2 The IDE reports: Non-zero return code (1) from pre-launch command: .../boot_link2 and the corresponding dfu_boot invocation reports that no bootable LPC-Link2 was found. I have verified that the same DFU device is still visible from a normal terminal while MCUXpresso IDE is running: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ... If I boot the LPC-Link2 externally first (for example with LinkFlash), the blue Debug button works correctly and I can debug the target normally. I have tested both the original LinkServer version supplied with MCUXpresso IDE 25.6 and LinkServer 26.9.130. The behaviour is the same. I also restored the IDE's original/default LinkServer configuration, with no improvement. Therefore the problem does not appear to be: LPC-Link2 hardware USB enumeration Linux DFU support the LinkServer boot image the LinkServer boot mechanism itself The failure appears to be specifically in the automatic LPC-Link2 boot performed by MCUXpresso IDE as part of the green Debug launch sequence on Linux. As a workaround, I can start LinkFlash, let it boot the LPC-Link2, close LinkFlash, and then use the blue Debug button. This works, but it is obviously not the intended workflow. Has anyone seen this behaviour with MCUXpresso IDE 25.6 Build 136 on Linux? Is there a known fix or patch for the IDE's automatic LPC-Link2 boot procedure? I would particularly like to know whether this is a known IDE issue, since the LPC-Link2 and the LinkServer boot process itself are demonstrably working. Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Thank you. I checked this. My system has: dfu-util 0.11 The MCUXpresso IDE 25.6.136 installation itself does not contain a dfu-util binary, so it appears to use the system version: /usr/bin/dfu-util This is indeed version 0.11. I also checked the forum post you linked. The situation described there looks potentially relevant, since it specifically concerns dfu-util 0.11 and the parsing of the VID:PID returned by dfu-util -l. However, there is one important difference in my case: the same boot_link2 / dfu_boot command works correctly when I run it manually from a terminal. The problem occurs when MCUXpresso IDE invokes boot_link2 as the pre-launch command of the green Debug launch. Could the dfu_boot script included with LinkServer/MCUXpresso IDE 25.6.136 still contain the dfu-util 0.11 parsing problem described in the linked post? That topic is from 2024, is it possible, that this issue still present in 2026? bela@bela-ThinkPad-P70:~ $ find /usr/local/mcuxpressoide-25.6.136 -type f -name 'dfu-util*' -ls bela@bela-ThinkPad-P70:~ $ which dfu-util dfu-util --version /usr/bin/dfu-util dfu-util 0.11 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2021 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ bela@bela-ThinkPad-P70:~ $ Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux Hi @jeanvaljean  Thank you for your post! Could you please review the dfu-util version your IDE is using?  Please review the post: Report dfu boot problem to LPC Link2 with lpscrypt under Linux

用 MIMX8QP6AVUFFAB 替换 MIMX8QM6AVUFFAB 我们能否用 MIMX8QP6AVUFFAB 替换 MIMX8QM6AVUFFAB？ Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB 如果设计不使用 QuadMax 专用的计算/DSP 资源，并且 QP 特定的软件和硬件检查通过，则这种替换是可行的。

MIMX8QM6AVUFFABをMIMX8QP6AVUFFABに交換する MIMX8QM6AVUFFABをMIMX8QP6AVUFFABに置き換えられるか? Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB 代替は、設計がQuadMax専用の計算/DSPリソースを使わず、QP特有のソフトウェアおよびハードウェアチェックに合格した場合に実用的です。

MCUXpresso IDE 25.6 ビルド136 – Linux上でLPC-Link2が自動的に起動されません ご列席の皆様、 Linux上の MCUXpresso IDE v25.6 Build 136 とLPC-Link2デバッグプローブで再現可能な問題が発生しています。 LPC-Link2が接続されると、最初はDFUモードで表示されます: 1fc9:000c NXP Semiconductors LPC4330FET180 (device firmware upgrade mode) LinuxはDFUデバイスを正しく検出します。例えば： $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ver=0100, devnum=19, cfg=1, intf=0, path="1-6", alt=0, name="DFU", serial="ABCD" 重要な点は、 LPC-Link2のブートプロセス自体は正しく動作しているということである。 端末からLinkServerの起動コマンドを手動で実行すると、プローブが正常に起動します。すると、次のように再列挙されます。 1fc9:0090 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.460 また、LinkFlashを使ってプローブを正常に起動することもできます。 しかし、LPC-Link2がまだDFUモードのまま緑色の Debugボタン でデバッグセッションを開始すると、MCUXpresso IDEはプローブの起動に失敗し、次のように報告します: No bootable LPC-Link2 found IDEsの事前発射指令は以下の通りです: /usr/local/LinkServer_26.9.130/binaries/boot_link2 IDEの報告は以下の通りです: Non-zero return code (1) from pre-launch command: .../boot_link2 そして、対応するdfu_bootコマンドの実行結果から、起動可能なLPC-Link2が見つからなかったことが報告されます。 MCUXpresso IDEが稼働している間も、通常の端末から同じDFUデバイスがまだ見えることを確認しました: $ /usr/bin/dfu-util -l Found DFU: [1fc9:000c] ... 例えば、LPC-Link2を外部から起動した場合(例えばLinkFlashで)、 青いDebugボタンが正しく動作 し、ターゲットを通常通りデバッグできます。 MCUXpresso IDE 25.6に付属していたオリジナルのLinkServerバージョンとLinkServer 26.9.130の両方をテストしました。動作は同じです。 また、IDEsの元/デフォルトのLinkServer設定も復元しましたが、改善はありませんでした。 したがって、問題は次のようではないようです。 LPC-Link2ハードウェア USB列挙 Linux DFUサポート LinkServerのブートイメージ LinkServerのブートメカニズム自体 この失敗は、 Linuxの緑色のデバッグ起動シーケンスの一部としてMCUXpresso IDEによって自動的に行われるLPC-Link2ブートに特化したようです。 回避策として、LinkFlashを起動してLPC-Link2を起動させ、LinkFlashを閉じてから青いDebugボタンを使うことができます。これは機能するが、明らかに本来のワークフローではない。 Linux 上のMCUXpresso IDE 25.6 Build 136でこの挙動を見た方はいらっしゃいますか?IDEのLPC-Link2自動起動手順に関する既知の修正やパッチはありますか? 特に、LPC-Link2とLinkServerの起動プロセス自体が明らかに動作しているので、これが既知のIDE問題かどうか知りたいです。 Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux ありがとう。確認しました。 私のシステムには以下があります： dfu-util 0.11 MCUXpresso IDE 25.6.136インストール自体にはDFU-utilバイナリは含まれていないため、システムバージョンを使用しているようです: /usr/bin/dfu-util これは確かにバージョン0.11です。 あなたがリンクしてくれたフォーラムの投稿も確認しました。そこで説明されている状況は、dfu-util 0.11 と dfu-util -l によって返される VID:PID の解析に特に関係しているため、潜在的に関連性があるように思われます。 しかし、私の場合に重要な違いがあります。同じboot_link2/dfu_bootコマンドをターミナルから手動で実行すると正しく動作します。この問題は、MCUXpresso IDEが緑色のデバッグローンチの事前実行コマンドとしてboot_link2を呼び出したときに発生します。 LinkServer/MCUXpresso IDE 25.6.136に含まれているdfu_bootスクリプトは可能でしょうか?リンク先の投稿で説明されているdfu-util 0.11の解析問題はまだ残っていますか？ その話題は2024年のものですが、この問題が2026年になってもまだ存在している可能性はありますか? bela@bela-ThinkPad-P70:~ $ find /usr/local/mcuxpressoide-25.6.136-type f -name 'dfu-util*' -ls bela@bela-ThinkPad-P70:~ $ which dfu-util dfu-util --version /usr/bin/dfu-util dfu-util 0.11 著作権 2005-2009 Weston Schmidt、Harald Welte、および OpenMoko Inc. 著作権 2010-2021 トルモッド・ヴォルデンおよびシュテファン・シュミット このプログラムはフリーソフトウェアであり、保証は一切ありません バグがあれば http://sourceforge.net/p/dfu-util/tickets/ に報告してください bela@bela-ThinkPad-P70:~ $ Re: MCUXpresso IDE 25.6 Build 136 – LPC-Link2 is not automatically booted on Linux こんにちは、 @jeanvaljean 投稿ありがとうございます! IDEで使っているdfu-utilのバージョンを確認してもらえますか? 投稿をご確認ください:Linuxでlpscryptを使ってLPCのLink2にdfuブート問題を報告してください

使用主机上的 SPIGen 无法驱动 FRDMPT2001EVM 上的 DRVEN 和 RESETB 引脚。 你好， 我按照 KTFRDMPT2001EVMUG.pdf 配置了 FRDM-KL25Z 板，并用电缆将其连接到我的 PC。FRDM-KL25Z 板上的蓝色 LED 灯亮起。在主机上的 SPIGen 中加载 *.spi 文件后，我可以正常下载并读取/写入寄存器。然而，DRVEN 和 RESETB 引脚仍然保持默认状态。我无法使用 SPIGen 面板/GUI 中的按钮将板上的相应引脚拉高或拉低。 我应该如何解决这个问题？感谢你的回复！ PT2001 FRDM-KL25Z Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 嗨 Lex（ @LexLiu ）， 请问您能否帮忙解决一下使用 SPIGen SW 驱动 FRDMPT2001EVM 上的 DRVEN 和 RESETB 引脚时遇到的问题？ 谢谢您！ BRs，托马斯 Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 这个问题我还没解决。你能帮助我吗？

Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC Hello, I configured the FRDM-KL25Z board according to KTFRDMPT2001EVMUG.pdf and connected it to my PC with a cable. The blue LED on the FRDM-KL25Z board turns on. After loading the *.spi file in SPIGen on the host PC, I can download normally and read/write registers. However, the DRVEN and RESETB pins remain in their default state. I cannot use the buttons in the SPIGen panel/GUI to drive the corresponding pins on the board high or low. How should I solve this issue? Thank you for your reply! PT2001  FRDM-KL25Z  Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC Hi Lex (@LexLiu), Could you please help with this question regarding the problem with driving both the DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen SW? Thanks! BRs, Tomas Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC I haven't solved this problem yet. Can you help me?

Ibis Lx2160a 型号 嗨，大家好 我想知道如何才能获得适用于 lx2160a 的 ibis 型号，有人可以帮帮我吗？ 非常感谢您 元 Re: Ibis model for Lx2160a IBIS模型不公开，请在此处创建案例： https://support.nxp.com/s/?language=en_US  并分享你的保密协议。 谢谢！

ホストPC上のSPIGenを使用してFRDMPT2001EVMのDRVENピンとRESETBピンを駆動できません こんにちは、 KTFRDMPT2001EVMUG.pdfに従ってFRDM-KL25Zボードを設定し、ケーブルでPCに接続しました。FRDM-KL25Z基板上の青色LEDが点灯します。ホストPCのSPIGenで*.spiファイルを読み込んだ後、通常通りレジスタをダウンロードし読み書きできるようになりました。しかし、DRVENとRESETBのピンはデフォルトのままです。 SPIGenパネルやGUIのボタンを使って、基板上の対応するピンを高くまたは低く動かすことはできません。 この問題をどう解決すればいいでしょうか？お返事ありがとうございます！ PT2001 FRDM-KL25Z Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC こんにちは、Lex（ @LexLiu ） SPIGen SWでFRDMPT2001EVMのDRVENピンとRESETBピンの両方を駆動する際の問題について、この質問についてご協力いただけますか? よろしくお願いします！ BRs、トーマス Re: Unable to drive DRVEN and RESETB pins on FRDMPT2001EVM using SPIGen on the host PC 私はまだこの問題を解決していません。助けてくれないか?

mcxn947 加密区指定可范围么，程序内部フラッシュ加密区 暗号化や署名は特定のフラッシュ空間の範囲に適用できますか? 暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか（読み戻されるデータは暗号文ですか？書き込まれるデータは平文ですか？）？ OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか? Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 こんにちは、 まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。 正しい 上記の観点に基づくと： そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。 つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。 もう少し詳しく説明させてください。 はい、SBファイルは暗号化されているため、フラッシュメモリに書き込む前にROMで復号化する必要があります。しかし、SBファイルはOEMと製造工場間のファームウェアを保護するために、完全に独立して暗号化されています。 フラッシュメモリのプログラミング（内蔵型か外付け型かを問わず）はまた別の話で、全く使用されないか、あるいは異なるアルゴリズム、初期ベクトルなどを用いて使用されます。 よろしくお願いいたします。 リボル Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 まず明確にしておきたいのは、暗号化が有効になると、チップ上で実行されているプログラムがフラッシュメモリに書き込む際、書き込まれるデータは平文ですが、最終的にフラッシュメモリに保存されるのは暗号文です。そして、チップ上で実行されているプログラムがフラッシュメモリ内の暗号文を読み取ると、平文として出力されます。   上記の観点に基づくと： そして、Secure Provisioningソフトウェアが読み取るSBファイルは暗号文であり、シリアルISP経由でチップの純正ISP ROMブートローダーに送られるものも暗号文でなければなりません(そうでなければ論理的な欠陥が生じます)。工場出荷時のISP ROMブートローダーは、シリアル通信で受信した暗号文を平文に復号化し、その平文データをフラッシュメモリに書き込みますが、最終的にフラッシュメモリに保存されたデータは再び暗号化され、暗号文になります。 つまり、ISPプログラミング中、工場出荷時のISP ROMブートローダーはまず復号化を行い、次に暗号化を行うため、復号化と暗号化の往復処理が行われる。                           Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 こんにちは、 MCXNデバイスの場合： 暗号化や署名は特定のフラッシュ空間の範囲に適用できますか? SECツール： - アプリケーション全体に署名 - 暗号化領域は製品のライフ期間中に一度設定され、FUTUREのアップデート(アプリの拡張)のために予約を取る必要があります。 暗号化されたフラッシュ領域内におけるプログラム自身の読み書き動作は、以前とどのように異なりますか（読み戻されるデータは暗号文ですか？書き込まれるデータは平文ですか？）？ 暗号化／復号化はリアルタイムで行われます。アプリがフラッシュメモリから読み込む場合、そのことを気にする必要はありません。透過的に処理されます。アプリケーション自体から暗号化されたフラッシュ領域に書き込むことについては、調査が必要です。注意点があるかはわかりません。 OTAアップグレードの際、チップの暗号化/復号に適合するアーキテクチャを競合なくするにはどうすればよいのでしょうか? 前述のとおり、暗号化には適切なサイズのメモリ領域を指定する必要があります。もしアプリケーションが暗号化領域を超えた場合、OTAは動作しますが、暗号化圏外のアプリ部分だけが動作し、IPアドレスは暗号化で保護されません。 よろしくお願いいたします。 リボル

启用 Falcon 模式下的安全启动（内核版本 6.12.49）|| iMX8MP_EVK 大家好， 请问您能帮我启用Falcon模式下的安全启动吗？ 我已成功借助 meta-imx-fastboot GitHub 代码库实现了 Falcon 模式。但是，我发现 meta-imx-fastboot 的实现会 在 Falcon 模式启动过程中 有意移除 OP-TEE 。 由于我的用例也需要用到 OP-TEE，我在 NXP 论坛上提出了一个问题， @elena_popa提供了一个保留并启用 OP-TEE 的解决方案。我附上了论坛链接供您参考。 目前，我在启用 安全启动 时遇到了问题 ，因为我找不到任何关于我的当前内核版本在 Falcon 模式下启用安全启动的文档。 环境详情： 主板： i.MX8M Plus EVK（i.MX8MP EVK） 内核版本： 6.12.49 Yocto 环境：基于 Yocto 的 NXP 电路板支持包。 启动模式：猎鹰模式 要求：猎鹰模式 + OP-TEE + 安全启动 Yocto Project Re: Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK 你好， 请问您遇到了什么错误？ 顺祝商祺！

Re: S32G274A LLCE CAN 現在、自社開発のボードはマルチコアモードで動作しています。1つのA53コアは他のデバイスとのネットワーク通信タスクに使用され、他の複数のA53コアはバス通信ドライバを実行します。各バスタイプはそれぞれ別のA53コアを使用します。問題が発生しました。現在のLLCE CANリカバリ操作は、LLCE CANモードを停止してから再開するように構成されています。実際のほとんどのシナリオでは通信は復旧できますが、バスリカバリが頻繁に実行される場合があり、他のA53コアの正常な動作に影響を与えます（ネットワーク通信タスクが中断されます）。質問は、LLCE CANバスリカバリにはどのような方法があるか、また、LLCE CANを別のコアで実行しても他のコアに影響を与えるのはなぜか、ということです。バージョン情報は、S32G_LLCE_1_0_9、SW32G_RTD_4.4_4.0.2_P04_D2312です。 Re: S32G274A LLCE CAN こんにちは、 @JACK_Q こんにちは ソフトウェアおよびハードウェアのテスト環境について、詳細な説明をいただけますでしょうか？ 1. あなたのシステムでは、MコアとAコアは同時に使用されていますか？M7コアはどのようなタスクを実行しますか？どのソフトウェアパッケージに依存していますか？ 2. あなたの説明によると、A53側の各コアはそれぞれ独自のタスクを実行しているようですが、どのようなソフトウェアが動作していますか？Linux BSPでしょうか？ BR チェイン

Difference between S32K1_S32M24X and S32K1 RTD packages? I am developing for the S32K116. I noticed while going through the S32DS Extensions an dUpdates that I have two S32K1 packages installed: "S32K1_S32M24X Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP06" and "S32K1 Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP06" What is the difference between the two? If they do the same for my case, which one should I keep/uninstall? I tried removing one of them (the S32K1 one) but then my projects couldn't load their .mex files anymore. Re: Difference between S32K1_S32M24X and S32K1 RTD packages? Hi @daniel_meier  Although the packages may appear similar, they have dependencies between themselves and with S32DS, and are not intended to be treated as standalone components that can be used independently of one another. Therefore, we recommend reinstalling the package and keeping both packages installed to ensure proper project functionality. BR, VaneB

Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK Hi Team, Could you please help me enable Secure Boot in Falcon Mode? I have successfully achieved Falcon Mode with the help of the meta-imx-fastboot GitHub repository. However, I observed that the meta-imx-fastboot implementation intentionally removes OP-TEE during the Falcon Mode boot flow. Since OP-TEE is also required for my use case, I raised a query on the NXP forum, where @elena_popa provided a solution to retain and enable OP-TEE. I have attached the forum link for reference. Currently, I am facing an issue with enabling Secure Boot, as I could not find any document for Secure Boot with falcon mode for my current kernel version. Environment details: Board: i.MX8M Plus EVK (i.MX8MP EVK) Kernel Version: 6.12.49 Yocto Environment: Yocto-based NXP BSP Boot Mode: Falcon Mode Requirement: Falcon Mode + OP-TEE + Secure Boot Yocto Project Re: Enable Secure Boot in Falcon Mode (6.12.49 - Kernel Version) || iMX8MP_EVK Hello, Could you please share which error are you getting? Best regards.

mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Can encryption and signing be applied to a specified range of flash space? How does the program's own read/write behavior within the encrypted flash region differ from before (is the data read back ciphertext? is the data written plaintext?)? During OTA upgrades, how can the architecture be made to match the chip's encryption/decryption without conflicts? Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Hello, To be clear first: once encryption is enabled, when a program running on the chip writes to flash, the data it writes is plaintext, but what is ultimately stored in flash is ciphertext; when the ciphertext in flash is read by a program running on the chip, it comes out as plaintext. Correct Based on above viewpoint : Then, the SB file read by your Secure Provisioning software is ciphertext, and what is sent over serial ISP to the chip’s factory ISP ROM bootloader must also be ciphertext (otherwise there would be a logical flaw). The factory ISP ROM bootloader decrypts the ciphertext received over serial into plaintext, and then writes the plaintext data into flash, but ultimately the data stored in flash is encrypted again, becoming ciphertext. In other words, during ISP programming, the factory ISP ROM bootloader first decrypts and then encrypts, going through a decrypt-then-encrypt round trip. Let me put more light into this: yes SB file is encrypted and must be decrypted by ROM before writing to Flash. But SB file is encrypted completely independently, to protect the firmware between the OEM and manufacturing facility. Programming flash, either internal or external, is different story and either is not used at all or is used with different algorithm, initial vector, etc. Regards, Libor Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 To be clear first: once encryption is enabled, when a program running on the chip writes to flash, the data it writes is plaintext, but what is ultimately stored in flash is ciphertext; when the ciphertext in flash is read by a program running on the chip, it comes out as plaintext.   Based on above  viewpoint : Then, the SB file read by your Secure Provisioning software is ciphertext, and what is sent over serial ISP to the chip’s factory ISP ROM bootloader must also be ciphertext (otherwise there would be a logical flaw). The factory ISP ROM bootloader decrypts the ciphertext received over serial into plaintext, and then writes the plaintext data into flash, but ultimately the data stored in flash is encrypted again, becoming ciphertext. In other words, during ISP programming, the factory ISP ROM bootloader first decrypts and then encrypts, going through a decrypt-then-encrypt round trip.                           Re: mcxn947 加密区域可以指定范围么，程序内部如何访问flash加密区 Hi, For MCXN devices: Can encryption and signing be applied to a specified range of flash space? SEC tool: - signs whole application - encryption region is configured once in the product lifetime, you need to make a reserve for future updates (increased size of app) How does the program's own read/write behavior within the encrypted flash region differ from before (is the data read back ciphertext? is the data written plaintext?)? Encryption/decryption is on-the-fly. App reading from flash does not need to care, it is transparent. About writing to encrypted flash region from the application itself, you need to investigate, I'm not sure if there are any caveats. During OTA upgrades, how can the architecture be made to match the chip's encryption/decryption without conflicts? As mentioned above, you need to specify reasonable size of memory region for encryption. If you application exceeds the encrypted region, OTA will work, only the part of the app that will be outside of encrypted area will still work, only your IP won't be protected by the encryption. Regards, Libor