交换请求：通过 Hse_Ip_ServiceRequest 发送的 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK 返回 0xAA55A11E 您好，目前我正在尝试对 S32K314HMS 微控制器进行 A/B 交换。交换请求通过以下方式提出：   /* 重置作业状态变量 */       交换作业状态=交换作业待处理； /* 设置 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 层发送服务请求 */ 如果 (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 ） {    如果( HseResponse == HSE_SRV_RSP_OK )     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_OK ;    }    别的     {       vFotaH_Appl_SwapJobStatus = SWAP_JOB_FAILED ;       VStdLib_ConvertUint32ToUint8ArrayBigEndian （（ uint32 ） HseResponse ，调试数据）；    } } #define HSE_SRV_RSP_NOT_SUPPORTED (( hseSrvResponse_t ) 0xAA55A11EUL ) /**< @brief 不支持此操作或功能。 */ 这种情况偶尔会发生，有时交换会按预期进行。原因可能是什么？我可以在哪里找到 HSE 返回此返回代码的原因/情况？ 此交换是在更新序列结束时触发的，在RESET/上电几分钟后（因此 HSE 已 100% 初始化）。 Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E 嗨@AlexI 这是一个非常简单的服务，没有任何参数。我唯一的解释就是这是数据缓存内存造成的。请确保将描述符放置在不可缓存的内存中。 通常情况下，所有用于与 HSE 通信的数据对象都必须强制存储在不可缓存的内存中，因为 HSE 无法访问缓存。 虽然这可能不是本案的原因，但是：如果使用 DTCM 内存，则必须使用后门地址。普通地址仅对拥有该内存的核心可见。其他总线主控器（其他核心、DMA、HSE 等）只能通过后门地址看到此内存。 此致， Lukas Re: Swap request: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK via Hse_Ip_ServiceRequest returns 0xAA55A11E 感谢@lukaszadrapa 的回复。 我修改了实现方式，使swapHseSrvDescriptor 和swapHseIpRequest具有初始值，并在启动时由链接器初始化而不是在运行时初始化，现在可以正常工作了。

S32 Design Studio for ARM Version 2.2 许可证到期,麻烦帮忙延期，谢谢！ S32 Design Studio for ARM Version 2.2 许可证到期,麻烦帮忙延期，谢谢！ Re: S32 Design Studio for ARM Version 2.2 许可证到期,麻烦帮忙延期，谢谢！ 你好， 您的S32DS许可证已延期。

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 Re: S32G399A serial boot IO confirm Hi，MichaelTao Please refer to the attachment S32G_IOMUX.xlsx in the S32G3 Reference Manual to obtain more information regarding the pin correspondence as you described. Hope this information can help you. 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驱动程序的直接点对点功能？ Re: E9171 AMDPU with T1040 RDB Board 不要假设 T1040 平台上的 E9171 + AMDGPU 支持 FPGA→GPU PCIe P2P DMA。根据目前可获得的 AMDGPU 信息，直接 FPGA 到 AMDGPU 的 P2P 通常不作为标准 AMDGPU 功能得到支持，不像 NVIDIA GPUDirect RDMA 那样。   AMDGPU是否支持PCIe点对点（P2P）连接？ AMDGPU确实包含Linux P2P基础架构支持（PCI_P2PDMA），AMD KFD也有一个HSA_AMD_P2P选项，但这种支持主要针对以下情况： AMD GPU ↔ AMD GPU 通信 ROCm/HSA 计算环境 GPU 暴露出大 BAR 且平台/芯片组支持 PCIe P2P 路由的平台 Linux Kconfig 的描述明确提到了AMD GPU 之间的 P2P 通信。 FPGA → AMD GPU 直接 DMA？ AMD工程师曾公开表示： 目前尚不支持在 Xilinx FPGA 和 AMD GPU 之间实现 P2P 通信。 并建议采用主机内存注册变通方案，而不是真正的设备到设备 PCIe DMA。 因此： 通路 状态 AMD GPU ↔ AMD GPU 支持特定 ROCm 平台 FPGA ↔ AMD GPU 直接 PCIe DMA AMDGPU通常不支持此功能。 FPGA → 主机 DDR → GPU 支持 FPGA P2P缓冲区映射到主机内存并注册到GPU   T1040 是否支持 PCIe P2P？ 从 T1040 端来看，如果满足以下条件，PCIe 硬件本身可以通过交换机在端点之间转发内存读/写 TLP： PCIe交换机支持P2P路由， ACS重定向已禁用（取决于交换机）， 地址映射配置正确。 PCIe 协议本身并不能阻止端到端数据传输。但是， T1040/NXP 软件不会自动提供 AMDGPU-FPGA P2P 支持。关键问题在于： AMDGPU 导出 GPU 内存以供第三方 DMA 访问。 FPGA QDMA 可以获取 GPU BAR/VRAM 物理地址。 Linux IOMMU/P2PDMA 路径接受事务。 通常情况下，AMDGPU 的限制才是阻碍因素，而不是 T1040 PCIe 控制器本身的限制。 哪些方法可能适用于您的系统？ 当前拓扑结构： PCIe交换机 / \ FPGA（QDMA）E9171 GPU / T1040 RC 最有可能支持的流程： FPGA ---> DDR（T1040 内存） | v AMDGPU DMA | 显存 不保证有效： FPGA（QDMA）---> GPU显存 因为 AMDGPU 通常不会为任意 FPGA 设备公开类似 GPUDirect-RDMA 的接口。

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