读取变量时随机出现超时 您好，我一直在使用前人在这个项目中搭建的电池测试装置。 测试装置使用 nxp S32K144EVB 板，通过 USB 连接到计算机。 该代码由 simulink 文件构建，测试监控通过 FreeMASTER 3.2 进行。 该项目已在一台笔记本电脑上运行了几个月，现在需要配置一台新的笔记本电脑作为替代品。然而，即使安装相同版本的 FreeMASTER、相同的驱动程序并使用相同的项目文件，所有变量仍然显示为“?”由于在看似随机的时间段后出现超时错误。 若能得到任何帮助，我将不胜感激。 运行 12 分钟后未发现任何问题，已记录错误： Re: Random occurences of timeouts while reading variables 你好， 我目前还没有遇到过这个问题，但我有一些建议，或许能帮到你： 尝试使用 12V 电源适配器为 S32K144EVB 供电，而不是使用 USB 接口。S32K144EVB 入门指南 尝试不同的方法将 FreeMASTER 项目连接到 EVB： 使用板载 USB 连接器 外置串口转USB转换器 使用调试探针直接连接到 S32K144 MCU 尽量减少非关键变量的刷新时间。 阻止笔记本电脑进入睡眠模式（因为睡眠模式可能会切断 USB 电源以节省电池电量）。 尝试从头开始创建一个新的 FreeMASTER 项目。 顺祝商祺！ 索林·班奇拉

S32DS arm V1.3 激活码失败 您好，我的S32DS Arm V1.3软件激活码已过期。您能帮我延长一下时间吗？ 我最初的激活码是：FF3F-27C7-FFAB-837F Re: S32DS arm V1.3 activation code failed 你好， 现在已经延长了。 顺祝商祺！ Peter 回复： S32DS arm V1.3 activation code failed 0D3F-EFEF-B771-DA51我的激活ID是新的，对同版本的软件进行激活，在线激活和离线激活都失败了，失败界面在下面的附件中，希望帮我一起解决一下谢谢

IMX95 Aquila ISP 使用情况 你好， 我购买了一套 Aquila IMX95 评估套件 2，包含两个 ov5640 传感器（ https://www.toradex.com/cart ）。 我有传感器的驱动程序。主板固件已正确刷写，ISP模块已激活： root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 摄像头显示在 libcamera 中： root@imx95-1:~# libcamera -sh: libcamera: command not found root@imx95-1:~# cam -l [17:17:31.010001558] [2747] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) [17:17:31.044088474] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 4-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.044159391] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 4-003c': The sensor kernel driver needs to be fixed [17:17:31.044178224] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 4-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.044882558] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 4-003c': Failed to retrieve the camera location [17:17:31.044918891] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 4-003c': Rotation control not available, default to 0 degrees [17:17:31.045722599] [2748] WARN CameraSensor camera_sensor_legacy.cpp:354 'ov5640 3-003c': Recommended V4L2 control 0x009a0922 not supported [17:17:31.045762974] [2748] WARN CameraSensor camera_sensor_legacy.cpp:426 'ov5640 3-003c': The sensor kernel driver needs to be fixed [17:17:31.045783849] [2748] WARN CameraSensor camera_sensor_legacy.cpp:428 'ov5640 3-003c': See Documentation/sensor_driver_requirements.rst in the libcamera sources for more information [17:17:31.046362016] [2748] WARN CameraSensor camera_sensor_legacy.cpp:594 'ov5640 3-003c': Failed to retrieve the camera location [17:17:31.046388308] [2748] WARN CameraSensor camera_sensor_legacy.cpp:616 'ov5640 3-003c': Rotation control not available, default to 0 degrees [17:17:31.048068724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048640224] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.048904099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049145974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049451724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049694683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.049937141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050184266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050477516] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050720433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.050962433] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051201724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051441724] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051683308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.051925308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052259141] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.052510099] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061185308] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061469974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061736058] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.061988683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062242933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062489474] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062733266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.062980349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063228266] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063470391] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063712849] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.063953933] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064216891] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064463349] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064706683] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.064958766] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 [17:17:31.065200974] [2748] WARN V4L2 v4l2_pixelformat.cpp:346 Unsupported V4L2 pixel format AR30 Available cameras: 1: 'ov5640' (/base/soc/bus@42000000/i2c@42540000/camera@3c) 2: 'ov5640' (/base/soc/bus@42000000/i2c@426e0000/camera@3c) 为了检查 mipis 是否正常，我启动了一个 gstreamer 流水线，并成功地在两个摄像头上都获得了稳定的 30fps 流。我还成功地使用 v4l2-ctl 拍摄了快照。 现在，我想用我的摄像头测试一下 Aquila 的 ISP，看看它的表现如何。 请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf我添加了环境变量： root@imx95-1:~# export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 但是这样做之后，libcamera 就检测不到摄像头了，我不知道为什么： root@imx95-1:~# cam -l [17:36:38.947430563] [2788] INFO Camera camera_manager.cpp:327 libcamera v0.4.0+dirty (2026-06-03T11:26:44UTC) Available cameras: root@imx95-1:~# 感谢你的回复 ！ 此致敬礼， Re: IMX95 Aquila ISP usage 查看您的日志后，我认为该问题与 MIPI 接口或 OV5640 驱动程序本身无关。 事实是： libcamera 检测到了两台 OV5640 摄像头。 GStreamer 可以以 30 fps 的帧率进行流媒体传输。 v4l2-ctl 可以捕获图像 这表明传感器驱动程序、I2C 通信、  CSI-2  链接和媒体拓扑结构均运行正常。 关键在于 NXP Neo ISP 流水线需要原始的拜耳传感器输入。 OV5640 是一款 SoC 图像传感器，具有自己的内部图像处理流程，在 NXP 电路板支持包 中，它通常以 YUV 输出模式（例如 YUV422）使用，而不是作为 RAW Bayer 传感器使用。在这种配置下，可以通过标准的 V4L2/libcamera 流水线使用摄像头，但它不符合 Neo ISP 流水线的要求。 这就能解释为什么了： `cam -l` 默认会显示两台 OV5640 摄像头。 设置后 export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 已检测不到任何摄像头 摄像头仍然存在于系统中，但 NEO 流水线处理程序找不到兼容的摄像头拓扑结构，因此没有向 libcamera 公开任何摄像头。 为了验证传感器的实际输出格式，请提供以下输出： ```bash media-ctl -p v4l2-ctl --list-formats-ext 我们特别感兴趣的是，该传感器是否支持任何 RAW Bayer 格式，例如： SBGGR8 SBGGR10 SRGGB10 RG10 BA10 如果只有 YUV 格式（例如 YUYV/UYVY）可用，则表示相机未在 RAW 模式下运行，无法通过 Neo ISP 处理流程进行处理。 虽然 OV5640 硬件能够输出 RAW Bayer 格式图像，但 BSP 相机驱动程序通常不会启用 RAW 支持，NXP Neo ISP 堆栈也依赖于传感器特定的调整数据。即使启用了 RAW 输出，由于缺少专用的 OV5640 调谐配置文件，可能会阻止 ISP 的正常操作（AE/AWB/图像质量调谐）。 如果您的目标是评估 Neo ISP 框架本身，那么使用已知可与 NXP ISP 协议栈配合使用的传感器可能会更容易。常见候选人包括： OS08A20 OX03C10 OX05B1S AR0521 AR1335（可能需要额外调校） 能否分享一下上述命令的输出结果？这将使我们能够确认当前的 OV5640 配置是否向系统暴露了 RAW Bayer 格式。 此致， Re: IMX95 Aquila ISP usage 谢谢回复。 我做了一些额外的检查： 您是对的，OV5640 最初运行在UYVY 模式下，但我手动将一个传感器切换到了RAW Bayer (SRGGB8) 。 media-ctl -p 现在显示：   root@imx95-1:~# media-ctl -p Media controller API version 6.12.55 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ad50000.isi hw revision 0x0 driver version 6.12.55 Device topology - entity 1: crossbar (13 pads, 11 links, 8 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 2/0 -> 5/0 [ACTIVE] 3/0 -> 6/0 [ACTIVE] 2/0 -> 7/0 [ACTIVE] 3/0 -> 8/0 [ACTIVE] 2/0 -> 9/0 [ACTIVE] 3/0 -> 10/0 [ACTIVE] 2/0 -> 11/0 [ACTIVE] 3/0 -> 12/0 [ACTIVE] pad0: SINK,MUST_CONNECT pad1: SINK,MUST_CONNECT pad2: SINK,MUST_CONNECT [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] <- "4ac10000.syscon:formatter@20":1 [ENABLED,IMMUTABLE] pad3: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "4ac10000.syscon:formatter@120":1 [ENABLED,IMMUTABLE] pad4: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad5: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] pad6: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.1":0 [ENABLED,IMMUTABLE] pad7: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.2":0 [ENABLED,IMMUTABLE] pad8: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.3":0 [ENABLED,IMMUTABLE] pad9: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.4":0 [ENABLED,IMMUTABLE] pad10: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.5":0 [ENABLED,IMMUTABLE] pad11: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 field:none] -> "mxc_isi.6":0 [ENABLED,IMMUTABLE] pad12: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "mxc_isi.7":0 [ENABLED,IMMUTABLE] - entity 15: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":5 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 18: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video2 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 26: mxc_isi.1 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":6 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.1.capture":0 [ENABLED,IMMUTABLE] - entity 29: mxc_isi.1.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video3 pad0: SINK <- "mxc_isi.1":1 [ENABLED,IMMUTABLE] - entity 37: mxc_isi.2 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev3 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":7 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.2.capture":0 [ENABLED,IMMUTABLE] - entity 40: mxc_isi.2.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video4 pad0: SINK <- "mxc_isi.2":1 [ENABLED,IMMUTABLE] - entity 48: mxc_isi.3 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":8 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.3.capture":0 [ENABLED,IMMUTABLE] - entity 51: mxc_isi.3.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video5 pad0: SINK <- "mxc_isi.3":1 [ENABLED,IMMUTABLE] - entity 59: mxc_isi.4 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev5 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":9 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.4.capture":0 [ENABLED,IMMUTABLE] - entity 62: mxc_isi.4.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video6 pad0: SINK <- "mxc_isi.4":1 [ENABLED,IMMUTABLE] - entity 70: mxc_isi.5 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev6 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":10 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.5.capture":0 [ENABLED,IMMUTABLE] - entity 73: mxc_isi.5.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video7 pad0: SINK <- "mxc_isi.5":1 [ENABLED,IMMUTABLE] - entity 81: mxc_isi.6 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev7 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":11 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.6.capture":0 [ENABLED,IMMUTABLE] - entity 84: mxc_isi.6.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video8 pad0: SINK <- "mxc_isi.6":1 [ENABLED,IMMUTABLE] - entity 92: mxc_isi.7 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":12 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.7.capture":0 [ENABLED,IMMUTABLE] - entity 95: mxc_isi.7.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video9 pad0: SINK <- "mxc_isi.7":1 [ENABLED,IMMUTABLE] - entity 103: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":4 [ENABLED,IMMUTABLE] - entity 110: 4ac10000.syscon:formatter@120 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev9 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "csidev-4ad40000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "crossbar":3 [ENABLED,IMMUTABLE] - entity 115: 4ac10000.syscon:formatter@20 (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev10 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080] <- "csidev-4ad30000.csi":1 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080] -> "crossbar":2 [ENABLED,IMMUTABLE] - entity 120: csidev-4ad30000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev11 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] <- "ov5640 4-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range] -> "4ac10000.syscon:formatter@20":0 [ENABLED,IMMUTABLE] - entity 125: csidev-4ad40000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev12 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] <- "ov5640 3-003c":0 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none] -> "4ac10000.syscon:formatter@120":0 [ENABLED,IMMUTABLE] - entity 130: ov5640 4-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev13 pad0: SOURCE [stream:0 fmt:SRGGB8_1X8/1920x1080@1/30 colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad30000.csi":0 [ENABLED] - entity 134: ov5640 3-003c (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev14 pad0: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/2624x1964 crop:(336,434)/1952x1088] -> "csidev-4ad40000.csi":0 [ENABLED] （第二个OV5640仍保持UYVY模式，用于对比） 所以 ： OV5640 -> SRGGB8 CSI -> SRGGB8 格式化程序 -> SRGGB8 横杆 -> SRGGB8 => RAW Bayer 成功通过传感器、CSI 和格式化器进行传输。 neoisp内核模块已加载： root@imx95-1:~# modprobe neoisp root@imx95-1:~# lsmod | grep -i isp neoisp 69632 0 运行中的设备树中存在 ISP 节点：   /sys/firmware/devicetree/base/soc/isp@4ae00000   => 但是，我只看到一个媒体设备（/dev/media0）暴露了 CSI/Formatter/ISI 管道。媒体图中没有出现新独立党派实体。我在媒体图中没有看到任何 neoisp 实体，我不知道这是否正常。 => cam -l (libcamera) 仍然返回没有可用的摄像头。 目前看来，RAW Bayer 路径似乎可以正常工作，但我无法确定 Neo ISP 在哪个环节成为活动流程的一部分。   如何验证该流是否确实由 Neo ISP 处理，而不是仅仅遵循 CSI -> 格式化程序 -> ISI 路径？   另外，请参阅https://www.nxp.com/docs/en/user-guide/UG10215.pdf对于这种配置，目前还是推荐的指南吗？或者有没有针对 i.MX95 上 OV5640 + Neo ISP 的更具体的参考资料？       此致敬礼， Re: IMX95 Aquila ISP usage 我目前怀疑以下情况之一正在发生： OV5640 很可能运行在 YUV 模式而不是 RAW Bayer 模式。 摄像头 DT 叠加层不是 ISP 启用版本。 根文件系统中缺少 Neo IPA/校准组件。 Neo 管道看到的媒体拓扑结构与预期的 i.MX95 ISP 图不匹配。 media-ctl -p 的输出通常会指出哪个才是真正的问题所在。 Re: IMX95 Aquila ISP usage 您好！ 以下是输出结果： root@imx95-1:~# v4l2-ctl --list-formats-ext -d /dev/video2 ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [0]: 'YUYV' (YUYV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [1]: 'YUVA' (32-bit YUVA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [2]: 'NV12' (Y/UV 4:2:0, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [3]: 'NM12' (Y/UV 4:2:0 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x2 - 4096x8190 with step 2/2 [4]: 'NV16' (Y/UV 4:2:2, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [5]: 'NM16' (Y/UV 4:2:2 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 2x1 - 4096x8191 with step 2/1 [6]: 'YM24' (Planar YUV 4:4:4 (N-C), csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [7]: 'RGBP' (16-bit RGB 5-6-5, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [8]: 'RGB3' (24-bit RGB 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [9]: 'BGR3' (24-bit BGR 8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [10]: 'XR24' (32-bit BGRX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [11]: 'AR24' (32-bit BGRA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [12]: 'RA24' (32-bit ABGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [13]: 'AB24' (32-bit RGBA 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [14]: 'RX24' (32-bit XBGR 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [15]: 'XB24' (32-bit RGBX 8-8-8-8, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [16]: 'AR30' (32-bit ARGB 2-10-10-10, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [17]: 'GREY' (8-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [18]: 'Y10 ' (10-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [19]: 'Y12 ' (12-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [20]: 'Y14 ' (14-bit Greyscale, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [21]: 'BA81' (8-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [22]: 'GBRG' (8-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [23]: 'GRBG' (8-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [24]: 'RGGB' (8-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [25]: 'BG10' (10-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [26]: 'GB10' (10-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [27]: 'BA10' (10-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [28]: 'RG10' (10-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [29]: 'BG12' (12-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [30]: 'GB12' (12-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [31]: 'BA12' (12-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [32]: 'RG12' (12-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [33]: 'BG14' (14-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [34]: 'GB14' (14-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [35]: 'GR14' (14-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [36]: 'RG14' (14-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [37]: 'BYR2' (16-bit Bayer BGBG/GRGR, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [38]: 'GB16' (16-bit Bayer GBGB/RGRG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [39]: 'GR16' (16-bit Bayer GRGR/BGBG, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [40]: 'RG16' (16-bit Bayer RGRG/GBGB, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 [41]: 'MJPG' (Motion-JPEG, compressed, csc-colorspace, csc-ycbcr, csc-quantization, csc-xfer-func) Size: Stepwise 1x1 - 4096x8191 with step 1/1 如果我理解正确的话，相机可以拍摄原始拜耳格式照片，我也将其配置为拍摄原始拜耳格式照片（希望我配置正确）。 我再尝试用另一个镜像文件刷机，看看问题是不是出在这里。 此致敬礼， Re: IMX95 Aquila ISP usage 谢谢你的更新。这  v4l2-ctl  输出结果证实 ISI 捕获节点支持 RAW Bayer 格式，并且  media-ctl -p  您上一条消息的输出已经表明，RAW Bayer 路径已正确传递到整个流程中： OV5640 (SRGGB8) -> CSI (SRGGB8) -> 格式化器 (SRGGB8) -> 十字开关 (SRGGB8) 所以传感器侧的配置看起来是正确的。 现在的核心问题是：  新互联网服务  模块已加载，但未出现在媒体图中，也没有其他信息。  /dev/media1  已创建。这通常表明  新互联网服务  驱动程序已成功作为内核模块加载，但在设备探测期间失败，这将阻止其注册媒体设备。 请您提供以下诊断信息： # 检查 NeoISP 探测状态 dmesg | grep -i neoisp dmesg | grep -i "isp@4ae" dmesg | grep -i “探测失败” dmesg | grep -i "4ae00000" # 确认所有可用的媒体设备ls -la /dev/media* # 检查 sysfs中的neoisp 状态ls /sys/总线/platform/drivers/nxp-neoisp/ cat /sys/firmware/devicetree/base/soc/isp@4ae00000/status 同时，我们也想问一下：您是否可以访问以下任何一款由 NXP Neo ISP 协议栈官方支持且具有完整调优我的的传感器？ OS08A20 OX03C10 OX05B1S 使用这些传感器之一进行测试，可以让我们快速验证 Neo ISP 驱动程序本身在您的环境中是否正常工作，并有助于确定问题是与驱动程序/环境相关还是 OV5640 配置特有的问题。 请注意，虽然 OV5640 能够输出 RAW Bayer 图像，但它没有官方的 NXP Neo ISP 调谐我的，这意味着即使管道连接正确，AE/AWB 和图像质量调谐功能也无法使用。 Re: IMX95 Aquila ISP usage 一些更新： 我们内部对此进行了检查，并想分享以下关于 OV5640 和 i.MX95 Neo ISP 流水线的观察结果。 虽然 OV5640 能够输出 RAW Bayer 数据，但出于以下原因，我们通常不建议在新设计中使用 OV5640 + Neo ISP 组合： OV5640 已经是一款停产（EOL）传感器。 虽然支持 RAW 输出，但与较新的 RAW 传感器相比，该传感器本身提供的可调控制功能有限。 NXP 的 i.MX95 参考，引用相机解决方案基于 OS08A20 等 RAW 传感器，这些传感器已在 Neo ISP 软件框架中得到支持和验证。 因此，我们的建议如下： 将 OV5640 与其现有的图像处理路径一起使用（不依赖 Neo ISP AE/AWB 调整功能）。 如果需要完整的 Neo ISP 功能，请使用 NXP 支持的 RAW 传感器，例如 OS08A20。 如果 OV5640 必须与 Neo ISP 管道一起使用，则需要额外的软件启用工作。 对于 OV5640 + Neo ISP 方案，需要实现 libcamera CameraHelper。以下文件可作为参考，引用： camera_helper_ov5640.cpp https://github.com/nxp-imx/libcamera/blob/lf-6.6.52_2.2.0/src/ipa/nxp/cam_helper/camera_helper_ov5640.cpp 请注意，此 CameraHelper 实现只是第一步。它的主要目的是让 libcamera 能够识别 OV5640 传感器。还需要针对特定传感器进行额外的适配。 例如，如果希望 Neo ISP 自动曝光 (AE) 功能正常工作，则需要实现传感器增益转换函数等 API。IMX219 CameraHelper 实现中提供了一个简单的示例： https://github.com/nxp-imx/libcamera/blob/lf-6.18.20_2.0.0/src/ipa/nxp/cam_helper/camera_helper_imx219.cpp 具体而言，客户需要确定并实施以下之间的映射关系： 传感器增益代码 实际模拟增益倍增器（增益值） 这样 Neo ISP AE 算法就能正确控制传感器曝光和增益。 有关 CameraHelper 开发的详细信息，请参阅相机移植指南： 第 5.3 节 – “为新传感器实现 libcamera CameraHelper” OV5640 的一个特殊之处在于它本身就包含 AE 功能。因此，如果打算继续使用传感器的内部 AE 而不是 Neo ISP AE 算法，则诸如 gainCodeToGain() 和 gainToGainCode() 之类的实现可能并非严格必需。在这种情况下，一个仅用于传感器检测的基本 CameraHelper 可能就足以启动管道。 然而，图像质量调优仍然需要进行评估和调整。由于 OV5640 最初并非作为 Neo ISP 参考，引用传感器进行特性分析和调校，因此可能需要额外的 ISP 调校工作才能达到最佳图像质量。 总的来说，虽然 OV5640 RAW 输出可以连接到 i.MX95 Neo ISP 流水线，但预计还需要一些针对特定传感器的 libcamera 和 ISP 集成工作。对于新开发项目，我们建议尽可能使用经过 Neo ISP 验证的 RAW 传感器，例如 OS08A20。 Re: IMX95 Aquila ISP usage 在前文讨论的基础上，我们调查了 Neo ISP 管道无法识别 OV5640 传感器的根本原因。 问题在于 NXP Neo IPA（图像处理算法）框架使用了一种  相机助手  工厂通过匹配内核 V4L2 子设备模型字符串来查找传感器特定的增益/曝光算法。由于没有  相机助手  已登记  “ov5640” ，工厂退回  nullptr  无法为该传感器配置 ISP 管道。 为了解决这个问题，我们实施了一项  相机助手  适用于基于 NXP 内核内部驱动程序（ drivers/media/i2c/ov5640.c） 的 OV5640 传感器😞 增益寄存器映射： 登记：  OV5640_REG_AEC_PK_REAL_GAIN  ( 0x350a )，10 位值 格式：Q6.4 定点，单位增益 = 16 gainCode(g) = round(g * 16) gain(code) = code / 16.0 两个文件已被修改： camera_helper_ov5640.cpp  – 为 OV5640 开发的新 CameraHelper 实现，已注册为  "ov5640"  与内核子设备模型字符串匹配 meson.build  ——已添加  camera_helper_ov5640.cpp  添加到版本源列表 请使用这两个文件重新构建 libcamera，然后重试。  LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo' 。Neo ISP 管道现在应该能够找到并配置 OV5640 传感器。 请注意，虽然这可以实现增益/曝光控制路径，但 OV5640 的完整 ISP 调谐我的（AE/AWB 参数）尚未可用。图像质量调优可能仍需进一步完善。 重建完成后与我们联系结果。

S9KEAZN16AM WDOG 时序说明：128 个总线时钟与观察到的 80 微秒和 2.5 毫秒延迟对比 你好， 我正在与S9KEAZN16AM合作，想了解一下 WDOG 初始化时间的相关问题。 配置 MCU：S9KEAZN16AM 总线时钟：16.777216 MHz WDOG 时钟源：1 kHz LPOCLK 重置类型：软件重置（SYSRESETREQ） 根据KEA64参考手册，在看门狗解锁序列之后： “解锁序列完成后，用户必须在 128 个总线时钟周期内重新配置看门狗；否则，看门狗将强制 RESET MCU。” 总线时钟频率为 16.777216 MHz： 128 个总线时钟周期 ≈ 7.63 微秒 说明 为了确保可靠运行，我们目前的实施方案需要以下延迟： 软件重置();   SysTick_DelayUs(2500);   禁用中断();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   启用中断(); 我们发现两个问题： 如果移除或减少Software_Reset() 之后的 2.5 毫秒延迟，看门狗计数器并不总是能正确启动/运行。 如果移除WDOG_Init() 之后的 80 µs 延迟，看门狗配置将无法始终正确应用。 问题 128 总线时钟要求是否仅限于解锁后的配置窗口，还是之后还会进行额外的内部同步？ 使用1 kHz LPO 时钟是否会引入额外的同步延迟？ RESET后是否存在已知的启动时间要求，可以解释为何需要约 2.5 毫秒？ 是否有推荐的状态位或轮询机制可以替代固定延迟？ 主要令人困惑的是，观察到的延迟（ 80 µs 和 2.5 ms ）明显大于记录在案的128 总线时钟（~7.6 µs）要求所隐含的时序。 任何指导都将不胜感激。 谢谢！

S32DS Arm V1.3 起動コードが失敗しました こんにちは、私のS32DS Arm V1.3のソフトウェアアクティベーションコードが期限切れになりました。時間を延長する手助けをしてもらえますか? 私の元の認証コードはFF3F-27C7-FFAB-837Fでした。 Re: S32DS arm V1.3 activation code failed こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター 回复： S32DS arm V1.3 activation code failed 私の認証ID（0D3F-EFEF-B771-DA51）は新しいもので、同じバージョンのソフトウェアをオンラインでもオフラインでも認証しようとしましたが、どちらも失敗しました。失敗画面は添付ファイルをご覧ください。解決にご協力いただければ幸いです。よろしくお願いいたします。

S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays Hello, I am working with S9KEAZN16AM and would like some clarification regarding WDOG initialization timing. Configuration MCU: S9KEAZN16AM Bus Clock: 16.777216 MHz WDOG Clock Source: 1 kHz LPOCLK Reset Type: Software Reset (SYSRESETREQ) According to the KEA64 Reference Manual, after the watchdog unlock sequence: "On completing the unlock sequence, the user must reconfigure the watchdog within 128 bus clocks; otherwise, the watchdog forces a reset to the MCU." With a bus clock of 16.777216 MHz: 128 bus clocks ≈ 7.63 µs Observations Our current implementation requires the following delays for reliable operation: Software_Reset();   SysTick_DelayUs(2500);   DisableInterrupts();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   EnableInterrupts(); We observe two issues: If the 2.5 ms delay after Software_Reset() is removed or reduced, the watchdog counter does not always start/run correctly. If the 80 µs delay after WDOG_Init() is removed, the watchdog configuration is not always applied correctly. Questions Is the 128 bus clock requirement only the configuration window after unlock, or does additional internal synchronization occur afterwards? Can the use of the 1 kHz LPO clock introduce additional synchronization delays? Is there any known startup timing requirement after a software reset that could explain the need for ~2.5 ms? Is there a recommended status bit or polling mechanism that should be used instead of fixed delays? The main point of confusion is that the observed delays (80 µs and 2.5 ms) are significantly larger than the timing implied by the documented 128 bus clock (~7.6 µs) requirement. Any guidance would be greatly appreciated. Thank you.

変数の読み取り中にタイムアウトがランダムに発生する こんにちは。私はこのプロジェクトの前任者たちが設置したバッテリー試験装置を使って作業しています。 テストリグはnxp S32K144EVBボードをUSBでコンピューターに接続しています。 コードはSimulinkファイルから構築され、テストの監視はFreeMASTER 3.2を介して行われます。 このプロジェクトは数ヶ月間ノートPCで作業しており、新しいノートPCを交換する必要がありました。しかし、同じFreeMASTERバージョン、同じドライバ、同じプロジェクトファイルを使っていても、すべての変数が「?」と読み取られます。一見ランダムな時間経過後にタイムアウトエラーが発生するため。 どんなご支援でも大変感謝いたします。 12分間の実行後、問題なくログに記録されたエラー： Re: Random occurences of timeouts while reading variables こんにちは、 私はまだその問題に直面していないと思いますが、いくつか提案があります。役に立つかもしれません。 S32K144EVBをUSBではなく12V電源から起動してみてください。S32K144EVB の入門 FreeMASTERプロジェクトをEVBに接続するために、さまざまな方法を試してみてください: オンボードのUSBコネクタを使用する 外部シリアル-USB変換アダプター デバッグプローブを使って直接S32K144 MCUに接続してください 重要度の低い変数については、更新時間を短縮してみてください。 ノートPCがスリープモードに入らないようにしてください(バッテリー節約のためにUSB電源が切れる可能性があります)。 FreeMASTERプロジェクトをゼロから新規作成してみてください。 よろしくお願いいたします。 ソリン・バンシラ

NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application We have created a sample application project and are using it as the bootloader. The actual application project is identical, with the only difference being the flash start address. The bootloader successfully jumps to the application, and the application starts executing. However, within the application, the xTaskCreate() function does not executed. Is there any additional configuration required when jumping from a bootloader to a FreeRTOS-based application? For example, are there any startup, interrupt, vector table, stack pointer, or scheduler-related configurations that must be performed before the application can create and execute FreeRTOS tasks? I referred the Unified bootloader Demo ticket from community. I didn't get the solution. Issue is only when we include FreeRTOS, without RTOS the application is working fine.  Its working for S32K344 not for NXPS32K358. Please let me know if any additional information is required. Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hi @Indhumathi, This "xTaskCreate() does not execute" is ambiguous and could mean different things. Can you check the following? 1. Execution never reaches xTaskCreate() The application starts, but something hangs or faults before the call. 2. xTaskCreate() is called but returns an error The function is called and returns an error, for example errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY. 3. Tasks are created, but the scheduler never runs them xTaskCreate() succeeds (returns pdPASS) and the tasks are created, but vTaskStartScheduler() is never called, fails, or SysTick/PendSV are not operating correctly after the bootloader jump. As a result, the tasks remain in the Ready state and never get CPU time. Also, is vApplicationMallocFailedHook() called? Which heap implementation are you using? What is the state of CM7_2? Is it running, held in reset, or started by the bootloader? Thank you, BR, Daniel Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Bootloader-to-Application Jump Code Used in Our Project: void Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t func; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;       for(i = 0; i < 10; i++)     {     S32_NVIC->ICER[i] = 0xFFFFFFFFU;     S32_NVIC->ICPR[i] = 0xFFFFFFFFU;     }     appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application Hello @Indhumathi, To narrow down the root cause, could you please verify whether the following interrupt handlers are actually being executed? SVC handler (vPortSVCHandler) — responsible for starting the first FreeRTOS task PendSV handler (vPortPendSVHandler) — responsible for context switching between tasks SysTick handler (vPortSysTickHandler / xPortSysTickHandler) — responsible for the FreeRTOS tick The simplest way to check is to place a breakpoint or a GPIO toggle at the entry of each handler in the application. Thank you, Regards, Daniel

Ara240 16GB M.2 Module Which quantization precisions are officially supported in Ara240 16GB M.2 Module ?(INT4,8,16) Re: Ara240 16GB M.2 Module According to Ara240 Discrete Neural Processing Unit Data Sheet Precision Officially documented support INT4 No documented support found INT8 Supported INT16 Supported INT32 Supported, though not in your INT4/8/16 list

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 のリストには含まれていません。

NXPS32K358：引导加载程序跳转到应用程序后，FreeRTOS 任务未运行 我们创建了一个示例应用程序项目，并将其用作引导加载程序。实际的应用程序项目与之完全相同，唯一的区别在于闪存起始地址。 引导加载程序成功跳转到应用程序，应用程序开始执行。但是，应用程序中的 xTaskCreate() 函数并未执行。 从引导加载程序跳转到基于 FreeRTOS 的应用程序时，是否需要任何额外的配置？例如，在应用程序能够创建和执行 FreeRTOS 任务之前，是否必须执行任何与启动、中断、向量表、堆栈指针或调度程序相关的配置？ 我提到了 统一引导加载程序演示 社区提交的工单。我没有找到解决方案。问题只出现在引入 FreeRTOS 时，不引入 RTOS 时应用程序运行正常。  它适用于 S32K344，但不适用于 NXPS32K358。 如有需要，请告知是否需要提供其他信息。 Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 我们项目中使用的引导加载程序到应用程序的跳转代码： 无效 Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t func; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;   for(i = 0; i < 10; i++)     { S32_NVIC->ICER[i] = 0xFFFFFFFFU; S32_NVIC->ICPR[i] = 0xFFFFFFFFU;    } appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 你好@Indhumathi ， 为了缩小问题根源范围，请您验证一下以下中断处理程序是否正在执行？ SVC 处理程序 (vPortSVCHandler) — 负责启动第一个 FreeRTOS 任务 PendSV 处理程序 (vPortPendSVHandler) — 负责任务之间的上下文切换 SysTick 处理程序（vPortSysTickHandler / xPortSysTickHandler）——负责 FreeRTOS 滴答 最简单的检查方法是在应用程序中每个处理程序的入口处设置断点或 GPIO 开关。 谢谢！ 此致， 丹尼尔

S32DS arm V1.3 activation code failed Hello, the software activation code of my S32DS Arm V1.3 has expired. Could you help me extend the time.   My original activation code was:FF3F-27C7-FFAB-837F Re: S32DS arm V1.3 activation code failed Hello, It is extended now. Best regards, Peter 回复： S32DS arm V1.3 activation code failed My activation ID (0D3F-EFEF-B771-DA51) is new, and both online and offline activation failed when I tried to activate the same version of the software. The failure screen is in the attachment below. I hope you can help me solve this. Thank you.

NXPS32K358: ブートローダーがアプリケーションにジャンプした後にFreeRTOSタスクが実行されない サンプルアプリケーションプロジェクトを作成し、それをブートローダーとして使用しています。実際のアプリケーションプロジェクトは同一で、唯一の違いはフラッシュスタートのアドレスだけです。 ブートローダーは無事にアプリケーションにジャンプし、アプリケーションは実行を開始します。しかし、アプリケーション内ではxTaskCreate()関数は実行されません。 ブートローダーからFreeRTOSベースのアプリケーションにジャンプする際に、追加の設定が必要ですか?例えば、FreeRTOSタスクを作成・実行する前に、起動、割り込み、ベクターテーブル、スタックポインタ、スケジューラ関連の設定などを行う必要がありますか? 私はそのことを紹介しました コミュニティからの統一ブートローダーデモ チケット。解決策は得られませんでした。問題はFreeRTOSを含めたときだけで、RTOSなしでアプリケーションは問題なく動作することです。  S32K344では動作しますが、NXPS32K358では動作しません。 追加情報が必要な場合はお知らせください。 Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application 私たちのプロジェクトで使用されているブートローダーからアプリケーションへのジャンプコード: void Boot_JumpToApp(uint32 i_AppAddr) { uint32_t appStack; uint32_t 関数; uint8 i;   DisableAllInterrupts();   S32_SysTick->CSRr = 0; S32_SysTick->RVR = 0; S32_SysTick->CVR = 0;   for(i = 0; i < 10; i++)     { S32_NVIC->ICER[i] = 0xFFFFFFFFU; S32_NVIC->ICPR[i] = 0xFFFFFFFFU;    } appStack = *(volatile uint32_t *)0x00442000; __set_MSP(appStack); S32_SCB->VTOR = 0x00442000; func = *(uint32_t volatile *)(((uint32_t)0x00442004)); (* (void (*) (void)) func)(); } Re: NXPS32K358: FreeRTOS Tasks Not Running After Bootloader Jumps to Application こんにちは、 @Indhumathi さん。 根本原因を絞り込むために、以下の割り込みハンドラが実際に実行されているか確認していただけますか? SVCハンドラ（vPortSVCHandler）—最初のFreeRTOSタスクを開始する役割を担う PendSVハンドラー（vPortPendSVHandler）—タスク間のコンテキスト切り替えを担当 SysTick ハンドラ (vPortSysTickHandler / xPortSysTickHandler) — FreeRTOS のティック処理を担当 最も簡単な確認方法は、アプリケーション内の各ハンドラのエントリにブレークポイントやGPIOトグルを配置することです。 ありがとうございました。 よろしくお願いいたします。 ダニエル

S32K118 FlexIO Hello. I would like to consult about implementing both-edge detection for motor Hall sensor signals using the FlexIO module on S32K118. Currently, I need to capture both rising and falling edges of three Hall feedback signals from the BLDC motor. I am trying to configure FlexIO pins as input capture channels. However, I am confused about how to set FlexIO to detect both rising and falling edges simultaneously. Could you share the proper FlexIO timer and shifter configuration workflow for dual-edge capture。Besides.I also want to know if interrupts can be triggered on every edge, and whether there are known limitations or precautions when using FlexIO for Hall signal sampling on the S32K118 platform. Thank you very much. Re: S32K118 FlexIO Hello @Niuyanlin, If application is Hall sensor in BLDC motor feedback, I suggest looking into the FTM module instead. The following application note mentions how to configure the module for single and dual edge capture, and how to generate a capture interrupt: AN5303: Features and Operation Modes of FlexTimer Module on S32K – Application Note. "The Hall sensors are connected to the channels of the independent FTM (FTM_CHx). The FTM can then detect both the falling and rising edges of the Hall sensor signals and generate a capture interrupt." FlexIO, by contrast, requires constructing input capture behavior indirectly through timer-decrement modes, and it can work, but in my opinion, FTM module is better suited. Best regards, Julián Re: S32K118 FlexIO Hello, Julian, Thank you very much for your prompt reply and valuable suggestions. I recognize that FTM is a superior choice for feedback from BLDC motor Hall sensors. However, due to insufficient peripheral resources in the project, we had to implement input capture functionality using FlexIO. We would greatly appreciate it if you could provide a detailed software implementation plan related to FlexIO for our reference. Best regards, Niu Yanlin Re: S32K118 FlexIO Hello @Niuyanlin, Since FlexIO does not have the dedicated input capture capability, most of the documentation is based on communication emulation. The main suggestion I can give is to refer to S32K1's reference manual chapter 54. You can refer to the following application notes, which detail how to configure shifters and timers, along with the respective interrupts: AN14284: Timing Parameter Tuning for FlexIO Emulated Interface | NXP Semiconductors AN12174: Using FlexIO to emulate communications and timing peripherals – Application Note Understanding FlexIO The FlexIO module can generate an interrupt from 3 sources: Shifter error, Shifter status flag and Timer status flag. To enable the interrupts, you need to set the bits in the SHIFTSIEN, SHIFTEIEN and TIMIEN. However, there are no routines for input capture or BLDC motor control. I apologize for the inconveniences. Best regards, Julián

GUIGuider 1.10.1 から 2.0.0 への移行 私たちはGUIGuiderプロジェクトをバージョン1.10.1で構築してきましたが、新しいバージョン2.0.0に移行して新機能を試してみたいと思っています。古いGUIGuiderプロジェクトファイルが新しいバージョンでは読み込めないことが分かりました。おそらくそれはプロジェクトが使う新しいJSON構造の2.0.0のせいだと思います。 GUIGuiderの新しいバージョンにプロジェクトを簡単に移行する方法はありますか？それとも手動で変換する必要がありますか？

iMXEBOOKDC5 触摸控制器 IC 零件编号 亲爱的团队， 我正在使用iMXEBOOKDC5和i.MX8ULP EVK 。 目前为止，一切进展顺利。电子墨水显示屏工作正常，按钮和操纵杆也都能正常工作。 我现在想启用显示屏上的触摸面板。但是，我无法确定 EPD 模块上使用的触摸控制器 IC 的零件编号，因为 IC 上的标记似乎已被激光打标擦除。 我曾尝试自己查找相关信息，但没有成功。 请问您能否分享一下： iMXEBOOKDC5 显示屏上使用的触摸控制器 IC 部件号。 任何可用于支持触摸功能的 Linux 驱动程序、库或软件包。 感谢您的帮助。 顺祝商祺！ 评估板 Re: Touch Controller IC Part Number for iMXEBOOKDC5 你好， 所使用的触摸控制器IC是汇顶科技（Goodix Technology）生产的GT911。 您可以通过以下链接查看驱动程序： https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/input/touchscreen/goodix.c 顺祝商祺！ Re: Touch Controller IC Part Number for iMXEBOOKDC5 亲爱的， 感谢您的支持 顺便问一下，您能否提供电子墨水面板的 wayform bin 文件？ BRs， 莱德

S32K5の2つの異なるコルテックスM7からメインプラットフォームドメインのSEMA42ユニットにアクセスする S32K5の2つの異なるCortex M7コア(M7_0とM7_1)からメインプラットフォームのSEMA42_1ユニットにアクセスしようとしています。システムがフリーズします。ここで社内作業スペースを共有することはできません。 訂正ERR053433には次のように記載されています:SEMA42:複数のアプリケーションコアによるSEMA42_0およびPBRIDGE_2への同時アクセスによりシステムがハングします。 残念ながら、SEMA42_1を使用するという回避策では、システムハングアップの問題は解決しません。 S32K56xで2つのCortex M-7コアを設定・検証し、Design StudioのSEMA42_1ユニットのgate0にアクセスして最適化-OSを有効にしてもらえますか? システムのフリーズ問題は、以下のいずれか１つを使用することで解消されます。 最適化を無効にする -O0 命令キャッシュを無効にする SoC上の別のドメインのSRAMを使用する例CPE デバッガー経由でステップインする Re: Accessing SEMA42 unit on main platform domain from two different cortex M7 in S32K5 こんにちは、 @seasonedbit さん。 ご存知かもしれませんが、S32K5は現在プリプロダクション段階にあります。イネーブルメント(ドキュメント、ソフトウェア、ボード)は承認されたお客様のみが利用可能であり、そのため当社のグローバルオンラインサポートチームからはまだサポートされていません。 最初にこの装置を提供したFAEやNXPの担当者に連絡していただけますか?彼らはさらなる支援を提供できるでしょう。 ご理解いただきありがとうございます。 よろしくお願いします、 ジュリアン

IMXRT1172 LPSPI EDMA転送APIを使用する場合、SPI転送が完了する前にDMA IRQハンドラが呼び出されます。 こんにちは、 私はIMXRT1172上でSDKのLPSPI EDMA転送API(2.16.100)を使って、SPIデータを同時に読み書きしています(つまり、同じサイズのバッファを持つ2つのDMAチャネルでのTX+RX転送)。残念ながら、EDMAコールバックは転送が実際に完了する前に呼び出されているようです。コールバック内でLPSPIのSR、FSR、RSRを確認すると、DMAは処理が完了したと考えているにもかかわらず、SPIはまだビジー状態であると考えていることがわかります。つまりMBFは設定されたままで、TXCOUNTは1です。 SR = 0x01000100 (MBF、WCF) FSR TXCOUNT = 1、RXCOUNT = 0 RSR = 0x00000002 (RXEMPTY、!SOF) もしTXだけを扱うなら、SPIペリフェラルがDMAから最後に読み込まれたバイトをまだ処理している可能性があるので、ある程度理にかなっているかもしれません。その場合、DMA周辺機器はRAMからSPIのデータTXレジスタへの最後のバイトの読み込みを終えていますが、SPIはそれを送信する作業をまだ必要としていました。 しかし、TXとRXを同時に行う場合、TXCOUNTが1ならRXCOUNTも1になるはずだと予想していました。つまり、DMAはすべてのTXデータがクロックアウトされるまでRXで完了してはならない。なぜなら、最後のバイトはSPI RXデータレジスタからDMAによってRAMに転送される必要があり、これは転送の最後のクロックサイクルでのみ発生するからである。 これは本当に問題なのでしょうか？ もしそうなら、SDKで問題ですか? それともハードウェアIPで? DMAコールバック内でLPSPI SRをチェックして、SPIエラーが発生しているかどうかを判断できればと思っていました。 ありがとうございます -m Re: Using IMXRT1172 LPSPI EDMA transfer API, DMA IRQ handler called before SPI transfer is done こんにちは、 @nxp16 さん。 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 DMA完了とSPIバス完了は、2つの異なる概念です。 eDMAコールバックは、DMAエンジンがメモリとLPSPI FIFO/レジスタパス間で設定されたバイト数のデータの転送を完了したことを示します。これは必ずしも、LPSPIバスステートマシンが最後のフレームを完了した、あるいはアイドル状態に戻ったことを意味するものではありません。 LPSPIバスの完了を確認するには、SR[TCF]を確認するか、SR[MBF]がクリアされるまでお待ちください。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: Using IMXRT1172 LPSPI EDMA transfer API, DMA IRQ handler called before SPI transfer is done はい、しかしTX/RX転送の場合、DMAが完了した時点でTX_COUNTとRX_COUNTの両方がゼロになることを期待していました。つまり、RX DMAが最後のSPIクロックより前に完了することは不可能であるはずです。なぜなら、SPI周辺機器はその時間までにデータの最後のビットをRX FIFOにシフトしておらず、DMAは最後のバイトをRX FIFOにシフトするまでRAMにコピーできないからです。その場合、TXとRXの両方がDMAが完成する前に完了しているはずです。もしTXの転送だけなら、DMAがSPIより先に完了し、TX_COUNTはまだ1のままかもしれません。 ありがとうございます -m Re: Using IMXRT1172 LPSPI EDMA transfer API, DMA IRQ handler called before SPI transfer is done こんにちは、 @Mike_M3 さん、 ご意見ありがとうございます。 あなたの指摘はRXデータパスに関しても正しいです。RX EDMAチャネルが完了すると、期待されるRXデータはすでにRAMに移されています。しかし、これはLPSPIバスの完了とはまだ同じではありません。 TXCOUNT/RXCOUNTはFIFO占有率インジケーターです。RXCOUNT=0はDMAによってRX FIFOが消耗されたことを意味し、TXCOUNT=1は送信/コマンドFIFO内の保留中のエントリを1つ示すことがあります。LPSPIでは、送信FIFOはコマンドやTCRエントリにも使用されるため、TXCOUNTは単なるRX補完のミラーではありません。MBF=1は、LPSPIバスステートマシンがまだ完全にアイドル状態に戻っていないことを示します。 したがって、転送完了の条件としてTXCOUNT/RXCOUNTの等価性を使用することはお勧めしません。LPSPIバス完了条件については、代わりにSR[TCF]=1またはSR[MBF]=0を使用してください。割り込みベースの表示が望ましい場合は、kLPSPI_TransferCompleteInterruptEnableを有効にし、EDMAコールバックをDMA完了表示専用にしてください。 よろしくお願いいたします。 5月

S32K314でDMAを使用したUARTが正しく動作しません こんにちは、 現在、DMAと連携するようにLPUART0チャネルの設定を試みています。UARTチャネルは1Mbpsのビットレートで動作している必要があります。 現在のUARTとDMAの設定は以下のようになっています。 MCUではクロックが有効化され、バッファはキャッシュできない領域内に宣言され、DMAのISR優先度はLPUARTよりも小さいです。 私たちの問題は、RXバッファ内のデータを見ることができない、あるいはデータが不完全であることです。 私たちのワークフローはこうです(LINコミュニケーションに似ています) 😞 受信バッファを準備 -> AsyncReceive スレーブにヘッダーを送信する -> AsyncSend 次のサイクルでスレーブからデータが受信されるまで待機します（私の関数は1msのタスクで実行されます）。 AsyncSendの実行後にブレークポイントを設けると、RXバッファ内のスレーブからのすべてのデータ送信が確認できます。 そのまま実行させても、何も表示されないか、不完全な結果しか得られない。 私の推測では、DMA割り込みは後から発生する。 私たちの設定のどこが問題なのか、あるいは次に何をチェックすればいいのか、いくつかヒントを教えてもらえますか? ご回答をお待ちしています。 コスミン Re: Uart using DMA is not working correct on S32K314 こんにちは、@ CosminSbera 1. DMA要求オプションを有効にするのを忘れないでください。 2. 「プラットフォーム」コンポーネントでLPUART0_IRQn割り込みを有効にするのを忘れないでください。 「プラットフォーム」->」LPUART0_IRQn--LPUART_UART_IP_0_IRQHandler」

i.MX93プロセッサ向けパラレルプログラミングシステム 私はIMX93プロセッサを使っていて、2台のボードを同時にプログラムする必要があります。しかし、それを試すと、ボードの1つでHID(W)エラーが発生し、他のボードのフラッシュは正常に完了します。 uu.exe -m 1:10 -b uuu-xxxxxx.flash uu.exe -m 1:7 -b uuu-xxxxxx.flash パス(1:10,1:7)を指定しても同じエラーが発生します。 案内してください。 Re: Parallel Programming System for i.MX93 Processors こんにちは、 次のコマンドを実行してみてください。 uuu -d -m 1:7 -m 1:10 uuu-xxxxxx.flash 何が手に入るの？ uuu -lsusb 列挙されたポート番号に従って、正しいポート番号を使用していることを確認してください。 よろしくお願いいたします。