S32G399A serial boot IO confirm Hi  I am reading the S32G3 Reference Manual. The Serial Boot section mentions that the CAN and UART interfaces use: UART: RX = PAD[42], TX = PAD[41] CAN: RX = PAD[43], TX = PAD[44] However, I cannot find PAD[41], PAD[42], PAD[43], or PAD[44] in the SoC pad list or pin descriptions. Could you please clarify which physical SoC pins or signals correspond to PAD[41], PAD[42], PAD[43], and PAD[44]? Also, are these pads associated with a specific LINFlexD instance and FlexCAN instance used by the BootROM Serial Boot mode? Re: S32G399A serial boot IO confirm Hi,MichaelTao Thank you for contacting us. I have received your question and will help you to check it. BR Joey

工具软件问题 LPC1765FBD100使用的开发软件NXP MCUXpresso IDE，怎么下载、谢谢 Analog(ADC|CMP|DAC|OpAmps) Core and Memory Development Board Re: 工具软件问题 您好，MCUXPresso 下载链接可以在这里找到：Free Professional ARM Development Tools | NXP Semiconductors BR Celeste

PCA2131：控制寄存器 2 中的 AF（报警标志）将无法清除 大家好， 我目前正在将PCA2131汽车实时时钟集成到电池管理系统 (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。最可能的原因是位域顺序不匹配。能否请您获取并分享一下读取和写入 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。 最诚挚的问候， 约瑟夫

E9171 AMDPU 带 T1040 RDB 板 我正在使用E9171 AMDGPU和T1040 NXP主板，请问这款GPU是否支持使用AMDGPU进行点对点数据传输？NXP主板通过PCIe交换机连接到FPGA和GPU。该GPU应该能够使用QDMA驱动程序直接从FPGA获取数据，另外，该NXP板是否支持使用AMDGPU驱动程序的直接点对点功能？

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 ジョーイ

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 许可证字符串。 由此给您带来的不便，我深表歉意。 问候， 爱德华多。

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.

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?

S32DSライセンスの有効期限が切れました。 サポートの皆さん、こんにちは。 有効期限が切れたライセンス番号FF6A-EDA4-CDF0-7186の延長にご協力ください。 よろしくお願いいたします。 マーカス アクティベーション | インストール | ライセンス | インストーラーのダウンロード Re: S32DS License Expired. ライセンスの延長は不可能だと思います。ライセンスを購入する必要があるかもしれません

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

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?

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!

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 乔伊

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エラーも解消されました。これが実装上の問題なのか、それとも別の方法で再設計すべきか確認していただけますか?