IARデバッグ中のHAL_RpmsgMcmgrInit()タイムアウトに関する質問 こんにちは、 IARを使ってKW47アプリケーションをデバッグしている際のNBU Core初期化に関する問題についてお伺いしたいと思います。 環境 ボード：カスタムKW47ボード SDK バージョン: 26.03.00 ARM用IAR組み込みワークベンチ:9.60.3 デバッグプローブ: CMSIS-DAP リセット設定：ハードウェアリセット 実行先: main 参考として、IARデバッガーの設定画面のスクリーンショットを添付します。    観察された行動 IARで「ダウンロードとデバッグ」を実行した後、ハードウェアリセットを実行せずに「Go」を押すと、BLE初期化中にASSERTが発生します。 問題の原因を突き止めたところ、以下の呼び出しシーケンスにたどり着きました。   APP_InitBle() ->PLATFORM_InitMulticore() -> HAL_RpmsgMcmgrInit() kStatus_HAL_RpmsgTimeout を返します -> assert(false) しかし、以下の手順を実行すると、 ダウンロードとデバッグ ハードウェア・リセット GO アプリケーションは通常通り開始され、ASSERTは発生しません。 私たちの仮説 観察された挙動に基づき、以下の一連の事象が発生している可能性があると推測されます。 ダウンロードを開始します。 ダウンロードが完了すると、デバッガーが完全に接続される前にNBU Coreの実行が開始されます。 デバッガが接続されると、Cortex-M33 CoreはResetHandlerに戻ります。 しかし、NBUコアは引き続き稼働している。 その結果、Cortex-M33コアとNBUコアが同期しなくなります。 HAL_RpmsgMcmgrInit()が実行されると、RPMsg/MCMGRの初期化ハンドシェイクが完了できず、kStatus_HAL_RpmsgTimeoutが返されます。 ハードウェアリセット後、Cortex-M33コアとNBUコアの両方がリセットされ、初期化が正常に完了します。 質問 上記の理解と仮説は正しいでしょうか？ IARでKW47アプリケーションをデバッグする際、Cortex-M33コアとNBUコアが実行開始前に適切に同期されていることを確認する推奨手順はありますか? 再開まで今しばらくお待ちください。 よろしくお願いします、 ヒヤマ プロトコル：BLE→コネクティビティ Re: Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging こんにちは、 @hyama 私たちにCASEを作ってくれてありがとう。 質問に答える前に、NBUバージョンがSDKsバージョンと一致しているか確認してもらえますか? もし確信が持てない場合は、SDKディレクトリにあるNBUの更新を手伝ってください:mcuxsdk\middleware\wireless\ble_controller\bin\kw47_nbu_ble_hosted.bin NBUのフラッシュ方法については、以下を参照してください: (1) KW47およびMCX W72のNBUファームウェア更新方法 - NXPコミュニティ NBUをSDKで同じバージョンにアップグレードした後、試してみてください。 BR、 Christine。 Re: Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging こんにちは、 @Christine_Li さん。 ご返信よろしくお願いします。 SDKバージョン26.03.00に付属するNBUファームウェアはすでにプログラム済みです。 しかし、NBUファームウェアが正しく書かれているのか、あるいは現在動作中のNBUファームウェアバージョンがSDKバージョンと実際に一致しているのかはまだ確認されていません。 デバイスに現在インストールされているNBUファームウェアのバージョンを確認する方法はありますか？ NBUファームウェアのバージョンを検証する推奨方法があれば、ぜひ教えてください。 よろしくお願いいたします。 ヒヤマ Re: Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging こんにちは、 @hyama 通常、私が提供したリンクをクリックして正常に完了した場合、NBUのアップデートは成功したと判断します。念のため、 NBU 情報を取得するために、次の API を提供します: int PLATFORM_GetNbuInfo(NbuInfo_t *nbu_info_p);。 当初のご質問を解決に向けて進めるため、以下の情報をお伺いしたいと思います。 もしKW47-EVKまたはKW47-LOCボードをお持ちなら、同じ問題が起きていないか試してみていただけますか?1.Do 2. SDKリリースのデフォルト例を使いましたか?あるいは、弊社のサンプルコードを基に何か変更を加えましたか？ 3. ハードウェアリセットを使わず、IARでソフトウェアリセットした場合、この問題は再現できるのでしょうか? BR、 Christine。 Re: Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging こんにちは、 @hyama あなたの側では今はどうですか？ 私の提案を試してみましたか？ BR、 Christine。 Re: Question Regarding HAL_RpmsgMcmgrInit() Timeout During IAR Debugging こんにちは、 @Christine_Li さん。 遅れて申し訳ありません。まだ試す機会がなかったので、来週から取り組んでみる予定です。 BR、 ヒヤマ。

关于 S32K328 生命周期转换期间的硬故障和 UTEST 编程的咨询 你好， 我们在使用 HSE 固件 2.40.0 (AB_SWAP) 对 S32K328 执行 IVT 熔丝和生命周期转换时遇到了 HardFault。我们希望您能协助调查此事。 1. 开发环境 MCU：S32K328 HSE固件：S32K358_HSE_FW_2.40.0 (AB_SWAP)   2. 问题描述 我们实现了一个功能，该功能按顺序执行 IVT 熔丝，然后进行生命周期转换到 IN_FIELD。 在测试过程中，我们观察到以下现象： 第一次函数调用期间发生硬故障。MCU 复位后，我们确认 IVT 熔丝已完成，但生命周期并未改变。 当再次调用同一函数时，又发生了一次 HardFault。MCU RESET 后，我们确认生命周期已更改为 IN_FIELD。 目前我们已确定的Hse_Ip_ServiceRequest函数、其子函数以及相关数据的内存放置情况如下： 004117a4+000378 .mcal_text Hse_Ip.o 21006cac+000008 .mcal_bss Hse_Ip.o 00411ca8+000008 .mcal_const Hse_Ip.o 00411b1c+00003e .mcal_text OsIf_Timer.o 以上信息仅涵盖目前已确定的项目。可能还涉及其他下属功能和相关数据。 作为参考，我们的测试环境配置为单核裸机系统，使用同步服务请求。除了服务请求之外，此过程中不会执行其他任何操作。 我们之前在 S32K314 上执行过同样的操作，并且成功完成，没有任何问题。虽然具体的内存布局有所不同，但当时的代码也位于 Flash Block 0 中。 3. 问题 问题1：UTEST编程过程中是否存在闪存读写冲突（RWW）的可能性 我们怀疑在 HSE 于 IVT 熔丝或生命周期转换期间对 UTEST 区域进行编程时可能会发生 RWW 冲突，而该转换是通过HSE_SRV_ID_SET_ATTR服务执行的。具体来说，主机核心可能正在执行 Flash Block 0 中的代码，而 HSE 正在对 UTEST 进行编程，从而导致 RWW 冲突，并随后发生硬故障。 请问这是否是对观察到的现象的一种合理解释？ 另外，能否确认 UTEST 区域是否与 S32K328 上的 Flash Block 0 属于同一个 RWW 分区？ Q2. 复位后硬故障原因的识别和诊断方法 RESET 后 由于每次执行 IVT 熔丝和生命周期转换时，MCU 的生命周期状态都可能发生变化，因此反复使用新的 MCU 样本进行根本原因分析并不实际。 因此，我们想澄清以下几点： 在发生 HardFault 时，是否有任何寄存器或状态信息可用于识别是否发生了 RWW 冲突并确定其原因？ 在发生硬故障后，MCU RESET 时，此错误信息是否会保留？ RESET后，是否可以通过闪存控制器状态寄存器、RWW 错误状态寄存器或其他诊断方法来识别故障原因？ 如果可以，请提供需要检查的相关寄存器名称和位字段。 Q3. 发生 RWW 冲突时，代码执行受到限制的内存区域 如果 Q1 中描述的疑似 RWW 冲突是实际原因，我们希望确定在 IVT 熔丝和生命周期转换期间代码执行受到限制的具体内存区域，因为 Flash Block 0 的地址范围相对较大。 能否提供以闪存扇区为单位的受限内存区域（每个扇区 0x2000 字节）？ 这将有助于我们区分 Flash Block 0 中允许代码执行的区域和在执行相关服务时限制代码执行的区域。 Q4. 需要重定位到 SRAM 或其他闪存块以防止 RWW 冲突的代码 如果 Q1 中描述的疑似 RWW 冲突是实际原因，我们正在考虑将相关代码移至 SRAM 或其他 Flash 块以防止出现此问题。 假设所有生命周期转换服务请求都是同步执行的，那么仅将Hse_Ip_ServiceRequest函数及其子函数迁移到 SRAM 或其他 Flash 块是否就足够了？ 或者，调用 Hse_Ip_ServiceRequest 的函数是否 也需要重新定位？ 此外，在函数执行或中断服务例程 (ISR) 期间引用的任何常量数据是否也应放置在 SRAM 或其他 Flash 块中？ 我们恳请您审阅并指导我们，以帮助我们找出问题的根本原因并防止此类问题再次发生。 感谢您的支持。 Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 嗨，卢卡斯， 感谢您的详细解释。 请查看下方所需信息。 1. RTD 版本 SW32K3_S32M27x_RTD_4.4_4.0.0_HF04_D2504 2. OSIF 模式 当前测试代码配置为使用虚拟计数器（OSIF_COUNTER_DUMMY）。但是，此配置仅用于测试目的，实际应用中可能会有所不同。 因此，能否请您提供一份完整的列表，列出在 UTEST 编程期间需要迁移到 RAM 中的所有函数和资源，涵盖所有支持的 OSIF 模式，而不仅仅是当前的虚拟计数器配置？ 3. Hse_Ip_apMuBase 内存放置 我们检查了 Hse_Ip.c通过源代码发现，Hse_Ip_apMuBase 的声明使用了以下内存映射宏： #define CRYPTO_START_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" /*! @brief Array of MU base pointers */ static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS; #define CRYPTO_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" 这与您提供的代码片段不同，该代码片段使用了 CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED 和 Crypto_43_HSE_MemMap.h。 我们还检查了映射文件，并确认 Hse_Ip_apMuBase 位于 .mcal_const 文件中。Flash Block 0 内的部分，地址如下： .mcal_const 00411ca8+000008 Hse_Ip_apMuBase 基于此，即使 Hse_Ip_ServiceRequest 函数本身被重新定位到 RAM 中，在 UTEST 编程期间访问 Hse_Ip_apMuBase 也可能导致 RWW 冲突。 请您检查一下，考虑到所有支持的 OSIF 模式，我们的 RTD 版本需要将哪些具体功能和资源迁移到 RAM 中？ 4. 关于RWW冲突的其他问题 关于此问题的可复现性和条件，我还有几个问题。 4.1.使用相同内存布局实现可复现性 如果另一台 S32K328 配置了相同的固件和内存布局，是否还会持续出现同样的 RWW 冲突？ 换句话说，如果满足 RWW 冲突的条件，我们是否应该预期该问题会在配置相同的不同 S32K328 设备上重现？ 4.2.内存布局差异的影响 即使相关代码和数据位于 Flash Block 0 中，它们的具体内存地址或位置的差异是否会影响 RWW 冲突的发生？ 例如，改变 Hse_Ip_ServiceRequest、其调用的函数或它们访问的数据的位置是否可以避免该问题？ 4.3.执行时机的影响 即使固件和内存布局相同，RWW 冲突的发生是否取决于服务请求的时机或其他执行条件？ 具体来说，冲突是否仅在主机核心尝试在 UTEST 编程进行期间访问 Flash Block 0 时发生？ 4.4.可重复性和发生频率 这个问题是在特定条件下确定性的，还是会根据执行时间间歇性地发生？ 换句话说，如果在相同条件下重复相同的操作，我们是否应该预期每次都会出现该问题，还是每次尝试出现该问题的情况可能有所不同？ 5. MCSR 注册和 RWE 标志 您提到当发生 RWW 冲突时，Flash MCSR 寄存器中的 RWE 标志会被设置。但是，我在参考手册中找不到名为 MCSR 的寄存器。 请问您指的是附件图片中显示的 MCRS 登记册吗？ 具体来说，我们是否应该检查第 20 位（地址：0x402EC004）的 RWE 位，以确定是否发生了 RWW 冲突？ 感谢您的支持。 Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 嗨@wodudwo 是的，你描述的行为很可能是由 RWW 冲突引起的。 在 S32K328 上，UTEST 和 Flash Block 0 属于同一个 RWW 分区。 另请参阅此帖子，其中我解释了调用 Hse_Ip_ServiceRequest() 时需要将哪些资源重新定位到 RAM 中： https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/m-p/2369325/highlight/true#M58774 需要重新定位的具体功能取决于所使用的 OSIF 模式，并且 RTD 版本之间也可能存在差异。 还有一点需要检查。根据 RTD 版本不同，Hse_Ip_ServiceRequest() 使用的 Hse_Ip_apMuBase 数组可以声明为常量，因此可以放置在 Flash 中： #define CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED #include "Crypto_43_HSE_MemMap.h"   /*! @brief MU 基指针数组 */ static MU_Type* const Hse_Ip_apMuBase[HSE_IP_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_43_HSE_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_43_HSE_MemMap.h" 如果 CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED 位于受影响的物理 Flash Block 0 中，则在限制期间访问此阵列仍会导致 Flash 读取。 作为一种变通方法，可以使用 CRYPTO_43_HSE_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE 将数组移动到 RAM 中，并移除 const 限定符。 我已经提交了一个功能请求，要求在 Hse_Ip 驱动程序中添加对 UTEST 编程的支持，因为当前的实现方式可能会导致此类问题。 如果您能告诉我您使用的RTD版本以及配置的OSIF模式（您是否使用OSIF_COUNTER_DUMMY？），我可以准确地检查哪些功能和资源需要迁移。 如果发生 RWW 冲突，则应设置 Flash MCSR 寄存器中的 RWE 标志。请注意，RESET后此信息将不会保留。 当 HSE 对 UTEST 进行编程时，既无法读取 UTEST 区域，也无法读取整个 Flash Block 0。 因此，推进生命周期、启用 IVT 授权以及其他发出触发信号以进行 UTEST 编程的操作应在受控环境中执行。我建议在这些操作期间禁用中断。否则，中断处理程序使用的所有资源也需要位于另一个可访问的 Flash 块中或 RAM 中。 此致， Lukas Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 为了从 RAM 同步执行 Hse_Ip_ServiceRequest()，请将以下函数放置在 RAM 中： Hse_Ip_ServiceRequest() OsIf_MicrosToTicks() OsIf_GetCounter() OsIf_GetElapsed() 此外，将所选 OSIF 超时实现的功能放置在 RAM 中： 虚拟 OSIF：OsIf_Timer_Dummy_MicrosToTicks()、OsIf_Timer_Dummy_GetCounter() 和 OsIf_Timer_Dummy_GetElapsed()。 系统 OSIF：OsIf_Timer_System_MicrosToTicks()、OsIf_Timer_System_GetCounter()、OsIf_Timer_System_GetElapsed()，以及选定的系统定时器后端函数。 自定义 OSIF：OsIf_Timer_Custom_MicrosToTicks()、OsIf_Timer_Custom_GetCounter() 和 OsIf_Timer_Custom_GetElapsed()。 MU 访问函数和内存屏障是内联代码。同步请求路径不使用 OsIf_Interrupts.c。 本RTD中，Hse_Ip_apMuBase被定义为一个常量： #define CRYPTO_START_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h"   /*! @brief MU 基指针数组 */ static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" 所以，改成： #define CRYPTO_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE #include "Crypto_MemMap.h"   /*! @brief MU 基指针数组 */ static MU_Type* Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_STOP_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE #include "Crypto_MemMap.h" 关于可复现性——如果启动条件始终完全相同（这意味着简单的顺序代码，没有中断等），您应该会看到相同的结果。这是因为缓存的数据和代码相同，闪存读取缓冲区处于相同的状态等等。 如果存在任何不确定性，您可能会看到不同的结果。例如，我遇到过这样的情况：客户没有收到硬故障，但生命周期信息没有正确存储到 UTEST 中，RESET 后设置了 LC_ERR 标志（生命周期扫描错误）。这意味着必须按照上述方式，从 RAM 或其他闪存块运行该代码。 抱歉，我打错了，应该是模块配置状态 (MCRS)。 此致， Lukas

NXP RTD SDKインストール問題:Linkフォルダが見つからないため、EB Tresos Studioとの連携が失敗しました こんにちは、 EB Tresos StudioのインストールからNXP RTD SDKへのパスを提供しているにもかかわらず、EB Tresos Studioとは統合されていません Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found こんにちは、 @VaneB さん。 パスを「C:/EB/Tresos/plugins」に変更しましたが、問題は解決しません。お知らせ下さい。 Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found こんにちは、 @a1g1さん RTDパッケージとEB tresoのリンクを作成する際に指定されているEB tresosのインストールディレクトリがC:\EB\tresos\であることを確認していただけますか? 問題が解決しない場合は、RTDプラグインをC:\EB\tresos\pluginsにコピーしてみてください。 BR、VaneB Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found こんにちは、 @a1g1さん 最後の部分の説明が十分ではなかったかもしれません。RTDパッケージをEB Tresosと連携できない場合は、そのステップを省略してプラグインを手動で追加することもできます。 これを行うには、インストール済みのRTDディレクトリに移動し、すべてのプラグインをコピーして、EB tresosディレクトリC:\EB\tresos\pluginsに貼り付けます。

RT1189 EVK Profinet Demo 扫描设备失败 我正在 RT1189 EVK 上设置 Profinet Demo。按照参考指南 UG10455 和 UG10361，该项目已成功构建，并且我已经将固件烧录到 MCU 中。 配置完 IP 地址并将 ICE 设置为 Profinet 模式后，设备扫描步骤失败。我尝试了 ENET2 和 ENET3，都无法扫描到设备。请问您能否提供故障排除步骤并就此问题提出一些建议？ 此外，我想确认一下刷写固件后是否应该可以通过 J53 获取日志输出，因为我这边没有看到任何日志。 期待您的尽快回复。谢谢。 Re: RT1189 EVK Profinet Demo scan device failed 嗨，雪莉， 更新最新信息： 1.我已经重新导入了 v26.06-LTS 版本SDK，并根据文档应用了所需的配置——启用 EDMA，并在 mcuxsdk\devices\RT\RT1180\MIMXRT1189\MIMXRT1189_cm33_features.h 中实现了几个 NETC 勘误表的变通方案。 我还向 sysbuild.cmake 文件中添加了以下路径：projects/goal_pnio_rpc/31_led_button/vsc/nxp/mimxrt1180_evk_cm7_rtos 项目构建成功。我使用 MCUXpresso Secure Provisioning Tool v26.06 将固件刷写到板上，并通过以太网线将 PC 连接到 EVK 的 ENET2\ENET3 端口。然而，设备扫描仍然失败。 2. 文档 UG10455 规定需要 SDK v26.06，但同一文档中的示例屏幕截图和随附说明指的是 v26.03。我想确认一下哪个版本应该作为官方参考版本。供您参考，我最初使用 SDK v26.03 进行测试时也遇到了同样的设备扫描失败问题。 期待您的尽快回复。谢谢。 顺祝商祺！ 钱德勒 Re: RT1189 EVK Profinet Demo scan device failed 嗨，雪莉， 感谢您的回复，我目前使用的是SDK 版本 V26.03。我会尝试使用 SDK V26.06，但是没有 V26.06 版本，所以我选择了 V26.06-LTS，这样对吗？   我想知道是否可以使用 SDK_26_06_00_MIMXRT1180-EVK.zip 作为 SDK 仓库，并成功构建 profinet_project？根据文档，该工具下载SDK需要很长时间。 顺祝商祺！ 钱德勒 Re: RT1189 EVK Profinet Demo scan device failed 亲爱的@ChandlerY ， 感谢您对RT1180的提问。 请与我们联系，告知您使用的是哪个SDK版本？此依赖项的版本为 26.06： 如果您使用的是 26.09 版本，请尝试使用 26.06 版本。 请提供您的SDK版本，以便我们进一步确认。谢谢你！ 顺祝商祺！ 雪莉

Raspberry Pi 5とのOM-SE050ARD-E統合のサポート NXPからEdgleLock SE050Eキットを購入し、Raspberry Pi 5で評価する予定です。オンラインドキュメント(EdgeLock SE05xクイックスタートガイド、Raspberry Pi対応)の手順に従い、EdgeLockキットとRaspberry Piボード間はSDA、SCL、VCC、GNDのみを接続し、2.1.2.2節のOM-SE05xARDへの配線コネクテッドで説明しています。Raspberry Pi ボードのセットアップ手順はすべて正常に完了しましたが、3.4 EdgeLock SE Plug & Trust Middleware テスト例の実行から se05x_minimal を実行するとエラーのみが表示されます。i2cdetect -y 1 を実行しても、SE050E の I2C アドレスを確認できません。 このキットをRaspberry Piで使用する際に、注意すべきジャンパー設定はありますか？ Raspberry PiボードからSE050Eチップへ、別の配線を使ってイネーブル/リセットピンを供給する必要もありますか？ ありがとう、 ルシアン SE050 Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 こんにちは、 Arduino Unoボードで基本的なi2cdetectの例をテストしたところ、スクリーンショットに示されているようにSE050デバイスがアドレス0x48で応答しているのが確認できます。 Raspberry Piの外部配線セットアップでは、SE050-EのENとRSTピンも何かに繋ぐ必要がありますか?Raspbery PiからSE050とはまだ通信できません。 ありがとうございます ルシアン Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 こんにちは、共有されたコマンドを使おうとしましたが、まだデバイスが表示されません。 ボードがRaspberry Piにコネクテッドされている様子やジャンパーの設定の写真を添付しました。動作させるために何か変更が必要なのかもしれません。もしそうなら教えてください。 その間に、SE050-EはデフォルトでArduino用に設計されているため、Arduinoボードでテストする予定です。 ありがとう、 ルシアン Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 こんにちは、 @lpsylux さん。 デバイスを再度検出するために、以下のコマンドを試していただけますでしょうか？ i2cdetect -y -a -q 1 デバイスが /dev/i2c-2 のような別のポートに接続されている場合は、代わりに i2cdetect -y -a -q 2 を使用してください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 また、SE050ボードのRSTやENAピンをRaspberry Piボードの特定の電圧に外部設定する必要があるかどうかも教えてください。 ありがとう！ Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 Arduinoのセットアップで住所0x48が表示されていることを確認するファイルを添付するのを忘れていました。 Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 こんにちは、 @lpsylux さん。 OM-SE050ARD-EとRaspberry Piの接続に関する詳細は以下を参照してください。また、 https://www.nxp.com/docs/en/application-note/AN12570.pdfのセクション2.1.1に従ってOM-SE050ARD-Eのジャンパー設定を確認してください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: Support for OM-SE050ARD-E integration with Raspberry Pi 5 こんにちは、 お返事ありがとうございます。i2c-2に切り替え、i2detectコマンドを実行するとSE050アドレス0x48が見えました。その後、いくつかの設定を変更してi2c-1をピンに正しく設定し、今ではi2c-1も動作しています。 サンプルを実行すると、以下のエラーメッセージが表示されます（スクリーンショットにも表示されています）。 Failed to open GPIO value file : No such file or directory Failed to unexport GPIO : Invalid argument Failed to unexport GPIO : Invalid argument それらは予想されていたものですか？Raspberry PiからSE050までI2Cコマンドしか使われていないので、これらのコマンドが実行されないように何か変更を加えるべきでしょうか? ありがとうございます。 ルシアン

i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi Team, We are using a custom i.MX95 board with the OV5640 camera sensor and are facing an issue when the camera is connected to CSI1 on Android Automotive 16. The hardware design has already been validated: - CSI0 and CSI1 work correctly with Linux 6.18.20. - CSI0 and CSI1 also work correctly with Android 16 based on Linux 6.18.20. - The issue is observed only with Android Automotive 16 based on Linux 6.18.20. Observations: - CSI0 works without any issues. - CSI1 fails to start streaming. - We tested CSI1 independently. - We also disabled NEO ISP and tested with the ISI pipeline only, but the issue persists. Observed errors: LIBCAMERA: Failed to start streaming: Connection timed out LIBCAMERA: 'mxc_isi.0': Unable to set format on pad 0/0: Device or resource busy Log and media-ctl validation results are attached for reference. Has anyone encountered a similar CSI1 issue on i.MX95 EVK or Android Automotive 16? Any suggestions, fixes, patches, or confirmation of CSI1 validation on the EVK would be greatly appreciated. Thanks, Maruti Naik Evaluation Board Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi, We have verified that the kernel DTS configuration is correct. The current Android Automotive 16 BSP is also based on Linux 6.18.20, and the same DTS configuration is working without any issues in the Linux 6.18.20 BSP. We have also successfully tested and validated the CSI1 with OV5640 camera in Android Automotive 15 BSP. Could you please confirm whether there are any restrictions or limitations on CSI1 camera support in the latest Android Automotive 16.0.0_2.1.0 BSP? Are any additional changes required to enable CSI1 camera support in this release? Kindly clarify. Regards, Maruti Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I checked AAOS, which support csi0 as default, current bsp doesn't support mipi dsi/csi for camera, you should change the dts, camera configure, did you change anything? if yes, share the detailed your changed steps and code Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi @joanxie Any update on this issue? Kindly share your findings or provide some technical guidance to help us resolve the CSI1 camera issue. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie  Yes, our B0 board design is based on the NXP i.MX95 19x19 EVK. For your information, the same hardware is working with Linux 6.18.20 and Android 16 based on Linux 6.18.20. Both CSI0 and CSI1 (CSI-DSI combo) are working with dual OV5640 cameras. We are using Android Automotive 16.0.0_2.1.0 (based on 6.18.20_2.0.0 BSP), which uses the same kernel version and kernel configurations. However, with the Android Automotive 16.0.0_2.1.0 BSP, the OV5640 camera is working on CSI0, but the OV5640 camera on CSI1 (CSI-DSI combo) is not working. The logs have already been shared. We currently do not have an i.MX95 B0 EVK board available (we have an A1 EVK board), so we are unable to test this on the EVK. It would be helpful if you could test the CSI1 (CSI-DSI combo) with any supported camera on the NXP i.MX95 19x19 EVK B0 board using the latest Android Automotive 16 BSP and share your findings. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi Maruti did your board design based on imx95 evk board? if yes, did you reproduce this on nxp imx95 evk board? and what detailed auto android 16 bsp version? 1.1.0 or 1.3.0? B.R. Joan Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I will double confirmed this from android auto team again, but they didn't say auto android 16 has any limitation before, based on your test result, it seems this issue is related to the auto android 16 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi, In our testing, on the Android Automotive 15 BSP, both CSI0 and CSI1 cameras worked correctly with both the Car image (EVS running on the M7 core) and the Car2 image (EVS running on the A55 core). On Android Automotive 16 BSP, with the Car image (EVS running on the M7 core), CSI0 works, but CSI1 does not. However, with the Car2 image (EVS running on the A55 core), both CSI0 and CSI1 work correctly. Could you please check if any background process in the Car image is accessing or holding CSI1, preventing the camera from working? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie, I have one update regarding the CSI1 camera issue. With the Car2 image, both CSI0 and CSI1 cameras are working fine. However, with the Car image, we are still facing an issue getting the CSI1 camera working. Kindly help us investigate and resolve the CSI1 camera issue in the Car image. Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie, Thank you for your support. Could you please provide any workaround or patch to enable CSI1 (DSI-CSI combo) support for camera validation on Android Automotive 16.0.0_2.1.0? Your assistance would be highly appreciated. Best regards, Maruti Naik Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Dear @joanxie We are currently using the Car image and are not focusing on EVS for now. Our requirement is to enable and validate the CSI1 camera directly through the Camera application. Kindly help us resolve the CSI1 camera issue Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue I don't think auto android team tested csi1 before, since the default is for csi0 only,  did you need EVS and Camera APK functions ? and did you use Car2 image type? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue what do you mean car2 image? do you mean with  EVS in Arm Cortex-A core? since you tested on auto android 15 successfully, what do you test on auto android 15？ do you mind sharing your patches to double check? Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue could you give me the two log files for car2 and car image? only for  csi1, and could you try  try to use the same CM7 FW version from AA15 to AA16.0 2.1.0?  Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue Hi, We were able to isolate the issue. It was caused by the rearview camera demo running on the M7 core in the CAR image. We have identified the code causing the CSI1 busy error and isolated it for now. We also confirmed that both cameras are working in the Camera app and evs_app with dual-camera support. Regards, Maruti

RT1189 EVK Profinetデモスキャンデバイスが失敗しました RT1189 EVK上でProfinetのデモをセットアップしています。プロジェクトはリファレンスガイドUG10455とUG10361に従って無事に構築され、私はMCUにファームウェアをフラッシュしました。 IPアドレスを設定し、ICEをProfinetモードに設定した後、デバイスのスキャン手順が失敗しました。ENET2とENET3の両方を試しましたが、どちらもデバイスのスキャンに失敗しました。トラブルシューティングの手順や、この問題に関するアドバイスをいただけますか? さらに、ファームウェアの書き換え後、J53経由でログ出力が利用可能になるはずかどうか確認したいのですが、私の環境ではログが全く表示されません。 迅速なご返信をお待ちしております。ありがとう。 Re: RT1189 EVK Profinet Demo scan device failed こんにちは、シェリーさん。 最新情報を更新してください。 1.v26.06-LTSを再インポートしましたSDKを適用し、ドキュメントに従って必要な設定を適用しました。例えば、EDMAの有効化や、mcuxsdk\devices\RT\RT1180\MIMXRT1189\MIMXRT1189_cm33_features.hでいくつかのNETC ERRATA回避策を実装しました。 また、sysbuild.cmake ファイルに次のパスを追加しました: projects/goal_pnio_rpc/31_led_button/vsc/nxp/mimxrt1180_evk_cm7_rtos プロジェクトは正常に構築されました。MCUXpresso Secure Provisioning Tool v26.06を使ってファームウェアをボードにフラッシュし、PCをEVKのENET2/ENET3ポートにイーサネットケーブルでコネクテッドしました。それにもかかわらず、デバイスのスキャンは依然として失敗する。 2. ドキュメントUG10455ではSDK v26.06が必要と明記されていますが、同じドキュメント内の例のスクリーンショットや説明はv26.03を指しています。どちらのバージョンを公式の参考資料とすべきか確認させてください。参考までに、私も最初にSDK v26.03でテストしましたが、同じデバイススキャンの失敗に直面しました。 迅速なご返信をお待ちしております。ありがとう。 よろしくお願いいたします。 チャンドリー Re: RT1189 EVK Profinet Demo scan device failed こんにちは、シェリーさん。 ご返信ありがとうございます。私はSDKバージョンV26.03を使っています。SDK V26.06を試してみますが、v26.06がないのでv26.06-LTSを選びました。これで合っていますか?   そして、SDK_26_06_00_MIMXRT1180-EVK.zipをSDKリポジトリとして使って、profinet_projectビルディングを成功させることは可能でしょうか?ドキュメントごとにSDKをダウンロードするのに時間がかかります。 よろしくお願いいたします。 チャンドリー Re: RT1189 EVK Profinet Demo scan device failed @ChandlerY様、 RT1180に関するご質問ありがとうございます。 どのSDKバージョンを使っているのか教えていただけますか?この依存関係のバージョンは26.06です。 バージョン26.09をご利用の場合は、代わりに26.06をお試しください。 SDKのバージョンを教えていただければ、さらに確認いたします。ありがとう！ よろしくお願いいたします。 シェリー

i.MX95 Android Automotive 16 CSI1 Ov5640 摄像头问题 大家好， 我们正在使用定制的 i.MX95 板和 OV5640 摄像头传感器，当摄像头连接到 Android Automotive 16 上的 CSI1 时，我们遇到了问题。 硬件设计已经过验证： - CSI0 和 CSI1 在 Linux 6.18.20 下工作正常。 - CSI0 和 CSI1 在基于 Linux 6.18.20 的 Android 16 上也能正常工作。 - 该问题仅在基于 Linux 6.18.20 的 Android Automotive 16 中出现。 观察结果： - CSI0 运行正常，没有任何问题。 - CSI1 无法开始播放。 - 我们对 CSI1 进行了独立测试。 - 我们还禁用了 NEO ISP，仅使用 ISI 管道进行了测试，但问题仍然存在。 观察到的误差： LIBCAMERA：启动流媒体失败：连接超时 LIBCAMERA：'mxc_isi.0'：无法在 0/0 号焊盘上设置格式：设备或资源忙 日志和 media-ctl 验证结果已附上，供参考。 有人在 i.MX95 EVK 或 Android Automotive 16 上遇到过类似的 CSI1 问题吗？任何建议、修复方案、补丁或关于 EVK 上 CSI1 验证的确认信息都将不胜感激。 谢谢， 马鲁蒂·奈克 评估板 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你好， 我们已验证内核 DTS 配置正确。当前的 Android Automotive 16 电路板支持包。也基于 Linux 6.18.20，相同的 DTS 配置在 Linux 6.18.20 电路板支持包。中运行没有任何问题。 我们还成功地在 Android Automotive 15 电路板支持包中测试并验证了配备 OV5640 摄像头的 CSI1。 请问最新的 Android Automotive 16.0.0_2.1.0 版本对 CSI1 摄像头的支持是否存在任何限制？电路板支持包。？此版本是否需要进行任何其他更改才能启用 CSI1 摄像头支持？ 请予以澄清。 问候， 马鲁蒂 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我检查了AAOS，它默认支持csi0，但当前的电路板支持包。不支持摄像头的mipi dsi/csi，你应该修改dts和摄像头配置，你修改过什么吗？如果可以，请分享您修改后的详细步骤和代码。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 嗨@joanxie 关于这个问题有任何进展吗？请分享您的发现或提供一些技术指导，以帮助我们解决 CSI1 摄像头问题。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie 是的，我们的 B0 板设计基于 NXP i.MX95 19x19 EVK。 供您参考，同样的硬件在 Linux 6.18.20 和基于 Linux 6.18.20 的 Android 16 上都能正常工作。CSI0和CSI1（CSI-DSI 组合）均使用双 OV5640 摄像头。 我们使用的是Android Automotive 16.0.0_2.1.0 版本。（基于 6.18.20_2.0.0 BSP），它使用相同的内核版本和内核配置。 然而，Android Automotive 16.0.0_2.1.0电路板支持包，OV5640 摄像头在CSI0上工作正常，但CSI1（CSI-DSI 组合）上的 OV5640 摄像头无法工作。日志已经共享。 我们目前没有 i.MX95 B0 EVK 板（我们有 A1 EVK 板），所以我们无法在 EVK 上进行测试。 如果您能使用最新的 Android Automotive 16 电路板支持包。 在 NXP i.MX95 19x19 EVK B0 板上，对任何支持的摄像头测试CSI1（CSI-DSI 组合） ，并分享您的测试结果，那将非常有帮助。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 您好， 马鲁蒂 你的板设计是基于imx95 evk板吗？如果是，您是否在 nxp imx95 evk 板上重现了此问题？以及具体的安卓16 电路板支持包。版本信息？1.1.0还是 1.3.0 版本？ B.R. 琼 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我会再次向 Android Auto 团队确认，但他们之前并没有说过 Android 16 的 Auto 功能有任何限制。根据你的测试结果，这个问题似乎与 Android 16 的 Auto 功能有关。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie ， 关于CSI1摄像头的问题，我有一个更新。 使用 Car2 图像，CSI0 和 CSI1 摄像头均工作正常。然而，对于汽车图像，我们仍然面临着让 CSI1 摄像头工作的问题。 请协助我们调查并解决车载图像中CSI1摄像头的问题。 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你好， 在我们的测试中，在 Android Automotive 15 电路板支持包。上，CSI0 和 CSI1 摄像头都能与 Car 图像（运行在 M7 内核上的 EVS）和 Car2 图像（运行在 A55 内核上的 EVS）正常工作。 在 Android Automotive 16 电路板支持包。上，使用 Car 映像（EVS 运行在 M7 内核上），CSI0 可以工作，但 CSI1 不能工作。但是，使用 Car2 镜像（EVS 运行在 A55 内核上），CSI0 和 CSI1 都能正常工作。 请检查一下车载系统镜像中是否有后台进程正在访问或占用 CSI1，导致摄像头无法工作？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你说的car2图片是什么意思？您是指在 Arm Cortex-A 内核上使用 EVS 吗？既然您在 Android 15 自动测试版上测试成功了，那么您在 Android 15 自动测试版上测试的是什么？能否分享一下您的补丁以便我再次检查？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 我认为安卓自动开发团队之前没有测试过 CSI1，因为默认设置只针对 CSI0。你需要EVS 和 Camera APK 功能吗？你使用的是 Car2 镜像类型吗？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie ， 感谢您的支持。 请问能否提供任何变通方法或补丁，以在 Android Automotive 16.0.0_2.1.0 上启用对 CSI1（DSI-CSI 组合）的摄像头验证支持？ 非常感谢您的帮助。 此致， 马鲁蒂·奈克 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 亲爱的@joanxie 我们目前正在使用汽车图像，暂时不关注电动汽车。我们的需求是通过 Camera 应用程序直接启用和验证 CSI1 摄像头。 请协助我们解决CSI1摄像头的问题 Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 能否提供一下 car2 和 car image 这两个日志文件？仅适用于 csi1，您能否尝试使用相同的 CM7 固件版本，从 AA15 升级到 AA16.0 2.1.0？ Re: i.MX95 Android Automotive 16 CSI1 Ov5640 Camera Issue 你好， 我们已成功找出问题所在。这是由于 CAR 图像中 M7 内核上运行的后视摄像头演示程序引起的。我们已经确定了导致 CSI1 忙错误的代码，并暂时将其隔离。 我们还确认，两款摄像头在相机应用和 evs_app 中均可正常工作，并支持双摄像头功能。 问候， 马鲁蒂

S32K328におけるライフサイクル移行中のハードフォルトおよびUTESTプログラミングに関する問い合わせ こんにちは、 HSEファームウェア2.40.0（AB_SWAP）を使用してS32K328でIVTフュージングとライフサイクルトランジションを実行中に、ハードフォルトが発生しました。この件の調査にご協力をお願いいたします。 1. 開発環境 MCU:S32K328 HSEファームウェア：S32K358_HSE_FW_2.40.0 (AB_SWAP)   2. 問題の説明 IVT融合を順次実行し、その後IN_FIELDへのライフサイクル遷移を実行する機能を実装しました。 テスト中に、以下の挙動が観察されました。 最初の関数呼び出し中にハードフォルトが発生しました。MCUがリセットされた後、IVT融合は完了したものの、ライフサイクルは変更されていないことが確認されました。 同じ関数が再度呼び出された際、別のハードフォルトが発生した。MCUがリセットされた後、ライフサイクルがIN_FIELDに変更されたことを確認しました。 Hse_Ip_ServiceRequest 関数、その従属機能、およびこれまでに特定した関連データの メモリ配置 は以下の通りです。 004117a4+000378 .mcal_text Hse_Ip.o 21006cac+000008 .mcal_bss Hse_Ip.o 00411ca8+000008 .mcal_const Hse_Ip.o 00411b1c+00003e .mcal_text OsIf_Timer.o 上記の情報は、これまでに特定された項目のみをカバーしています。追加の補助機能や関連データも関係する場合があります。 参考までに、私たちのテスト環境は同期サービス要求を用いたシングルコアのベアメタルシステムとして構成されています。この手順では、サービスリクエスト以外の操作は一切行われません。 以前、S32K314で同様の操作を実施しましたが、問題なく正常に完了しました。詳細なメモリレイアウトは異なっていたものの、当時もコードはフラッシュブロック0に配置されていた。 3. 質問 Q1.UTESTプログラミング中のフラッシュ読み書き(RWW)競合の可能性 HSEがIVT融合中またはライフサイクル遷移中にUTEST領域をプログラミングしている際に、RWW競合が発生する可能性があると推測されます。ライフサイクル遷移はHSE_SRV_ID_SET_ATTRサービスを介して実行されます。具体的には、HSEがUTESTをプログラミングしている間に、ホストコアがフラッシュブロック0のコードを実行している可能性があり、その結果、RWW競合が発生し、ハードフォルトが発生します。 この現象が観察された行動の正当な説明かどうか確認していただけますか? さらに、UTESTエリアがS32K328上のFlash Block 0と同じRWWパーティションに属しているかどうかも確認できますか? Q2。リセット後のハードフォルトの原因と診断方法 MCUのライフサイクル状態はIVT融合やライフサイクル遷移のたびに変化する可能性があるため、新しいMCUサンプルを繰り返し根本原因分析に使用することは実用的な方法ではありません。 したがって、以下の点について明確にしておきたいと思います。 ハードフォルト時にRWWの競合が発生し、その原因を特定するために使えるレジスタやステータス情報はありますか? このエラー情報はハードフォールト後にMCUがリセットされた後も保持されますか? リセット後でも原因を特定するために使えるフラッシュコントローラの状態レジスタ、RWWエラーステータスレジスタ、またはその他の診断方法はありますか? 可能であれば、チェックすべき関連するレジスタ名とビットフィールドを指定してください。 Q3。RWWの衝突時にコード実行が制限されるメモリ領域 Q1で説明された疑われるRWWの競合が実際の原因である場合、Flash Block 0のアドレス範囲が比較的広いため、IVTフュージングおよびライフサイクル移行時にコード実行が制限される特定のメモリ領域を特定したいと考えています。 制限されたメモリ領域をフラッシュセクター単位(セクターあたり0x2000バイト)で提供できますか? これにより、フラッシュブロック0内のコード実行が許可されている領域と、関連するサービスが実行されている間は実行が制限されている領域を区別するのに役立ちます。 Q4。RWWの競合を防ぐためにSRAMや他のフラッシュブロックに移す必要があるコード Q1で説明された疑われるRWWの衝突が実際の原因であれば、この問題を防ぐために関連コードをSRAMや他のFlash Blockに移すことを検討しています。 すべてのライフサイクル遷移サービス要求が同期的に実行されると仮定した場合、 Hse_Ip_ServiceRequest関数とその下位関数のみをSRAMまたは別のフラッシュブロックに移動するだけで十分でしょうか？ あるいは、 Hse_Ip_ServiceRequest を呼び出す関数 も再配置する必要があるのでしょうか？ さらに、関数実行中または割り込みサービスルーチン（ISR）中に参照される定数データも、SRAMまたは別のフラッシュブロックに配置する必要があるでしょうか？ この問題の根本原因を特定し、再発防止に役立てるため、皆様のご意見とご指導をいただければ幸いです。 再開まで今しばらくお待ちください。 Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 こんにちは、ルーカスさん。 詳しいご説明をありがとうございました。 ご依頼いただいた情報は下記をご覧ください。 1. RTDバージョン SW32K3_S32M27x_RTD_4.4_4.0.0_HF04_D2504 2. OSIFモード 現在のテストコードは、ダミーカウンタ（OSIF_COUNTER_DUMMY）を使用するように構成されています。しかし、この構成はテスト目的のみで使用され、実際の用途では異なる場合があります。 ですので、UTESTプログラミング中にRAMに移すべきすべての機能とリソースを、現在のダミーカウンター構成だけでなく、すべての対応OSIFモードを網羅して完全なリストを提供していただけますか? 3. Hse_Ip_apMuBase メモリ配置 Hse_Ip.c を確認しましたソースコードを解析した結果、Hse_Ip_apMuBaseの宣言では以下のメモリマッピングマクロが使用されていることがわかりました。 #define CRYPTO_START_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" /*! @brief Array of MU base pointers */ static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS; #define CRYPTO_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" これは、あなたが提供したコードスニペットとは異なり、CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIEDとCrypto_43_HSE_MemMap.hを使用しています。 マップファイルも確認し、Hse_Ip_apMuBaseが.mcal_constに配置されていることを確認しました。Flash Block 0 内の次のアドレスにあるセクション: .mcal_const 00411ca8+000008 Hse_Ip_apMuBase このことから、UTESTプログラミング中にHse_Ip_apMuBaseにアクセスすると、Hse_Ip_ServiceRequest関数自体がRAMに移動されていてもRWWの競合が発生する可能性があります。 RTD版で、サポートされているすべてのOSIFモードを考慮して、どの特定の機能やリソースをRAMに移すべきか確認していただけますか? 4. RWW紛争に関する追加の質問 この問題の再現性および発生条件に関して、いくつか追加の質問があります。 4.1.同一メモリレイアウトでの再現性 別のS32K328を同じファームウェアとメモリレイアウトで構成した場合、同じRWW競合が常に発生するでしょうか？ 言い換えれば、RWW競合の条件が満たされた場合、同じ構成の異なるS32K328デバイス間でこの問題が再現されると予想すべきでしょうか？ 4.2.メモリレイアウトの違いが及ぼす影響 たとえ関連するコードやデータがFlash Block 0にあったとしても、それらの特定のメモリアドレスや配置の違いがRWWの衝突の有無に影響を与える可能性はありますか? 例えば、Hse_Ip_ServiceRequestの配置やその関数、アクセスするデータの配置を変えることで問題が防げるでしょうか? 4.3.実行タイミングの影響 同じファームウェアとメモリレイアウトであっても、RWWの競合が発生するかどうかは、サービス要求のタイミングや他の実行条件によって変わる可能性はありますか? 具体的には、UTESTプログラミング中にホストコアがFlash Block 0にアクセスしようとした場合にのみ競合が発生するのでしょうか? 4.4.再現性と発生頻度 この問題は特定の条件下でデターミニスティックなのでしょうか、それとも実行タイミングによって断続的に発生することがありますか? 言い換えれば、同じ操作を同じ条件下で繰り返す場合、毎回問題が発生すると予想すべきでしょうか、それとも試みによって発生頻度が異なるのでしょうか? 5. MCSR登録とRWEフラグ Flash MCSRレジスタのRWEフラグは、RWW競合が発生したときに設定されるとおっしゃっていましたね。しかし、リファレンス・マニュアルにはMCSRという名前のレジスターは見つかりませんでした。 添付の画像に示されているMCRS登録簿のことを言っているのか確認していただけますか? 具体的には、RWEビットのビット位置20(アドレス:0x402EC004)でRWWの競合が発生したかどうかを確認するべきでしょうか? 再開まで今しばらくお待ちください。 Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 こんにちは、 @wodudwo さん。 はい、ご説明いただいた現象は、RWWの競合が原因である可能性が最も高いです。 S32K328では、UTESTとフラッシュブロック0は同じRWWパーティションに属しています。 Hse_Ip_ServiceRequest() を呼び出す際にどのリソースを RAM に移動する必要があるかを説明したこちらの投稿もご参照ください。 https://community.nxp.com/t5/S32K/S32K324-HSE-Setting-ADKP-Issue/m-p/2369325/highlight/true#M58774 再配置が必要な具体的な機能は、使用するOSIFモードによって異なり、RTDのバージョンによっても違いが生じる可能性があります。 もう一つ確認すべき点があります。Hse_Ip_ServiceRequest() で使用される Hse_Ip_apMuBase 配列は、RTD のバージョンによっては定数として宣言され、フラッシュメモリに配置される場合があります。 #define CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIED #include "Crypto_43_HSE_MemMap.h"   /*! @brief MUベースポインタの配列 */ static MU_Type* const Hse_Ip_apMuBase[HSE_IP_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_43_HSE_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_43_HSE_MemMap.h" CRYPTO_43_HSE_START_SEC_CONST_UNSPECIFIEDが影響を受けた物理的なフラッシュブロック0に位置している場合、このアレイへのアクセスは制限期間中もフラッシュの読み取りが行われます。 回避策として、配列をCRYPTO_43_HSE_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLEを使ってRAMに移動させることができ、コンスタント修飾子は削除されます。 現在の実装ではこの種の問題を引き起こす可能性があるため、Hse_IpドライバにUTESTプログラミングのサポートを追加する機能要請はすでに提出しています。 使用しているRTDのバージョンと設定されているOSIFモード（OSIF_COUNTER_DUMMYを使用していますか？）を教えていただければ、どの機能やリソースを移すべきか正確に確認できます。 RWW競合が発生した場合、Flash MCSRレジスタのRWEフラグを設定する必要があります。この情報はリセット後には保持されないことにご注意ください。 HSEがUTESTをプログラムしている間、UTEST領域もFlash Block 0全体も読み取れません。 したがって、ライフサイクルの進行、IVT認証の有効化、およびUTESTプログラミングをトリガーするその他の操作などの作業は、管理された環境下で実行する必要があります。これらの操作中は割り込みを無効にしておくことをお勧めします。そうでない場合、割り込みハンドラで使用されるすべてのリソースは、アクセス可能な別のフラッシュブロック、またはRAMに配置する必要があります。 よろしくお願いいたします。 ルーカス Re: Inquiry Regarding HardFault During Lifecycle Transition and UTEST Programming on S32K328 RAMから同期的にHse_Ip_ServiceRequest()を実行するには、以下の関数をRAMに配置してください。 Hse_Ip_ServiceRequest() OsIf_MicrosToTicks() OsIf_GetCounter() OsIf_GetElapsed() さらに、選択したOSIFタイムアウト実装の機能をRAMに配置します。 ダミーOSIF: OsIf_Timer_Dummy_MicrosToTicks()、OsIf_Timer_Dummy_GetCounter()、およびOsIf_Timer_Dummy_GetElapsed()。 システムOSIF：OsIf_Timer_System_MicrosToTicks()、OsIf_Timer_System_GetCounter()、OsIf_Timer_System_GetElapsed()、および選択されたシステムタイマーバックエンド関数。 カスタムOSIF：OsIf_Timer_Custom_MicrosToTicks()、OsIf_Timer_Custom_GetCounter()、およびOsIf_Timer_Custom_GetElapsed()。 MUアクセス機能とメモリバリアはインラインコードです。OsIf_Interrupts.c は同期要求パスでは使用されません。 Hse_Ip_apMuBase は、この RTD において定数として定義されています。 #define CRYPTO_START_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h"   /*! @brief MUベースポインタの配列 */ static MU_Type* const Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_STOP_SEC_CONST_UNSPECIFIED #include "Crypto_MemMap.h" SO、以下に変えてください: #define CRYPTO_START_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE #include "Crypto_MemMap.h"   /*! @brief MUベースポインタの配列 */ static MU_Type* Hse_Ip_apMuBase[HSE_NUM_OF_MU_INSTANCES] = MU_HOST_BASE_PTRS;   #define CRYPTO_STOP_SEC_VAR_INIT_UNSPECIFIED_NO_CACHEABLE #include "Crypto_MemMap.h" 再現性に関して言えば、起動条件が常に完全に同じであれば（つまり、単純な逐次コードで、割り込みがないなど）、同じ結果が得られるはずです。それは、同じデータとコードがキャッシュされ、フラッシュ読み取りバッファが同じ状態になっているためです。 不確定要素がある場合は、異なる結果が得られる可能性があります。例えば、お客様にハードフォールトが発生しなかったにもかかわらず、ライフサイクル情報がUTESTに正しく保存されておらず、リセット後にLC_ERRフラグ(ライフサイクルスキャン中のエラー)が設定されたCASEを見ました。つまり、前述のように、そのコードをRAMまたは別のフラッシュメモリから実行することが重要であるということです。 申し訳ありません、それはタイプミスでした。正しくはモジュール構成ステータス（MCRS）です。 よろしくお願いいたします。 ルーカス

NXP RTD SDK 安装问题：由于找不到 Link 文件夹，EB Tresos Studio 集成失败 你好， 尽管已提供指向 NXP RTD SDK 安装目录的 EB Tresos Studio 安装路径，但它并未与 EB Tresos Studio 集成。 Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found 你好@VaneB ， 我已将路径更改为“C:/EB/Tresos/plugins”，但问题仍然存在。请指教。 Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found 嗨@a1g1 请您确认在创建 RTD 包和 EB tresos 之间的链接时指定的 EB tresos 安装目录是否为C:\EB\tresos\ 如果问题仍然存在，请尝试将 RTD 插件复制到C:\EB\tresos\plugins目录。 BR，VaneB Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found 嗨@a1g1 我觉得最后一部分可能解释得不够清楚。如果无法将 RTD 包与 EB tresos 连接，您可以跳过该步骤并手动添加插件。 为此，请导航至已安装的 RTD 目录，复制所有插件，然后将其粘贴到 EB tresos 目录C:\EB\tresos\plugins中。

Fault reaction related to Double bit ECC error in SRAM Hello @danielmartynek  Good morning, I have a question regarding the ECC error reaction configuration for SRAM. When a double-bit ECC error occurs in SRAM, will the MCU generate a memory fault exception, or will the reaction be based on the configured FCCU NCF[2] channel? The reason I am asking is that I have currently not configured the NCF[2] channel to trigger any specific reaction for double-bit ECC errors. However, when I inject a double-bit ECC error into SRAM, I still observe a memory fault exception. Could you please clarify what will happen once I configure the NCF[2] channel? Will the memory fault exception still occur, or will the reaction be triggered according to the NCF[2] channel configuration? If both reactions can occur, which one will be triggered first: the memory fault exception or the reaction configured for the FCCU NCF[2] channel? NCF[2] ECC errors: PRAMC; TCMs; Caches; eDMA; EDC after ECC (PRAMC);HSE RAM errors; QSPI FLASHA ECC errors  All SRAM ECC uncorrectable error ERM_SRAM or ECC cache memry  error ERM_M7_Dcache +Icache ECC or read done by safety masters DMA or FMU: Coming from flash. Newly added or HSE RAM ECC. QSPI FLASH ECC No No Disabled   Functional reset Re: Fault reaction related to Double bit ECC error in SRAM Hello, Correct. The selected FCCU NCF2 reaction changes the system behavior: With R3, FCCU initiates a functional reset. Therefore, execution of the BusFault handler is not guaranteed, and the handler may not complete before the reset. With Alarm/R1_R3, both BusFault and FCCU Alarm can occur. Their handling order depends on the configured priorities. Best regards, Peter Re: Fault reaction related to Double bit ECC error in SRAM Hello Team, Thanks for the quick response, it means based on NCF configuration behaviour of the system will change, if i configure R3 then we cant guarantee that bus fault handler not sure of execution. Re: Fault reaction related to Double bit ECC error in SRAM Hello, Yes, the BusFault you observe is expected, even when no specific reaction is configured for FCCU NCF2. An uncorrectable double-bit ECC error in SRAM is reported independently to the Cortex-M7 exception path and to FCCU NCF2. Therefore, configuring NCF2 does not replace or suppress the BusFault. If BusFault is enabled, the MCU enters the BusFault handler. Otherwise, the exception escalates to HardFault. If FCCU NCF2 is configured for an Alarm reaction, both reactions can occur. Under the default priority, the BusFault is handled first, followed by the pending FCCU Alarm interrupt. If NCF2 is configured for R3, the FCCU generates a functional reset, so the BusFault handler may not complete before the reset occurs. Therefore, for your current test, the observed memory fault exception is expected. It will still be generated after NCF2 is configured, although the final system behavior will depend on the selected FCCU reaction. Best regards, Peter

SRAM中与双比特ECC错误相关的故障反应 你好@danielmartynek  早上好， 我有一个关于SRAM的ECC错误响应配置的问题。 当 SRAM 中发生双位 ECC 错误时，MCU 会生成存储器故障异常，还是会根据配置的 FCCU NCF[2] 通道做出反应？ 我之所以这样问，是因为我目前还没有配置 NCF[2] 通道来触发双比特 ECC 错误的任何特定反应。但是，当我向 SRAM 中注入双位 ECC 错误时，我仍然观察到内存故障异常。 请问配置 NCF[2] 通道后会发生什么情况？内存故障异常是否还会发生，还是会根据 NCF[2] 通道配置触发反应？ 如果两种反应都可能发生，那么哪一种反应会先触发：内存故障异常还是为 FCCU NCF[2] 通道配置的反应？ NCF[2] ECC错误：PRAMC；TCM；缓存；eDMA；ECC（PRAMC）后的EDC；HSE RAM错误；QSPI FLASH AECC错误 所有 SRAM ECC 不可纠正错误 ERM_SRAM 或 ECC 缓存内存错误 ERM_M7_Dcache +Icache ECC 或由功能安全主设备 DMA 或 FMU 执行的读取：来自闪存。新增或 HSE RAM ECC。QSPI 闪存 ECC 无 无 禁用   功能复位 Re: Fault reaction related to Double bit ECC error in SRAM 你好， 正确的。所选的 FCCU NCF2 反应改变了系统行为： 使用 R3，FCCU 启动功能 RESET。因此，BusFault 处理程序的执行无法保证，并且该处理程序可能在 RESET 之前无法完成。 使用 Alarm/R1_R3 时，BusFault 和 FCCU Alarm 都可能发生。它们的处理顺序取决于配置的优先级。 顺祝商祺！ Peter Re: Fault reaction related to Double bit ECC error in SRAM 各位同事好， 感谢您的快速回复，这意味着根据 NCF 配置，系统的行为会发生变化。如果我配置 R3，那么我们无法保证总线故障处理程序一定会执行。 Re: Fault reaction related to Double bit ECC error in SRAM 你好， 是的，即使没有为 FCCU NCF2 配置任何特定反应，您观察到的 BusFault 也是预期的。 SRAM 中无法纠正的双位 ECC 错误会分别报告给 Cortex-M7 异常路径和 FCCU NCF2。因此，配置 NCF2 并不会取代或抑制 BusFault。如果启用了 BusFault，MCU 将进入 BusFault 处理程序。否则，异常将升级为 HardFault。 如果 FCCU NCF2 配置为报警反应，则两种反应均可发生。默认优先级下，首先处理 BusFault，然后处理待处理的 FCCU 报警中断。如果 NCF2 配置为 R3，则 FCCU 会生成​​功能 RESET，因此 BusFault 处理程序可能无法在 RESET 发生之前完成。 因此，对于您当前的测试而言，观察到的内存错误异常是预期的。即使配置了 NCF2，它仍然会生成，尽管最终的系统行为将取决于所选的 FCCU 反应。 此致， 彼得

NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found Hello, Despite providing the path to the EB Tresos Studio installation to the NXP RTD SDK installation, it is not getting integrated with EB Tresos Studio Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found Hello @VaneB , I changed the path to "C:/EB/Tresos/plugins" yet the issue persists. Please advise. Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found Hi @a1g1  Could you please verify that the EB tresos installation directory specified when creating the link between the RTD package and EB tresos is C:\EB\tresos\ If the issue persists, please try copying the RTD plugins to C:\EB\tresos\plugins BR, VaneB Re: NXP RTD SDK installation issue: EB Tresos Studio integration failed due to Link folder not found Hi @a1g1  I think I may not have explained the last part clearly enough. If you are not able to link the RTD package with EB tresos, you can skip that step and add the plugins manually. To do this, navigate to the installed RTD directory, copy all the plugins, and paste them into the EB tresos directory C:\EB\tresos\plugins

S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V I am using the S32E288-975EVB with the S32X-MB motherboard and would like to interface the EVL kit with an external custom board operating at 3.3 V logic levels. For our application, we would prefer to use the signals available through the Motor Control section/connectors of the S32E288-975EVB. From the EVB schematic, I can see that the Motor Control section includes AE GPIOs and level translation circuitry, as well as VDDIOD, P5V0, MOTOR1_3V3, MOTOR1_5V, MOTOR2_3V3, and MOTOR2_5V supply nets.  We are considering GPIOs from the Motor Control/AE section PBA_GPIO[0]  to PBB_GPIO[12], eMIOS0_CH1/CH2/CH3 are intended for PWM-related functions, while eMIOS1_WSC8 and eMIOS1_WSC10 will be used for speed-sense inputs.  1. Can these GPIO interfaces be operated at 3.3 V logic levels at the external Motor Control connector, instead of 5 V, by changing the EVB jumper configuration? 2. Can the physical pins selected for these eMIOS channels also be brought to the EVB external/Motor Control connector at 3.3 V logic levels?   Our target setup is: S32E288-975EVB + S32X-MB → Motor Control/external connector → external custom board Our goal is to configure the EVL kit so that GPIO, eMIOS/PWM, speed-sense and ADC interfaces are compatible with a 3.3 V external board, preferably through jumper changes only and without board rework. Could you please provide the required jumper configuration? Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V Hi,vishal_HoneywellAerospace 1.The VDDIOD controls the level conversion and requires jumper connections to determine whether 5V or 3.3V should be used. 2.The signal for controlling the motor is connected to the S32X-MB motherboard J51 via the PCIE interface. Do you have any adapter cables? 3.Could you please provide more detailed information about the working methods of your motors and control boards? How many motors need to be controlled? How many PWM control signals does S32E288 need to provide, and which signals should be collected? BR Joey Re: S32E288-975EVB: Can Motor Control GPIO, eMIOS and SAR ADC interfaces be configured for 3.3V Hi, The application is not driving Motor.  The requirement is 3 PWMs, 10 ADC, 9 GPIOs and 2 WSC. 1. Since the adapter is not available now, are these signals available in General header in S32MX-MB? Open to change the channel config. 2. Can you share the adapter purchase link to place order?

プローブインデックス1を開けません。エラー: プローブが開いていません こんにちは、 FRDM-MCXN947でLEDブリンキーの例をデバッグしようとしていますが、いくつかのエラーが発生し、ターゲットとのデバッグ接続を確立できません。 注:別のFRDMボードは同じノートPCで正常に動作し、このFRDM-MCXN947は別のノートPCで動作します。この問題はこの特定のノートPCのこのボードでのみ発生しています(ただし、他のノートPCとFRDM-MCXN947でしかテストしていません)。 私もここで説明されているのと同じ問題を抱えているかもしれません。 https://community.nxp.com/t5/MCX-Microcontrollers/unable-to-open-probe-index-1/td-p/2416776 そこでMCUXpressoのSecure Provisioning Toolを使ってデバイスを消去しようとしましたが、うまくいきませんでした。 この問題の原因や、他に試せるアイデアがあれば教えてください。 FRDM-MCXN947 Re: Unable to open probe index1. Error: Probe not open こんにちは、 @JustinNL さん、 投稿ありがとうございます。 同じFRDM-MCXN947ボードが別のノートPCで正常に動作し、別のFRDMボードもこのノートPCで動作しているので、基板自体は問題ない可能性が高いです。 スクリーンショットからわかる重要なエラーの一つは、 「デバッグプローブとの通信に失敗しました」です。 これは、問題がアプリケーションやMCXN947デバイス自体ではなく、ノートPCとオンボードのMCU-Linkデバッグプローブ間の通信に関連している可能性を示唆しています。 まずは以下のことを試していただけますか:   - MCUXpresso IDEおよびMCUXpressoセキュアプロビジョニングツールを閉じる。 - Windowsタスクマネージャーを開き、まだ稼働中のLinkServerプロセスがあるか確認します。もしそうなら、タスクを終了してください。 FRDM-MCXN947をUSBから取り外し、数秒待ってから再度接続してください。 - MCUXpresso IDEのみを開いて、LEDブリンキーのデバッグを再度試みます。 それでも問題が起きる場合は、別のUSBポートを試してみてください。できればUSBハブやドッキングステーションではなく、ボードをノートPCに直接接続してください。 これらの手順で改善しない場合は、MCU-LinkのファームウェアやWindows USBデバイス/ドライバの状態をさらに確認できます。MCUXpresso IDEsで使われているLinkServerのバージョンと、FRDM-MCXN947ボード上のMCU-Linkファームウェアのバージョンを教えていただけませんか?   よろしくお願いいたします。 セレステ Re: Unable to open probe index1. Error: Probe not open ご返信よろしくお願いします。 MCUXpressoを閉じた後も、まだ動いているLinkServerのプロセスは見つかりませんでした。 他にUSBポートを2つ試しました(全部で3つあり、すべてノートPCに直接接続)が、前回と同じエラーが出ます。 LinkServerバージョン: v26.9.130(ビルド130) MCU-Linkファームウェアバージョン: CMSIS-DAP V3.174(FRDM-MCXN947ボードのMCU-LINK上で動作) MCUXpresso IDE v25.6.136 スクリーンショットや画像をいくつか添付しましたので、お役に立てれば幸いです。 敬具、 ジャスティン Re: Unable to open probe index1. Error: Probe not open こんにちは、 @JustinNL さん、 さらに確認するために手伝ってもらえますか: 1. ジャンパーJ22とJ24：短絡；ジャンパーJ21：開放 2. MCUXpresso のリンクサーバーパス構成が Linkserver_26.9.130 であることを確認してください。 BR セレステ Re: Unable to open probe index1. Error: Probe not open ジャンパーJ22とJ24：短絡；ジャンパーJ21：開放 私の MCUXpresso のリンクサーバー パス構成は Linkserver_26.9.130 です。 よろしくお願いいたします。 ジャスティン Re: Unable to open probe index1. Error: Probe not open こんにちは、 警告が表示されていることに気づきました。 問題はこのノートPCとオンボードのMCU-Linkデバッグプローブ間の通信に関連しているようです。 以下のチェックをご協力いただけますか? 1. WindowsデバイスマネージャーでMCU-Linkを確認する FRDM-MCXN947がコネクテッドの状態で、WindowsデバイスマネージャでMCU-Link関連デバイスを確認してください。   2. 動作中のノートPCでのLinkServerプローブ検出を比較する このFRDM-MCXN947が正常に動作するノートPCでは、同じLinkServerバージョン(v26.9.130)を使用し、以下を実行します。 LinkServer.exe プローブ 問題のあるノートPCの結果と比較できるよう、完全な出力を教えてください。   3. J-Linkファームウェアを試してください もう一つのクロスチェックとして、オンボードのMCU-LinkをJ-Linkファームウェアに切り替え、LEDブリンキーの例を再度デバッグしてみてください。 このテストは、このノートPCのCMSIS-DAP/LinkServer通信経路に問題が特有かどうかを判断するのに役立ちます。   これらの検査結果をお知らせください。彼らは問題のさらなる調査に役立つはずだ。   よろしくお願いいたします。 セレステ Re: Unable to open probe index1. Error: Probe not open 1. FRDM-MCXN947は以下のように表示されます。 MCU-LINK FRDM-MCXN947 (r0E7) CMSIS-DAP V3.128 MCU-Link VComポート(COM3) 2. ノートPCのプローブLinkServer.exe、FRDM-MCXN947が正常に動作するLinkServer v26.9.130を使ってテストしました。 3. 私は提供されたprogram_JLINKスクリプト(Firmware_J-Link-MCU-Link_240702.s19)を使って、J-LinkファームウェアでオンボードのMCU-Linkをプログラムしました。 これで、LED点滅サンプルのデバッグが正しく動作するようになりました。   またボードを使えるようになって嬉しいですが、MCU-Linkのファームウェアの問題が何なのかまだ気になります。これまでのご助力とサポートに心から感謝します。本当に感謝しています。 よろしくお願いいたします。 ジャスティン Re: Unable to open probe index1. Error: Probe not open 今は正常に動作していると聞いて安心しました。時にはJLinkのファームウェアに切り替えることで問題が解決することもあります。この現象は説明できません。おそらく互換性の問題かもしれませんが、一貫して起こるわけではありません。 BR セレステ

IMX8QXP 差分/部分 OTA 开发 大家好， IMX8QXP - 斯卡思间隙 - L 6.6.52 请问能否分享一下关于IMX8QXP Yocto平台差分OTA/部分OTA开发的文档或参考资料？ 谢谢，此致敬礼！ VKS i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8QXP Differential/ Partial OTA development 您好， 对于差异化 OTA 更新，值得考虑的一种方法是 OSTree。 在 Toradex，我们使用 Torizon OS 中的 OSTree 来管理操作系统更新，只传输设备上尚不存在的对象，而不是下载整个根文件系统。 这并非针对您特定 Yocto 配置的现成解决方案，但我们的更新架构或许可以作为有用的参考： https://developer.toradex.com/torizon/torizon-platform/torizon-updates/torizon-updates-architecture/ 此致， 丹尼尔·莫赖斯 Re: IMX8QXP Differential/ Partial OTA development 您好， 目前我正在这样做 ### 第一部分：初始完整OTA（1）到完整OTA（2） - 完整 OTA (1): 基础版本。 - 完整 OTA (2): 目标版本。 比较完整 OTA (1) 和完整 OTA (2) 之间的差异，以确定更改的文件。 生成了包含已更改的根文件系统文件以及其他所需文件的 SWU 文件。 更新期间： 1. 挂载不活动的（下一个）插槽。 2. 将更改后的文件复制到非活动槽中的相应位置。 3. 卸下插槽。 4. 从更新后的插槽重启设备。 从当前插槽切换到下一个插槽后，将两个插槽同步到相同的配置。这样可以确保两个插槽对齐，并为即将到来的差分 OTA 更新做好准备。 ## 第二部分：完整 OTA (2) 到完整 OTA (3) - 完整 OTA (2)：基础版本。 - 完整 OTA (3): 目标版本。 以更新后的 Full OTA (2) 为基础，以 Full OTA (3) 为目标。比较两个版本之间的差异，找出更改的文件。 生成包含已更改文件和所需更新元器件的差异化 SWU 软件包。 将更新应用到非活动插槽，从更新后的插槽重启，并将两个插槽同步到相同的配置。 ## 第 3 部分：完整 OTA (3) 到完整 OTA (2) - 完整 OTA (3)：基础版本。 - 完整 OTA (2): 目标版本。 使用更新后的 Full OTA (3) 作为基础，Full OTA (2) 作为目标。比较两个版本之间的差异，找出更改的文件。 生成包含已更改文件和所需更新元器件的差异化 SWU 软件包。 将更新应用到非活动插槽，从更新后的插槽重启，并将两个插槽同步到相同的配置。 ## 整体更新流程 完整OTA（1） 初始基础 差分OTA（1→2） 完整OTA（2） 更新后的基础 差分OTA（2→3） 完整OTA（3） 更新后的基础 差分OTA（3→2） 完整OTA（2） 返回上一版本 关键点：每次 OTA 更新成功后，同步两个时隙，以便可以使用当前更新的版本作为基础生成下一个差异化 OTA。 请您帮我检查一下我的方法。 谢谢，此致敬礼！ VKS

11x21MMのウェットインレイNTAG215まとめて調達しようとしています NXP NTAG215 11x21MMのウェットインレイステッカーをまとめ注文しようとしているのですが、Aliexpress以外で卸売価格のサイトを見つけるのに苦労しています。 1000個を1個あたり0.12米ドルで販売しているサイトを見つけました。 しかし、それらはNTAG213であり、私はパスワード保護を探しています。 もしこの質問をする場所が適切でない場合は申し訳ありませんが、ここにいる誰かが知っているだろうと思い、またNXPが最も互換性の高いチップベースだと読んだことがあったので質問させていただきました。 お時間をいただきありがとうございました。 Re: Trying to source NTAG215 11x21MM wet inlay in bulk 必要ならおすすめできます。 Re: Trying to source NTAG215 11x21MM wet inlay in bulk こんにちは、 NXP Semiconductorsの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 なお、NXPは完成したインレイステッカーなどのエンドソリューションを販売していません。NTAG 215の製品ページのエンジニアリングサービス欄では、インレイステッカーのご要望をお手伝いできる当社の認定パートナーをご紹介します。 NXP製品は、無許可の購入先から購入された場合、偽造品や破損品、その他使用に適さない場合がありますので、これらの認定パートナーのいずれかにご連絡ください。 この情報があなたのアプリケーションに最適な解決策を見つける助けになれば幸いです。 よろしくお願いします、 アロンドラ

i.MX95 Neutron NPU:INT16 Conv2Dはタイル境界で誤った出力を出す;INT16はサポートされているのか? i.MX95(FRDM-IMX95、BSP LF6.12.49_2.2.0、eIQ Neutron SDK 2.2.2)上で、INT8モデルはNPU上で正しく動作しますが、INT16活性化畳み込みは誤った結果をもたらします。 最小限のテスト:3 ×3 CONV_2D 1件(16→16チャネル、入力1×32×64×16、同じパッド、ReLU)。NXPのtfliteプロファイラーとtflite量子化器(INT16活性化、INT8重み)で量子化し、Neutronコンバータ--targetimx95でコンパイルしました。 INT8: 正解です。 INT16 対称型: 出力行 6～8、14～16、22～24 は誤りです。その他の行はすべて正確です。これらは4つのNPUユニット間の境界にある行です（--dump-tile-ir 8行からなる4つのゾーンを示します。 INT16 非対称: すべての行が間違っています。 同じレイヤーを1×3畳み込みとして書き換えた場合（ユニット間で行の共有なし）：正しい。 結果はSDK 2.2.2ランタイムでもSDK 3.3.0でも同じですLF6.18ランタイム上で。 SDK 2.2.2 SupportedOperatorsS.md では、N3/N3+(i.MX95はN3+として記載)のConv2DDenseカーネルのInt16入出力が記載されていますが、SDK 3.3.0 SupportedOperatorsS.md ではCONV_2D、MUL、AD、CONCATENATIONのみがINT8として記載されています。 質問: i.MX95 NPUはINT16活性化CNNレイヤーをサポートしていますか？ これは既知の問題ですか？ Re: i.MX95 Neutron NPU: INT16 Conv2D gives wrong output at tile boundaries; is INT16 supported? こんにちは@SwethaRaghavendran  SDKリリース間の違いから、これは既知の問題です。したがって、CONV_2D、MUL、ADD、CONCATENATIONでサポートされる量子化タイプについては、最新のSDKのドキュメントを参照してください。 よろしくお願いします、 志明

wwdt0 mcxa145vll を使用しています こんにちは、 MCXA145VLLマイクロコントローラを使っていて、WWDT0について質問があります。これが私の設定です。 フリーズが起きた場合に備えて、250ms後にファームウェアをリセットするために使っています。ファームウェアの一部では、このリセットを可能にするために、意図的に`while(1)`ループを含めています。ウィンドウ型ウォッチドッグを使用するのは正しい選択でしょうか？ ウォッチドッグタイマーは、あるハードウェアでは正しく動作するのですが、別のハードウェアでは動作しないことに気づきました。WWDT の動作を妨げている可能性のある要因があるのでしょうか、それとも私が注意すべき点があるのでしょうか？ よろしくお願いいたします。 よろしくお願いいたします。 Re: Using wwdt0 mcxa145vll こんにちは、 @Transidico さん、 投稿ありがとうございます。 このようにWWDTを使用しても問題ありません。 「ウォッチドッグはあるハードウェアプラットフォームでは正しく動作するが、別のプラットフォームでは動作しない」と言うのは、2つの異なるボードのことを指していますか? まずはWWDT0クロックの設定を確認することをお勧めします。 CLOCK_GetWdtClkFreq(0) を使用して設定済みのウォッチドッグクロック周波数を取得し、両方のボードで結果を比較してください。また、WWDT初期化後の関連するクロックレジスタも比較してください。リセット原因フラグを確認することで、ウォッチドッグリセットが発生したかどうかを確認できます。 また、当社のSDKにあるWWDTデモも参考にすることをお勧めします。 これがお役に立てば幸いです。 BR セレステ

DD_CORE connectivity There are 2 VDD_CORE pins in 172HDQFP package of MCX N series – pin 16 and pin 105. It looks like pin 16 is an output in LDO mode while pin 105 is an input in DCDC mode. In schematics for evaluation boards which use BGA package, the 2 VDD_CORE pins are shorted on the board which is not a problem as the 2 balls are adjacent in the package. However, in 172pin package, the 2 pins pin 16 and pin 105 are on the opposite sides of the package and we don’t plan to short the 2 VDD_CORE pins on the board. Is it a problem if the 2 VDD_CORE pins are not connected on the board for LDO mode? Each VDD_CORE pin will have caps are described in the UG10092 Hardware Design Guide. Thanks and regards, Satish MCXN Power