Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
LPC18xxのウォッチドッグリセットを検出できません ウォッチドッグリセットが発生したことを検出する際に問題が発生しています。現在、ユーザーガイドに記載されている手順に従っています。 ウォッチドッグのタイムアウトフラグ(WDTOF)を調べることで、ウォッチドッグがリセット状態を引き起こしているかどうかを判断できます。WDTOFフラグはソフトウェアによってクリアされなければなりません。 デバイスのリセットは正しく行われるものの、その後フラグが設定されていないようです。 LPC4357で似たような問題に関する古い投稿(解決済み:LPC4357:ウォッチドッグリセットを検出できない - NXPコミュニティ)を見かけましたが、LPC18xxのエラッタには何も記載されていませんでした。 LPC18xxも上記と同じ問題を抱えているかどうか確認していただけますか? lpc18xx Re: Cannot detect watchdog reset for LPC18xx こんにちは@ejg 投稿ありがとうございます! どのLPC18xxを使っているのか、具体的に教えていただけますか? また、国旗をレビューしたのはいつですか? lpc18xx_wwdt.hからWWDT_Init関数を呼び出すと割り込みフラグが消去されるため、WDTOFを読み込む必要があります。 Re: Cannot detect watchdog reset for LPC18xx こんにちは、 @carlos_o さん、ご返信ありがとうございます。 私はLPC1837を使用しています。 このフラグは、他のWWDTレジスタとやり取りする前に、起動時にチェックされます。CMSIS SystemInitが完了したら、systickを設定し、このフラグを確認します。 Re: Cannot detect watchdog reset for LPC18xx こんにちは@ejg はい、LPC18xxはLPC43xxと同じ問題を抱えています。 コアリセットの原因を特定するには、LPC18xxユーザーマニュアルのセクション14.5.1「コアリセットの原因を特定する」を参照してください。 BR アリック
查看全文
RT1064:引脚配置,用于从内部闪存启动 你好, 这可能听起来像个愚蠢/新手问题,但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源(通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC),但没有列出内部闪存,就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存,但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出,只有两种启动模式可用(QSPI 或 SD 卡),并且还声称不支持 QSPI 启动(参见 2.7 段),因此 SD 卡是唯一的启动源…… 非常感谢您的帮助! i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat , 如 AN12290 中所述,MIMXRT1064 只能从 FlexSPI2 启动,FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存,该接口可用于保存数据或其他功能,但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源,即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC;通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI,并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动,引导设备开关 (SW7) 设置应为: SW7-1 关闭,SW7-2 关闭,SW7-3 打开,SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0,才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时,BOOT_CFG2[2:0]引脚也必须设置为0,以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR, 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好,埃德温, 确实有道理。我感到很困惑,因为外部闪存和内部闪存都是 QSPI 接口的,很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”,并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。
查看全文
MPC5644A 核心测试 我正在尝试对 MPC5644A 芯片组进行核心测试。 我目前使用的环境是 Eclipse 和 Wind River。 我下载了制造商的库 e200Zx_ICST_RTMC_3.0.0,其中包含几个汇编源 (.s) 文件。 其中,vle 编译成功。 但是 book_e 和 spe 编译失败。 编译过程中,各种汇编指令(如 bc、bcl、bclr、xoris、bclrl 和 bcctrl)出现错误。我打开了 book_e 和 spe 汇编文件的属性,并将 -tPPCE200Z4NEG:simple 添加到 C/C++ 版本 --> 设置 --> Diab 汇编器 --> 其他 --> 其他选项和标志中,并成功完成了编译。然而,在调试过程中,我到达了 `fsl_self_test_icst.c` 中的 `Fsl_call_test_execution_icst` 之前,而这部分实际上执行的是核心测试。如果我继续进行下一步,就会陷入无限循环。 通过 Eclipse 的反汇编检查,我发现当我单步进入地址 0x51518(紧接在 `SPE_ICST_int_logical_test` 开始之后)时,它会立即跳转到 0x3f2b90(一个空白空间)。 我应该怎么办?我不知道从哪里开始。 Re: MPC5644A core test 你好, SCST 仅支持 MPC56xx 系列中的以下设备: MPC560xP MPC564xB-C 由于 MPC5644A 和 MPC564xB 共享相同的 e200z4 CPU 内核,因此 SCST 库中以 CPU 为中心的部分可以进行调整。但是,所有整合方面都必须进行审查: 异常向量地址 存储器映射 时钟初始化 外围依赖性 链接器脚本假设 实际的 CPU 测试算法应该具有很强的可移植性,因为它们针对的是相同的 e200z4 架构。 NXP 没有为旧款 MPC5644A 设备提供官方的 SCST 库。然而,由于 MPC5644A 与 MPC564xB 系列使用相同的 e200z4 内核,因此在审查特定设备的集成细节后,或许可以采用 MPC564xB 解决方案中以 CPU 为中心的自检例程。或者,可以使用 MCU 的内置功能安全机制(ECC、CRC、看门狗、MPU、异常处理)开发自定义启动诊断实现,以满足项目特定的功能安全要求。 我应该怎么办?我不知道从哪里开始。 如果代码在 0x51518 处进入 SPE_ICST_int_logical_test(),然后立即跳转到 0x3F2B90(看起来像是空内存),我首先怀疑的不是 CPU 故障,而是链接器/库集成问题。 对于 SCST 库而言,这通常意味着以下情况之一: 1. 函数指针或分支表未正确链接 2. 缺少库对象 3. 内存模型错误/虚拟环境不匹配 4. 为另一台设备构建的 SCST 库 5. MMU/TLB 翻译问题 顺祝商祺! Peter
查看全文
在 i.MX8M Plus 和 TIM-VX/VSINPU 上,GC7000UL 通用计算推理路径似乎仅支持 NPU。 板/电路板支持包。: i.MX8M Plus,aarch64 Galcore 版本 6.4.11.p2.745085 ONNX 运行时,带有 VSINPUExecutionProvider(静态链接到 libtim-vx.so) Vivante OpenCL ICD 已存在且功能正常(Vivante.icd → libVivanteOpenCL.so) 目标: 专门在 GC7000UL 3D GPU 核心上运行 ResNet50 推理基准测试(MLPerf loadgen 测试框架),以便与已收集的现有 NPU(VIP8000Nano)和 CPU 基准测试结果进行比较。 已确认有效的功能: 通过 Vivante OpenCL ICD 使用 clGetPlatformIDs/clGetDeviceIDs 可以清晰地枚举同一平台下的两个独立设备: 设备 0:GC7000UL.6204.0000 设备 1:VIP8000Nano-S+I.8002.0000 两者都报告 CL_DEVICE_TYPE_ACCELERATOR,没有错误,通过链接到 libOpenCL.so → libGAL.so 的最小 C 测试程序确认。 是什么阻碍了通过 ORT 进行 GPU 调度: ort.get_available_providers() 仅返回 ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — 没有基于 OpenCL 的 EP。 VSINPUExecutionProvider 静态链接到 libtim-vx.so(OVXLIB/vsi_nn_* API)。libtim-vx.so 和 libGAL.so 的符号/字符串转储显示没有 DEVICE_INDEX/DEVICE_ID 风格的环境变量或配置表面——只有行为切换(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_* 等)。 libGAL.so 确实在原始 HAL 层导出了 gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex,但是从 OVXLIB/TIM-VX 到该调用没有明显的管道,这表明 VSINPU 使用的图形编译器可能被硬编码为仅针对 NPU 核心,而不管设备索引如何。 具体问题: 此电路板支持包 (galcore 6.4.11.p2) 上的 TIM-VX / OVXLIB 是否支持将图编译并分发到 GC7000UL 作为通用计算目标?或者,此版本中的图编译器是否设计为仅限 NPU?我如何验证是否可以以这种方式运行它? 如果 TIM-VX 上游支持 GPU 目标图编译,但 NXP 提供的版本中未启用,是否有构建标志/SDK 元器件可以启用它? 如果无法通过 TIM-VX/ORT 获得支持,NXP 是否有推荐的方法可以直接在 GC7000UL 上运行通用推理(例如通过 OpenCL/OpenVX 层,因为该部分协议栈已被确认功能正常),或者是否有示例应用程序、SDK 组件或参考实现可供我们参考? 我目前是一名学生,正在尝试进行这项实现,并在 GPU 上运行 ORT,请问是否有任何方法或途径可以使用 GPU 进行推理? 非常感谢 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 嗨@WaleedO , 感谢您联系恩智浦技术支持。 要在 GPU 上运行推理,您应该使用 GPU 委托,它允许由 GPU 加速支持的操作,而不是完全在 CPU 上运行。 我建议您查看我们的机器学习用户指南,以便更好地了解可用的执行后端、委托配置、支持的框架和示例应用程序。该指南还包含逐步示例,可以帮助您验证 GPU 委托是否已正确加载以及您的模型是否按预期执行。 如果在安装或执行过程中遇到任何问题,请分享您的模型、BSP 版本以及您正在使用的命令,我将很乐意为您提供进一步的帮助。 此致, 亚历杭德罗·加西亚 Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only 你好@Chavira 很高兴见到你。 查阅文档后发现,GPU 委托和 OpenCL 路径是在 i.MX 95/952 GPU(Arm Mali G310)中使用。我目前正在研究IMX8MPLUS。IMX8M Plus 的架构如下:VX 代理 ==> TIM-VX ==> GPU/NPU(统一驱动程序) ==> I.MX 8 系列 NPU 和 GPU(GC7000、GC7000L、GC7000UL)。根据文件记载。 目前我正在使用 ONNX 和 ORT。当我运行该程序时,它默认在 NPU 上运行。是否有办法使用 OpenCL 在IMX8MPLUS GPU 上工作?或者是否有任何手动覆盖或我可以实现的技术,以便我可以手动将编译目标设置为 NPU 或/和 GPU? 非常感谢您的回复。 亲切的问候, IMX8MPLUS #TIM-VX #VX-delegate
查看全文
複数のAB_SWAPロケーションにおけるIVTの使用に関する説明(S32K328) こんにちは、NXPチームの皆様、 私はAB_SWAPとHSE_Bを使用してS32K328のメモリレイアウトを作成しているのですが、IVTの位置をどのように扱うべきかについて明確な説明が必要です。 S32K3xxリファレンスマニュアルより: IVTは、フラッシュメモリ内の固定位置に定義された、主要なブートエントリ構造です。 IVTにはアプリケーションイメージ、起動設定、オプションの認証データへのポインタが含まれています。 AB_SWAP構成では、デバイスと設定に応じて、ブートとイメージ選択に関連付けられた複数の定義済みフラッシュ領域/アドレスが存在します。 S32K328のメモリマップを見ると、次のようになっています。 IVT は0x0040_0000 (アクティブバンク) にあります 同じバンク内の0x0060_0000にある別の整列領域は、ブート/優先度処理または一部のレイアウトにおける予約領域に関連しているようです。 質問: IVT配置 IVTは、各バンクのプライマリロケーション(例:0x0040_0000)にのみ存在することが想定されていますか? それとも、IVT(またはIVTに似た構造)が別の住所(例えば 0x0060_0000)にも存在しなければならないという要件(または支持されるケース)はありますか? AB_SWAP内の複数のIVTアドレス RMに複数のIVT関連アドレス(例:0x0040_0000、0x0050_0000、0x0060_0000など)が表示されている場合、これらは何を表していますか? 別々のIVTインスタンス、または 同じIVTコンセプトで使用される代替ブートスロット/優先ロケーション? 二次/代替領域の使用 0x0060_0000のような領域がIVTを含むことが明示的に文書化されていない場合: 予約しておくべきか、 アプリケーションデータやメタデータには安全に使えますか? ベストプラクティス AB_SWAP + HSEセキュアブートシステムにおいて、IVTに関連してこれらの追加のアラインメントされたアドレスをどのように解釈するのが推奨されますか? コンテクスト: デバイス: S32K328 ブートモード: AB_SWAP セキュリティ:セキュアブートが有効HSE_B 目標:正しい起動動作と安全なメモリ割り当て S32K3 #s32k328 Re: Clarification on IVT usage at multiple AB_SWAP locations (S32K328) こんにちは、 @venkatesh-kv 1.利用可能な定義済みアドレスにIVTを1つ配置すれば十分です。必ずしも0x40_0000のようなプライマリロケーションである必要はありません。有効なIVTを指定された順番で検索するのはSBAFの責任です。 IVT のアップデート中に何らかの問題が発生した場合に備えて、2 番目の IVT をバックアップとして使用するオプションがあります。これは通常、IVT のブート構成ワードの BOOT_SEQ ビットによってセキュアブートを有効にする際に行われます。 2. AB_SWAP モードの S32K328 には、IVT の可能な位置が 3 つあります: 0x40_0000、0x60_0000、0x1000_0000。SBAFは有効なIVTをこの順番で検索します。住所が小さいほど、優先順位が高くなります。例えば、0x40_0000に有効なIVTが存在する場合、SBAFはこのIVTを使用し、他の場所をチェックしません。 3. エリアを予約しておく必要はなく、コードやデータ用に利用できます。 4. このユースケースでは、前述のバックアップとして他のIVTロケーションを利用することができます。また、Secure Boot アプリケーションノートの「6.2 Update IVT」セクションでも説明されています。 ダウンロード可能: https://www.nxp.com/products/S32K3 アプリケーションノートはこちらでご覧いただけます: ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511) 関連するデモプロジェクトはこちらからダウンロードできます: Design Resources - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310) よろしくお願いいたします。 ルーカス
查看全文
KW47におけるELEMUとLTCの比較:LTCには性能以外に何か利点があるのか? こんにちは。 KW47プラットフォーム上のELEMU(EdgeLockメッセージングユニットドライバー)とLTC(LP信頼暗号)の使用違いについてお聞きしたいです。 私の現在の理解は以下のとおりです。 エレム ・暗号処理は専用のセキュリティコアを要求することで行われ、鍵を隔離された安全な環境に保存できるため強力な改ざん耐性を提供します。 ・セキュリティコアとの通信が必要なため、非常に厳しいレイテンシ要件を持つアプリケーションには適さない場合があります。 ・LTCで利用可能なすべての暗号アルゴリズムをサポートし、さらにECDHなどLTCが扱えないアルゴリズムもサポートしています。 ・セキュリティ関連サービス(セキュアブート統合など)も利用可能です。 したがって、私の理解では、ELEMUは高度なセキュリティを必要とする暗号処理により適していると理解しています。 LTC ・暗号操作はLTCハードウェアアクセラレータレジスタを直接制御することで実行されるため、非常に低コストかつ高性能です。 ・対応アルゴリズムはAES、DES、ハッシュなどのハードウェアアクセラレーション関数に限定されています。 ・鍵は安全で隔離された環境に保管できないため、改ざん抵抗レベルはセキュリティコアが提供するものより低い。 したがって、私の理解ではLTCはレイテンシに敏感なプロセッシングやセッションキーのような一時キーを使ったユースケースにより適していると理解しています。 上記の理解が正しければ、LTCがELEMUに対して最大の利点はパフォーマンスやレイテンシであり、タイミング要件を満たせばLTCで実現できることはすべてELEMUを通じて実現できると言ってもよいでしょうか? あるいは、機能的な制限や対応アルゴリズム、ハードウェアアクセス制限、その他の考慮点で、LTCが特定のシナリオで好まれたり必須の選択肢になるのでしょうか? ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 あなたの調子が良いといいのですが。   ELEメッセージングユニット(ELE_MU)は、アプリケーションコアとEdgeLock Enclave(ELE)セキュリティコア間の通信メカニズムです。このインターフェースを通じて、ホストプロセッサはELEに暗号およびセキュリティ関連サービスを要求できます。暗号操作に加え、ELEは鍵生成、インポート/エクスポート、安全な鍵保存、非揮発性保存のための暗号化鍵ブロブ生成などの安全な鍵マネジメント機能を提供します。 より詳細な情報は KW47セキュリティリファレンスマニュアル 第9章に記載されています。 LTC(LP Trusted Cryptography)ドライバは、KW47ハードウェア暗号加速器への直接アクセスを提供します。この方法は、アプリケーションがELE_MUのようにセキュリティコアを通るのではなく、ハードウェアアクセラレータAPIと直接やり取りするため、ソフトウェアのオーバーヘッドが低減されます。LTCハードウェアはAES、DES、HASH、PKHAなどのアルゴリズムの加速をサポートしています。( KW47 APIリファレンス・マニュアルを参照) つまり、あなたの理解は概ね正しいですが、最終的には実装要件によります。低レイテンシと最小限のソフトウェアオーバーヘッドを主な目標にしているなら、長期介護(LTC)が望ましい選択肢です。しかし、セキュリティ境界やキーライフサイクル管理が重要な考慮事項であれば、一般的にELE_MUがより良い選択肢です。 よろしくお願いします、 ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 お返事ありがとうございます。 私の理解がおおむね正しいと分かって安心しました。 LTCとELE_MUのレイテンシの違いについてもう一つ質問があります。 実際の性能差は、使用されている暗号アルゴリズム、セキュリティコアとのやり取り回数、処理されるデータのサイズなどの要因によって異なると理解しています。具体的なユースケースの詳細な条件を提供できないため、予想されるレイテンシの違いの大まかなガイドラインや一般的な特徴を教えていただけるとありがたいです。 例えば、セキュリティコアとの通信のオーバーヘッドは通常、実際の暗号処理時間よりもはるかに大きく、その結果、LTCの数倍、あるいは数十倍の遅延が発生するのでしょうか? それとも、ほとんどの実用的なCASEでは、暗号処理時間自体が全体の実行時間を支配し、総処理時間の割合で見ると追加のオーバーヘッドは比較的小さくなELE_MUのでしょうか? ELE_MUのパフォーマンスへの影響が顕著になる時期を理解するためには、大まかなガイドラインや定性的な比較だけでも非常に役立つだろう。 ご指導をよろしくお願いいたします。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、 不便をおかけして申し訳ありません。現時点では、ELE_MUとLTCのレイテンシ差を比較したり定性的に説明したドキュメントが存在しません。 ELE暗号エンジンは速度よりも安全な実行を優先して最適化されていますが、具体的な性能指標については、特定の目標条件下でKW47ハードウェア上で直接測定することをお勧めします。 KW47におけるELE機能や暗号操作に関しては、最も関連するガイダンスがKW47セキュリティリファレンスマニュアルに記載されています。 よろしくお願いします、 アナ・ソフィア。 Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? こんにちは、ソフィアさん。 ご回答ありがとうございます。 ELE_MUとLTCのレイテンシを比較したり、レイテンシー特性を定性的に説明したりするドキュメントは存在しないことは理解しています。 その場合は、実際のKW47ハードウェアでの性能を評価し、レイテンシを直接測定して両実装の違いをよりよく理解します。 ご協力ありがとうございました。 よろしくお願いします、
查看全文
ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi. I would like to ask about the differences in usage between ELEMU (EdgeLock Messaging Unit Driver) and LTC (LP Trusted Cryptography) on the KW47 platform. My current understanding is as follows: ELEMU ・Cryptographic operations are performed by requesting the dedicated Security Core, providing strong tamper resistance because keys can be stored in an isolated secure environment. ・Since communication with the Security Core is required, it may not be suitable for applications with very strict latency requirements. ・It supports all cryptographic algorithms available through LTC, and additionally supports algorithms that LTC cannot handle, such as ECDH. ・Security-related services such as secure boot integration can also be utilized. Therefore, my understanding is that ELEMU is better suited for cryptographic operations that require a high level of security. LTC ・Cryptographic operations are executed by directly controlling the LTC hardware accelerator registers, resulting in very low overhead and high performance. ・Supported algorithms are limited to hardware-accelerated functions such as AES, DES, HASH, etc. ・Keys cannot be stored in a secure isolated environment, so the level of tamper resistance is lower than that provided by the Security Core. Therefore, my understanding is that LTC is better suited for latency-sensitive processing or use cases involving temporary keys such as session keys. If the above understanding is correct, is it fair to say that the primary advantage of LTC over ELEMU is performance/latency, and that if timing requirements can be met, everything that can be accomplished with LTC can also be accomplished through ELEMU? Or are there any functional limitations, supported algorithms, hardware access restrictions, or other considerations that would make LTC the preferred or required choice in certain scenarios? Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, Hope you are doing well.   The ELE Messaging Unit (ELE_MU) is a communication mechanism between the application core and the EdgeLock Enclave (ELE) security core. Through this interface, the host processor can request cryptographic and security-related services from ELE. In addition to cryptographic operations, ELE provides secure key management capabilities, including key generation, import/export, secure key storage, and encrypted key blob generation for non-volatile storage. More detailed information can be found in KW47 Security Reference Manual Chapter 9. The LTC (LP Trusted Cryptography) driver provides direct access to the KW47 hardware cryptographic accelerator. This path offers lower software overhead because the application interacts directly with the hardware accelerator APIs rather than communicating through the security core like ELE_MU. The LTC hardware supports acceleration for algorithms such as AES, DES, HASH, and PKHA. (See KW47 API Reference Manual) So your understanding is generally correct, it will ultimately depend on your implementation requirements. If low latency and minimal software overhead are your primary goals, LTC would be the preferred option. But if security boundaries and key lifecycle management are important considerations, ELE_MU is generally the better choice. Best regards, Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your reply. I am glad to know that my understanding is generally correct. I have one additional question regarding the latency difference between LTC and ELE_MU. I understand that the actual performance difference depends on factors such as the cryptographic algorithm being used, the number of interactions with the Security Core, and the size of the data being processed. Since I am not able to provide detailed conditions for a specific use case, I would appreciate even a rough guideline or general characterization of the expected latency difference. For example, is the overhead of communicating with the Security Core typically much larger than the actual cryptographic processing time, resulting in latency that is several times or even tens of times higher than LTC? Or, in most practical use cases, does the cryptographic processing time itself dominate the overall execution time, making the additional overhead introduced by ELE_MU relatively small when viewed as a percentage of the total processing time? Even a high-level guideline or qualitative comparison would be very helpful for understanding when the performance impact of ELE_MU becomes significant. Thank you in advance for your guidance. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hello, I apologize for the inconveniences, currently there is no available documentation that provides a comparison or qualitative guideline characterizing the latency difference between ELE_MU and LTC. While the ELE cryptographic engines are optimized for secure execution rather than speed, for specific performance metrics, direct measurement on KW47 hardware under the specific target conditions would be recommended. Regarding ELE functionality or cryptographic operations on KW47, the most relevant guidance is provided in the KW47 Security Reference Manual. Best regards, Ana Sofia. Re: ELEMU vs. LTC on KW47: Are There Any Advantages of LTC Beyond Performance? Hi Sofia, Thank you for your response. I understand that there is no available documentation that compares the latency of ELE_MU and LTC or describes their latency characteristics qualitatively. In that case, I will evaluate the performance on actual KW47 hardware and measure the latency directly to gain a better understanding of the differences between the two implementations. Thank you again for your help. Best regards,
查看全文
RDDRONE-BMS772开发板配件 RDDRONE-BMS772开发板配件 抱歉,你没听懂我的意思。我目前的研究是关于电池状态估计,这需要测量真实电池的电压、电流和温度数据。因此,我不需要电池模拟器;我需要的是真正的电池。所以,我需要一块与我的开发板兼容的电池,以及一个特定型号的配套电池充电器。另外,链接中提到的 PEMicro 适配器和 SEGGER J-Link Mini 调试器是调试或编程开发板所必需的硬件吗?开发板能否直接连接到电脑进行调试和编程?这些适配器和调试器在市场上可以买到吗?此外,除了您提到的硬件之外,开发板是否还有其他必要的硬件元器件?如果是,请列出详细的配件类别及其对应的型号。非常感谢您对这些问题的详细解答。 抱歉,你没明白我的意思,我目前的研究是关于电池状态估计的,需要测量真实电池的电压和温度数据,所以我不需要电池模拟器,我需要真实的电池,所以我需要改装开发板的电池和对应电池充电器的具体型号;以及那个链接里提到的PEMicro适配器以及SEGGER J-Link迷你调试器是开发板或者烧录算法必须的硬件吗?开发板不能直接连接到电脑上进行调试和烧录程序吗?这些调试器和调试器在可以买到吗?还有,开发板除了你提到的这几个硬件以外还必须硬件吗?如果有的话请帮我列出详细的配件类别及其对应的型号;请您详细解答一下这些疑问,万分感谢。 Re: RDDRONE-BMS772 Development Board Accessories RDDRONE-BMS772开发板配件 亲爱的 Fan007, 对于电池状态估计研究,RDDRONE-BMS772 支持真正的 3S 至 6S 锂离子/锂聚合物电池组(6 V 至 26 V),并且不需要特定的电池型号。所选电池必须包含电池平衡连接器。 需要使用与所选电池化学成分和电芯数量兼容的充电器。RDDRONE-BMS772 无需专用的 电池管理系统 通信接口,因为必要时它可以断开充电路径。 对于固件开发和调试,NXP 建议使用外部 SWD 调试器,例如 PEMicro Universal Multilink 或 SEGGER J-Link Mini。RDDRONE-BMS772 没有板载 USB 调试接口,因此需要使用外部调试器。这些调试器在市场上均有销售。 对于电池特性分析和 SOC/SOH 算法开发,强烈建议使用可编程电子负载 (E-load) 进行受控充放电测试。   最诚挚的问候, 约瑟夫
查看全文
IMXRT 1180 系列 您好,NXP团队, 我们目前正在评估恩智浦半导体微控制器在空间机载计算机 (OBC) 应用中的使用情况。 最初,我们考虑的是i.MX RT1170 (MIMXRT1170) ,在评估过程中,我们注意到 NXP 的文档明确指出该器件采用28nm FD-SOI 技术制造。由于半导体工艺技术是我们应用的关键评估标准,因此我们现在也对评估i.MX RT1180系列感兴趣。 在继续进行下一步之前,我们希望了解i.MX RT1180的制造工艺: i.MX RT1180 是否也像 i.MX RT1170 一样,采用28nm FD-SOI 技术制造? 如果没有,能否请您提供RT1180所采用的工艺技术信息? 是否有任何官方文档或产品简介提及该设备的制造节点和工艺技术? 我们查阅了公开的文档,但未能找到有关 RT1180 工艺技术的官方声明。 这些信息对我们的内部技术评估和认证活动非常重要,我们非常感谢您的指导。 感谢您的支持。 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的快速回复,并确认i.MX RT1180采用28nm FD-SOI 技术制造。 我们希望您能再澄清一点。请问这是否适用于整个 i.MX RT1180 系列,包括以下设备? i.MX RT1186 i.MX RT1187 i.MX RT1189 如果 RT1180 系列的所有成员都采用相同的 28nm FD-SOI 工艺制造,则此信息将有助于我们进行外围和特征分析,以确定最适合我们应用的设备。 希望您能确认一下。 感谢您的支持。 此致, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 非常感谢您对我们产品的关注以及对我们社区的使用。 是的。i.MX RT1180 采用 28 纳米 FD-SOI 技术。 抱歉,目前还没有任何公开的官方文件或产品简介明确提及该设备的制造节点或工艺技术。 希望对你有帮助 顺祝商祺! 5月 Re: IMXRT 1180 Family 嗨@mayliu1 , 感谢您的及时回复和确认。这些信息非常有帮助,非常感谢。 根据您的确认,我们将继续进行评估,并将此视为对该制造技术的确认。 感谢您的支持。 问候, 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 , 感谢您的反馈。 是的,我查阅了 i.MX RT1186、i.MX RT1187 和 i.MX RT1189 的相关信息。它们均采用相同的 28nm FD-SOI 工艺技术制造。   希望对你有帮助 顺祝商祺! 5月
查看全文
How to measure CPU load for S32G399 baremetal application on S32DS Hi everyone, I would like to know how to measure CPU load for S32G399 while it is running.  Background: my S32G399 project is a four-core M7 baremetal one with one ELF file which is developed on S32DS3.5.10. I use a custom bootloader to boot up A53 and M7 which has been implemented. My request is measuring CPU load on M7 end. I have S32 Debug Probe on hand, so I can attach to my M7 application while it is running. However, I don't know the detailed steps/way to measure the load. I even don't know if it is feasible only using S32 Debug Probe to reach this goal.  Hopefully someone can provide relevant document or some guidance. Thank you. Re: How to measure CPU load for S32G399 baremetal application on S32DS Hello, @Yang_C  Thanks for your post. 1. From my understanding, solely depend on the debugger may not obtain run time CPU load accurately. 2. It is possible to add some code to your own application, for example, to enable timer, then measure the time executing your main task, at last. calculate the portion of (executing time)/(running time) to evaluate the rough CPU load. BR Chenyin Re: How to measure CPU load for S32G399 baremetal application on S32DS Thank you very much. I will try code-side measuring.
查看全文
PN7160 在内核版本 6.6.92 下无响应 我们的团队已将PN7160移植到内核6.6.92 , 但它目前无法读取任何NFC标签。 以下是我们的DUT信息: 内核版本: 6.6.92 操作系统: Yocto Scarthgap PN7160 驱动程序补丁文件: 0003-nfc-nxpnfc-add-NXP-PN7160-i2c-spi-kernel-driver.patch(克隆自 NFC GitHub 项目并修改以适配内核 6.6) nfcDemoApp 配方: recipes-nfc.7z(从 NFC GitHub 克隆并修改以修复构建错误) 内核日志: nfc-log.txt 您能否提供一些建议,帮助我们解决这个问题? 回复: PN7160 no response with kernel 6.6.92 请在 libnfc-nxp.conf 中将 LOGLEVEL 设置为 0x03。然后把运行 nfcDemoApp 时的日志发给我。请同时将 libnfc-nci.conf 和 libnfc-nxp.conf 文件发送给我,以便我检查。 回复: PN7160 no response with kernel 6.6.92 感谢您的回复。 日志文件和配置文件(libnfc-nci.conf 和 libnfc-nfc.conf)已附上。 您能给我们一些建议吗?
查看全文
S32K388 使用 MemAcc 擦除 PFLASH 卡住 您好!我使用 MemAcc_Example_S32K388,并将 DFLASH 更改为 PFLASH。但是当我擦除 pFlash 时,程序卡在了 MEMACC_JOB_PENDING == MemAcc_GetJobStatus(TEST_AREA) 处。 我修改了比较程序,将 TEST_AREA 设置为 1。 这是修改后的程序,希望它能发现并指出我的错误,我将非常感激。 S32K3 Re: S32K388 Use MemAcc Erase PFLASH Stuck 嗨@zhangyu5454 , 我发现一个问题,前缀不正确,应该是 Mem_43_INFLS。 Re: S32K388 Use MemAcc Erase PFLASH Stuck 我尝试将其更改为 Mem_43_INFLS,但仍然无法成功运行。然后我将例程 DFLASH 中的 Mem_43_INFLS 更改为 abc123,它就可以正常运行了。最后,我发现问题出在 MemAcc 内存调用的 DIRECT_STATIC 上。 将其更改为间接静态可以解决我的问题。
查看全文
EB许可证激活失败:错误“允许的数量 (0)”和 50019 我无法激活我的单用户 EB Tresos 离线许可证。在本地退回旧许可证后,我的激活码的所有许可证席位在 FlexNet 云服务器上都被锁定。 我尝试过在线激活和离线激活两种方式。每种方法的相应结果分别显示在附图中的两张截图中。
查看全文
Zephyr:RW61X用の圧縮FWサポート CONFIG_NXP_COMPRESS_WIFI_NB_FW は、 https://github.com/nxp-zephyr/nxp-zephyr/commit/e64f39fa2a05edec7bd8a2b24d9f1236c43d6c35でデフォルトで有効になっています。 rw61x_sb_wifi_a2_compressed.bin ファイルがないと、CMake が失敗します。圧縮処理が抜けているのでしょうか?どの圧迫方法がサポートされていますか? ローダーに変化は見られませんでした。圧縮ファームウェアは自動的に処理されますか? Re: zephyr: support compressed FW for RW61X NXPのZephyrフォーラムがあることを今見かけました。これをあちらに移動すべきでしょうか? Re: zephyr: support compressed FW for RW61X 私はnxp-v4.4-branchを使用しています。Zephyr/Samples/Net/WiFi/Shellはfrdm_rw612で使っています。 何が起こったのか分かりました。私はこの西側アップデートエラーを見落としていました。 === 更新中 wifi_nb_fw (modules/hal/nxp/zephyr/blobs): 致命的な:宛先パス「modules/hal/nxp/zephyr/blobs」はすでに存在しており、空のディレクトリではありません。 次にファームウェアを取得するために、 https://docs.zephyrproject.org/latest/boards/nxp/frdm_rw612/doc/index.html#wireless-connectivity-supportに従って「west blobs fetch hal_nxp」を使用しました。 これにより圧縮イメージがダウンロードされず、CONFIG_NXP_COMPRESSED_WIFI_NB_FW が設定されている場合に表示されるエラーが発生しました。 blobs ディレクトリには既に次の場所からのファイルが含まれていました: https://github.com/nxp-zephyr/hal_nxp/tree/nxp-v4.4-branch/zephyr/blobs/license/ 私は.mcuxpressotools/.mcux-venv-3.12/bin/westからwestを使用していました。これはバージョン1.5.0です。 古いバージョン(v1.3.0)を試してみたところ、westはエラーを起こすことなく、既存の空でないディレクトリにリポジトリを追加するだけでした。 Re: zephyr: support compressed FW for RW61X こんにちは、 あなたの調子が良いといいのですが。何を検査しているのか、詳しく教えていただけますか? 具体的な例を使って作業していますか? 何か変更を加えましたか? よろしくお願いいたします。 リカルド
查看全文
8MPLUSLPD4-EVK - Autopower ON Hi Team, 8MPLUSLPD4-EVK turns ON (boots) when power supply is provided and SW3 is turned ON. Based on our understanding and assumption ONOFF button (SW1) needs to be pressed to turn ON Board. But in actual case EVK turns ON without pressing ONOFF Button *SW1. Could you clarify how this auto power on works and use case of ONOFF button? Correct me if my understanding is wrong 🙂 Re: 8MPLUSLPD4-EVK - Autopower ON Hello @ramkrish  I hope you are doing very well. Actually, that behavior is correct. When you Turn On the SW3, is expected that board will power up. When you power off the board by software, you can Turn on again with the SW1 (ONOFF). Best regards, Salas.
查看全文
EB tresos activation code failed i'm trying to use EBtresos for AUTOSAR, but i failed to activated. activation Code : 7416-E905-5CC2-F20A ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. so i need the the other activate code to use the EBtresos. thank you. Re: EB tresos activation code failed Thank you for your patience. The internal team has updated the activation code on the webpage. Please click the link below to find the latest activation code: S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool -> EB tresos Studio 29.0.0  Re: EB tresos activation code failed Hi Sorry for the inconvenience we bring you! I have already reported this issue to the internal team, and I will let you know as soon as I receive their reply.   Best Regards, Robin Re: EB tresos activation code failed Hello, the activation code updated on the NXP website is still this: 7416-E905-5CC2-F20A. I tried to activate it today, but it still failed ERROR: flxActAppActivationSend (50040,41147,10248) The quantity specified exceeds maximum quantity allowed (0). Connection to FlexNet Operations Server failed. Re: EB tresos activation code failed Please see my previous reply; the activation code has been updated. Please tell me which version of EBTresos page has not yet had its activation code modified so I can report it to the internal team for an update.
查看全文
GUI Guiderの失われたプロジェクト設定ファイルを復元するにはどうすればよいですか? 組み込み型T113ボードには、解像度480×320の液晶画面が使用されました。当初、UI設計はNXP GuiGuiderソフトウェアツールを使用して行われ、自動的にCコードのセットを生成していました。その後、.guiguiderプロジェクトファイルが失われ、GuiGuiderのIDEsソフトウェアで再度開こうとすると、.guiguiderが起動しなかったため読み込みに失敗しましたプロジェクト設定ファイルが見つかりませんでした。今では生成されたCコードを通じてしかインターフェースを変更できず、非常に直感的で非効率的です。皆さんにお伺いしたいのですが、.guiguider を復元する方法はありますか?C言語プロジェクトコードからプロジェクト構成ファイルを取得する? Re: How to recover lost project config files of GUI Guider? こんにちは@wenzhang さん 残念ながら、.guiguider を復元する確実な方法はありません。C言語プロジェクトコードからのプロジェクトファイル。これらは技術的には互いに独立している。.guiguiderファイルは、GUI Guiderアプリケーションが入力として使用するすべての設定を編集可能なプロジェクトとして表示するために使われます。一方、生成されたCコードはGUI Guiderの出力であり、このグラフィックライブラリを使用してGUIを表示するためのLVGL構成として生成されます。 微調整のみが必要な場合は、必要なウィジェットの変更を大まかに設定した新しいプロジェクトを作成し、生成されたコードを参考にして元のプロジェクトのコードを調整するのが最善の方法でしょう。 必要な変更がより大きな場合は、新しいプロジェクトでGUI GuirでGUI全体をやり直し、ツールにコード全体の生成を再度任せる方が良いでしょう。これにより、最新バージョンのGUI Guider(v2.0.0)を使用して、GUIを最新バージョンのLVGL(v9.4.0)にアップデートすることも可能になります。 BR、 エドウィン。
查看全文
了解 RD772BJBCANFDEVB、RD-K358BMU 和 RD33774CNC3EVB 之间的通信流程 您好,NXP团队: 我们正在评估以下NXP 电池管理系统评估板: RD772BJBCANFDEVB (BJB) RD-K358BMU(BMU) RD33774CNC3EVB(卡内基梅隆大学) 在审查现有示例软件时,我们无法理解 BJB、BMU 和 CMU 之间的完整通信流程。 我们希望您能就以下问题作出澄清: 三个董事会之间的整体沟通流程。 它们之间交换 CAN 消息。 信号从一个电路板流向另一个电路板。 哪些软件模块/文件实现了这种通信? 是否有通信流程图或架构文档? 任何解释软件通信流程的文档或应用笔记都将不胜感激。 谢谢。 RD33774CNC3EVB 、 RD-K358BMU 、 RD772BJBCANFDEVB
查看全文
imx95はRAMへのサスペンド時にvdd_socをオフにする こんにちは、 アイドル状態になった後、VDD_SOCをオフにしようとしています。 例えば、m33コンソールでは次のようになります。 lm サスペンド lm M7 サスペンション アイドル 次に、vdd socをオフにします(pf09のスタンバイモードをvdd socオフに設定することによって)。 次にスタンバイピンを放します。 m33 の VDD_SOC は最初からやり直しますが、RAM は保存されたままです。 bl31でウォームブートパスを実行するようにsplのコードを変更し、カーネルへの起動に成功しました。 しかしその後、カーネルが詰まってしまい、以下の通りの「最新のログ」が確認できます。 2つのCASEで何が違うのか気になります。 - CASEノーマルサスペンド:(保持vdd_soc) - Case Abnormal(vdd_soc オフ) この場合、M33の起動時に何か再初期化するために別のことをすべきでしょうか? [2026-07-06 10:39:55.070]通知: BL31: ウォームレジュームNSコンテキストが復元されました [2026-07-06 10:39:55.074][ 1018.529356][T3251] its_restore_enable+0x0/0x1ac を呼び出しています [2026-07-06 10:39:55.080][ 1018.529356][T3251] cpu_pm_resume+0x0/0x5c を呼び出しています [2026-07-06 10:39:55.084][ 1018.529356][T3251] kvm_resume+0x0/0x68 を呼び出しています [2026-07-06 10:39:55.089][ 1018.529356][T3251] irq_gc_resume+0x0/0x110 を呼び出しています [2026-07-06 10:39:55.094][ 1018.529356][T3251] irq_pm_syscore_resume+0x0/0x24 を呼び出しています [2026-07-06 10:39:55.100][ 1018.529356][T3251] timekeeping_resume+0x0/0x188 を呼び出しています [2026-07-06 10:39:55.105][ 1018.529356][T3251] sched_clock_resume+0x0/0xd0 を呼び出しています [2026-07-06 10:39:55.110][ 1018.529619][T3251] ブート以外のCPUを有効にする... [2026-07-06 10:39:55.142][ 1018.559214][T0] CPU1でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3: CPU1: 再分配器100の領域0:0x0000000048080000が見つかりました [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1: 起動済みのセカンダリプロセッサ0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1が起動しました [2026-07-06 10:39:55.191][ 1018.608610][T0] CPU2でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3: CPU2: 再分配器200の領域0:0x00000000480a0000が見つかりました [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2:起動されたセカンダリプロセッサ0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2が起動しました [2026-07-06 10:39:55.240][ 1018.657836][T0] CPU3でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3: CPU3: 再分配器300領域0:0x00000000480c0000が見つかりました [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3: 起動された二次プロセッサ0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3が起動しました [2026-07-06 10:39:55.289][ 1018.707065][T0] CPU4でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3: CPU4: 再分配器400領域0:0x00000000480e0000が見つかりました [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4:セカンダリプロセッサ0x0000000400起動 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4が起動しました [2026-07-06 10:39:55.339][ 1018.756298][T0] CPU5でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3: CPU5: 再分配器500領域0:0x0000000048100000が見つかりました [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5:起動したセカンダリプロセッサ0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5が起動しました [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-ライフサイクル rpmsg-lifecycle: PM: 呼び出し rpmsg_lifecycle_resume_noirq @ 3251、親: プラットフォーム [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle: PM: rpmsg_lifecycle_resume_noirq が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.383][ 1018.802181][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] @ 3251 を呼び出し中、親プロセス: 49000000.bus [2026-07-06 10:39:55.394][ 1018.812966][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] が 60 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 3 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 42000000.bus [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 44000000.bus [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 4 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.interrupt-controller:PM: genpd_resume_noirq @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM: GENPD_RESUME_NOIRQ dev=4b0b0000.interrupt-controllerドメイン=display タスク=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD ディスプレイ ドメイン=13 状態=オン タスク=kworker/4:5 pid=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram ログにはエラーは記録されていませんが、a55はそこで停止してしまいます。 通常の場合(vddsoCを切らさずに)、そのまま動作を続けます スリープモードでの消費電力を減らそうとしているので、この方法でvddsocをオフにしつつRAMは残しています。 Re: imx95 turn off vdd_soc when suspend to ram ログにはエラー情報がないようです。電圧を遮断するかどうかによって、消費電流に差が生じる可能性があります。消費電力に違いを感じますか?また、VDDSOCをオフにしたい理由は何ですか? Re: imx95 turn off vdd_soc when suspend to ram こんにちは@thinkembedsw VDD_SOC(および関連するデジタル電源)電圧は、「サスペンドモード」電圧まで低下します。直接電源を切ることはサポートしていません BR
查看全文
imx6 jtag random Invalid ACK (7) in DAP response Hi everyone, I'm still picking at the mazda cmu and I've already been able to connect to jtag, but there's a problem. After initializing the memory, the chip stops responding to jtag commands after a while, and openocd resets the connection accordingly. If I do everything quickly and try to download the compiled project from eclipse, I get a bunch of: Error: timeout waiting for DSCR bit change Error: Error waiting for InstrCompl=1 Error: Error waiting for cortex_a_exec_opcode and the subsequent loss of communication. I tried initializing the APB-AP registers with the command imx6d.dap apcsw 1 0 and disabling wdog, but it didn't help. I have attached archive with my configs and log. i.MX6Dual Re: imx6 jtag random Invalid ACK (7) in DAP response Hello, I suggest you check directly with manufacturer. If you are not able to debug the device, may have secure JTAG debug enabled. Best regards. Re: imx6 jtag random Invalid ACK (7) in DAP response Hello. Visteon is not particularly willing to share information, but Mazda is... It does not introduce reverse engineering of its devices at all, as explicitly stated in the license agreement. secure jtag is most likely not enabled because I can initialize the memory and perform operations with it. it seems to me that the problem is in openocd or in the second core, which is not affected by the halt state.
查看全文