KW45B41Z RTC not running during power off (Power backup given by super capacitor) The RTC is retaining its value in the KW45B41Z-EVK during power off when power back up is provided by Coin cell battery, but in i am using KW45B41Z for my project where i am using a super capacitor(25F/3.8V) to power RTC during power off. Here RTC is not retaining its value. So do I need to enable any Low power mode through SPC or is there any special configuration that i should do? I have also verified the voltage across the super capacitor that is enough to power the RTC during power off. Any low power mode configurations are there for RTC? Regards Kaif Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) According to the EVK schematics, the VDD_DCDC pin powers the RTC when JP5 pins 2 and 3 are connected. With this configuration, the RTC functions correctly on the EVK. We observed that the RTC draws approximately 1 mA in this setup. When we replicate this arrangement on our custom board using a supercapacitor, the supercapacitor discharges very quickly. We specifically chose a supercapacitor because we required a rechargeable power source capable of maintaining RTC operation for at least 1–2 months, which is typical for RTC applications. However, a coin cell was not considered suitable since it is not rechargeable. Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello What values are you getting from voltage across the capacitor? As if goes to a very low voltage (from the capacitor discharging) or approximates to minimal values according to Datasheet, it may cause abnormal functionality such as loss of RTC Functionality: The most immediate consequence is that the RTC will likely stop operating reliably. The timekeeping accuracy will be compromised, and any data stored in the RTC's backup registers may be lost. A coin cell offers a stable and nearly constant voltage over most of its lifespan, which ensures that the RTC always receives a voltage above its minimum operating threshold. Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) I am using kw45b41zevk_rtc demo (not rtc_func or power mode switch as in AN14122). Instead of Coin Cell (as in KW45B41Z EVK) I am using a super capacitor for RTC Power Backup. During power on RTC will be powered by VDD_SWITCH but during power off, super capacitor will supply power to RTC.  During power off Super capacitor is discharging (tested) but RTC is not retaining its register value. I have attached the schematics of RTC supply configuration i am using.  Why in the KW45B41Z EVK coin cell backup is given for RTC why there is no rechargeable source like super capacitor or battery? Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello Kaif, As shown in the KW45B41Z-EVK, the coin cell or lithium battery will be the preferred methods, this to achieve long battery life and voltage stability. Regarding the RTC not retaining values, Could you please kindly describe what is the procedure you are using for the configuration and test? By any chance, are you using the demo called "rtc_func" or power_mode_switch as in AN14122? Also please consider the recommendations mentioned in the AN14122 to start the RTC from a low-power mode. Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) I am using KW45B41Z in custom board with back up power using super capacitor. Can we use super capacitor to power RTC during power off? or Lithium battery is the only way? I would really appreciate your support on this. Regards  Kaif Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello, Could you help us confirm if you are using a custom board with the KW45B41Z or the KW45-EVK? The Application note 14122 describes how to integrate the RTC feature to a low-power application with the KW45 and explains the file modifications needed to implement it. AN14122: How to use RTC on KW45-EVK | NXP Semiconductors Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) We have attached schematics of super capacitor going to VDD_SWITCH line, do we need to enable any specific bits through software in rtc or power section? Best Regards Kaif

在 MPC5748G MCU 的扩展 SPI 模式下，EOQF 标志未被设置 你好，团队、 我在 MPC5748G MCU 中使用扩展 SPI 模式进行 32 位帧传输，发现传输结束时 EOQF 标志没有被设置。我在 MPC5777C MCU 上使用了相同的代码，一切正常。 你知道为什么会出现这个问题吗？任何建议或想法都会被极大地采纳。 期待您的真知灼见。 谢谢！ 此致， 克里希纳 用于 i.MX RT 的 eIQ 机器学习软件 Re: EOQF flag is not getting set in EXTENDED SPI mode in MPC5748G MCU 你好，伊谢、 谢谢您的答复。我已正确配置 SPI 模块以传输 32 位帧，如果不查看 EOQ 标志，读取和写入均可在 MPC5748 中正常工作。我还设置了 EOQ 标志，以便传输最后一个字，但模块不承认这一点。 仅供参考，我不在 EOQ 中使用中断我正在轮询寻找那个标志。 您提到"虚假队列结束语" ，能否请您解释一下这是什么意思？ 谢谢！ 此致， 克里希纳

GD3162 新しい回路図デザインで GD3162 ゲート ドライバを使用する予定です。NXP のサイトで短いデータシートを見つけました。完全なデータシートはありますか? Re: GD3162 この製品に関して要求されたドキュメントは管理リリース下にあり、NDA (秘密保持契約) に基づいてセキュア ファイル経由でアクセスできます。 アクセスをリクエストするには、こちらをクリックしてください: https://www.nxp.com/webapp-signup/docstoreReg  フォームの送信時に、有効な NDA のコピーをアップロードするよう求められることにご注意ください。NXPについてにまだNDAがない場合は、まずNDAのフォームにご記入ください。 https://www.nxp.com/webapp-signup/ndaReqForm NDA の準備ができたら、安全なファイルへのアクセスをリクエストできます。 プロセスを理解するには、以下のリンク/FAQを確認してください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS https://www.nxp.com/support/support/secure-access-rights/secure-access-rights-faqs:SEC-ACCESS-FAQS

S32K396s ブートラウダー S32K396sブートローダープロジェクトでは、ldファイルをどのように変更すればよいでしょうか？K396用のブートローダーの例はありますか？ Re: S32K396s bootlouder こんにちは、 1. S32K3シリーズ用統合ブートローダデモ NXP は、S32K396 を含む S32K3 ファミリをサポートする統合ブートローダ デモを提供しています。このデモには以下が含まれます: ブートローダーとアプリケーションプロジェクト フラッシュ・メモリ・コンフィグレーション 起動とアプリケーションへのジャンプロジック 公式投稿とダウンロード リンクは、こちらにあります: NXPコミュニティの統合ブートローダー デモ。 https://community.nxp.com/t5/S32K-Knowledge-Base/Unified-bootloader-Demo/ta-p/1423099 2. S32 Design Studio（S32DS）とRTD ブートローダの例を使用するには、次のものが必要です。 S32 Design Studio (S32DS) S32K3 リアルタイム ドライバ (RTD) パッケージ S32K396開発パッケージ これらは、S32DS の拡張機能と更新メニューからCANインストールできます。インストールしたら、次のようなサンプル テンプレートから新しいプロジェクトを作成 CAN。 ポート_例_S32K396 Bootloader_Example (RTD バージョンで利用可能な場合) セットアップの詳細については、S32K396-BGA-DC1のスタートガイドをご覧ください。 https://www.nxp.com/document/guide/getting-started-with-s32k396-bga-dc1-evaluation-board:GS-S32K396-BGA-DC1?section=get-software よろしくお願いいたします。 ピーター

用于 NFC 驾驶舱的 SPI 适配器 你好 我找到了你的 PN5180 和其他阅读器的探索板，它上面似乎有一个 USB <-> SPI 适配器，所以 NfcCockpit 可以用它与 PN5180 之类的东西通信。 我的问题是：有没有基于 Arduino 的固件可以实现同样的功能？ 我有很多基于 esp32 或 rp2040 的板，但你提供的固件似乎不支持它们... Re: SPI Adapter for the NFC Cockpit 你好，谢谢你的建议！ 最后，我设计了自己的解决方案： https://github.com/dakhnod/NFCCockpitSPIAdapter 再次感谢！ Re: SPI Adapter for the NFC Cockpit 你好@dakhnod 1.我的问题是：有没有基于 Arduino 的固件可以实现同样的功能？ 没有，没有基于 Arduino 的固件。 2。我有很多基于 esp32 或 rp2040 的板，但你提供的固件似乎不支持它们... 你可以将 NFC COCKPIT VCOM 移植到 tesp32 或 rp2040，源代码可以从 NFC Cockpit 下载|恩智浦半导体 KaiLi_0-1753701919912.png

TEA2017 27-30V 550W 设计，PFC Mosfet 在 DCM/QR/CCM 模式下迅速发热。 你好我正在处理一个客户项目，该项目采用 TEA2017 PFC 和 LLC 设计，电压为 27-30V，功率为 550W。 最初，我们使用固定频率 55khz 的 PFC，mosfets 的温度比平时高，但仍可通过散热片控制，但现在我们正试图提高 PFC 的效率。因此采用 DCM/QR/CCM 模式。遗憾的是，在我们的设计中，在 DCM/QR/CCM 模式下，mosfets 的温度会迅速升高到失效温度。 我们尝试过但没有成功的方法： 1：使用晶体管作为栅极驱动器来驱动 Pfc 栅极 2：确认我们的开关是在振荡周期之后和 DrainPFC 下降时进行的。 3.禁用 LLC 并将负载直接连接到 Vboost，以测试/调整 PFC（结果：茶水没有切换 PFC，Vboost 保持在 327V（SNSBoost 为 2V）） 我们的设计或 TEA 设置没有太大变化，因为我们正在尝试测试 DCM/QR/CCM。任何正确方向的帮助/线索都将非常有用。 我已经公布了原理图的 PFC 部分，我们使用的是 CONFIG_D。 Re: TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. HI 1：您应该确认哪个元器件变热了电感器或其他元器件，然后提供散热解决方案。 2: 您也可以按照所附的 excel 计算表配置电路，然后更新原理图。

MCUXpresso SDK：CI/CD 流水线 概述 在不断发展的嵌入式系统开发领域，支持自动化和高效的工作流程变得越来越重要。本文将探讨如何使用 GitHub Actions、Docker、MCUXpresso SDK 和 Visual Studio Code 为嵌入式项目量身打造一个强大的 CI/CD 管道。通过集成这些工具，开发人员可以自动构建、运行测试，并确保在不同团队和环境中一致地交付固件。 我们首先概述了 CI/CD 在嵌入式工作流程中的优势，包括更快的迭代周期、减少人为错误以及增强协作。接下来，我们深入探讨实际设置：使用 Docker 封装构建环境，利用 GitHub Actions 协调构建和测试，以及在 VS Code 中借助 MCUXpresso SDK 来管理和开发固件项目。真实案例和可重复使用的模板将引导读者创建一个可扩展、可维护且针对基于恩智浦的开发板进行了优化的管道。 无论您是希望实现工作流程现代化的嵌入式工程师，还是希望缩短交付时间的产品经理，本指南都将帮助您在开发生命周期中利用自动化的力量。 前提条件 MCUXpresso for VS Code MCUXpresso SDK 24.12 或更高版本 Git GitHub 帐户 Docker 目录 嵌入式工作流程中的 CI/CD 优势 容器 - Docker 自动化 - GitHub Actions 使用流水线 结束语 1. CI/CD 在嵌入式工作流中的优势 在嵌入式系统开发中实施持续集成和持续部署 (CI/CD) 具有变革性优势，尤其是在使用 MCUXpresso SDK 等复杂工具链和特定硬件限制时。以下是主要优势： 自动构建和测试 CI/CD 管道通过自动编译、链接和闪存流程，消除了手动构建步骤。这可确保每次代码更改都能在一致的构建环境中得到验证，从而降低人为错误的风险，节省宝贵的工程时间。 及早发现问题 通过将自动单元测试、静态分析和在环硬件 (HIL) 测试集成到管道中，开发者可以在错误和回归进入生产硬件前及早发现。这将使固件更加稳定，减少集成过程中的意外情况。 使用 Docker 实现一致的环境 使用 Docker 对构建环境进行容器化，可确保开发机器和 CI 运行程序之间的一致性。开发人员不再需要担心工具链版本不匹配或依赖项缺失的问题，一切都已定义并可重现。 改善协作和代码质量 CI/CD 鼓励频繁提交和拉取请求，这些请求会自动验证。这促进了团队成员间更好的协作，执行编码标准，并确保只有经过测试的代码被合并到主分支中。 更快的迭代和部署 借助自动化管道，固件更新可以快速构建、测试并部署到目标设备或暂存环境中。这加快了开发周期，实现了快速原型开发，尤其适用于敏捷或迭代开发模式。 可追溯性和可审计性 CI/CD 系统会记录每一次构建、测试结果和部署，从而提供清晰的更改历史记录。这对于在汽车或医疗设备等受监管行业中进行调试、确保合规性和维持高质量标准至关重要。 跨项目的可扩展性 管道一旦建立，就可以在多个嵌入式项目中重复使用或调整。这种可扩展性减少了新板或应用程序的设置时间，并促进了团队之间的最佳实践。 2. 容器 - Docker 什么是容器？ 容器是轻量级、可移植的软件单元，它将代码与其所有依赖项、库和配置文件组成一个代码包，因此可以在不同的计算环境中可靠地运行。 将容器视为一个独立的盒子，其中包含应用程序运行所需的一切。有几个平台可以用来容器化工作区。本指南将重点介绍 Docker。 Docker是什么？ Docker 是一个开源平台，它使开发人员能够在容器中构建、打包和运行应用程序。它简化了创建隔离环境的过程，该环境包括应用程序在不同系统上持续运行所需的代码、库、工具和设置等所有内容。 Docker 的核心是确保开发、测试和部署环境相同，无论您是在本地还是在云中工作，都能帮助解决“它在我的机器上运行”的问题。 使用 Docker 对 MCUXpresso SDK 和构建系统进行容器化的步骤 使用 Docker 对 MCUXpresso SDK 和构建系统进行容器化需要以下组件。 Dockerfile - 这是一个文本文件，其中定义了构建 Docker 镜像的步骤，例如安装软件包、复制文件和设置环境变量。 Docker 镜像 - 这是容器环境的快照。它由 Dockerfile 构建，用于创建容器。 Docker 容器 - Docker 镜像的运行实例。它具有隔离性、轻便性和便携性。 编写 dockerfile 1. 打开文本编辑器（例如 VS Code） 2. 创建一个新的文本文件。将其命名为 dockerfile。将此文件保存为 Docker 文件类型。 3. 创建用于容器化 MCUXpresso SDK 和构建系统的 dockerfile 时，必须指定所需的所有元器件。我们在下面提供了一个模板，你可以复制并粘贴到 dockerfile 中。 该模板的用途： - 使用 Ubuntu 22.04 作为容器的基础。这为构建和运行嵌入式工具提供了稳定的 Linux 环境。 - 防止安装期间出现交互式提示 - 安装使用 MCUXpresso SDK 所需的所有软件包（部分为可选软件包） 安装 ARM GNU 13.2 工具链 - 设置一个工作区，以便使用 West 克隆 MCUXpresso SDK - 配置工具链路径环境变量 # Use Ubuntu 22.04 as the base image FROM ubuntu:22.04 # Set environment variables for non-interactive installations ENV DEBIAN_FRONTEND=noninteractive # Install necessary packages /some optional RUN apt update && apt install -y \ curl \ wget \ ca-certificates \ xz-utils \ libncurses5 \ cmake \ ninja-build \ git \ python3 \ python3-pip \ build-essential \ device-tree-compiler \ unzip \ && rm -rf /var/lib/apt/lists/* # =========================================================================================================== # Notes on flags used: # (-LO) follows http redirects and saves the downloaded file with same name as in URL # (-k) ignores SSL certificate verification. This is needed when system security prevents certain actions # Contact IT to whitelist arm servers if needed. # ============================================================================================================ RUN curl -LO -k https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz && \ tar xf arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz && \ rm arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz # Install additional Python packages RUN pip3 install --upgrade west imgtool requests # Set the workspace directory WORKDIR /workspace # Clone the mcuxsdk-manifests repository RUN git clone https://github.com/nxp-mcuxpresso/mcuxsdk-manifests.git # Set the MCUXpresso SDK path environment variable ENV MCUX_SDK_PATH=/workspace/mcuxsdk-manifests # Initialize and update the west workspace RUN cd $MCUX_SDK_PATH && \ west init -l . && \ west update # ARMGCC ENV variable ENV ARMGCC_DIR=/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi # Default command: Start a shell CMD ["/bin/bash"] 构建容器映像 在继续之前，建议设置一个 GitHub 存储库并配置凭据，以便在后续步骤中使用。 1. 创建一个新的存储库。暂时留空。稍后，它将包含以下项目： .github/workflows/docker-build.yml my_app dockerfile README.md 2. 生成个人访问令牌（PAT）。这将允许您访问 GitHub API。 - 点击“我的”图标 joseOcampoHernandez_0-1760392547685.png - 选择设置 > 开发者设置 > 个人访问令牌 > 令牌（经典版） joseOcampoHernandez_2-1760392708201.png - 选择“生成新令牌（经典）” - 范围可以根据您的需求自定义。请在本指南中使用以下范围：delete:packages、repo、write:packages - 点击“生成令牌”。生成令牌后，请务必复制并保存该令牌。 - 然后，将个人访问令牌 (PAT) 存储为 GitHub 密钥。GitHub 密钥将用于工作流文件中的身份验证。这样做是为了在不修改工作流文件的情况下提高可重用性、安全性和轮换性。 - 导航到已创建的存储库，然后单击“设置”。 joseOcampoHernandez_3-1760393083849.png - 选择密钥和变量，然后单击操作。 - 我们将在此处添加 2 个密钥。一个是用户名，另一个是个人访问令牌。点击“新建存储库密钥”。 用户名的密钥 - 这可以个性化定制。然而，在本指南稍后将介绍的工作流文件中，该变量设置为 GH_USERNAME。将名称设置为 GH_USERNAME。在 “密钥” 字段中输入您的 GitHub 用户名。 令牌的密钥 - 工作流已将变量设置为 GH_PAT。将名称设置为 GH_PAT。在 “密钥” 字段中粘贴您的个人访问令牌。 joseOcampoHernandez_0-1760393296107.png 3. 现在我们可以通过命令行构建容器镜像。 - 克隆存储库的本地副本。打开该位置的命令行界面。 - 将 dockerfile 保存到克隆存储库的根目录下。 登录到 GitHub 容器注册表。运行： echo | docker login ghcr.io -u --password-stdin 输出： joseOcampoHernandez_1-1760393609136.png -构建容器镜像。这是本指南中最长的步骤，但只需构建一次镜像，就能将其推送到 ghcr 以供使用。运行： docker build -t . 输出： joseOcampoHernandez_3-1760393769087.png - 要验证您的镜像详细信息，请运行： docker images - 标记 Docker 镜像。此命令不会创建新镜像；它只为现有镜像提供新名称和标签。当你准备将镜像推送到像 GHCR 这样的注册表时尤其有用。Docker 要求在推送镜像前必须标记注册表 URL 和存储库名称。运行： docker tag - 将镜像推送到容器注册表。运行： docker push **注意：由于服务器错误，输出可能显示为失败。如果出现这种情况，只需再次运行该命令即可。 joseOcampoHernandez_0-1760394102481.png 再次运行该命令： joseOcampoHernandez_1-1760394158501.png 恭喜！MCUXpresso SDK 和构建系统现已集成在容器镜像中，可以用于构建项目。接下来，我们将配置 GitHub 以实现自动化。 3. 自动化 - GitHub Actions 为什么要使用 GitHub Actions？ GitHub Actions 是 GitHub 内置的自动化工具，允许你定义工作流，根据推送或拉取请求等事件来构建、测试和部署代码。它使用 YAML 文件来配置这些工作流，从而可以直接在存储库中轻松设置 CI/CD 管道。 1. 在本地克隆您的存储库。然后导航到其根目录。 - 在项目根目录内创建 .github/workflows 目录。 - 导航至 VS 代码并创建一个新文件。将其命名为：docker-build.yml - 我们在下面提供了一个模板，您可以将其复制并粘贴到 docker-build.ymll 中。 该模板的用途： 在推送或 PR 时运行 使用包含 MCUXpresso SDK 工具的容器 检查您的存储库 将您的应用复制到 West 工作区 使用 West 为 FRDM-MCXA153 构建它 name: Build MCUXpresso Project on: push: # branches: [ main ] pull_request: jobs: build: runs-on: ubuntu-latest container: image: ghcr.io/nxp-jose/mcuxpresso-sdk:latest steps: - name: Checkout repository uses: actions/checkout@v3 - name: Copy my_app into west workspace run: | cp -r $GITHUB_WORKSPACE/my_app /workspace/mcuxsdk-manifests/my_app - name: Build project using west working-directory: /workspace/mcuxsdk-manifests run: | echo "Building project..." west build -b frdmmcxa153 my_app 4. 使用管道 完成您的工作区设置 该过程的最后一步是创建一个项目以用于我们的管道。 1. 打开适用于 VS Code 的 MCUXpresso 2. 点击“从存储库导入示例” joseOcampoHernandez_0-1760642379145.png 3. 从 MCUXpresso SDK 24.12 或更高版本导入一个项目，作为独立示例。将导入位置设置为克隆存储库的根目录。 joseOcampoHernandez_1-1760642544479.png 4. 将更改暂存、提交并推送到您的存储库。现在，您的存储库中应该包含： joseOcampoHernandez_2-1760643602809.png *注意：如果在本地构建项目，您将看到 .vscode 目录。将此目录推送到存储库是完全可选的。 5. 推送完成后，在 GitHub 上启用工作流。启用工作流后。连续的推送或拉取请求将触发自动项目构建。 6. 检查构建细节。 - 导航至 GitHub 上的“操作”选项卡 joseOcampoHernandez_3-1760643944715.png - “操作”选项卡将显示工作流已运行的所有实例。 joseOcampoHernandez_4-1760644181055.png - 点击“构建”查看详细信息。 joseOcampoHernandez_0-1760644351578.png - 显示的详细信息是构建过程中执行的各个步骤。点击步骤以查看具体详情。 joseOcampoHernandez_1-1760644531717.png 5. 结论 本指南中概述的 CI/CD 管道为使用 Docker、MCUXpresso SDK 和 GitHub Actions 自动构建提供了一个简单而有效的起点。虽然该示例以基本工作流为重点，但可对其进行广泛自定义，以满足项目的特定需求，例如集成自动测试、添加质量检查或使用自定义 MCUXpresso SDK 清单。利用这些工具，团队可以简化开发流程，确保一致性，并以最少的人工干预来扩展流程。 MCUXpresso SDK

Example S32K312 ADC_IP Continuous Scan DMA S32DS36 RTD600 * ================================================================================================== * Detailed Description: * * This example shows how to implement ADC continuous scan with DMA read. * ADC1 is set to perform continuous scan of 4 channels (S10/S11/S12,S13) with DMA request enabled * for last channel S13. DMA reads respective sequential ADC data registers in one major loop. * * ADC1 channel S10 is connected to board's potentiometer, converted value is used to dim board's LED. * * ================================================================================================== * Test HW: S32K312EVB-Q172 * MCU: S32K312_172LQFP * Compiler: S32DS 3.6.3 * RTD release: S32K3_S32M27x Real-Time Drivers ASR R21-11 Version 6.0.0 * Debugger: On-Board Debugger (J40), Lauterbach * Target: Internal_FLASH * ==================================================================================================   Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.  

初めてのMQXLiteアプリケーションの作成 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 投稿者:ルイス・ガラビト アプリケーションエンジニア TICS, メキシコ 新しい環境で初めてアプリケーションを開発するために費やす時間は、かなりのものになる可能性があります。環境がどのように機能するかを理解し、この環境のアプリケーションを生成できるようにする必要があります。 このアプリケーション・ノートの目的は、開発者がフリースケールMQXLite RTOSで初めてのアプリケーションの開発を迅速かつ容易に開始できるようにするための知識を提供することです。 このドキュメントでは、開発者が基本的なフリースケールMQXLiteアプリケーションを作成するために理解しておく必要のある基礎を提供します。 このアプリケーション・ノートは、 Kinetis KL2 USBマイクロコントローラ ・ファミリ、特にKL25Z128VLK4マイクロコントローラに基づいています。この例では、Freescale Freedom開発プラットフォーム・ボード(FRDM-KL25Z) も使用されます。 アプリケーションノートの全文は添付されています。

无线充电让您摆脱电线的束缚！ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您的智能手机、平板电脑或数字智能手表的电池可能会没电，或者您的床头柜或办公桌上的充电线可能缠绕不住您，那么无线充电器的简便性将使您的梦想成真！但无线充电器需要很多技术，而且并不是都一样。NXP 的发射器和接收器组件系列为 Qi 和 Rezence 标准提供解决方案。我们对这两者进行了研究，并提供了一些实用的硬件解决方案来切断这种联系。

FTF-ACC-F1276.pdf This session will explain how Freescale can enable customers to develop 76-81 GHz short and long range radar applications using the MPC577xK MCU, it will explain the concepts of the radar algorithms, including practical aspects such as SDADC or MIPI CSI sampling, Chirp Generation, Data Compression, R,V FFT, Detection and Tracking algorithms, and the benefits of the new Freescale IP that can allow them to improve their system resolution and accuracy. In this session customers will take away a detailed understanding of how to develop fast modulation radar systems using the MPC577xK MCU including the BOM cost advantages it also brings. This session will explain how Freescale can enable customers to develop 76-81 GHz short and long range radar applications using the MPC577xK MCU, it will explain the concepts of the radar algorithms, including practical aspects such as SDADC or MIPI CSI sampling, Chirp Generation, Data Compression, R,V FFT, Detection and Tracking algorithms, and the benefits of the new Freescale IP that can allow them to improve their system resolution and accuracy. In this session customers will take away a detailed understanding of how to develop fast modulation radar systems using the MPC577xK MCU including the BOM cost advantages it also brings.

FTF-ACC-F1247 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将涵盖当前变更管理面临的各种主题，包括产品变更通知 (PCN) 对飞思卡尔客户的重要性（特别是在降低成本方面）以及产品和制造流程的质量改进。本次会议还将讨论从金线到铜线转变的几个方面，包括这一转变的技术细节、飞思卡尔为实现这一转变所做的工作、按产品系列进行的推出时间审查以及客户批准的重要性。FTF-ACC-F1247 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本次会议将涵盖当前变更管理面临的各种主题，包括产品变更通知 (PCN) 对飞思卡尔客户的重要性（特别是在降低成本方面）以及产品和制造流程的质量改进。本次会议还将讨论从金线到铜线转变的几个方面，包括这一转变的技术细节、飞思卡尔为实现这一转变所做的工作、按产品系列进行的推出时间审查以及客户批准的重要性。FTF-ACC-F1247

S32K3 上的 LDREX/STREX/CLREX——似乎在 SRAM 中也能正常工作？ 我之前问过一个问题——https://community.nxp.com/t5/S32K/Understanding-Atomics-i-e-STREX-LDREX-on-S32K3/m-p/2356118 ——而回答似乎暗示，即使我仅在单核上使用 LDREX/STREX/CLREX，也无法依赖其行为来防止中断服务程序（ISRs）或中断请求（IRQs）与主线程发生冲突，尤其是当被检查的内存位于 SRAM 中时。 不过经过一些测试，结果似乎与我的预期一致——能否请设计团队确认，LDREX/STREX/CLREX 并不负责解决来自单个内核的访问冲突？我知道这无法阻止DMA与Cortex-M7内核之间的独占访问，但内核自身之间的访问又如何呢？ Re: LDREX/STREX/CLREX on S32K3 - seems to work in SRAM? 你好 @kscz， 我也进行了测试，根据测试结果，我重新开启了这项讨论。 一旦有最新消息，我会尽快回复您。 此致， 丹尼尔 Re: LDREX/STREX/CLREX on S32K3 - seems to work in SRAM? 你好@kscz ， 我已经确认，SRAM 中的行为与 TCM 中的行为相同。我已经据此更新了之前的回答。谢谢你指出这一点。 BR，丹尼尔

什么是工业以太网协议？EtherCAT、PROFINET 和 EtherNet/IP 详解（日语博客） 目录 介绍 什么是工业以太网？ 工业网络的基本结构 1. EtherCAT（超高速、低延迟方向） 2. Profinet（灵活性/互操作性） 3. 以太网/IP（IT 亲和性/标准化） 总结 介绍   工业设备通信正迅速从传统的现场总线转向基于以太网的系统。而这一转变的核心正是工业以太网协议。   本文重点介绍三种广泛使用的协议，并清楚地解释它们在技术结构和设计理念上的差异。 以太网 PROFINET 以太网/IP （※评估和实施方法将在另一篇文章中详细说明。） 什么是工业以太网？   简而言之，工业以太网是一种通信技术，与通用以太网相比，它增强了“实时性能”、“鲁棒性”和“诊断能力” 。 标准以太网在工业应用中面临以下挑战：   这是一种尽力而为的通信方式，延迟会根据负载和切换过程而变化。 可能会出现丢帧（丢包）现象。 TCP/UDP/IP 并非为实时控制而设计。 为了应对这些挑战，工业以太网协议采用独特的方法来满足以下要求：   实时通信 同步控制 冗余配置 诊断功能   ■ 理解工业以太网的关键点：OSI 模型   理解工业以太网的关键之一在于理解“实时性能是在哪一层实现的”，而OSI参考模型有助于理解这一点。OSI模型将通信功能划分为七层，每一层都扮演着不同的角色，从物理信号的传输到应用处理。 工业以太网以 OSI 的每一层为基础，并针对每种协议扩展和优化特定层，从而实现实时性能和可靠性。 工业以太网中的 OSI 参考模型： 等级制度 姓名 工业以太网的作用 7 应用 通信数据内容（设备控制、状态、设置） 6 推介会 数据编码、压缩和加密 5 会议 建立、维护和终止通信 4 运输 通信质量控制（TCP/UDP），数据传输保证。 3 网络 通过 IP 地址路由（确定数据包目的地） 2 数据链路 通过 MAC 地址进行数据传输，创建以太网帧 1 物理 电缆（Cat5e/6 等）、连接器和物理信号传输。 工业以太网协议所使用的层： ZHOU_XIAO_0-1779432108374.png 以太网协议各特性： 协议 等级制度 特点 以太网 2 无需使用IP即可实现高速传输 PROFINET RT/IRT 是L2 NRT L3/4 RT 和 IRT 的区分使用。 以太网/IP 3/4 基于标准以太网 这些特征差异直接导致以下结果： 速度（实时性能） 实施成本 适用范围   工业网络的基本结构   工业以太网通常具有共同的基本结构，而本文讨论的三种协议（EtherCAT、PROFINET 和 EtherNet/IP）也不例外。 ■ 系统和设备结构   工业网络大致可以分为“控制器侧”和“设备侧”。   主设备（控制器）： 它在控制整个网络中起着核心作用。 启动通信并设置连接参数 发送输出数据和接收输入数据 沟通管理和终止流程 典型例子：PLC、工业PC 子设备（设备）： 响应连接请求并发送和接收必要数据。 接收输出数据并发送输入数据 网络自通知 根据需要发送警报 典型例子：传感器、伺服电机、执行器 ■ 沟通方式：周期性沟通与非周期性沟通 连接建立后，主设备和子设备之间会以极短的时间间隔持续交换I/O数据。根据应用场景的不同，这种通信可分为“周期性通信”和“非周期性通信”。 周期性沟通（周期性沟通） 应用：用于实时控制 - 对于需要实时性能的应用，例如电机控制和I/O控制，至关重要。 非循环通信 用途：配置、诊断和事件管理 - 用于读取和写入配置数据、诊断信息和意外事件通知。 ■支持实时性能的关键概念：同步（时钟） 在工业系统中，“所有设备都按照同一时间标准运行”这一点至关重要。 例如，如下图所示，如果多个设备在不同的时间 Δt₁、Δt₂ 和 Δt₃ 获取数据，则控制器 (PLC) 接收到的信息将不是来自同一时间的数据，而是时间上交错的“单独的快照”。 结果： 位置错位的发生 错误的控制判断 特别是运动控制中的关键同步误差 这可能会导致诸如此类的问题。 因此，在工业以太网中，设备间时钟同步机制是一个至关重要的要素。 ZHOU_XIAO_2-1779431627985.png 三种协议的技术比较总结   以太网 PROFINET 以太网/IP 运营组织 贝乔夫 / ETG（EtherCAT 技术集团） 西门子 / PNO（PROFIBUS & PROFINET International） 洛克威尔 / OVDA（开放设备网络供应商协会） 沟通方式 摘要帧（子设备在帧中读取和写入数据） 基于第 2 层的实时通信 (RT/IRT) CIP：显式（TCP）/隐式（UDP）通信模型 主要用途 运动控制，超高速控制 通用型FA、过程控制以及广泛的工业应用 工厂自动化、PLC网络、机器人 周期 约 31.25μs 级（取决于具体实现，速度非常快） RT：几毫秒 IRT：31.25μs（取决于具体实现方式，TSN/IRT） 通常情况下，延迟级别为 10 毫秒（基于 UDP）。 同步方法 分布式时钟（DC） IRT：精确同步（PTCP） CIP 同步（IEEE1588） 设备型号 PDO/SDO（基于 EtherCAT 的 CANopen） 插槽/子插槽（GSDML） 类/实例/属性对象模型 拓扑 线型、树型、环型（低延迟） 线、星、环（MRP/MRPD） 线、星、环（DLR） 优势 简而言之，就是高速低延迟/硬件处理。 多种类别和诊断功能，高度互操作性 广泛应用于标准以太网基础设施，易于理解。 接下来，我们将解释每项技术特点。 1. EtherCAT （超高速、低延迟导向型） ■ EtherCAT 概述 由 Beckhoff Automation 开发，ETG 管理。 它运行于第 2 层，没有 IP/TCP/UDP 开销。 周期时间：约31.25微秒（取决于具体实现方式） 同步精度：±1μs 或更小 ZHOU_XIAO_0-1779258860716.png ■ 网络配置 主设备（主控设备）和  多个子设备（从设备） 该子设备配备了ESC （ EtherCAT 从控制器），并使用专用硬件进行高速处理。 虽然线路配置是基本设置，但它也支持使用环形结构的冗余配置。 ZHOU_XIAO_0-1780967472867.png 图： EtherCAT网络配置图 EtherCAT 最显著的特点是“即时处理”。单个帧在经过所有设备的过程中都会被处理，每个设备都会在传输过程中读取和写入数据。由于处理工作由专用硬件（ESC）完成，无需 CPU 参与，因此延迟极低。   ZHOU_XIAO_3-1780967819685.png 图： EtherCAT网络传输图像 ■ 相关协议转换：EtherCAT（IEC 61784-2-12） • CoE （CAN over EtherCAT）：通过EtherCAT帧隧道化，使CANopen通信得以使用。 • FoE （File over EtherCAT）：一种通过 EtherCAT 传输文件的协议。 EoE （以太网 over EtherCAT）：一种封装和传输常规以太网帧（例如TCP/IP ）的机制。 ZHOU_XIAO_4-1779258860793.png 图：主设备（MDevice）的EoE协议转换 2. PROFINET （灵活性/互操作性） ■ PROFINET 概述 由西门子开发，PNO 管理。 基于标准以太网 根据应用场景选择RT/IRT/NRT。 生产者/消费者模式 ■ 网络配置 灵活支持各种拓扑结构，例如线型、星型和混合型拓扑结构。 它还支持通过MRP （媒体冗余协议） / MRPD（IRT）实现环冗余。 PROFINET的通信性能按“一致性等级( CC )”进行分类。 CC-A ：基本实时，所有IT服务（例如TCP/IP ）均可无限制使用。 CC-B ：为通用FA的RT添加网络诊断和其他功能。 CC-C （ IRT ）： 31.25 μs级运动应用 ■ 沟通类型 NRT（非实时）：记录读/写：非周期性地发送和接收参数和设置。报警：通知设备异常情况。 RT：周期性I/O通信，通常为1 毫秒 IRT（等时性）：时间同步的高速周期性通信，通常为 31.25 微秒。 → 实现了高度灵活性、详细的诊断和高度互操作性。 ZHOU_XIAO_5-1779258860863.png 3. 以太网/IP （ IT兼容性/标准化） ■以太网/IP概述 EtherNet/IP 由 ODVA（开放设备网络供应商协会）管理。 它采用 CIP（通用工业协议），该协议运行在 TCP/UDP/IP（L3/L4）之上的一层。 面向对象模型 ZHOU_XIAO_6-1779258860900.png ■ 网络配置 支持线型、星型和环形拓扑结构。 支持使用DLR （设备级环）的高速冗余。 主设备 →扫描器：作为控制器运行，通常发起请求。 子设备 →适配器：响应该请求的设备。 ■ EtherNet/IP 的关键特性：“面向对象模型” 每个设备都被定义为由“类”、“实例”、“属性”和“服务”组成的对象的集合。 类：函数类型（例如，恒等函数、汇编函数） 实例：该类的特定实例。 属性：每个实例所具有的特定值。 服务：操作细节，例如读写。 这使得设备的功能结构非常清晰，从而实现了与不同制造商之间的高度兼容性。 ZHOU_XIAO_7-1779258860986.png ■ 沟通类型 显式消息连接 使用TCP ，读取和写入配置值，执行自我诊断，并记录日志。 分别发出一次“读”和一次“写”之类的指令。 隐式消息传递 - I/O 连接 它使用UDP 协议，可以实现实时通信，例如循环I/O ，扫描器会定期发送和接收I/O数据。   EtherNet/IP的关键特性是它能够使用隐式（ UDP ）协议实现高速I/O通信。 总结 工业以太网不仅仅是通信；它是一种能够实现实时控制的系统技术。本文介绍的三种协议分别通过不同的方法来实现这一目标。 协议 设计理念 主要用途 以太网 高速、低延迟 运动控制 PROFINET 灵活性和集成性 通用工厂自动化（FA） 以太网/IP IT集成 PLC网络   作为未来的发展趋势，产业网络将朝着以下方向发展。 TSN （时间敏感网络） 安全（包括符合《社区再投资法案》） 与OPC UA集成 换句话说，关键在于“实时性× IT集成×安全性”的融合。 下次， 为什么i.MX RT1180适用于工业以太网协议？ 实际实施和评估程序 我们将详细解释这一点。 ============================= 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。 ） 工业设备通信正迅速从传统的现场总线转向基于以太网的系统。而这一转变的核心正是工业以太网协议。 本文重点介绍三种广泛使用的协议，并清楚地解释它们在技术结构和设计理念上的差异。 以太网 PROFINET 以太网/IP （※评估和实施方法将在另一篇文章中详细说明。）   本文将介绍主导工业以太网的三大协议：EtherCAT、PROFINET 和 EtherNet/IP，并清晰地解释它们在技术结构和设计理念上的差异。   （阅读时间：15分钟） i.MX RT 处理器 介绍 日本博客

i.MX95 EVKまたはi.MX8QM上でAndroidとLinuxの両方をDomUとして実行する Xenハイパーバイザー上でAndroid オートモーティブとLinuxゲストOSの両方を実行できるかどうか、その適用可能性を検証しています。 リリースノートとユーザーガイドの間には、矛盾する情報がいくつかあります。Android オートモーティブのリリースノートでは、i.MX8QMとi.MX95の両方で仮想化 Android に「N」が付いていますが、ユーザーガイドではXen上でAndroidを実行する方法が明確に説明されています。 AKassem_0-1779120051485.png サポートされているかどうかという質問に答えたいのですが、異なるドキュメントに基づいて正確に判断することができません。古いドキュメントではi.MX8QMでもサポートされていると書かれていますが、新しいドキュメントではサポートされていないと書かれています。 ユーザーガイドには、LinuxゲストまたはAndroid Automotiveゲストを実行できると記載されていますが、それらが同時に共存できるかどうか（2つのDomU）については記載されていません。i.MX95、i.MX8QM、あるいはその両方でこれが可能かどうか教えてください。 質問1で述べたように、i.MX 8QuadMaxについては、古いドキュメントにXen上でAndroid VMを実行できると記載されていましたが、それはAndroid 9またはAndroid 10の場合でした。最近のドキュメントでは、Xen 上の Android VM では「N」と記載されており、ユーザーガイドには i.mx 95 の手順しか記載されていません。新しいバージョンの Android を実行できない理由は何でしょうか？ Android i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Re: Running both Android + Linux as DomU's on i.MX95 EVK or i.MX8QM こんにちは、 1> 以前のバージョンの Android では、デモ/リファレンスとして i.MX8 XEN のサポートがありましたが、新しい Android リリースではサポートされなくなりました。一方、i.MX95については、最新リリースでサポートされています。 2> 上記のように、古いリリースでは i.MX8 で可能かもしれませんが、i.MX95 は公式にはサポートされていませんが、カスタム統合により技術的には可能です。 3> これは、1) i.MX8 用の公式 XEN がデモ/リファレンスとしてリリースされたことに関連しており、新しい Android リリースへの変更により、焦点は新しい i.MX95 に移されました。 よろしくお願いいたします。 アルド。 Re: Running both Android + Linux as DomU's on i.MX95 EVK or i.MX8QM こんにちは、迅速なご対応ありがとうございます！ i.MX95の場合、公式にサポートされているのはDom0（Linux、ドキュメントを見る限りシンクライアントではないようです）とDomU（Android）のみです。Dom0にディスプレイを1つ、DomUにもう1つのディスプレイを接続することは可能ですか？ i.MX95でFUTURE的に2つのDomUをサポートする予定はありますか？ Re: Running both Android + Linux as DomU's on i.MX95 EVK or i.MX8QM こんにちは、アルドさん。 私の質問について何か進展はありますか？

LX2160 定制板上模块的掉电 在我们基于 LX2160 的定制主板中，没有 SPDT 开关可用于通过软件控制电源轨。 不过，我们的目标是降低 USB、WiFi、BT、PoE 和蜂窝模块的功耗。 我方提出了当前的意见和做法： 1.WiFi、BT 和蜂窝模块通过 PCIe 连接。 我们观察到，这些功能可以通过 SerDes 配置禁用。 通过将 SerDes 协议配置为 S2 = 9，所有相应的通道都被配置为 SGMII，而不是 PCIe，从而有效禁用 PCIe 连接的模块。 2.USB 模块似乎没有类似的基于 SerDes 的禁用选项。 对于 USB，我们目前正在尝试使用以下方法基于 GPIO 禁用： USB1_MUX_EN USB2_MUX_EN RCW 配置已经过验证，相应引脚已确认配置为 GPIO。 然而，即使驱动这些 GPIO 进行禁用操作，也无法观察到预期的功耗降低。 3.PoE 模块（AQR113c 用于以太网） 请就可能需要修改的其他文件或配置提出意见/建议，以便完全禁用和降低功耗。 Re: Power down of modules on LX2160 custom board 闲置时是否可以对 USB、WiFi、BT、PoE 和蜂窝模块掉电？还是产品的配置不同，这些接口根本不会被使用？   请注意，即使接口未使用，仍需为其电源轨供电。LX2160A 不支持从其轨道上拔下电源。 如果断开接口设备的电源，则需要确保 LX2160A I/O 不会发生泄漏   你能做什么？ 1) 内核消耗最大功率。SDK 支持在不使用 CPU 时降低其频率，以节省功耗。 Refer 电源管理单元 - [Layerscape Software Development Kit User Guide | NXP 半导体|https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-2E8E375E-7DCD-4671-B0CF-D4713D8BB9EB.html] 2) 未使用的 IP 可通过 DEVDISR 进行时钟门控。不过，一旦禁用，就无法再启用。 3) 如果 SerDes 通道未使用，可将其断电。参见第 26.10.2 节LX2160A 参考手册中未使用的车道 4) 当通过 RCW 设置选择 SerDes 协议时，它还会根据协议要求配置与该协议相关的寄存器。因此，重新配置车道并不是正确的方法。 5) 从原理图片段来看，您已将 SerDes#2 配置为 SRDS_PRTCL_S2 =3，但只使用了单通道。 你可以使用 SRDS_PRTCL_S2=11 并按照 (4) 对未使用的通道进行掉电。类似的机制也可应用于其他 SerDes。 6) 如果 PCIe 未使用 Gen3，则 PLLF 可以断电。同样，未使用的 PLL 也可以断电 谢谢！ Re: Power down of modules on LX2160 custom board 如何测量耗电量？ 请注意，对于 SerDes 通道，您需要检查为 SerDes I/O 供电的 0.9V 和 1.8V 电源通道。 对于 DFS，请检查 VDD（0.8V）电源的功耗。 既然这是你的定制电路板，你有电源轨的功率测量电路吗？ 如果你在自定义主板的输入上进行衡量，我不确定你会看到多大的差异。这还取决于测量的最小计数。 为进行检查，可在较低配置下运行核心/平台。查看设计检查表，其中有 VDD 轨功耗图表。 Re: Power down of modules on LX2160 custom board 你好， 感谢您的及时回复。我附上了我对您分享的有关功率优化建议的观察和测试结果。请查看它们，并与我们联系是否建议进行其他检查或配置。 要点 说明 CPU 热插拔/频率缩放观测 我们使用以下方法测试了 CPU 热插拔、CPU 频率缩放和不同的 CPU 模式： lscpu | grep line 观察结果： On-line CPU(s): 9 Off-line CPU(s): 0-8,10-15 不过，在这些情况下都没有观察到明显的功耗降低。 通过 DEVDISR 进行未使用的 IP 时钟门控 我们知道未使用的 IP 可以通过 devDisr 进行时钟门控。但是，由于禁用这些区块如果不重置就不可逆转，我们认为这种方法风险很高，因此不建议在我们当前的测试中使用这种方法。 未使用的 SerDes 通道掉电 寄存器写入成功。 不过，迄今为止还没有观察到明显的功耗降低。 SerDes 协议配置优化 PLL 掉电未使用的 Gen3 PCIe 应用配置： SRDS_REFCLKF_DIS_S2 = 1 SRDS_PRTCL_S2 = 11 SRDS_INTRA_REF_CLK_S2 = 0 SRDS_PLL_PD_PLL3 = 1 Re: Power down of modules on LX2160 custom board 你好， 我们正在使用这些连接到 BMC 的电流传感器来测量功耗，其中 VCC_12V 感应定制板的输入，而 VCC_0V8 正在感应恩智浦 (LX2160A) 芯片组的输入。 同样 在闪存时（这些以 VCC_12V 即总功耗测量）-使用 CodeWarrior（可能会下降约 10W）和 -使用 (echo mem > /sys/power /state & echo freeze > /state sys/power/state）（可能会下降约 6W)（但在此之下，由于不存在用户交互，因此不建议将其用于我们的测试）， Re: Power down of modules on LX2160 custom board 与内部团队讨论，我们我们已经回答了 您的与配置相关的问题。 在 12V 输入电压下，10 瓦的功耗在我们看来是相当合理的。 我们对于 LX2160A 而言，这是很合理的。 请 请分享您的目标，您的 示意图和配置、日志和应用。我们将检查还能实现哪些功能。

s32k344 罐 你好，我正在使用 s32k344 电机驱动器代码，并有几个原型。我发现其中一台 CAN 机器在运行一段时间后会脱机，发送和接收都会出现异常。我打开了离线回复，发现信息会丢失 200 毫秒的帧。我更换了 CAN 收发器，但同样的现象依然存在。我已经阅读了勘误手册，是否是芯片本身存在这个错误？ Re: s32k344 can Hi@qicbeng 示例代码"MCSPTE1AK344_PMSM_FOC_2Sh_ll" 不提供 FLEXCAN 功能；您必须自行添加 CAN 相关功能。 请提供您的 CAN 测试项目，以便我检查您的配置是否正确。

RW612 TF-M NS：Flexcomm UART 无功能 - 时钟驱动器使用安全 CLKCTL1 地址 您好， 我发现了一个 Bug，当出现以下情况时，任何 Flexcomm UART 都会完全失效 为启用 TF-M 的 frdm_rw612/rw612/ns 构建。 根本原因：时钟驱动器使用安全 CLKCTL1 地址 (0x50021000) 启用 Flexcomm 时钟时。从 NS 世界中默默地写下这些文字 被忽视了，让外围没有了防护罩。所有 USART 寄存器的读数均为 0x00000000。 解决方法是在 UART 启动前通过 NS 别名手动启用时钟： volatile uint32_t *clkctl1_ns = (volatile uint32_t *)0x40021000UL； clkctl1_ns[0x508/4] = 0x01； clkctl1_ns[0x40/4] = (1UL<< 8)； 我已经在 nxp-zephyr GitHub 上提交了一份错误报告： https://github.com/nxp-zephyr/nxp-zephyr/issues/35 有人遇到过这种情况吗？是否正在进行适当的修复？ 谢谢！ Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好，@chofmeister。 请与我们分享您复制这种行为的步骤。我无法通过 MCUXpresso for VS Code 使用 psa_protected_storage 示例来重现这种行为，该示例使用 TF-M 和 UART 控制台，信息正在打印，因此 UART 外设的时钟是正确的。 此外，对于 FRDM-RW612，时钟初始化是在 soc.c 文件的 clock_init 函数中完成的。 Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 感谢您提供的链接。确认一下 - 我运行的是 4.3.0 版来自 nxp-zephyr 下游仓库，那里存在错误。 我阅读了《时钟配置》一文。据我所知，外设 时钟应在 init.c 或 soc.c 中的 board_early_init_hook() 中启用。 查看 frdm_rw612 init.c、我可以看到 Board_early_init_hook() 已在 上实现，但并未启用任何 Flexcomm 时钟。 根本原因特定于 TF-M NS 版本：HAL 时钟函数 (fsl_clock.c)使用安全 CLKCTL1 地址（0x50021000）。在 NS 世界中，对该地址的写入将被静默忽略，从而使 Flexcomm0 完全处于无时钟状态 - 所有 USART 寄存器的读数均为 0x00000000。 我目前的解决方法是在 UART 启动之前，在应用代码中直接写入 CLKCTL1 NS 别名 (0x40021000)，这虽然有效，但 显然不是正确的长期解决方案。 根据这篇文章，修复可能属于 init.c 中的 board_early_init_hook() 。在 CONFIG_TRUSTED_EXECUTION_NONSECURE 保护下，使用 NS 别名地址。不过，在尝试公关之前，我想确保这与 团队的方法一致。 这是基于 RW612 的 TF-M NS 版本 的已知差距吗，是否有 建议的修复正在进行中？ Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好，@chofmeister，希望你一切都好。 我看到您在我们的下游存储库中提交的报告是您在 Zephyr 4.1.0 版本中发现的一个错误、能否请您确认一下，在我们最新的下游版本库（目前为 4.3.0）中是否仍然存在这种行为？ 另外，我还建议查看Zephyr 中的时钟配置，因为 Zephyr 时钟管理子系统尚未支持时钟配置和启用。 Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好，RomanVR、 感谢您的回复。我可以在 soc.c 中看到时钟启动代码： #if (DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm0), nxp_lpc_usart, okay))&& CONFIG_SERIAL CLOCK_SetFRGClock(&(const clock_frg_clk_config_t){0, kCLOCK_FrgPllDiv, 255, 0})； CLOCK_AttachClk(kFRG_to_FLEXCOMM0); #endif 代码是正确的，但底层 HAL 函数 （CLOCK_AttachClk、CLOCK_SetFRGClock）使用的是安全的 CLKCTL1 地址 (0x50021000)。在 NS 世界中，对该地址的写入会被 默默忽略，从而使 Flexcomm0 处于无时钟状态。所有 USART 寄存器的读数均为 0x00000000。 我还在 nxp-zephyr GitHub 仓库（问题 #35）上提交了一个错误， 贡献者 waqar-tahir 证实了这个问题，并指出这个问题已经在即将发布的 4.4 下游版本中得到解决。 目前，我的解决方法是在 UART 启动之前，在应用代码中直接写入 CLKCTL1 NS 别名 (0x40021000)。 希望这有助于澄清根本原因。

iMX95：两路视频输入和两路视频输出。 下午好！ 我们有一个想使用 iMX95 的项目，但需要两个视频输入和两个视频输出。在输入方面，我们希望使用两个 MIPI-CSI 输入。关于视频输出，我们希望使用两个 LVDS 输出，因为两个 MIPI-CSI 输入无法使用 MIPI-DSI 输出（由于 MIPI-DSI/CSI 组合）。 我们有几个关于 LVDS 输出的问题，因为我们希望一个输出连接到 LCD（480x272），另一个连接到 LVDS 转 HDMI 桥接器。以下是我们目前提出的问题： 1.输出端是否可以像我们描述的那样？也就是说，一个 LVDS 输出端连接 LCD，另一个 LVDS 输出端连接 LVDS 转 HDMI 桥接器。 2.您推荐哪种 LVDS 转 HDMI 桥接器？我们看到的是 IT6263 芯片，对吗？还有其他人吗？ 3.我们需要"LVDS 转 HDMI" 桥接器后的 HDMI 输出支持以下格式：720p50/59/60、1080p50/59/60、PAL、NTSC 和 1080i50/59/60。有可能达到 1080p60 吗？通过 iMX95 的 LVDS 和"LVDS 到 HDMI" 桥接器，是否可以支持隔行扫描格式输出？ 谢谢， Daniel。 Re: iMX95: Two video inputs and two video outputs. 感谢您的回复！ 关于 HDMI 输出的隔行扫描格式支持...如果我们使用 MIPI-DSI 转 HDMI 桥接器，是否会支持隔行扫描格式，还是会出现与使用 LVDS 转 HDMI 桥接器相同的问题？ 谢谢， Daniel。 Re: iMX95: Two video inputs and two video outputs. 你好 1.是的，这是可能的。 2。IT6263 是我们的参考设计中唯一经过测试的芯片，其他 LVDS 转 HDMI 芯片应该可以正常工作。 3. i.MX95 最多支持 2 个 1080p60 LVDS Tx（2x 4 通道或 1x 8 通道），电路板支持包不支持隔行格式，应由您自己实现。 顺祝商祺！ Re: iMX95: Two video inputs and two video outputs. 你好 由于我们的 BSP 中未实现隔行格式，因此会出现与使用 LVDS 转 HDMI 桥接器一样的问题。 顺祝商祺！ Re: iMX95: Two video inputs and two video outputs. 感谢您的回复！ 关于 HDMI 输出的隔行扫描格式支持...如果我们使用 MIPI-DSI 转 HDMI 桥接器，是否会支持隔行扫描格式，还是会出现与使用 LVDS 转 HDMI 桥接器相同的问题？ 谢谢， Daniel。 Re: iMX95: Two video inputs and two video outputs. 在澄清了有关产出的问题后（非常感谢），我们想澄清有关两项投入的一些要点。 首先，我会解释我们的想法，然后提出问题。我们要使用 iMX95 的两个 MIPI-CSI 输入：一个连接到 TC358743 芯片，另一个连接到 TC358748 芯片。对于这两种输入，我们希望支持以下格式：720p50/59/60、1080p50/59/60、PAL、NTSC 和 1080i50/59/60。 这一设置提出了以下问题： 1.是否可以像我们描述的那样进行输入？也就是说，一个 MIPI-CSI 输入来自 TC358743，另一个 MIPI-CSI 输入来自 TC358748，这两个输入可支持不同的视频格式。 2.有支持这两种芯片的驱动程序吗？TC358743 和 TC358748？ 3.MIPI-CSI 输入是否也支持隔行扫描格式 PAL、NTSC 和 1080i50/59/60？如果是这样，如何使用所谓的"虚拟通道" ？文档似乎支持 MIPI-CSI 输入中的隔行扫描（"CSI Pixel Formatter (CSI_PIXEL_FORMATTING)" => " 支持 YUV/RGB 数据类型的隔行扫描模式" ），但我们要求确认。 4.由于 TC358743 芯片的 MIPI-CSI 接口对隔行扫描数据的限制，我们无法使用 YUV422。我们正在考虑使用 YUV444 格式，但通过 MIPI-CSI 接口将其作为 RGB 格式发送，然后可能需要更改软件（驱动程序）。这可能吗？软件（驱动程序等）是否已经准备就绪，还是需要我们自己动手？ 5.我们希望将两个 MIPI-CSI 接口之一的输入路由到 H264/HEVC 视频编码器，但该编码器需要 YUV420，而 MIPI-CSI 接口是 YUV422（或 YUV444）。根据文档，似乎可以使用"HW" 模块"CSC 从 YUV422/YUV444/RGB 8 位" 。这个 CSC 是 ISI 模块中的那个，还是另一个？是使用 CSC 进行转换，还是必须通过软件将 YUV422/YUV444 转换为 YUV420？ 6.继续前面的问题，考虑将视频解码器输出发送到 LVDS，这需要将 YUV420（解码器）转换为 RGB（LVDS）...这种转换（YUV420 到 RGB）是使用硬件模块（也许可以使用显示控制器的"Blit 控制器" ）还是必须在软件中完成？ 7.说到色彩转换，我们还有一个关于支持和使用 BT601 和 BT709 的问题。它们是否在任何硬件转换中都受支持，还是取决于特定的系数配置或其他因素？ 谢谢， Daniel。 Re: iMX95: Two video inputs and two video outputs. 还有一个新问题： 8.我们需要对 MIPI-CSI 接口的通道数进行动态配置。这可能吗？ 谢谢你，丹尼尔。 Re: iMX95: Two video inputs and two video outputs. 谢谢！ Re: iMX95: Two video inputs and two video outputs. 你好 关于这些有关输入的新问题，我建议创建一个新的社区主题或提交支持票据。 这将有助于使每个主题集中在一个话题上。 顺祝商祺！ Re: iMX95: Two video inputs and two video outputs. 谁能帮我回答最后 8 个问题？ 非常感谢， Daniel。 Re: iMX95: Two video inputs and two video outputs. 谢谢！你说得对，我会就这些问题开辟一个新的主题。

PFE MCAL driver receiver processing may have reentrancy issue Hi Team From PFE MCAL driver 1.6.0, the receiver processing may have reentrancy issue. The call relationship of function pfe_hif_drv_process_rx_frames() is shown as the following figure.  The _Receive, TxConfirmation and MainFunction will call pfe_hif_drv_process_rx_frames when driver works in polling mode. If the callers are in different tasks, pfe_hif_drv_process_rx_frames has a risk of reentrancy. Should we add exclusive protection for pfe_hif_drv_process_rx_frames ? Regards, Ryder PFE PFE MCAL Re: PFE MCAL driver receiver processing may have reentrancy issue Hello @Ryder_Gong, The PFE team has picked up the case, also who is the customer that reported this? Best regards,  Radu Re: PFE MCAL driver receiver processing may have reentrancy issue Hi, The original issue is from Mobileye, actually software team has involved by a debug call. Re: PFE MCAL driver receiver processing may have reentrancy issue Hello Ryder.  Thank you for finding the race condition. It was confirmed as cause of the "Rx stops working" issue and bug ticket ANET-1032 was created to fix it. It will be fixed by adding an exclusive area protection as you have proposed. The bug affects all versions of the PFE MCAL driver, in polling mode, and it will be fixed in version 1.8.0.