RF Power Amplifier Design - MRF13750H Hello! I am designing an 805 MHz RF power amplifier using the MRF13750H, and my design is based on the 915 MHz reference circuit found in the datasheet. However, I only have access to Usimmics for simulating the matching networks; I do not have access to the software NXP uses to open their design files. Therefore, to design the matching networks, I am requesting the complete schematic for the MRF13750H 915 MHz reference circuit from NXP, including the microstrip line dimensions, as this information is not provided in the datasheet. If possible, I would also like to request the large-signal model impedances at 805 MHz; otherwise, I will base my design on the values ​​provided for 915 MHz. The reference circuit at 915Mhz and the datasheet is attached below. On the other hand, if anyone knows a different method for designing the matching networks at 805 MHz, I would appreciate the input.

我们能否在 i.mx9 中使用已配置的证书或密钥来设置 HTTPS 连接或 TLS 连接？ i.MX93 上配置的证书和私钥可以直接用于建立 HTTPS/TLS 连接吗？如果可以，那么访问和使用这些凭据进行客户端/服务器身份验证和 mTLS 实现的推荐方法是什么？ 配置完成后，安全对象 blob 会出现在 /etc/ele/ 中，那么在实际的 HTTPS/TLS 连接中使用这些已配置的凭据的推荐工作流程是什么？ Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i 嗨， @Manuel_Salas 谢谢你的回复。 关于 mbedTLS/opaque-key 指南——我们这边已经解决了私钥的问题。 剩下的问题具体是关于证书，该证书通过 EL2GO 配置，并与私钥一起存储在 /etc/ele/ 中。由于证书是公共数据，我们需要将其提取为纯 DER 格式，以便交给 mbedtls_x509_crt_parse_der() 进行 TLS 握手——与密钥不同，它不需要保持不透明。 支持的 SMW/PSA 调用是什么，才能检索已配置证书对象的明文 DER 字节？ 具体来说：它是通过 psa_ps_get() / psa_its_get()（PSA 保护存储/内部可信存储）使用对象 ID 作为 UID 公开，还是通过不同的 SMW API 公开？我们在已安装的 SMW 头文件中看到了 protected_storage.h 和 internal_trusted_storage.h，但在基于它进行构建之前，我们想确认这是否是证书对象的预期路径。 Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i 你好@NEXUSNERD 希望你一切都好。 在 i.MX93 上，配置流程的设计使得私钥始终受到ELE的保护。 因此，存储在 /etc/ele/ 中的 blob 是安全的对象表示，允许 ELE 重新加载或引用已配置的密钥材料，它们不应被视为普通的 TLS 密钥文件。 您可以查看imx-secure-enclave (Mbed-TLS)。 顺祝商祺！ 萨拉斯。

LED 的 IO 扩展 我目前正在设计用于定制测量设备的开关矩阵板。 为了路由信号，我计划使用光中继器，准确地说是 G3VM-61DR1。 所以我需要控制超过 250 个！以某种方式使用 LED（1.5-1.8V 6-8mA）。 同时开启的设备数量将少于25台。 供电电压为3.3V或更低，温度应在40°C左右。 我们只需要打开或关闭它们，不需要调光或PWM调光。 我不想使用LED驱动器，因为它可能会引入噪声。 我无法使用传统的矩阵式电路，因为无法预知哪些开关会同时处于开启状态。 因此，唯一的选择是为每个继电器/LED 提供一个独立的输出，您的 IO 扩展器看起来很有希望实现这一点，例如PCAL6524 。 由于通道数量较多，我希望尽可能减少每个通道的元器件数量，因此我有几个问题： 我能否依赖 Agile IO 设备的 7.5mA 电流设置，而省略 LED 串联电阻？ 如果可以的话，可能会有哪些副作用？ 由于这些设备最初配置为输入，因此当它们用于控制 LED 时，某些设备会经历高电流（例如，PCA9535A数据手册第 14/15 页）。对于这么多通道来说，为每个通道使用上拉电阻的传统解决方法并不理想。这是否也会影响 Agile IO 设备？ 能否通过给 LED 提供 3.3V 电压，给扩展器提供 1.65V 电压来解决这个问题？ 先感谢您 奥托 Re: IO Expansion for LEDs PCAL6524 非常适合驱动大量的光继电器和 LED。然而，敏捷 I/O 驱动能力并不是为了取代所需的串联限流电阻器。为了降低上电时 I/O 仍处于输入状态时出现意外电流的风险，可以考虑使用 VDD(P) 较低的 3.3 V LED 电源，或者实现全局 LED 电源开关等方案。然而，每个 LED 通道都应该始终保留单独的限流电阻。

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 Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages Thanks for the response. Are there any plans of adding this support in the SDK? A continuous DMA based implementation instead of just the current transactional API implementation? 

求找适用于 PCF8563TS/5,118 的电容 我正在使用 PCF8563TS/5,118 IC，想正确连接 OSCI 引脚上的外部电容。 我正在使用 50k ESR、12.5pF 32.568KHz 的晶体，尽可能短的走线，原理图与数据手册中的应用图完全相同。 我查阅了数据手册和 UM10301，尝试进行计算，以了解该设备。我发现很难找到一种清晰的方法来计算外部电容的值，因为数据表在同一主题的不同页面上提到了并联和串联，即 OSCI 和 OSCO。 我看到外部 OSCI 和 OSCO 引脚并联了一个内部 25pF 电容。数据手册中的表 30 表明 CL 是并联计算的，但有一个注释显示，CL 是串联电容的计算方法。 我找不到能让设备正常工作的外接电容。没有收到 I2C 响应。我尝试了 25pF、22.5pF、20pF、25pF、10pF、8.2pF、6pF。所有 0603 C0G/NP0 帽。 我通过完全不放置电容器，成功地让它在另一块板上工作了。经过计算，这根本说不通。 我想请您举例说明一下如何计算这些输入值（12.5pF 50k ESR 晶体），因为我无论通过计算还是暴力破解都无法使其正常工作。 Re: Help finding capacitor for PCF8563TS/5,118 是的，那是内置电容的数值，我在自己的帖子中也提到过。我已阅读过该文件。 如果你能把你想表达的意思写下来，那会更有帮助。感谢您抽出时间。 Re: Help finding capacitor for PCF8563TS/5,118 UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123 和 PCA21125 用户手册 Re: Help finding capacitor for PCF8563TS/5,118 亲爱的戴维： db16122 正确地指出了UM10301 中的表 3。如果您的目标负载电容为 12.5pF，则需要在 OSCI 引脚上连接一个 25pF 的中间值的微调电容。 这个 25pF 值可以通过表 30 下方的公式计算得出。在PCF8563 数据手册中。 其中 CL 为目标负载电容，在本例中为 12.5pF。 Cosco 是已知的内部电容，25pF。 根据公式，可以推导出 Ctrim 值： CL=Ctrim*Cosco/(Ctrim+Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim 边际贡献 = CL * Cosco / (Cosco - CL) = 12.5 * 25 / (25 - 12.5) = 312.5 / 12.5 Ctrim=25pF 由于内部 Cosco 电容还有余量，因此需要可变微调电容。Cosco 值可能在 15pF 到 35pF 之间波动。 最诚挚的问候， 约瑟夫

无法更新 i.MX95 FlexSPI 启动映像的 APP 容器软件版本 各位专家好， 我正在使用 i.MX95 平台，并启用ROLLBACK_INDEX_IN_CONTAINER 的回滚保护功能。 我在local.conf文件中引入了以下变量： export ROLLBACK_INDEX_IN_CONTAINER = "1" 该值会在整个构建过程中传递，构建日志证实mkimage_imx8被调用时使用了“1”。 构建eMMC 启动映像时，解析生成的镜像显示容器软件版本已正确更新。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   然而，在构建FlexSPI 启动镜像（ imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ）时，解析该镜像仍然报告默认的软件版本。 ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 我在 iMX95/soc.mak 中注意到一个有趣的地方，因为在构建 flash_a55_flexspi 时没有包含 sw_version。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 我的问题是： ROLLBACK_INDEX_IN_CONTAINER是否预期会更新 FlexSPI 启动映像的软件版本？ FlexSPI 镜像是否遵循不同的容器生成流程，需要单独配置回滚索引/软件版本？ 这是 i.MX95 imx-mkimage版本流程中已知的限制或问题吗？ 如果有人已成功在 i.MX95 上为 FlexSPI 启动映像启用ROLLBACK_INDEX_IN_CONTAINER ，能否分享一下预期流程或所需的任何其他配置？ 提前感谢！ 顺祝商祺！ 阿伦·库马尔 Re: Unable to update APP container software version for i.MX95 FlexSPI boot image 你好@arun16598 FlexSPI 镜像不是 AHAB 格式的另一种变体，而是采用了一种组合过程，即先生成引导容器，然后附加 U-Boot/ATF 容器。您的-sw_version 1已在u-boot-atf-container.img上设置；但是，包含 SM/M33、OEI、SPL 和 FCB 的 APP 容器（ flash_a55_flexspi首先创建）没有传递-sw_version选项，因此该容器仍然显示SW 版本：0。ROLLBACK_INDEX_IN_CONTAINER用于生成辅助 U-Boot/ATF APP 容器，但它没有传递给flash_a55_flexspi创建的主 APP 容器。如果第一个 FlexSPI APP 容器需要相同的软件版本，则还必须将-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)添加到flash_a55_flexspi中的 mkimage_imx8 调用中。 如果目标是真正实现 AHAB 防回滚强制执行，则需要验证和配置的关键设置是fuse_version和-fuse_version ，而不仅仅是sw_version 。S PSDK 的 i.MX95 防回滚示例明确指出，OEM 防回滚使用 AHAB 容器 YAML 中指定的fuse_version ，然后通过 ELE 的OEM_FW_FUSE提交过程提交该版本。 此致， 志明

AUTOSAR マカルMPC5744P こんにちは、MPC5744P用のAUTOSAR MCALアプリケーションを無料で作成できるコンパイラオプションはありますか? Re: AUTOSAR MCAL MPC5744P こんにちは、 レガシーのAUTOSAR MCAL for MPC5744Pパッケージ(MPC574xP MCAL 4.x)では、公式に検証されたツールチェーンは通常以下の通りです: Wind River Diab Compiler（最も一般的な資格） グリーンヒルズコンパイラ（GHS） 実際には、AUTOSAR MCALには公式にサポートされているフリーコンパイラMPC5744P提供されていません。 MPC5744Pエコシステムは一般的な組み込み開発のためにS32 Design Studio for Power Architectureをサポートする一方で、MCALパッケージ自体は主にDiabとGHSで開発・検証されました。 DEVKIT-MPC5744P情報にはGCC(S32DS経由)、GHS、Cosmic、その他のMPC5744P開発ツールチェーンが掲載されていますが、それがAUTOSAR MCALリリースがGCCに適格であることを意味しません。 検証済みコンパイラのリストは常にMCALパッケージに付属するリリースノートに記載されています。 よろしくお願いします、 ピーター

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()。 此致， 加文 Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages 谢谢你的回复。SDK 是否有计划添加此功能的支持？是采用基于连续DMA的实现方式，还是仅仅采用当前的事务性API实现方式？

CodeWarriorのライセンスに関する質問 私たちはレガシー製品でCodeWarrior 10.6を使っており、新しいPCにインストールする必要があります。CodeWarrior 10.6のオフラインインストールファイルが見つからず、オンラインインストールも失敗します（ダウンロードサイトが見つかりません）。 10.7のダウンロードは見つかります。弊社は10.6用の永続的なフローティングライセンスを保有しています。これらは10.7でも動作し続けるのでしょうか?それともオフラインの10.6インストールを教えてもらえますか? よろしくお願いします。

LED用IO拡張機能 現在、カスタム測定機器用のスイッチマトリックスボードで設計しています。 信号のルーティングには、光リレー、具体的にはG3VM-61DR1を使用する予定です。 だから>250をコントロールしなきゃいけないんだ!LED（1.5～1.8V、6～8mA）何らかの方法で。 同時にオンにできるのは25個未満のみです 供給電圧は3.3V以下、温度は40℃前後である必要があります。 オンオフするだけでよく、調光やPWM制御は不要です。 LEDドライバはノイズが出るかもしれないので使いたくありません どのスイッチが同時にオンになるか分からないため、従来のマトリックス配置は使えません ですので、唯一の選択肢は各リレー/LEDごとに独立した出力を持つことです。例えば、IOエクスパンダーはその用途で有望に見えます。 PCAL6524。 チャネル数が多いため、チャネルごとのコンポーネント数をできるだけ減らしたいので、いくつか質問があります。 Agile IOデバイスの7.5mA電流設定を頼りにして、LED直列抵抗を省いてもいいのでしょうか? これが問題ない場合、考えられる副作用は何ですか？ デバイスは入力として構成されて開始されるため、LED の制御に使用される場合、高電流が発生する場合があります (例:PCA9535Aデータシート14/15ページ）。各チャネルにプルアップを付けるという古典的な解決策は、多くのチャネルにはあまり良くありません。これはAgile IOデバイスにも影響しますか？ LEDには3.3V、エキスパンダーには1.65Vを供給することで、この問題を回避できますか? よろしくお願いします オットー Re: IO Expansion for LEDs PCAL6524は、多数の光リレーやLEDを駆動するのに最適です。ただし、Agile I/Oの駆動能力は、必要な直列電流制限抵抗器を置き換えることを意図したものではありません。I/Oがまだ入力状態にある状態で電源を入れる際の意図しない電流のリスクを軽減するため、3.3V LED電源にVDD(P)を低く設定したり、グローバルLED電源スイッチの実装などが検討されることがあります。それでも、各LEDチャネルごとに個別の電流制限抵抗は常に保持すべきです。

S32K328 HSE-B：推荐的采用 Mem_43_INFLS 进行 A/B 交换的架构（无需 Vector FOTA） 您好，NXP团队， 我们目前正处于为运行在 S32K328 上的现有应用程序添加 OTA A/B 交换支持的设计和实施阶段。 这是初步实现，我们是在现有软件的基础上扩展 OTA 功能，而不是集成完整的 FOTA 框架。 当前环境 MCU：S32K328（8 MB P-Flash） AUTOSAR 堆栈：矢量 MICROSAR RTD：S32K3_RTD_6_0_0_QLP04_D2508_ASR_REL_4_7_REV_0000_20250822 二进制传输接口：UART 镜像激活服务：HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE A/B 切换可通过 RTD 配置实现 OTA 二进制文件通过 UART 由定制的 OTA CDD 接收。 我们目前的 Vector 配置仅包含用于 NvM/Fee (D-Flash) 的 MemAccM。没有用于对应用程序 P-Flash 进行编程的 MemAccM 配置，我们也没有使用 Vector OTA/FOTA。 因此，我们正在考虑使用 OTA CDD 中的 Mem_43_INFLS 直接擦除和编程非活动应用程序闪存。 我们希望就以下几点获得指导。 1. 推荐方法 在不使用 Vector 的 OTA/FOTA 软件包的情况下，Mem_43_INFLS 是否是 A/B 交换设置中管理 OTA 映像编程的推荐底层驱动程序？ 或者，MemAccM 是否应该扩展到涵盖 P-Flash 编程，即使是针对自定义 OTA 实现？ 2. 非活动闪存块寻址 启用 HSE A/B 切换后： 非活动应用程序 P-Flash 块是否始终通过内存布局中定义的固定物理地址进行访问？ HSE 是否为被动模块提供了任何逻辑映射或抽象？ 3. 激活的前提条件 成功执行 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK 的必要前提条件是什么？ 例如： 图像头格式 元数据要求 对齐约束 身份验证/签名要求 闪光状态或属性 4. Flash 控制器并发性 S32K328 上的 C40 闪存控制器是否支持 D-Flash（费用/NvM）和 P-Flash（非活动块）之间的并发操作？ 如果不是，那么推荐的同步策略是什么？ 应用层调度 RTD司机仲裁 MemAccM 使用情况 5. 推荐架构 以下架构是否符合恩智浦半导体（NXP）的建议？ UART ↓ 自定义OTA CDD ↓ Mem_43_INFLS（擦除/写入非活动 P-Flash） ↓ 图像验证 ↓ HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK ↓ 系统重置 ↓ HSE/BAF激活被动阻断 我们特别想了解这种轻量级方法是否合适，是否符合 HSE 要求。 如果您有任何关于带有 HSE A/B 交换的自定义 OTA 的应用笔记、RTD 示例或参考实现，我们将非常感谢您的指导。 感谢您的支持。 此致， 文卡特什·KV #s32k328 Re: S32K328 HSE-B: Recommended Architecture for A/B Swap using Mem_43_INFLS (without Vector FOTA) 嗨@venkatesh-kv 1.自定义 OTA 实现可以直接使用 Mem_43_INFLS 来擦除和编程被动分区。 MemAccM 是否应该扩展是一个架构决策，主要取决于应用程序是否需要通用的闪存访问和仲裁层。 2. 被动应用程序映像通常使用其物理 P-Flash 地址范围进行编程。HSE 没有为被动块提供专用的逻辑寻址抽象。应用程序/引导加载程序负责将新映像写入非活动分区，之后可以使用 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK 在下次 RESET 时激活该分区。 3. 如果使用安全启动，则应相应地更新签名（取决于安全启动模式和其他设置），以便在下次重置后能够成功验证和执行新应用程序。 旧版本的 HSE 固件需要超级用户权限才能执行服务 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK。在固件版本 0.2.55.0 及更高版本中，此功能已降级为普通用户权限。 4. 一次只能运行一个闪存操作。闪存访问仲裁的实现由应用程序架构决定。 一般来说，建议避免多个软件组件同时进行闪存操作，并确保闪存访问正确同步，以防止 OTA 编程活动与系统中的任何其他闪存用户发生冲突。 Fee/NvM 和 Mem_43_INFLS 之间没有同步支持。 5. 是的，流程正确。事实上，唯一的要求是，在交换分区之前，被动分区中必须存在有效的应用程序，并且签名（或一般的安全启动配置）应相应地进行更新。 我们有适用于 S32K344 的基本 OTA 演示“SW32K3_OTADEMO_0.8.0_D2203” - 它展示了如何将新应用程序写入被动块，然后请求 AB SWAP（这是 HSE 固件的一个功能）。本演示中使用的是 RTD 1.0.0 版本。 接下来更高级的演示是“S32K396 OTA Demo version 0.4.0”，它展示了如何通过以太网更新固件。这个版本使用的是 RTD 3.0.0。P07。 这两个演示程序都可以在 S32K3 参考软件中找到： https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-REFSW-D 点击链接，然后搜索“汽车软件 - S32K3 - OTA 演示”。 这些是我们仅有的版本，它只是参考软件，如果需要，用户需要将其迁移到其他衍生版本或更新的 RTD 软件包。 我们提供以下OTA培训： https://www.nxp.com/design/design-center/training/TIP-CONNECTS2021-AUT428 https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T3955A 这两点都可以在S32K3页面的“培训”部分找到： https://www.nxp.com/products/S32K3 您还可以查看“S32K3XX HSE 和 OTA 高级培训 [TR744101]”，该培训可从“文档”->“安全文件”下载： https://www.nxp.com/products/S32K3 问候， 卢卡斯

RT1176 PWM启动失败 我使用PWM+故障+QTimer来实现电机脉冲控制，但PWM3子模块0的PWM_A通道偶尔无法启动，在第一个高电平之后就一直保持高电平，后续脉冲不再出现。检查后发现，PWM的“运行”位没有正确设置。即使后来在程序中添加了重复启动操作，这种异常情况仍然发生。 Re: RT1176 PWM startup failed 你好@liu626 ， 你用的是定制板还是EVK板？如果你使用的是 EVK，你对它进行过任何修改吗？ 能否分享一下您使用的PWM3配置？ 您是使用示例作为参考吗？如果是，是哪一个？ 如果尝试使用仅包含 PWM3 的项目来重现该问题，问题是否仍然存在？ 这种情况是否只发生在 PWM3 子模块 0 PWM_A 通道上？其他PWM模块或子模块是否也出现过这种情况？ 是否还有其他任务或中断会操作 PWM3 寄存器，从而影响或覆盖运行位？ 此致， 巴勃罗 Re: RT1176 PWM startup failed 您好，我使用的是定制电路板。我没有举任何例子。这是在项目正式开发过程中发现的问题。我配置了六个PWM通道用于脉冲控制。只有这个通道出现了问题，其他子模块都没有出现此类问题。我检查后发现，只有这个通道使用了 PWM3 模块。未检测到其他干扰因素。以下是我的配置。 静态 axis_ctrl_t g_axes[AXIS_NUM] = { { 。ID= AXIS_X1，.name= "X1", .pwmBase= PWM1，.pwmModule= kPWM_Module_0，.pwmChannel= kPWM_PwmA， .tmrBase= TMR3，.lowCh= kQTMR_Channel_2，.highCh= kQTMR_Channel_3， .tmrInputsrc=kQTMR_ClockCounter2InputPin,.cascadePcs= 6U， 故障编号= 0U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, { 。ID= AXIS_X2，.name= "X2", .pwmBase= PWM2，.pwmModule= kPWM_Module_0，.pwmChannel= kPWM_PwmA， .tmrBase= TMR2，.lowCh= kQTMR_Channel_0, .highCh= kQTMR_Channel_1， .tmrInputsrc=kQTMR_ClockCounter0InputPin,.cascadePcs= 4U， 故障编号= 0U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, { 。ID= AXIS_Y，.name= "Y", .pwmBase= PWM3，.pwmModule= kPWM_Module_0，.pwmChannel= kPWM_PwmA， .tmrBase= TMR3，.lowCh= kQTMR_Channel_0, .highCh= kQTMR_Channel_1， .tmrInputsrc=kQTMR_ClockCounter0InputPin,.cascadePcs= 4U， 故障编号= 0U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, { 。ID= AXIS_Z，.name= "Z", .pwmBase= PWM4，.pwmModule= kPWM_Module_0，.pwmChannel= kPWM_PwmA， .tmrBase= TMR1，.lowCh= kQTMR_Channel_0, .highCh= kQTMR_Channel_1， .tmrInputsrc=kQTMR_ClockCounter0InputPin,.cascadePcs= 4U， 故障编号= 0U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, { 。ID= AXIS_EX1，.name= "EX1", .pwmBase= PWM1，.pwmModule= kPWM_Module_1，.pwmChannel= kPWM_PwmA， .tmrBase= TMR1，.lowCh= kQTMR_Channel_2，.highCh= kQTMR_Channel_3， .tmrInputsrc=kQTMR_ClockCounter2InputPin,.cascadePcs= 6U， 故障编号= 1U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, { 。ID= AXIS_EX2，.name= "EX2", .pwmBase= PWM2，.pwmModule= kPWM_Module_1，.pwmChannel= kPWM_PwmA， .tmrBase= TMR2，.lowCh= kQTMR_Channel_2，.highCh= kQTMR_Channel_3， .tmrInputsrc=kQTMR_ClockCounter2InputPin,.cascadePcs= 6U， 故障编号= 1U，.hwExactSupported= true，.outTrigMask= kPWM_ValueRegisterMask_3， }, };static void APP_Init_PWM_QTMR(void) { pwm_config_t pwmConfig; pwm_fault_param_t faultConfig; qtmr_config_t qtmrConfig; PWM_GetDefaultConfig(&pwmConfig); pwmConfig.pairOperation= kPWM_Independent; pwmConfig.reloadLogic = kPWM_ReloadImmediate; PWM_FaultDefaultConfig(&faultConfig); faultConfig.faultLevel = true; faultConfig.enableCombinationPath= false； faultConfig.faultClearingMode= kPWM_手动安全； faultConfig.recoverMode = kPWM_NoRecovery; QTMR_GetDefaultConfig(&qtmrConfig); CLOCK_EnableClock(kCLOCK_Qtimer1); CLOCK_EnableClock(kCLOCK_Qtimer2); CLOCK_EnableClock(kCLOCK_Qtimer3); PWM_StopTimer(PWM1, 0x0FU); PWM_StopTimer(PWM2, 0x0FU); PWM_StopTimer(PWM3, 0x0FU); PWM_StopTimer(PWM4, 0x0FU); pwm_fault_input_filter_param_t faultFilter; 故障过滤器.故障过滤器周期= 255U； faultFilter.faultFilterCount= 7U； faultFilter.faultGlitchStretch= false； /* 记录每个PWM实例上已配置的故障通道，避免重复设置 */ uint16_t pwm1FaultDone = 0U, pwm2FaultDone = 0U, pwm3FaultDone = 0U, pwm4FaultDone = 0U; for (uint8_t i = 0U; i < AXIS_NUM; i++) { axis_ctrl_t *ax = &g_axes[i]; PWM_Init(ax->pwmBase, ax->pwmModule, &pwmConfig); PWM_SetupFaults(ax->pwmBase, (pwm_fault_input_t)ax->faultNum, &faultConfig); /* 故障提示（每个 PWM 实例的每个故障通道只设置一次） */ { uint16_t *faultDone; 如果 (ax->pwmBase == PWM1) faultDone = &pwm1FaultDone; 否则如果 (ax->pwmBase == PWM2) faultDone = &pwm2FaultDone; 否则如果 (ax->pwmBase == PWM3) faultDone = &pwm3FaultDone; 否则 faultDone = &pwm4FaultDone; uint16_t faultBit = (uint16_t)(1U << ax->faultNum); 如果 ((*faultDone & faultBit) == 0U) { PWM_SetupFaultInputFilterExt(ax->pwmBase, (pwm_fault_channels_t)ax->faultNum, &faultFilter); *faultDone |= faultBit; } } /* 故障时输出低电平 */ ax->pwmBase->SM[ax->pwmModule].OCTRL &= ~(PWM_OCTRL_PWMAFS_MASK | PWM_OCTRL_PWMBFS_MASK); APP_PWM_Unmap_Selected_Fault(ax); APP_PWM_ClearFault_Safe(ax); ax->pwmBase->SM[ax->pwmModule].INIT = 0U; ax->pwmBase->SM[ax->pwmModule].VAL0 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL1 = 1U; ax->pwmBase->SM[ax->pwmModule].VAL2 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL3 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL4 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL5 = 0U; ax->pwmBase->SM[ax->pwmModule].TCTRL = PWM_TCTRL_OUT_TRIG_EN(ax->outTrigMask); APP_PWM_Disable_Output(ax); 如果 (ax->hwExactSupported) { qtmrConfig.primarySource= ax->tmrInputSrc; QTMR_Init(ax->tmrBase, ax->lowCh, &qtmrConfig); QTMR_Init(ax->tmrBase, ax->highCh, &qtmrConfig); ax->tmrBase->CHANNEL[ax->lowCh].CTRL = TMR_CTRL_CM(kQTMR_PriSrcRiseEdge) | TMR_CTRL_PCS(ax->tmrInputSrc); ax->tmrBase->CHANNEL[ax->highCh].CTRL = TMR_CTRL_CM(kQTMR_CascadeCount) | TMR_CTRL_PCS(ax->cascadePcs); APP_QTMR_Disable_Low_OFLAG_Output(ax); QTMR_DisableInterrupts(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_DisableInterrupts(ax->tmrBase, ax->highCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->highCh, 0xFFU); } ax->phase = kAxisIdle; ax->armed = false; ax->running = false; ax->done = true; #if HARD_PWM_STATE_GUARD_ENABLE APP_StateGuard_Reset(ax); #endif } /* 使能 QTMR 中断 */ NVIC_SetPriority(TMR1_IRQn, 2U); NVIC_SetPriority(TMR2_IRQn, 2U); NVIC_SetPriority(TMR3_IRQn, 2U); 启用IRQ(TMR1_IRQn); 启用IRQ(TMR2_IRQn); 启用IRQ(TMR3_IRQn); }static bool APP_PWM_Config_Pulse(axis_ctrl_t *axis, uint32_t highCnt400M， uint32_t lowCnt400M) { pwm_clock_prescale_t 预分频； uint16_t periodTicks; uint32_t totalCnt400M = highCnt400M + lowCnt400M; 如果 ((axis == NULL) || (totalCnt400M == 0U)) 返回 false; 如果 (!APP_PWM_SelectPrescaler_FromPeriodCnt400M(totalCnt400M, &prescale, &periodTicks)) 返回 false； uint32_t highTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)highCnt400M + ((uint64_t)totalCnt400M / 2ULL)) / （uint64_t）totalCnt400M）； 如果 (highTicks32 == 0U) highTicks32 = 1U; 如果 (highTicks32 >= periodTicks) highTicks32 = (uint32_t)periodTicks - 1U; uint32_t riseTicks32 = 0U; uint32_t fallTicks32 = highTicks32; #if HARD_PWM_LOW_START_PHASE_ENABLE uint32_t lowTicks32 = (uint32_t)periodTicks - highTicks32; 如果 (lowTicks32 >= (2U * HARD_PWM_LOW_START_PHASE_MIN_TICKS)) { uint32_t desiredLeadCnt400M = highCnt400M; uint32_t minLeadCnt400M = (uint32_t)HARD_PWM_LOW_START_PHASE_MIN_US * 400U; 如果 (desiredLeadCnt400M < minLeadCnt400M) desiredLeadCnt400M = minLeadCnt400M; uint32_t desiredLeadTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)desiredLeadCnt400M + ((uint64_t)totalCnt400M / 2ULL)) / （uint64_t）totalCnt400M）； 如果 (desiredLeadTicks32 < HARD_PWM_LOW_START_PHASE_MIN_TICKS) desiredLeadTicks32 = HARD_PWM_LOW_START_PHASE_MIN_TICKS; uint32_t maxRiseByHalfTicks32 = lowTicks32 / 2U; uint32_t postGuardTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)(HARD_PWM_VAL3_POST_LOW_GUARD_US * 400U) + ((uint64_t)totalCnt400M / 2ULL)) / （uint64_t）totalCnt400M）； 如果 (postGuardTicks32 < HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS) postGuardTicks32 = HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS; uint32_t maxRiseByPostGuardTicks32 = (lowTicks32 > postGuardTicks32) ? （lowTicks32 - postGuardTicks32）：0U； uint32_t selectedRiseTicks32; 如果 (maxRiseByHalfTicks32 >= desiredLeadTicks32) { selectedRiseTicks32 = desiredLeadTicks32; 如果 (selectedRiseTicks32 > maxRiseByHalfTicks32) selectedRiseTicks32 = maxRiseByHalfTicks32; } 否则如果（maxRiseByPostGuardTicks32 >= desiredLeadTicks32） { selectedRiseTicks32 = desiredLeadTicks32; 如果 (selectedRiseTicks32 > maxRiseByPostGuardTicks32) selectedRiseTicks32 = maxRiseByPostGuardTicks32; } 别的 { selectedRiseTicks32 = maxRiseByPostGuardTicks32; } 如果 (selectedRiseTicks32 >= HARD_PWM_LOW_START_PHASE_MIN_TICKS) { riseTicks32 = selectedRiseTicks32; fallTicks32 = riseTicks32 + highTicks32; } } #endif 如果 (fallTicks32 >= (uint32_t)periodTicks) fallTicks32 = (uint32_t)periodTicks - 1U; uint16_t riseTicks = (uint16_t)riseTicks32; uint16_t fallTicks = (uint16_t)fallTicks32; PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), false); uint16_t ctrl = axis->pwmBase->SM[axis->pwmModule].CTRL; ctrl &= (uint16_t)(~PWM_CTRL_PRSC_MASK); ctrl |= PWM_CTRL_PRSC（预分频）； axis->pwmBase->SM[axis->pwmModule].CTRL = ctrl; axis->pwmBase->SM[axis->pwmModule].INIT = 0U; axis->pwmBase->SM[axis->pwmModule].VAL0 = 0U; axis->pwmBase->SM[axis->pwmModule].VAL1 = (uint16_t)(periodTicks - 1U); 如果 (axis->pwmChannel == kPWM_PwmA) { axis->pwmBase->SM[axis->pwmModule].VAL2 = riseTicks; axis->pwmBase->SM[axis->pwmModule].VAL3 = fallTicks; } 否则如果 (axis->pwmChannel == kPWM_PwmB) { axis->pwmBase->SM[axis->pwmModule]。VAL4 = riseTicks; axis->pwmBase->SM[axis->pwmModule].VAL5 = fallTicks; } axis->pwmBase->SM[axis->pwmModule].TCTRL = PWM_TCTRL_OUT_TRIG_EN(axis->outTrigMask); PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), true); PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), true); axis->pwmConfigValid = true; axis->cachedHighCnt400M = highCnt400M; axis->cachedLowCnt400M = lowCnt400M; 返回 true； } Re: RT1176 PWM startup failed 你好@liu626 ， 您能否帮我找出配置问题，并测试一下仅初始化 PWM3 时问题是否仍然存在？ 在查看了您分享的配置后，为了尝试重现该行为，我有以下问题： axis_ctrl_t 的定义是什么？ 您的应用程序中是否启用了 HARD_PWM_LOW_START_PHASE_ENABLE 和 HARD_PWM_STATE_GUARD_ENABLE？ 以下APP功能是做什么用的？ APP_PWM_Unmap_Selected_Fault APP_PWM_ClearFault_Safe APP_PWM_禁用输出 APP_QTMR_Disable_Low_OFLAG_Output APP_StateGuard_Reset APP_PWM_SelectPrescaler_FromPeriodCnt400M APP_PwmModuleMask 此致， 巴勃罗 Re: RT1176 PWM startup failed 感谢你的回复。我使用的 GPIO 引脚是 rt1176 的 GPIO_EMC_B1_29。“axis_ctrl_t”是与电机轴相关的定义。 * PWM 输出脉冲 -> 触发 XBAR 信号 -> 脉冲下降沿驱动 QTMR 的外部时钟输入 -> * QTMR 32 位级联计数器递减 1 -> 当计数器达到 0 时，触发 QTMR 比较中断 -> 中断内部关闭 PWM * 同时，QTMR 触发硬件故障，直接拉低 PWM 的物理输出引脚。。ID= AXIS_Y， 。姓名= "Y", /* 用于串口日志记录或断点调试，以识别 Y 轴 */ /* ================= PWM 输出资源分配 ================= */ .pwmBase= PWM3, /* Y轴使用FlexPWM3模块 */ .pwm模块= kPWM_Module_0, /* 使用 PWM3 的子模块 0（每个 PWM 有 4 个子模块，编号从 0 到 3） */ .pwm通道= kPWM_PwmA, /* 使用子模块 0 的 A 相输出引脚，对应于物理引脚 GPIO_EMC_B1_29 */ /* ================= 32 位 QTMR 级联计数资源分配 ================= */ .tmrBase= TMR3, /* Y轴使用QTMR3外设（对应于IRQ中断号TMR3_IRQn） */ 低= kQTMR_Channel_0, /* 16 位低计数器：使用 TMR3 的通道 0 */ .highCh= kQTMR_Channel_1,/* 16 位高位计数器：使用 TMR3 的通道 1 */ /* 👉 .lowCh 和 .highCh它们成对出现，在硬件层面上，它们会自动组合成一个 32 位计数器。 /* ================= 硬件级联时钟源配置（核心关键） ================= */ .tmrInputsrc=kQTMR_ClockCounter0InputPin, /* 通道 0 的时钟源：设置为“外部引脚输入 0”。 在 XBAR 配置中，PWM3 脉冲的下降沿通过 XBAR 连接到 TMR3 通道 0 的输入引脚。 因此，每次 PWM 输出脉冲时，通道 0（16 位）将执行一次减量操作。*/ .cascadePcs = 4U， /* 高 16 位通道（通道 1）的时钟源 (PCS) 配置。 在 i.MX RT 的 QTMR 寄存器中，PCS 值对应如下： 0-3 = 外部引脚输入； 4 = 通道 0 的溢出/终止事件； 5 = 通道 1 的溢出/终止事件； 6 = 通道 2 的溢出/终止事件； 7 = 通道 3 的溢出/终止事件。 这里配置为 4U，意思是：让“TMR3 的通道 1”监测“TMR3 的通道 0 的溢出事件”。 已启用 HARD_PWM_LOW_START_PHASE_ENABLE 和 HARD_PWM_STATE_GUARD_ENABLE。APP_PWM_Unmap_Selected_Fault 功能：移除与当前轴对应的故障引脚映射。调用底层 PWM_SetupFaultDisableMap 函数来禁用故障。目的是为了：在不需要硬件故障的情况下，防止意外的外部干扰导致 PWM 关闭，从而方便底层调试过程。 APP_PWM_ClearFault（原始代码函数） 功能：清除 PWM 模块的故障状态标志（axis->pwmBase->FSTS）。触发硬件故障后，必须先清除此标志，然后才能允许 PWM 重新启动。 APP_PWM_禁用输出 功能：立即停止 PWM 定时器，强制引脚输出低电平（PWM_SetPwmForceOutputToZero），并启用输出。它的目的是确保在电机启动之前，引脚不会因为浮空或处于默认状态而输出高电平，这可能会导致电机运动不规则。 APP_QTMR_Disable_Low_OFLAG_Output 功能：禁用 QTMR 的 OFLAG（状态标志）输出，并强制 OFLAG 处于低电平。它与 XBAR 硬件配合使用，其作用是切断 QTMR 输出到 PWM 故障引脚的路径，防止在启动前意外触发故障。 APP_StateGuard_Reset 功能：清除国家卫队（看门狗）的计数器和旗帜。如果启用 HARD_PWM_STATE_GUARD_ENABLE 时系统遇到长时间无脉冲变化或死锁，则此功能用于在停止或重新启动系统之前重置这些保护变量。 APP_PWM_SelectPrescaler_FromPeriodCnt400M 功能：这是一个非常核心的底层频率计算函数。它接收高电平 + 低电平的总 400MHz 计数值，并计算应设置多少个预分频器 (PRSC) 和 PWM 周期 (PERIOD) 才能放入 16 位 PWM 寄存器中。请注意：如果计算出的周期超过 65535 且除法系数超出范围，则此函数将返回 false，导致电机无法启动。 APP_PwmModuleMask 功能：将 PWM 子模块的索引号（例如，值为 0 的 kPWM_Module_0）转换为左移 N 位的位掩码。NXP 的许多 PWM 寄存器（例如 OUTEN、MCTRL）都是逐位控制的。该函数负责生成正确的二进制掩码。 Re: RT1176 PWM startup failed 我找到了原因。这是因为 cm4 内核中 PIT 中断的内部负载过重，影响了 cm7 内核的 PWM 操作。降低 PIT 中断的负载后，PWM 启动失败的问题就消失了。

PCF8563TS/5,118用のコンデンサを探すお手伝いをします 私はPCF8563TS/5118 ICを使用しており、OSCIピンの外部コンデンサを正しく接続しようとしています。 私は50k ESR、12.5pF、32.568KHzの結晶、可能な限り短いトレース、データシートのアプリケーション図と同じ回路図を使っています。 デバイスを理解するために、データシートとUM10301の両方を参照して計算を試みました。外部コンデンサの値を明確に計算する方法を見つけるのが難しかったです。なぜなら、データシートには同じトピックの別々のページ、OSCIとOSCOで並列と直列が記載されているからです。 外部のOSCIピンとOSCOピンに並列に25pFの内部コンデンサが接続されているのがわかります。データシートの表30では、CLは並列接続の場合に計算されると記載されていますが、代わりに直列接続の場合の計算方法を示す注記があります。 デバイスを動かす外部コンデンサが見つかりません。I2Cからの応答がありません。25pF、22.5pF、20pF、25pF、10pF、8.2pF、6pFを試しました。0603 C0G/NP0 キャップすべて。 別の基板では、コンデンサを全く取り付けないことで動作させることができました。計算してみると、それは全く意味をなさない。 これらの入力値（12.5pF、50k ESR水晶発振器）の計算方法の例を教えていただけないでしょうか。計算しても、値を総当たりで試しても、うまく動作させることができませんでした。 Re: Help finding capacitor for PCF8563TS/5,118 はい、それは内蔵コンデンサの値で、私自身の投稿でも触れました。私はそのファイルを読みました。 あなたが伝えたいことを実際に書いてくれた方が、はるかに役に立つでしょう。時間を割いていただきありがとうございました。 Re: Help finding capacitor for PCF8563TS/5,118 UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123、PCA21125のユーザーマニュアル Re: Help finding capacitor for PCF8563TS/5,118 親愛なるデイビッド、 db16122さんが正しく表3を案内してくれました。UM10301で。目標負荷静電容量が12.5pFなら、OSCIピンに25pF中間値のトリムコンデンサを接続する必要があります。 この25pF値は表30の下記式から計算できます。PCF8563のデータシートに記載されています。 ここでCLは目標負荷静電容量、あなたの場合は12.5pFです。 コスコは既知の内部静電容量、25pFです。 この式から、Ctrimは次のように導くことができます: CL = Ctrim * Cosco / (Ctrim + Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim Ctrim = CL * Cosco / (Cosco - CL) = 12.5 * 25 / (25 - 12.5) = 312.5 / 12.5 Ctrim=25pF 可変トリムコンデンサが必要なのは、内部のCoscoコンデンサに余裕があるためです。Coscoは15pFから35pFの範囲で変動する場合があります。 敬具、 ヨゼフ

can we use provisioned cert or key for setting up in the https connection or tls connection in i.mx9 Can the provisioned certificate and private key on the i.MX93 be used directly to establish HTTPS/TLS connections? If yes, what is the recommended method for accessing and utilizing these credentials for client/server authentication and mTLS implementations? once provisioning is complete and the secure object blobs are present in /etc/ele/, what is the recommended workflow for using those provisioned credentials in a real HTTPS/TLS connection? Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i Hi ,@Manuel_Salas  Thanks for your reply. Following up on the mbedTLS/opaque-key guidance — that's resolved on our side for the private key. Remaining question is specifically about the certificate, provisioned via EL2GO and stored in /etc/ele/ alongside the private key . Since a certificate is public data, we need to extract it as plain DER to hand to mbedtls_x509_crt_parse_der() for the TLS handshake — unlike the key, it doesn't need to stay opaque. What is the supported SMW/PSA call to retrieve the plaintext DER bytes for a provisioned certificate object? Specifically: is it exposed via psa_ps_get() / psa_its_get() (PSA Protected Storage / Internal Trusted Storage) using the object ID as the UID, or through a different SMW API? We see protected_storage.h and internal_trusted_storage.h in the installed SMW headers but want to confirm this is the intended path for certificate objects before building against it. Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i Hello @NEXUSNERD  Hope you are doing very well. On the i.MX93, the provisioning flow is designed so that the private key remains protected by the ELE. So, the blobs stored in /etc/ele/ are secure object representations that allow ELE to reload or reference the provisioned key material, and they are not intended to be treated as ordinary TLS key files. You can take a look to the imx-secure-enclave (Mbed-TLS). Best regards, Salas.

オンラインプロビジョニング ボードのオンラインプロビジョニングは無事完了しました。あとは、edge2lockのプロビジョニング後に作成された証明書やキーを抽出するか、場合によっては読み取る必要があるのですが、それは可能でしょうか? Frdm i.mx93 を使用しています Re: Online Provisioning こんにちは、 pkcs11-toolを使っても構いません。こちらのドキュメントをご覧ください。 https://github.com/nxp-imx/imx-smw/blob/release/version_5.x/Documentations/user_guide/pkcs11/pkcs11_tool_user_guide.md また、SMWのユーザーマニュアルもご覧になることをお勧めします: https://github.com/nxp-imx/imx-smw/blob/release/version_5.x/Documentations/user_manual/SMW_UserManual_UM12513.pdf よろしくお願いいたします。 アルド。 Re: Online Provisioning こんにちは、アルドさん。 お返事ありがとうございます。 FRDM i.MX93でオンラインプロビジョニングに成功した後、SMW PKCS#11プロバイダーでpkcs11-toolを使おうとしましたが、プロビジョニング済みの証明書やキーが見えたり読み取ったりできません。 もう少し詳しく教えていただけますか: プロビジョニングされた証明書と秘密鍵はPKCS#11インターフェースを通じてアクセス可能でしょうか? そうでない場合、それらはELEに安全に保存され、エクスポートされることなくPSA Crypto/SMW APIを通じてのみ使用されることを意図しているのでしょうか？ 私の目標は、プロビジョニングされた認証情報を使用して相互TLS接続を確立することです。 ありがとう。

S32DS 3.4 License Problem Dear NXP team， 当我重新安全S32DS 3.4时，无法激活，提示如下图。目前我已无法重旧电脑上返回license，麻烦处理一下。谢谢！ Re: S32DS 3.4 License Problem 你好， 可用许可证数量已增加。

USXGMII multi-rate on i.MX95 Hi, we are trying to evaluate if we can implement an ethernet port on the i.MX95 that is able to support the following ethernet speeds: 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te In general this requires us to place a 10Gbit capable ethernet PHY on our design and connect it to the i.MX95 ethernet controller via one of two interfaces: USXGMII or XFI From our understanding the USXGMII interface is a multi-rate interface in theory, meaning it can facilitate all speeds from 10Gbit to 10bit over one link. In contrast the XFI interface is a single-rate interface that can only facilitate 10Gbit. According to the i.MX95 reference manual (e.g. section 104.2, table 621) the i.MX95 supports both XFI and "10G-USXGMII". So initially it looks like our desired interface USXGMII seems to be supported. There are several points that confuse us however: 1. The declaration "10G-USXGMII" could be interpreted to mean that the interface is a USXGMII link in theory but it only really works in the 10Gbit mode. 2. The NXP eval board IMX95LPD5EVK-19 implements a 10GBase-T port using a Marvell AQR113C PHY. a) In the block diagram in figure 1, section 1.1 the PHY looks to be connected to the USXGMII interface: b) In the associated section 2.11.3 "10 Gbit Ethernet Interface" the AQR113C ethernet transceiver is said to support all data rates from 10Gbit to 10bit, hinting at true USXGMII: c) This section also mentions that the interface used to connect the ethernet PHY is XFI: So in conclusion we are confused wether or not the i.MX95 supports the full multi-rate USXGMII or only a 10Gbit-only version. We tried to look at the NXP eval board as a reference but we are not sure either if the 10GbE port on that board is connected via USXGMII (allowing multi-rate from 10Gbit to 10bit) or via XFI (10Gbit only). Could you please clarify for us: Is it possible to implement a true multi-rate 10GbE port on the i.MX95 that supports speeds from 10Gbit to 10bit? Re: USXGMII multi-rate on i.MX95 Thank you very much for this in-depth response. This clears up any confusion on our side! Re: USXGMII multi-rate on i.MX95 1. Meaning of "10G-USXGMII" "10G-USXGMII" refers to the standard multi-rate USXGMII protocol, not a 10G-only mode. The "10G" denotes the fixed SerDes lane speed, while USXGMII supports in-band rate adaptation for 10M, 100M, 1G, 2.5G, 5G, and 10G Ethernet. On i.MX95, this mode is represented by the PCS_PROT_10G_SXGMII setting. 2. Interface Used on the i.MX95 EVK The i.MX95 EVK uses XFI (10GBASE-R) rather than USXGMII. In imx95-19x19-evk.dts, enetc_port2 is configured as: phy-mode = "10gbase-r"; Therefore, the onboard AQR113C operates in XFI mode. 3. Is True Multi-Rate USXGMII Supported? Yes. The i.MX95 NETC hardware supports USXGMII, and the Linux ENETC4 driver handles speed changes through enetc4_set_port_speed(). The Marvell AQR113C also supports USXGMII host-interface mode. 4. What Is Needed on a Custom Board? To enable full multi-rate operation: Configure the device tree: phy-mode = "usxgmii"; managed = "in-band-status"; Configure the AQR113C firmware for USXGMII host mode instead of XFI. The EVK uses XFI for its 10GbE port, but a custom i.MX95 design can use USXGMII with the AQR113C (or a similar PHY) to support 10M/100M/1G/2.5G/5G/10G over a single MAC-to-PHY link. Thanks Re: USXGMII multi-rate on i.MX95 I am not the original poster but I am also trying to get usxgmii working. Has NXP ever validated if usxgmii works on the BSP kernel? I am trying to use it with a mv-cux3610 phy but I get these errors: [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 it seems to be caused by the netc PCS not advertising usxgmii support, only 10gbase-r, 2500-basex and sgmii: (this is on the lf-6.18.y linux-imx branch) Re: USXGMII multi-rate on i.MX95 Just one more follow-up question: Is the driver for the Marvell AQR113C included in the NXP Linux BSP or is it an out-of-tree module we must supply ourselves? Re: USXGMII multi-rate on i.MX95 Thank you for your reply! Last question from my side: Is it possible to configure the enetc_port2 and the AQR113C on the i.MX95 EVK to USXGMII mode? Would this allow us to test the multi-rate functionality of the USXGMII interface on the EVK? Re: USXGMII multi-rate on i.MX95 the driver has been included in NXP Linux BSP, link: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c Re: USXGMII multi-rate on i.MX95 Simply "switching the DTS to usxgmii" on the EVK is only a software-level attempt. You would also have to re-provision the AQR113C with USXGMII firmware, and because of the EVK's XFI-oriented board design, this is not a reliable path for multi-rate validation. If the goal is to validate true multi-rate USXGMII (10M/100M/1G/2.5G/5G/10G), we recommend building a custom board designed for USXGMII (SerDes routing + AQR113C in USXGMII host-mode firmware + phy-mode = "usxgmii"). You can use EVK board, after obtaining the USXGMII provisioning firmware for the AQR113C, but please be aware of its limitations. Thanks

HTTPS接続やI.mx9のTLS接続で設定するためにプロビジョニング済みのcertやkeyを使うことは可能でしょうか? i.MX93のプロビジョニング済み証明書と秘密鍵は、直接HTTPS/TLS接続を確立するために使えますか?もしそうなら、クライアント/サーバー認証やmTLS実装のためにこれらの認証情報にアクセスし活用する推奨方法は何ですか? プロビジョニングが完了し、セキュアオブジェクトブロブが /etc/ele/ に存在する場合、プロビジョニングされた認証情報を実際の HTTPS/TLS 接続で使用するための推奨ワークフローは何ですか？ Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i こんにちは、 @Manuel_Salas ご返信ありがとうございます。 mbedTLS/opaque-keyに関するガイダンスに従って、プライベートキーに関する問題は弊社側で解決済みです。 残りの質問は、EL2GO を介してプロビジョニングされ、秘密鍵とともに /etc/ele/ に保存される証明書についてです。証明書は公開データであるため、TLS ハンドシェイクのために mbedtls_x509_crt_parse_der() に渡すために、プレーンな DER として抽出する必要があります。鍵とは異なり、証明書は不透明なままにしておく必要はありません。 プロビジョニングされた証明書オブジェクトの平文DERバイトを取得するためにサポートされているSMW/PSA呼び出しは何ですか？ 具体的には、オブジェクトIDをUIDとして使用してpsa_ps_get() / psa_its_get()（PSA保護ストレージ / 内部信頼ストレージ）を介して公開されるのか、それとも別のSMW APIを介して公開されるのか？インストールされたSMWヘッダーにはprotected_storage.hとinternal_trusted_storage.hが見られますが、証明書オブジェクトに対してこれを意図した経路かどうかを確認したいです。 Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i こんにちは、 @NEXUSNERD お元気でお過ごしのことと思います。 i.MX93では、プロビジョニングフローは秘密鍵が ELEによって保護されるように設計されています。 したがって、/etc/ele/ に保存されているブロブは、ELEがプロビジョニングされたキー素材を再ロードまたは参照できるようにする安全なオブジェクト表現であり、通常のTLSキーファイルとして扱うことを意図していません。 imx-セキュア・エンクレーブ(Mbed-TLS)を見てみてください。 よろしくお願いいたします。 サラス。

USXGMII 多速率 i.MX95 您好， 我们正在评估是否可以在 i.MX95 上实现一个能够支持以下以太网速度的以太网端口： 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te 通常，这要求我们在设计中集成一个支持 10Gbit 以太网的 PHY，并通过 USXGMII 或 XFI 这两个接口之一将其连接到 i.MX95 以太网控制器。 据我们了解，USXGMII 接口理论上是一个多速率接口，这意味着它可以通过一条链路实现从 10Gbit 到 10bit 的所有速度。 相比之下，XFI 接口是单速率接口，只能支持 10Gbit。 根据 i.MX95 参考手册（例如第 104.2 节，表 621）i.MX95 同时支持 XFI 和“10G-USXGMII”。所以初步看来，我们想要的接口 USXGMII 似乎得到了支持。 然而，有几点让我们感到困惑： 1.“10G-USXGMII”声明可以解释为该接口理论上是 USXGMII 链路，但实际上只能在 10Gbit 模式下工作。 2. NXP 评估板IMX95LPD5EVK-19 使用 Marvell AQR113C PHY 实现 10GBase-T 端口。 a) 在图 1 的框图中，1.1 节中，PHY 似乎连接到了 USXGMII 接口： b) 在相关的 2.11.3 节“10 Gbit 以太网接口”中，AQR113C 以太网收发器据称支持从 10Gbit 到 10bit 的所有数据速率，暗示了真正的 USXGMII： c) 本节还提到，用于连接以太网 PHY 的接口是 XFI： 因此，我们最终还是不清楚 i.MX95 是否支持完整的多速率 USXGMII，还是只支持 10Gbit 版本。 我们尝试以 NXP 评估板作为参考，但我们也不确定该板上的 10GbE 端口是通过 USXGMII 连接（允许从 10Gbit 到 10bit 的多速率）还是通过 XFI 连接（仅限 10Gbit）。 请问能否为我们澄清一下： i.MX95 是否有可能实现真正的多速率 10GbE 端口，支持从 10Gbit 到 10bit 的速度？ Re: USXGMII multi-rate on i.MX95 非常感谢您如此详尽的回复。 这样就消除了我们这边的任何疑惑！ Re: USXGMII multi-rate on i.MX95 1. “10G-USXGMII”的含义 “10G-USXGMII”指的是标准的多速率USXGMII协议，而不是仅10G模式。“10G”表示固定的 SerDes 通道速度，而 USXGMII 支持 10M、100M、1G、2.5G、5G 和 10G 以太网的带内速率自适应。 在 i.MX95 上，此模式由 PCS_PROT_10G_SXGMII 设置表示。 2. i.MX95 EVK 上使用的接口 i.MX95 EVK 使用 XFI (10GBASE-R) 而不是 USXGMII。在 imx95-19x19-evk.dts 中，enetc_port2 配置如下： phy-mode = "10gbase-r"; 因此，机载 AQR113C 以 XFI 模式运行。 3. 是否支持真正的多速率 USXGMII？ 是的。i.MX95 NETC 硬件支持 USXGMII，Linux ENETC4 驱动程序通过 enetc4_set_port_speed() 处理速度更改。Marvell AQR113C 也支持 USXGMII 主机接口模式。 4. 定制板需要哪些组件？ 为实现完整的多速率操作： 配置设备树： phy-mode = "usxgmii"; managed = "带内状态"; 将 AQR113C 固件配置为 USXGMII 主机模式而不是 XFI 模式。 EVK 的 10GbE 端口使用 XFI，但定制的 i.MX95 设计可以使用 USXGMII 和 AQR113C（或类似的 PHY）来支持通过单个 MAC 到 PHY 链路传输 10M/100M/1G/2.5G/5G/10G 网络。 谢谢！ Re: USXGMII multi-rate on i.MX95 我不是原帖作者，但我也在尝试让usxgmii运行起来。 NXP 是否验证过 usxgmii 是否能在 BSP 内核上运行？我尝试将其与 mv-cux3610 PHY 一起使用，但出现以下错误： [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 这似乎是由于 netc PCS 没有宣传 usxgmii 支持，而只支持 10gbase-r、2500-basex 和 sgmii 造成的： （这是在 lf-6.18.y linux-imx 分支上） Re: USXGMII multi-rate on i.MX95 还有一个后续问题：NXP Linux 电路板支持包。 中是否包含 Marvell AQR113C 的驱动程序，还是我们需要自己提供的外部模块？ Re: USXGMII multi-rate on i.MX95 该驱动程序已包含在 NXP Linux 电路板支持包中，链接： https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c Re: USXGMII multi-rate on i.MX95 感谢你的回复！ 我最后一个问题：是否可以将 i.MX95 EVK 上的 enetc_port2 和 AQR113C 配置为 USXGMII 模式？这样我们就可以测试 EVK 上 USXGMII 接口的多速率功能了吗？ Re: USXGMII multi-rate on i.MX95 在 EVK 上简单地“将 DTS 切换到 usxgmii”只是软件层面的尝试。 您还需要使用 USXGMII 固件重新配置 AQR113C，但由于 EVK 的板设计面向 XFI，因此这不是多速率验证的可靠途径。 如果目标是验证真正的多速率 USXGMII（10M/100M/1G/2.5G/5G/10G），我们建议构建一个专为 USXGMII 设计的定制板（SerDes 路由 + AQR113C 在 USXGMII 主机模式固件中 + phy-mode = "usxgmii")。 在获得 AQR113C 的 USXGMII 配置固件后，您可以使用 EVK 板，但请注意其局限性。 谢谢！

CodeWarrior License Questions We use CodeWarrior 10.6 on a legacy product and need to install it on a new P.C.  I'm unable to find an offline CodeWarrior 10.6 offline install and the online install fails (missing download site). I can find a 10.7 download.  We have permanent floating licenses for 10.6.  Will these continue to work with 10.7 or can someone point me to an offline 10.6 install? thanks