Android 14+ performance issues (Janky frames) Hello,  We are using a custom board based on IMX8MP and noticed some performance issues when upgrading from Android 11 to Android 14. We noticed that transitions and animations feel laggy when using the device.  For evaluation, we performed the same tests on the IMX8MP EVK board. We were taking a look at the gfxinfo of the device and saw that there are huge differences in Janky frames, Number High input latency, and GPU percentile.  Android 11:  Total frames rendered: 1372 Janky frames: 204 (14.87%) 50th percentile: 7ms 90th percentile: 34ms 95th percentile: 77ms 99th percentile: 200ms Number Missed Vsync: 91 Number High input latency: 274 Number Slow UI thread: 89 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 61 Number Frame deadline missed: 145 50th gpu percentile: 2ms 90th gpu percentile: 3ms 95th gpu percentile: 3ms 99th gpu percentile: 4ms Android 14:  Total frames rendered: 1136 Janky frames: 429 (37.76%) Janky frames (legacy): 600 (52.82%) 50th percentile: 29ms 90th percentile: 73ms 95th percentile: 113ms 99th percentile: 250ms Number Missed Vsync: 130 Number High input latency: 755 Number Slow UI thread: 254 Number Slow bitmap uploads: 3 Number Slow issue draw commands: 376 Number Frame deadline missed: 429 Number Frame deadline missed (legacy): 342 50th gpu percentile: 4ms 90th gpu percentile: 23ms 95th gpu percentile: 23ms 99th gpu percentile: 24ms Android 15: Total frames rendered: 1093 Janky frames: 318 (29.09%) Janky frames (legacy): 639 (58.46%) 50th percentile: 18ms 90th percentile: 97ms 95th percentile: 105ms 99th percentile: 109ms Number Missed Vsync: 221 Number High input latency: 1028 Number Slow UI thread: 145 Number Slow bitmap uploads: 0 Number Slow issue draw commands: 317 Number Frame deadline missed: 318 Number Frame deadline missed (legacy): 309 50th gpu percentile: 11ms 90th gpu percentile: 4950ms 95th gpu percentile: 4950ms 99th gpu percentile: 4950ms Is this a known issue, or are there any hints on how we could solve this issue? Android Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Thanks for the data, we will do an internal research and get back to you when we find anything. Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza ,  I did tests on A16 and A13. Android 16:  Total frames rendered: 946 Janky frames: 414 (43.76%) Janky frames (legacy): 631 (66.70%) 50th percentile: 30ms 90th percentile: 113ms 95th percentile: 200ms 99th percentile: 350ms Number Missed Vsync: 180 Number High input latency: 764 Number Slow UI thread: 265 Number Slow bitmap uploads: 7 Number Slow issue draw commands: 384 Number Frame deadline missed: 414 Number Frame deadline missed (legacy): 366 50th gpu percentile: 11ms 90th gpu percentile: 4950ms 95th gpu percentile: 4950ms 99th gpu percentile: 4950ms Android 13:  Total frames rendered: 1000 Janky frames: 284 (28.40%) Janky frames (legacy): 397 (39.70%) 50th percentile: 12ms 90th percentile: 69ms 95th percentile: 129ms 99th percentile: 250ms Number Missed Vsync: 122 Number High input latency: 446 Number Slow UI thread: 176 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 242 Number Frame deadline missed: 284 Number Frame deadline missed (legacy): 248 50th gpu percentile: 3ms 90th gpu percentile: 23ms 95th gpu percentile: 24ms 99th gpu percentile: 4950ms Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Yes, please run the same test and forward the results. Regards, Juan Jorge Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza , Thanks for the reply! As a test for the Janky frames, we just started the system and rebooted once, so we don't have issues caused by any first boot optimizations, and moved around inside the Settings App. Then we read out the gfxinfos through: adb shell dumpsys gfxinfo If you would say this is a valid test, I am happy to perform it on A12, A13, and A16. Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, No, that shouldn't be an issue.  Could you share the test used to test the Janky frame? Also if possible, could you please run the same test on A12 and A13? It will help us to track down where the issue begins to appear. Regards, Juan Jorge Re: Android 14+ performance issues (Janky frames) Hi @danielchen , The Display only supports one resolution, which is 720p. I would guess this shouldn't be the issue. Re: Android 14+ performance issues (Janky frames) Hi @JK-dev   what display resolution you are using?   Could you check if lowering it  helps reduce GPU/CPU load and improves overall performance. Re: Android 14+ performance issues (Janky frames) @danielchen Thanks for the reply. I saw this post before, but for my understanding, it would mean that if we are using a user build instead of a userdebug build, the issue should be gone; however, this isn't the case. For us, it seems to be the same in user and userdebug images; is there a different way to turn off debuggable for the whole system? Re: Android 14+ performance issues (Janky frames) Hi @JK-dev  Yes,  this is a known issue on Android 14+ for i.mx8mp. Android 14+ enables more extensive tracing and memory tracking for debug apps,  which can slow down rendering by 1.5x-2x compared to previous versions.  This affects UI thread, GPU scheduling, and input latency. Please refer to below link for the quick workaround and more information. https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Low-Performance-on-Android-14/ta-p/1991262 Regards Daniel Re: Android 14+ performance issues (Janky frames) Hello @JK-dev, Sorry for the late response it took us a while to optimize the GUI for the 8MP. The patch "0001-MA-22638-Update-expected-present-time-to-optimize-re.patch" is used to optimize the refresh rate in framework/native. Another two patches need to be applied in vendor/nxp-opensource/imx   Please let us know if that solve your problem Re: Android 14+ performance issues (Janky frames) Hi @JuanJorge_Mendoza , Sorry for the late reply, I was on holiday. Thank you for the patches! We tested your patches, and we can see that there is a slight improvement when navigating around.  However, when it comes to higher loads or more Animations, the system remains very laggy, and most frames arrive way too late. To reproduce this, you could, for example, go to Settings -> Apps -> All Apps -> Include System Apps and scroll through that list. You will see that more than 50% of the frames are late.  Re: Android 14+ performance issues (Janky frames) Hey @joanxie , No, the performance is slightly better than before.  Without the patches:  Total frames rendered: 1015 Janky frames: 376 (37.04%) Janky frames (legacy): 731 (72.02%) 50th percentile: 31ms 90th percentile: 150ms 95th percentile: 200ms 99th percentile: 400ms Number Missed Vsync: 262 Number High input latency: 1167 Number Slow UI thread: 368 Number Slow bitmap uploads: 1 Number Slow issue draw commands: 26 Number Frame deadline missed: 376 Number Frame deadline missed (legacy): 386 50th gpu percentile: 4ms 90th gpu percentile: 11ms 95th gpu percentile: 11ms 99th gpu percentile: 12ms   With the patches:  Total frames rendered: 2078 Janky frames: 594 (28.59%) Janky frames (legacy): 1050 (50.53%) 50th percentile: 21ms 90th percentile: 133ms 95th percentile: 200ms 99th percentile: 400ms Number Missed Vsync: 367 Number High input latency: 2045 Number Slow UI thread: 567 Number Slow bitmap uploads: 4 Number Slow issue draw commands: 68 Number Frame deadline missed: 594 Number Frame deadline missed (legacy): 580 50th gpu percentile: 4ms 90th gpu percentile: 11ms 95th gpu percentile: 11ms 99th gpu percentile: 12ms   As you see, the patch reduces the number of Janky frames, and the 50% percentile is better, but still not sufficient. Re: Android 14+ performance issues (Janky frames) when it comes to higher loads or more Animations > is it worse than before? Is there any specific performance comparison data between using this patch and not using this patch? Re: Android 14+ performance issues (Janky frames) did your operation via UI? if yes, do you have any script or something specific steps? then I can forward to the android team to validate and debug further Re: Android 14+ performance issues (Janky frames) Hey @joanxie, It's basically the same test we did before. What would be a test for the Android team that is sufficient? Re: Android 14+ performance issues (Janky frames) they hope you can give them a script to run the performance test and show the detailed performance degradation data, then they can reproduce this, because they don't find the same issue on their side Re: Android 14+ performance issues (Janky frames) There is now a solution for this issue: https://www.linkedin.com/posts/kalkov_embeddedandroid-nxp-aosp-share-7490309949391089664-ifxq/?utm_source=share&utm_medium=member_desktop&rcm=ACoAADU1d0wBcGPG6tNYlHxJaSFzHqMEI3XBUJY https://emteria.com/blog/nxp-imx8m-plus-android-scroll-fix

How to Test TX PAUSE Frames with DPDK enetc4 VF Driver on i.MX95 / i.MX9x Series This post walks through end-to-end steps to enable and verify TX PAUSE frame (IEEE 802.3x flow control) generation on the i.MX95 / i.MX9x series using DPDK 25.11 with the enetc4 VF driver and a Spirent traffic generator. I also share an optional debug patch that lowers the PAUSE trigger threshold for quick lab reproduction and adds register readback prints to dmesg. --- Overview -------- On i.MX95 the ENETC4 Ethernet controller uses a PF/VF split: - The kernel PF driver (fsl_enetc4, Linux 6.18+) owns the MAC, PHY negotiation, and PAUSE configuration. - The DPDK VF driver (net/enetc, DPDK 25.11) owns the receive rings in the DPDK application. When the link partner negotiates PAUSE, the kernel PF configures the MAC and notifies the DPDK VF via a mailbox message. The VF then enables congestion signaling on its Rx rings. When incoming traffic fills those rings past the configured threshold, the hardware automatically emits PAUSE frames toward the sender. The trigger chain looks like this: High-rate ingress traffic fills VF Rx rings --> ICM fill level crosses PPAUONTR threshold --> MAC emits IEEE 802.3x PAUSE frame to link partner --> link partner pauses its transmitter --- Hardware Setup -------------- - i.MX95 EVK (or any i.MX9x board with ENETC4) - 10G SFP+ DAC cable or fiber between i.MX95 ENETC4 port and Spirent TestCenter port - Spirent TestCenter (or equivalent traffic generator with flow control capture) Software versions used in this guide: - Kernel: Linux 6.18+ with fsl_enetc4 PF driver - DPDK: 25.11 (net/enetc VF PMD) - ethtool: 6.x --- Step 1 — Enable PAUSE on the Kernel PF Interface ------------------------------------------------- The kernel PF interface (typically eth1 for ENETC4 port 1) must have TX PAUSE enabled before the link comes up so that phylink can negotiate it with the link partner. # Identify the kernel PF interface ip link show | grep -E "eth[0-9]" # Enable TX and RX PAUSE (autoneg lets the link partner also advertise PAUSE, it is off since we are using spirent) ethtool -A eth1 tx on rx on autoneg off # Bring the link up ip link set eth1 up # After link is up, verify PAUSE was negotiated ethtool -a eth1 Expected output: Pause parameters for eth1: Autonegotiate: off RX: on TX: on If TX shows "off" after link up, the link partner may not have advertised PAUSE capability. Try forcing it: ethtool -A eth1 tx on rx on autoneg off --- Step 2 — Verify ethtool Statistics Are Available ------------------------------------------------- Confirm that the ethtool stats interface is working before starting traffic: ethtool -S eth1 | grep -E "txpf|rxpf|pause" You should see counters like txpf_frames and rxpf_frames (both 0 at this point). If you see "no stats available", verify your kernel build includes the ethtool ops for enetc4. --- Step 3 — Bind the DPDK VF to igb_uio ----------------------------------- note bootargs: must have iommu_passthrough=1 # Load the VFIO driver modprobe igb_uio echo 1 > /sys/bus/pci/devices/0002\:00\:10.0/sriov_numvfs echo igb_uio > /sys/bus/pci/devices/0002\:00\:12.0/driver_override echo 0002:00:12.0 > /sys/bus/pci/drivers/fsl_enetc_vf/unbind echo 0002:00:12.0 > /sys/bus/pci/drivers/igb_uio/bind ip link set eth1 vf 0 trust on --- Step 4 — Allocate Hugepages ----------------------------- # 4 x 1 GB hugepages (recommended for 10G line-rate testing) echo 4 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages mount -t hugetlbfs none /dev/hugepages # Verify allocation grep HugePages /proc/meminfo # HugePages_Total: 4 # HugePages_Free: 4 --- Step 5 — Start testpmd ------------------------ For PAUSE testing the goal is to build up backpressure in the VF Rx rings so the ICM congestion threshold is crossed. Use rxonly mode with a small Rx descriptor count so the ring fills up quickly under load. testpmd \ -l 0-3 -n 4 \ -a 0002:00:12.0 \ -- \ --rxd=256 \ --txd=512 \ --nb-cores=2 \ --rxq=1 --txq=1 \ --forward-mode=rxonly \ --stats-period=5 Inside the testpmd prompt: testpmd> set fwd rxonly testpmd> start testpmd is now receiving and the DPDK VF Rx rings will fill under high-rate ingress traffic, generating the congestion signal that drives PAUSE frame emission. --- check stats via: ethtool --include-statistics -a eth1 Step 6 — Configure Spirent TestCenter --------------------------------------- Spirent port sending TO i.MX95 (ingress traffic): - Frame size: 64 bytes or smaller (smaller frames fill rings faster) - Rate: 100% line rate (10 Gbps) - Frame type: Ethernet II / IPv4 - Destination MAC: MAC address of the i.MX95 ENETC4 VF interface - Destination IP: IP address assigned to the i.MX95 interface Spirent port receiving FROM i.MX95 (PAUSE capture): - Port Properties → Flow Control → Enable IEEE 802.3x PAUSE - Enable Capture → Filter EtherType: 0x8808 - Results → Port Results → watch "Flow Control Frames Received" This counter increments every time a PAUSE frame arrives from i.MX95. - Optional: Results → Flow Analysis → check "Pause Duration (quanta)" Expected value: ~32767 (0x7FFF) Alternative capture without Spirent license: # On any PC with a tap on the wire tcpdump -i eth0 'ether proto 0x8808' -v # PAUSE frame: dst 01:80:c2:00:00:01, EtherType 0x8808, opcode 0x0001 --- Step 7 — Verify PAUSE Frames Are Being Sent --------------------------------------------- Start Spirent at 100% line rate, then on the i.MX95 host run: watch -n 1 'ethtool -S eth1 | grep -E "txpf|rxpf"' Expected output when PAUSE is active: txpf_frames: <-- TX PAUSE frames sent by i.MX95 On Spirent, "Flow Control Frames Received" should be incrementing at the same time. --- Optional — Debug Patch for Faster Lab Reproduction ---------------------------------------------------- I am attaching a patch file to this post. This useful for bring-up and debug — this is not required for production use. Adds dev_info() prints to enetc4_set_tx_pause() and enetc_set_congestion_mode() in the kernel driver. After link-up you will see in dmesg: fsl_enetc4 0000:00:00.0: enetc4_set_tx_pause: tx_pause=1 fsl_enetc4 0000:00:00.0: PPAUONTR = 0x00001000 fsl_enetc4 0000:00:00.0: PPAUOFFTR = 0x00000400 fsl_enetc4 0000:00:00.0: PM_CMD_CFG(0) = 0x000000c3 TX_EN=1 RX_EN=1 TXP=0 fsl_enetc4 0000:00:00.0: set_congestion_mode: enable=1 num_rx_rings=1 fsl_enetc4 0000:00:00.0: ring[0] readback rbmr=0x00000010 This confirms the kernel PF configured the MAC and set the RBMR congestion mode bit on the PF rings. The DPDK VF should receive the same setting via mailbox. also Lowers the PAUSE trigger threshold to PPAUONTR=4096 bytes so that PAUSE frames are generated at much lower traffic rates — useful for quick lab tests without needing a full 10G line-rate traffic generator. Also adds ICM register definitions (PRXBCR, PRXBCHWMR) so you can observe the ICM fill level via ethtool -S. After applying this patch, check ICM fill level during traffic: ethtool -S eth1 | grep -E "prxbcr|prxbchwmr" # prxbcr_bytes: # prxbchwmr_bytes: When prxbchwmr_bytes >= 4096, the threshold has been crossed and PAUSE should fire. --- Key Register Reference (ENETC4) --------------------------------- Note: ENETC4 register offsets start at 0x5000 for MAC/PM registers. This is different from ENETC v1 which uses 0x8000. Use ethtool -S for PM counters since PF BAR0 is IOMMU-protected on i.MX95. Register Offset Description PM_CMD_CFG(0) 0x5008 MAC config register (TXP = BIT 15) PM_TXPF(0) 0x5218 TX PAUSE frames sent (64-bit) PM_RXPF(0) 0x5118 RX PAUSE frames received (64-bit) PPAUONTR 0x108 ICM fill level threshold to START PAUSE PPAUOFFTR 0x10C ICM fill level threshold to STOP PAUSE PRXBCR 0x128 Current ICM RX fill level (live, read-only) PRXBCHWMR 0x12C ICM RX peak fill since boot (read-only) For VF Rx ring registers, VF BAR0 is accessible via devmem2: # Check RBMR of VF ring 0 — BIT 4 = CM (congestion mode) # Replace VF_BAR0 with your actual address (find via /sys/bus/pci/devices/.../resource0) devmem2 w # Expected when PAUSE is active: 0x00000010 --- Environment ----------- SoC: i.MX95, i.MX943 (i.MX9x series with ENETC4) Kernel: Linux 6.18+ (fsl_enetc4 PF driver) DPDK: 25.11 (net/enetc VF PMD) Tool: testpmd, ethtool 6.x, Spirent TestCenter Hope this helps. Happy to answer questions on the setup.

Lab 1 – Low Power is a Superpower

（TC358748）并行至CSI2视频桥接器出现故障 你好， 我正在做一个项目，需要将 FPGA 连接到我们定制的 i.MX8MP 板。我正在尝试修改 tc358746（并行 -> CSI2）驱动程序，以支持我们的 yocto lf-5.15.71 版本。 我希望视频管道（FPGA (YUV4:2:2) -> bridge (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0）目前以 YUV4:2:2 格式输出 1920x1080@30Hz，但我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 v4l-subdev1 不会出现在 v4l2 设备列表中。 请查看网桥的 media-ctl 输出和 dmesg 日志，非常感谢您能提供任何故障排除方面的见解。 root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - 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":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath 你解决这个问题了吗？如果可以的话，能否分享一下您的TC358748 内核驱动代码和最新的设备树文件？因为我也遇到了同样的问题。非常感谢！ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你不能随意选择格式，这取决于你的桥接端设置。检查你的 TC358748 寄存器，看看你在那里设置的是什么格式，然后选择 imx8mp 端的正确格式。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好， 很抱歉回复晚了。我按照您建议的格式使用了数据，现在可以看到一些数据，但正如您从附件示例中看到的那样。它还不完美。我尝试了不同的 MEDIA_BUS_FMT 和 V4L2_PIX_FMT，也尝试了不同的频率（23.98、50、60 等）。 MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8。 V4L2_PIX_FMT_YUYV / UYVY / YUV422P。 但从 dmesg 日志中可以看到，有很多 CRC 错误。另外，我注意到从 media-ctl -p 中，除了桥接节点之外，其他节点都没有格式信息。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 或许你需要考虑一下格式。我检查了 CHNL_IMG_CTRL，它是 100000 字节的 YUV422_1P8P 格式，每个颜色元器件 8 位；单平面，YUV 交错打包字节。 https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c { 。姓名= "YUYV-16", .fourcc= V4L2_PIX_FMT_YUYV， 。深度= { 16 }, 。颜色= MXC_ISI_OUT_FMT_YUV422_1P8P， .memplanes= 1， .colplanes= 1， 。对齐= 3， .mbus_code= MEDIA_BUS_FMT_YUYV8_1X16， } 你应该从 ISI 选择此格式作为默认格式，并且也要检查你的桥接端。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 --> 这只是为了指示函数调用，在该行下面您可以看到启用 4 个数据通道和 1 个时钟通道的这些行。 tc358748 2-000e：CLW_CNTRL：0 0x140 tc358748 2-000e：D0W_CNTRL：0 0x144 tc358748 2-000e：D1W_CNTRL：0 0x148 tc358748 2-000e：D2W_CNTRL：0 0x14c tc358748 2-000e：D3W_CNTRL：0 0x150 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> 我们使用 148.5MHz。 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 --> hs-settle 值是根据以下公式设置的：（像素速率 * 每像素位数）/（通道数 * 2），即 148.5 pixclk * 16bpp / 2 * 4 通道 = 475.2 MBits/s所以 RX_HS_SETTLE 为 10。 此外，我们板上的数据通道也互换了。修改之后，当我使用 Gstreamer 或 v4l2-ctl 用上市，不用发布视频捕获时，会出现绿屏。 gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge 我检查了您的 dts 文件设置，TC358748 有 4 个数据通道，但日志文件只显示 1 个通道（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1），请再次检查。 在你的 csi&isi dump.txt 文件中，[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(硬编码>: 74250000MHz)) 但在 gst-lauch-1.0.txt 中，[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) 那么你究竟设定的是哪个时间呢？我查看了你的DTS文件，你设置了74.25M像素时钟，我建议你测量一下时钟频率，并设置hs-settle和clk-settle。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 你好@joanxie ， 是的，TC358748 的输入信号正常，我看到 TC358748 有信号输出。 要开始使用 GStreamer 进行捕获： gst-用上市，不用发布-1.0v4l2src 设备=/dev/video2 ！video/x-raw，宽度=1920，高度=1080！自动视频接收器 另一个问题是，当在 dts 中启用 ISI 节点时，系统会在几分钟后挂起。 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge 目前我无法使用 Gstreamer 或 v4l2-ctl 捕获任何帧。 您使用的是哪种 GStreamer 命令？您收到了什么消息？能否确认一下来自 TC358748 的信号是否完全正常？你检查过TC358748那边了吗？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查找他的注册表转储文件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 从imx8mp这边来看，我没有发现任何问题，连接设置正确。 [ 7.992257] mx8-img-md：已注册传感器子设备：tc358748 2-000e (1) [ 8.002921] mx8-img-md：创建链接 [mxc_isi.0]=> [mxc_isi.0.捕获] [ 8.018980] mx8-img-md：创建链接 [mxc-mipi-csi2.0] [[ ## completed ##]]=> [mxc_isi.0] [ 8.025519] mx8-img-md: 创建链接 [tc358748 2-000e] => [mxc-mipi-csi2.0] [ 8.032634] mxc-md 32c00000.总线:camera:mxc_md_create_links 实际上，isi0 是为 mipi csi0 设计的，在 mipi csi0 中添加 port@1 后，当前的 电路板支持包 应该会出现一些错误，所以你是否更改了任何 mipi 驱动程序？但由于您的设置正确，这应该不会影响您的数据捕获。您可以检查 FPGA 端，确认其是否设置了正确的时钟或发送了正确的数据，并仔细检查 TC358748 的寄存器。此外，请导出 MIPI CSI 和 ISI 寄存器，以检查是否存在任何错误位。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 请查收附件。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge 能否将日志文件和DTS文件发送给我？

I want all the pin delays for the MIMX9352CVVXMAC. I want all the pin delays for the MIMX9352CVVXMAC. Re: 我想要MIMX9352CVVXMAC的所有的pindelay Please following the design guide in the IMX93HDG and refer to our EVK design. Re: 我想要MIMX9352CVVXMAC的所有的pindelay Are there any other versions? Re: 我想要MIMX9352CVVXMAC的所有的pindelay Sorry we do not have this excel for it. Re: 我想要MIMX9352CVVXMAC的所有的pindelay I want the Excel version Re: 我想要MIMX9352CVVXMAC的所有的pindelay Hi @ABC007 , Please following the IMX93HDG.pdf, I attach it to you. Hope can do help for you Wish you have a nice day Best Regards Rita

Trouble with (TC358748) Parallel to CSI2 video bridge Hello, I am working on a project that requires interfacing an FPGA to our custom i.MX8MP board. I am trying to modify the tc358746 (Parallel -> CSI2) driver to support for our yocto lf-5.15.71 version. I want the video pipeline (FPGA (YUV4:2:2) -> bridge (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0) to output 1920x1080@30Hz with YUV4:2:2 format for now but I am unable to capture any frames using Gstreamer or v4l2-ctl. The v4l-subdev1 won't show up in the v4l2 device list Please find the media-ctl output and the dmesg log for the bridge, Any insights on troubleshooting the issue is greatly appreciated. root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - 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":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath  Were you able to solve the problem? if possible, could you please share your TC358748 kernel driver code and latest devicetree file? Because I am having trouble with the same issue. Many thanks Re: Trouble with (TC358748) Parallel to CSI2 video bridge you couldn't choose any format you want, depends on what your bridge side, check your TC358748 register, what format did you set there, then choose the correct format of imx8mp side Re: Trouble with (TC358748) Parallel to CSI2 video bridge Hello, Sorry for the delayed response. I used the format as you suggested and now I see some data but as you can see from the attached sample. It is still not perfect. I tried different MEDIA_BUS_FMT and V4L2_PIX_FMT's and also tried different frequencies (23.98, 50, 60, etc). MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8. V4L2_PIX_FMT_YUYV / UYVY / YUV422P. But as you can see from the dmesg log there are a lot of CRC error's. Also I notice that from media-ctl -p other than the bridge node none of them have format information. Re: Trouble with (TC358748) Parallel to CSI2 video bridge maybe you need consider the format, I checked the CHNL_IMG_CTRL, which is 100000b - YUV422_1P8P with 8-bits per color component; 1-plane, YUV interleaved packed bytes https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c { .name = "YUYV-16", .fourcc = V4L2_PIX_FMT_YUYV, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_YUV422_1P8P, .memplanes = 1, .colplanes = 1, .align = 3, .mbus_code = MEDIA_BUS_FMT_YUYV8_1X16, } you should choose this format from ISI as default, and check your bridge side too Re: Trouble with (TC358748) Parallel to CSI2 video bridge checked your dts file settings 4 data lane for TC358748, but the logfile shows only 1 lane([ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1), pls double check it --> That is just to indicate the function call, below that line you can see these line which enables 4 data lanes and 1 clock lane. tc358748 2-000e: CLW_CNTRL: 0 0x140 tc358748 2-000e: D0W_CNTRL: 0 0x144 tc358748 2-000e: D1W_CNTRL: 0 0x148 tc358748 2-000e: D2W_CNTRL: 0 0x14c tc358748 2-000e: D3W_CNTRL: 0 0x150 in your csi&isi dump.txt, [ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 74250000MHz)) but in the gst-lauch-1.0.txt, [ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> We are using 148.5MHz. so what clock you set indeed? I checked your dts, you set 74.25M pixel clock, I suggest that you can measure the clock and set the hs-settle and clk-settle --> hs-settle value was set based on this (pixel rate * bits per pixel) / (number of lanes * 2) which is 148.5 pixclk *16bpp / 2 * 4 lane = 475.2MBits/s so RX_HS_SETTLE is 10. Also data lanes on our board were interchanged. So after this modification now I am getting a green screen when I launch video capture using Gstreamer or v4l2-ctl gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge checked your dts file settings 4 data lane for TC358748, but the logfile shows only 1 lane([ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1), pls double check it in your csi&isi dump.txt, [ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 74250000MHz)) but in the gst-lauch-1.0.txt, [ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) so what clock you set indeed? I checked your dts, you set 74.25M pixel clock, I suggest that you can measure the clock and set the hs-settle and clk-settle Re: Trouble with (TC358748) Parallel to CSI2 video bridge Hello @joanxie, Yes the input signals to TC358748 is okay and I see signals coming out of TC358748. To start capture using Gstreamer: gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-raw,width=1920,height=1080 ! autovideosink Another issue is when the ISI node is enabled in the dts the system hangs after few minutes. 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge for now but I am unable to capture any frames using Gstreamer or v4l2-ctl. > what kind gstreamer command do you use and what message do you get? could you confirm if your signal from TC358748 is total fine? did you check TC358748 side？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge Please find he register dump. Re: Trouble with (TC358748) Parallel to CSI2 video bridge from imx8mp side, I don't find any issue,  the connection set up correctly [ 7.992257] mx8-img-md: Registered sensor subdevice: tc358748 2-000e (1) [ 8.002921] mx8-img-md: created link [mxc_isi.0] => [mxc_isi.0.capture] [ 8.018980] mx8-img-md: created link [mxc-mipi-csi2.0] => [mxc_isi.0] [ 8.025519] mx8-img-md: created link [tc358748 2-000e] => [mxc-mipi-csi2.0] [ 8.032634] mxc-md 32c00000.bus:camera: mxc_md_create_links in fact isi0 is for mipi csi0, after you add port@1 in the mipi csi0, you should get some errors in the current bsp, so do you change any mipi driver? but since you set up correctly, this shouldn't affect your capture, you can check the FPGA side, to check if they set the correct clock or send the correct data, to double review the registers of TC358748, also pls dump the mipi csi and ISI registers to check any error bits Re: Trouble with (TC358748) Parallel to CSI2 video bridge Please find the attached files. Re: Trouble with (TC358748) Parallel to CSI2 video bridge could you send the logfile and dts file to me

(TC358748) CSI2ビデオブリッジの並列接続に問題があります こんにちは、 私は、FPGAを当社独自のi.MX8MPボードに接続する必要があるプロジェクトに取り組んでいます。私はtc358746(Parallel -> CSI2)ドライバをYocto lf-5.15.71バージョンにサポートしようとしています。 今のところ、ビデオパイプライン (FPGA (YUV4:2:2) -> ブリッジ (YUV4:2:2/4-lane) -> mipi_csi0 -> isi0) から YUV4:2:2 フォーマットで 1920x1080@30Hz を出力したいのですが、Gstreamer や v4l2-ctl を使用してフレームをキャプチャすることができません。 v4l-subdev1はv4l2デバイスリストに表示されません ブリッジのmedia-ctl出力とdmesgログを探してください。問題のトラブルシューティングに関するご意見をいただけると大変ありがたいです。 root@:~$ media-ctl -p Media controller API version 5.15.71 Media device information ------------------------ driver mxc-md model FSL Capture Media Device serial bus info hw revision 0x0 driver version 5.15.71 Device topology - entity 1: mxc_isi.0 (16 pads, 2 links) type V4L2 subdev subtype Unknown flags 0 pad0: Sink <- "mxc-mipi-csi2.0":4 [ENABLED] pad1: Sink pad2: Sink pad3: Sink pad4: Sink pad5: Sink pad6: Sink pad7: Sink pad8: Sink pad9: Sink pad10: Sink pad11: Sink pad12: Source -> "mxc_isi.0.capture":0 [ENABLED] pad13: Source pad14: Source pad15: Sink - 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":12 [ENABLED] - entity 22: mxc-mipi-csi2.0 (8 pads, 2 links) type Node subtype V4L flags 0 device node name /dev/v4l-subdev0 pad0: Sink <- "tc358748 2-000e":0 [ENABLED,IMMUTABLE] pad1: Sink pad2: Sink pad3: Sink pad4: Source -> "mxc_isi.0":0 [ENABLED] pad5: Source pad6: Source pad7: Source - entity 31: tc358748 2-000e (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: Source [fmt:UYVY8_2X8/1920x1080@1/30 field:none colorspace:srgb] -> "mxc-mipi-csi2.0":0 [ENABLED,IMMUTABLE] root@:~$ v4l2-ctl --list-devices (): /dev/v4l-subdev0 mxc-isi-cap (platform:32e00000.isi:cap_devic): /dev/video2 FSL Capture Media Device (platform:mxc-md): /dev/media0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video1 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video0 root@:~$ v4l2-ctl --device /dev/video2 --list-formats-ext ioctl: VIDIOC_ENUM_FMT Type: Video Capture Multiplanar [3]: 'YUYV' (YUYV 4:2:2) Size: Discrete 1920x1080 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.033s (30.000 fps) root@:~$ v4l2-ctl -d /dev/video2 --all Driver Info: Driver name : mxc-isi-cap Card type : mxc-isi-cap Bus info : platform:32e00000.isi:cap_devic Driver version : 5.15.71 Capabilities : 0x84201000 Video Capture Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04201000 Video Capture Multiplanar Streaming Extended Pix Format Media Driver Info: Driver name : mxc-md Model : FSL Capture Media Device Serial : Bus info : Media version : 5.15.71 Hardware revision: 0x00000000 (0) Driver version : 5.15.71 Interface Info: ID : 0x03000014 Type : V4L Video Entity Info: ID : 0x00000012 (18) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000013 : 0: Sink Link 0x02000021: from remote pad 0x100000e of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled Priority: 2 Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'RGBP' (16-bit RGB 5-6-5) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : Default YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 Crop Capability Video Output: Bounds : Left 0, Top 0, Width 1920, Height 1080 Default : Left 0, Top 0, Width 1920, Height 1080 Pixel Aspect: 1/1 Selection Video Output: compose, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_default, Left 0, Top 0, Width 1920, Height 1080, Flags: Selection Video Output: compose_bounds, Left 0, Top 0, Width 1920, Height 1080, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 vertical_flip 0x00980915 (bool) : default=0 value=0 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 [ 15.547696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.966015] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 . . . [ 26.968164] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968181] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968195] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.968210] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 26.971188] mxc_isi.0: Not match format, set default [ 26.971199] mxc_isi.0: Not match format, set default [ 27.305025] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305150] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305352] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305392] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305442] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.305507] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.309455] enter tc358748_s_power = ON [ 27.309471] tc358748 2-000e: tc358748_enable_hw [ 27.311682] tc358748 2-000e: tc358748_set_pad_format [ 27.311696] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.311705] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.316716] bypass csc [ 27.316724] input fmt YUV4 [ 27.316728] output fmt YUYV [ 27.667770] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667876] tc358748 2-000e: tc358748_set_pad_format [ 27.667882] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.667889] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.672900] bypass csc [ 27.672909] input fmt YUV4 [ 27.672912] output fmt YUYV [ 27.672922] enter tc358748_s_power = OFF [ 27.672929] tc358748 2-000e: tc358748_disable_hw [ 27.701511] enter tc358748_s_power = ON [ 27.701530] tc358748 2-000e: tc358748_enable_hw [ 27.703406] tc358748 2-000e: tc358748_set_pad_format [ 27.703418] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.703427] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 27.708440] bypass csc [ 27.708451] input fmt YUV4 [ 27.708456] output fmt YUYV [ 28.035292] tc358748 2-000e: [tc358748_stream,1152]: Stream enable ... [ 28.035309] tc358748 2-000e: tc358748_set_pll [ 28.035313] tc358748 2-000e: tc358748_calc_pll [ 28.035382] tc358748 2-000e: PLL: refclk 10000000, fbd 88, prd 0, frs 1 [ 28.035388] tc358748 2-000e: PLL: pll_clk: 445000000, CSIClk 222500000, CSIByteClk 55625000 [ 28.035393] tc358748 2-000e: PLL: pclk 74166666 (FPGA(Hardcode=>: 74250000MHz)) [ 28.037869] tc358748 2-000e: tc358748_sw_reset [ 28.038566] tc358748 2-000e: tc358748_apply_misc_config [ 28.038902] tc358748 2-000e: DATAFMT: 0x60 [ 28.039301] tc358748 2-000e: CONFCTL[PDATAF]: 0x0 [ 28.039642] tc358748 2-000e: FIFOCTL: 0x20 [ 28.039976] tc358748 2-000e: WORDCNT: 0xf00 [ 28.039984] tc358748 2-000e: tc358748_enable_csi_lanes: 1 [ 28.040454] tc358748 2-000e: CLW_CNTRL: 0 0x140 [ 28.040777] tc358748 2-000e: D0W_CNTRL: 0 0x144 [ 28.041158] tc358748 2-000e: D1W_CNTRL: 0 0x148 [ 28.041538] tc358748 2-000e: D2W_CNTRL: 0 0x14c [ 28.041899] tc358748 2-000e: D3W_CNTRL: 0 0x150 [ 28.041908] tc358748 2-000e: tc358748_apply_dphy_config [ 28.041912] tc358748 2-000e: dsiclk_nsk: 4494 [ 28.041916] tc358748 2-000e: ui_nsk: 2247 [ 28.041920] tc358748 2-000e: csibclk_nsk: 17977 [ 28.041924] tc358748 2-000e: phy_delay_nsk: 26965 [ 28.042278] tc358748 2-000e: LINEINITCNT: 0x15ba [ 28.042661] tc358748 2-000e: LPTXTIMECNT: 0x2 [ 28.043043] tc358748 2-000e: TCLK_HEADERCNT: 0xa03 [ 28.043456] tc358748 2-000e: TCLK_TRAILCNT: 0xffffffff [ 28.043803] tc358748 2-000e: THS_HEADERCNT: 0xffffee03 [ 28.044156] tc358748 2-000e: TWAKEUP: 0x49e0 [ 28.044535] tc358748 2-000e: TCLK_POSTCNT: 0x7 [ 28.044914] tc358748 2-000e: THS_TRAILCNT: 0x1 [ 28.045298] tc358748 2-000e: HSTXVREGEN: 0x1f [ 28.045307] tc358748 2-000e: tc358748_enable_csi_module: 1 [ 28.045680] tc358748 2-000e: STARTCNTRL: 0x1 [ 28.046025] tc358748 2-000e: CSI_START: 0x1 [ 28.046407] tc358748 2-000e: CSI_CONFW_REG: 2734719110 (0x518) [ 32.176687] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.176772] tc358748 2-000e: tc358748_get_pad_format code=0x2006, w/h=(1920,1080), colorspace=8, field=1 [ 32.178272] tc358748 2-000e: [tc358748_stream,1152]: Stream disable ... [ 32.240654] enter tc358748_s_power = OFF [ 32.240673] tc358748 2-000e: tc358748_disable_hw [ 60.422080] imx-sdma 30bd0000.dma-controller: firmware found. [ 60.422080] imx-sdma 30e10000.dma-controller: firmware found. [ 60.422326] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 66.531400] cfg80211: failed to load regulatory.db i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Trouble with (TC358748) Parallel to CSI2 video bridge @shaswath 問題は解決できましたか？可能であれば、TC358748カーネルドライバーコードと最新のDevicetreeファイルを共有していただけませんか?私も同じ問題で困っています。どうもありがとうございます Re: Trouble with (TC358748) Parallel to CSI2 video bridge 任意のフォーマットを選択できるわけではありません。ブリッジ側の設定によります。TC358748レジスタを確認し、そこに設定したフォーマットを確認してから、imx8mp側の正しいフォーマットを選択してください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge こんにちは、 返信が遅くなり申し訳ありません。ご提案のフォーマットを使いましたが、添付のサンプルからもCANが見えるように、いくつかのデータが見えます。まだ完璧ではない。MEDIA_BUS_FMTとV4L2_PIX_FMTをいろいろ試してみたり、周波数もいろいろ試してみたりしました（23.98、50、60など）。 MEDIA_BUS_FMT_YUYV8_1X16 / UYVY8_1X16 / 2X8。 V4L2_PIX_FMT_YUYV / UYVY / YUV422P。 しかし、dmesgログからもわかるように、CRCエラーが多くあります。また、media-ctl -pからはブリッジノード以外にフォーマット情報が一切表示されていないことに気づきました。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge フォーマットを考慮する必要があるかもしれません。CHNL_IMG_CTRLを確認したところ、100000バイトのYUV422_1P8Pで、カラーコンポーネントごとに8ビット、1プレーン、YUVインターリーブパックバイトでした。 https://github.com/nxp-imx/linux-imx/blob/lf-5.15.y/drivers/staging/media/imx/imx8-isi-fmt.c ヤージュ 。名前= "YUYV-16", .fourcc= V4L2_PIX_FMT_YUYV、 。深さ= { 16 }、 。色= MXC_ISI_OUT_FMT_YUV422_1P8P、 .memplanes= 1、 .colplanes= 1、 .align= 3、 .mbus_code= MEDIA_BUS_FMT_YUYV8_1X16、 } ISI のこのフォーマットをデフォルトとして選択し、ブリッジ側も確認してください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge TC358748のdtsファイル設定で4データレーンを確認しましたが、ログファイルには1レーンしか表示されていません（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1）。もう一度確認してください。 --> これは関数呼び出しを示すためのもので、その下のラインは4つのデータレーンと1つのクロックレーンを有効にしています。 tc358748 2-000e: CLW_CNTRL: 0 0x140 tc358748 2-000e: D0W_CNTRL: 0 0x144 tc358748 2-000e: D1W_CNTRL: 0 0x148 tc358748 2-000e: D2W_CNTRL: 0 0x14c tc358748 2-000e: D3W_CNTRL: 0 0x150 csi&isi dump.txt では、[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(ハードコード=>: 74250000MHz)) しかし、gst-lauch-1.0.txt では、[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) --> 148.5MHzを使用しています。 SO、実際にどの時計をセットしたのですか?DTSを確認しましたが、74.25Mピクセルクロックを設定しています。クロックを測定してhs-settleとclk-settleを設定することをお勧めします --> hs-settle 値は、(ピクセルレート * ピクセルあたりのビット数) / (レーン数 * 2) に基づいて設定され、148.5 pixclk * 16bpp / 2 * 4 レーン = 475.2Mbits/s となります。SO RX_HS_SETTLEは10です。 また、基板上のデータレーンも入れ替わっていました。SO、この改造の後、Gstreamerやv4l2-ctlでビデオキャプチャを起動すると緑色の画面が出ています [[ ## completed ##]] gst-launch-1.0 -e \ v4l2src device=/dev/video3 ! \ 'video/x-raw,format=YUY2,width=1920,height=1080,framerate=60/1' ! \ videoconvert ! queue ! waylandsink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... ^Chandling interrupt. Interrupt: Stopping pipeline ... EOS on shutdown enabled -- Forcing EOS on the pipeline Waiting for EOS... Got EOS from element "pipeline0". EOS received - stopping pipeline... Execution ended after 0:00:09.751003250 Setting pipeline to NULL ... Total showed frames (544), playing for (0:00:09.750853750), fps (55.790) green screen.jpg Re: Trouble with (TC358748) Parallel to CSI2 video bridge TC358748のdtsファイル設定で4データレーンを確認しましたが、ログファイルには1レーンしか表示されていません（[ 39.473097] tc358748 2-000e: tc358748_enable_csi_lanes: 1）。もう一度確認してください。 csi&isi dump.txt では、[ 58.212425] tc358748 2-000e: PLL: pclk 218750000 (FPGA(ハードコード=>: 74250000MHz)) しかし、gst-lauch-1.0.txt では、[ 39.413394] tc358748 2-000e: PLL: pclk 218750000 (FPGA(Hardcode=>: 148500000MHz)) SO、実際にどの時計をセットしたのですか?DTSを確認しましたが、74.25Mピクセルクロックを設定しています。クロックを測定してhs-settleとclk-settleを設定することをお勧めします Re: Trouble with (TC358748) Parallel to CSI2 video bridge こんにちは、 @joanxie さん。 はい、TC358748への入力信号は正常で、TC358748から信号が出力されているのも確認できます。 Gstreamerを使用してキャプチャを開始するには： gst-launch-1.0v4l2src デバイス=/dev/video2 !video/x-raw、幅=1920、高さ=1080 !自動ビデオシンク もう一つの問題は、dtsでISIノードを有効にすると、数分後にシステムがハングアップすることです。 6-min.jpg 5-min.jpg    Re: Trouble with (TC358748) Parallel to CSI2 video bridge 今のところは、Gstreamerやv4l2-ctlを使ってフレームをキャプチャすることができません。 >どのgstreamerコマンドを使っていて、どんなメッセージが出ますか?TC358748からの信号が完全に正常かどうか確認してもらえますか?TC358748側を確認しましたか？ Re: Trouble with (TC358748) Parallel to CSI2 video bridge 登録ダンプファイルはこちらです。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge imx8mp側から見ると、問題は見当たらず、接続設定も正しく行われています。 [ 7.992257 ] mx8-img-md: 登録センサーサブデバイス: tc358748 2-000e (1) [ 8.002921] mx8-img-md: 作成されたリンク [mxc_isi.0]=> [mxc_isi.0.capture] [ 8.018980] mx8-img-md: リンク [mxc-mipi-csi2.0] を作成しました=> [mxc_isi.0] [ 8.025519] mx8-img-md: リンク [tc358748 2-000e] => [mxc-mipi-csi2.0] を作成しました [ 8.032634] mxc-md 32c00000.bus:camera:mxc_md_create_links 実際、ISI0はMIPI CSI0用で、MIPI CSI0に port@1 を加えると現在のBSPでエラーが出るはずです。では、MIPIドライバーは変更していますか?しかし正しく設定しているなら、キャプチャには影響しないはずです。FPGA側を確認して、正しいクロック設定やデータ送信をしているか確認し、TC358748のレジスタを再確認し、またmipi csiやISIレジスタもダンプしてエラービットをチェックしてください Re: Trouble with (TC358748) Parallel to CSI2 video bridge 添付ファイルをご確認ください。 Re: Trouble with (TC358748) Parallel to CSI2 video bridge ログファイルとDTSファイルを送ってもらえますか?

MIMX9352CVVXMACのすべてのピン遅延値が必要です。 MIMX9352CVVXMACのすべてのピン遅延値が必要です。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay IMX93HDGのデザインガイドに従い 、当社のEVK設計を参照してください。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 他のバージョンはありますか？ Re: 我想要MIMX9352CVVXMAC的所有的pindelay 申し訳ありませんが、このExcelファイルはご用意しておりません。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay Excel版が欲しいです Re: 我想要MIMX9352CVVXMAC的所有的pindelay こんにちは、 @ABC007 さん。 IMX93HDG.pdf に従ってください。添付しておきます。 HopeがCANあなたの助けになります 素敵な一日をお過ごしください よろしくお願いいたします。 リタ

S32K3常见问题检查列表(Check list)分享 大家好~       我是NXP的一名FAE。       我总结了K3的常见问题和注意事项，请大家参考。        我删除了之前分享的版本，附件中加入了最新版本，即2026年6月22日版本V1.4。         在文档的附录B中有修改说明。       不能保证每一条总结内容都是正确的，如有疑问，请联系代理商FAE，通过他们把建议反馈给我，不要在此留言。在此，只是内容分享，不在此讨论问题。        谢谢~ 回复：S32K3常见问题检查列表(Check list)分享 享受这些论文吧！ 谢谢！ 此致 塞斯 Re: S32K3常见问题检查列表(Check list)分享 嗨，塞思、 能否请您与我们分享此文档"MCU Ecc 问题和解决方案解答 standard_S32K3 S32K1 KEA.docx" ？一位客户向我们索取该文件。谢谢。 回复： S32K3常见问题检查列表(Check list)分享 感谢您的分享。 Re: S32K3常见问题检查列表(Check list)分享 你好     我最近在使用S32K358，用的RTD是7.0.1版本，S32DS是3.6.10版本，我下载了FreeRTOS的官网软件组件，里面有SMP双核的代码，但我想要多elf多核，每个核都有freeRTOS的工程，我想请问一下，有没有官方的S32K358多核多elf的，用S32DS能正常编译下载调试的example工程，有带FreeRTOS的更好。     谢谢

我想要MIMX9352CVVXMAC的所有的pindelay 我想要MIMX9352CVVXMAC的所有的pindelay Re: 我想要MIMX9352CVVXMAC的所有的pindelay 请按照IMX93HDG 中的设计指南并参考我们的 EVK 设计。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 还有其他版本吗？ Re: 我想要MIMX9352CVVXMAC的所有的pindelay 抱歉，我们没有这个Excel表格。 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 我想要Excel版本 Re: 我想要MIMX9352CVVXMAC的所有的pindelay 你好@ABC007 ， 请参考 IMX93HDG.pdf 文件，我把它附在你身上。 希望对您有所帮助。 祝你今天过得愉快 顺祝商祺！ Rita

BIST問題S32K388アップデート:ソフトリセットがアプリでペリフェラルのinit失敗を引き起こしました NXPサポートチームの皆さん、こんにちは。 以前発生したBISTのハードリセットの問題について：ご提案いただいた変更を適用したところ、BISTは正常にソフトリセットを実行するようになりました。 このソフトリセットに適応し、MCUクロックの初期化が二重になるのを避けるため、当初はアプリケーション内でMCUクロックの初期化を保持しました。しかし、BISTソフトリセットを実行してアプリを起動した後、時計の再初期化に異常に長い時間がかかっていた。この遅延とロックアップは、クロックがすでにブートマネージャーによって初期化されていたため、2回目の試み時に競合が生じたためと考えられています。 この極端な遅延を解消するため、アプリケーションからMCUクロックの初期化を完全に削除し、ブートマネージャーのみに残しました。残念ながら、これにより新たな問題が生じました。アプリケーションに切り替えた後、システムはペリフェラルの初期化(特にFlexCAN)中にフリーズし、クロックの可用性問題を示唆しています。 ここで正しいクロック設定戦略についてアドバイスいただけますか?具体的には、BISTソフトリセットがBMが初期化したクロックを妨げてアプリ内で再初期化が必要になるのか、またBMとアプリ間でロックアップや極端な遅延を起こさずに適切にクロックを渡すにはどうすればよいのか、ということです。 Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App こんにちは、 @HazemIhab さん。 サポートチケットやコミュニティThreadの中には、以前のBISTハードリセットの問題は見つかりませんでした。 ST_DONEが機能リセットであることを理解しています。 リセット後はクロック設定がリセットされるため、初期化が必要です。 RTDドライバを使う場合、Clock_Ip_InitClock()関数はまずすべてのクロックをセーフステートにリセットします。これはおそらくブートマネージャとアプリケーションの両方でクロックを初期化した場合に見られる遅延です。 設定はブートマネージャーでのみ可能ですが、ドライバがアプリケーションに必要なすべてのクロック、つまりFlexCANクロックを有効にしていることを確認する必要があります。 また、すべてのシステムクロックは、RMに記載されているクロックオプションのいずれかと一致する必要があります。例：表156。オプションA - 高性能モード（CM7_CORE_CLK @ 160 MHz）（S32K388/S32K389用）。 BR、ダニエル Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App こんにちは、 @HazemIhab さん。 過失例外があると聞いていますが、確認できますか? もしSOなら、例外が本当に時計に関係しているかどうかを確認するために、さらに詳しい情報を調べる必要があります。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 例外が発生していないにもかかわらず、実行がループに陥っている場合、具体的にどの部分で発生しているのでしょうか？ また、前述したように、すべてのシステムクロックは、RM に記載されているクロックオプションのいずれかと一致する必要があります。表156。オプションA - 高性能モード(CM7_CORE_CLK @ 160 MHz)(S32K388/S32K389用)確認できますか? ありがとうございました。 BR、ダニエル Re: Update on S32K388 BIST issue: Soft reset causing peripheral init failure in App こんにちは、 @danielmartynek さん。 ご説明ありがとうございます。 設定を明確にすると、ブートマネージャー(BM)とアプリケーション(アプリ)はすでに全く同じクロック構成を使っており、FlexCANのクロック設定も含まれます。 セーフステートリセットによる遅延を回避するため、BMにすべてのクロックを初期化させ、アプリからClock_Ip_InitClock()を削除しました。しかし、ジャンプ後にアプリがFlexCANを初期化しようとすると、システムはクロック関連のエラーでハングアップしてしまう。

LS1046A DDR4 32GB DDR4サイズサポート こんにちは、 32GBのDDR4メモリLS1046Aサポートされているのか知りたいです。また、DDR3Lでも動作しますか? Re: LS1046A DDR4 32GB DDR4 Size Support yipingwangさん、迅速なご回答ありがとうございます。LS1034AでサポートされるDDRの最大サイズはどれくらいでしょうか？ Re: LS1046A DDR4 32GB DDR4 Size Support 1. 32 GB DDR4 LS1046Aサポートしていますか? はい。 2. DDR3L LS1046ACAN動作しますか? いいえ。 LS1043A 32ビットDDR3L/DDR4コントローラをサポートし、LS1046A/LS1088Aは64ビットDDR4コントローラをサポートします。 Re: LS1046A DDR4 32GB DDR4 Size Support LS1043A LS1043Aリファレンスマニュアル/製品概要によると、最大32GBのDDR/メインメモリをサポートしています

DMAディスクリプタを使用して1024バイトを超えるデータを受信する（LPC55S69） コミュニティの皆様、こんにちは。 DMAの最大転送サイズが1024バイトであることを考慮すると、 DMAを介して大量のデータ（2000バイト以上）をLPC55S69ボードに受信する方法を見つけるのに苦労していました。 「usart_dma_double_buffer_transfer」の例を見てみましたが、例えば以下のような機能が古くなっていました。 DMA_PrepareTransfer() は DMA_PrepareChannelTransfer() に、DMA_SubmitTransfer() は DMA_SubmitChannelTransfer() に、DMA_CreateDescriptor() は DMA_SetupDescriptor() に変更されました。SO、例には表示されなかったこれらの新しい関数の新しい入力パラメータ、特に新しいDMA_SetupDescriptor()にあるDMAの転送構成パラメータ "xfercfg" を入力するのに少し迷ってしまいました。 [[ ## completed ##]] 「dma_channel_chain」というサンプルコードも確認しましたが、新しい関数のいくつかについて別の視点を得るのに役立ちましたが、まさに私が探していたものではありませんでした。 さらに、 DMA卓球アプリケーション - NXPコミュニティという記事も見ましたが、私が使っていたLPCボードとは完全に互換性がありませんでした。 オンラインで得た情報をまとめ、キーボードに頭を打ち付けて、 ついに目的の場所にたどり着き、DMAを通じて大量のデータを受け取った。 （データはそれぞれ1024バイトの3つの異なるバッファに保存されます） SO、この 機会にコードを共有して、同じ 道を歩んでいる方の助けになれたり、指針を提供できればと思っています。また、この素晴らしいコミュニティから学んだことを少しでも還元したいと思っています。 (これは質問というわけではなく、議論の余地があるトピックであることを考えると、ここに投稿しても問題ないことを願っています。) 幸運を祈ります！ #include "fsl_usart_dma.h" #include "fsl_dma.h" #define NUMBER_DESCRIPTORS 3 #define DESCRIPTOR_TRANSFER_SIZE 1024 #define RX_BUFFER_SIZE 1024 uint8_t g_data_buffer[RX_BUFFER_SIZE]; uint8_t g_data_1[RX_BUFFER_SIZE]; uint8_t g_data_2[RX_BUFFER_SIZE]; uint8_t g_data_3[RX_BUFFER_SIZE]; /* Custom Descriptors (Must be 16-byte aligned) */ SDK_ALIGN(dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS], 16); /* equal to writing: __attribute__((aligned(FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE))) dma_descriptor_t g_Desc[NUMBER_DESCRIPTORS] = {0}; or DMA_ALLOCATE_LINK_DESCRIPTORS_AT_NONCACHEABLE(g_Desc, NUMBER_DESCRIPTORS); */ /* Function definitions ****************************************************************************/ //Initialising Rx DMA to receive data bigger than 1024 bytes. void init_USART_DMA(void){ //Channel configuration for DMA descriptor dma_channel_config_t channelConfig; /* 1. System/Peripheral Level Init */ // Done in peripheral.c, initialized the functions USART_Init(), DMA_EnableChannel(), DMA_CreateHandle(), USART_TransferCreateHandleDMA(). /*I have not used the function DMA_SubmitChannelDescriptor(), by giving as input the g_ChannelTable, as it would not allow to receive data. the g_ChannelTable variable should be initalized as follow: //Allocates the mandatory, 512-byte aligned master table in RAM used by the hardware to manage all DMA channels SDK_ALIGN(dma_descriptor_t g_ChannelTable[FSL_FEATURE_DMA_MAX_CHANNELS], 512); then call the function here in the code DMA_SubmitChannelDescriptor(FLEXCOMM5_USB_PC_RX_Handle,g_ChannelTable); */ /* 2. Enable USART RX DMA requests */ USART_EnableRxDMA(FLEXCOMM5_USB_PC_PERIPHERAL, true); /* 3. Prepare the Descriptor Configuration Variable Flags */ //Intermediate Descriptors, where it jumps from one to another /* Common XFER configuration options for intermediate descriptors (1, 2,...) */ /* reload = true (keeps the chain moving to the next descriptor) */ /* intA = false (we only want the final interrupt when everything is done) */ uint32_t intermediatexfercfg = DMA_CHANNEL_XFER( true, /* reload: true to move to the next descriptor */ false, /* clrTrig: false */ false, /* intA: false */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); //Final Descriptor, where it stops jumping to another descriptor /* Final XFER configuration options for the last descriptor */ /* reload = false (this is the end of the chain) */ /* clrTrig = true (stop the DMA hardware channel) */ /* intA = true (fire the completion interrupt) */ uint32_t finalxfercfg = DMA_CHANNEL_XFER( false, /* reload: false because this is the terminal descriptor */ true, /* clrTrig: true to clear peripheral hardware requests */ true, /* intA: true to fire our completion interrupt */ false, /* intB: false */ sizeof(uint8_t), /* width: 1 byte for USART char processing */ kDMA_AddressInterleave0xWidth, /* srcInc: 0x (read from fixed USART FIFO address) */ kDMA_AddressInterleave1xWidth, /* dstInc: 1x (increment buffer pointer by 1 byte) */ DESCRIPTOR_TRANSFER_SIZE /* totalBytes: DESCRIPTOR_TRANSFER_SIZE */ ); /* 4. Configure the Custom Descriptors structure */ //Descriptor #0 DMA_SetupDescriptor( &g_Desc[0], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_1[0], /* Destination address: RAM buffer */ &g_Desc[1] /* Point to next descriptor */ ); //Descriptor #1 DMA_SetupDescriptor( &g_Desc[1], intermediatexfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_2[0], /* Destination address: RAM buffer */ &g_Desc[2] /* Point to next descriptor */ ); //Descriptor #2 (final) DMA_SetupDescriptor( &g_Desc[2], finalxfercfg, (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* Source address: USART FIFO Read Register */ &g_data_3[0], /* Destination address: RAM buffer */ NULL /* Final descriptor, does not move to another*/ ); /* 5. Set up Head Transfer to execute first descriptor first */ /* Point the initial hardware channel block straight to the first buffer to save data */ DMA_PrepareChannelTransfer( &channelConfig, /* 1. Pointer to configuration structure */ (void *)&FLEXCOMM5_USB_PC_PERIPHERAL->FIFORD, /* 2. Source start address */ (void *)&g_data_1[0], /* 3. Destination start address */ DMA_CHANNEL_XFER( /* 4. Initial transfer settings bitmask */ true, /* reload: true to step into linked descriptor */ false, false, false, sizeof(uint8_t), kDMA_AddressInterleave0xWidth, kDMA_AddressInterleave1xWidth, DESCRIPTOR_TRANSFER_SIZE ), kDMA_PeripheralToMemory, /* 5. Transfer type enum path */ NULL, /* 6. Hardware Trigger parameters (NULL uses default peripheral request) */ &g_Desc[1] /* 7. Address of next descriptor. (including already 2nd descriptor, as this will already transfer all the data to begining of rxBuffer like first descriptor would have done*/ ); DMA_SubmitChannelTransfer(&FLEXCOMM5_USB_PC_RX_Handle,&channelConfig); DMA_StartTransfer(&FLEXCOMM5_USB_PC_RX_Handle); } LPC55xx ペリフェラル Re: Using DMA Descriptors to receive Data bigger than 1024 bytes (LPC55S69) こんにちは、 調査結果とコードを共有していただきありがとうございます。このコミュニティは発見を共有したり、質問したり、指導やサポートを提供したりするのに素晴らしい場所SO、ここに投稿していただき感謝しています。 さらにご不明な点やご要望がございましたら、お気軽にお問い合わせください。 敬具、ルイス

xaf_record Example Fails with comp_setup failure in SDK_26_06_00_MIMXRT700-EVK Board: MIMXRT700-EVK SDK Version: SDK_26_06_00_MIMXRT700-EVK Example: SDK_26_06_00_MIMXRT700-EVK/mcuxsdk/middleware/cadence/multicore-xaf/examples/xaf_record/cm/ Build Configuration: Default example without modifications After starting DMIC recording using the shell command: record_dmic en The DSP reports a component setup failure, preventing the recording pipeline from functioning correctly. console output ****************************** DSP audio framework demo start ****************************** [CM33 Main] Configure codec [DSP_Main] Cadence Xtensa Audio Framework [DSP_Main] Library Name: Audio Framework (Hostless) [DSP_Main] Library Version: 3.6 [DSP_Main] API Version: 3.4 [DSP_Main] start [DSP_Main] established RPMsg link [CM33 Main] DSP image copied to DSP TCM [CM33 Main][APP_DSP_IPC_Task] start [CM33 Main][APP_Shell_Task] start Copyright 2024 NXP >> record_dmic en [CM33 CMD] Setting VIT language to en [DSP_Main] Number of channels 1, sampling rate 16000, PCM width 32 [CM33 CMD] [APP_DSP_IPC_ Task] response from DSP, cmd: 13, error: 0 [DSP Record] Audio Device Ready [CM33 CMD] DSP DMIC Recording started [DSP Record] comp_setup failure: 4294967294 [CM33 CMD] To see VIT functionality say wakeword and command [CM33 CMD] [APP_DSP_IPC_ Task] response from DSP, cmd: 13, error: 4294967295 [CM33 CMD] DSP DMIC Recording started [CM33 CMD] To see VIT functionality say wakeword and command Expected Behavior After executing: record_dmic en The DMIC recording pipeline should initialise successfully, allowing audio capture and VIT wake-word detection without any component setup errors. Actual Behavior The DSP reports: [DSP Record] comp_setup failure: 4294967294 followed by an IPC response with: error: 4294967295 As a result, the recording pipeline does not function as expected. Request  Could you please help identify the following? What causes the comp_setup failure, 4294967294, in the default xaf_record example? Does this indicate a missing DSP component, codec configuration issue, or another initialisation problem? Is there any known issue or patch for the xaf_record example in SDK 26.06.00? Are any additional configuration steps required before using the record_dmic command? Any guidance on debugging this issue would be appreciated. Evaluation Board Re: xaf_record Example Fails with comp_setup failure in SDK_26_06_00_MIMXRT700-EVK Please find the above reply. Re: xaf_record Example Fails with comp_setup failure in SDK_26_06_00_MIMXRT700-EVK Hi @suhas1503 , Could you please provide some information about the IDE you're using? Is it MCUXpresso IDE or VS Code? I tried to reproduce the issue in MCUXpresso IDE, but it ran fine. Gavin_Jia_0-1785739563410.png I didn't find anything related to “[DSP VIT]” in your log information. I suspect this might be due to missing content in your local project rather than a software bug. Best regards, Gavin Re: xaf_record Example Fails with comp_setup failure in SDK_26_06_00_MIMXRT700-EVK I was able to reproduce the issue using the same package. I’ll conduct an internal investigation to see if there are any discrepancies. This may take some time. In the meantime, I recommend that you continue development based on the MCUXpresso IDE project to save the time. Once the issues with the SDK package based on the ARM GCC toolchain have been resolved, you can port your project over. Re: xaf_record Example Fails with comp_setup failure in SDK_26_06_00_MIMXRT700-EVK We have downloaded the sdk from the below link; also attaching the snap; we downloaded sdk version 26.06.00 Screenshot from 2026-08-03 12-23-01.png https://mcuxpresso.nxp.com/download/c7b3a37a7e9e773a92291031541e9b58 we are compiling and flashing through command line Build command:  west build -b mimxrt700evk middleware/cadence/multicore-xaf/examples/xaf_record/cm -d build/ -- -Dcore_id=cm33_core0 -Dtarget=flash_debug Flash command: LinkServer flash MIMXRT798S:MIMXRT700-EVK load dsp_xaf_record_cm33_core0.elf

SGTL5000XNLA3/R2 はアクティブな部分です チームの皆さん、こんにちは。 この部品SGTL5000XNLA3/R2はアクティブですか？新しいデザインにCANを使えますか? データシートはEOLと記載されています Re: SGTL5000XNLA3/R2 is part is active わかりました。ご回答ありがとうございます。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 製品情報 |NXP Semiconductors guoweisun_0-1785821314080.png データシートには以下のように記載されています。 guoweisun_1-1785824177846.png

Fault flag clearing behavior of FS6500 Hi team, I have a question regarding the fault flag clearing behavior of FS6500.   According to the datasheet, the LPOOF (bit0) and DFS (bit1) flags inside the MODE register (address 0x15) shall be cleared only by Power-on reset or register read operation. However, from my hardware test:   Writing to the MODE register also clears LPOOF and DFS fault bits unexpectedly.   There is no description in the datasheet mentioning that write access can clear these status flags. Could you help explain the root cause for this phenomenon?   Is this intended silicon behavior or undocumented side effect?   Thanks & Best regards   DEVKIT-MPC5744P FS6500  Re: Fault flag clearing behavior of FS6500 Hello, Check you write instruction. In most software drivers, a register write is implemented as a read-modify-write (RMW) sequence. If the datasheet specifies that reading MODE clears LPOOF/DFS, then the flags may already be cleared during the read phase. The subsequent write merely creates the impression that the write operation caused the clearing. Best regards, Peter

imx93 AHAB SGK 支持 imx93 现在支持安全启动签名的 SGK 还是仅支持 SRK？ 应用笔记 12312 " 在支持 AHAB 的设备上安全启动 " 在第 3 章中说： 注意：对于 i.MX8ULP 和 i.MX93，当前版本固件仅支持 SRK。 现在还支持 SGK 吗？如果是，来自哪个固件版本？ Re: imx93 AHAB SGK support 现在依然如此。i.MX93 不支持 SGK。 此致 哈维 Re: imx93 AHAB SGK support 您好，请问imx91支持SGK吗？（参考手册上说支持）

etpuc mpc5775 我想运行 eTPUC 中 cw 函数选择器中的一个函数。我知道 etpuc 的起始/结束 RAM 地址（与 mpc5777c_vars_c.h 相同）。我相应地修改了 etpuc 的my_system_etpu_init 函数。我只是复制函数文件（比如crank），然后为etpuc生成新文件。 在运行所有程序并暂停程序时，调试器卡住，显示“PC：找不到“0x800400”的源”。 哪里出了问题？ Re: etpuc mpc5775 下面有几篇应用笔记，关于 etpu 初始化代码有哪些更改？ AN5374：应用程序中的 eTPU 库使用 – 应用笔记 AN4907：发动机控制 eTPU 库 – 应用笔记 AN2864：eTPU 的通用 C 函数 – 应用笔记 AN4908：发动机控制 eTPU 演示应用 – 应用笔记 Re: etpuc mpc5775 eTPU代码是如何生成的？您是使用函数选择器生成了完整的函数集，还是只复制了 CRANK 函数文件？ 能否分享一下您修改后的 my_system_etpu_init() 实现？ 初始化过程中，生成的 eTPU 代码映像是否已成功加载到 SCM 中？ 能否提供生成的 eTPU 项目文件（例如：etpu_set.c，etpu_set.h）？ 电脑总是停在 0x800400 这个错误代码处，还是会变化？

使用 ADC 触发唤醒 S32K312 MCU RTD3.0.0 S32DS3.5 您好， 我正在使用 S32k312 控制器 mini EVBKIT 来检查 MCU 的睡眠和唤醒功能。我正在尝试通过在 ADC 中施加低阈值和高阈值电压值，利用 ADC 中断唤醒 MCU。此功能能否使MCU唤醒？ LavanyaPilli_1-1784889112438.png Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 你好@LavanyaPilli ， 当然。如果您使用 PTA1 (ADC0_S9) 作为外部中断唤醒，您可以参考 S32K312_IOMUX.xlsx 文件查找分配的 WKPU 通道： Julin_AragnM_0-1785173159422.png PTA1 是 WKPU[5]，但是由于有 4 个内部唤醒源，您还必须添加 +4 作为偏移量。这使得 PTA1 WKPU_CH_9。 Julin_AragnM_1-1785173923562.png 您必须初始化 WKPU 单元，并配置相应的通道： /* WKPU configuration */ Wkpu_Ip_Init(WKPU_INST, &Wkpu_Ip_Config_PB); Wkpu_Ip_EnableInterrupt(WKPU_INST, Wkpu_Ip_ChannelConfig_PB[0].hwChannel); 您可以参考以下低功耗示例： S32K3 低功耗管理 AN 和演示 示例 S32K312 在待机状态下通过 CAN-0-RX 和 GPIO 开关 DS3.5 唤醒 RTD300 [RTD600 IP] S32K312EVB-Q172 待机 RAM GPIO 唤醒 此致， 朱利安 Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 您好， 谢谢你的解释。 我将按照您的建议，评估使用 LPCMP 进行待机唤醒。但是，对于我们的应用需求，我们仍然需要实现ADC中断唤醒功能。 请问您能否协助我验证 MEX 文件，看看 ADC 是否可以专门配置为外部中断唤醒？ Re: S32K312 MCU wakeup using ADC trigger RTD3.0.0 S32DS3.5 你好@Julián_AragónM ， 谢谢你的参考，引用，这很有帮助。我们目前采用的是基于 CAN 总线的唤醒配置。我们将在稍后阶段评估基于ADC的唤醒设置。

UM11490 和蓝牙经典 尊敬的NXP技术支持： 我们的一位客户正在运行 UM11490 第 149 页中的以下命令，但看不到任何波形。 请检查并确认是否缺少任何其他命令/条件。 谢谢！ 顺祝商祺！ 码头 ------------------------------------ # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 启动TX变速器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 39 00 00 00 -------------------- 在发送数据之前停止对蓝牙低功耗 (BLE) 和经典蓝牙 (Classic) 的扫描 ---------------- # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 禁用蓝牙扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 00 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 禁用经典扫描 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI 命令：ogf 0x08，ocf 0x000c，plen 2 00 00 > HCI 事件：0x0e plen 4 01 0C 20 00 # 启动TX变速器 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 63 07 00 00 ** 在进入测试模式前禁用扫描时，TX 传输停止会显示以下信息： root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 ED 04 00 00 适用于 5 GHz Wi-Fi -------------------------------------------------------------------------------- 参数：连续发射，带宽 = 40 MHz，802.11ac无DFS，CH = 40，MCS0（13.5），功率 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config 硬件状态=0 netlink_num=31 驱动模式=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=1 bw=1 频道=44 radio_mode[0]=3 radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic 嗨@Christine_Li ， 抱歉，我没理解上下文： 内核版本：lf-6.6.52-2.2.2 已与 6.6.y 合并社区内核 固件版本：IW612-18.99.3.p25.7独立的蓝牙/WiFi固件，没有组合固件 产品：IW612 UM11490 版本：修订版1.8 — 2025年6月2日 以下详情将尽快公布。 加载固件时，dmesg 日志或控制台日志会显示出来。 频谱分析仪设置的屏幕截图 在此期间，如果您还有任何需要，请随时告知我们。 谢谢！ 顺祝商祺！ 码头 Re: UM11490 and Bluetooth Classic 嗨， @pierluigi_p 您使用的是哪款Wi-Fi/蓝牙产品？ 你的Linux内核版本是多少？WiFi/蓝牙驱动程序和固件版本？ 从命令日志来看，所有 HCI 命令均已成功完成，并且 TX 启动命令已被控制器接受。此外，TX stop 命令返回的厂商特定事件包含非零数据包计数器，这表明控制器认为在测试期间已传输了数据包。 因此，该问题似乎并非由测试序列中缺少 HCI 命令引起。 我建议您查看： 频谱分析仪中心频率和跨度设置。 通过 TX 测试命令配置的蓝牙通道。 板上的射频天线配置。 蓝牙固件是否已正确加载。 您能否也分享一下： 所使用的芯片型号（IW416/IW612等）？ 具体是哪个版本的UM11490？ 加载固件时，dmesg 日志或控制台日志会显示什么？ 你加载的是组合固件还是仅BT固件？ 频谱分析仪设置的截图？ 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 补充一点，我们尝试了 HackRF 的不同设置（增益和图形调整），可以看到 2.4 GHz（wifi）波形。此外，我们还测试了 imx-firmware 存储库中不同版本的不同固件，其中包括一个用于 RF 测试的固件（ https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se中的 sduart_nw61x_rftm_v1.bin.se），但均未成功。 Re: UM11490 and Bluetooth Classic 皮尔和克里斯汀，你们好 我是 Helbert，在 Veriscite 论坛上发起这个帖子的开发者。 以下是一些关于测试的附件： dmesg 日志（不包含电源配置信息）： Dmesg 日志（包含电源配置信息）： 频谱分析仪截图和 5 GHz 的配置文件（包括我自己的实现和 NXP 的实现） 5GHz-running-test.png 修改后 5GHz-after-test.png 注意：我们发现，当功率值为 -1 时，我们使用默认值，但也尝试了不同的值。 NXP脚本： NXP-5GHz-running-test.png 经典蓝牙测试的屏幕截图： Bluetooth-2.4-Classic-RUNNING.png 如图所示，没有生成波形。 BLE测试运行中的屏幕截图： BLE-RUNNING-2.4-CH2.png BLE测试后的屏幕截图（波形中断）： BLE-FINISHED.png 从下图可以看出，测试结束时波形中断了。 模块信息日志： 已测试的 HCI 命令： Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 谢谢你提供详细信息。 我需要查看一下你的信息和截图，然后再回复你。 请给我一些时间。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，Christine，有人提出我的二手SoM里可以再加一个Murata模块。我拆解了地雷，发现它的零件编号是：LBEE5PL2DL 因此，我需要检查一下2EL的指令是否也适用于这个型号。 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 感谢您提供详细信息。 您的截图中只显示了一些背景噪音，没有任何有用的射频波形信息。 请问： 1.您正在使用我们的IW612-EVK吗？或者任何模块？如果是模块，请问您能否告知一下模块的零件编号？ 2.您的硬件与测试设备的连接情况如何？ 3.您的问题是关于蓝牙还是Wi-Fi？ 如果是针对蓝牙的测试，我看到了您的测试命令，根据我们的射频测试指南，停止命令是： hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 但您正在发送： root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 请严格按照我们的指导命令执行操作。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好克里斯汀，谢谢你的核实。 1. 您使用的是我们的 IW612-EVK 模块吗？还是其他模块？如果是模块，能否告知您模块的零件编号？ 我们已将该模块集成到 Variscite DART-IMX8M 系统模块 (SoM) 中https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ 它的零件编号是：LBES5PL2EL.4 2.您的硬件与测试设备的连接情况如何？ 我们通过 HackRF One 设备无线访问设备的无线电，该设备可以使用其天线捕获信号（但它也会捕获其他信号；这就是您看到一些噪声的原因）。 3 - 你的问题是关于蓝牙还是Wi-Fi？ 两者皆适用。对于传统蓝牙，我们无法看到生成的波形（只有低功耗蓝牙可以），而对于 Wi-Fi，我们无法捕获 5 GHz 频段的信号。 关于 hci 命令，我看到了两种说法，NXP/Murata 的文档中都推荐了这两种说法。 在 AN14114 中，我们在第 47 页找到了简短的命令。 在 UM11490 中，第 150 页有很长的命令。 对于经典的蓝牙连接，我想我已经找到了解决方案。检查 UM11490 时，该命令的解释如下： hcitool -i hci0 cmd 文档中的示例将 tx_test_interval 设置为 0x0D，在这种情况下，间隔似乎有点长，因此，很难看到生成的波形。听起来像是噪音。将此参数设置为 0x01 时，我可以看到稳定的波形。此外，由于它是低带宽波形，所以我降低了频率范围。所以，我认为这解决了蓝牙问题。 但是，我仍然看不到 5 GHz 的波形。你有什么建议吗？ 非常感谢您的帮助 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 请尝试将初始捕获的带宽从 40MHz 改为 20MHz？ echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config 您的回读显示  bw=1  ，AN14114 将其定义为 40 MHz ；  bw=0  是 20 MHz 。 对于 HackRF 观察而言，20 MHz 是更好的首次测试，因为在窄带或边缘 SDR 设置上，40 MHz Wi-Fi 更难清晰地捕获/识别。 请问它在 20MHz 下是否运行良好？然后我们逐步过渡到 40MHz。   顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，克里斯汀，我没看到这条消息，回复的是另一条。 是的，我尝试过不同的黑白设置，但我倾向于认为问题可能归因于某些地区的限制和噪声。 Re: UM11490 and Bluetooth Classic 你好，克里斯汀， 非常感谢您的支持。 经过一番调试，我发现这里可能存在问题。使用此处提供的文件更改区域时： https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL我注意到 iw reg set 存在问题 基本上，我参考了这里发布的想法： https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working 我使用了 2EL（和 2DL，它们是一样的）对应的文件，但在切换区域时，我注意到 iw reg get 并没有改变它的位置，并显示了以下消息： HelbertPaulino_0-1784905230306.png 因此，当使用文件 *txpower*.bin 更改驱动程序要使用的区域时，我们并没有更改系统区域。我发现，根据所选区域和应用于收音机的设置，这有可能阻止波形被触发。 我删除了 regulatory.db*我从 Murata 那里获取了文件，并使用了原始文件，而且它似乎表现得更好。我成功触发了一些5GHz的波形，但其他一些波形我认为被噪声掩盖了。 请问iw寄存器组/寄存器以及所使用的监管文件是否会影响波形生成？ 如果答案是肯定的，那么我认为我们找到了问题的根源。这不是固件/脚本/校准文件的问题，而是地区限制。你觉得这个推断合理吗？还是你怀疑另有其他嫌疑人？ 再次非常感谢！ Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 谢谢你的信息，很高兴听到蓝牙现在可以正常工作了。 现在我们来重点讨论 Wi-Fi 5G 射频测试模式问题。 LBEE5PL2DL 模块的芯片组是我们 NXP 的 WiFi/蓝牙芯片组：IW611。 IW611 和 IW612 的区别在于：IW612 支持 802.15.4，但 IW611 不支持。 但对于 WiFi 和蓝牙来说，IW611 和 IW612 是相同的。 所以这意味着， 2EL 的命令也适用于此型号（LBEE5PL2DL）。 现在请按照 AN14114 的第 2 部分“Wi-Fi RF 测试模式”来设置您的板子并开始 WiFi 5G RF 测试。 从你分享的 cat /proc/mwlan/adapter0/config 的输出结果来看，我没有发现任何可疑之处。唯一需要注意的是：请检查您的测试设备连接以及硬件连接。 同时，让我内部确认一下这两个模块是否支持射频测试。我确认的是：我们可以在 IW611 或 IW612 EVK 板上进行测试，但对于这两个模块，我需要检查是否需要进行任何硬件改造才能测试射频性能。 如有任何更新，我会通知您。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 嗨，克里斯汀 我正在验证该命令，您是对的，但我不知道为什么这些参数（SHORT_PREAMBLE 和 ADVANCED_CODING）显示为 -1（表示为4294967295）。 或许在代码的最初实现中，它们被错误地设置为了 -1。不过，根据您的要求，现在我们可以生成 5 GHz (tx_frame) 的波形了。对于 tx_continuous，我可以看到波形，但幅度很低（几乎看不见）。 您可以在下图查看帧生成过程： 5GHz-CH100-BW40-FRAME-0x1100-14.png 尝试触发连续信号时，我可以看到波形，但波形非常平滑。 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png 我使用了上述配置。 我认为无法看到通道波形的问题是，我们设备中的噪声比生成的波形要大。我要求硬件团队使用功能更强大的频谱分析仪进行验证。我正在等待他们的回复，以便结束关于非生成波形的问题。 但是关于区域的问题，你认为这可以解释为什么有些波形没有生成吗？   Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 请尝试使用以下命令： echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config 而不是使用 tx_frame 命令？ 我在你之前的输出“cat /proc/mwlan/adapter0/config”中找到了 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff 我担心它可能无法被正确识别。 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 是的，错误的区域/监管功能域配置也可以解释为什么某些5GHz Wi-Fi波形无法生成，或者为什么设备在某些信道上完全不发射信号。   你们的硬件团队是否打算使用功能更强大的频谱分析仪进行验证？ 关于这个案子，我还能为您做些什么吗？   顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 你好，克里斯汀， 我认为这一确认以及他们在另一个无噪音环境下进行的测试证实，现在一切都运行正常了。 非常感谢您的支持。 很高兴见到你 Re: UM11490 and Bluetooth Classic 你好， @HelbertPaulino 感谢您的回复，很高兴听到一切都运行正常了。 那么，能否请您将我的回答标记为本帖的解决方案，以便我们关闭此问题？ 此外，如果您将来有任何其他主题方面的问题，也请随时向我们创建新案例。 我们一直很乐意为您提供支持！ 顺祝商祺！ Christine。 Re: UM11490 and Bluetooth Classic 再次非常感谢你，克里斯汀。 我会这么做。 🙂