S32DS License Expired. Hi Support, Please help extend the license: FF6A-EDA4-CDF0-7186 that has expired. Regards, Marcus Activation | Installation | Licensing | Installer Download Re: S32DS License Expired. I don't think extend the license is possible. Maybe you need to purchase the license

Android版の登録アプリは動作せず、iOS版も動作しません Android用のアプリを登録しました。 しかしiOSで同じことをしようとすると「パッケージ名はすでに存在します」と表示されます。 意味がわかりません。AndroidとiOSは同じパッケージ名でいても、2つの異なるプラットフォームです。 アプリ登録 Re: Register app for Android and iOS doesn't work こんにちは、 @Skelさん あなたの調子が良いといいのですが。 プラットフォームは異なりますが、 UG10044 および第2章 UG10045 、TapLinxライセンス文字列を取得するにはNXPサーバー上でパッケージ文字列が一意でなければなりません。 ご迷惑をおかけして申し訳ございません。 よろしくお願いいたします。 エドゥアルド。

PN7221+Android16 EDLA certification issues PN7221, Android 16   The EDLA-certified build only supports partial NFC functions. Card detection works in our tests, but EMVCo, firmware upgrade and other features are unavailable. Root cause identified via comparison is as follows:   The EDLA build uses Google's prebuilt NFC service, while the AOSP build is compiled with NXP patches integrated.   Below is the EDLA-related build configuration snippet:   apex_set {   name: "com.google.android.nfcservices_compressed",   apex_name: "com.android.nfcservices",   overrides: ["com.android.nfcservices"],   owner: "google",   set: "com.google.android.nfcservices_compressed.apks",   filename: "com.google.android.nfcservices_compressed.apex",   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } Could you advise how to import NXP patches under this scenario? Are there alternative solutions? For other customers using NXP NFC chips, what approaches are adopted to pass EDLA certification while retaining full NFC functionality? Re: PN7221+Android16 EDLA certification issues Hello @zhangkai  Based on our analysis, the issue is likely caused by the EDLA build using Google's prebuilt NFC APEX (com.android.nfcservices) instead of the NFC module integrated with NXP Android middleware. The NXP Android 16 solution extends multiple layers of the Android NFC stack, including the NFC framework, NFC service, EMVCo framework, HAL, and associated libraries. If the Google prebuilt NFC service is used, only standard NFC features may remain available, while NXP-specific features such as EMVCo functionality, firmware update support, and other middleware extensions may not be active. At present, NXP's Android 16 porting documentation does not describe a method to directly patch or modify Google's prebuilt EDLA NFC APEX. The typical NXP integration approach is based on AOSP source integration and rebuilding the NFC stack with NXP middleware. For customers requiring full PN7221 functionality, we recommend evaluating whether the NFC APEX can be rebuilt with the NXP NFC middleware included, or consulting Google/OEM support regarding customization of the EDLA NFC module while maintaining EDLA compliance.

PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi everyone, I am currently integrating the PCA2131 Automotive RTC into a Battery Management System (BMS). I am encountering a persistent issue where the Alarm Flag (AF, bit 4 of Control_2 register 01h) is stuck high. Basic SPI communication is functioning perfectly-I can successfully set and read the time registers without issue. However, I cannot clear the AF flag during initialization. Important Context: I have already ensured that all Alarm Enable (AE_X) bits in the alarm registers (0Ah through 0Eh) are set to 1 (disabled) prior to attempting to clear the AF flag. The sequence I am executing: Read Control_2 (Register 01h). The AF bit reads as 1. Clear the flag by setting AF = 0 and AIE = 0 in my local struct. Write the modified byte back to Control_2. Read Control_2 again. The AF bit is still 1. I have attached screenshots from my debug session showing the register states before clearing, during the clear operation, and after reading it back. My Questions: Given that all AE_X bits are disabled, what other internal conditions could force the AF flag to immediately re-assert (or prevent it from clearing)? Any insights or recommendations would be greatly appreciated! Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Jozef, Thank you for your support and for pointing me in the right direction. I checked the SPI messages using the picoscope and verified that the hardware values were correct. Following your suggestion, I debugged my code further and confirmed that the root cause was indeed a bitfield ordering mismatch. I have fixed the mismatch, and the issue is now fully resolved. Thanks again for your help! Best regards, Vikas Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Vikas, thank you for confirmation. Given the PCA2131 behavior described in the datasheet, and assuming AE_S/AE_M/AE_H/AE_D/AE_W are all 1. it does not look the RTC is legitimately re-triggering AF. Most likely cause is bitfield ordering mismatch. Could you please catch and share the scopes of the three reading, writing SPI messages? To confirm the timing and registers/bits written and read.  With Best Regards, Jozef Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Oops, sorry for the typo! The correct address is 0Eh to 12h. I just double-checked, and I did have it correct in my code, so it was just a mistake in my message. Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear Hi Vikas, please double check the Alarm registers. These registers have address 0Eh to 12h.  Please try to set all the AE_x bits to 1 again.  With Best Regards, Jozef

Utility software issues How do I download the NXP MCUXpresso IDE development software used for the LPC1765FBD100? Thank you. Analog (ADC|CMP|DAC|OpAmps) Core and Memory Development Board Re: 工具软件问题 Hello, you can find the MCUXPresso download link here: Free Professional ARM Development Tools | NXP Semiconductors BR Celeste

S32G399A 串行启动 I/O 确认 你好 我正在阅读S32G3参考手册。 串行启动部分提到，CAN 和 UART 接口使用： UART：RX = PAD[42]，TX = PAD[41] CAN：RX = PAD[43]，TX = PAD[44] 但是，我在 SoC 焊盘列表或引脚描述中找不到 PAD[41]、PAD[42]、PAD[43] 或 PAD[44]。 请问 PAD[41]、PAD[42]、PAD[43] 和 PAD[44] 分别对应哪些 SoC 物理引脚或信号？ 另外，这些焊盘是否与 BootROM 串行启动模式使用的特定 LINFlexD 实例和 FlexCAN 实例相关联？ Re: S32G399A serial boot IO confirm 你好， MichaelTao 感谢您与我们联系。 我已经收到您的问题，我会帮您核实。 BR 乔伊

S12X 串行 MCU，如何知道代码的起始地址 现在我有一个 Can 启动 Demo，它可以分析 S19 文件并将数据和偏移地址发送到 S9S12G64，MCU 只需要将数据写入主计算机发送的指定地址即可。我需要知道APP代码的起始地址，这里有一个app项目的prm文件，如何获取起始地址？ Re: S12X serial MCU ,how to know the Code's START ADDRESS 你好@李乐 能否请您提供 MAP 文件或 S19 文件以供参考？谢谢。 BR 爱丽丝 Re: S12X serial MCU ,how to know the Code's START ADDRESS 以下是应用程序和启动代码 Re: S12X serial MCU ,how to know the Code's START ADDRESS 嗨@李乐 APP 的起始地址为 0xC000。 谢谢！ BR 爱丽丝

FLEXCAN EDMA - CANメッセージのバースト受信時にACKエラーが発生する i.MXRT1176では、EDMAとFLEXCANを使用しています。(SDK 26.03) DMA転送完了時にコールバック関数が定義されています。 これが私たちの流れです。 1.転送を開始するには、`FLEXCAN_TransferReceiveFifoEDMA()` を呼び出してください。 2. DMA転送完了時にユーザー定義コールバックが呼び出されます。 3. データはDMAバッファからコピーされ、メッセージの受信を継続するために`FLEXCAN_TransferReceiveFifoEDMA()`が呼び出されます。 4. 手順2～4を繰り返す 別のノードから最小限のフレーム間隔でバースト的にメッセージを送信すると、ACKエラーの数が増加することがわかりました。つまり、iMXがメッセージをACKできないということです。 処理の流れを追っていくと、DMA転送完了コールバックが発生するたびに、FLEXCAN上でDMAが無効化されているようです。「FLEXCAN_TransferReceiveFifoEDMA()」が呼び出されると再び有効化されます。 これは「FLEXCAN_EnableRxFifoDMA()」を呼び出すことで行います。有効化/無効化DMAはFLEXCANのMCRレジスタ内のDMAビットを更新し、フリーズモードでのみ可能です。メッセージを一気に受信しているため、FLEXCANがフリーズモードに設定されている間に送信が進行中である可能性があります。そして、着信メッセージをACKで確認できません。   `FLEXCAN_EnableRxFifoDMA()` の呼び出しを削除することで、すべての ACK エラーが解消されることを確認しましたが、今度は一部のメッセージがドロップされるようになりました。また、メッセージの間隔を空けて送信してみたところ、ACKエラーも解消されました。これが実装上の問題なのか、それとも別の方法で再設計すべきか確認していただけますか?

私のS32 Design Studio for ARMバージョン2.2のライセンスが期限切れになりました。延長手続きをお願いできますでしょうか？よろしくお願いいたします。 私のS32 Design Studio for ARMバージョン2.2のライセンスが期限切れになりました。延長手続きをお願いできますでしょうか？よろしくお願いいたします。

MPC5746C hangs (no boot, no UART) at 115°C ambient Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK) During thermal chamber testing at 115°C ambient, our MPC5746C-based board becomes completely unresponsive on boot — no UART console output at all, and this happens on every boot attempt at that temperature. The part appears to fully recover after cooling: reflashing/rebooting at room temperature restores normal operation with no persistent damage. Interestingly, we can still successfully reprogram flash via PEMicro JTAG debug probe while the board is at 115°C — we've confirmed this by flashing a build with an incremented version string at temperature and reading back the new version after cooling down. So the debug-probe flash path works at 115°C; only the application boot path hangs/bad state. From manual it states MCU can with hold upto 125°C.  Could you please help us to root cause the issue and how fix this issue. Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Hello, From manual it states MCU can with hold upto 125°C. Yes, that is not an issue. Could you please help us to root cause the issue and how fix this issue. Since this is your custom board and issue disappear after cooling I suspect: 1. Clock startup issue (highest probability) At 115°C: External crystal (FXOSC) startup time increases. Oscillator gain margin decreases. Load capacitors shift value with temperature. PCB leakage increases. The debugger can still access the part because debug logic uses its own infrastructure and does not depend on the application reaching main(). FXOSC status bits CMU clock-monitor faults FIRC-only boot experiment Run entirely from FIRC and disable external crystal temporarily The fact that JTAG programming continues to work at 115°C is the strongest clue that the core infrastructure remains alive and the failure is occurring very early in the application boot path rather than in the flash array itself best regards, Peter

PN7221+Android16 EDLA認証に関する問題 PN7221、Android 16   EDLA認証を受けたビルドは、部分的なNFC機能のみをサポートしています。当社のテストではカード検出機能は正常に動作しましたが、EMVCo、ファームウェアのアップグレード、その他の機能は利用できません。比較によって特定された根本原因は以下のとおりです。   EDLAビルドはGoogleの既製NFCサービスを使用する一方、AOSPビルドはNXPのパッチを統合してコンパイルされている。   以下は、EDLA関連のビルド構成の抜粋です。   apex_set {   名前:「com.google.android.nfcservices_compressed」   apex_name:「com.android.nfcservices」   オーバーライド: ["com.android.nfcservices"],   所有者: "google"、   セット:「com.google.android.nfcservices_compressed.apks」   ファイル名:「com.google.android.nfcservices_compressed.apex」、   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } このシナリオでNXPパッチをインポートする方法を教えてもらえますか?代替案はありますか？NXP NFCチップを使用している他のお客様に対して、完全なNFC機能を維持しつつEDLA認証に合格するためにどのようなアプローチが取られていますか? Re: PN7221+Android16 EDLA certification issues こんにちは、 @zhangkai さん。 私たちの分析によると、この問題はGoogleのプリビルドNFC APEX(com.android.nfcservices)を用いたEDLAビルドが原因である可能性が高いですNXPのAndroidミドルウェアと統合されたNFCモジュールの代わりに、 NXP Android 16ソリューションは、NFCフレームワーク、NFCサービス、EMVCoフレームワーク、HALおよび関連ライブラリを含むAndroid NFCスタックの複数層を拡張しています。GoogleのプリビルトNFCサービスを使用する場合、標準的なNFC機能のみが利用可能になり、EMVCo機能、ファームウェアアップデートサポート、その他のミドルウェア拡張などのNXP固有の機能はアクティブでない場合があります。 現時点でNXPのAndroid 16移植ドキュメントには、Googleの既製品EDLA NFC APEXを直接パッチまたは修正する方法について説明されていません。NXPの一般的な統合アプローチは、AOSPソースコードの統合と、NXPミドルウェアを用いたNFCスタックの再構築に基づいています。 PN7221のフル機能を必要とするお客様には、NXP NFCミドルウェアを含んでNFC APEXを再構築できるか、EDLA準拠を維持しつつEDLA NFCモジュールのカスタマイズについてGoogleやOEMのサポートに相談することをお勧めします。

PWM Capture can't work in frdm_mcxw72 board Hi， I tried to practice the pwm capture sample in  frdm_mcxw72 board, but unfortunately, the print message in serial tool only show " capture cycle err -134" . I'm sure there is the 1Khz, 50% duty cycle pwm signal inject into the PTA21 pins in frdm_mcxw72 board. i imported the whole project files from the demo case,  there is no change that i only added the overlay file,   below is the overlay files setting. can you help check the reason why there is no correct print information. thanks in advance! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Hope you are doing well. Could you please clarify what Zephyr repo are you using? Also, are you starting from any of the examples? Did you modify something? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo， The repo version is V4.4.1.0,  below is the my steps  1. Import the capture example application from the repo  2. Add the  DTS overlay file in the board folder, the content of the overlay file  posted in first message. 3. build and flash into the frdm_mcxw72 board in my hand,  the print message is  "capture cycle err" ,  it looks the board state is ok because i didn't inject the pwm signal , but the print message is the same after the pwm signal injected into PTA21 pins.     Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify what repository are you using? Are you using Upstream or Downstream? Also, is the example working on your side without modifications? Best Regards, Ricardo

Kinetis (.. /45/47/43；MCX W71/72/70) & MCX W23 Power 我的 工具（包括本地化） 本页专用于 Kinetis（KW35/KW38/KW45/KW47）和 MCX Wx（MCX W71/72 & MCX W23）Power 我的 工具。 它将帮助您估算应用（汽车或物联网）的功耗，并评估解决方案的电池寿命。 本页包含 2 个专用的电源配置工具： 1.'One 连接 Power Profiling Tool' 包括： 新增：基于仿真的KW43（汽车）和 MCX W70（工业物联网）产品独立组网 (SA)。 KW3x/KW4x（汽车）和 MCX W7x（工业物联网）产品独立组网 (SA)。 MCX W23 (IIoT) 产品独立组网 \\(SA\\)。 K32W0/QN9090、KW41、QN9080 产品独立组网 (SA)。 MCX W71 & W72 独立组网 \\(SA\\) 产品 (IIoT)。 新增：基于仿真的独立组网 (SA) (IIoT) 的 MCX W70 产品。 BLE 802.15.4 物质& ZED SmartFob应用程序（汽车）： BLE/KW45 + UWB Ranger4 + SE + 运动传感器 新产品：BLE/KW47 + UWB Ranger5 + SE + 运动传感器 2.CCC CS 应用程序（汽车） 1。'One Connectivity 电源分析工具' 概述： 安装文件可在 OneConnectivityPowerProfilingtool_SDK_26_03.ZIP 文件中。文件中。 请按照快速启动说明使用该工具。 要使用最新版本更新工具，只需下载 ZIP 中的 source_file.txt。 新增：One Connectivity 电源配置工具中提供适用于 BLE (KW45/47) 和 UWB (Ranger4/5) 的 Smart Fob 应用程序（汽车）   概述： 2.KW43 CCC CS 本地化 应用（汽车） 该工具基于 R&D 设计人员提供的模拟数据。 有关功耗和低功耗应用笔记，请参阅产品页面。以下是一些直接链接，以方便您使用： BLE AN14554 Kinetis KW47 蓝牙 LE 功率我的分析 版本.pdf AN14739 MCX W72 低功耗蓝牙我的分析 Rev2.0.pdf Kinetis KW45 和 K32W1 蓝牙 LE 功耗分析 MCX W71 蓝牙 LE 功耗分析 AN14659：MCX W23 低功耗蓝牙功耗分析|恩智浦半导体 CS AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf 802.15.4 AN14841 MCX W72 802.15.4 Matter 和 Zigbee 电源我的 analysis.pdf 电源管理 KW45/K32W148-电源管理单元硬件 MCXW71 - 电源管理单元硬件 请找到这个重要链接，使用 KW45/MCX W71 或 KW47/MCX W72 版本 PCB，以及所有与无线电性能和无线电认证 (CE/FCC/IC) 相关的内容： 使用KW45版本 PCB 的最佳方式（汽车配件...-恩智浦社区 首次成功设计 KW47（汽车级）或 MCX W72（物联网 / 工业级）PCB 的最佳方法 产品：K32W0 产品：K32W1 产品：KW 34|35|36 产品：KW 37|38|39 产品：KW41Z |31Z |21Z 产品：QN9080|SIP 产品：QN9090|30 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 嗨，埃弗雷特、 密码的设置是为了避免在太多细节上出现变化或竞争对手的基准。 很抱歉给您带来不便，但这是不可能的。 Re: Kinetis (KW35/38/KW45 & K32W1/MCX W71) Power Profile Tools (including Localization) 你好，克里斯托夫-梅纳德。 @christophe_menard能否提供Sheet 保护 密码 ，非常感谢。 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 你好 ， 我们想使用OneConnectivityPowerProfilingtool_SDK_26_03.zip，但检测到了木马程序。 如何使用这个工具？ 感谢您的支持 Re: Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization) 嗨@pierre_demeyer 我已向IT部门提交了工单以核实此事。 我会尽快通知您最新情况。

ユーティリティソフトウェアの問題 LPC1765FBD100で使用するNXP MCUXpresso IDE開発ソフトウェアはどのようにダウンロードできますか？ よろしくお願いします。 アナログ（ADC｜CMP｜DAC｜オペアンプ） コアとメモリ 開発委員会 Re: 工具软件问题 こんにちは。MCUXPressoのダウンロードリンクはこちらです：無料のプロフェッショナルARM開発ツール｜NXPセミコンダクターズ BR セレステ

スワップ要求: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK (Hse_Ip_ServiceRequest 経由) が 0xAA55A11E を返します こんにちは、現在S32K314HMSマイクロコントローラでA/Bスワップを試みています。交換リクエストは以下の方法で行われます。   /* ジョブステータス変数をリセットします */       SwapJobStatus = SWAP_JOB_PENDING ; /* HSEリクエストのサービス記述子を設定します */ swapHseSrvDescriptor.srvId = HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK; /* HSE IPレイヤーに送信するリクエストパラメータを設定します */       swapHseIpRequest.eReqType = HSE_IP_REQTYPE_ASYNC_POLL ;​​       swapHseIpRequest.u32Timeout = SWAP_TIMEOUT ;​​ swapHseIpRequest.pfCallback = SwapProcessMuChannelResponse; /* サービスリクエストをHSE IPレイヤーに送信します */ if (HSE_SRV_RSP_OK != Hse_Ip_ServiceRequest(SWAP_MU_INSTANCE, SWAP_MU_ADMIN_CHANNEL, &swapHseIpRequest, &swapHseSrvDescriptor))     {          結果= E_NOT_OK ;      } 次に、swapHseIpRequest.pfCallback ( SwapProcessMuChannelResponse)が呼び出され、返される HseResponse は次のようになります。 static void SwapProcessMuChannelResponse ( uint8 u8MuInstance , uint8 u8MuChannel ,                                              hseSrvResponse_t HseResponse 、 void * pCallbackParam ) {    if ( HseResponse == HSE_SRV_RSP_OK )     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK ;    }    それ以外     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED ;       VStdLib_ConvertUint32ToUint8ArrayBigEndian (( uint32 ) HseResponse , DebugData );    } } #define HSE_SRV_RSP_NOT_SUPPORTED (( hseSrvResponse_t ) 0xAA55A11EUL ) /**< @brief サポートされていない操作または機能です。 */ これは散発的に発生し、時にはスワップが期待どおりに機能することもあります。その理由は何でしょうか?HSEがこの返還コードを返答する理由やシナリオはどこで見つけられますか? このスワップは、リセットや電源オンの数分後にアップデートシーケンスの終了時にトリガーされます(つまりHSEは100%初期化されています)。 Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E こんにちは、@AlexI さん。 これはパラメータのない非常にシンプルなサービスです。私が考えられる唯一の説明は、データキャッシュメモリが原因であるということです。記述子がキャッシュ不可能なメモリ領域に配置されていることを確認してください。 一般的に、HSEとの通信に使用されるすべてのデータオブジェクトは、キャッシュを認識できないため、キャッシュ対応できないメモリに強制的に移行する必要があります。 今回の理由はおそらく違うかもしれませんが、DTCMメモリを使う場合、バックドアアドレスを使う必要があるということです。通常のアドレスは、そのメモリを所有するコアからのみ参照可能です。他のバス・マスタ(他のコア、DMA、HSEなど)はバックドアアドレスを通じてのみこのメモリを認識できます。 よろしくお願いいたします。 ルーカス

MPC5746C 在 115°C 环境温度下死机（无法启动，UART 无输出） 部件号： MPC5746C（电源架构 Z4，SDK：NXP MPC57xx 平台 SDK） 在 115°C 环境温度下进行热室测试时，我们基于 MPC5746C 的板在启动时完全无响应——没有任何 UART 控制台输出，并且在该温度下每次启动尝试都会发生这种情况。冷却后该部件似乎完全恢复：在室温下重新刷写/重启即可恢复正常运行，且不会造成永久性损坏。 有趣的是，即使电路板温度高达 115°C，我们仍然可以通过 PEMicro JTAG 调试探针成功地对闪存进行重新编程——我们通过在高温下刷入版本字符串递增的构建版本，并在冷却后读取新版本，证实了这一点。因此，调试探测闪存路径在 115°C 下工作；只有应用程序启动路径挂起/处于错误状态。 手册上说MCU可以承受高达125°C的温度。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ Re: MPC5746C hangs (no boot, no UART) at 115°C ambient 你好， 手册上说MCU可以承受高达125°C的温度。 是的，这不是问题。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ 由于这是你的定制板，而且问题在冷却后消失，我怀疑： 1. 时钟启动问题（可能性最高） 在 115°C 时： 外部晶体（FXOSC）启动时间增加。 振荡器增益裕度降低。 负载电容的电容值会随温度变化。 PCB漏电加剧。 调试器仍然可以访问该部分，因为调试逻辑使用自己的基础架构，并不依赖于应用程序是否执行到 main() 函数。 FXOSC 状态位 CMU时钟监测故障 仅 FIRC 启动实验 完全通过 FIRC 运行，并暂时禁用外部晶振。 JTAG编程在115°C下仍能正常工作，这有力地表明核心基础设施仍然运行正常，故障发生在应用程序启动路径的早期阶段，而不是闪存阵列本身。 顺祝商祺！ Peter

S12X serial MCU ,how to know the Code's START ADDRESS Now I have a Can Boot Demo , it can analysis S19 file and send data and offset address to S9S12G64 , MCU just need to write flash on Specify address which master Computer send. I need to know the start address of the APP code ,there is the app project 's prm file ,how to get the start address?  Re: S12X serial MCU ,how to know the Code's START ADDRESS Here is APP and Boot Code Re: S12X serial MCU ,how to know the Code's START ADDRESS Hello @李乐  Could you please send the MAP file or the S19 file for reference? Thank you. BR Alice Re: S12X serial MCU ,how to know the Code's START ADDRESS Hi @李乐  The start address of APP is 0xC000. Thank you. BR Alice

在 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

PCA2131: コントロールレジスタ2のAF（アラームフラグ）はクリアできません こんにちは、皆さん 現在、 PCA2131 オートモーティブ RTCをバッテリー・マネジメント・システム(BMS)に統合しています。 アラームフラグ（AF、Control_2レジスタ01hのビット4）がハイのままになるという問題が継続的に発生しています。基本的なSPI通信は完璧に動作しており、タイムレジスタの設定や読み込みは問題なくできます。しかし、初期化時にAFフラグをクリアできません。 重要な背景情報： AFフラグをクリアする前に、アラームレジスタ（0Ah～0Eh）内のすべてのアラーム有効化（AE_X）ビットが1（無効）に設定されていることを既に確認済みです。 私が実行しているシーケンス： Control_2（レジスタ01h）を読み取ります。AFビットは1と読み取られます。 ローカル構造体でAF = 0とAIE = 0に設定してフラグをクリアします。 変更したバイトをControl_2に書き戻す。 Control_2をもう一度読み込んでください。AFビットはまだ1です。 デバッグセッションのスクリーンショットを添付しました。クリア前、クリア操作中、および読み出し後のレジスタの状態を示しています。 私の質問： すべてのAE_Xビットが無効化されている場合、他にAFフラグを即座に再アサートさせる(またはクリアを妨げる)内部条件は何でしょうか? ご意見やご提案をいただければ大変ありがたいです！ Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヨゼフさん。 あなたのサポートと正しい方向への教えてくださり、ありがとうございます。 私はピコスコープを使ってSPIメッセージを確認し、ハードウェアの値が正しいことを検証しました。ご提案に従い、さらにコードをデバッグし、根本原因がビットフィールドの順序の不一致であることを確認しました。 不一致を修正しましたので、問題は完全に解決しました。ご協力ありがとうございました！ よろしくお願いします、 ヴィカス Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヴィカスさん。 ご確認いただきありがとうございます。データシートに記載されている PCA2131 の動作を考慮すると、AE_S/AE_M/AE_H/AE_D/AE_W がすべて 1 であると仮定すると、RTC が AF を正しく再トリガーしているようには見えません。最も可能性の高い原因はビットフィールドの順序ミスマッチです。3つの読み書きSPIメッセージの範囲をぜひ教えていただけますか?タイミングと、書き込みおよび読み出しされたレジスタ/ビットを確認するため。 敬具、 ヨゼフ Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear おっと、タイプミスでごめんなさい！正しいアドレスは0Ehから12hです。再確認したところ、コードに正しく記載されていたので、メッセージの誤りでした。 Re: PCA2131: AF (Alarm Flag) in Control Register 2 will not be able to clear こんにちは、ヴィカスさん。 警報記録を再度確認してください。これらのレジスタのアドレスは0Ehから12hです。 AE_xビットをすべて1に再度設定してみてください。 敬具、 ヨゼフ

GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Board/BSP: i.MX8M Plus, aarch64 Galcore version 6.4.11.p2.745085 ONNX Runtime with VSINPUExecutionProvider (statically linked against libtim-vx.so) Vivante OpenCL ICD present and functional (Vivante.icd → libVivanteOpenCL.so) Goal: Run ResNet50 inference benchmarks (MLPerf loadgen harness) on the GC7000UL 3D GPU core specifically, as a comparison point against existing NPU (VIP8000Nano) and CPU benchmark results already collected. What's confirmed working: clGetPlatformIDs/clGetDeviceIDs via the Vivante OpenCL ICD cleanly enumerates two independent devices under one platform: Device 0: GC7000UL.6204.0000 Device 1: VIP8000Nano-S+I.8002.0000 Both report CL_DEVICE_TYPE_ACCELERATOR, no errors, confirmed via a minimal C test program linked against libOpenCL.so → libGAL.so. What's blocking GPU dispatch via ORT: ort.get_available_providers() returns only ['VSINPUExecutionProvider', 'CPUExecutionProvider'] — no OpenCL-based EP. VSINPUExecutionProvider is statically linked to libtim-vx.so (OVXLIB/vsi_nn_* API). Symbol/string dump of both libtim-vx.so and libGAL.so shows no DEVICE_INDEX/DEVICE_ID-style env var or config surface — only behavior toggles (VIV_VX_ENABLE_SHADER, VSI_NN_ENABLE_*, etc). libGAL.so does export gcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndex at the raw HAL layer, but there's no visible plumbing from OVXLIB/TIM-VX down to that call which is  suggesting the graph compiler used by VSINPU may be hardcoded to target the NPU core only, regardless of device index. Specific question: Does TIM-VX / OVXLIB on this BSP (galcore 6.4.11.p2) support compiling and dispatching a graph to the GC7000UL as a general-compute target, or is the graph compiler NPU-only by design in this build, and how can I verify if it is possible to run it that way ?  If GPU-target graph compilation is supported upstream in TIM-VX but not enabled in this NXP-shipped build, is there a build flag / SDK component that exposes it? If there is no supported path through TIM-VX/ORT, is there an NXP-recommended way to run generic  inference on the GC7000UL directly (e.g. via the OpenCL/OpenVX layer, since that portion of the stack is confirmed functional) ,  a sample app, SDK component, or reference implementation we should be building against instead? as a currently a student, and trying to work on this implementation and running an ORT on TOP of the GPU, is there any way, or any other way to be able use the GPU for inference ?  Thank you very much  IMX8MPLUS  #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only HI @WaleedO, Thank you for contacting NXP Support. To run inference on the GPU, you should use the GPU delegate, which enables supported operations to be accelerated by the GPU instead of running entirely on the CPU. I recommend reviewing our Machine Learning User Guide to better understand the available execution backends, delegate configuration, supported frameworks, and example applications. The guide also includes step-by-step examples that can help you validate that the GPU delegate is being loaded correctly and that your model is executing as expected. If you encounter any issues during setup or execution, please share the model, BSP version, and the commands you are using, and I will be happy to assist further. Best regards, Alejandro Garcia Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only Hello @Chavira  Nice to meet you. After checking the documentation, the GPU delegate and the OpenCL path is used within  i.MX 95/952 GPU (Arm Mali G310). I am curently working on The IMX8MPLUS .  the imx8m Plus have this stack:  VX delegate ==> TIM-VX ==>  GPU/NPU (unified driver)  ==> I.MX 8 series NPU and GPU (GC7000,GC7000L, GC7000UL).  as per the documentation.  Currently, I am working with ONNX and ORT. When I run the execution, It is per default running on the NPU. Is there any way to use the OpenCL to work ont the IMX8MPLUS  GPU ? or if there is any manual override, or technique that I can implement, so that I can manually set the compilation toward either NPU or/And  GPU ?  Thank Your very much for your reply.  Kind regards,  IMX8MPLUS  #TIM-VX #VX-delegate