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 作为定时器的时钟源。根据它提供的频率，我可以将计数值加载到定时器寄存器中。 Re: MPC5746C FXOSC output frequency 你好， MPC5746C 不提供从 FXOSC 寄存器测量或确定 FXOSC 频率的方法。频率必须从硬件设计中得知： OSCBYP = 0：FXOSC 频率等于安装在板上的外部晶体/谐振器的频率。 OSCBYP = 1：FXOSC 频率等于施加到 FXOSC 输入引脚的外部时钟信号的频率。 要将 FXOSC 用作定时器时钟源，应用程序在计算定时器计数值时必须使用电路板原理图或时钟设计中指定的频率（例如，8 MHz、16 MHz、40 MHz 等）。OSCBYP 和 OSCM 设置不会影响频率本身。 顺祝商祺！ Peter

Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installer "lsdk2606" version Hello, I installed the Debian image using flex-installer version "lsdk2606" using Spoiler (Highlight to read) sudo flex-installer -i auto -d /dev/sdX -m imx95-15x15-frdm sudo flex-installer -i auto -d /dev/sdX -m imx95-15x15-frdm on my imx95-15x15-frdm Then, I followed the standard procedure to continue the installation using  Spoiler (Highlight to read) debian-post-install-pkg debian-post-install-pkg After installing all the packages and rebooting, I encounter this error at startup: Spoiler (Highlight to read) [FAILED] Failed to start weston.service - W…nd compositor, as a system service. [FAILED] Failed to start weston.service - W…nd compositor, as a system service. Spoiler (Highlight to read) root@imx95-15x15-frdm:~# systemctl status weston.service × weston.service - Weston, a Wayland compositor, as a system service      Loaded: loaded (/usr/lib/systemd/system/weston.service; enabled; preset: enabled)      Active: failed (Result: exit-code) since Mon 2026-07-20 13:51:20 UTC; 19s ago  Invocation: 67b22b0fa1484ce681d8b2acdc107add TriggeredBy: ● weston.socket        Docs: man:weston(1)              man:weston.ini(5)              http://wayland.freedesktop.org/     Process: 408 ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE)    Main PID: 408 (code=exited, status=1/FAILURE)    Mem peak: 3.5M         CPU: 49ms Jul 20 13:51:19 imx95-15x15-frdm systemd[1]: Starting weston.service - Weston, a Wayland compositor, as a system service... Jul 20 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): session opened for user root(uid=0) by (uid=0) Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: weston.service: Main process exited, code=exited, status=1/FAILURE Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: weston.service: Failed with result 'exit-code'. Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: Failed to start weston.service - Weston, a Wayland compositor, as a system service. root@imx95-15x15-frdm:~# systemctl status weston.service× weston.service - Weston, a Wayland compositor, as a system service     Loaded: loaded (/usr/lib/systemd/system/weston.service; enabled; preset: enabled)     Active: failed (Result: exit-code) since Mon 2026-07-20 13:51:20 UTC; 19s ago Invocation: 67b22b0fa1484ce681d8b2acdc107addTriggeredBy: ● weston.socket       Docs: man:weston(1)             man:weston.ini(5)             http://wayland.freedesktop.org/    Process: 408 ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE)   Main PID: 408 (code=exited, status=1/FAILURE)   Mem peak: 3.5M        CPU: 49ms Jul 20 13:51:19 imx95-15x15-frdm systemd[1]: Starting weston.service - Weston, a Wayland compositor, as a system service...Jul 20 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): session opened for user root(uid=0) by (uid=0)Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: weston.service: Main process exited, code=exited, status=1/FAILUREJul 20 13:51:20 imx95-15x15-frdm systemd[1]: weston.service: Failed with result 'exit-code'.Jul 20 13:51:20 imx95-15x15-frdm systemd[1]: Failed to start weston.service - Weston, a Wayland compositor, as a system service. Spoiler (Highlight to read) root@imx95-15x15-frdm:~# cat /run/user/0/weston.log Date: 2026-07-20 UTC [12:34:22.150] weston 14.0.2 https://wayland.freedesktop.org Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/ Build: LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+ [12:34:22.153] Command line: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so [12:34:22.153] OS: Linux, 6.12.49, #5 SMP PREEMPT Thu May 28 13:07:26 KST 2026, aarch64 [12:34:22.153] Flight recorder: enabled [12:34:22.155] Using config file '/etc/xdg/weston/weston.ini' [12:34:22.156] Output repaint window is 16 ms maximum. [12:34:22.158] Loading module '/usr/lib/libweston-14/drm-backend.so' [12:34:22.162] Failed to load module: libdisplay-info.so.1: cannot open shared object file: No such file or directory [12:34:22.162] fatal: failed to create compositor backend root@imx95-15x15-frdm:~# cat /run/user/0/weston.logDate: 2026-07-20 UTC[12:34:22.150] weston 14.0.2https://wayland.freedesktop.orgBug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/Build: LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+[12:34:22.153] Command line: /usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so[12:34:22.153] OS: Linux, 6.12.49, #5 SMP PREEMPT Thu May 28 13:07:26 KST 2026, aarch64[12:34:22.153] Flight recorder: enabled[12:34:22.155] Using config file '/etc/xdg/weston/weston.ini'[12:34:22.156] Output repaint window is 16 ms maximum.[12:34:22.158] Loading module '/usr/lib/libweston-14/drm-backend.so'[12:34:22.162] Failed to load module: libdisplay-info.so.1: cannot open shared object file: No such file or directory[12:34:22.162] fatal: failed to create compositor backend I'm getting this error too (I don't know if it's related), but nothing is showing up on my screen. Spoiler (Highlight to read) it6263 3-004c: failed to clear DDC FIFO it6263 3-004c: Failed to read EDID it6263 3-004c: failed to clear DDC FIFOit6263 3-004c: Failed to read EDID Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe root@imx95-15x15-frdm:~# ldd /usr/lib/libweston-14/drm-backend.so linux-vdso.so.1 (0x0000ffffac56c000) libweston-14.so.0 => /usr/lib/libweston-14.so.0 (0x0000ffffac410000) libwayland-client.so.0 => /lib/aarch64-linux-gnu/libwayland-client.so.0 (0x0000ffffac3e0000) libpixman-1.so.0 => /lib/aarch64-linux-gnu/libpixman-1.so.0 (0x0000ffffac330000) libwayland-server.so.0 => /lib/aarch64-linux-gnu/libwayland-server.so.0 (0x0000ffffac2f0000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x0000ffffac2b0000) libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000ffffac250000) libdisplay-info.so.1 => not found libgbm.so.1 => /usr/lib/libgbm.so.1 (0x0000ffffac220000) libseat.so.1 => /lib/aarch64-linux-gnu/libseat.so.1 (0x0000ffffac1f0000) libinput.so.10 => /lib/aarch64-linux-gnu/libinput.so.10 (0x0000ffffac170000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffabfb0000) /lib/ld-linux-aarch64.so.1 (0x0000ffffac520000) libxkbcommon.so.0 => /lib/aarch64-linux-gnu/libxkbcommon.so.0 (0x0000ffffabf40000) libffi.so.8 => /lib/aarch64-linux-gnu/libffi.so.8 (0x0000ffffabf10000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffabe60000) libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2 (0x0000ffffabe30000) libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000ffffabd00000) libmtdev.so.1 => /lib/aarch64-linux-gnu/libmtdev.so.1 (0x0000ffffabcd0000) libevdev.so.2 => /lib/aarch64-linux-gnu/libevdev.so.2 (0x0000ffffabc90000) libwacom.so.9 => /lib/aarch64-linux-gnu/libwacom.so.9 (0x0000ffffabc60000) libgudev-1.0.so.0 => /lib/aarch64-linux-gnu/libgudev-1.0.so.0 (0x0000ffffabc30000) libgobject-2.0.so.0 => /lib/aarch64-linux-gnu/libgobject-2.0.so.0 (0x0000ffffabba0000) libglib-2.0.so.0 => /lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000ffffaba10000) libatomic.so.1 => /lib/aarch64-linux-gnu/libatomic.so.1 (0x0000ffffab9e0000) libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffffab920000) Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe Thank you for the update. I can see that libdisplay-info is present on the system, but the Weston log is looking for libdisplay-info.so.1, while the installed library appears to be libdisplay-info.so.2. Could you please run the following command and share the output? ldd /usr/lib/libweston-14/drm-backend.so This will help verify whether there is a library version mismatch or another missing dependency. Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe Could you please run the following command and share the output? find /usr -name "libdisplay-info*" Thanks Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe Hello root@imx95-15x15-frdm:~# find /usr -name "libdisplay-info*" /usr/lib/aarch64-linux-gnu/libdisplay-info.so.2 /usr/lib/aarch64-linux-gnu/libdisplay-info.so.0.2.0 /usr/share/doc/libdisplay-info2

S32K344/358/388 SWO Printf が動作しないのは S32DS3.6 です チームの皆さん、こんにちは。 この手順に従って、PEマルチリンクとS32DS3.6を使用してSWOのprintf関数をテストしました。S32K3の公式EVBを使用し、SWOピンが正常に伸びていることを確認しました。S32K311、312 SWOは正常に動作しますが、S32K344、358、388は印刷できません。ソフトウェアに何らかの隠れた設定があるはずです。テストして試していただけますか？ S32DS3.6.1、3.6.2をテストしました。3.6.3、3.6.5.すべて同じように動作します。311/312は正常に動作しますが、344、358、388は動作しません。 優先度：高 S32DS Re: S32K344/358/388 SWO Printf not work is S32DS3.6 S32K344と312のSWOルーティングに関するRMを確認しました。344はより複雑です。ソフトウェアによって追加のスイッチをオンにする必要があるのかもしれません。 よろしくお願いいたします。 ジェレミー Re: S32K344/358/388 SWO Printf not work is S32DS3.6 こんにちは、ジェレミーさん。 あなたの問題を調べてみます。以前は既知のバグでしたが、現在は修正されていることを願っています。最新のPE Microプラグインを使用していますか？ Re: S32K344/358/388 SWO Printf not work is S32DS3.6 こんにちは、ジリさん。 これは私のPEマイクロプラグインです Re: S32K344/358/388 SWO Printf not work is S32DS3.6 こんにちは、ジェレミーさん。 最新のPE Microプラグイン（v6.1.8）をお試しください。 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 こんにちは、ジリさん。 後で時間ができたら試してみますか？バージョン6.1.8は試してみましたか？ よろしくお願いいたします。 ジェレミー Re: S32K344/358/388 SWO Printf not work is S32DS3.6 こんにちは、Jiriさん。この問題は私の方ではまだ解決していません。そちらでは何か進展はありますか？ よろしくお願いいたします。 ジェレミー

NXP iMX8MP: WFI-based CPU idle in U-Boot never wakes Dear NXP Support Team, We are investigating a low-power waiting mechanism in U-Boot for a i.MX8M Plus based product and have reached a point where we would appreciate guidance from NXP. Software versions SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 Based on the public NXP BSP (Variscite fork contains no relevant modifications in the ATF/GIC code paths) Goal The application needs to remain in U-Boot for several minutes while a deeply discharged battery charges before Android is started. A busy-loop based on mdelay() consumes unnecessary power and generates additional heat, so we are trying to periodically enter a low-power idle state and wake using the ARM Generic Timer (CNTP, PPI 30). Initial implementation configure CNTP timer enable PPI 30 execute a raw wfi() from EL2 The processor never wakes from wfi(). UART output simply stops with no exception or crash. PSCI implementation PSCI_VERSION returns 1.1 PSCI_FEATURES(CPU_SUSPEND) returns 0 (supported) invoke CPU_SUSPEND requesting the Standby power state This reaches the ATF standby implementation imx_cpu_standby(), but the system hangs in exactly the same way: no exception, no UART output, and execution never resumes. Therefore, both: raw wfi() executed at EL2 wfi() executed through ATF via PSCI produce identical behavior. What have been already verified CPU and timer U-Boot executes at EL2. CNTP timer is correctly programmed. CNTP_TVAL_EL0 counts down correctly. CNTP_CTL_EL0 shows: ENABLE = 1 IMASK = 0 ISTATUS = 0 immediately after arming. CPU interface ICC_PMR_EL1 is configured correctly. ICC_IGRPEN1_EL1 is enabled. Virtualization HCR_EL2 has: IMO = 0 FMO = 0 so interrupt routing through EL2 virtualization is not involved. Interrupt security classification From the ATF sources we verified that: all PPIs are initially configured as Group 1 Non-secure by the generic GICv3 helper code, only SGI8 (and optionally SDEI SGIs) are reconfigured as Secure, PPI 30 is **not** present in the secure interrupt property table. Therefore the Generic Timer interrupt appears to remain Group 1 Non-secure as expected. SCR_EL3.TWE We originally suspected that non-secure wfi() might be trapped to EL3 via SCR_EL3.TWE, but this now seems unlikely because the same behavior occurs when wfi() is executed inside ATF itself through PSCI. Additional investigation While tracing the ATF GIC initialization we noticed that gicv3_distif_init() clears the Distributor EnableGrp bits and only re-enables those requested by the secure interrupt property table. Since the helper only produces Group0 and Group1 Secure properties, it appears that EnableGrp1NS is never explicitly re-enabled. To verify this we: read GICD_CTLR observed EnableGrp1NS = 0 attempted to set EnableGrp1NS ourselves from EL2. Unexpectedly: the write completes without fault, RWP behaves normally, but EnableGrp1NS remains 0 after readback. We also verified: GICD_CTLR.DS == 0 RDC protection for the GIC memory regions is disabled (ENA = 0) RDC violation registers remain zero. Therefore RDC does not appear to be preventing the write. Remaining question At this point we have eliminated: timer programming, CPU interface configuration, interrupt priority masking, interrupt group classification, SCR_EL3.TWE trapping, PSCI vs raw WFI execution, RDC protection. The remaining unexplained behavior is that an architecturally Non-secure writable Distributor control bit (EnableGrp1NS) does not appear to accept writes on this platform, and consequently neither raw wfi() nor PSCI CPU_SUSPEND ever wake using the Generic Timer interrupt. Is this behavior expected on the i.MX8M Plus Android 15 BSP? Is there any platform-specific initialization missing outside the public ATF sources that is required before the Generic Timer PPI can wake a CPU from wfi()? Is EnableGrp1NS intentionally prevented from being modified by non-secure software on this platform? Has anyone successfully implemented periodic wake-up from U-Boot using either: raw wfi(), or PSCI CPU_SUSPEND  driven by the ARM Generic Timer? Any insight into the expected initialization sequence or platform-specific behavior would be greatly appreciated. Thanks Best Regards Pier

使用 flex-installer "lsdk2606" 版本在 Debian "imx95-15x15-frdm" 系统上发布 "Weston.Service" 你好， 我使用 flex-installer 版本“ lsdk2606 ”安装了 Debian 镜像。 剧透 （高亮部分可供阅读） sudo flex-installer -i auto -d /dev/sdX -m imx95-15x15-frdm sudo flex-installer -i auto -d /dev/sdX -m imx95-15x15-frdm 我的imx95-15x15-frdm 然后，我按照标准流程继续安装。 剧透 （高亮部分可供阅读） debian-post-install-pkg debian-post-install-pkg 安装完所有软件包并重启后，启动时出现以下错误： 剧透 （高亮部分可供阅读） [失败] 启动 weston.service - W…nd compositor 作为系统服务失败。 [失败] 启动 weston.service - W…nd compositor 作为系统服务失败。 剧透 （高亮部分可供阅读） root@imx95-15x15-frdm:~# systemctl status weston.service × weston.service - Weston，一个 Wayland 排版器，作为系统服务 已加载: 已加载 (/usr/lib/systemd/system/weston.service;已启用；预设：已启用） 活动状态：失败（结果：退出代码），自 2026 年 7 月 20 日星期一 13:51:20 UTC 起；19 秒前 调用：67b22b0fa1484ce681d8b2acdc107add 触发者：● weston.socket 文档：man:weston(1) man:weston.ini(5) http://wayland.freedesktop.org/ 进程：408 ExecStart=/usr/bin/weston --log= ${XDG_RUNTIME_DIR} /weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE) 主进程 ID：408（退出代码=1，状态=1/失败） 内存峰值：3.5M CPU：49毫秒 7月20日 13:51:19 imx95-15x15-frdm systemd[1]: 正在启动 weston.service - Weston，一个 Wayland 合成器，作为系统服务... 7 月 20 日 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): 用户 root(uid=0) 的会话已由 (uid=0) 打开 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:主进程已退出，代码=已退出，状态=1/失败 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:失败，结果为“退出代码”。 7 月 20 日 13:51:20 imx95-15x15-frdm systemd[1]: 启动 weston.service 失败 - Weston，一个 Wayland 合成器，作为系统服务。 root@imx95-15x15-frdm:~# systemctl status weston.service×weston.service - Weston，一个 Wayland 合成器，作为系统服务已加载：已加载 (/usr/lib/systemd/system/weston.service;已启用；预设：已启用）活动状态：失败（结果：退出代码）自 2026 年 7 月 20 日星期一 13:51:20 UTC 起；19 秒前 调用：67b22b0fa1484ce681d8b2acdc107add 触发者：● weston.socket文档： man:weston(1) man:weston.ini(5) http://wayland.freedesktop.org/进程：408 ExecStart=/usr/bin/weston --log= ${XDG_RUNTIME_DIR} /weston.log --modules=systemd-notify.so (code=exited, status=1/FAILURE) 主进程 ID：408 (code=exited, status=1/FAILURE) 内存峰值：3.5M CPU：49ms 7月20日 13:51:19 imx95-15x15-frdm systemd[1]: 正在启动 weston.service - Weston，一个 Wayland 合成器，作为系统服务... 7月20日 13:51:19 imx95-15x15-frdm (weston)[408]: pam_unix(weston-autologin:session): 用户 root(uid=0) 的会话已由 (uid=0) 打开 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:主进程已退出，代码=已退出，状态=1/失败 7月20日 13:51:20 imx95-15x15-frdm systemd[1]: weston.service:失败，结果为“退出代码”。7 月 20 日 13:51:20 imx95-15x15-frdm systemd[1]: 启动 weston.service 失败 - Weston，一个 Wayland 合成器，作为系统服务。 剧透 （高亮部分可供阅读） root@imx95-15x15-frdm:~# cat /run/user/0/weston.log 日期：2026年7月20日 UTC [12:34:22.150]韦斯顿 14.0.2 https://wayland.freedesktop.org 错误报告请提交至： https://gitlab.freedesktop.org/wayland/weston/issues/ 版本：LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+ [12:34:22.153]命令行：/usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so [12:34:22.153]操作系统：Linux，6.12.49，#5 SMP PREEMPT 2026年5月28日星期四 13:07:26 KST，aarch64 [12:34:22.153]飞行记录仪：已启用 [12:34:22.155]使用配置文件“/etc/xdg/weston/weston.ini” [12:34:22.156]输出重绘窗口最大为 16 毫秒。 [12:34:22.158]正在加载模块“/usr/lib/libweston-14/drm-backend.so” [12:34:22.162]模块加载失败：libdisplay-info.so.1：无法打开共享对象文件：没有该文件或目录 [12:34:22.162]致命错误：创建合成器后端失败 root@imx95-15x15-frdm:~# cat /run/user/0/weston.logDate:2026-07-20 UTC[12:34:22.150]weston 14.0.2https://wayland.freedesktop.org错误报告至：https://gitlab.freedesktop.org/wayland/weston/issues/Build：LSDK-25.12_DEBIAN-13_LF-6.12.20-168-g2ddc741+[12:34:22.153]命令行：/usr/bin/weston --log=/run/user/0/weston.log --modules=systemd-notify.so[12:34:22.153]操作系统：Linux，6.12.49，#5 SMP PREEMPT 2026 年 5 月 28 日星期四 13:07:26 KST，aarch64[12:34:22.153]飞行记录仪：已启用[12:34:22.155]使用配置文件“/etc/xdg/weston/weston.ini”[12:34:22.156]输出重绘窗口最大为 16 毫秒。[12:34:22.158]正在加载模块“/usr/lib/libweston-14/drm-backend.so”[12:34:22.162]模块加载失败：libdisplay-info.so.1：无法打开共享对象文件：没有该文件或目录[12:34:22.162]致命错误：创建合成器后端失败 我也遇到了同样的错误（我不知道是否相关），但是我的屏幕上什么都没显示。 剧透 （高亮部分可供阅读） it6263 3-004c：未能清除 DDC FIFO it6263 3-004c：读取 EDID 失败 it6263 3-004c：清除 DDC FIFO 失败；it6263 3-004c：读取 EDID 失败 Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe root@imx95-15x15-frdm:~# ldd /usr/lib/libweston-14/drm-backend.so linux-vdso.so.1 (0x0000ffffac56c000) libweston-14.so.0 => /usr/lib/libweston-14.so.0 (0x0000ffffac410000) libwayland-client.so.0 => /lib/aarch64-linux-gnu/libwayland-client.so.0 (0x0000ffffac3e0000) libpixman-1.so.0 => /lib/aarch64-linux-gnu/libpixman-1.so.0 (0x0000ffffac330000) libwayland-server.so.0 => /lib/aarch64-linux-gnu/libwayland-server.so.0 (0x0000ffffac2f0000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x0000ffffac2b0000) libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000ffffac250000) libdisplay-info.so.1 => 未找到 libgbm.so.1 => /usr/lib/libgbm.so.1 (0x0000ffffac220000) libseat.so.1 => /lib/aarch64-linux-gnu/libseat.so.1 (0x0000ffffac1f0000) libinput.so.10 => /lib/aarch64-linux-gnu/libinput.so.10 (0x0000ffffac170000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffabfb0000) /lib/ld-linux-aarch64.so.1 (0x0000ffffac520000) libxkbcommon.so.0 => /lib/aarch64-linux-gnu/libxkbcommon.so.0 (0x0000ffffabf40000) libffi.so.8 => /lib/aarch64-linux-gnu/libffi.so.8 (0x0000ffffabf10000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffabe60000) libcap.so.2 => /lib/aarch64-linux-gnu/libcap.so.2 (0x0000ffffabe30000) libsystemd.so.0 => /lib/aarch64-linux-gnu/libsystemd.so.0 (0x0000ffffabd00000) libmtdev.so.1 => /lib/aarch64-linux-gnu/libmtdev.so.1 (0x0000ffffabcd0000) libevdev.so.2 => /lib/aarch64-linux-gnu/libevdev.so.2 (0x0000ffffabc90000) libwacom.so.9 => /lib/aarch64-linux-gnu/libwacom.so.9 (0x0000ffffabc60000) libgudev-1.0.so.0 => /lib/aarch64-linux-gnu/libgudev-1.0.so.0 (0x0000ffffabc30000) libgobject-2.0.so.0 => /lib/aarch64-linux-gnu/libgobject-2.0.so.0 (0x0000ffffabba0000) libglib-2.0.so.0 => /lib/aarch64-linux-gnu/libglib-2.0.so.0 (0x0000ffffaba10000) libatomic.so.1 => /lib/aarch64-linux-gnu/libatomic.so.1 (0x0000ffffab9e0000) libpcre2-8.so.0 => /lib/aarch64-linux-gnu/libpcre2-8.so.0 (0x0000ffffab920000) Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe Hello root@imx95-15x15-frdm:~# find /usr -name "libdisplay-info*" /usr/lib/aarch64-linux-gnu/libdisplay-info.so.2 /usr/lib/aarch64-linux-gnu/libdisplay-info.so.0.2.0 /usr/share/doc/libdisplay-info2 Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe 请运行以下命令并分享输出结果？ 查找 /usr -name "libdisplay-info*" 谢谢！ Re: Issue "Weston.Service" on the "imx95-15x15-frdm" Debian using flex-installe 谢谢你的更新。 我可以看到 libdisplay-info 存在于系统中，但是 Weston 日志正在查找 libdisplay-info.so.1，而安装的库似乎是 libdisplay-info.so.2。 请运行以下命令并分享输出结果？ ldd /usr/lib/libweston-14/drm-backend.so 这将有助于验证是否存在库版本不匹配或其他缺失的依赖项。

S32K344/358/388 SWO Printf 在 S32DS3.6 中不起作用 嗨，团队、 我按照这个步骤用 pe multilink 和 S32DS3.6 测试了 SWO printf 函数。 我使用了 S32K3 官方 EVB 并检查了 SWO 引脚是否成功伸出。S32K311,312 SWO 可以正常工作，但 S32K344,358,388 无法打印出来。肯定有一些隐藏设置需要在软件中完成，您能帮忙测试并尝试一下吗？ 我已经测试了 S32DS3.6.1、3.6.2、3.6.3,3.6.5.所有情况都一样，311/312 可以正常工作，而 344、358、388 则无法工作。 优先级：高 S32DS Re: S32K344/358/388 SWO Printf not work is S32DS3.6 我已经检查了 S32K344 和 312 的 SWO 路线的 RM。344 则更为复杂。 也许需要用软件打开一些额外的开关。 顺祝商祺！ 杰里米 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 嗨，杰里米、 我来看看你的问题。过去这是一个已知的错误，但希望现在已经修复。您使用的是最新的 PE Micro 插件吗？ Re: S32K344/358/388 SWO Printf not work is S32DS3.6 嗨，吉瑞、 这是我的 PE 微型插件 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 嗨，杰里米、 请尝试使用最新的 PE Micro 插件（v6.1.8 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 嗨，吉日、 有时间的话，我会测试一下。您试过这个 v6.1.8 版本吗？ 顺祝商祺！ 杰里米 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Jiri，你好，我这边这个问题仍然存在，你那边有什么进展吗？ 顺祝商祺！ 杰米

MPC5746C FXOSC 出力周波数 パーツ:MPC5746C(Power Architecture Z4、SDK:NXP MPC57xxプラットフォームSDK)。 MPC5746Cのマニュアルには、FXOSCは8～40MHzの出力周波数を提供すると記載されています。以下の構成における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のサポート範囲内で行われます。 したがって、記載されている4つの構成すべてにおいて、FXOSCの出力周波数は外部入力周波数と全く同じになります。OSCMの設定（LCP/FSP）は発振器の動作モードに影響を与えますが、クロック周波数は変更しません。 よろしくお願いいたします。 ピーター Re: MPC5746C FXOSC output frequency @petervlna上記のFXOSCの問い合わせについてサポートいただければ幸いです。 Re: MPC5746C FXOSC output frequency クリスタル/共振器(OSCBYP = 0)と外部クロック(OSCBYP = 1)が提供する周波数はどのように見つければよいのでしょうか? 上記の質問について、 @petervlna さんにお知らせください。FXOSCをタイマーのクロックソースとして使用したい。提供される周波数に基づいて、カウント値をタイマーレジスタに読み込めます Re: MPC5746C FXOSC output frequency こんにちは、 MPC5746Cには、FXOSCレジスタからFXOSC周波数を測定または判定する方法がありません。周波数はハードウェア設計から知られている必要があります: OSCBYP = 0: FXOSC周波数は、基板に取り付けられた外部水晶発振器/共振器の周波数と等しい。 OSCBYP = 1: FXOSC周波数は、FXOSC入力ピンに印加される外部クロック信号の周波数と等しくなります。 FXOSCをタイマークロックソースとして使用するには、タイマーカウント値を計算する際に基板の回路図やクロックデザインで指定された周波数(例:8 MHz、16 MHz、40 MHzなど)を使用する必要があります。OSCBYPとOSCMの設定は、周波数自体には影響しません。 よろしくお願いいたします。 ピーター

S32K344/358/388 SWO Printf not work is S32DS3.6 Hi Team, I have tested the SWO printf function with pe multilink and S32DS3.6 following this step.  I have used the S32K3 official EVB and checked the SWO pin have extended out successfully. The S32K311,312 SWO can work fine, but S32K344,358,388 can't print out. There must be some hidden settings which needs to be done in the software, Could you help to test and try? I have tested S32DS3.6.1, 3.6.2, 3.6.3, 3.6.5. All behaves the same, 311/312 can work fine and 344,358,388 can't work. Priority: HIGH S32DS Re: S32K344/358/388 SWO Printf not work is S32DS3.6 I have checked the RM for the SWO routing for S32K344 and 312. 344 is more complex.  Maybe some extra switch need to be swited on by software. Best Regards, Jeremy Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Hi Jeremy,  I'll look at your issue. In past it was known bug, but hope that it is fixed now. Are you using latest PE Micro plugin?  Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Hi jiri, This is my PE micro plugin Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Hi Jiri, I will test it when I get time lator? Have you tried this  v6.1.8 version?  Best Regards, Jeremy Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Hi Jeremy,  please try to use the latest PE Micro plugin which is v6.1.8 Re: S32K344/358/388 SWO Printf not work is S32DS3.6 Hi Jiri, this issue still exists at my side, any update on your side? Best Regards, Jermey

サポート要望:i.MX8MプラスLVDS出力を用いたHD-SDIインターフェース 拝啓、 私たちは NXP i.MX8M Plus プロセッサをベースにしたシステムを設計しており 、 HD-SDIインターフェース の実装について皆様のご指導をいただきたい と考えています。 私たちの要件は、3つのHD-SDI出力をサポートすることです。 i.MX8M PlusのLVDSインターフェースを使用し、以下のデバイスを使ってHD-SDIに変換する予定です。 LMH0340SQE/NOPB – LVDS-HD-SDIシリアライザ LMH0324RTWT 1対3 HD-SDI分配アンプ 2台 i.MX8M PlusのLVDSインターフェース が 、3つのHD-SDI出力を生成するこのアーキテクチャに対応している か確認していただけます か? もしこの方法が推奨されない場合やサポートされていない場合、i.MX8M Plusプロセッサを使い続けながら3つのHD-SDIインターフェースを実装する代替案をご提案いただけます か?私たちはi.MX8M Plusをデザインに残したいと考えています。なぜなら、他のシステム要件をすべて満たすからです。 このインターフェースを成功裏に実装するためのリファレンス・デザインやアプリケーションノートのご提案をいただけるとありがたいです。 サポートありがとうございます。ご指導をお待ちしております。 よろしくお願いいたします。 サムドラランカイア・ジャンパニ アナログ(ADC|CMP|DAC|OpAmp) ボード設計 MCXA MCX C Re: Support Request: HD-SDI Interface Using i.MX8M Plus LVDS Output こんにちは、 残念ながら、私はこの種の使い方にあまり慣れていません。あなたが共有した部分を調べたところ、FPGAで使うことが期待されているようで、LVDSチャネルでは使えそうでないようで、このインターフェースがその用途に使えるかはわかりません。 i.MX8MPの別のブリッジや他のインターフェース、あるいはその間の別のレイヤー(FPGA)を使うのが解決策かもしれません。 よろしくお願いいたします。 アルド。

如何调整功放MD8LC925NR1的偏置电压？ 你好， 我们目前正在设计一个使用MD8LC925NR1功率放大器的系统。我们恳请您推荐合适的偏置电路或专用电源管理元器件，以便为该功率放大器提供正确的偏置。 请问您能否提供一些推荐的参考设计、应用笔记或具体零件编号？ 谢谢你的帮助。 Re: How to bias the amp MD8LC925NR1? 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 提供的零件编号似乎有误。MDL8LC925NR1不是 NXP 可订购的有效零件编号。最接近的匹配设备是MD8IC925N。请注意，该设备目前已停产，这意味着它不再受支持，也不再接受新的购买。 以下NXP文档提供了详细的设计信息，包括电路原理图、元器件清单和特性数据： MD8IC925N 数据手册 AN1977 –射频集成电路系列中的静态电流热跟踪电路 AN1987 – 射频集成电路设备系列的静态电流控制（包括两种偏置电路拓扑结构及完整的元器件清单） AN1955 – 射频功率放大器的热测量方法 遗憾的是，MD8IC925N 没有直接的替代品。此外，许多涵盖100 MHz 至 1000 MHz频率范围的射频产品即将停产，目前还没有宣布推出新的替代设备。 如果您需要我们根据您的具体频率、功率和供电电压要求，协助您寻找替代解决方案，请与我们联系。 顺祝商祺！

NXP iMX8MP：基于WFI的CPU在U-Boot中处于空闲状态时不会唤醒 尊敬的恩智浦技术支持团队： 我们正在研究基于 i.MX8M Plus 的产品的 U-Boot 中的低功耗等待机制，现在我们希望得到 NXP 的指导。 软件版本 SoC：NXP i.MX8M Plus BSP： ATF：lf_v2.10_android-15.0.0_1.2.0 U-Boot：lf_v2024.04_android-15.0.0_1.2.0 基于公开的 NXP 电路板支持包（Variscite 分支对 ATF/GIC 代码路径没有相关的修改） 目标 在 Android 系统启动之前，应用程序需要在 U-Boot 模式下停留几分钟，以便为深度放电的电池充电。 基于 mdelay() 的忙循环会消耗不必要的功率并产生额外的热量，因此我们正在尝试定期进入低功耗空闲状态，并使用 ARM 通用定时器 (CNTP, PPI 30) 唤醒。 初始实施 配置 CNTP 定时器 启用 PPI 30 从 EL2 执行原始 wfi() 处理器永远不会从 wfi() 中唤醒。UART 输出突然停止，没有任何异常或崩溃。 PSCI 实现 PSCI_VERSION 返回 1.1 PSCI_FEATURES(CPU_SUSPEND) 返回 0（支持） 调用 CPU_SUSPEND 请求进入待机电源状态 程序会执行 ATF 备用程序实现 imx_cpu_standby()，但系统会以完全相同的方式挂起：没有异常，没有 UART 输出，执行永远不会恢复。 因此，两者： 在 EL2 级别执行原始 wfi() 函数 wfi() 通过 ATF 经由 PSCI 执行 产生相同的行为。 已经核实的内容 CPU 和定时器 U-Boot 在 EL2 层执行。 CNTP定时器已正确编程。 CNTP_TVAL_EL0 倒计时正常。 CNTP_CTL_EL0 显示： 启用 = 1 IMASK = 0 布防后，ISTATUS = 0。 CPU接口 ICC_PMR_EL1 配置正确。 ICC_IGRPEN1_EL1 已启用。 虚拟化 HCR_EL2 具有： IMO = 0 FMO = 0 因此，中断路由不会通过 EL2 虚拟化进行。 中断网络安全分类 我们从美国烟酒枪炮及爆炸物管理局（ATF）的消息来源证实： 所有PPI最初都由通用GICv3辅助代码配置为第1组非安全设备。 只有 SGI8（以及可选的 SDEI SGI）被重新配置为安全模式。 PPI 30 不在安全中断属性表中。 因此，通用定时器中断似乎仍如预期那样保持为第 1 组非安全状态。 SCR_EL3.TWE 我们最初怀疑不安全的 wfi() 可能会通过 SCR_EL3.TWE 被困到 EL3，但现在看来不太可能，因为当 wfi() 通过 PSCI 在 ATF 内部执行时，也会发生同样的行为。 进一步调查 在跟踪 ATF GIC 初始化时，我们注意到 gicv3_distif_init() 会清除 Distributor EnableGrp 位，并且只会重新启用安全中断属性表请求的那些位。 由于该辅助程序只生成 Group0 和 Group1 Secure 属性，因此 EnableGrp1NS 似乎永远不会被显式地重新启用。 为了验证这一点，我们： 读取 GICD_CTLR 观察到 EnableGrp1NS = 0 尝试从 EL2 自行设置 EnableGrp1NS。 不料： 写入操作顺利完成，没有出现任何错误。 RWP运行正常 但读取后 EnableGrp1NS 仍然为 0。 我们还核实了： GICD_CTLR.DS == 0 GIC 内存区域的 RDC 保护已禁用（ENA = 0） RDC违规登记数量仍为零。 因此，RDC 似乎并没有阻止写入操作。 剩余问题 至此，我们已经排除了： 定时器编程 CPU接口配置， 中断优先级掩码 中断组分类， SCR_EL3.TWE 捕获， PSCI 与原始 WFI 执行方式对比， RDC保护。 剩下的未解释的行为是，架构上不安全的可写分发器控制位（EnableGrp1NS）似乎不接受此平台上的写入，因此原始 wfi() 和 PSCI CPU_SUSPEND 都无法使用通用定时器中断唤醒。 i.MX8M Plus Android 15 电路板支持包。 出现这种现象是否正常？ 在公共 ATF 源代码之外，是否存在任何平台特定的初始化缺失，导致通用定时器 PPI 无法通过 wfi() 唤醒 CPU？ EnableGrp1NS 是否被有意阻止在此平台上被不安全的软件修改？ 有没有人成功地使用以下两种方法之一实现了从 U-Boot 定期唤醒： 原始 wfi()，或 PSCI CPU_SUSPEND 由 ARM 通用定时器驱动？ 非常感谢您能提供任何关于预期初始化顺序或平台特定行为的见解。 谢谢！ 顺祝商祺！ 码头

PN7221 无法检测到 ISO 14443-3B 我们按照文档AN14880 PN7160/PN7220 - Android 16 移植指南移植了 PN7221。测试过程中，无法检测到 ISO 14443-3B (NfcB) 卡。此外，轻触此类卡片后，NFC 功能出现故障，无法识别任何卡片。需要将 NFC 关闭再重新打开才能恢复正常运行。相关日志附在下方，供您分析。 ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.516 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF接口 = 帧 RF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: 协议 = 未知 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: 模式 = B 被动轮询 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 type=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 已发送至 lower =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp:写 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - 写入请求..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - 调用 I2C 写入..... 07-16 09:24:28.519 530 6385 D NxpNciX : 长度 = 12 > 0000091D0000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C 写入成功..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - 发布新消息..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml 写入线程正在运行................ 07-16 09:24:28.519 530 6387 D NxpHal : 写入成功 状态 = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.520 530 6384 D NxpNciR：长度 = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.521 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.523 530 6384 D NxpNciR：长度 = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.523 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 已发送至 lower =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp:写 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - 写入请求..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - 调用 I2C 写入..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.525 530 6385 D NxpNciX : 长度 = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C 写入成功..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - 发布新消息..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - Tml 写入线程正在运行................ 07-16 09:24:28.525 530 6387 D NxpHal : 写入成功 状态 = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.527 530 6384 D NxpNciR：长度 = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.528 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C 读取成功..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB97166900000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - 正在发布已读消息..... 07-16 09:24:28.532 530 6387 D NxpHal : 读取成功 状态 = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:???? 未知子状态 (18) 07-16 09:24:28.533 1599 6381 我 libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - 读取请求..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - 调用 I2C 读取..... Re: PN7221 fails to detect ISO 14443-3B 我们已经升级到 3.2.5 版本，但测试结果仍然没有改变。 07-17 01:13:52.157 533 542 D NxpHal : 设备上检测到的固件版本 = 0x30205 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 请更新至 3.2.5 版本，您可以通过以下路径获取固件文件： nfc-NXPNFCC_FW/InfraFW/pn7220 at master · NXP/nfc-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : 设备上检测到的固件版本 = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 固件版本是多少？如果版本低于 3.2.5，请更新到最新版本并再次测试。 如果还有疑问，请向我们提供完整日志。 Re: PN7221 fails to detect ISO 14443-3B 你好@zhangkai 能否提供 libnfc-nci.conf 和 libnfc-nxp.conf 文件？ Re: PN7221 fails to detect ISO 14443-3B Hello @zhangkai  此问题可能与A16的变更有关。具体而言：在A15之前，NXP的MW依赖NFA_PROTOCOL_T3BT（80）来支持身份证，但A16通过Google已将中国身份证直接纳入其支持范围。然而，PN7xxx的MW仍保留了该代码。因此，客户尝试将T3BT逻辑从PN7xxx MW中完全移除，并直接使用Google的原生逻辑。 KaiLi_0-1784790560099.png Re: PN7221 fails to detect ISO 14443-3B 配置文件已上传。

How to bias the amp MD8LC925NR1? Hello, We are currently designing a system using the MD8LC925NR1 Power Amplifier. We would appreciate your recommendation for a suitable bias circuit or a dedicated power management component to properly bias this PA. Could you please provide any reference designs, application notes, or specific part numbers that you recommend for this purpose? Thank you for your assistance. Re: How to bias the amp MD8LC925NR1? Hello, Thank you for your interest in NXP Semiconductors products and for the opportunity to support you. There appears to be a typo in the part number provided. MDL8LC925NR1 is not a valid NXP orderable part number. The closest matching device is MD8IC925N. Please note that this device is currently End of Life, meaning it is no longer supported and is no longer available for new purchases. The following NXP documents provide detailed design information, including circuit schematics, component lists, and characterization data: MD8IC925N Datasheet AN1977 – Quiescent Current Thermal Tracking Circuit in the RF Integrated Circuit Family AN1987 – Quiescent Current Control for the RF Integrated Circuit Device Family (includes both bias circuit topologies with complete component lists) AN1955 – Thermal Measurement Methodology of RF Power Amplifiers Unfortunately, there is no direct replacement available for the MD8IC925N. In addition, many RF products covering the 100 MHz to 1000 MHz frequency range are approaching EOL status, and no new replacement devices have been announced at this time. Please let us know if you would like assistance identifying alternative solutions based on your specific frequency, power, and supply voltage requirements. Best regards

PN7221はISO 14443-3Bを検出できません PN7221は PN7160/PN7220 - Android 16移植ガイドAN14880文書に従って移植しました。テスト中、ISO 14443-3B(NfcB)カードは検出できません。さらに、そのようなカードをタップすると、NFC機能が誤作動を起こし、どのカードも認識しなくなります。正常な動作に戻すには、NFC機能を一度オフにしてから再度オンにする必要があります。分析に必要な関連ログを以下に添付いたします。 ❯ 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - I2C読み込み成功..... 07-16 09:24:28.515 530 6384 D NxpNciR : len = 26 > 61051701010001FF010C0B00000000D103860500808001000000 07-16 09:24:28.515 530 6384 D NxpTml : PN72xx - 既読メッセージを投稿中..... 07-16 09:24:28.516 530 6387 D NxpHal : read 成功状態 = 0x0 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: RF インターフェース = フレームRF 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: プロトコル = 不明 07-16 09:24:28.516 530 6387 D NxpHal : NxpNci: Mode = B パッシブ投票 07-16 09:24:28.516 530 6387 D NxpHal : NCI NTF: RF_DEACTIVATED len=26 タイプ=1 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - 読書リクエスト..... 07-16 09:24:28.517 530 6384 D NxpTml : PN72xx - I2Cリードの呼び出し..... 07-16 09:24:28.517 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 下層へ送信 =0 07-16 09:24:28.517 530 542 I android.hardware.nfc2-service.nxp:書く 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - 書き込みリクエスト..... 07-16 09:24:28.517 530 6385 D NxpTml : PN72xx - I2C Writeの呼び出し..... 07-16 09:24:28.519 530 6385 D NxpNciX : len = 12 > 00000091D000000000000080100 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - I2C 書き込み成功..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - 新しい書き込みメッセージの投稿中..... 07-16 09:24:28.519 530 6385 D NxpTml : PN72xx - Tml Writer Thread実行中................ 07-16 09:24:28.519 530 6387 D NxpHal : write true status = 0x0 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - I2C読み取り成功..... 07-16 09:24:28.520 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.520 530 6384 D NxpTml : PN72xx - 既読メッセージを投稿中..... 07-16 09:24:28.521 530 6387 D NxpHal : read, 成功した状態 = 0x0 07-16 09:24:28.521 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - 読書リクエスト中..... 07-16 09:24:28.521 530 6384 D NxpTml : PN72xx - I2Cリードの呼び出し..... 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - I2C読み取り成功..... 07-16 09:24:28.523 530 6384 D NxpNciR : len = 5 > 0000020000 07-16 09:24:28.523 530 6384 D NxpTml : PN72xx - 既読メッセージの投稿..... 07-16 09:24:28.523 530 6387 D NxpHal : read 成功状態 = 0x0 07-16 09:24:28.524 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:WAIT_ENDEF_FILE_CTRL_TLV (17) 07-16 09:24:28.524 1599 6381 D libnfc_nci: rw_t4t_send_to_lower: conn_id 下層へ送信 =0 07-16 09:24:28.524 530 542 I android.hardware.nfc2-service.nxp:書く 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - 書き込みリクエスト..... 07-16 09:24:28.524 530 6385 D NxpTml : PN72xx - I2C Write..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - 読書リクエスト中..... 07-16 09:24:28.524 530 6384 D NxpTml : PN72xx - I2Cリードの呼び出し..... 07-16 09:24:28.525 530 6385 D NxpNciX : len = 8 > 0000050036000008 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - I2C 書き込み成功..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - 新しい書き込みメッセージの投稿中..... 07-16 09:24:28.525 530 6385 D NxpTml : PN72xx - TMLライターThread実行中................ 07-16 09:24:28.525 530 6387 D NxpHal : write failed status = 0x0 07-16 09:24:28.527 530 6384 D NxpTml : PN72xx - I2C読み込み成功..... 07-16 09:24:28.527 530 6384 D NxpNciR : len = 6 > 600603010001 07-16 09:24:28.528 530 6384 D NxpTml : PN72xx - 既読メッセージを投稿中..... 07-16 09:24:28.528 530 6387 D NxpHal : read 成功状態 = 0x0 07-16 09:24:28.528 530 6387 D NxpHal : NCI NTF: CORE_GENERIC_ERROR len=6 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - 読書リクエスト..... 07-16 09:24:28.530 530 6384 D NxpTml : PN72xx - I2Cリードの呼び出し..... 07-16 09:24:28.531 530 6384 D NxpTml : PN72xx - I2C読み取り成功..... 07-16 09:24:28.532 530 6384 D NxpNciR : len = 14 > 00000B21CBA4729CB971669000000 07-16 09:24:28.532 530 6384 D NxpTml : PN72xx - 既読メッセージを投稿中..... 07-16 09:24:28.532 530 6387 D NxpHal : read 成功状態 = 0x0 07-16 09:24:28.533 1599 6381 I libnfc_nci: rw_t3Bt_sm_get_id (): sub_state:????不明のサブステート(18歳) 07-16 09:24:28.533 1599 6381 I libnfc_nci: nfa_rw_update_pupi_id: 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - 読書リクエスト..... 07-16 09:24:28.534 530 6384 D NxpTml : PN72xx - I2Cリードの呼び出し..... Re: PN7221 fails to detect ISO 14443-3B バージョン3.2.5にアップグレードしましたが、テスト結果は変わりません。 07-17 01:13:52.157 533 542 D NxpHal : デバイスで見つかったファームウェアバージョン = 0x30205 Re: PN7221 fails to detect ISO 14443-3B こんにちは、 @zhangkai さん。 3.2.5にアップデートしてください。fwファイルは以下のサイトから入手できます:nfc-NXPNFCC_FW/InfraFW/pn7220 at master ·NXP/NFC-NXPNFCC_FW Re: PN7221 fails to detect ISO 14443-3B 06-24 10:20:33.259 390 401 D NxpHal : デバイスで見つかったファームウェアバージョン = 0x302c4 Re: PN7221 fails to detect ISO 14443-3B こんにちは、 @zhangkai さん。 ファームウェアのバージョンは何ですか？もし3.2.5のような低いバージョンであれば、最新バージョンにアップデートして再度テストしてください。 それでもご不明な点がある場合は、ログ全体をご提供ください。 Re: PN7221 fails to detect ISO 14443-3B こんにちは、 @zhangkai さん。 libnfc-nci.confとlibnfc-nxp.confのファイルを提供してもらえますか? Re: PN7221 fails to detect ISO 14443-3B こんにちは、 @zhangkai さん。 この問題は、A16の変更に関連している可能性があります。具体的には、A15以前のNXP製モバイルMWは、IDカードのサポートにNFA_PROTOCOL_T3BT(80)を使用していましたが、A16ではGoogleを通じて中国のIDカードがサポート対象に直接含まれるようになりました。しかし、PN7xxx MWには依然としてこのコードが残っています。そのため、顧客はPN7xxx MWからT3BTロジックを完全に削除し、Googleのネイティブロジックを直接使用しようとしています。 KaiLi_0-1784790560099.png Re: PN7221 fails to detect ISO 14443-3B 設定ファイルがアップロードされました。

UG10215 lists imx708 as supported — which kernel driver should be used? Hi, I'm working on integrating a Raspberry Pi Sony IMX708 camera on an i.MX 95 based board, following UG10215 (i.MX 95 Camera Porting Guide). The document's "List of camera sensors modules supported" table lists the Raspberry Pi Sony imx708 as a supported reference camera module. However, I couldn't find a corresponding driver (e.g. imx708.c) in the linux-imx repository (branch lf-6.18.y😞 https://github.com/nxp-imx/linux-imx/commits/lf-6.18.y/drivers/media/i2c Could you clarify which kernel driver is expected to be used for the imx708 sensor on the i.MX 95? Is the IMX708 driver included in the public BSP? Thanks in advance. Re: UG10215 lists imx708 as supported — which kernel driver should be used? Hello, We do not have it officially supported yet in our standard BSP, you can take the driver from raspberry sources and use it: https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/media/i2c/imx708.c Best regards/Saludos, Aldo. Re: UG10215 lists imx708 as supported — which kernel driver should be used? Hi Aldo, thanks for your reply. We do not have it officially supported yet in our standard BSP Will it be supported in the future? Why is the IMX708 camera listed in UG10215 if support is not included in the standard BSP? Thanks again Diego Re: UG10215 lists imx708 as supported — which kernel driver should be used? Hello, Yes it is planned to be added but, unfortunately, I do not have a due date/version when its going to be added to the standard BSP release. The reason that it appears in the guide is because is one of the cameras that was tested in early development but was not fully supported in our BSP. Best regards/Saludos, Aldo.

Ara240 16GB M.2 模块 Ara240 16GB M.2 模块官方支持哪些量化精度？（INT4、8、16） Re: Ara240 16GB M.2 Module 根据Ara240 离散神经处理单元数据表 精确测量 官方文件支持 INT4 未找到相关文档支持 INT8 支持 INT16 支持 INT32 虽然不在您的 INT4/8/16 列表中，但已支持。

SDAファームウェアに関する質問 FRDM-A-S32K358の開発ボードを購入し、Open SDAを担当するMK26チップのファームウェアを変更するためにJTAGポートを確認しました。もし誤ってJ13にファームウェアをインストールしてしまった場合、Open SDAのファームウェアを入手する必要があります。この場合、サポートチケットを通じてファームウェアを入手できますか? Re: Open SDA Firmware Question こんにちは、 @wj_kwak MK26 OpenSDAデバイスがJ13経由で上書きされた場合、正常に動作するOpenSDAブートローダーを前提としているため、標準のOpenSDAアップデート手順は適用できなくなる可能性があります。OpenSDAのリカバリファームウェアは、通常、単体のプログラミングイメージとしては配布されていません。 OpenSDAのファームウェアとブートローダーは、NXPが開発したソフトウェアではなくPEmicro技術です。PEmicroはOpenSDAのファームウェアアップデート、ブートローダー更新アプリケーション、関連サポートを提供しています。 したがって、MK26がJTAG/SWDで消去または再プログラムされ、OpenSDAブートローダーが機能しなくなった場合、回復案内やファームウェアの入手は主にPEmicroが担当となります。 https://www.pemicro.com/support/index.cfm よろしくお願いいたします。 ルーカス

ライブラリを追加する CodeWarriorから移行したばかりで、新しいiMacにMCUXをインストールしたばかりです。私は赤外線リモコンを含む新しいプロジェクトに取り組んでおり、IRemoteライブラリ（GitHubから入手）を使用したいと考えています。ライブラリファイルはダウンロードしましたが、SDK_2.x_LPCXpresso824MAX(私が使っている開発ボード)には追加できません。「静的ライブラリの作成と使用方法」というドキュメントの手順に従ったのですが、手順とスクリーンショットは私のものよりかなり古いバージョンのもののようです。 私の問題を解決してくれるような「初心者向けガイド」を持っている人はいませんか？ Re: Add a library こんにちは、 ライブラリにはどのようなファイル形式がありますか？拡張子は.aですか、それとも.hですか？ 「ユーザーアプリケーションにユーザー静的ライブラリを追加する」第2章( MCUXpresso IDEで静的ライブラリの作成と使用 方法)の5ページで述べた手順は、新しいバージョンのMCUXpresso IDEにも引き続き適用されます。ガイドに示されているウィンドウは最近のMCUXpressoバージョンでも同じです。手順に問題がありますか？ また、どのバージョンを使っているのか確認してもらえますか? SDKに関しては、「SDK_2.x_」と書いたのですね。どの古いバージョンを使っているか確認してもらえますか?最新のSDKバージョン26.06を使うようにアップデートすることもできます。SDK Builderからダウンロードできます 敬具、ルイス Re: Add a library これは私の問題の一部です。ファイルには拡張子がなく、単に「IRemote-4.7.1」という名前で、ダウンロードフォルダ内ではフォルダとして表示されます。古いバージョンのSDKを使っているとは思いません。バージョンは26.06.00です。もしかすると、実際のIRemoteライブラリを読み込んでいないのかもしれません。ただダウンロードボタンを押してしまっただけかもしれません Re: Add a library Hello おそらくライブラリのGithubフォルダ全体をダウンロードしていると思います。通常、Githubユーザーは.h/.c/.hpp/.cppを保存します。srcフォルダ内のなど。 必要な.h/.aファイルだけをsrcフォルダからダウンロードするか、Githubで検索するだけで、Githubプロジェクト全体をダウンロードせずに、ガイドに従ってライブラリとリンクへのパスを追加できます。 敬具、ルイス

Windows ARM64 サポート リクエスト (LinkServer/MCUXpresso) LinkServerとMCUXpressoインストーラーのWindows ARM64版もリリースしてほしいという要望です。最近、ArmベースのWindowsノートPCを使っている学生をよく見かけるようになりました。 開発ボード MCXA MCX N Re: Windows ARM64 support request (LinkServer/MCUXpresso) こんにちは、 ご提案ありがとうございます。担当チームにこの件についてコメントいたします。 MCUXpressoを使用するにあたり、Visual Studio Codeの拡張機能を使ってみるお手伝いをしていただけますか？調査結果をぜひ教えてください。 このツールのインストールと使用方法については、以下をご覧ください。 MCUXpresso for VS Code ドキュメント — MCUXpresso for VS Code 26.05 ドキュメント Visual Studio Code 用 MCUXpresso | NXP Semiconductors 敬具、ルイス Re: Windows ARM64 support request (LinkServer/MCUXpresso) ご返信ありがとうございます。VS Code拡張機能は正常に動作します。mcu-linkドライバは、Microsoftが巧みに移植したWinUSBをベースにしている。私はテストシステム上で管理者権限を持っていませんでしたが、リンクサーバーをシステムにコピーしてプロジェクトのデバッグを行うことができました。LinkServerのインストールに含まれる他のドライバについては分かりませんが、それらには署名済みのARMバージョンが必要になるでしょう。 残念ながら、「mcuxpressoインストーラー」によってインストールされるツールはすべてx64なので、すべてがPrism変換レイヤーを介して実行されます。git、python、ninja、cmakeなどは既にARM版がリリースされているはずなので、パッケージ化できるはずだ。arm-none-eabiツールチェーンだけはまだarm64版がリリースされていませんが、ビルドすることは可能です。特にMCU-Link開発ボードに関しては、主にARM64版Windowsのパフォーマンスが重要になります。 Re: Windows ARM64 support request (LinkServer/MCUXpresso) こんにちは! 問題なく動作していると聞いて安心しました。このトピックの最新情報ですが、残念ながらMCUXpressoのIDE用ARM64はメンテナンスのみで、推奨されているのはMCUXpressoには引き続きVS Code拡張機能の使用です。 敬具、ルイス Re: Windows ARM64 support request (LinkServer/MCUXpresso) MCUXpressoインストーラーはVSCode拡張機能で使用されており、私が話していたのはそのことです。https ://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-installer :MCUXPRESSO-INSTALLER およびhttps://mcuxpresso.nxp.com/mcux-vscode/latest/html/MCUXpresso-Installer.html を参照してください。これはmacOS x64/arm64およびlinux/windows x64向けにリリースされていますが、arm64には対応していません。このパッケージにはlink serverが含まれており、macOS x64/arm64、linux x64/arm64向けにリリースされていますが、Windows x64向けにリリースされています。私のお願いは、これらのアプリケーションをWindows Arm64向けにリリースすることです。mcuxpressoインストーラーは多くのものをインストールするようですが、そのほとんどは既にWindows arm64向けに提供されているものだと理解しています。私は新しいWindows Arm64ノートPCを持つ学生たちと仕事をしていますが、今は彼らがうまく動作させるための回避策を手伝わなければなりません。

S9KEAZN16AM WDOGタイミングに関する補足説明：128バスクロックと観測された80µsおよび2.5msの遅延について こんにちは、 私はS9KEAZN16AMを扱っており、WDOGの初期化タイミングについていくつか確認したい点があります。 設定 MCU:S9KEAZN16AM バスクロック: 16.777216 MHz WDOGクロックソース：1kHz LPOCLK リセットタイプ:ソフトウェアリセット(SYSRESETREQ) KEA64リファレンスマニュアルによると、ウォッチドッグの解除シーケンスの後: 「アンロックシーケンスを完了した後、ユーザーは128のバスクロック内でウォッチドッグを再構成しなければなりません;そうでなければ、監視役はMCUのリセットを強制します。」 バスクロック周波数は16.777216MHzです。 128バスクロック ≈ 7.63マイクロ秒 補足事項 現在の実装では、安定した動作のために以下の遅延が必要となります。 ソフトウェアリセット();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); 我々は2つの問題点を指摘する。 Software_Reset() の後の 2.5 ms の遅延を削除または短縮すると、ウォッチドッグ カウンタが正しく起動/実行されない場合があります。 WDOG_Init() の後の 80 µs の遅延を削除すると、ウォッチドッグの設定が常に正しく適用されるとは限りません。 質問 128バスクロックの要件は、ロック解除後の設定ウィンドウのみに適用されるのでしょうか、それともその後も追加の内部同期が行われるのでしょうか？ 1 kHzのLPOクロックの使用によって追加の同期遅延が生じることはありますか? ソフトウェアリセット後の起動タイミングの要件で、約2.5msの遅延が必要になる理由は何かありますか? 固定遅延の代わりに、推奨されるステータスビットやポーリングメカニズムはありますか？ 混乱の主な原因は、観測された遅延（ 80 µs と 2.5 ms ）が、文書化された128 バス クロックの要件（約 7.6 µs）から示唆されるタイミングよりもかなり大きいことである。 何かご助言いただければ大変ありがたいです。 よろしくお願いします。