S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello, I am developing an application on the following platform: MCU: NXP S32K314 RTD 7.0.0 (AUTOSAR MCAL) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 During development, I encountered a deadlock related to high-priority interrupts and would like to ask whether my understanding is correct and whether there is a recommended solution. Background FreeRTOS specifies that ISRs with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY must not call FreeRTOS APIs. However, I found that many RTD MCAL APIs internally execute FreeRTOS critical section APIs through the following call chain: MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() and MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() This behavior exists even in APIs that only perform simple peripheral register accesses, such as DIO and GPT. Problem When a MCAL API is called from a high-priority ISR (priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY), the internal call to taskENTER_CRITICAL_FROM_ISR() causes the FreeRTOS interrupt masking state to become inconsistent. As a result, after taskEXIT_CRITICAL_FROM_ISR() returns, BASEPRI is not restored correctly, causing lower-priority interrupts such as SysTick and PendSV to remain masked. The scheduler eventually stops because xPortSysTickHandler() is no longer executed. I was able to reproduce this issue using APIs such as: Dio_FlipChannel() GPT (PIT) interrupt processing Other MCAL APIs that use SchM exclusive areas Current Workaround To avoid modifying RTD-generated source code directly, I used the GNU linker --wrap option to wrap the following functions: OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() The wrapper checks the current interrupt priority. Please refer to the attached WrapperExample.c. If the current ISR priority is higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, it skips the original function. Otherwise, it calls the original implementation. This workaround appears to resolve the deadlock while leaving the generated RTD source unchanged. Questions Is this behavior expected by design in the RTD MCAL? Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Is there an official or recommended solution for this problem that does not require modifying generated RTD source code? Any advice or recommendations would be greatly appreciated. Thank you. Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hello @tobara, The case is currently pending input from the RTD development team. BR, Daniel Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Hi, please see below punctual answers to your question: Is this behavior expected by design in the RTD MCAL?Answer: yes, this happens because you are calling OS APIs from a CAT1 interrupt (aka interrupts with prio higher than MAX SYSCALL).  The purse of interrupts higher than MAX_SYSCALL is to do work with minimal latency also unhindered by the RTOS.If you need to avoid latency introduced by RTOS then you should not call APIs that in the end use the RTOS. Is it recommended to call DIO, GPT, CAN, or other MCAL APIs from high-priority ISRs? Answer:  no, not larger than MAX_SYSCAL, for the reason mentioned in first answer. Does NXP recommend implementing dedicated drivers (Complex Device Drivers) for high-priority real-time functions such as watchdog servicing or GPIO toggling? Answer: if you already can tolerate the latency introduced by the RTD SchM, OSIf APIs, RTOS then you can just use the existing drivers but just call them from the higher interrupt but lower than MAX_SYSCALL. You still get the priority boost but not the problems described in the ticket. Is wrapping OsIf_Interrupts_SuspendAllInterrupts() and OsIf_Interrupts_ResumeAllInterrupts() using the GNU linker --wrap option an acceptable workaround? Answer: No, a quick analysis points in the direction that this workaround protects in only one direction. It might avoid the deadlock but does not protect lower prio ISR that share registers / resources with higher prio ISR (> MAX_SYSCALL). This implementation can introduce race conditions on shared registers and global variables. Is there an official or recommended solution for this problem that does not require modifying generated RTD source code?Answer (but it needs to be confirmed by the RTD team): do not call RTD / RTOS APIs from IRQ > MAX_SYSCALL. If you can tolerate the current RTD->OSIF->RTOS latencies then just use a  higher prio IRQ but lower than MAX_SYSCALL. All answers need to be confirmed by the RTD team, I'm answering from a RTOS point of view. Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections Thank you very much for your detailed explanation. I now understand the following design constraints of the NXP RTD/MCAL: RTD/MCAL APIs must not be called from high-priority ISRs (interrupts with a priority higher than configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY). Although using --wrap may prevent the deadlock, bypassing the RTD critical sections can introduce race conditions when resources or registers are shared between high- and low-priority contexts. I have a few additional questions. If an application requires processing in a high-priority ISR (AUTOSAR Category 1 ISR), what is the recommended software architecture? Should such functionality always be implemented as a Complex Device Driver (CDD) or a dedicated low-level driver? If a GPIO port or timer channel is exclusively owned by a single high-priority ISR and is never accessed from any other task or ISR, would the concerns about race conditions still apply to the --wrap workaround? Is it correct to understand that the current RTD/MCAL does not provide a supported way to use its APIs from high-priority ISRs, and therefore high real-time functions must be implemented using a CDD or a dedicated driver? From my experience with embedded software outside the automotive domain, hardware abstraction layers are often designed to be independent of the operating system. Therefore, I was surprised to find that simple GPIO and timer APIs internally invoke RTOS critical section APIs. As a reference, I have attached the GPT driver that I implemented to avoid this issue (CpuPit.h/c). I would appreciate any comments or suggestions from the RTD team. Thank you again for your support.

S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 S32K314 RTD (MCAL) - 由 OsIf 临界区引起的高优先级 ISR 死锁 你好， 我正在以下平台上开发一个应用程序： MCU：NXP S32K314 RTD 7.0.0（AUTOSAR MCAL） FreeRTOS 7.0.0 S32 设计工作室 3.6.4 在开发过程中，我遇到了与高优先级中断相关的死锁，想请教一下我的理解是否正确，以及是否有推荐的解决方案。 背景信息 FreeRTOS 规定优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 的中断服务例程 (ISR) 不得调用 FreeRTOS API。 然而，我发现许多 RTD MCAL API 在内部通过以下调用链执行 FreeRTOS 临界区 API： MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() 以及 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() 即使在仅执行简单外设寄存器访问的 API（例如 DIO 和 GPT）中，也存在这种行为。 问题 当从高优先级 ISR（优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY）调用 MCAL API 时，对 taskENTER_CRITICAL_FROM_ISR() 的内部调用会导致 FreeRTOS 中断屏蔽状态变得不一致。 因此，在 taskEXIT_CRITICAL_FROM_ISR() 返回后，BASEPRI 无法正确恢复，导致 SysTick 和 PendSV 等低优先级中断保持屏蔽状态。 调度程序最终停止，因为 xPortSysTickHandler() 不再执行。 我使用以下 API 重现了这个问题： Dio_FlipChannel() GPT（PIT）中断处理 其他使用 SchM 专属区域的 MCAL API 当前解决方法 为了避免直接修改 RTD 生成的源代码，我使用了 GNU 链接器的 --wrap 选项来包装以下函数： OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() 该包装器会检查当前的中断优先级。 请参考附件WrapperExample.c 。 如果当前 ISR 优先级高于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY，则跳过原始函数。 否则，它将调用原始实现。 这种变通方法似乎可以解决死锁问题，同时保持生成的 RTD 源不变。 问题 RTD MCAL 的这种行为是设计预期的吗？ 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？ 任何建议或推荐都将不胜感激。 谢谢！ Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 你好@tobara ， 目前该案件正在等待RTD开发团队的意见。 BR，丹尼尔 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 您好， 以下是对您问题的及时解答： RTD MCAL 的这种行为是预期行为吗？答：是的，这是因为您正在从 CAT1 中断（即优先级高于 MAX SYSCALL 的中断）调用操作系统 API。大于 MAX_SYSCALL 的中断次数是为了以最小的延迟完成工作，并且不受 RTOS 的干扰。如果您需要避免 RTOS 引入的延迟，则不应该调用最终会使用 RTOS 的 API。 是否建议从高优先级 ISR 调用 DIO、GPT、CAN 或其他 MCAL API？ 答：不，不能大于 MAX_SYSCAL，原因已在第一个答案中提及。 NXP 是否建议为看门狗服务或 GPIO 切换等高优先级实时功能实现专用驱动程序（复杂设备驱动程序）？ 回答： 如果您已经能够容忍 RTD SchM、OSIf API、RTOS 引入的延迟，那么您可以直接使用现有的驱动程序，但只需从高于 MAX_SYSCALL 的中断调用它们即可。您仍然可以获得优先级提升，但不会遇到工单中描述的问题。 使用 GNU 链接器的 --wrap 选项包装 OsIf_Interrupts_SuspendAllInterrupts() 和 OsIf_Interrupts_ResumeAllInterrupts() 是否是一种可接受的解决方法？ 答：不，简单的分析表明，这种变通方法只能在一个方向上起到保护作用。它或许可以避免死锁，但不能保护与优先级更高的 ISR (> MAX_SYSCALL) 共享寄存器/资源的优先级较低的 ISR。这种实现方式可能会在共享寄存器和全局变量上引入竞争条件。 是否有官方或推荐的解决方案来解决此问题，而无需修改生成的 RTD 源代码？答案（但需要 RTD 团队确认） ：不要从 IRQ > MAX_SYSCALL 调用 RTD / RTOS API。如果您可以容忍当前的 RTD->OSIF->RTOS 延迟，那么只需使用优先级更高的 IRQ，但低于 MAX_SYSCALL 即可。 所有答案都需要RTD团队确认，我是从RTOS的角度回答的。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 非常感谢您的详细解释。 我现在理解了NXP RTD/MCAL的以下设计限制： 不得从高优先级 ISR（优先级高于configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY的中断）调用 RTD/MCAL API。 虽然使用--wrap可以防止死锁，但绕过 RTD 临界区可能会在高优先级和低优先级上下文之间共享资源或寄存器时引入竞争条件。 我还有几个问题。 如果应用程序需要在高优先级 ISR（AUTOSAR 1 类 ISR）中进行处理，推荐的软件架构是什么？此类功能是否应该始终以复杂设备驱动程序 (CDD) 或专用底层驱动程序的形式实现？ 如果一个 GPIO 端口或定时器通道被一个高优先级 ISR 独占，并且从未被任何其他任务或 ISR 访问，那么对于--wrap解决方法，竞争条件的问题是否仍然适用？ 目前的 RTD/MCAL 不支持从高优先级 ISR 中使用其 API，因此必须使用 CDD 或专用驱动程序来实现高实时性功能，这种理解是否正确？ 根据我在汽车领域之外的嵌入式软件开发经验，硬件抽象层通常被设计成独立于操作系统。因此，我惊讶地发现，简单的 GPIO 和定时器 API 在内部调用了 RTOS 临界区 API。 作为参考，我附上了我为避免此问题而实现的 GPT 驱动程序（CpuPit.h/c）。 我非常感谢RTD团队的任何意见或建议。 再次感谢您的支持。

S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック S32K314 RTD (MCAL) - OsIf クリティカルセクションが原因で発生した高優先度 ISR デッドロック こんにちは、 私は以下のプラットフォームでアプリケーションを開発しています: MCU:NXP S32K314 RTD 7.0.0(AUTOSAR・マカル) FreeRTOS 7.0.0 S32 Design Studio 3.6.4 開発中に、優先度の高い割り込みに関連するデッドロックに遭遇しました。私の理解が正しいかどうか、また推奨される解決策があるかどうかをお伺いしたいと思います。 バックグランド FreeRTOSでは、configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い優先度を持つISRは、FreeRTOS APIを呼び出してはならないと規定されています。 しかし、多くのRTD MCAL APIは、内部的に以下の呼び出しチェーンを通じてFreeRTOSのクリティカルセクションAPIを実行していることがわかりました。 MCAL API ↓ SchM_Enter_xxx() ↓ OsIf_SuspendAllInterrupts() ↓ SuspendAllInterrupts() ↓ OsIf_Interrupts_SuspendAllInterrupts() ↓ taskENTER_CRITICAL_FROM_ISR() そして、 MCAL API ↓ SchM_Exit_xxx() ↓ OsIf_ResumeAllInterrupts() ↓ ResumeAllInterrupts() ↓ OsIf_Interrupts_ResumeAllInterrupts() ↓ taskEXIT_CRITICAL_FROM_ISR() この挙動は、DIOやGPTのような単純なペリフェラルレジスタアクセスのみを行うAPIでも存在します。 問題 MCAL API が高優先度 ISR (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY より高い優先度) から呼び出されると、taskENTER_CRITICAL_FROM_ISR() の内部呼び出しによって FreeRTOS の割り込みマスキング状態が不整合になります。 その結果、taskEXIT_CRITICAL_FROM_ISR() が戻った後、BASEPRI が正しく復元されず、SysTick や PendSV などの優先度の低い割り込みがマスクされたままになります。 xPortSysTickHandler() が実行されなくなるため、スケジューラは最終的に停止します。 以下のようなAPIを使用して、この問題を再現することができました。 Dio_FlipChannel() GPT(PIT)割り込みプロセッシング SchMの排他領域を使用するその他のMCAL API 現在の回避策 RTDで生成されたソースコードを直接変更することを避けるため、GNUリンカーの--wrapオプションを使用して以下の関数をラップしました。 OsIf_Interrupts_SuspendAllInterrupts() OsIf_Interrupts_ResumeAllInterrupts() ラッパーは現在の割り込み優先度をチェックします。 添付のWrapperExample.cを参照してください。 現在のISRの優先度がconfigLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも高い場合、元の関数はスキップされます。 そうでない場合は、元の実装を呼び出します。 この回避策は、生成されたRTDソースを変更せずにデッドロックを解消するようです。 質問 この挙動はRTD MCALのデザイン上当然のことですか? 高優先度のISRからDIO、GPT、CAN、または他のMCAL APIを呼び出すのは推奨されますか? NXPは、ウォッチドッグサービスやGPIOトグルなどの高優先度リアルタイム機能に対して専用ドライバ(複雑デバイスドライバ)の実装を推奨していますか? GNUリンカーの--wrapオプションを使用してOsIf_Interrupts_SuspendAllInterrupts()とOsIf_Interrupts_ResumeAllInterrupts()をラップすることは、許容できる回避策でしょうか？ 生成されたRTDソースコードを変更する必要のない、この問題に対する公式または推奨される解決策はありますか？ 何かアドバイスやご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections こんにちは、 @tobara さん、 このケースは現在、RTD開発チームからの意見提出を待っています。 BR、ダニエル Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections こんにちは、 ご質問に対する回答は以下のとおりです。 この挙動はRTD MCALの設計上当然のことですか?回答:はい、これはCAT1割り込み(つまり優先度がMAX SYSCALLより高い割り込み)からOSのAPIを呼び出すために起こります。MAX_SYSCALL以上の割り込みの手当は、RTOSの影響を受けずに最小限のレイテンシで作業を行うためです。RTOSによって生じるレイテンシを避けたいなら、最終的にRTOSを使うAPIを呼び出すべきではありません。 高優先度のISRからDIO、GPT、CAN、または他のMCAL APIを呼び出すのは推奨されますか? 回答：いいえ、最初の回答で述べた理由により、MAX_SYSCALより大きくすることはできません。 NXPは、ウォッチドッグサービスやGPIOトグルなどの高優先度リアルタイム機能に対して専用ドライバ(複雑デバイスドライバ)の実装を推奨していますか? 回答: RTD SchM、OSIf API、RTOSによる遅延に耐えられるなら、既存のドライバーを使い、MAX_SYSCALLより低い割り込みから呼び出しすればいいです。優先度アップの効果は引き続き得られますが、チケットに記載されている問題は解消されません。 GNUリンカーの--wrapオプションを使用してOsIf_Interrupts_SuspendAllInterrupts()とOsIf_Interrupts_ResumeAllInterrupts()をラップすることは、許容できる回避策でしょうか？ 回答：いいえ、簡単な分析によると、この回避策は一方向のみを保護するものです。デッドロックは回避できるかもしれないが、優先度の高いISR（> MAX_SYSCALL）とレジスタ/リソースを共有する優先度の低いISRを保護するものではない。この実装は共有レジスタやグローバル変数に競合条件を導入することができます。 生成された RTD ソース コードを変更する必要のない、この問題に対する公式または推奨される解決策はありますか?回答 (ただし、RTD チームによる確認が必要です) : IRQ > MAX_SYSCALL から RTD / RTOS API を呼び出さないでください。現在のRTD->OSIF->RTOSのレイテンシに耐えられるなら、優先度の高いIRQをMAX_SYSCALLより低く設定すればいいです。 すべての回答はRTDチームによる確認が必要です。私はRTOSの観点から回答しています。 Re: S32K314 RTD (MCAL) - High Priority ISR Deadlock Caused by OsIf Critical Sections 詳細なご説明をありがとうございました。 私は今、NXP RTD/MCALの以下の設計制約を理解しました。 RTD/MCAL API は、優先度の高い ISR ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITYよりも優先度の高い割り込み) から呼び出してはなりません。 --wrapを使う ことでデッドロックを防ぐことはできますが、RTDクリティカルセクションをバイパスすると、リソースやレジスタが高優先度コンテキストと低優先度コンテキスト間で共有される際に競合条件が発生する可能性があります。 いくつか追加の質問があります。 アプリケーションが高優先度のISR(AUTOSARカテゴリー1 ISR)でのプロセッシングを必要とする場合、推奨されるソフトウェアアーキテクチャは何ですか?このような機能は、常に複雑なデバイスドライバ(CDD)として実装されるべきでしょうか、それとも専用の低レベルドライバーとして実装されるべきでしょうか? もしGPIOポートやタイマーチャネルが単一の高優先度ISRのみで、他のタスクやISRからは一切アクセスされない場合、レースコンディションに関する懸念はラップ回避策にも適用されます か? 現在のRTD/MCALは、高優先度ISRからのAPI利用をサポートしておらず、したがって高リアルタイム機能はCDDまたは専用ドライバで実装しなければならないと理解してよいでしょうか? 自動車分野以外の組み込みソフトウェアの経験から言うと、ハードウェア抽象化層はしばしばオペレーティングシステムに依存しないように設計されています。そのため、単純なGPIOおよびタイマーAPIが内部的にRTOSのクリティカルセクションAPIを呼び出していることに気づいて驚きました。 参考までに、この問題を避けるために実装したGPTドライバー(CpuPit.h/c)を添付しました。 RTDチームからのご意見やご提案をいただければ幸いです。 改めてサポートありがとうございます。

iMX8M Plus - Flexspi chip select pin On the i.MX8M Plus EVK, the ECSPI chip select signal can be configured using a GPIO pin. Could you please confirm whether FlexSPI also supports GPIO-based chip-select signals, or whether only the dedicated FlexSPI chip select pins can be used? As per our requirement, we need two chip select signals for FlexSPI. Kindly suggest the recommended configuration for supporting two FlexSPI devices. Re: iMX8M Plus - Flexspi chip select pin Hi @pengyong What we can do for two chip select of QSPI? This is also from our requirement. If there is lack of CS pin means, can we use the any gpio has a chip select? If it will work Re: iMX8M Plus - Flexspi chip select pin Hi @Govind1807  You could use a GPIO-based chip select signal. However, you only have two FlexSPI Flash devices. Why would you use a GPIO as the chip select signal? The imx8mp has four FLEX SS signals that can be used directly： https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h B.R Re: iMX8M Plus - Flexspi chip select pin Hi @pengyong_zhang , What we can do for two chip select of QSPI? This is also from our requirement. If there is lack of CS pin means, can we use the any gpio has a chip select? If it will work or not? Re: iMX8M Plus - Flexspi chip select pin Hi @Govind1807  What we can do for two chip select of QSPI? >>>For information on configuring QSPI CS, please refer to the following dts file: https://github.com/nxp-imx/linux-imx/blob/5b372337acc9c764ce9e92f272e69d0b494ab38f/arch/arm64/boot/dts/freescale/imx8mp-evk.dts#L1122 This is also from our requirement. If there is lack of CS pin means, can we use the any gpio has a chip select? If it will work or not? >>>Yes, you can use GPIO for your CS pin As long as your driver supports GPIO. B.R

例tflm_cifar10_cm33_core0に tflm_label_image_ext_mem のメモリ設定を使ってもいいですか? 良い１日を。 現在はEIQ例tflm_cifar10_cm33_core0 を使ってNPUモードでモデル化しています。モデルデータはSRAMに保存されます。推論時間は良好です。そして、こちらがメモリ構成です。このeiq例を5クラスのモデル用に修正しました https://docs.nxp.com/bundle/AN14700/page/topics/eiq_enablement.html しかし今はモデルが大きくなり、NPU tfliteモデルを外部メモリ上で特定したいと考えています。モデルデータはFlashに格納されています。そして、こちらは eiq の例tflm_label_image_ext_memの設定です。 https://docs.nxp.com/bundle/AN14700/page/topics/imx_rt700_system_details.html 私の目標は、ソースコードをtflm_cifar10_cm33_core0から保持したい(tflm_label_image_ext_memで新しいソースコードを作成したくはありません)が、NPU tfliteモデルを外部メモリ上で特定したい ということです。 私の解決策は、上記の画像のように、メモリ構成をSRAMから外部メモリに変更することだけです。それで合っていますか？あるいは、他の設定も変更する必要があるのかもしれません。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは、 @nnxxpp さん。 ご説明ありがとうございます。 「--use-sequencer」を外部メモリモデルの実行と組み合わせて使用しないでください。 「tflm_label_image_ext_mem」例では、モデルが外部メモリから実行されるため、「--fetch-constants-to-sram」を残し、「--use-sequencer」は削除してください。 モデルを以下のように変換してみてください。 ./Neutronコンバータ \ --入力 QAT.tflite\ --出力 QAT_NPU.tflite\ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --定数をSRAMに取得   お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? @mayliu1 こんにちは。これは新たな問題です（まだ解決されていません）。この問題は、外部メモリ(SRAMではなく)でのNPU tfliteモデルのデプロイに関連しています。 現在はSDKs of MIMRT700のeiqサンプルtflm_label_image_ext_memを使っています。この例はCANうまく実行できます。この例はモデル mobilenetv1 で、サイズ=224、クラス数=1000です。 サンプルのモデルを自分のモデル(同じ分類モデル)に置き換えようとしましたが、クラス数を変えました。 ラベルを変えました。(レーベル名の場合)、 サンプルのモデルを自分のモデルに置き換え、名前は同じまま使っています model_data.h ファイル内のmodel_data_lenも変更しました。 ビルドはできましたが、デバッグを実行するとプログラムは「静的プロセッシング」で停止し、結果が出ませんでした。 上の画像には 「モデルハンドルを保存できません。完了したらneutronModelUnprepare()を呼び出せ」というメッセージがありますが、NXPの従業員の一人はエラーではないと言っていました。https://community.nxp.com/t5/eIQ-Machine-Learning-Software/eIQ-FAQ/ta-p/1099741 NPUモデルが外部メモリ上にあるCASE、拡張子.tflite モデルを使います(モデルがSRAM上で位置する場合はヘッダーファイル.hではありません)。 モデルをフラグで--fetch-constants-to-sramに変換して、外部メモリ上のNPUモデルをこのように位置づけています ./Neutronコンバータ \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --ヘッダーファイル出力をダンプする --dump-header-file-input \ --use-sequencer \ --定数をSRAMに取得   NXPから設定や設定(SOの変更方法や場所)のチュートリアルが見当たらなかったので、上記の手順で試しましたがうまくいきませんでした。 手伝ってもらえますか?ありがとう。 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? こんにちは@nnxxpp さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 返信が遅くなり申し訳ありません。 前回の投稿で、問題はすでに解決済みだと書かれていたことに気づきました。全てが正常に機能していると聞いて安心しました。 ご理解いただき、改めて感謝申し上げます。 よろしくお願いいたします。 5月 Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? 応援してくれて本当にありがとうございます。正しく動作しました

MIMXRT1052CVJ5Bの電源問題 MIMXRT1050HDUGの仕様にあるように、このMCUには2つのバージョンが存在します。電源設計の参考にするために、自分のMCUの具体的なバージョンをどのように特定すればよいでしょうか？ i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 ありがとう！ Re: MIMXRT1052CVJ5B供电问题 こんにちは、 @Simon_CHan さん。 NXPのRTシリーズ製品にご関心をお寄せいただき、またNXPコミュニティをご利用いただきありがとうございます。 i.MX RT1050 のチップ正誤表にある ERR011093 を参照してください。正誤表には、この問題は A1 シリコンで修正済みであると記載されています。したがって、最も簡単な方法は、チップのシルクスクリーンでシリコン リビジョンを確認することです。A は A0、B は A1 を示します。バージョンが B の場合は、問題は修正済みです。バージョンが A の場合は、正誤表で規定されているとおり、DCDC_IN/DCDC_IN_Q を 2.8 V ～ 3.0 V の範囲内に制御する必要があります。 上記の情報がお役に立てば幸いです。 よろしくお願いします 5月

ADC Configuration Issue Hi @Senlent , I have also same issue which you mentioned above. Our external oscillator clock is 25 MHz. According to the S32K322 datasheet, the ADC supports up to 80 MHz, so I have configured a prescaler of 2. I also configured the sampling time to 1.2 microseconds and set the BCTU mode to trigger mode. However, we are still getting noisy data when executing the BCTU method and the normal chain method simultaneously on the same ADC0 peripheral. Is there a workaround or an alternative method to safely run both on the same ADC0 peripheral? S32 SDK for S32K1 Re: ADC Configuration Issue Hello @praveen_ext , Considering the previous Community thread, the behavior in BCTU Control Mode is expected: when the ADC is controlled by BCTU in Control Mode, normal conversions cannot be started independently on the same ADC instance. This explains why the current sensing becomes more stable in Control Mode, but the voltage and temperature channels configured in the normal chain stop working. In Trigger Mode, the situation is different. This mode allows BCTU-triggered conversions as well as normal/injected conversions, but all these conversions still share the same ADC instance and therefore the same ADC conversion resources. For a time-critical current sensing use case, especially if synchronized with PWM, the important point is not only whether the conversion is possible, but also whether the sampling instant remains deterministic. From the shared data, the current-sense signal seems mostly stable, but it shows occasional large spikes/dropouts. These do not look like ordinary random analog noise only. They look more like event-related outliers, possibly caused by conversion scheduling, result handling or interaction between the BCTU-triggered conversions and the normal chain conversions on the same ADC peripheral. Therefore, I would suggest first isolating whether the issue is caused by the mixed use of the ADC instance: 1. Please run only the BCTU-triggered current sensing in Trigger Mode and completely disable the normal chain execution.    - Do the current-sense spikes still occur? 2. Please run only the normal chain conversions and disable the BCTU-triggered current sensing.    - Are the voltage and temperature channels still stable? 3. Please check whether the current-sense spikes correlate with the moment when the normal chain conversion is started by the application.  Could you also clarify how the normal chain conversion is started while the BCTU-triggered current sensing is running? For example, is the normal chain started periodically by software, from an interrupt or from another scheduler task? One more point to confirm: from your channel list, ADC1-P2 and ADC1-P3 seem to be mentioned both as BCTU current-sensing channels and as normal-chain channels. Could you please confirm whether these channels are intentionally used by both acquisition methods or if this is only a description/configuration mismatch?  If the spikes disappear when the normal chain is disabled, then the likely issue is not the ADC electrical configuration itself, but the timing/scheduling of two acquisition flows on the same ADC instance. In that case, possible workarounds would be: - keep the current-sensing channels exclusively under BCTU control, - move the slower voltage/temperature measurements to another ADC instance, if available, - or schedule the normal chain conversions only in a time window where they cannot interfere with the BCTU/PWM-synchronized current measurement.   After this isolation test, it is still recommended to check the analog front-end, especially for the continuously noisy signals: - source impedance of the measured signal, - external RC filter values, - ADC input capacitor value, - capacitor placement close to the MCU ADC input pin, - whether the configured sampling time is sufficient for the given source impedance and external components.   Similar ADC accuracy/noise-related discussions are available here: - Issue with Inaccurate ADC Values on S32K3:   https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/m-p/2033042   - Smoke detector interfacing with FS32K146HAT0MLLT:   https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/m-p/1773787   - S32K3 Confusion about ADC accuracy and results:   https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/m-p/2006783   Best regards, Pavel

MIMXRT1052CVJ5B power supply problem As indicated by the MIMXRT1050HDUG, there are two versions of the MCU. How do I determine my specific version to guide my power supply design? i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 Thanks! Re: MIMXRT1052CVJ5B供电问题 Hi @Simon_CHan , Thank you for your interest in NXP's RT series products and for using the NXP community. You can refer to ERR011093 in Chip Errata for the i.MX RT1050. The Errata documentation states that this issue has been fixed in A1 silicon. Therefore, the simplest method is to check the chip silkscreen for Silicon Rev: A indicates A0, and B indicates A1. If it's version B, the issue has been fixed; if it's version A, you need to control DCDC_IN/DCDC_IN_Q within the 2.8 V–3.0 V range as required by Errata. I hope the above is helpful to you. Best Regards May

ARA240(.dvm)用のカスタムONNX/TFLiteモデルをコンパイルする方法は?(搬送波はi.MX95 FRDMを使用しています) 私はi.MX95 FRDMのARA240 M.2アクセラレータを評価しています。 ランタイムは正常に動作しています。 ARA240はPCIe経由で検出されます。 nnapp は提供された .dvm を正常に実行しますモデル. ランタイムSDKs(rt-sdk-ara240)とPython DVAPIバインディングがインストールされています。 しかし、自分でMobileNetモデルを展開したいのですが、モデルを.dvmにコンパイルするためのツールチェーンが見つかりません形式。 私の質問は以下のとおりです。 カスタムONNX/TFLiteモデルを.dvmにコンパイルする際のサポートワークフローは何ですか?ARA240用ですか？ Ara2コンバータ(またはdvconvert/dvnc)は公開されているのか、それともRuntime SDKsとは別に配布されているのか? NXPがサポートするカスタムCNNモデルを展開する方法はありますか(例:MobileNet) を ARA240 に移植する際に、私が見落としている点はありますか？ どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします！

How to compile custom ONNX/TFLite models for ARA240 (.dvm) ?(carrier being used i.MX95 FRDM) I'm evaluating the ARA240 M.2 accelerator on the i.MX95 FRDM. The runtime is working correctly: ARA240 is detected over PCIe. nnapp successfully runs the provided .dvm models. The Runtime SDK (rt-sdk-ara240) and Python DVAPI bindings are installed. However, I would like to deploy my own MobileNet model, and I'm unable to find the toolchain required to compile models into the .dvm format. My questions are: What is the supported workflow to compile a custom ONNX/TFLite model into .dvm for ARA240? Is the Ara2 Converter (or dvconvert/dvnc) publicly available, or is it distributed separately from the Runtime SDK? Is there an NXP-supported way to deploy custom CNN models (e.g. MobileNet) onto ARA240, that I am missing? Any guidance or documentation would be greatly appreciated. Thanks!

ユーザー空間からカーネルのrpmsgバッファにアクセスする こんにちは、 IMX8MPのMPUとMCU間で通信はできました。しかし、ユーザー空間から共有メモリのデータにアクセスしたいのです。これに関する例はありますか？ imx_rpmsg_pinpong.c についても質問したいのですがデバイスドライバは、カーネル空間とユーザー空間間の通信のためにLinuxのユーザースペースI/Oを処理するように拡張可能です。 よろしくお願いします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Accessing my kernel rpmsg buffer from user space こんにちは、 私も同じ問題に取り組んでいます。あなたが提示した例は、カーネルモジュールで動作します。 しかし、実はユーザースペースのアプリケーション例を探しています。Linux側でユーザースペース内で動かせるサンプルCプログラムを教えてもらえますか? ありがとう！ Re: Accessing my kernel rpmsg buffer from user space こんにちは、 @ababatola さん。 お元気でお過ごしでしょうか！返信が遅くなり申し訳ありません。 i.MX 8M Plus SDKsにあるrpmsg_lite_str_echo_rtosマルチコアの例を見ることをお勧めします。これはシンプルなアプリケーションで、Cortex AからCortex Mへメッセージを送信し、M4が受信した内容を表示し、同じメッセージを確認応答として返します。 SDKは https://mcuxpresso.nxp.com/ からビルドしてダウンロードできます これがあなたにとって有効かどうか教えてください。 よろしくお願いします、 ヘクター。

如何为 ARA240 (.dvm) 编译自定义 ONNX/TFLite 模型？（载板型号为 i.MX95 FRDM） 我正在评估 i.MX95 FRDM 上的 ARA240 M.2 加速器。 运行时运行正常： 通过 PCIe 检测到 ARA240。 nnapp 成功运行提供的 .dvm 文件模型。 已安装运行时 SDK (rt-sdk-ara240) 和 Python DVAPI 绑定。 但是，我想部署我自己的 MobileNet 模型，却找不到将模型编译成 .dvm 文件所需的工具链。格式。 我的问题是： 将自定义 ONNX/TFLite 模型编译成 .dvm 文件的受支持工作流程是什么？适用于 ARA240？ Ara2 变流器（或 dvconvert/dvnc）是公开提供的，还是与运行时 SDK 分开分发的？ NXP 是否支持部署自定义 CNN 模型（例如）MobileNet) 到 ARA240，我漏掉了什么吗？ 任何指导或文件都将不胜感激。 谢谢您！

MIMXRT1052CVJ5B供电问题 从MIMXRT1050HDUG可知，MCU有两个版本，那我要如何确定自己的版本，从而确定我的供电设计呢 i.MXRT 105x Re: MIMXRT1052CVJ5B供电问题 谢谢！ Re: MIMXRT1052CVJ5B供电问题 Hi @Simon_CHan ,  感谢您关注恩智浦RT系列产品以及使用NXP社区。 您可以参考 Chip Errata for the i.MX RT1050 中的 ERR011093 。该问题在 Errata 里说明已经 Fixed in A1 silicon 。所以最简单的方法是看芯片丝印Silicon Rev： A 表示 A0，B 表示 A1 。如果是 B 版本，则该问题已修复；如果是 A 版本，则需要按 Errata 要求将 DCDC_IN/DCDC_IN_Q 控制在 2.8 V–3.0 V 范围内。 希望以上对您有帮助 Best Regards May

iMX8M Plus - Flexspiチップセレクトピン i.MX8M Plus EVKでは、ECSPIチップ選択信号をGPIOピンで設定できます。 FlexSPIがGPIOベースのチップセレクト信号もサポートしているのか、それとも専用のFlexSPIチップセレクトピンのみが使えるのか確認していただけますか? 当社の要件に基づき、FlexSPIには2つのチップセレクト信号が必要です。FlexSPIデバイスを2台サポートするための推奨構成をご提案ください。 Re: iMX8M Plus - Flexspi chip select pin こんにちは@pengyong QSPIの2チップセレクトで何ができるでしょうか?これも私たちの要件です。もしCSのピン手段が不足している場合、チップセレクトがあるGPIOを使ってもいいのでしょうか?うまくいくなら Re: iMX8M Plus - Flexspi chip select pin こんにちは、 @Govind1807さん GPIOベースのチップセレクト信号を使うこともできます。しかし、FlexSPIフラッシュデバイスは2つしかありません。なぜGPIOをチップセレクト信号として使用するのですか？ imx8mpには4つのFLEX SS信号があり、直接使用できます: https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h BR Re: iMX8M Plus - Flexspi chip select pin こんにちは@pengyong_zhang QSPIの2チップセレクトで何ができるでしょうか?これも私たちの要件からです。もしCSのピン手段が不足している場合、チップセレクトがあるGPIOを使ってもいいのでしょうか?それがうまくいくかどうかは? Re: iMX8M Plus - Flexspi chip select pin こんにちは、 @Govind1807さん QSPIの2チップセレクトで何ができるでしょうか? >>>QSPI CSの設定方法については、以下のdtsファイルを参照してください。 https://github.com/nxp-imx/linux-imx/blob/5b372337acc9c764ce9e92f272e69d0b494ab38f/arch/arm64/boot/dts/freescale/imx8mp-evk.dts#L1122 これも私たちの要件です。もしCSのピン手段が不足している場合、チップセレクトがあるGPIOを使ってもいいのでしょうか?それがうまくいくかどうか？ >>>はい、ドライバーがGPIOをサポートしていれば、CSピンにGPIOを使うことは可能です。 BR

ADC構成の問題 こんにちは、 @Senlent さん。 私も上記で述べられたのと同じ問題を抱えています。 外部発振器のクロックは25MHzです。S32K322のデータシートによると、ADCは最大80MHzをサポートしているので、プリスケーラーは2MHzに設定しています。また、サンプリング時間を1.2マイクロ秒に設定し、BCTUモードをトリガーモードに設定しました。しかし、同じADC0ペリフェラルでBCTU方法とノーマルチェーン方法を同時に実行しても、依然としてノイズの多いデータが得られます。同じADC0ペリフェラルで両方を安全に動かす回避策や代替方法はありますか? S32 SDK for S32K1 Re: ADC Configuration Issue こんにちは、 @praveen_ext さん。 前回のコミュニティThreadを考慮すると、BCTUコントロールモードでADCが制御されている場合、同じADCインスタンス上で通常の変換を独立して開始できません。これが制御モードで電流検出が安定する一方で、通常のチェーンで設定された電圧と温度チャネルが機能しなくなる理由を説明しています。 トリガーモードでは、状況は異なります。このモードでは、BCTUトリガーによる変換と通常の/注入による変換の両方が可能ですが、これらの変換はすべて同じADCインスタンスを共有するため、同じADC変換リソースが使用されます。特にPWMと同期している時間的に重要な電流センシングのCASEでは、変換が可能かどうかだけでなく、サンプリング瞬間がデターミニスティックなままであるかどうかが重要なポイントです。 共有データから判断すると、電流検出信号は概ね安定しているように見えるが、時折大きなスパイクやドロップアウトが見られる。これらは普通のランダムなアナログノイズのようには見えません。これらはイベント情報関連の異常値のように見え、コンバージョンのスケジューリング、結果処理、またはBCTUトリガーの変換と同じADCペリフェラルでの通常のチェーン変換の相互作用が原因と考えられます。 したがって、まずは問題の原因がADCインスタンスの混在使用にあるかどうかを特定することをお勧めします。 1. BCTUトリガーによる電流検出のみをトリガーモードで実行し、通常のチェーン実行は完全に無効にしてください。 電流感知スパイクはまだ発生しますか？ 2. 通常のチェーン変換のみを実行し、BCTUトリガーによる電流検出を無効にしてください。 - 電圧と温度チャネルはまだ安定していますか? 3. 電流センススパイクがアプリケーションによって通常の連鎖変換が開始される瞬間と相関しているかどうかを確認してください。  また、BCTUトリガー電流検出が稼働している間に通常のチェーン変換がどのように開始されるのかも説明していただけますか?例えば、通常のチェーンはソフトウェアによって定期的に開始されるのか、割り込みからですか、それとも別のスケジューラタスクからですか? もう一つ確認したい点ですが、あなたのチャンネルリストを見ると、ADC1-P2とADC1-P3はBCTUの電流感知チャネルと正規連鎖チャネルの両方として言及されているようです。これらのチャネルが両方の取得方法で意図的に使われているのか、それとも単なる説明や設定の不一致なのか確認いただけますか?  通常のチェーンが無効化されたときにスパイクが消えた場合、問題はADCの電気構成自体ではなく、同じADCインスタンスで2つの取得フローのタイミングやスケジューリングにある可能性が高いです。その場合、回避策として考えられるのは以下の通りです: - 電流検出チャネルをBCTUの制御下に置くこと、 - 利用可能な場合は、より低速な電圧/温度測定を別のADCインスタンスに移動します。 - または、通常のチェーン変換をBCTU/PWM同期電流測定に干渉しない時間帯内にスケジュールする。   この絶縁テスト後も、特に連続的にノイズの多い信号についてはアナログフロントエンドの確認が推奨されます。 - 測定信号のソースインピーダンス、 - 外部RCフィルタ値、 - ADC入力コンデンサ値、 - コンデンサをMCU ADC入力ピンの近くに配置すること、 - 設定されたサンプリング時間が、指定されたソースインピーダンスと外部コンポーネントに対して十分であるかどうか。   同様のADC精度／ノイズ関連の議論は、こちらでもご覧いただけます。 - S32K3におけるADC値の不正確さに関する問題： https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/mp/2033042   - 煙感知器とFS32K146HAT0MLLTのインターフェース接続： https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/mp/1773787   - S32K3におけるADCの精度と結果に関する混乱： https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/mp/2006783   よろしくお願いいたします。 パベル

iMX8M Plus - Flexspi 芯片选择引脚 在 i.MX8M Plus EVK 上，可以使用 GPIO 引脚配置 ECSPI 片选信号。 请问FlexSPI是否也支持基于GPIO的片选信号，还是只能使用FlexSPI专用的片选引脚？ 根据我们的要求，FlexSPI 需要两个片选信号。请推荐支持两个FlexSPI设备的配置方案。 Re: iMX8M Plus - Flexspi chip select pin 嗨@pengyong 对于 QSPI 的两个片选信号，我们可以做什么？这也是我们的要求。如果缺少 CS 引脚，我们可以使用任何具有片选功能的 GPIO 吗？如果它有效的话 Re: iMX8M Plus - Flexspi chip select pin 你好@Govind1807 您可以使用基于 GPIO 的片选信号。但是，您只有两个 FlexSPI Flash 设备。为什么要使用GPIO作为片选信号？ imx8mp 具有四个可直接使用的 FLEX SS 信号： https://github.com/nxp-imx/linux-imx/blob/5768b67a64961d932b7c50adf15ba3f5bfcc8f70/arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h BR Re: iMX8M Plus - Flexspi chip select pin 嗨@pengyong_zhang ， 对于 QSPI 的两个片选引脚，我们该如何实现？这也是我们的需求。如果没有 CS 引脚，我们是否可以使用任何具有片选功能的 GPIO？这样做是否可行？ Re: iMX8M Plus - Flexspi chip select pin 你好@Govind1807 对于 QSPI 的两个片选信号，我们可以做什么？ >>>有关配置 QSPI CS 的信息，请参阅以下 dts 文件： https://github.com/nxp-imx/linux-imx/blob/5b372337acc9c764ce9e92f272e69d0b494ab38f/arch/arm64/boot/dts/freescale/imx8mp-evk.dts#L1122 这也是我们的要求。如果缺少 CS 引脚，我们可以使用任何具有片选功能的 GPIO 吗？它到底行不行？ 是的，只要你的驱动程序支持GPIO，你就可以使用GPIO作为CS引脚。 BR

从用户空间访问我的内核 rpmsg 缓冲区 您好， 我已经能够实现我的imx8mp MPU和MCU之间的通信。但是，我想从用户空间访问共享内存中的数据。有例子吗？ 我还想问一下 imx_rpmsg_pinpong.c设备驱动程序可以扩展以处理 Linux 用户空间 I/O，从而实现内核空间和用户空间之间的通信。 谢谢！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Accessing my kernel rpmsg buffer from user space 你好， 我也在关注同样的问题。你提供的示例适用于内核模块。 但我实际上想找一个用户空间应用程序的示例。能否提供一个可以在Linux用户空间运行的C语言程序示例？ 谢谢！ Re: Accessing my kernel rpmsg buffer from user space 嗨@ababatola ， 希望你一切都好！抱歉回复晚了。 我建议您查看 i.MX 8M Plus SDK 中的 rpmsg_lite_str_echo_rtos 多核示例。这是一个简单的应用程序，允许你从 Cortex A 向 Cortex M 发送消息，然后 M4 显示接收到的内容，并将相同的消息回显作为确认。 您可以从https://mcuxpresso.nxp.com/版本和下载 SDK。 如果这个方法对你有效，请告诉我。 此致， 赫克托。

rw612 sdk 26.06 Hi, I downloaded SDK 26.06 for rw612, but it is not available in vs code, i imported the sdk, but i cannot generate project, it is not in the list also cannot open existing project which i created by 26.03 it is not in the dropdown list  Re: rw612 sdk 26.06 Hi. I did, but did not work. When I want to import the project, it says board not supported ( or something like this). but i generated SDK from https://mcuxpresso.nxp.com/ for my board. Re: rw612 sdk 26.06 Hello, Hope you are doing well. I am not able to reproduce this behavior. I would recommend updating the MCUXpresso Installer, and checking that all Software Kits are updated. Best Regards, Ricardo Re: rw612 sdk 26.06 Hello, Could you please try importing repository? Regards, Ricardo Re: rw612 sdk 26.06 hi, it worked, but I should delete other sdks and then add

RW612 SDK 26.06 您好，我下载了适用于 RW612 的 SDK 26.06，但它在 VS Code 中不可用。我已经导入了 SDK，但无法生成项目，它不在列表中，也无法打开我使用 26.03 版本创建的现有项目。 它不在下拉列表中 Re: rw612 sdk 26.06 你好。我试过了，但是没成功。当我尝试导入项目时，它显示“不支持的板”（或类似信息）。但我已从https://mcuxpresso.nxp.com/为我的开发板生成了 SDK。 Re: rw612 sdk 26.06 你好， 希望你一切都好。我无法重现此现象。 我建议更新 MCUXpresso 安装程序，并检查所有软件包是否已更新。 顺祝商祺！ 里卡多 Re: rw612 sdk 26.06 你好， 请问您能否尝试导入仓库？ 此致， 里卡多 Re: rw612 sdk 26.06 嗨，它奏效了，但我应该先删除其他 SDK，然后再添加。

Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? Have a nice day. Currently I am using eiq example tflm_cifar10_cm33_core0 to model on NPU mode. Modeldata is saved in SRAM. Inference time is good. And here is memory configuration. I modified this eiq example for my models with 5 classes https://docs.nxp.com/bundle/AN14700/page/topics/eiq_enablement.html But now my model is larger and I want to locate NPU tflite model on external memory. Modeldata is located in Flash. And here is configuration from eiq example tflm_label_image_ext_mem https://docs.nxp.com/bundle/AN14700/page/topics/imx_rt700_system_details.html My target is that, I want to keep source code from tflm_cifar10_cm33_core0 (I dont want to create new source code with tflm_label_image_ext_mem), but I want to locate my NPU tflite model on external memory.  My solution that I will change only memory configuration from SRAM to external memory as above images. Is that right? Or I need to change more other configurations. Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? Hi @nnxxpp , Thanks for your clarification. Please do not use `--use-sequencer` together with external-memory model execution. For the `tflm_label_image_ext_mem` example, please keep `--fetch-constants-to-sram` and remove `--use-sequencer`, since the model is executed from external memory. Please try converting the model as below: ./neutron-converter \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --dump-header-file-output \ --dump-header-file-input \ --fetch-constants-to-sram   Wish it helps you Best Regards May Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? @mayliu1  Hi. This is new issue (not resolved yet). This issue is related to deploy NPU tflite model on external memory (not on SRAM). Currently, I am using eiq sample tflm_label_image_ext_mem from SDK of MIMRT700. I could successfully run this example. This example is for model mobilenetv1, size=224 and number of classes=1000. I tried to replace the sample's model by my model (same classification model) but with different number of classes. I have changed labels.h (for label names),  I replaced the sample's model by my model and I keep the same name I also change model_data_len in the file model_data.h I could build, but when running debug, the program is stopping at "Static processing" and did not give result. There is an message in the above image Unable to save model handle, call neutronModelUnprepare() when done but one NXP's employee said that it is not error. https://community.nxp.com/t5/eIQ-Machine-Learning-Software/eIQ-FAQ/ta-p/1099741 I see that in the case NPU model is located on external memory, we use model with extension .tflite (not header file .h in the case we locate model on SRAM). I convert model with flag --fetch-constants-to-sram to locate NPU model on external memory like this ./neutron-converter \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --dump-header-file-output \ --dump-header-file-input \ --use-sequencer \ --fetch-constants-to-sram   Because I did not see any tutorial from NXP to set up and configs (where and how to change source code), so I tried with the above steps, but it did not work. Could you help me? Thank you. Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? Hi @nnxxpp ， Thank you so much for your interest in our products and for using our community. I apologize for the delayed response. I noticed that in your previous post, you mentioned that the issue has already been resolved. I’m glad to hear that everything is working now. Thank you again for your understanding. Best regards, May Re: Can I use memory config from tflm_label_image_ext_mem for the example tflm_cifar10_cm33_core0? Thank you so much for supporting me. It worked correctly