LX2160A 上的 VSC8254 PHY 在 1G SGMII 模式下启动需要协助 大家好， 我们正在开发一款基于 LX2160A Rev2 SoC 的定制电路板，其中 VSC8254 PHY 通过 eMDIO1 连接到 SoC。目前我们在 1G SGMII 模式下启动 PHY 时遇到问题。 到目前为止，我们已经通过在 DPC 文件和 Linux 内核设备树中配置固定链路，成功地在 10G XFI 模式下启动了 PHY。启动后，我们执行 NXP 提供的 mdio_cl45_write 脚本来对所需的 Clause 45 寄存器进行编程，之后链接建立并正常运行。 但是，当我们将配置切换到 1G SGMII 模式时，我们会进行以下更改： 更新 DPC 和 Linux 设备树，使其使用 SGMII 而不是 XFI。 执行 1G 对应的 Clause 45 寄存器初始化序列。 根据新配置的要求，将 SERDES 参考时钟从 125 MHz 更新为 100 MHz。 尽管做了这些更改，PHY 链路仍然无法建立。 供参考： VSC8254 PHY 连接到 SERDES1 MAC3 和 MAC4。 我们使用 RCW 6 进行 10G XFI 配置。 我们对 1G SGMII 配置采用 RCW 4。 关于在 1G SGMII 模式下启动 PHY 是否需要任何额外的配置更改或初始化步骤，请与我们联系。 感谢您的时间和支持。 @yipingwang @chenyin_h Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. 请将 RCW[SRDS_PLL_REF_CLK_SEL_S1] 配置为“00”。 2. 请在 Linux 内核中配置“CONFIG_VITESSE_PHY”。 3. 在 Linux 启动 dts 文件 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 中，请修改 dpmac3 和 dpmac4 的配置，使其与下面的配置类似。 &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "带内状态"; }; aquantia_phy1：以太网物理层@4 { /* AQR107 PHY */ 兼容 = "ethernet-phy-ieee802.3-c45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; 修改为： &dpmac3 { phy-handle = <&sgmii_phy1>; phy-connection-type = "sgmii"; managed = "带内状态"; }; sgmii_phy1：以太网物理层@xx{ reg = <0xxx>;//指定与dpmac3相关的MDIO PHY地址         }; 4. 请按如下方式修改 dtc 文件 dpc-usxgmii.dts。 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII";                         }; 修改为： 板信息 { 港口 { mac@3 { link_type = "MAC_LINK_TYPE_PHY";                         }; mac@4 { link_type = "MAC_LINK_TYPE_PHY";                         };

i.MX RT1010 刷机问题 我正在使用定制板上的 @ i.MX RT1010 ，遇到了刷机问题。 所有电源轨均稳定且符合规格。 RESET引脚稳定（上电后为高电平）。 调试器可以检测到目标设备，但烧录总是失败。 我已经检查过硬件是否存在短路和焊接问题。 开发板 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 ， 为了更好地为您提供支持，您能否提供以下信息？ -您使用的外置闪光灯设备与RT1010-EVK相同吗？如果没有，请问您能否提供您定制板上使用的闪存设备的零件编号？ -您尝试对哪张图片进行编程？这是一个 SDK 示例还是您自己的自定义应用程序？ -您使用哪种工具来对设备进行编程？例如 MCUxpresso IDE、安全配置工具等？ -您是通过 JTAG 还是 SWD 连接？ 如果您认为还有其他细节可能有所帮助，请随时告诉我。 BR 哈比卜 Re: i.MX RT1010 Flashing Issue 你好，哈比卜， 感谢您的反馈， 详情如下： 外部闪存：我的定制板上使用的是AT25SF128A-SHB-T QSPI 或非 闪存，与 EVK 相同。 图片：我正在尝试对evkmimxrt1010_igpio_input_interrupt SDK 示例进行编程。 编程工具： SEGGER J-Link Commander V9.56和SEGGER J-Flash Lite V9.56 。 调试接口： JTAG ，使用与 RT1010-EVK 相同的接口。 图片也附在后面供您参考 所有电源时序 RESET 线均正常工作 Re: i.MX RT1010 Flashing Issue 你好@keerthisri123 ， 请问您是否能够通过 UART 接口连接到您的设备？如果是这样，请您按照安全配置工具用户指南 v26.03 中的 6.15.2 节“连接 RT10xx/RT116x/RT117x 设备的板”中描述的步骤进行操作，并告诉我您的结果？这将有助于确定问题是与SWD连接有关，还是可能存在其他硬件问题。 您可以通过导航至“帮助”→“用户指南”，直接从安全配置工具访问用户指南。 此外，我建议复习MIMXRT1010 处理器硬件开发指南的第 5 章“调试和编程”。本章提供了一些关于调试连接器实现的建议和最佳实践，可以帮助您验证硬件设计并确保可靠的调试操作。 上电时，启动模式引脚和启动配置引脚的状态如何？它们稳定吗？ 最后，能否请您提供上电过程的示波器波形图？这将有助于验证上电时序和初始化顺序是否正确执行。 BR 哈比卜 Re: i.MX RT1011 Flashing Issue 嗨，哈比比， 我附上了一些参考图片，展示了我正在使用的安全配置工具。 我同时使用了 JTAG 和 UART 接口，但仍然收到“检查连接、电源并重置为 ISP 模式”的消息，如下面的错误日志所示。 请问您能否指导我下一步该如何排查这个问题？ 在安全配置过程中，我应该遵循哪些具体步骤？另外，在执行这些步骤之前，是否需要完成任何硬件检查？ 感谢您提前给予的支持。 Re: i.MX RT1011 Flashing Issue 你好@keerthisri123 ， 由于本帖是公开的，能否请您提交一个支持工单，以便我们可以通过更私密的沟通渠道继续调查并安全地查看您的原理图？这将有助于进一步分析问题，并排除任何潜在的硬件连接问题。 提交工单时，请随时引用此帖并提及我的名字，以便我继续为您提供帮助。 为了便于进行初步审核，请提供完整的电路板原理图，尤其要注意以下方面： -启动模式引脚和启动配置引脚。 -外部闪存连接。 -核心和调试接口连接。 -电源电路。 -时钟连接。 -使用示波器捕获上电序列以及上电期间启动模式引脚和启动配置引脚的状态。 BR 哈比卜 Re: i.MX RT1011 Flashing Issue 嗨，哈比卜 谢谢你的回复 我们发现了一个错误：启动选项配置不正确，QSPI 无法正常工作。我们已解决此问题。 此致 大君M

About the Finite-State Machine (FSM) of i.MX8Mplus We use Toradex's Veridin i.MX8Mplus at our company. At that time, the SOM_PW_ON signal is input to control the SoM's power supply. (Directly connected to the ON/OFF signal of the i.mx8MPlusSoC). *Please refer to the waveform on the attached oscilloscope.   Due to the circuit configuration on the SoM side, the voltage should be High (1.8V), but for about 800 msec after startup, it remains at an intermediate potential of approximately 0.3-0.4V. I'd like to know how this voltage (0.3 to 0.4V) is handled as an ON/OFF signal on the SoC side. This information was not included in the datasheet or reference manual. I think that in cases of very short ON/OFF operations (<5s), the system may proceed to shutdown. Would the operation detection criteria be the transition from High to Low edge state and the duration of the Low state? I would also like to know the exact minimum/maximum times for those times. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MplusのFinite-State Machine (FSM)について For i.MX8M Plus, ONOFF is handled as a level-held button input with configurable 0/50/100/500 ms qualification and 5/10/15 s forced-off timing, and your observed 0.3–0.4 V on a 1.8 V ONOFF net is most consistently interpreted as logic Low by the available input-threshold documentation. Re: i.MX8MplusのFinite-State Machine (FSM)について Thank you for your reply. The observed V values of 0.3–0.41.8V on the ONOFF network are most consistently interpreted as logically low by the available input threshold documentation. By the way, could you also tell me about the voltage threshold that is interpreted as logically low? Furthermore, if interpreted as logically low, the ON/OFF state will remain logically low for approximately 800 msec after startup before changing to logically high. In that case, would it be considered that a button input occurred? My concern is whether a button press might cause the system to automatically shut down immediately after startup. Re: i.MX8MplusのFinite-State Machine (FSM)について By the way, could you also tell me about the voltage threshold that is interpreted as logically low? I apologize. I would like to know the voltage threshold at which the logic value is interpreted. Re: i.MX8MplusのFinite-State Machine (FSM)について Thank you for your reply. The observed V values of 0.3–0.41.8V on the ONOFF network are most consistently interpreted as logically low by the available input threshold documentation. By the way, could you also tell me about the voltage threshold that is interpreted as the logical high? Furthermore, if interpreted as logically low, the ON/OFF state will remain logically low for approximately 800 msec after startup before changing to logically high. In that case, would it be considered that a button input occurred? My concern is whether a button press might cause the system to automatically shut down immediately after startup. To the NXP TechSupport representative What do you think about this matter? I have one more question: ON/OFF is processed as a level hold button input, with conditions of 0/50/100/500 ms. Regarding that point, I believe the default is 0. In this case, if the level momentarily exceeds the logical high or logical low threshold due to noise or other factors, will the level be held? I am concerned that with this default setting, if noise is received, there is a possibility of malfunction if something that causes a logic judgment opposite to the currently held level logic is introduced, even for a moment. Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang I have added a few more questions. We apologize for the inconvenience, but please provide your response. Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang How is the confirmation process going? Please provide an answer. Re: i.MX8MplusのFinite-State Machine (FSM)について Sorry to miss your message, I can help checking it and will give you reply next week. Wish you have a nice day

Ubuntu LinuxでのMCUXpresso IDEサポートに一体何が問題なのでしょうか? LinuxのMCUXpresso IDEでHello Worldプログラムを作るような、本当に単純なことなんて一つもありません。私はrt700のevkbボードを使っていますが、そのIDEは何度もクラッシュして切れてしまいます。ここ2〜3日ずっと苦戦しています。一体これは一体何なんだ?ある日は十分なサポートがあるはずですが、ある日は動かないのに。解決策を見つけるためのガイドもありません。基本的なプロジェクトを作成しても、ペリフェラルの設定タブを開くと、なぜか動作せず、奇妙なことにプロセッサコアがこれをサポートしていないとか、そんな感じです。最近はMicrosoft WindowsからこのIDE、そしてある程度はUbuntuまで、スロップか何かしらしかありません。このIDEを動かすには、Windows上でどうすればいいのですか?どうかこの問題を直してください。スクリーンショットも撮れません。あまりにもひどくフリーズします。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux EVKBのBOMファイル自体は、IDEプロジェクト作成で使われるのと同じパッケージを使用しています。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux ぜひこの動画を見て、このツールの使い方についてトレーニング動画も作ってください。VScode拡張機能を使うなんて、どれほどサポートが壊れるのか想像するしかありません。 Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux システムを再起動してIDEを開くとこれが起きています Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux こんにちは、 @prathamvora さん。 MCUXpresso統合開発環境(IDE)のウェブページによると、サポートされているUbuntuバージョンはUbuntu 22.04 LTSとUbuntu 24.04 LTSです。Visual Studio Code版MCUXpressoの場合、サポートされているUbuntuバージョンはUbuntu 20.04.2 LTS、Ubuntu 22.04 LTS、Ubuntu 24.04 LTSです。 MCUXpresso IDEにはサポートされているUbuntuバージョン、Visual Studio CodeにはMCUXpressoを使うことをおすすめします。 よろしくお願いします、 パブロ

RT1176 - BT_FUSE_SEL のプログラミング後に JTAG 経由で SPI NOR フラッシュの読み出しに問題が発生する こんにちは、 RT1176 CPU上で署名および暗号化処理のテストを行っています。 基本的なシステム構成は、UART/JTAG <-> RT1176 <-> SPI Nor Flashです テストに使用するソフトウェアは以下の通りです: - RT1176テストファームウェア（起動後にLEDを点灯させるだけのシンプルなファームウェア） - NXP MCUXpresso セキュアプロビジョニング / blhost (UART を介した署名および暗号化用) - Segger JFlash(JTAG経由でFlashアクセス用) これまでに以下のテストを実施しました: 1) CPUがアンロックされ、署名がオフになっている間、ファームウェア(署名なし/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 2) CPUがアンロックされて署名が有効な間、ファームウェア(署名済み/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 3) CPUがロックされて署名がオンになっている間、ファームウェア(署名済み/暗号化済み)が起動せず、JTAG経由でフラッシュへのアクセスが不安定になります。 つまり、暗号化の問題があるということです。しかし、大きな暗号化問題を検証する前に、ステップ3の不安定なフラッシュ挙動を理解したいと思います。 いくつかのテストで、フラッシュ問題はBT_FUSE_SELが吹き抜けた直後に必ず発生することが明らかになりました(BT_FUSE_SEL無傷時はJTAG経由のフルフラッシュアクセスBT_FUSE_SEL、吹き飛ばすとJTAG経由の不安定なフラッシュアクセス)。現在テスト中のため、ヒューズ設定によるJTAGの無効化は行っていません。 では、質問はこうです: なぜBT_FUSE_SELがフラッシュへのアクセスを失わせるのでしょうか?（CPUがロックされているときに、何らかの読み出し保護機能が有効になっているのでしょうか？）segger jflashツールは、CPUがロックされている場合に問題が発生するのでしょうか？ こちらもご覧ください： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/mp/2044051 -同じ問題>:BT_FUSE_SEL >フラッシュアクセスできません よろしくお願いします。 よろしくお願いします、 フロリアン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @florian_arndt さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ BT_FUSE_SELは、SPI NOR読み出し保護を直接有効にしたり、JTAGを無効にしたりするものではありません。その機能は、ブートROMにBOOT_CFGピンではなく、eFuseに保存されているブート構成を使用させることです。 OTFAD/encrypted-XIP構成がeFuseにもプログラムされている場合、BT_FUSE_SELを書き込むことで、その構成が起動のたびに有効になり、BOOT_CFGピンを介してそれをバイパスする可能性がなくなります。誤ったOTFADコンテキスト、キー、アドレス範囲、または暗号化されたイメージは、アプリケーション開始前にブートROMが失敗する原因となることがあります。 したがって、現時点で最も可能性の高い原因は、ブートに関連するGPIOがバイパスされているものの、対応するeFuseが正しく設定されていないことだと考えられます。BT_FUSE_SEL自体はJTAG接続に影響を与えません。問題点を迅速に特定するために、A/Bテストを実施することをお勧めします。 よろしくお願いします、 ギャビン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @Gavin_Jia さん、 ご回答ありがとうございます！ 本日、暗号化処理に関する不具合（ファームウェアのバグ）を修正しました。当社のファームウェアは、CPU内で署名/暗号化が有効になった状態で起動するようになりました。 つまり、大きな問題は解決しました。 残っているのは、BT_FUSE_SELを設定した後のJTAG経由のSPIフラッシュ読み出しの問題です。 添付ファイルにヒューズマップがあります。 問題の原因になりそうなものは見えますか? 前もって感謝します。 フロリアン

FRDM中的ISP调谐 我目前正在 Verdin iMX95 FRDM 套件中安装拜耳传感器，已经获得了信号流，即将开始 ISP 调优。这里的调音完全不同，与 iMX8M Plus 有很大的不同。有人用Verdin iMX95套件进行过调校吗？

what the hell is wrong with MCUXpresso IDE support on ubuntu linux not a single bloody simplest of the simplest thing like creating a hello world program in the MCUXpresso IDE on Linux. I have a rt700 evkb board and that ide just keep crashing and hanging up i am struggling with it for the past 2-3 days just what in the world is this BS. it is obviously expected to have a decent enough support one day it works and then the other day it does not. there is also no guide to have some fix. even after creating some basic project when opening the peripheral configuration tab it magically just does not work it weirdly just say the processor core whatever does not support this or something like that. these days all we have is slop or what from Microsoft windows to even this IDE and then to some degree ubuntu as well.  to run this ide what is do you expect us to do to run it on windows? please for love of everything please fix this issues and i can't even take a screenshot it hangs up that bad.   Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux The BOM file for the EVKB itself uses the same package as being used in ide project creation.  Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux please have  a look at this video and please make some training videos on how to even use this tool. let alone use the vscode extension i can only imagine what kind of broken support it is going to be. Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux this is what i get after rebooting my system and opening the IDE Re: what the hell is wrong with MCUXpresso IDE support on ubuntu linux Hi @prathamvora, According to the MCUXpresso Integrated Development Environment (IDE) webpage, the supported Ubuntu versions are Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. In the case of MCUXpresso for Visual Studio Code, the supported Ubuntu versions are Ubuntu 20.04.2 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. I would recommend using one of the supported Ubuntu versions for MCUXpresso IDE or MCUXpresso for Visual Studio Code. Best Regards, Pablo

RTC 示例程序在 frdm_mcxw72 开发板上无法成功编译。 您好， 我的工作台无法成功编译 RTC 示例。您可以在下面的截图中找到基本设置信息。 以下是构建过程中的日志信息： 配置任务已启动... 工作区位于 d:\ABC\rtc 正在加载 Zephyr 默认模块（Zephyr 基础模块（已缓存））。 -- 应用程序：D:/ABC/rtc -- CMake 版本：3.30.0 -- 找到 Python3：C:/Users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe（找到合适的版本“3.12.12”，最低要求版本为“3.12”）找到的元器件：解释器 缓存文件将写入：D:/ABC/zephyr/zephyr/.cache -- Zephyr 版本：4.4.1 (D:/ABC/zephyr/zephyr) -- 已找到西部（找到合适的版本“1.5.0”，最低要求为“0.14.0”） -- 板：frdm_mcxw72，资格赛选手：mcxw727c -- 找到主机工具：zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 找到工具链：zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 找到 Dtc：C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe（找到合适的版本“1.6.1”）最低要求为“1.4.6”） -- 找到 BOARD.dts 文件：D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- 找到设备树覆盖文件：D:/ABC/rtc/boards/frdm_mcxw72.overlay -- 生成的 zephyr.dts 文件：D:/ABC/rtc/build/zephyr/zephyr.dts -- 生成的 pickle 格式 edt 文件：D:/ABC/rtc/build/zephyr/edt.pickle -- 生成的 devicetree_generated.h：D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h 正在解析 D:/ABC/zephyr/zephyr/Kconfig 已加载配置“D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig” 合并配置“D:/ABC/rtc/prj.conf” 配置已保存到“D:/ABC/rtc/build/zephyr/.config” Kconfig 头文件已保存到 'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h' -- 找到 GnuLd：C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe（找到版本“2.43.1”） -- C 编译器标识为 GNU 14.3.0 -- CXX 编译器标识为 GNU 14.3.0 -- 汇编编译器标识为 GNU -- 找到汇编程序：C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe -- 在 D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ 中查找设备 MCXW727C -- 找到设备文件夹：D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- 找到 gen_kobject_list：D:/ABC/zephyr/zephyr/scripts/build/gen_kobject_list.py 配置完成（耗时26.9秒） 生成完成（耗时 1.8 秒） 版本文件已写入：D:/ABC/rtc/build 配置完成，返回代码为 0 * 终端将被任务重复使用，按任意键即可关闭。 * 正在执行任务：CMake：版本 工作区位于 d:\ABC\rtc 构建任务已启动…… C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] 正在生成 include/generated/zephyr/version.h -- Zephyr 版本：4.4.1 (D:/ABC/zephyr/zephyr)，构建版本：v4.4.1 [2/156] 正在生成 misc/generated/syscalls.json 和 misc/generated/struct_tags.json [3/156] 正在生成 include/generated/device-api-sections.ld 和 include/generated/device-api-sections.cmake [4/156] 正在生成 include/generated/zephyr/driver-validation.h [5/156] 正在生成 include/generated/zephyr/kobj-types-enum.h 和 include/generated/zephyr/otype-to-str.hinclude/generated/zephyr/otype-to-size.h [6/156] 正在生成 include/generated/zephyr/syscall_dispatch.c、include/generated/zephyr/syscall_exports_llext.c，syscall_weakdefs_llext.c，包含/generated/zephyr/syscall_list.h [7/156] 正在构建 C 对象 zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] 正在生成 ../../include/generated/zephyr/heap_constants.h [9/156] 正在构建 C 对象 zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] 正在生成 include/generated/zephyr/offsets.h [11/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] 正在构建 C 对象 CMakeFiles/app.dir/src/main.c.obj [13/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] 正在构建 ASM 对象 zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init.S.obj [32/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] 正在构建 C 对象 zephyr/CMakeFiles/zephyr.dir/subsys/tracing/tracing_none.c.obj [39/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] 正在构建汇编对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/nmi_on_reset.S.obj [41/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] 构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fault_s.S.obj [43/156] 构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/fatal.c.obj [44/156] 正在生成 linker_zephyr_pre0.cmd [45/156] 构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/nmi.c.obj [46/156] 正在构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/reset.S.obj [47/156] 正在构建 C 对象 zephyr/arch/arch/arm/core/CMakeFiles/arch __arm__ core.dir/tls.c.obj [48/156] 构建 ASM 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/vector_table.S.obj [49/156] 构建 C 对象 zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fpu.c.obj [50/156] 链接 C 静态库 zephyr\arch\common\libisr_tables.a [51/156] 正在构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/svc.S.obj [52/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/scb.c.obj [53/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/fault.c.obj [54/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/prep_c.c.obj [55/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/irq_manage.c.obj [56/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/thread.c.obj [57/156] 正在构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/swap_helper.S.obj [58/156] 构建 ASM 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/__aeabi_read_tp.S.obj [59/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/cpu_idle.c.obj [60/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/exc_exit.c.obj [61/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/irq_init.c.obj [62/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/thread_abort.c.obj [63/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/CMakeFiles/arch __arm__ core__cortex_m.dir/isr_wrapper.c.obj [64/156] 正在构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_core_mpu.c.obj [65/156] 构建 C 对象 zephyr/arch/arch/Arm/core/cortex_m/cmse/CMakeFiles/arch __arm__ core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] 正在构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_mpu_regions.c.obj [67/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/assert.c.obj [68/156] 构建 C 对象 zephyr/arch/arch/Arm/core/mpu/CMakeFiles/arch __arm__ core__mpu.dir/arm_mpu.c.obj [69/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/cbprintf.c.obj [70/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/chk_fail.c.obj [71/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/errno_wrap.c.obj [72/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/exit.c.obj [73/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/time/time.c.obj [74/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/locks.c.obj [75/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/fnmatch.c.obj [76/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/stdlib/abort.c.obj [77/156] 正在构建 C 对象 zephyr/lib/libc/picolibc/CMakeFiles/lib __libc__ picolibc.dir/stdio.c.obj [78/156] 正在构建 C 对象 zephyr/lib/libc/common/CMakeFiles/lib __libc__ common.dir/source/stdlib/malloc.c.obj [79/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/getentropy.c.obj [80/156] 正在构建 C 对象 zephyr/lib/posix/c_lib_ext/CMakeFiles/lib __posix__ c_lib_ext.dir/getopt_shim.c.obj [81/156] 正在构建 C 对象 zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] 正在构建 C 对象 zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] 构建 C 对象 zephyr/drivers/pinctrl/CMakeFiles/drivers __pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__ gpio.dir/gpio_mcux.c.obj [85/156] 正在构建 C 对象 zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] 正在构建 C 对象 zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] 正在构建 C 对象 zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] 正在构建 C 对象模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] 正在构建 C 对象 zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_Arm.c.obj [91/156] 正在构建 C 对象 zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] 正在构建 C 设备 zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] 正在构建 C 设备 zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] 链接 C 静态库 app\libapp.a [133/156] 链接 C 静态库 zephyr\libzephyr.a [134/156] 链接 C 静态库 zephyr\arch\common\libarch __common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__ arm__core.a [136/156] 链接 C 静态库 zephyr\arch\arch\arm\core\cortex_m\cmse\libarch __arm__ core__cortex_m __cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ arm __core__ mpu.a [138/156] 链接 C 静态库 zephyr\arch\arch\arm\core\cortex_m\libarch __arm__ core__cortex_m.a [139/156] 链接 C 静态库 zephyr\lib\libc\common\liblib __libc__ common.a [140/156] 链接 C 静态库 zephyr\lib\posix\c_lib_ext\liblib __posix__ c_lib_ext.a [141/156] 链接 C 静态库 zephyr\drivers\clock_control\libdrivers__clock_control.a [142/156] 链接 C 静态库 zephyr\lib\libc\picolibc\liblib __libc__ picolibc.a [143/156] 链接 C 静态库 zephyr\drivers\console\libdrivers __console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__ gpio.a [145/156] 链接 C 静态库 zephyr\drivers\pinctrl\libdrivers __pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__ serial.a [147/156] 链接 C 静态库 zephyr\drivers\rtc\libdrivers __rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__ timer.a [149/156] 链接 C 静态库 modules\hal_nxp\libmodules__hal_nxp.a [150/156] 链接 C 静态库 zephyr\kernel\libkernel.a [151/156] 链接 C 可执行文件 zephyr\zephyr_pre0.elf 失败：zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd .&& C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.azephyr/libzephyr.azephyr/arch/common/libarch __common.a zephyr/arch/arch/arm/core/libarch__ arm__core.azephyr/arch/arch/arm/core/cortex_m/libarch __arm__ core__cortex_m.azephyr/arch/arch/arm/core/cortex_m/cmse/libarch __arm__ core__cortex_m __cmse.a zephyr/arch/arch/arm/core/mpu/libarch__ arm __core__ mpu.azephyr/lib/libc/picolibc/liblib __libc__ picolibc.azephyr/lib/libc/common/liblib __libc__ common.azephyr/lib/posix/c_lib_ext/liblib __posix__ c_lib_ext.azephyr/drivers/clock_control/libdrivers__clock_control.azephyr/drivers/console/libdrivers __console.a zephyr/drivers/gpio/libdrivers__ gpio.azephyr/drivers/pinctrl/libdrivers __pinctrl.a zephyr/drivers/rtc/libdrivers__ rtc.azephyr/drivers/serial/libdrivers __serial.a zephyr/drivers/timer/libdrivers__ timer.amodules/hal_nxp/libmodules__hal_nxp.a-Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a-fuse-ld=bfd -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space"-lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /DD:\ABC\rtc\build\zephyr && C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe:app/libapp.a(main.c.obj): 在函数 `k_sleep` 中： D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94):未定义对“__device_dts_ord_92”的引用 collect2.exe：错误：ld 返回 1 退出状态 ninja：版本停止：子命令失败。 构建完成，但出现错误。 * 终端进程终止，退出代码为：1。 * 终端将被任务重复使用，按任意键即可关闭。 非常感谢您帮忙检查这个问题。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 示例： zephyr/samples/drivers/counter/alarm运行良好，但即使我创建的 overlay 文件与快照中的相同， RTC 示例在构建过程中仍然存在问题。 以下是构建过程中出现的关键错误信息，它应该能帮助您解决问题。非常感谢！ [5/64] 正在构建 C 对象 zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj 失败：zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS __ -D__ PROGRAM_START -D__ZEPHYR_SUPERVISOR __ -D__ ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/.-ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/.-ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers -isystem D:/ABC/zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -MF zephyr\drivers\rtc\CMakeFiles\drivers__rtc.dir\rtc_counter.c.obj.d-o zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -c D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c 从 D:/ABC/zephyr/zephyr/include/zephyr/toolchain.h:52 包含的文件， 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel_includes.h:23， 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel.h:17， 来自 D:/ABC/zephyr/zephyr/include/zephyr/drivers/rtc.h:26， 来自 D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36:错误：静态断言失败：“RTC 初始化优先级必须大于计数器” 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: 注意：在宏“BUILD_ASSERT”的展开中 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] 正在构建 C 目标模块 modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ，希望你一切都好。 当前MCXW72的RTC驱动程序实现旨在与counter.h配合使用。Zephyr库。考虑到这一点，我建议使用以下示例测试 RTC 功能： zephyr/samples/drivers/counter/alarm 。如下图所示： 该项目模板将把 RTC 配置为具有报警功能的计数器。为了进行测试，请在/boards文件夹中创建一个名为 [frdm_mcxw72.overlay] 的覆盖文件。并将以下内容添加到文件中： / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; 请告诉我这些修改是否对您的开发有所帮助。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ， 要使 RTC 示例正确构建，您必须将以下设置添加到prj.conf文件中： CONFIG_RTC_INIT_PRIORITY=70 请告诉我这是否对您有效。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好@anliu114036 ， 请将该设置添加到名为prj.conf的文件中。因为将其添加到名为frdm_mcxw72.conf的创建文件中，Zephyr 版本系统不会像处理 overlay 文件那样自动获取它。 请告诉我这是否有帮助。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 我已经添加了包含该设置的 prj.conf 文件。 CONFIG_RTC_INIT_PRIORITY=70 但它仍然无法通过构建，错误提示信息也相同，您可以在附件中找到完整的构建日志。希望这能有助于找到问题所在。 顺祝商祺！ Re: RTC example can't build successfully in frdm_mcxw72 board 嗨@anliu114036 ，很高兴得知你已经成功构建了示例。 关于实时时钟 (RTC) 功能，目前 Zephyr 的 RTC 驱动程序 (rtc.h) 与我们用于 MCXW72 RTC 节点的底层驱动程序 (counter_mcux_rtc.c) 不兼容，因此 W72 的 RTC 应通过counter.h来使用。由于 API 与底层驱动程序中定义的 API 兼容，因此该驱动程序是可行的。 我之前分享的闹钟示例（zephyr/samples/drivers/counter/alarm）演示了我们 RTC 驱动程序的全部当前功能。 请告诉我这些信息是否解答了您的疑问。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR， 在 prj.conf 文件中添加设置后，问题解决了，谢谢你的帮助！ 但是仍然存在一个问题，就是当我把镜像刷入EVK后，RTC功能似乎仍然无法正常工作，因为打印出来的时间信息没有变化。 能否帮忙查一下？非常感谢！

MPC5746C FXOSC 输出频率 部件： MPC5746C（电源架构 Z4，SDK：NXP MPC57xx 平台 SDK）。 MPC5746C 的手册中指出，FXOSC 提供 8 -40 MHz 的输出频率。请帮我查找FXOSC在以下配置下的输出频率？ 1. FXOSC_CTL：OSCBYP = 0 且 OSCM = LCP 2. FXOSC_CTL：OSCBYP = 0 且 OSCM = FSP 3. FXOSC_CTL：OSCBYP = 1 且 OSCM = LCP 4. FXOSC_CTL：OSCBYP = 1 且 OSCM = FSP 请考虑为其他注册字段设置默认值。谢谢。 Re: MPC5746C FXOSC output frequency 感谢你的回复@petervlna 。 如何找到晶体/谐振器（OSCBYP = 0）和外部时钟（OSCBYP = 1）提供的频率？ Re: MPC5746C FXOSC output frequency 你好， FXOSC 模块不会根据 OSCBYP 和 OSCM 设置生成特定频率。FXOSC 的输出频率始终等于连接到 FXOSC 的外部源的频率（当 OSCBYP=0 时为晶体/谐振器，当 OSCBYP=1 时为外部时钟），在支持的 8–40 MHz 范围内。 因此，对于列出的所有四种配置，FXOSC 输出频率就是外部输入频率。OSCM 设置（LCP/FSP）会影响振荡器的工作模式，但不会改变时钟频率。 顺祝商祺！ Peter Re: MPC5746C FXOSC output frequency @petervlna请您协助解答我上面提到的关于 FXOSC 的问题。 Re: MPC5746C FXOSC output frequency 如何找到晶体/谐振器（OSCBYP = 0）和外部时钟（OSCBYP = 1）提供的频率？ @petervlna ，请告诉我以上问题的答案。我想使用 FXOSC 作为定时器的时钟源。根据它提供的频率，我可以将计数值加载到定时器寄存器中。

小程序 您好，请问。请问有人能帮帮我吗？ 1.在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？ 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？ B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者 EMVCo 认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要单独的安全元件？ 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的 EMVCo 认证失效？ C. 自定义小程序可使用单调计数器和加密功能 (SE051P) 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？ 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。） 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐特定的去耦电容或缓冲器来处理加密操作期间的 16.5 mA 峰值电流？ 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作是可能的，那么在仅使用场功率的情况下，ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？ 虚拟测试 Re: Applet 嗨@aaschi ， 感谢您的联系！我的评论如下： 1. 在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？// 我们提供有关这些主题的文档，请通过安全文件通道索取。更多详情请参考以下内容。 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？是的，需要签署保密协议，并且需要达到最低订购量。请联系您当地的恩智浦代表了解更多详情。 B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者，EMVCo认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要一个单独的安全元件？不，您必须使用两个安全元件——一个经过认证的支付 SE 和一个用于专有逻辑的 SE051P/自定义 SE。 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的EMVCo认证失效？//不，这不可能。 C. 自定义小程序 (SE051P) 可使用单调计数器和加密 // SE05x IoT 小程序文档支持单调计数器安全对象，因此从硬件角度来看，SE051P 也应该支持，但这取决于您的自定义小程序实现。 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？// 您无法在 SE051P 上安装 SE05x 预装的 IoT 小程序，您必须开发自己的自定义小程序。 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ SE05x IoT 小程序支持多种算法和曲线，因此 SE051P 也可能支持，但这取决于您的自定义小程序实现。 D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。）//ECDSAP-256 验证记录为 <55 毫秒；未找到签名计时。主动式非对称加密电流高达 16.5 mA。这些信息来自SE05x IoT 小程序，对于自定义小程序，则取决于您自己的实现。 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐使用特定的去耦电容或缓冲器来处理加密操作期间 16.5 mA 的峰值电流？//否确定了 CR2032 缓冲电容的具体值；设计峰值电流约为 16.5 mA，加上工作时间和电池 ESR。 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作可行，那么在仅使用场强的情况下，诸如 ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？//射频供电支持 SE051 操作，但必须确认和测试对自定义小程序加密/NVM 更新的 RF 专用支持。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Applet 嗨，Kan， 感谢您的详细解答，非常有帮助。我会将此帖子标记为正确答案。 关于问题 1：我想通过安全文件通道请求您提到的文档（SE051P 的自定义 Java Card 小程序开发路径 — SDK、工具、Java Card / GlobalPlatform 版本和小程序配置）。 请问您能告诉我具体的操作步骤吗？具体来说： 1.我该如何访问安全文件通道？我应该在与此社区帐户关联的 NXP 支持门户上开一个私人支持案例，还是有其他途径？ 2. 在签署保密协议之前，哪些文件可以获取？哪些文件需要通过您在问题 2 中提到的保密协议/当地代表途径获取？ 我现阶段的目标是审查开发路径文档，以规划原型阶段；之后将与当地代表讨论保密协议/最低订购量。 再次感谢， 阿斯基

edge ai Suggest the EDGE AI app with imx93

S32 Design Studio MCP統合の使い方 S32 Design Studio MCP連携の使い方、関連する資料やドキュメントはありますか?

i.mx8M plus 序列号下载失败 尊敬的恩智浦： 我按照附图所示的电路图将电路板连接到 i.MX8M plus 板，并执行了串行下载，但如捕获的图像所示，屏幕只显示出来，下载过程没有继续进行。 我想咨询一下如何解决这个问题。 谢谢！ 顺祝商祺！ 全仁浩 Re: i.mx8M plus Serial download failure 亲爱的王一平： NXP EVK (8MPLUS-BB) 工作正常，但我设计的电路板（附图）运行一段时间后，如屏幕截图所示，就会停止工作。请核对附件中的电路图，确保其设计正确。 谢谢！ 顺祝商祺！ 全仁浩 Re: i.mx8M plus Serial download failure 请从https://github.com/nxp-imx/mfgtools/releases下载最新版本的 UUU 然后使用以下命令对图像进行编程。 unzstd - .rootfs.wic.zst uuu -b emmc_all - .rootfs.wic 如果仍然失败，请尝试以下命令。 uuu.exe -b emmc imx-boot-imx8mpevk-sd.bin-flash_evk Re: i.mx8M plus Serial download failure 原理图看起来和NXP EVK底板一样。唯一的区别是 JTAG_MOD 被拉高了。请移除 R216 再试一次。    

MPC5746C 在 115°C 环境温度下死机（无法启动，UART 无输出） 部件号： MPC5746C（电源架构 Z4，SDK：NXP MPC57xx 平台 SDK） 在 115°C 环境温度下进行热室测试时，我们基于 MPC5746C 的板在启动时完全无响应——没有任何 UART 控制台输出，并且在该温度下每次启动尝试都会发生这种情况。冷却后该部件似乎完全恢复：在室温下重新刷写/重启即可恢复正常运行，且不会造成永久性损坏。 有趣的是，即使电路板温度高达 115°C，我们仍然可以通过 PEMicro JTAG 调试探针成功地对闪存进行重新编程——我们通过在高温下刷入版本字符串递增的构建版本，并在冷却后读取新版本，证实了这一点。因此，调试探测闪存路径在 115°C 下工作；只有应用程序启动路径挂起/处于错误状态。 手册上说MCU可以承受高达125°C的温度。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ Re: MPC5746C hangs (no boot, no UART) at 115°C ambient 你好， 手册上说MCU可以承受高达125°C的温度。 是的，这不是问题。 请问您能否帮我们找出问题的根本原因以及如何解决这个问题？ 由于这是你的定制板，而且问题在冷却后消失，我怀疑： 1. 时钟启动问题（可能性最高） 在 115°C 时： 外部晶体（FXOSC）启动时间增加。 振荡器增益裕度降低。 负载电容的电容值会随温度变化。 PCB漏电加剧。 调试器仍然可以访问该部分，因为调试逻辑使用自己的基础架构，并不依赖于应用程序是否执行到 main() 函数。 FXOSC 状态位 CMU时钟监测故障 仅 FIRC 启动实验 完全通过 FIRC 运行，并暂时禁用外部晶振。 JTAG编程在115°C下仍能正常工作，这有力地表明核心基础设施仍然运行正常，故障发生在应用程序启动路径的早期阶段，而不是闪存阵列本身。 顺祝商祺！ Peter Re: MPC5746C hangs (no boot, no UART) at 115°C ambient 感谢@petervlna的真知灼见。 随后，我和我的同事@mnargund进行了进一步调查，我们成功地让 MPC5746C 在 115°C 下启动。以下是我们发现的结果总结。 根本原因：在预初始化期间，我们配置系统启动 FIRC、FXOSC 和 PLL，然后将系统时钟从 FIRC 切换到 PLL。随后，我们触发了向 DRUN 模式的模式转换（尽管系统默认已处于 DRUN 模式，但如手册中所述，需要转换到相同模式才能使新配置生效），并轮询 MC_ME_GS.MTRANS 以等待转换完成。 然而，即使在 MC_ME_GS.MTRANS 清除之后，代码仍然出现 IVOR1 异常，这可能表明在执行继续进行时，转换尚未完全稳定。在高温（115°C）下，转变似乎比在室温下需要更长时间，导致系统在执行下一条指令时处于不一致的状态。 已采取的变通方法：我们在 MC_ME_GS.MTRANS 轮询之后、在继续执行其余初始化操作之前插入了一个显式的软件延迟。延迟 500 毫秒，在 115°C 下启动始终成功。我们还测试了 100 毫秒的延迟，在我们的设置中也能可靠地工作。 在初始化过程中，是否存在一个可以安全插入的最大推荐软件延迟？ 在高达 125°C 的整个工作温度范围内，是否有推荐的做法来确保时钟稳定可靠？

边缘人工智能 建议使用 imx93 的 EDGE AI 应用

I need to configure DMA for SPI I am using S32DS IDE and RTD 3.0 can anyone tell me how to start the DMA with SPI with step by step instructions or any other example code if available Re: I need to configure DMA for SPI Thank you for your response Do this work for s32k322 MCU Re: I need to configure DMA for SPI Hi @ershi  Included with the RTDs are provided two example codes for SPI communication using DMA, one using Low-Level Drivers (Ip) and one using High-Level Drivers (MCAL). You can refer to the thread HOWTO: S32 Design Studio - Create a New S32DS Project from Example for guidance on how to import the examples. Also, you can refer to the example provided in the thread Example S32K31 SPI Multiple Packet Transmit & Receive: Solution for DMA Cache Issue. BR, VaneB Re: I need to configure DMA for SPI Hi @ershi  Although the examples are not specifically designed for the S32K322, the functionality is generally the same across the S32K3 family, unless otherwise stated in the Reference Manual Therefore, you can use this project as a reference for your implementation and adapt it as needed for your specific device. Re: I need to configure DMA for SPI I had configurated everything but still it is not working initially it is return as LPSPI_IP_STATUS_SUCCESS  for (Lpspi_Ip_AsyncTransmit )and second time it is showing failed LPSPI_IP_STATUS_FAIL  I can able to send the data through spi using this api without the dma Lpspi_Ip_SyncTransmit() I have attached few configuration screenshot  Re: I need to configure DMA for SPI Hi @ershi  Could you also share images of the RM and IntCtrl_Ip driver configurations? Re: I need to configure DMA for SPI Hi @VaneB  I've attached the screenshots for the RM and IntCtrl_IP driver configurations, along with a short video clip for your detailed reference. I noticed one difference in the LPSPI configuration page. In the SPI General tab, under Spi_Phy_TxDmaChannel, the naming is different between the TX and RX configurations. Please let me know if you need any additional details InterruptsInterruptsInterrupts RMRMRM Re: I need to configure DMA for SPI Hi @ershi  Thank you for sharing all the information. I just have one observation. In the Dma_Ip driver configuration, you have defined DMA_SPI_CALLBACK_0 as the Interrupt Callback. However, the LPSPI DMA callbacks are already provided by the driver and can be found in the Lpspi_Ip_Irq.c file. For LPSPI2, the configured callbacks should be: Lpspi_Ip_LPSPI_2_IrqTxDmaHandler for the TX DMA channel Lpspi_Ip_LPSPI_2_IrqRxDmaHandler for the RX DMA channel

S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hi, I recently bought an S32K148EVB-Q176 board. According to the documentation and schematics, I expected it to come with a UJA1132, but the board I received has a UJA1131. Because of this, I only have one LIN interface, while I was expecting the features of the UJA1132. I just wanted to ask if this is normal. Are there different versions of the S32K148EVB-Q176 with different SBCs, or did I receive the wrong board? Thank you! Re: S32K148EVB-Q176 received with UJA1131 instead of UJA1132 Hello @sousou54, Thank you for the report. This issue is currently under investigation. Could you please provide a photo of the large white label located on the product box? The information on this label can help us identify the manufacturing details of the board. Since the label may contain product-specific information, you can share the photo through a private message or by opening a support case (Support) rather than posting it publicly. Best regards, Julián

MPC5746C FXOSC output frequency Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK). In the manual of MPC5746C, it is stated that FXOSC provides 8 -40 MHz output frequency. Please help me in finding the output frequency provided by FXOSC for the following configurations? 1. FXOSC_CTL: OSCBYP = 0 and OSCM = LCP 2. FXOSC_CTL: OSCBYP = 0 and OSCM = FSP 3. FXOSC_CTL: OSCBYP = 1 and OSCM = LCP 4. FXOSC_CTL: OSCBYP = 1 and OSCM = FSP Please consider default values for the other register fields. Thanks. Re: MPC5746C FXOSC output frequency Thanks for your response @petervlna.  How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Re: MPC5746C FXOSC output frequency Hello, The FXOSC module does not generate a specific frequency based on the OSCBYP and OSCM settings. The FXOSC output frequency is always equal to the frequency of the external source connected to FXOSC (crystal/resonator when OSCBYP=0, or external clock when OSCBYP=1), within the supported range of 8–40 MHz. Therefore, for all four configurations listed, the FXOSC output frequency is simply the external input frequency. The OSCM setting (LCP/FSP) affects the oscillator operating mode, but does not change the clock frequency. Best regards, Peter Re: MPC5746C FXOSC output frequency @petervlna please provide your support for my FXOSC query mentioned above.  Re: MPC5746C FXOSC output frequency How can we find the frequency provided by the crystal/resonator(OSCBYP = 0) and external clock(OSCBYP = 1)? Please let me know on the above question @petervlna. I want to use FXOSC as clock source for a timer. Based on the frequency it provides i can load a count value into the timer register

NXPカップ2026のNXPコミュニティ参加に関する質問 私は2026年のNXPカップに参加しています。コミュニティやグループの一部としてリアルタイムで情報やリソースの情報を伝えるメールは送っていますが、郵送中のグループリンクにはアクセスできません。それが私が直面している問題であり、その解決策を求めています。

FRDMにおけるISPチューニング 現在、Verdin iMX95 FRDMキットでBayerセンサーを導入していて、Streamを手に入れてISPのチューニングを始めようとしています。ここでのチューニングは全く異なり、iMX8M Plusとは大きな違いがあります。Verdin iMX95キットを使ってチューニングを行った方はいますか？