Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
ICODE SLIはICODE SLIXに切り替えられません クライアントは私が提供したICODE SLIチップを使っていますが、このチップは終了しています。ICODE SLIXへの切り替えを試みていますが、クライアントのRFIDリーダーが認識できません。 Re: ICODE SLI can't be switch to ICODE SLIX こんにちは、 ICODE SLIXはISO15693レベルでICODE SLIと後方互換性を持つことを意図しているため、リーダーは少なくとも在庫管理時にSLIX UIDを検出すべきです。リーダーが認識できない場合は、まず故障がRFインベントリレベルにあるのか、アプリケーションのタグ識別ロジックにあるのかを確認してください。一般的な原因には、AFI/UIDフィルタリング、SLI製品認識のハードコード、古いリーダーファームウェア、または移行時のSLIX特有のセキュリティや機能の使用などがあります。最初のテストでは、AFIフィルタリングとタグホワイトリストを無効にし、標準ISO15693インベントリを実行し、UID/DSFID/AFIを読み取り、アプリケーションの受け入れロジックを旧SLIタグと比較します。 よろしくお願いします。 Re: ICODE SLI can't be switch to ICODE SLIX このスレッドを適切なコミュニティに移してください。これはColdfireや68kの部品ではありません。
查看全文
LX2160A:SerDesレーンを使わないレシーバのプルダウンバリュー こんにちは、 チップ: LX2160A アプリケーションノートAN5407には、SerDesレーンを使用しない場合にプルダウンを指定しています: もし一部のSerDesレーンがノーコネクトなら、その受信ピンをGNDに引き下げてください。 プルダウンの価値を教えていただけますか?それともレシーバのピンを直接GNDに接続すべきでしょうか? ありがとうございます。 Re: LX2160A: Pull down value on receiver for SerDes lanes not used こんにちは、 AN5407の「 受信機ピンをGNDに引き下げる」 という言語は、方法について意図的に曖昧にしています。NXPの明確化は、GNDへの直接の0 Ω接続が正しく推奨されるアプローチであるということです。 SerDesの電源オフ RXピンがGNDに接続されている場合でも、SerDesブロックに電源が供給されたままの場合は、AN5407ではファームウェアを介して未使用のレーンを電源オフにすることを推奨しています。PBIフェーズ中にGeneral Control 0レジスタを設定して、未使用のSerDesレーンを電源オフにします。SerDesブロック全体が既に電源オフになっている場合は、個々のレーンの電源オフは不要です。 よろしくお願いします。
查看全文
使用 NXP 基于模型的设计方法开发完整的裸机操作系统是否可行? 大家好, 我的目标是评估使用 MATLAB/Simulink、Embedded Coder 和 NXP MBDT 为 NXP S32G3 开发完整的裸机操作系统/软件平台的可行性。 目标是在 Simulink 中开发完整的软件栈,使用 Embedded Coder 生成 C 代码,并将生成的代码直接部署到 S32G3 Gold Box 上,而无需依赖外部操作系统、RTOS 或 AUTOSAR BSW。 具体来说,我想了解使用 NXP MBDT 在技术上是否可行,能否在 S32G3 上为 Cortex-A 内核和 Cortex-M 内核实现软件,生成的软件能够处理系统初始化、调度、中断管理、内存管理、硬件抽象、外设初始化、IPC 机制以及操作系统通常提供的其他服务。 我了解到启动 ROM 是硬件驻留的,并且在应用程序之前执行。我的目标是尽可能地使用 NXP MBDT 工作流程,通过 Simulink 生成的代码来实现硬件启动过程之后的所有操作。 因此,我的主要问题是: 1. 使用 NXP 基于模型的设计工具箱以及 MATLAB/Simulink 和 Embedded Coder,为 S32G3 开发一个完整的裸机软件平台(类似操作系统的框架),同时面向 Cortex-A 和 Cortex-M 内核,在技术上是否可行?如果 MBDT 工作流程存在任何限制,能否请您说明哪些部分仍然需要手写 C 代码或汇编代码? 据我了解,MBDT是由NXP公司开发的。但是,如果这个问题更适合由 NXP MBDT 团队解答,请您指点我到合适的联系方式或支持渠道。 感谢您的指导。
查看全文
Is it feasible to develop a complete bare-metal operating system using the NXP Model-Based Design To Hi team, My objective is to evaluate the feasibility of developing a complete bare-metal operating system/software platform for the NXP S32G3 using MATLAB/Simulink, Embedded Coder, and the NXP MBDT. The goal is to develop the complete software stack in Simulink, generate C code using Embedded Coder, and deploy the generated code directly onto the S32G3 Gold Box without relying on an external operating system, RTOS, or AUTOSAR BSW. In particular, I would like to understand whether, using the NXP MBDT, it is technically feasible to implement software for both the Cortex-A cores and the Cortex-M core on the S32G3, with the generated software handling system initialization, scheduling, interrupt management, memory management, hardware abstraction, peripheral initialization, IPC mechanisms, and other services typically provided by an operating system. I understand that the Boot ROM is hardware-resident and executes before the application. My intention is for everything after the hardware boot process to be implemented, as much as possible, using Simulink-generated code through the NXP MBDT workflow. Therefore, my primary question is: 1. Is it technically feasible, using the NXP Model-Based Design Toolbox together with MATLAB/Simulink and Embedded Coder, to develop an entire bare-metal software platform (OS-like framework) for the S32G3 targeting both the Cortex-A and Cortex-M cores? If there are any limitations within the MBDT workflow, could you please clarify what portions would still require handwritten C or assembly? I understand that MBDT is developed by NXP. However, if this question is better addressed by the NXP MBDT team, I would appreciate it if you could kindly direct me to the appropriate contact or support channel. Thank you for your guidance.
查看全文
i.MX8M Plus - 专用于显示屏和摄像头的 I2C 接口 大家好, 我想确认一下是否有专用于显示屏和摄像头的 I2C 接口。 (例如,I2C2 用于显示器,I2C4 用于摄像头)或者配置上没有限制,我可以使用任何 I2C 接口作为显示器和摄像头接口吗? Re: i.MX8M Plus - Dedicated I2C for Display and Camera 在 i.MX8M Plus 上,您可以使用任何可用的 I2C 控制器来连接显示相关设备或摄像头相关设备。SoC 内部没有专用的“摄像头 I2C”或“显示器 I2C”。选择取决于您的硬件设计和设备树配置。
查看全文
LX2160A:接收器上未使用的 SerDes 通道的下拉值 你好, 芯片: LX2160A 应用笔记 AN5407 规定,如果未使用 SerDes 通道,则应将其下拉: 如果某些 SerDes 通道未连接,请将其接收器引脚拉低至 GND。 请问下拉菜单的值是多少?或者我应该将接收器引脚直接连接到 GND? 谢谢。 Re: LX2160A: Pull down value on receiver for SerDes lanes not used 你好, AN5407 中的“将接收器引脚拉低至 GND”的说法故意含糊不清——NXP 的澄清是,直接将 0 Ω 连接到 GND 是正确且首选的方法。 SerDes 掉电 即使 RX 引脚连接到 GND,如果 SerDes 模块仍然通电,AN5407 还建议通过固件掉电未使用的通道:在 PBI 阶段配置通用控制 0 寄存器以掉电未使用的 SerDes 通道。如果整个 SerDes 模块已经掉电,则无需单独掉电各个通道。 此致
查看全文
使用 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 这将有助于验证是否存在库版本不匹配或其他缺失的依赖项。
查看全文
标记细节 请解释标记的含义 04 01 616 适用于 MPN:PCA9553DP/01,118
查看全文
NXPモデルベース設計を用いて完全なベアメタルオペレーティングシステムを開発することは実現可能でしょうか? こんにちは、チームのみなさん。 私の目的は、MATLAB/Simulink、Embedded Coder、NXP MBDTを用いて、NXP S32G3向けの完全なベアメタルオペレーティングシステム/ソフトウェアプラットフォームを開発する実現可能性を評価することです。 目標は、Simulinkで完全なソフトウェアスタックを開発し、Embedded Coderを使ってCコードを生成し、生成されたコードを外部オペレーティングシステムやRTOS、AUTOSAR BSWに依存せずに直接S32G3 Gold Boxにデプロイすることです。 特に、NXP MBDTを用いて、Cortex-AコアとCortex-Mコアの両方をS32G3上で実装し、生成されたソフトウェアがシステムの初期化、スケジューリング、割り込み管理、メモリ管理、ハードウェア抽象化、周辺機器初期化、IPCメカニズム、その他オペレーティングシステムで通常提供されるサービスとして技術的に実装できるかどうかを理解したいです。 Boot ROMはハードウェア上に常駐しており、アプリケーションより先に実行されると理解しています。私の意図としては、ハードウェアの起動プロセス以降のすべての処理を、可能な限りNXP MBDTワークフローを通じてSimulinkで生成されたコードを使用して実装することです。 したがって、私の主な質問は次のとおりです。 1. NXP Model-Based Design ToolboxとMATLAB/Simulink、Embedded Coderを組み合わせて、Cortex-AおよびCortex-Mの両方を対象としたS32G3向けのベアメタルソフトウェアプラットフォーム(OS風フレームワーク)を開発することは技術的に実現可能か?MBDTのワークフローに制限がある場合、どの部分が手書きのCやアセンブリを必要とするのかを明確に教えていただけますか? MBDTはNXPによって開発されたものだと理解しています。しかし、もしこの質問にNXP MBDTチームがより適切に回答できる場合は、適切な連絡先やサポートチャネルをご案内していただけるとありがたいです。 ご指導ありがとうございました。
查看全文
Performance degradation in Facemesh Landmark model ptq conversion We were using Google's FaceMesh model released by NXP after ptq in this repo: nxp-demo-experience-demos-list/downloads.json at lf-6.12.3_1.0.0 · nxp-imx-support/nxp-demo-experience-demos-list But this model is based on Google's old FaceMesh model, which had 468 landmark points. Now we want to move to Google's new FaceMesh model, which has 478 landmark points. We want to run this on iMX 95 FRDM board NPU. So, we wanted to quantize this. We are using NXP's eIQ-neutron-sdk-linux-3.1.3 to quantize this model. After this quantization, we are seeing significant degradation in model performance, almost unusable for actually using it. Initially we were quantizing it with MIN-MAX option. That model was unusable. Then we tried using percentile option and found a better performance with percentile set to 95 (even though this was regressor outputs). But this is still not giving great performance 1) When NXP created the ptq file for old FaceMesh(468) model which option did they use, MIN-MAX? Or percentile? 2) Is there anything else we need to check when the performance degrade drastically after quantization 3) we profiled with the CelebA dataset used the serialize_image.py in scripts dir with model options specific options, should we run the full media pipe and create the calibration dataset or make changes in serialize script  options supplied serialize_image.py:  -i            //218 x 178 front facing RGB images  -o -f bin -t float32 -m 0to1 -s 256, 256 -layout NHWC -co RGB tflite-profiler: --input  --dataset --output tflite-quantizer: --input  --profile  --quantize-inputs=false      --quantize-outputs=false --quantization-calibration-method= //MinMax or Percentile Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @dhilshad, Thank you for contacting NXP Support! 1) Unfortunately, we do not have that information available at this time. 2) This behavior is expected. Quantization is only one part of the deployment process; converting and optimizing a model for execution on embedded hardware involves several additional steps, such as graph optimization, operator mapping, hardware-specific transformations, and runtime validation. As a result, model behavior and performance can vary even when the model is already quantized. For new designs and evaluations, I recommend using eIQ Olive, as it provides a more modern framework for model optimization and deployment on NXP i.MX platforms. It includes updated workflows and improved support for current machine learning deployment scenarios. Please refer to the following tutorials and documentation for more information: https://eiq.nxp.com/learning-hub/tools/olive/index.html These resources cover the recommended workflows and best practices for deploying machine learning models on i.MX devices. Best regards, Chavira Re: Performance degradation in Facemesh Landmark model ptq conversion Hi @Chavira , Thanks for the replay. And pointing out to the documentation Just to clarify here, our main concern is the accuracy of the model . In case of FaceMesh model, we see that the output landmark points are not accurate enough for our application. As I said earlier, we had found that keeping a 95 percentile cutoff was giving a slightly better result than the MIN MAX. But still not comparable to the accuracy we see in the NXP's ptq model (FaceMesh 468).  We have one more observation: 1) We tried by giving just 8 samples from our production environment as representative dataset. This was slightly improving the result. Then we added 250 images from the same environment and profiled and quantized. But this caused the accuracy to degrade.  Do you have any idea why this kind of behaviour might come? 2) Also, has NXP already converted the Google's new FaceMesh model (with 478 landmark) model to ptq?
查看全文
IPCF version issue I'm using the following RTD version: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01&04; IPCF version: SW32K3_IPCF_4.2.1_D2504; EB version: 29.0. When importing into Excample... An error occurred in the project: IPCF_AutosarOS_S32K358_M7_0, with the following content: Errors (11061) Plug in with a module Os TS T40D34M413R184" is not instald - cannot create module configurations for project IPCF AutosarOS S32K358 M7 0" 0 (11061) Plug in with a module "pc TS T40D34M4210R0 is not installed cannot create module configurations for project "IPCF AutosarOS $32K358 M7 0" 0 (11061) Plug in with a module Resource TS T40D34M5010Ro is notinstaled -cannet create module configurations for prcject IPCF AutosarOS $32K358 M7 0° @ (11061) Plug in with a module 'BaseNXP TS T40D34M50I0RO is notinstalled - cannot create module configurations for prgject IPCF AutosarOS $32K358 M7 0 @ (11061) Plug-in with a module "Mcu TS T40D34M5010R0 "is not installed - cannot create module configurations for project 'IPCF AutosarOS $32K358 M7 0" How can I solve this problem using the appropriate IPCF or EB version? Re: IPCF版本问题 Hi @liyongfeng  Could you please let me know which plugin versions are currently installed in your EB tresos environment? Also, could you try reinstalling the RTD package and verify whether the issue persists afterward? BR, VaneB
查看全文
我的NFC卡出了问题,需要帮助。 我最近在亚马逊上购买了 ACR122U-A9 和 13.56MHz RFID 近距离 ID 卡钥匙扣,可写入可重写 CUID 钥匙扣标签,兼容 MIFARE Classic 1K。我安装了 MWT V.1.6.8424.424.63,它读取了大约 4 个标签后就停止了,要么显示无法读取卡,要么读取到 63 到 64 时就停止了。请问有人能帮忙吗?我对科技真的不太擅长。 NFC读卡器库 Re: I need help with my NFC card 您好,先生, 感谢您使用我们的设备。 关于 ACR122U-A9 的使用,我注意到官方页面上提到,不建议在新设计中使用此读卡器。我的建议是迁移到推荐且受支持的版本。 关于您安装的 MW,能否请您说明一下您是从哪里获得的中间件?因为我在官方页面上找不到它。 我想了解一下您所说的“与 MIFARE Classic 兼容的标签能够像 4 个标签一样工作”是什么意思。MIFARE Classic 卡仅支持 ISO14443-3 命令,请查看数据表以获取正确的命令说明。 如果您能提供更多关于您项目的信息,我或许可以给出更好的建议,因为出于安全原因,我们也不推荐使用MIFARE Classic卡。
查看全文
i.MX8M Plus — ECSPI/SPI NOR 上のセカンダリイメージブート (IMG_CNTN_SET1_OFFSET): OP で ROM がフォールバックするか i.MX8M Plus -- ECSPI/SPI NOR 上のセカンダリ イメージ ブート (IMG_CNTN_SET1_OFFSET): OPEN 構成では ROM がフォールバックしますか? ==== セットアップ ==== - SoC:i.MX8M Plus(カスタムSMARCモジュール) - ブートデバイス: ECSPI2 / CS1 上のシリアル NOR (Winbond W25Q128、16 MiB)。これはFlexSPIではなく、レガシーのeCSPIコントローラーです。 - セキュリティ:OPEN構成(デバイスがHABクローズドでない)。 - ヒューズ IMG_CNTN_SET1_OFFSET (ヒューズ読み取り 2 1) = 0x00000000。 - フラッシュマップ: プライマリブートローダーは0x000000、セカンダリコピーは0x400000 (4 MiB) にあります。 文書化されたSPIマッピングによると: 「SPIの場合:ヒューズが10より大きい場合はセカンダリブートが無効になります。n == 0の場合はオフセット = 4 MB、n == 2の場合は1 MB、その他でn <= 10の場合は1 MB * 2^nとなります。」 ヒューズ n = 0 (工場出荷時のデフォルト設定、書き込み不要) の場合、セカンダリオフセットは正確に 0x400000 になります。 ==== 問題点 ==== バイト単位で同一で、cmp.bで検証済みのプライマリイメージのコピーを0x400000に配置し、プライマリブートヘッダーを無効化(sf erase 0 0x1000)してリセットしました。 ROMはセカンダリイメージにフォールバックしないため、ボードは起動不能状態になります(USB SDP経由でのみ復旧可能)。 また、プライマリボディ内部の穴を消去する(sf erase 0x100000 0x40000)ことも試みましたが、結果は同じでした。 ==== 質問 ==== 1. SPI/ECSPI NORで、ROMがIMG_CNTN_SET1_OFFSETの二次映像に切り替わるのは具体的に何をトリガーするのか? これは無効なプライマリブートヘッダーやイメージ解析失敗、それとも特定のHAB認証失敗なのでしょうか? 2. セカンダリイメージブートは、OPEN(非セキュア)構成でも機能しますか、それともデバイスがHABで閉じられている場合にのみ機能しますか? 3. 同じリセットにフォールバックするのか、それとも電源のオンオフ/2回目のリセット(永続ブート方式)が必要なのか? 4. 0x400000 のセカンダリ イメージは、別々に構築されたブート可能なイメージ (そのオフセット用の独自の IVT/ブート データ) である必要があります。 それとも、プライマリとバイト単位で同一のコピーで十分なのでしょうか? ==== ロジックアナライザによる証拠(リセット中にキャプチャされたSPIバス) ==== リセット中に、Saleae Logic Pro 16を使用してECSPI2バス(CLK、MOSI、MISO、CS)を500 MS/sでプローブし、すべてのSPIトランザクションをデコードしました。比較のために、FlexSPI NORから起動し、セカンダリへのフォールバックも正常に行われるi.MX8QMモジュールでも同様のテストを実施しました。 ---- i.MX8M Plus (ECSPI NOR)、プライマリが破損しています ---- ROMは0x03のREADコマンドのみを発行し、オフセット0から厳密に順次読み取ります。 0x03 00 00 FC -> 0x0000FC を読み込む 0x03 00 04 EC -> 0x0004EC を読み込む 0x03 00 08 DC -> 0x0008DC を読み込む ...(64 KiBブロックあたり約50回の読み取り、増加傾向)... 0x03 00 13 xx -> ここで読み取りカウントが減少(0x100000-0x140000 の領域が消去され、MISO=0xFF) 0x03 00 18 xx -> 穴を越えて直線的に続く ...最大で約0x1A69E8まで... ROMはプライマリ領域全体を直線的に読み取り、消去/無効領域をそのまま通過し(0xFFを取得)、0x400000または0x800000(セカンダリ領域)への読み取りは決して行いません。 キャプチャ全体(2500万サンプル、デコードされたトランザクション654件)には、「0x03 40 xx xx」はどこにも存在しません。 完全に消去されたヘッダーの場合、ROMは0xFFをロードし実行し、同期アボートでクラッシュします。フォールバックは一切ありません。 ---- i.MX8QM (FlexSPI NOR) は比較のために使用しています -- セカンダリフォールバックは正常に動作します ---- プライマリコンテナヘッダーのみが無効化された場合(FCBは0x000400にそのまま残された場合)、QM ROMは次の動作をします。 0x0B 00 04 00 -> 高速読み取り FCB @0x000400、MISO: 46 43 46 42 ("FCFB" マジック、FlexSPI 設定有効) ...FCB構成データを読み込む... 0x0B 00 10 00 -> 高速読み取りプライマリコンテナ @0x001000、MISO: FF FF FF FF (無効!) 0x0B 40 10 00 -> 高速読み取りセカンダリコンテナ@0x401000、MISO:有効な<-- ROMスイッチ、同じリセット 0x0B 40 30 00、0x0B 40 40 00、... -> 2次画像全体を読み込みます(0x40xxxxで~90リード) QM ROMはFCBを読み取り、FlexSPIを設定し、0x001000のプライマリコンテナをチェックし、0xFFを認識します。 そして直ちに(同じリセットで)0x401000のセカンダリコンテナに切り替わります。これはうまくいきます。 代わりに最初の4MB(FCBを含む)をすべて消去すると、QM ROMは2回だけの読み込みを行います 0x000400で、0xFFを得て撤退しません。つまり、撤退が作戦するには有効なFCBが必要です。 - - 比較 - - i.MX8M Plus (このボード): コントローラ:eCSPI(レガシーSPI) オペコードを読みます:0x03 READ FCBの現状:いいえ(eCSPIにはFCBの概念はありません) 破損したプライマリでセカンダリーを読み取る:いいえ ― バスは「0x03 40 xx xx」を表示しません。 結果:レンガ(ロード0xFF ->クラッシュ) i.MX8QM(参考文献): コントローラー:FlexSPI オペコードを読んでください:0x0B 速読 FCBの提示:はい(0x400、魔法の「FCFB」) 破損したプライマリで二次を読み取る:はい -- 「0x0B 40 10 00」、同じリセット 結果:セカンダリーブーツ成功 ==== 要約 ==== バスキャプチャから、i.MX8M Plus の IMG_CNTN_SET1_OFFSET セカンダリイメージの起動が確認できる。 FlexSPI専用であるか、HABクローズド構成によって制限されているかのどちらかで、有効になりません。 OPEN構成のeCSPI NORの場合。 NXPの皆さん、確認いただけますか: - i.MX8M Plus上で、eCSPI(FlexSPIとは異なる)NORがセカンダリイメージブートにサポートされているかどうか; - トリガーがHAB-auth-failure(閉じた設定のみ)か、無効なヘッダー(開設定も含む)か; - フォールバックが同じリセットか電源サイクルが必要か; - セカンダリはそのオフセットのために別途構築する必要があるのか、それともバイト同一のコピーで問題ないのか。 よろしくお願いします。 Re: i.MX8M Plus — Secondary image boot (IMG_CNTN_SET1_OFFSET) on ECSPI/SPI NOR: does ROM fall back i こんにちは、 @djordje_nodさん。 お元気でお過ごしのことと思います。 Q1.ECSPI NORにおいて、ROMがセカンダリROMにフォールバックするトリガーは何ですか? OPENモードでは、ROM/HABがイメージ認証を行いますが、すべての認証エラーは無視され、イメージは実行されます。 閉鎖モード(SEC_CONFIGフューズ)では、主イメージのHAB認証が失敗すると、ROMはPERSIST_SECONDARY_BOOT(SRC_GPR10[30])を1に設定し、ソフトウェアリセットを実行します。 Q2。OPEN構成でセカンダリイメージブートは動作しますか? OPENモードでは、ROMはHABエラーを無視するため、PERSIST_SECONDARY_BOOTを自律的に設定することはありません。 Q3。同じリセットですか、それとも2回目のリセットですか? プライマリブートはHAB認証に失敗します(クローズドモード)---->ROMセットSRC_GPR10[30] = 1---->ソフトウェアリセットを引き起こします。 次のリセットサイクルで、ROMはパーシステントビットを読み取り、それが1であることを確認し、プライマリオフセットではなくセカンダリオフセットからロードします。 Q4。0x400000でバイト同一のコピーか、別途ビルドされたイメージか? IVT/ブートデータフィールドにはフラッシュアドレスではなくRAMアドレスが含まれているため、バイト単位で同一のコピーで十分です。 よろしくお願いいたします。 サラス。
查看全文
サポート要望: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)を使うのが解決策かもしれません。 よろしくお願いいたします。 アルド。
查看全文
IMX95EVK-19-REV-A1 フラッシュの問題 NXP様、 Linuxイメージ(6.18.20_2.0.0/ 6.18.2_1.0.0/6.12.49_2.2.0)を IMX95LP5-19 EVK REV A1のeMMC/SDカードにフラッシュしようとしていますが、 どれも 成功しません。 コマンドプロンプトには[HID(W): LIBUSB_ERROR_PIPE (-9) ] SDPS: boot -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all と表示されます。 IMX95LPD5EVK-19CM:L6.18.2のUUU eMMCフラッシュが失敗(LinuxおよびWindowsでのLIBUSBエラー) 上記のリファレンスでは、公式サイトではA1シリコンは現在のイメージをサポートしていません(6.12.34にはパッチが付IMX95EVKいません)。そこで、適切な画像を含む未公開の公式リンクがあるのか気になっています。 ご返信をお待ちしております。よろしくお願いいたします。 BR/デビッド こちらは参考 文献IMX95LPD5EVK-19CMです:L6.18.2のUUU eMMCフラッシュが失敗(LinuxおよびWindowsでLIBUSBエラー発生) Re: IMX95EVK-19-REV-A1 flash problem A1シリコン:推奨BSPはLF 6.6.52_2.2.xです。 デモイメージL6.6.52_2.2.2_MX95をダウンロードしてください。 そして、imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all イメージを使用します。 先ほど以下のコマンドを確認したところ、正常に動作しました。 uuu.exe -b emmc imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all
查看全文
MTC40F2046S1RC64BD2 この部品番号: MTC40F2046S1RC64BD2がX線に敏感かどうか確認していただけますか? Re: MTC40F2046S1RC64BD2 それは事実ではありません。X線照射は一般的な検査手順であり、損傷を引き起こすことはありません。安全保証のために、適合証明書(COC)を持つ販売者を見つけることをお勧めします。
查看全文
i.MX8M Plus - SPDIF Protocol Implementation Example Hi Team, Could someone pls suggest how to implement and validate SPDIF Protocol in i.MX8M plus? Re: i.MX8M Plus - SPDIF Protocol Implementation Example For the simplest i.MX 8M Plus S/PDIF implementation, use the i.MX Audio Board / MCIMX8M-AUD as the closest NXP reference hardware, not the base i.MX 8M Plus EVK alone. The audio board is documented as supporting i.MX 8M Plus and providing S/PDIF I/O with RCA and TOSLINK connectors, with TOSLINK support up to 192 kHz. Recommended simple approach: Use optical S/PDIF first if possible Easiest hardware path: i.MX8MP SPDIF_OUT → optical TOSLINK transmitter module. For receive: optical TOSLINK receiver module → i.MX8MP SPDIF_IN . This avoids coaxial 75 Ω line-drive, transformer/coupling, and grounding concerns. Use the i.MX 8M Plus S/PDIF pins through IOMUX The i.MX 8M Plus audio subsystem includes SPDIF input and output . The reference manual shows IOMUX options for AUDIOMIX_SPDIF1_OUT and AUDIOMIX_SPDIF1_IN on selectable pads. In Linux, the corresponding IOMUX definitions include MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUT and MX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_IN . If you need coaxial RCA Do not treat the SoC pin like a direct RCA line driver. Add the proper 75 Ω S/PDIF coax output network / coupling per the selected transmitter/interface circuit. Optical is usually the simpler and safer first implementation. Reference material to look at MCIMX8M-AUD / i.MX Audio Board : best NXP reference for S/PDIF I/O with RCA and TOSLINK on the i.MX 8M family. i.MX 8M Plus Reference Manual : pinmux / IOMUX setup for AUDIOMIX_SPDIF1_IN and AUDIOMIX_SPDIF1_OUT . i.MX 8M Plus datasheet : S/PDIF timing parameters are documented, including clock high/low timing. For the simplest design, route AUDIOMIX_SPDIF1_OUT/IN to optical TOSLINK modules and use the MCIMX8M-AUD as the NXP reference point for S/PDIF I/O behavior. Re: i.MX8M Plus - SPDIF Protocol Implementation Example Hi Yipingwang, Could you please guide me with any reference schematics to implement SPDIF in Simplest way. Re: i.MX8M Plus - SPDIF Protocol Implementation Example Use the existing Linux ALSA Audio XCVR / S/PDIF driver on i.MX8M Plus; you normally do not implement the S/PDIF protocol from scratch. The i.MX8M Plus Audio XCVR supports eARC, ARC, and S/PDIF modes, and the Linux S/PDIF support exposes one playback device for Tx and one capture device for Rx through ALSA.  Suggested implementation path: Enable the kernel driver Enable: CONFIG_SND_IMX_SPDIF Menu path: Copy Device Drivers   -> Sound card support     -> Advanced Linux Sound Architecture       -> ALSA for SoC audio support         -> SoC Audio for Freescale i.MX CPUs           -> SoC Audio support for i.MX boards with S/PDIF The documented DT bindings are under Documentation/devicetree/bindings/sound/fsl,spdif.txt and Documentation/devicetree/bindings/sound/imx-audio-spdfif.txt .  Configure the device tree For i.MX8M Plus, use the xcvr audio block and enable the sound card / DAI link. A representative configuration is: sound-xcvr {     compatible = "fsl,imx-audio-card";     model = "imx-audio-xcvr";     pri-dai-link {         link-name = "XCVR PCM";         cpu {             sound-dai = <&xcvr>;         };     }; }; &xcvr {     #sound-dai-cells = <0>;     pinctrl-names = "default";     pinctrl-0 = <&pinctrl_xcvr>;     status = "okay"; }; For Tx pin muxing, one documented example uses MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT .  Check board routing / jumpers If using the NXP audio board, set the physical routing for the intended S/PDIF path. For i.MX8M Plus, J1500=1-2 routes the coaxial connector to i.MX8M Plus, and J1500=4-5 routes the optical connector to i.MX8M Plus.  If routing through CPLD / HDMI card, J2511=1-3 is documented as “i.MX 8M Plus to CPLD to HDMI card.”  Use ALSA / IEC958 correctly The S/PDIF Tx driver supports 32, 44.1, and 48 kHz sample rates, with S16_LE and S24_LE formats; for 24-bit output, the file must use 32 bits per channel frame with only the 24 LSBs valid.  If the path expects IEC958 subframes rather than raw PCM, do the PCM-to-IEC958 conversion in user space, for example using an ALSA PCM plugin.  Validation steps: aplay -l arecord -l Use these to identify the S/PDIF playback / capture card and device IDs. The documentation shows the S/PDIF device appearing as an ALSA card such as imxspdif [imx-spdif], device 0: S/PDIF PCM .  Tx validation: aplay -D hw: , audio48k24S.wav The reference validation method uses an external optical S/PDIF receiver, such as an M-Audio Transit USB sound card with WaveLab, then records the stream externally and plays it back to check correctness.  Rx validation: arecord -D hw: , -c 2 -d 20 -r 48000 -f S24_LE record.wav The sample rate passed to arecord must match the incoming S/PDIF stream sample rate.  For Rx, the application flow is to open the S/PDIF Rx PCM device, wait for the internal DPLL to lock to the input bit stream, get the input sample rate, set channel / format / rate parameters, then prepare and trigger capture.  For protocol-level checks, use: iecset -c iecset is the standard utility documented for setting or dumping IEC958 status bits, and the driver also exposes channel-status handling through the ALSA control interface.  For i.MX8M Plus EVK-style validation, NXP also documents loopback-style Linux testing using the imxaudioxcvr card, for example recording from imxaudioxcvr and playing to wm8960audio : arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \ aplay -Dsysdefault:CARD=wm8960audio In short: enable the i.MX S/PDIF / XCVR ALSA driver, configure the xcvr device tree and board routing, then validate Tx/Rx with aplay , arecord , iecset , and an external optical/coax S/PDIF source or sink.
查看全文
ls1021a eTSEC 送信タイムアウト 私はLS1021A IoTと、このCPUをベースにしたプロトタイプ基板を持っています。どちらの場合も、弊社独自のブートローダーを使用しています。 IOTボードでは完璧に動作しますが、私のボードではイーサネットポートで送信タイムアウトが発生します。数回のpingが送信され、その後送信タイムアウトが発生し、さらにpingが送信されます。このため、TFTPはほとんど利用できません。 もちろん、ハードウェアの違いはあります。私たちのMACはBCM54616Sに接続され、その後LAN9514に接続されています。自動交渉の上限は100FDです。ループバックモードでもTXタイムアウトが発生します。 データを送信するためには、ボードのTBI PHYでビットSGMII_ANビットを設定しなければなりませんでしたが、IOTでは不要でした(IOTは1000FDで交渉可能です)。 なぜTXがこんなに断続的に起こるのか分かりません。この速度制限と関係があるのでしょうか? Re: ls1021a eTSEC tx timeout こんにちは、 100FD SGMIIの場合、プロトタイプ基板上のブートローダーで以下の項目を確認してください。 LS1021AのeTSECをSGMII 100Mbpsに設定する ECNTRL[TBIM] = 1 ECNTRL[SGMIIM] = 1 ECNTRL[R100M] = 1 MACCFG2[I/F Mode] = 01 (10/100モードの場合) LS1021Aのリファレンスマニュアルには、SGMII 100Mbpsの場合、 R100M = 1 設定することが明記されています。 内部のTBI PHYをリセットしプログラムするRMは、SGMIIがTBIレジスタセットを使用していること、そしてSGMIIを含むすべてのインターフェースモードでTBIをリセットすることが重要であると述べています。 SGMII_AN ビットは設定したままにしてください。TBI の SGMII_AN ビットは「1 に設定する必要があります」と記載されています。このビットを設定した後にしか基板が送信しないのは驚くことではありません。このPHY/MACモードのブートローダー初期化が不完全であることを示唆しています。 100 Mbps での 1G スタイルの SGMII AN 動作に頼らないでください。LS1021A では、100 Mbps SGMII 動作時に「SGMII リンクが正常ではありません」というメッセージが表示されたり、リンクのサイクル後に断続的にパケットが送信されないという報告が知られていますが、1G 動作では問題ありません。それは、あなたのTXタイムアウトの正確な根本原因を証明するものではありませんが、100FD SGMIIの設定が有力な容疑者であることを示唆しています。 ループバックの結果が重要です。もし「ループバックモード」が外部PHYループバックやSGMII側ループバックであれば、100FDのSGMII/TBIセットアップは関与可能です。内部MAC/eTSECループバックの場合、外部BCM54616S/LAN9514パスはほとんど関係ないので、eTSECの初期化、ディスクリプタリングの処理、キャッシュの一貫性、およびTXの停止/エラー状態に焦点を当てます。 デバッグを行うには、タイムアウトが発生したときにeTSEC TXの停止状態を確認してください。RMは、eTSECがTxBDリングからの送信フレームを処理しなくなったときに送信停止ビットを設定すると述べています。繰り返し可能な原因には、バスエラー、無効なBD/データアドレス、修正不能なBD/データ読み取りエラー、長さ 0 の Ready = 1 などのTxBDプログラミングエラーなどがあります。また、見ているかどうかも確認してください IEVENT_BSY ;NXPの資料では、BSYはバッファ不足やソフトウェアがBDリングに十分速く対応できないことによるRXフレームのドロップと説明されており、これは純粋なSGMIIの電気的症状ではなくソフトウェア/BDリングの症状です。 推奨される分離シーケンス: 1. 必要に 応じて、 外部 PHY を 100FD に 強制し 、 銅線に対する自動ネゴシエーションを無効にします 。2. LS1021Aの MAC / eTSEC を SGMII 100Mbps に 強制的に設定する : TBIM = 1 、 SGMIIM = 1 、 R100M = 1 、 MACCFG2 I / F モード = 10 / 100。3. SGMII モードを設定した後、 TBIを リセット / 再初期化します 。4. TBI SGMII_AN = 1 に設定します 。 5. TBI リンク / AN ステータス 、 eTSEC ECNTRL / MACCFG2 、 および PHY SGMII 側 ステータス を確認します 。6.タイムアウト時に、 IEVENT 、 TXハルトレジスタ、 DMAステータス、およびTXBDリングの内容をダンプします。 敬具 Re: ls1021a eTSEC tx timeout 言い忘れていましたが、私のポートはSGMIIモードに設定されています。 Re: ls1021a eTSEC tx timeout こんにちは、 詳細な調査結果をありがとうございます。ご指摘いただいた回避策(1ミリ秒の遅延、手動によるDMAフラッシュ、 dma-coherent 削除)の組み合わせは、キャッシュエイリアスの問題の典型的なパターンです。以下に、根本原因の説明と推奨される解決方法を示します。 根本原因:TX記述子領域上のキャッシュされた仮想エイリアス LS1021A ENET DMAはキャッシュ整合性のないバス・マスタであり、CPUキャッシュの可視性を持たずにDDRを直接読み込みます。LS1021A上のgianfarの正しい運用モデルは、非コヒーレントなソフトウェア管理モデルです。すなわち、ディスクリプタをキャッシュされていないメモリに割り当て、CPUがディスクリプタフィールドを更新するたびに明示的な dma_sync_* 呼び出しを行います。 LPAEの変更によって最も可能性が高いのは、記述子の物理アドレス範囲のページテーブルエントリに、誤ったキャッシュ属性(デバイスまたは通常のキャッシュ不可ではなく、通常のライトバック)が付与されたことです。これにより、同じ物理メモリに対して異なるキャッシュ性を持つ2つの仮想エイリアスが作成されます。割り当てパス( dma_alloc_noncoherent 経由)はキャッシュされていない状態をマッピングしますが、send関数のパケットごとのTXディスクリプタ更新パスはキャッシュされたエイリアス経由でアクセスします。CPUは更新されたディスクリプタフィールドをキャッシュラインに書き込みますが、それらはDDRに到達せず、ENET DMAは古いデータを読み取ってアンダーランを起こします。 なぜあなたの3つの回避策はすべて同じ欠陥を隠蔽しているのか 1 ms遅延/メッセージ挿入:低負荷時にCPU書き込みバッファが自然に消耗する十分なレイテンシを追加します。タイミング依存で、トラフィックや周波数の変化により故障します。 send 関数で dma_flush 手動で指定すると、DMA がディスクリプタを読み取る前に、PoC へのキャッシュのクリーンアップが強制されます。これは正しい動作ですが、領域が実際にキャッシュされていない場合は不要です。 enet デバイス ノードから dma-coherent 削除すると、カーネルは送信前に各 TX ディスクリプタに対して dma_map_single() / dma_sync_single_for_device() を呼び出し、明示的にキャッシュをクリアします。これも正しく、LS1021A-IOT が送信パスのフラッシュなしで確実に動作した理由を説明しています。 送信パスのフラッシュがないことが、欠けている要素です。LS1021A-IOTは dma-coherent 削除しても動作しました。これは、カーネルのDMAマッピングレイヤーが同期を自動的に挿入したためです。一方、プロトタイプにはそのパスがありません。LPAEの変更により、同期を再導入することなく記述子領域のキャッシュ属性が変更されたためです。 DDR3LとDDR4/周波数の違い これは根本原因ではありません。異なるDRAMの種類や周波数が書き込みレイテンシやバッファのドレインタイミングを変えるため、プロトタイプでは故障がより目立つのですが、根本的な欠陥はアーキテクチャ的なもので、十分な負荷がかかると両方の基板に存在します。 推奨される修正方法 正しく、かつ矛盾のない解決策は、以下の2つを組み合わせることです。 enetデバイスノードから dma-coherent 離しておきましょう(非コヒーレントモデル)。これにより、カーネルDMAレイヤーは、 dma_alloc_noncoherent を介して割り当てられたディスクリプタのDMA所有権が転送される前に、 dma_sync_single_for_device() 自動的に発行します。 TX 送信パスにおいて、各パケットに TX 記述子フィールド ( status 、 data_length 、 data_pointer ) が書き込まれる箇所に、明示的な dma_sync_single_for_device() 呼び出しを追加します。これは手動で追加したフラッシュですが、 TDAR を書く前に正式には dma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE) として配置する必要があります。これにより、MMUがディスクリプタ領域をどのように属性付けしても、モデルは明示的かつ正確になります。 別途、ENET記述子に使用される物理アドレス範囲に割り当てられた AttrIndx / TEX+C+B フィールドについて、LPAE MMUライブラリの変更を監査します。ディスクリプタプールは、Device-nGnRnE(厳密な順序付け)またはNormal Non-cacheableとしてマッピングする必要があります。Normal Writebackは使用しないでください。カーネルの ptdump デバッグインターフェースで、割り当て後にディスクリプタプールの仮想アドレスを確認することで、実際に使われている属性を検証できます。 あなたが追加したDMAフラッシュは回避策ではなく、正しい仕組みです。本当の欠陥は、そもそも送信パスにそれが存在していなかったことであり、LPAEの変更によってその領域の実効的なキャッシュ可能性が変わったため、この欠陥が露呈した。   よろしくお願いします。 Re: ls1021a eTSEC tx timeout 送信機能にメッセージを追加したり、1ミリ秒の遅延を設けたりすることで、データの損失なく正しく転送することが可能になります。 送信関数内のTXディスクリプタにDMAフラッシュを追加したところ、改善されました。ただし、ディスクリプタはキャッシュされていないメモリに割り当てられるため、これは必要ないはずです。LPAEサポートを追加したMMUライブラリの欠陥かもしれません。 そういえば、ずいぶん前にenetデバイスノードのdma-coherentプロパティを削除したところ、LS1021A-IOTが動作するようになったことを思い出しました。これは、ディスクリプタ用にキャッシュされていないメモリを割り当てながら、DMAフラッシュを強制的に実行します。しかし、送信関数には、各パケットのTX記述子を更新するキャッシュフラッシュ機能がありませんでした。なぜ私のプロトタイプでは動作しないのか分かりません(周波数の違い、DDR3LとDDR4の違い,...)
查看全文
i.MX8M Plus - Sony Philips数字接口格式(SPDIF) 协议实现示例 大家好, 请问有人能指导一下如何在 i.MX8M plus 中实现和验证 Sony Philips数字接口格式(SPDIF) 协议吗? Re: i.MX8M Plus - SPDIF Protocol Implementation Example 对于最简单的 i.MX 8M Plus S/PDIF 实现,请使用 i.MX 音频板 / MCIMX8M-AUD 作为最接近的 NXP 参考硬件,而不是仅使用基本的 i.MX 8M Plus EVK。音频板的文档显示其支持 i.MX 8M Plus,并提供带有 RCA 和 TOSLINK 连接器的 S/PDIF I/O,TOSLINK 支持高达 192 kHz。 推荐的简易方法: 如果可以,请优先使用光纤 S/PDIF 接口。 最简单的硬件路径:i.MX8MP SPDIF_OUT → 光纤 TOSLINK 发射器模块。 接收:光纤 TOSLINK 接收器模块 → i.MX8MP SPDIF_IN。 这样就避免了同轴 75 Ω 线路驱动、变压器/耦合和接地问题。 通过 IOMUX 使用 i.MX 8M Plus 的 S/PDIF 引脚 i.MX 8M Plus 音频子系统包括Sony Philips数字接口格式(SPDIF) 输入和输出。 参考手册显示了可选择的焊盘上的 AUDIOMIX_SPDIF1_OUT 和 AUDIOMIX_SPDIF1_IN 的 IOMUX 选项。 在 Linux 中,相应的 IOMUX 定义包括 MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUT 和 MX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_IN 。 如果您需要同轴RCA接口, 不要将 SoC 引脚当作直接 RCA 线路驱动器使用。 根据所选的发射器/接口电路,添加合适的 75 Ω S/PDIF 同轴输出网络/耦合。 光学方式通常是更简单、更安全的首选方案。 可供参考的资料 MCIMX8M-AUD / i.MX 音频板:NXP 为 i.MX 8M 系列提供 S/PDIF I/O 的最佳参考级产品,带有 RCA 和 TOSLINK 接口。 i.MX 8M Plus 参考手册:AUDIOMIX_SPDIF1_IN 和 AUDIOMIX_SPDIF1_OUT 的 pinmux / IOMUX 设置。 i.MX 8M Plus 数据手册:记录了 S/PDIF 时序参数,包括时钟高/低时序。 对于最简单的设计,将 AUDIOMIX_SPDIF1_OUT/IN 连接到光纤 TOSLINK 模块,并使用 MCIMX8M-AUD 作为 NXP S/PDIF I/O 行为的参考点。 Re: i.MX8M Plus - SPDIF Protocol Implementation Example 王一平您好, 请问能否提供一些参考电路图,以便我以最简单的方式实现Sony Philips数字接口格式 (SPDIF) 功能? Re: i.MX8M Plus - SPDIF Protocol Implementation Example 在 i.MX8M Plus 上使用现有的 Linux ALSA Audio XCVR / S/PDIF 驱动程序;通常情况下,您不会从头开始实现 S/PDIF 协议。i.MX8M Plus 音频 XCVR 支持 eARC、ARC 和 S/PDIF 模式,Linux S/PDIF 支持通过 ALSA 公开一个用于 Tx 的播放设备和一个用于 Rx 的捕获设备。 建议的实施路径: 启用内核驱动程序: 配置_SND_IMX_SPDIF 菜单路径: 复制 设备驱动程序 -> 声卡支持 -> 高级 Linux 音频架构 -> ALSA 用于 SoC 音频支持 -> 适用于飞思卡尔 i.MX CPU 的 SoC 音频           -> 为带有 S/PDIF 的 i.MX 板提供 SoC 音频支持。 记录的 DT 绑定位于 Documentation/devicetree/bindings/sound/fsl,Sony Philips数字接口格式(SPDIF).txt 和 Documentation/devicetree/bindings/sound/imx-audio-Sony Philips数字接口格式(SPDIF)if.txt 下。 配置 i.MX8M Plus 的设备树,使用 xcvr 音频模块并启用声卡/DAI 链路。典型的配置如下: sound-xcvr { 兼容 = "fsl,imx-audio-card"; 型号 = "imx-audio-xcvr"; pri-dai-link { 链接名称 = "XCVR PCM"; 中央处理器 { sound-dai = <&xcvr>;         }; }; }; &xcvr { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_xcvr>; 状态 = "正常"; }; 对于 Tx 引脚复用,一个有记录的示例使用 MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT。 检查电路板布线/跳线。如果使用 NXP 音频板,请设置预期 S/PDIF 路径的物理布线。对于 i.MX8M Plus,J1500=1-2 将同轴连接器连接到 i.MX8M Plus,J1500=4-5 将光纤连接器连接到 i.MX8M Plus。如果通过 CPLD / HDMI 卡进行路由,则 J2511=1-3 的文档为“i.MX 8M Plus 到 CPLD 到 HDMI 卡”。 正确使用 ALSA / IEC958 S/PDIF 发送驱动程序支持 32、44.1 和 48 kHz 采样率,以及 S16_LE 和 S24_LE 格式;对于 24 位输出,文件必须使用每通道帧 32 位,并且只有 24 个最低有效位有效。如果路径需要的是 IEC958 子帧而不是原始 PCM,则在用户空间中进行 PCM 到 IEC958 的转换,例如使用 ALSA PCM 插件。 验证步骤: aplay -l 记录 -l 使用这些信息来识别 S/PDIF 播放/采集卡和设备 ID。文档显示 S/PDIF 设备显示为 ALSA 卡,例如 imxspdif [imx-spdif],设备 0:S/PDIF PCM。 交易验证: aplay -D hw: , audio48k24S.wav 参考验证方法使用外部光纤 S/PDIF 接收器,例如带有 WaveLab 的 M-Audio Transit USB 声卡,然后外部录制音频流并回放以检查正确性。 处方验证: arecord -D hw: , -c 2 -d 20 -r 48000 -f S24_LE record.wav 传递给 arecord 的采样率必须与输入的 S/PDIF 流采样率相匹配。对于 Rx,应用程序流程是打开 S/PDIF Rx PCM 设备,等待内部 DPLL 锁定到输入比特流,获取输入采样率,设置通道/格式/速率参数,然后准备并触发捕获。 对于协议级检查,请使用: iecset -c iecset 是用于设置或转储 IEC958 状态位的标准实用程序,并且该驱动程序还通过 ALSA 控制接口公开通道状态处理。 对于 i.MX8M Plus EVK 风格的验证,NXP 还记录了使用 imxaudioxcvr 卡进行环回式 Linux 测试的方法,例如从 imxaudioxcvr 录制音频并播放到 wm8960audio: arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \ aplay -Dsysdefault:CARD=wm8960audio 简而言之:启用 i.MX S/PDIF / XCVR ALSA 驱动程序,配置 xcvr 设备树和板路由,然后使用 aplay、arecord、iecset 和外部光纤/同轴 S/PDIF 源或接收器验证 Tx/Rx。
查看全文
Marking details Please advise the meaning of marking 04 01 616 for MPN : PCA9553DP/01,118
查看全文