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 こんにちは、マイケルタオ お問い合わせいただきありがとうございます。 ご質問を拝受いたしました。確認させていただきます。 BR ジョーイ Re: S32G399A serial boot IO confirm こんにちは、 MichaelTao あなたが述べたピン対応についての詳細は、S32G3リファレンスマニュアルの添付資料S32G_IOMUX.xlsxを参照してください。 この情報があなたの助けになれば幸いです。 BR ジョーイ

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"]，   所有者：“谷歌”，   设置：“com.google.android.nfcservices_compressed.apks”，   文件名：“com.google.android.nfcservices_compressed.apex”，   exported_bootclasspath_fragments: ["com.android.nfcservices-bootclasspath-fragment"],   } 请问在这种情况下如何导入NXP补丁？是否有其他解决方案？对于其他使用 NXP NFC 芯片的客户，他们采取了哪些方法来通过 EDLA 认证，同时保持完整的 NFC 功能？ Re: PN7221+Android16 EDLA certification issues 你好@zhangkai 根据我们的分析，该问题很可能是由使用谷歌预构建的 NFC APEX (com.android.nfcservices) 的 EDLA 版本引起的。而不是集成了 NXP Android 中间件的 NFC 模块。 NXP Android 16 解决方案扩展了 Android NFC 协议栈的多个层，包括 NFC 框架、NFC 服务、EMVCo 框架、HAL 和相关库。如果使用 Google 预置的 NFC 服务，则可能仅保留标准 NFC 功能，而 NXP 特有的功能（例如 EMVCo 功能、固件更新支持和其他中间件扩展）可能无法激活。 目前，NXP 的 Android 16 移植文档没有描述直接修补或修改 Google 预构建的 EDLA NFC APEX 的方法。NXP 的典型集成方法是基于 AOSP 源代码集成，并使用 NXP 中间件重建 NFC 协议栈。 对于需要完整 PN7221 功能的客户，我们建议评估是否可以在包含 NXP NFC 中间件的情况下重建 NFC APEX，或者咨询 Google/OEM 支持，了解如何在保持 EDLA 合规性的同时定制 EDLA NFC 模块。

安卓和iOS应用注册功能无法使用。 我已注册了我的安卓应用。 但是尝试在 iOS 上执行相同的操作时，却显示“软件包名称已存在”。 这完全说不通，Android 和 iOS 可以使用相同的软件包名称，因为它们是两个不同的平台。 应用注册 Re: Register app for Android and iOS doesn't work 你好@Skel 希望你一切都好。 尽管它们是不同的平台，但根据UG10044和UG10045第 2 章，软件包字符串在 NXP 服务器上必须是唯一的，才能获得 TapLinx 许可证字符串。 由此给您带来的不便，我深表歉意。 问候， 爱德华多。 Re: Register app for Android and iOS doesn't work @EduardoZamora你好， 如何将我的iOS应用迁移到Android平台？

Register app for Android and iOS doesn't work I registered my app for Android, But when trying to do the same for iOS it says "Package Name already exists", Which makes no sense, Android and iOS can have the same package name, it's 2 different platforms. App registration Re: Register app for Android and iOS doesn't work Hello @Skel Hope you are doing well. Although they are different platforms, according to UG10044 and UG10045 Chapter 2, the package string must be unique on the NXP Server for getting a TapLinx license string. I apologize for the inconvenience this might cause you. Regards, Eduardo. Re: Register app for Android and iOS doesn't work @EduardoZamora Hi, How can i transfer my iOS app to Android?

E9171 AMDPU with T1040 RDB Board I Am using E9171 Amdgpu with T1040 NXP Board, here does this GPU supports per to peer data transfer using amdgpu.? this NXP is connected to FPGA and GPU via PCIe switch. this GPU should be able able to get data directly from FPGA using QDMA driver and also  does this NXP board supports direct peer to peer feature using AMDGPU driver? Re: E9171 AMDPU with T1040 RDB Board Do not assume that E9171 + AMDGPU on a T1040 platform supports FPGA→GPU PCIe P2P DMA. Based on currently available AMDGPU information, direct FPGA-to-AMDGPU P2P is not generally supported as a standard AMDGPU feature in the same way that NVIDIA GPUDirect RDMA is.   Does AMDGPU support PCIe Peer-to-Peer (P2P)? AMDGPU does contain Linux P2P infrastructure support (PCI_P2PDMA) and AMD KFD has an HSA_AMD_P2P option, but this support is primarily documented for: AMD GPU ↔ AMD GPU communication ROCm/HSA compute environments Platforms where the GPU exposes a large BAR and the platform/chipset allows PCIe P2P routing The Linux Kconfig description explicitly mentions P2P communication between AMD GPUs. FPGA → AMD GPU direct DMA? AMD engineers have publicly stated that: achieving P2P between Xilinx FPGA and AMD GPU is currently not directly supported and suggested a host-memory registration workaround instead of true device-to-device PCIe DMA. Therefore: Path Status AMD GPU ↔ AMD GPU Supported on specific ROCm platforms FPGA ↔ AMD GPU direct PCIe DMA Not generally supported by AMDGPU FPGA → Host DDR → GPU Supported FPGA P2P buffer mapped into host memory and registered with GPU   Does T1040 support PCIe P2P? From the T1040 side, PCIe hardware itself can forward Memory Read/Write TLPs between endpoints through a switch if: the PCIe switch allows P2P routing, ACS redirect is disabled (depends on switch), address translation is configured correctly. PCIe as a protocol does not prevent endpoint-to-endpoint transfers. However, T1040/NXP software does not automatically provide AMDGPU-FPGA P2P support. The critical question is whether: AMDGPU exports GPU memory for third-party DMA access. FPGA QDMA can obtain GPU BAR/VRAM physical addresses. Linux IOMMU/P2PDMA path accepts the transaction. The AMDGPU limitation is typically the blocking factor rather than the T1040 PCIe controller itself. What is likely to work on your system? Current topology:           PCIe Switch            /                     \ FPGA(QDMA)    E9171 GPU            \                       /              T1040 RC Most likely supported flow: FPGA ---> DDR (T1040 memory) | v AMDGPU DMA | VRAM Not guaranteed to work: FPGA(QDMA) ---> GPU VRAM because AMDGPU generally does not expose a GPUDirect-RDMA-like interface for arbitrary FPGA devices.

S32DSライセンスの有効期限が切れました。 サポートの皆さん、こんにちは。 有効期限が切れたライセンス番号FF6A-EDA4-CDF0-7186の延長にご協力ください。 よろしくお願いいたします。 マーカス アクティベーション | インストール | ライセンス | インストーラーのダウンロード Re: S32DS License Expired. ライセンスの延長は不可能だと思います。ライセンスを購入する必要があるかもしれません Re: S32DS License Expired. こんにちは、マーカスさん。 お客様のS32DSライセンスが延長されました。以前使用していたコードを使って、S32DSを再度有効化してください。 Re: S32DS License Expired. ジリさん、ありがとうございます！ Re: S32DS License Expired. こんにちは、 これはARM 2018.R1用のS32DS向けです。ライセンスの延長にご協力ください。 よろしくお願いいたします。 マーカス

Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hello, currently I am trying to perform an A/B swap on an S32K314HMS microcontroller. The swap is requested via:         /* Reset the job status variable */       SwapJobStatus = SWAP_JOB_PENDING;       /* Set the service descriptor for the HSE request */       swapHseSrvDescriptor.srvId = HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK;       /* Set the request parameters to be sent to Hse Ip layer */       swapHseIpRequest.eReqType = HSE_IP_REQTYPE_ASYNC_POLL;       swapHseIpRequest.u32Timeout = SWAP_TIMEOUT;       swapHseIpRequest.pfCallback = SwapProcessMuChannelResponse;       /* Send the service request to Hse Ip layer */       if (HSE_SRV_RSP_OK != Hse_Ip_ServiceRequest(SWAP_MU_INSTANCE, SWAP_MU_ADMIN_CHANNEL, &swapHseIpRequest, &swapHseSrvDescriptor))       {          result = E_NOT_OK;       } Then swapHseIpRequest.pfCallback (SwapProcessMuChannelResponse) will be reached and the returned HseResponse will be: static void SwapProcessMuChannelResponse( uint8 u8MuInstance, uint8 u8MuChannel,                                              hseSrvResponse_t HseResponse, void* pCallbackParam ) {    if (HseResponse == HSE_SRV_RSP_OK)    {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK;    }    else    {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED;       VStdLib_ConvertUint32ToUint8ArrayBigEndian((uint32)HseResponse, DebugData);    } } #define HSE_SRV_RSP_NOT_SUPPORTED               ((hseSrvResponse_t)0xAA55A11EUL)  /**< @brief The operation or feature not supported. */ This happens sporadically, sometimes the swap works as expected. What could be the reason ? Where can I find the reasons / scenarios when HSE responds with this return code ? This swap is triggered at the end of an update sequence, a couple of minutes after reset/power on (so HSE is 100% initialized). Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Hi @AlexI  This is very simple service with no parameters. The only explanation I have is that it is caused by data cache memory. Please make sure that the descriptor is placed in non-cacheable memory. Generally, all data objects used for communication with HSE must be forced to non-cacheable memory because HSE can’t see the cache. Probably not the reason in this case but: if DTCM memory is used, it’s necessary to use backdoor addresses. Normal addresses are visible only for a core which owns the memory. Other bus masters (other cores, DMA, HSE…) can see this memory only via backdoor addresses. Regards, Lukas Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E Thank you for this response @lukaszadrapa. I changed the implementation so that swapHseSrvDescriptor & swapHseIpRequest have initial values and are initialized by the linker at startup and not at runtime, now it works. 

FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages On i.MXRT1176 we are using FLEXCAN with EDMA. (SDK 26.03) We have a callback defined for DMA transfer complete. This is our flow: 1. Call `FLEXCAN_TransferReceiveFifoEDMA()` to start the transfer. 2. On DMA transfer completion, user-defined callback is called. 3. Data is copied from DMA buffers, and `FLEXCAN_TransferReceiveFifoEDMA()` is called to continue receiving messages. 4. Repeat Steps 2-4 We noticed that when we transmit messages from another node in a burst with just the bare minimum Inter-Frame Space, we see an increase in number of ACK errors - the iMX is unable to ACK the messages.  Going through the flow, it appears that every time there is a DMA transfer complete callback, DMA is disabled on FLEXCAN. It is re-enabled again when `FLEXCAN_TransferReceiveFifoEDMA()` is called.  This is done by calling `FLEXCAN_EnableRxFifoDMA()`. The enabling/disabling DMA updates the DMA bit in FLEXCAN's MCR register, and it can only be done in Freeze mode. As we are receiving messages in a burst, it is possible that a transmission is actively in progress when FLEXCAN is put it freeze mode. And it is unable to ACK the incoming message.   We confirmed that removing that call to `FLEXCAN_EnableRxFifoDMA()` removes all ACK errors, though now we are dropping some messages. Also, we tried spacing out the messages, and that also got rid of the ACK errors. Can you please confirm if this is indeed an issue with the implementation, or if we should be rearchitecting it in a different way? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages Hi @r-uv , Thank you for the detailed analysis. Your observation is consistent with the SDK  implementation. FLEXCAN_TransferReceiveFifoEDMA() is a finite-length transactional API. After each DMA completion, the driver disables the Rx FIFO DMA request, and the next call enables it again. Because changing MCR[DMA] requires Freeze mode, the next frame in minimum-IFS traffic may arrive before FlexCAN returns to Normal mode, resulting in a missed ACK. This also explains why removing the repeated DMA enable/disable operation eliminates the ACK errors but still causes dropped frames: the Freeze-related ACK gap is removed, but the eDMA transfer is not continuously rearmed. For continuous burst traffic, we recommend keeping the Rx FIFO DMA request enabled and using hardware-chained ping-pong/scatter-gather TCDs so that the next buffer is activated automatically. This requires a continuous DMA receive path rather than repeatedly restarting FLEXCAN_TransferReceiveFifoEDMA(). Best regards, Gavin

My S32 Design Studio for ARM Version 2.2 license has expired. Could you please help me extend it? Thank you! My S32 Design Studio for ARM Version 2.2 license has expired. Could you please help me extend it? Thank you! Re: S32 Design Studio for ARM Version 2.2 许可证到期,麻烦帮忙延期，谢谢！ Hi,  your S32DS license has been extended. 

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 Re: S32DS License Expired. Hi Marcus,  your S32DS license has been extended. Please activate S32DS again with your old code.  Re: S32DS License Expired. Hi, This is meant for S32DS for ARM 2018.R1.  Please assist to extend the license. Regards, Marcus Re: S32DS License Expired. Thank you Jiri !

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

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 乔伊 Re: S32G399A serial boot IO confirm 您好， MichaelTao 请参考 S32G3 参考手册中的附件 S32G_IOMUX.xlsx，以获取有关您所描述的引脚对应关系的更多信息。 希望这些信息对您有所帮助。 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エラーも解消されました。これが実装上の問題なのか、それとも別の方法で再設計すべきか確認していただけますか? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages こんにちは、@r-uv さん。 詳細な分析をありがとうございました。あなたの観察はSDKの実装と一致しています。 FLEXCAN_TransferReceiveFifoEDMA() は、有限長のトランザクション API です。DMA完了の後、ドライバーはRx FIFO DMA要求を無効化し、次の呼び出しで再び有効化します。MCR[DMA]を変更するにはフリーズモードが必要となるため、最小IFSトラフィックの次のフレームがFlexCANが通常モードに戻る前に到着する可能性があり、その結果ACKが欠落する可能性があります。 これは、繰り返し行われるDMAの有効化/無効化操作を削除するとACKエラーは解消されるものの、フレームのドロップが依然として発生する理由も説明しています。フリーズに関連するACKギャップは解消されますが、eDMA転送は継続的に再有効化されないためです。 連続的なバーストトラフィックについては、Rx FIFO DMA要求を有効にし、ハードウェアチェーンのピンポン/散乱集いTCDを使用して次のバッファが自動的に有効化されるようにすることを推奨します。これは、FLEXCAN_TransferReceiveFifoEDMA() を繰り返し再起動するのではなく、連続した DMA 受信パスを必要とします。 よろしくお願いします、 ギャビン

私のS32 Design Studio for ARMバージョン2.2のライセンスが期限切れになりました。延長手続きをお願いできますでしょうか？よろしくお願いいたします。 私のS32 Design Studio for ARMバージョン2.2のライセンスが期限切れになりました。延長手続きをお願いできますでしょうか？よろしくお願いいたします。 Re: S32 Design Studio for ARM Version 2.2 许可证到期,麻烦帮忙延期，谢谢！ こんにちは、 お客様のS32DSライセンスが延長されました。

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 Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Thank you for the insight @petervlna. Following up on this, my colleague @mnargund and me investigated further, we were able to get the MPC5746C booting successfully at 115°C. Here is a summary of what we found. Root Cause: During pre-initialization, we configured the system to bring up FIRC, FXOSC, and PLL, and then switched the system clock from FIRC to PLL. Following this, we triggered a mode transition to DRUN mode (even though the system was already in DRUN mode by default, a transition to the same mode is required for the new configuration to take effect, as mentioned in the manual), and polled MC_ME_GS.MTRANS to wait for the transition to complete. However, even after MC_ME_GS.MTRANS cleared, the code faulted with an IVOR1 exception, maybe indicating the transition had not fully stabilized by the time execution continued. At elevated temperatures (115°C), the transition appears to take longer than at room temperature, causing the system to be in an inconsistent state when the next instructions were executed. Workaround applied: We inserted an explicit software delay after the MC_ME_GS.MTRANS poll and before proceeding with the rest of initialization. With a 500 ms delay, the boot is consistently successful at 115°C. We also tested a 100 ms delay, which also works reliably in our setup.  Is there a maximum recommended software delay that can safely be inserted at this point in initialization? Is there a recommended practice to ensure reliable clock stabilization before proceeding, across the full operating temperature range up to 125°C?

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のサポートに相談することをお勧めします。

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