Unifiのようなソフトウェアではなく、OpenWrtを使ったことを後悔していますか？ 私の無知をお許しください。UnifiではなくOpenWrtを使ったことを後悔していますか？OpenWrtを使って、自宅の実験室用にルーターを設定しています。多くのことを学びつつありますが、時間がかかるので、Unifiのようなきれいな結果には絶対にならないでしょう。 OpenWrtで一番気に入っているのは、安価なデバイスでケーキを設定できて、1Gbpsのルーティングを代わりに行ってくれることです。また、自分のニーズに合わせてUnboundをカスタマイズできるのは素晴らしいです。 Re: Do you regret using OpenWrt instead of something like Unifi? こんにちは、 どのプロセッサを使っていますか? よろしくお願いします。

The PN7220's card reading performance is excessive. The PN7220 project has excessive card reading performance; the V-card reading range is ≥150mm. Adjusting ARC and DGRM_BBA only reduces the reading range to around 110mm. Due to the need to pass EMVCo RR2, the maximum voltage can currently only be reduced to 4.5V. Are there any other parameters that can reduce card reader performance? Thank you. Re: PN7220 读卡性能过剩 Here, the MAX_READ voltage is set to 4.5V (0x07), then DPC is applied. The _EMVCo switch is not working; after switching, the maximum voltage is still 5.7V (the forum shows the maximum voltage is 4.5V). Is this normal? Re: PN7220 读卡性能过剩 Hello @mark_tang Adjust the antenna matching impedance to 20~22 Ω. This requires hardware modification; try again. Re: PN7220 读卡性能过剩 After adjusting the target current to 200mA, the V-card's performance remained unchanged when the current was reduced to 100mA and then further reduced. Re: PN7220 读卡性能过剩 The complete version was not released to us by this client. Re: PN7220 读卡性能过剩 Hello @mark_tang Another option is to adjust the matching impedance to 20~21 Ω. Re: PN7220 读卡性能过剩 Hello @mark_tang The target current can be adjusted to 200mA, give it a try! Furthermore, the schematic diagram does not only show the antenna section, but also the complete 7220 design. Re: PN7220 读卡性能过剩 The target current is 240mA. The attached file is the debugged XML file. Re: PN7220 读卡性能过剩 I noticed that the latest Cockpit allows setting different target currents (shared across tables). Will this affect the EMVCo RR2 test, or does the system have a recognition mechanism that automatically switches between them? Re: PN7220 读卡性能过剩 Hello @mark_tang Could you please provide the DPC table, the antenna smitch chart, and the schematic diagram? What is the target? What is the current target? Re: PN7220 读卡性能过剩 DPC has been debugged, but it doesn't help reduce card reader performance. Currently, client requirements stipulate performance cannot exceed 75mm, and it's currently exceeding that by 50%. Re: PN7220 读卡性能过剩 Hello @mark_tang  Also, you can enable  and calibratie DPC, please try. Re: PN7220 读卡性能过剩 Hello @mark_tang  it's normal.

PN7220 读卡性能过剩 PN7220 项目读卡性能过剩，V卡性能≥150mm，调整ARC ，DGRM_BBA，性能只能降到110mm左右；由于需要过EMVCo RR2 ，目前最大电压只能降到4.5V 请问是否还有其他参数可以把读卡性能降下来，谢谢 Re: PN7220 读卡性能过剩 这边设置0x07 MAX_READ电压4.5，再DPC _EMVCo这边没有生效，切换后，最大电压还是5.7V（forum这边max电压生效为4.5V），这个是正常的吗 Re: PN7220 读卡性能过剩 Hello @mark_tang  将天线匹配阻抗调整到20~22 Ω. 这个需要修改硬件，再试试吧 Re: PN7220 读卡性能过剩 Forum 目标电流调整到200mA后，V卡降到100，再进一步降低电流，V卡性能没有变化 Re: PN7220 读卡性能过剩 完整的，这个客户没有释放给我们 Re: PN7220 读卡性能过剩 Hello @mark_tang  还有一个方案可以将匹配阻抗调整到20~21 Ω. Re: PN7220 读卡性能过剩 Hello @mark_tang  目标电流可以调整到200mA，试试！ 另外，原理图不是仅天线部分，完整的7220设计部分 Re: PN7220 读卡性能过剩 目标电流240mA,附件是调试后的xml Re: PN7220 读卡性能过剩 我看最新的cockpit里目标电流可设置不同的（table共用），这个会影响到EMVCo RR2测试吗，还是系统有识别机制，自动切换 Re: PN7220 读卡性能过剩 Hello @mark_tang  那么您提供下DPC table，天线的smitch chart 和原理图！ 目标是多少？当前是多少？ Re: PN7220 读卡性能过剩 DPC已调试，对降读卡性能没什么帮助，现在客户端要求性能不能超过75mm，目前超了50% Re: PN7220 读卡性能过剩 你好@mark_tang 另外，您还可以启用并校准DPC，请尝试一下。 Re: PN7220 读卡性能过剩 你好@mark_tang 这是正常的。

[S32K358] 适用于 HSM、RTD 的 s32k358 版本 亲爱的恩智浦 s32k358 上的 HSM 和 RTD 版本是什么？ 谢谢， 布莱恩 Re: [S32K358] Version for HSM, RTD on s32k358 嗨@bryan_hong 建议使用最新版本的RTD和HSE固件。这意味着： - S32K358 的 HSE 固件版本 0.2.55.0 - RTD 7.xx 如发行说明中所述，RTD 7.xx 中的 Crypto 驱动程序已使用 HSE 固件 0.2.55.0 进行测试。 此致， Lukas Re: [S32K358] Version for HSM, RTD on s32k358 嗨，卢卡斯。 谢谢你的评论，这对我很有帮助。 谢谢， 布莱恩    

你后悔使用 OpenWrt 而不是像 Unifi 这样的固件吗？ 请原谅我的无知，但您是否后悔使用 OpenWrt 而不是 Unifi？我正在为我的家庭实验室配置一台运行 OpenWRT 的路由器。我确实学到了很多东西，别误会，但这太耗时了，而且最终结果肯定不会像 Unifi 那样呈现一个漂亮的界面。 我最喜欢 OpenWrt 的一点是，我可以在一台廉价设备上配置 Cake，它就能帮我完成 1Gbps 的路由。此外，能够根据我的需求定制 Unbound 也非常棒。 Re: Do you regret using OpenWrt instead of something like Unifi? 你好， 你使用的是哪款处理器？ 此致

i.MX 95 NNStreamer C++ Demo NPU Issues Environment | Component | Detail | |-----------|--------| | Board | i.MX 95 | | BSP | lf-6.12.49-2.2.0 | | Kernel | Linux ... 6.12.49-lts-next-gbf3cf0324593 #1 SMP PREEMPT Tue Jun 16 03:46:26 UTC 2026 aarch64 | | NNStreamer | 2.4.2 | | TensorFlow Lite | 2.19.0 | | Neutron Delegate | libneutron_delegate.so reports v1.0.0-f24d08e5, non-zerocp, built Nov 12 2025 | | nnstreamer-examples | v1.6 (SRCREV 062ebd1) and v1.9 (SRCREV 37d3d86) — same behavior | | Camera | OV5640 MIPI via libcamera (imx8-isi), camera ID: /base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c | Binaries from meta-nxp-demo-experience/recipes-examples/imx-nnstreamer-examples/imx-nnstreamer-examples.bb, installed at /opt/gopoint-apps/scripts/machine_learning/nnstreamer/. Models All models are from the Yocto gopoint-base-apps recipe (downloads.json, lf-6.12.49_2.2.0 branch), hosted at: https://github.com/nxp-imx-support/nxp-demo-experience-assets/raw/lf-6.12.49_2.2.0/models/ Models on target at /opt/gopoint-apps/scripts/machine_learning/nnstreamer/downloads/models/: | Task | CPU model | NPU model | |------|-----------|-----------| | Face Detection | face-detection/ultraface_slim_uint8_float32.tflite | face-detection/ultraface_slim_uint8_float32_neutron.tflite | | Object Detection | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite | | Classification | classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite | classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite | Metadata from same source: labels_mobilenet_quant_v1_224.txt, coco_labels_list.txt, box_priors.txt. Required Environment Variables OV5640 on i.MX 95 requires libcamera ISI: export CAMERA_BACKEND=libcamera export LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c'--- Issue 1: Face Detection NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --backend NPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=320,height=240,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=face_filter \ ! tensor_sink name=tsink_fd \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 ! cairooverlay name=cairooverlay \ ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 2 nodes delegated out of 49 nodes with 2 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. [libcamera v0.0.0+6194-lf-6.12.49-2.2.0] [ov5640 pipeline: ov5640 -> csidev-4ad30000.csi -> formatter@20 -> crossbar] Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed from NULL to READY. DEBUG: Pipeline state changed from READY to PAUSED. DEBUG: Pipeline state changed from PAUSED to PLAYING. Result: Bounding boxes garbled. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --backend CPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same camera pipeline, same imxvideoconvert_g2d] ... tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ custom=Delegate:XNNPACK,NumThreads:6 ... DEBUG: Pipeline state changed ... PLAYING. Result: ✅ Bounding boxes accurate. Same pipeline, same camera, same imxvideoconvert_g2d YUY2→RGB conversion. Only difference: quantized .tflite + XNNPACK vs _neutron.tflite + neutron delegate. --- Issue 2: Object Detection (SSD MobileNetV2) NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --backend NPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=300,height=300,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=detection_filter \ ! tensor_decoder name=tensor_decode_bounding_boxes_1 mode=bounding_boxes option1=mobilenet-ssd \ option2=downloads/models/object-detection/coco_labels_list.txt \ option3=downloads/models/object-detection/box_priors.txt \ option4=640:480 option5=300:300 ! imxvideoconvert_g2d ! mix.sink_0 \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 ! mix.sink_1 \ imxcompositor_g2d name=mix sink_0::zorder=2 sink_1::zorder=1 latency=20000000 min-upstream-latency=20000000 \ ! cairooverlay name=perf ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 1 nodes delegated out of 26 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed area completely black. Bounding boxes inaccurate. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --backend CPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same pipeline, same imxvideoconvert_g2d, same imxcompositor_g2d, XNNPACK delegate] DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed area still completely black (same as NPU). Bounding boxes correct. Black screen in both CPU and NPU. Face detection and classification (which do not use imxcompositor_g2d) display normal camera feed. --- Issue 3: Classification (MobileNetV1) NPU mode CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --backend NPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf time Pipeline log: INFO: Start app... DEBUG: libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ! video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 ! queue ! tee name=t \ t. ! queue name=thread-nn max-size-buffers=2 leaky=2 \ ! imxvideoconvert_g2d name=scale_csc_g2d_0 ! video/x-raw,width=224,height=224,format=RGB \ ! tensor_converter ! tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=classification_filter \ ! tensor_decoder name=tensor_decode_labeling_1 mode=image_labeling \ option1=downloads/models/classification/labels_mobilenet_quant_v1_224.txt ! overlay.text_sink \ t. ! queue name=thread-img max-size-buffers=2 leaky=2 \ ! textoverlay name=overlay font-desc="Sans, 24" valignment=baseline halignment=center \ ! imxvideoconvert_g2d ! cairooverlay name=perf \ ! fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink INFO: NeutronDelegate delegate: 1 nodes delegated out of 4 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, non-zerocp. Camera camera.cpp:1215 configuring streams: (0) 640x480-YUYV/Unset DEBUG: Pipeline state changed ... PLAYING. Result: Camera feed normal. Label consistently wrong. CPU mode — same pipeline, different model and delegate CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --backend CPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf time Log: INFO: Start app... INFO: Created TensorFlow Lite XNNPACK delegate for CPU. DEBUG: [same pipeline, same imxvideoconvert_g2d, XNNPACK delegate] DEBUG: Pipeline state changed ... PLAYING. Result: ✅ Camera feed normal. Label correct and responsive to camera scene. --- Summary In all three demos, CPU and NPU use the same camera pipeline, same imxvideoconvert_g2d YUY2→RGB conversion, same GStreamer pipeline structure. The only difference is: | Variable | CPU test | NPU test | |----------|----------|----------| | Model | *.tflite (quantized) | *_neutron.tflite | | Delegate | XNNPACK (Delegate:XNNPACK) | neutron (Delegate:External,ExtDelegateLib:libneutron_delegate.so) | Results: | Demo | CPU (quantized .tflite + XNNPACK) | NPU (_neutron.tflite + neutron) | |------|:---:|:---:| | Face Detection — bounding boxes | ✅ correct | ❌ garbled | | Object Detection — bounding boxes | ✅ correct | ❌ inaccurate | | Classification — label | ✅ correct | ❌ wrong | Object detection also shows black camera feed in both CPU and NPU. This demo uses imxcompositor_g2d for display; face detection and classification use cairooverlay/textoverlay and display normally. Re: i.MX 95 NNStreamer C++ Demo NPU Issues Hi @Chavira : The Board Support Package (BSP) version is 6.12.49. I built nxp-nnstreamer-examples (SRCREV: 062ebd1) separately via Yocto, then deployed the compiled debs onto the target board. Instead of launching the demos via the GoPoint application, I manually downloaded the model files according to the accompanying downloads.json  and ran the programs using the commands mentioned earlier. Re: i.MX 95 NNStreamer C++ Demo NPU Issues Hi @BIG_FLY,  Thanks for the information regarding the GoPoint demos. Could you please clarify how you are running the demos? Are you running them directly using the GoPoint application, or did you cross compile them yourself? Could you describe step by step how you are executing the demos on your side? Are you using BSP version 6.12.49? Which board are you using? This information will help us better understand your setup and identify any potential issues. Best regards, Chavira

i.MX 95 NNStreamer C++ 演示 NPU 问题 环境 | 元器件 | 细节 | |-----------|--------| | 主板 | i.MX 95 | | 电路板支持包。 | lf-6.12.49-2.2.0 | | 内核 | Linux ... 6.12.49-lts-next-gbf3cf0324593 #1 SMP PREEMPT 2026年6月16日星期二 03:46:26 UTC aarch64 | | NNStreamer | 2.4.2 | | TensorFlow Lite | 2.19.0 | | Neutron 委托 | libneutron_delegate.so 报告版本为 v1.0.0-f24d08e5，非零cp，构建于 2025 年 11 月 12 日 | | nnstreamer-examples | v1.6 (SRCREV 062ebd1) 和 v1.9 (SRCREV 37d3d86) — 行为相同 | |相机 | OV5640 MIPI 通过 libcamera (imx8-isi)，相机 ID：/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c | 从 meta-nxp-demo-experience/配方示例/imx-nnstreamer-examples/imx-nnstreamer-examples.bb 获取二进制文件，安装在 /opt/gopoint-apps/scripts/machine_learning/nnstreamer/。 模型 所有模型均来自 Yocto gopoint-base-apps 配方（downloads.json，lf-6.12.49_2.2.0 分支），托管于： https://github.com/nxp-imx-support/nxp-demo-experience-assets/raw/lf-6.12.49_2.2.0/models/ 目标模型位于 /opt/gopoint-apps/scripts/machine_learning/nnstreamer/downloads/models/： | 任务 | CPU 型号 | NPU 型号 | |------|-----------|-----------| | 人脸检测 | face-detection/ultraface_slim_uint8_float32.tflite | face-detection/ultraface_slim_uint8_float32_neutron.tflite | | 目标检测 | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite | object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite | | 分类 | classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite | classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite | 来自同一来源的元数据：labels_mobilenet_quant_v1_224.txtcoco_labels_list.txt，box_priors.txt。 必需的环境变量 i.MX 95 上的 OV5640 需要 libcamera ISI： export CAMERA_BACKEND=libcamera export LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c'--- 问题 1：人脸检测 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --后端 NPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=320,height=240,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=face_filter \ ！张量接收器名称=tsink_fd \ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 ！cairooverlay 名称=cairooverlay \ ！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：49 个节点中有 2 个节点被委托，共 2 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 [libcamera v0.0.0+6194-lf-6.12.49-2.2.0] [ov5640 管道：ov5640 -> csidev-4ad30000.csi -> formatter@20 -> crossbar] 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态从 NULL 变为 READY。 调试：管道状态从就绪变为暂停。 调试：管道状态从暂停变为播放。 结果：边界框错乱。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/face_detection/example_face_detection_tflite \ --后端 CPU \ --model_path downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试信息：[相同的相机流程，相同的 imxvideoconvert_g2d] ... tensor_converter！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/face-detection/ultraface_slim_uint8_float32.tflite \ custom=Delegate:XNNPACK,NumThreads:6 ... 调试：管道状态已更改……正在播放。 结果： ✅ 边界框准确。 相同的流程，相同的摄像机，相同的 imxvideoconvert_g2d YUY2→RGB 转换。唯一区别：量化的 .tflite+ XNNPACK 与 _neutron.tflite + neutron 委托。 --- 问题 2：目标检测（SSD MobileNetV2） 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --后端 NPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=300,height=300,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=detection_filter \ ！tensor_decoder name=tensor_decode_bounding_boxes_1 mode=bounding_boxes option1=mobilenet-ssd \ option2=downloads/models/object-detection/coco_labels_list.txt \ option3=downloads/models/object-detection/box_priors.txt \ 选项4=640:480 选项5=300:300 ！imxvideoconvert_g2d！mix.sink_0 \ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 ！mix.sink_1 \ imxcompositor_g2d name=mix sink_0::zorder=2 sink_1::zorder=1 latency=20000000 min-upstream-latency=20000000 \ ！cairooverlay 名称=perf！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：26 个节点中有 1 个节点被委托，共 1 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态已更改……正在播放。 结果：摄像头画面区域完全黑屏。边界框不准确。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/object_detection/example_detection_mobilenet_ssd_v2_tflite \ --后端 CPU \ --model_path downloads/models/object-detection/ssdlite_mobilenet_v2_coco_quant_uint8_float32_no_postprocess.tflite \ --labels_path downloads/models/object-detection/coco_labels_list.txt \ --boxes_path downloads/models/object-detection/box_priors.txt \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试：[相同的管道，相同的 imxvideoconvert_g2d，相同的 imxcompositor_g2d，XNNPACK 代理] 调试：管道状态已更改……正在播放。 结果：摄像头画面区域仍然完全是黑色的（与 NPU 相同）。边界框正确。 CPU和NPU均出现黑屏。人脸检测和分类（不使用 imxcompositor_g2d）显示正常的摄像头画面。 --- 问题 3：分类（MobileNetV1） 神经网络处理单元模式 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --后端 NPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf 时间 管道日志： 信息：启动应用程序... 调试：libcamerasrc name=cam_src camera-name=/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c \ ！video/x-raw,width=640,height=480,framerate=30/1,format=YUY2 !队列 ！tee name=t \ t.！队列名称=thread-nn 最大缓冲区大小=2 泄漏=2 \ ！imxvideoconvert_g2d name=scale_csc_g2d_0 ！video/x-raw,width=224,height=224,format=RGB \ ！张量转换器！tensor_filter latency=1 framework=tensorflow-lite \ model=downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32_neutron.tflite \ custom=Delegate:External,ExtDelegateLib:libneutron_delegate.so name=classification_filter \ ！张量解码器名称=tensor_decode_labeling_1 模式=图像标注 \ option1=downloads/models/classification/labels_mobilenet_quant_v1_224.txt ！overlay.text_sink\ t.！队列名称=thread-img 最大缓冲区大小=2 泄漏=2 \ ！textoverlay name=overlay font-desc="Sans, 24" valignment=baseline halignment=center \ ！imxvideoconvert_g2d！cairooverlay name=perf \ ！fpsdisplaysink name=img_tensor text-overlay=false video-sink=waylandsink 信息：NeutronDelegate 委托：4 个节点中有 1 个节点被委托，共 1 个分区。 信息：Neutron 委托版本：v1.0.0-f24d08e5，非零cp。 相机 camera.cpp:1215配置流：（0）640x480-YUYV/未设置 调试：管道状态已更改……正在播放。 结果：摄像头画面正常。标签始终错误。 CPU 模式——相同的流水线，不同的模型和委托 CAMERA_BACKEND=libcamera \ LIBCAMERA_CAM_DEVICE='/base/soc/bus@42000000/i2c@42530000/ov5640_mipi@3c' \ /opt/gopoint-apps/scripts/machine_learning/nnstreamer/classification/example_classification_mobilenet_v1_tflite \ --后端 CPU \ --model_path downloads/models/classification/mobilenet_v1_1.0_224_quant_uint8_float32.tflite \ --labels_path downloads/models/classification/labels_mobilenet_quant_v1_224.txt \ --display_perf 时间 日志： 信息：启动应用程序... 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 调试信息：[相同的管道，相同的 imxvideoconvert_g2d，XNNPACK 代理] 调试：管道状态已更改……正在播放。 结果： ✅ 摄像头画面正常。标签正确且能根据摄像机画面做出响应。 --- 摘要 在这三个演示中，CPU 和 NPU 都使用相同的相机管线、相同的 imxvideoconvert_g2d YUY2→RGB 转换以及相同的 GStreamer 管线结构。唯一的区别在于： | 变量 | CPU 测试 | NPU 测试 | |----------|----------|----------| | 模型 | *.tflite（量子化） | *_neutron.tflite | | 委托 | XNNPACK (委托:XNNPACK) | neutron (委托:External,ExtDelegateLib:libneutron_delegate.so)| 结果： | 演示 | CPU（量化 .tflite）+ XNNPACK) | NPU (_neutron.tflite + neutron) | |------|:---:|:---:| 人脸检测——边界框 | ✅ 正确 | ❌ 乱码 | | 目标检测 — 边界框 | ✅ 正确 | ❌ 不准确 | | 分类 — 标签 | ✅ 正确 | ❌ 错误 | 目标检测结果显示，CPU 和 NPU 中的摄像头画面均为黑色。此演示使用 imxcompositor_g2d 进行显示；人脸检测和分类使用 cairooverlay/textoverlay 并正常显示。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues 嗨@Chavira ： 板级支持包（BSP）版本为6.12.49 。我通过 Yocto 单独构建了nxp-nnstreamer-examples (SRCREV: 062ebd1 )，然后将编译好的 deb 部署到目标板上。我没有通过 GoPoint 应用程序启动演示程序，而是根据随附的downloads.json文件手动下载了模型文件。并使用前面提到的命令运行程序。 Re: i.MX 95 NNStreamer C++ Demo NPU Issues 嗨@BIG_FLY ， 感谢您提供的有关 GoPoint 演示的信息。 请问您能否详细说明一下您是如何运行演示的？ 您是直接使用 GoPoint 应用程序运行这些程序，还是自己交叉编译的？ 您能否一步一步地描述一下您那边是如何进行演示的？ 您使用的是 电路板支持包。 版本 6.12.49 吗？ 你用的是哪款板？ 这些信息将有助于我们更好地了解您的设备配置并发现任何潜在问题。 此致， 查维拉

[S32K358] HSM、RTD対応バージョン（S32K358） 親愛なるNXP s32k358におけるHSM、RTDのバージョンは何ですか？ ありがとう、 ブライアン Re: [S32K358] Version for HSM, RTD on s32k358 こんにちは、 @bryan_hong さん。 RTDおよびHSEファームウェアは最新バージョンを使用することをお勧めします。つまり、次のようになるということです。 - S32K358用HSEファームウェア バージョン0.2.55.0 - RTD 7.xx リリースノートにもあるように、RTD 7.x.xのCryptoドライバはHSEファームウェア0.2.55.0でテストされています。 よろしくお願いいたします。 ルーカス Re: [S32K358] Version for HSM, RTD on s32k358 こんにちは、ルーカス。 コメントありがとうございます。とても参考になりました。 ありがとう、 ブライアン    

RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 2. 図2：モジュールAの100kHzにおけるロジックアナライザの波形 3. 図3：モジュールBの400kHzにおける波形 i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート：400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V～5V サブボード：ADUM1251 - モジュールA 5V～3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー 疑い： 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。（第47.3.1.4章を参照）タイミングパラメータ） マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。 このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。 デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。 Re: RT1064 I2C communication abnormality at 400kHz 以下は印刷設定です。どのパラメータを調整する必要があるでしょうか？ 追伸:どうやら自動インターフェース割り当てによるようです Re: RT1064 I2C communication abnormality at 400kHz 60MHzと8MHzの両方を変更してみましたが、それでもうまくいきませんでした。下図の赤い枠で囲まれた部分は、修正後に印刷された値を示しており、マニュアルに記載されている値とは異なっています。 Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 I2Cクロックを設定する方法はいくつかあります。 提案として、8 MHzと60 MHzを試してみるのも良いでしょう。この2つのクロック設定は比較的簡単に達成できます。 SDKのデモを使っています: 「evkmimxrt1064_lpi2c_edma_b2b_transfer_master」 方法1：LPI2Cクロックソースを60MHzに設定する 時計の分周器を0に設定するだけです。 方法2：LPI2Cクロックソースを8MHzに設定する MCUXpresso IDEsクロックツールを使い、以下の通りに設定してください。クロックソースとしてOSC_CLKを選択し、分周器を3に設定すると、LPI2C（I2C）モジュール用の8MHzクロックが生成されます。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 現在のI2Cクロックは、SDK2_13_0-EVK-MIMXRT1064 \ ボード \ evkmimxrt1064 \ river_deamples \ lpi2cディレクトリ内のサンプル構成に基づいて構成されています。 #define LPI2C_CLOCK_SELECT(0U) #define LPI2C_CLOCK_DIVIDER(5U) CLOCK_SetMux(kCLOCK_Lpi2cMux、LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv、LPI2C_CLOCK_DIVIDER); ---正確な8MHzか48MHzをどうやって修正すればいいですか?（時計の木が見えないようですね） Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 レジスタを直接設定してみるのも良いでしょう。 例えば、60 MHzのI2Cクロックを使用する場合、以下の構成を適用できます。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 図に示すように、パラメータに対応するようにレジスタ設定を変更しようとしましたが、60MHzでは改善がありませんでした。良いモジュールでも8MHzでは正常に動作しません

S32K144チップにはクロック構成の問題があり、クロックを変更するとタイミング周期が変わってしまう。 S32K144の開発中に、以下の問題に遭遇しました。 初期化タイマーの割り込みオーバーフロー期間は1秒に設定する必要があります。 前提として、私のクロック設定は8MHzです。 しかし、時計を20Mの時計に変えた後… タイマーのオーバーフロー期間が1秒ではなく、400ミリ秒になっていることに気づきました。 しかし、タイマーのクロック設定は依然として8MHzの内部クロックに設定されたままです。 PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* クロックソース=1、8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* FTMレジスタのクロックを有効にする */ この問題の原因となっている設定上の問題が何なのか、私には分かりません。 Re: S32K144芯片的时钟配置问题，更改时钟后定时周期出现变化 ハイ 次の S32K1 RM の表 27-9 を参照してください。peripheral module clocking (continued),FTM具体選択哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1 Register (PCC_FTM1)的PCS位。 プロセッサ エキスパートがコンフィギュレーションを生成し、ベアメタル モードでレジスタを直接操作しました。SDK サイトを使用した API が原因でベアメタル プログラムがクラッシュしたかどうかはわかりません。 さらに、ProcessorExpert 搭載 SDK の API を使用する場合は、ベアメタルの直接操作レジスタの構築リファレンス S32K144_Project_FTM サンプル ftm_periodic_interrupt_s32k144 を参照してください。 よろしくお願いいたします ロビン

如何通过 I2C 从 NTP5332 读取 UID 我有一个问题，如何通过 I2C 接口从 NTP5332 读取 UID？我在数据手册中没有找到 UID 的块地址。 Re: How to read UID from NTP5332 through I2C Hello @zhjyang  UID 是芯片内部唯一标识，不在任何 memory block 中，只能通过 NFC接口RF 命令读取,比如 INVENTORY （ISO15693）

EMIOS Pwm tooling error Emios 0 ch 255 in MCL I am trying to run trapezoidal motor control using S32K312 mini development board.  After porting the initialisation, I get the following error :  Issue: [Generation error] Please configure the counter bus EMIOS_0_CH_255 in MCL Level: Error Type: Tool problem Tool: Peripherals Origin: Peripherals Resource: Sources Information: [Generation error] Please configure the counter bus EMIOS_0_CH_255 in MCL My setup has : EMIOS mcl  initialises 0 and 1  for  EMIOS0 - Channel 0 -> PWM time base EMIOS1 - Channel 23 -> Time base for Hall pulse counter EMIOS pwm for  EMIOS0 Channel 1 as OPWMB for PWM 20KHz EMIOS Channel 3 as OPWMB for PWM pulse  Both the channels are based out od EMIOS Channel 0 in BCD mode.  Re: EMIOS Pwm tooling error Emios 0 ch 255 in MCL Here is a mex file. Re: EMIOS Pwm tooling error Emios 0 ch 255 in MCL Hi @ArunnK  I have tried applying the configuration you mentioned for Emios_Mcl and Emios_Pwm in the FreeRTOS_Toggle_Example_S32K312 (RTD 7.0.0 with FreeRTOS 7.0.0), and I have not been able to reproduce the errors on my side. Would you mind sharing your .mex file? It would also be really helpful if you could outline the steps you followed, so I can try to replicate the same behavior here. BR, VaneB Re: EMIOS Pwm tooling error Emios 0 ch 255 in MCL Hi @ArunnK  Thank you for sharing your .mex file. I imported it into the FreeRTOS_Toggle_Example_S32K312 (RTD 7.0.0 with FreeRTOS 7.0.0) project I previously used, and the error did not appear. To make sure we are following the same steps, could you please try the following: Delete the current example project and recreate. Update the code as needed to ensure everything is correct. Once the configurations are successfully generated, go to File → Import → S32 Configuration Tools → Import Configuration (*.mex). Select the .mex file you shared and merge it into the current configuration. After that, does the error still appear? And just to be sure, please double-check that all the software versions you are using are compatible.

imx93 sai - simple-audio-card devicetree settings Hi, I am searching for the device tree settings of the simple-audio-card for: -imx93 is the Master -Audio Codec is Slave TDM 16 Slots / 32 Bit and the following timing should be fullfilled: Any hints are appreciated Linux Re: imx93 sai - simple-audio-card devicetree settings Hello, Unfortunately, we do not have device tree examples to configure SAI port as slave in TDM for i.MX93. You could use this post as reference: https://community.nxp.com/t5/i-MX-Processors/How-should-I-write-a-dts-file-to-use-16ch-TDM-with-quot-simple/m-p/1625768#M203519 Best regards.

How to read UID from NTP5332 through I2C I have a question, how to read UID from NTP5332 through I2C interface? I don't see the block address for UID in the datasheet Re: How to read UID from NTP5332 through I2C Hello @zhjyang The UID is a unique identifier within the chip; it is not stored in any memory block and can only be read via NFC interface RF commands, for example... INVENTORY (ISO15693)

RT1064 I2C 通信异常，频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常，但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看，这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS：将该设备的 I2C 驱动程序移植到另一台 1064 设备上，测试模块 A，在 400k 功耗下未发现问题。 原因可能是什么？ 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2：模块 A 在 100kHz 下的逻辑分析仪波形 图3：模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察，该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足，而不是模块 A 本身的异常。 即使上升时间在规格范围内，在 RT1064 上，我们仍然建议检查 LPI2C 主侧 400 kHz 配置，特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1，因为 RT1064 上的主同步延迟不仅受上升时间的影响，还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置，并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符： I2C模块时钟源 目标波特率：400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息：昨天在定位方面取得了一些进展： 我们的硬件扩容计划如下： 主板：RT1064--- ADUM1251 3.3V 至 5 V 子板：ADUM1251-模块A 5V转3.3V 经验证，在硬件链路的两层中添加 ADUM1251 后，模块 A 的通信出现异常。但移除 ADUM1251 后，通信在 400k 处恢复正常。造成这种情况的原因可能是什么？ PS：我们的硬件工程师认为 ADUM1251 只会增加通信延迟，不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好，@mayliu1 我们的产品即将发布，我们已经调查这个问题好几天了。如果您能尽快回复，我们将不胜感激！ Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形，上升时间符合要求，在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备，并测试了模块 A，没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑： 1.如果时钟在拉伸后恢复异常，还有哪些其他原因可能导致这种情况？ 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置？我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求，我们是否就不需要考虑这些寄存器设置了？ Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题，而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上，LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出，上升时间越大，同步延迟就越高。（参见第 47.3.1.4 章）时序参数） 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置，使其延迟保持在最小 SCL 低/高周期以下，RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此，如果模块 A 使总线边沿稍微变慢或改变有效负载，则总线可能在 400 kHz 时发生故障，但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率，但应根据 I2C 规范仔细验证自动生成的定时参数，特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险，建议使用经过验证的时钟源，例如 48 MHz，如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数？ PS：显然是由于自动接口分配造成的 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 您可以尝试直接设置寄存器。 例如，当使用 60 MHz I2C 时钟时，可以采用以下配置。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率？（时钟树似乎看不见） Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz，但仍然无效。下图中的红色方框显示的是修改后打印的值，这些值与手册中的值不同。 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 ， 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz，因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版： "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一：将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 方法二：将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源，并将分频器设置为 3，这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 希望对你有帮助 顺祝商祺！ 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示，我尝试修改寄存器设置以匹配参数，但在 60MHz 下性能没有提升；即使是性能良好的模块在 8MHz 下也无法正常工作。

UJA1169ATK/F/3 I'm using UJA1169ATK/F/3 connected to a S32K146 CPU on FlexCAN1. The UJA1169ATK/F/3 is used in Partial Networking with WakeUp Frame (no FD!) to wakeup the whole system from a deep sleep mode. Actually every thing works correctly if a valid Frame is sent within the CAN BUS (for valid Frame a mean a frame which is compatible with the filtering masks selected). The problem arise when an unwanted Frame (i.e. a frame, non FD, which is syntactically correct but do not pass the WUP filtering in use) is sent. What happen is that, quit often, if one such frame is sent, than any successive valid Frame does not wakeup the transceiver any more. It seems that, when an unwanted Frame, often, locks the capability of the UJA1169ATK/F/3 to correctly recognize valid Frames and hence to wakeup. At first i suppose the problem could be something on the bus which generate a bus error which in turns switch the UJA1169ATK/F/3 in reset mode without moving RX signal and thus without advise CPU. But this is not the case, since i used a CAN monitor and no bus error are recorded (note that i use a Windows application to generate messages on CAN BUS and another application to monitor the bus; both application use separate USB/CAN converter). Do you have any idea of which could be the problem ? Re: UJA1169ATK/F/3 Hello Michele, The behavior you describe is most likely related to the internal PN error handling of the UJA1169A. The device maintains an internal frame detection error counter. If a sequence of frames is received that do not match the configured PN filters (or are interpreted as invalid in PN evaluation), this counter can overflow and trigger a PN frame detection error (PNFDE). Once this condition occurs, the SBC may temporarily stop correctly recognizing valid wake-up frames, which could explain why subsequent valid frames no longer wake the device. I recommend checking the PNFDE status bit and verifying the PN configuration (ID/mask, DLC, data mask and data rate settings). As a debug step, you can try disabling data field evaluation (PNDM = 0) to determine whether the issue is related to data filtering. Please let me know the observed PNFDE state and PN configuration so I can further support your analysis. BRs, Tomas

MCUXpressoで「転送送信」が有効になっている場合に、無効なeDMAコードが生成される（MCXN547） こんにちは、 MCUXpresso Config Tools v26.xをMCXN547プロジェクトで使用し、eDMAペリフェラルコンポーネントを使ってADC -> eDMA転送を設定しています。 構成： eDMAチャネルAPIモード:トランザクション(転送設定) eDMAリクエスト: ADC1 FIFO Aリクエスト 送金送信：有効 自動停止リクエスト:有効 周辺要求:有効 peripherals.cで生成されたコード には以下が含まれます: status = EDMA_SubmitTransfer(&DMA0_CH0_Handle, DMA0_CH0_Transfers_config, 1U); assert(status == kStatus_Success); しかし、ステータスの宣言は生成されません。その結果、プロジェクトはコンパイルに失敗します。 error: 'status' undeclared (first use in this function) 生成されるコードは以下のいずれかになります。 status_t status; status = EDMA_SubmitTransfer(...); または： assert(kStatus_Success == EDMA_SubmitTransfer(...)); この問題に遭遇したことがある方はいらっしゃいますか？ これはConfig Toolsにおける既知のコード生成バグでしょうか、それとも「転送を送信」を使用する際に必要な追加の設定オプションがあるのでしょうか？ 必要に応じて生成されたペリフェラル.cと.mexの設定も提供できます。 ありがとうございます。 ボード設計 MCX N Re: MCUXpresso generates invalid eDMA code when "Submit transfer" is enabled (MCXN547 ) ハイ 迅速なご対応ありがとうございます。 はい、ツールのバージョン26.03を持っています。 プロセッサー: MCXN547(2020年3月26日) - MCX MCXN MCUXpresso SDK バージョン 25.13.00 パッケージ:mcuxsdk-core バージョン:2.0.0 DMA0転送構成の「すべての転送をループ」に、このコードをDMA0_init()に追加します。 /* DMA0 ループ転送送信 */ status = EDMA_SubmitLoopTransfer(&DMA0_CH0_Handle, DMA0_CH0_Transfers_config, 1U); assert(status == kStatus_Success); 「ステータス」がどこにも宣言されていない場合。 Re: MCUXpresso generates invalid eDMA code when "Submit transfer" is enabled (MCXN547 ) こんにちは、 @tjo_dkさん。 投稿ありがとうございます！ どのMCXN547パッケージを使っているのか教えていただけますか? 使用しているConfig Toolsのバージョンは何ですか？26.03でしょうか？ どのSDKバージョンをインストールしていますか? 私の環境で同様の設定を行うために、この情報を共有してください。 Re: MCUXpresso generates invalid eDMA code when "Submit transfer" is enabled (MCXN547 ) こんにちは、 @tjo_dk さん。 あなたと同じ構成で、同様の問題を再現しようと試みました。しかし、私の環境では、コードプレビューにはすでにDMA0_init関数内でステータス変数の宣言が含まれています。

The S32K144 chip has a clock configuration issue; the timing period changes after the clock is modified. I encountered the following problem during the development of S32K144: The initialization timer's interrupt overflow period should be 1 second. The premise is that my clock configuration is 8MHz. However, after I changed the clock to a 20M clock... I discovered that my timer overflow period is no longer 1 second, but has become 400 milliseconds. However, my timer clock selection is still set to the 8MHz internal clock. PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* Clock src=1, 8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* Enable clock for FTM regs */ I'm not sure what configuration issue is causing this problem. Re: S32K144芯片的时钟配置问题，更改时钟后定时周期出现变化 Hi 建议看一下S32K1 RM的Table 27-9. Peripheral module clocking (continued)，FTM具体选择哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1 Register (PCC_FTM1)的PCS位。 你用Processor Expert生成配置，又用baremetal方式直接操作寄存器。我不确定是否是因为调用了SDK里的API导致和你的baremetal程序冲突了。 建议debug情况下直接检查上述两个寄存器。 顺便提一句，baremetal直接操作寄存器的话建议参考S32K144_Project_FTM例程，如果想用ProcessorExpert 搭配SDK的API则建议参考ftm_periodic_interrupt_s32k144例程。 Best Regards, Robin

IMX93 SAI - シンプルオーディオカードデバイスツリー設定 こんにちは、simple-audio-cardのデバイスツリー設定を探しています: -imx93 はマスターです -オーディオコーデックはスレーブTDM 16スロット/32ビット そして、以下のタイミングが守られる必要があります。 どんなヒントでもありがたいです Linux Re: imx93 sai - simple-audio-card devicetree settings こんにちは、 残念ながら、i.MX93のTDMでSAIポートをスレーブとして構成するためのデバイスツリーの例は提供しておりません。 参考文献としては以下の投稿を参考にしてください: https://community.nxp.com/t5/i-MX-Processors/How-should-I-write-a-dts-file-to-use-16ch-TDM-with-quot-simple/mp/1625768#M203519 よろしくお願いいたします。

S32K144芯片的时钟配置问题，更改时钟后定时周期出现变化 我在开发S32K144过程中遇到了如下问题： 这个定时器的初始化  计数中断溢出周期应该是1s   前提是我的  时钟配置是8M的时钟 但是当我更改时钟为  20M的时钟之后 我发现我的定时溢出周期  不是1s了  而变成了400ms    但是我的  定时器  时钟选择还是  8M的内部时钟   PCC->PCCn[PCC_FTM1_INDEX] |= PCC_PCCn_PCS(0x01) /* Clock src=1, 8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* Enable clock for FTM regs */ 我不清楚是哪里没有配置导致这个问题出现 Re: S32K144芯片的时钟配置问题，更改时钟后定时周期出现变化 HI 建议看一下S32K1 RM的表27-9。外设模块时钟（续），FTM具体选择哪个时钟源需要查看FTMn_SC[CLKS]和29.6.17 PCC FTM1寄存器（PCC_FTM1）的PCS位。 您用Processor Expert生成配置，又用裸机方式直接操作注册。我是否不确定是因为调用了SDK里的API导致和您的裸机程序冲突了。建议调试情况下直接检查上述两个注册。 顺便提一下，baremetal直接操作注册的话建议参考S32K144_Project_FTM例程，如果想用ProcessorExpert搭配SDK的API则建议参考ftm_periodic_interrupt_s32k144例程。 此致敬礼， Robin