FLEXCAN EDMA - 接收 CAN 消息突发时出现 ACK 错误 在 i.MXRT1176 上，我们使用 FLEXCAN 和 EDMA。（SDK 26.03） 我们定义了 DMA 传输完成的回调函数。 这是我们的流程： 1.调用 ` FLEXCAN_TransferReceiveFifoEDMA()` 开始传输。 2. DMA 传输完成后，调用用户定义的回调函数。 3. 从 DMA 缓冲区复制数据，并调用 `FLEXCAN_TransferReceiveFifoEDMA()` 继续接收消息。 4. 重复步骤 2-4 我们注意到，当我们从另一个节点以突发方式发送消息，且帧间间隔仅为最小值时，ACK 错误的数量会增加——iMX 无法确认消息。 从流程来看，每次 DMA 传输完成回调时，FLEXCAN 上的 DMA 都会被禁用。当调用 `FLEXCAN_TransferReceiveFifoEDMA()` 时，DMA 功能会重新启用。这可以通过调用 ` FLEXCAN_EnableRxFifoDMA()` 来实现。启用/禁用 DMA 会更新 FLEXCAN 的 MCR 寄存器中的 DMA 位，并且只能在冻结模式下进行。由于我们以突发方式接收消息，因此当 FLEXCAN 进入冻结模式时，可能正在进行传输，导致它无法确认接收到的消息。   我们确认，移除对 `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，以便自动激活下一个缓冲区。这需要连续的 DMA 接收路径，而不是反复重新启动 FLEXCAN_TransferReceiveFifoEDMA()。 此致， 加文

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の情報に基づくと、NVIDIA GPUDirect RDMAのように、FPGAとAMDGPU間の直接的なP2P通信は、AMDGPUの標準機能として一般的にはサポートされていません。   AMDGPUはPCIeピアツーピア(P2P)をサポートしていますか? AMDGPUにはLinuxのP2Pインフラストラクチャサポート(PCI_P2PDMA)があり、AMD KFDにはHSA_AMD_P2Pオプションがありますが、このサポートは主に以下の目的で文書化されています: AM 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パスはトランザクションを受け入れます。 通常、T1040 PCIeコントローラ自体よりもAMDGPUの制限がブロック要因となっています。 あなたのシステムでうまく機能しそうなものは何ですか？ 現在のトポロジー： PCIeスイッチ / \ FPGA(QDMA)E9171 GPU \ / T1040 RC 最も可能性の高いサポートフロー： FPGA →--> DDR（T1040メモリ） | V AMDGPU DMA | VRAM 動作保証はありません： FPGA(QDMA)---> GPU VRAM AMDGPUは一般的に任意のFPGAデバイス向けにGPUDirect-RDMAのようなインターフェースを公開しないからです。

交换请求：通过 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

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

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.