Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
TJA1120A RGMII 自动以太网 我们正在基于 TI AM62A7 的定制主板上开发 TJA1120A RGMII 自动以太网 请帮助我们了解如何在 Yocto Linux 上启用该接口。 我们按照 https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp% 2Ctja11xx.yaml 中的 DTS 节点格式进行了尝试 但驱动程序在内核 dmesg 中没有探测到 据了解,该 PHY 的供应商 ID 为 D001B:B031 我们还在内核配置CONFIG_NXP_C45_TJA11XX_PHY中启用了 CONFIG_ NXP_TJA11XX_PHY。 Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 为了缩小范围,请与我们分享一下: 1) U-Boot 是否在预期的地址检测到 MDIO 总线上的 PHY?例如“mdio 列表”/“mii info” 的输出) 2) 请分享 CPSW 端口节点和 MDIO/PHY 节点(phy-handle、phy-mode、PHY 注册/地址)的相关 DTS 片段,以及与 MDIO/PHY 初始化相关的启动日志行:dmesg | egrep-i " mdio|cpsw|phy|tja|nxp " 有了这两个项目,我们可以快速确定PHY在MDIO上是不可见的(硬件/PINMUX/RESET/地址),还是DT绑定/引用问题。 顺祝商祺! 帕维尔 Re: TJA1120A RGMII Auto-Ethernet 我们目前使用的是基于 AM62A7 的 iWave 系统模块,尚未修改 eMMC 中存储的 u-boot/引导加载程序固件。 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info U-Boot固件我们没有改动,只是从SD卡启动Linux系统。 我已附上k3-am62a7-iwg55m.dtsi文件,其中以太网接口 eth0 和 eth1 均已禁用 &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; 在 k3-am62a7-iwg55s-prgjj-41.dts 文件中,我使用相应的 DT 条目启用了 eth0 和 eth1。 &cpsw_port1 和 &cpsw3g_phy0 对应于我们的自动以太网 &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; 我的 PHY TJA1120A 的 PHY 标识寄存器 1:1B 和 PHY 标识寄存器 2:B030。 因此,合适的驱动程序应该兼容 = "ethernet-phy-id001b.b030" dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"的响应 root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL 我还附上了 dmesg 文件。 Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 请注意,社区帖子会在最后一条回复发布后的7天内受到持续监测。此后,我们将仅收到订阅邮件通知以获取后续更新,此类通知有时可能会被错过。   如果您将来需要更多帮助,我们建议您创建一个新的社区查询或支持工单https://support.nxp.com/s/?language=en_US 。 总之,以下是我的分析。 请注意,以下提供的 Linux 命令仅作为建议的诊断检查。由于我无法访问您的确切版本和运行时环境,因此我无法直接在您的设置上验证它们,根据您的系统配置,可能需要进行一些小的调整。 以下讨论串可能对参考有所帮助: 使用 TJA1120 和 i.MX8 评估硬件时,无法进行数据包传输。 从日志来看,MDIO 访问本身似乎工作正常,因为 Linux 检测到 MDIO 总线上有两个 PHY 设备: [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown 因此,TJA1120A 似乎在 MDIO 地址 4 处可见,但它尚未绑定到 NXP C45 TJA11xx PHY 驱动程序。这很可能是 CPSW 端口在 RGMII 验证期间发生故障的原因。 首先,请尝试更新 TJA1120A PHY 节点,明确指定第 45 条: &cpsw_port1 { 状态 = "正常"; phy-mode = "rgmii"; /* 或 rgmii-id / rgmii-rxid / rgmii-txid,具体取决于您的电路板延迟设计 */ phy-handle = <&cpsw3g_phy0>; };   &cpsw3g_phy0 { 兼容 = "ethernet-phy-id001b.b030", "ethernet-phy-ieee802.3-c45"; reg = <4>; 状态 = "正常"; }; 另外,请从 TJA1120A 节点中移除此属性:  nxp,rmii-refclk-in; 此属性与 RMII 参考时钟配置有关,不应将其用于您的 RGMII TJA1120A 设置。   使用更新后的 DTB 重新构建并启动后,请检查驱动程序是否已附加,例如: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"   预期结果是地址 4 处的 PHY 不再显示为 driver unknown ,而是连接到 NXP C45 TJA11xx/TJA1120 驱动程序。 如果仍然显示为 driver unknown ,请确认正在运行的内核确实包含驱动程序支持: zcat /proc/config.gz | zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" 查找 /lib/modules/$(uname -r) -name "*tja*"   顺祝商祺! 帕维尔 Re: TJA1120A RGMII Auto-Ethernet 好的,帕维尔,抱歉回复晚了。 你说得对,只是内核不支持 TJA1120,即使我在旧内核中启用了 CONFIG_NXP_C45_TJA11XX_PHY=y。看来我应该检查一下驱动程序源代码,在那里我发现旧内核中没有 TJA1120( https://github.com/torvalds/linux/blob/v6.12/drivers/net/phy/nxp-c45-tja11xx.c )。 root@am62axx-evm:~# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.383879] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.397521] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.438966] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.448696] NXP C45 TJA1120 8000f00.mdio:04: the phy does not support MACsec [ 1.466641] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [ 1.486189] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.494016] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.502639] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.521311] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.665485] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.756195] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.767993] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode root@am62axx-evm:~# zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" CONFIG_PHYLIB=y CONFIG_PHYLIB_LEDS=y CONFIG_BCM_NET_PHYLIB=m CONFIG_NXP_C45_TJA11XX_PHY=y CONFIG_NXP_TJA11XX_PHY=y CONFIG_QCOM_NET_PHYLIB=y # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_TI_TLC4541 is not set 内核会检测并探测PHY。 目前我使用的是支持 100BASET1 SPE 的 Microchip EVB-LAN8770M_MC 媒体变流器。它是否兼容TJA1120A(1000BASET1)并支持自动协商? Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 谢谢你的更新。新的 dmesg 输出现在看起来好多了。在 MDIO 地址 4 上检测到了 TJA1120A,并且已正确绑定到 NXP C45 TJA1120 驱动程序: [    1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [    6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120]  因此,之前缺少驱动程序支持的问题似乎已经解决。 关于您当前的链路合作伙伴:Microchip EVB-LAN8770M_MC 是 100BASE-T1 媒体变流器,而 TJA1120A 是 1000BASE-T1 PHY。这些是不同的汽车以太网 PHY 标准/速度,因此不应期望基于 LAN8770M 的 100BASE-T1 变流器与 TJA1120A 1000BASE-T1 PHY 建立连接。如果一方支持 100BASE-T1,而另一方是 1000BASE-T1 PHY,则自动协商无法协商共模。 TJA1120 是一款汽车 1000BASE-T1 PHY,在汽车以太网应用中,链路配置通常需要是确定性的,并且需要明确定义。因此,自动协商并非必需,因此也不被支持。 要测试 TJA1120A 链路,请使用支持 1000BASE-T1 的链路伙伴,例如另一个基于 TJA1120/TJA1121 的板或 1000BASE-T1 媒体变流器。 如果您还需要任何进一步的帮助,请在论坛上另开新帖提问,因为本帖已被标记为已解决。 顺祝商祺! 帕维尔
View full article
S32K344 - EMIOS - IPM(输入周期测量)数据采集错误 您好, 我正在为我的 S32K3X4EVB-T172 评估板上的 EMIOS 模块编写裸机驱动程序。 目前,我使用的是配置好的 EMIOS_0,全局预分频器设置为 256 倍,通道配置如下: CH_23 -> MC 递增计数器(Emios 计数器总线 A 的时基)@ 625 kHz CH_17 -> 以 OPWMB 模式运行(使用计数器总线 A) CH_22 -> MC 递增计数器(Emios 计数器总线 F 的时基)@ 156.25 kHz CH_9 -> 以 IPM 模式运行(使用计数器总线 F) 我正在生成一个占空比为 50% 的 16.18Hz 信号,经示波器验证,我将其从 OPWMB 通道 ( PTA0) 路由到 IPWMB 通道 (PTA1)。 我每隔 10 毫秒采集一个 IPM 样本,它始终返回 9657/9658,因此我测得的周期为 9657 * 0.0000064 = 0.0618048,由此得出频率为 1/0.0618048 = 16.18Hz。 我遇到的问题是几乎周期性地获取错误值(如下所示)。 period[0] UINT16 40017 period[1] UINT16 9658 period[2] UINT16 9657 period[3] UINT16 9658 period[4] UINT16 40017 period[5] UINT16 9658 period[6] UINT16 9657 period[7] UINT16 9658 period[8] UINT16 40017 period[9] UINT16 9658 period[10] UINT16 9657 period[11] UINT16 40018 period[12] UINT16 9657 period[13] UINT16 9658 period[14] UINT16 9657 period[15] UINT16 40018 以下是一段代码片段,解释了我目前基于轮询的采集逻辑(不使用 DMA,也不使用中断): 如果(( EMIOS0 -> UC [ 9 ] . S & 1 u ) != 0 u ) { UINT16 a1 = ( UINT16 ) EMIOS0 -> UC [ 9 ] . A ; UINT16 b1 = ( UINT16 ) EMIOS0 -> UC [ 9 ] . B ; UINT16 a2 = ( UINT16 ) EMIOS0 -> UC [ 9 ] 。一个; UINT16 b2 = ( UINT16 ) EMIOS0 -> UC [ 9 ] 。乙; 如果( a1 != a2 ) { 如果( b1 != b2 ) { period [ Index ] = ( UINT16 )( a2 - b2 ) ; } else { period [ Index ] = ( UINT16 )( a1 - b1 ) ; } } else { period [ Index ] = ( UINT16 )( a2 - b2 ) ; } 索引++; 如果(索引> 99u )​ 索引= 0 u ; EMIOS0 -> UC [ 9 ] . S = EMIOS_UC_CLEAR_STATUS_FLG ; /* 80008001u */ } 测试不同频率时,异常值的出现频率大大降低,但仍然存在。以下是一个使用 303Hz 的例子: period[0] UINT16 519 period[1] UINT16 519 period[2] UINT16 519 period[3] UINT16 519 period[4] UINT16 519 period[5] UINT16 519 period[6] UINT16 519 period[7] UINT16 519 period[8] UINT16 519 period[9] UINT16 519 period[10] UINT16 519 period[11] UINT16 519 period[12] UINT16 519 period[13] UINT16 30879 period[14] UINT16 519 period[15] UINT16 519 period[16] UINT16 519 period[17] UINT16 519 period[18] UINT16 519 period[19] UINT16 519 period[20] UINT16 519 period[21] UINT16 519 period[22] UINT16 519 period[23] UINT16 519 period[24] UINT16 519 period[25] UINT16 519 period[26] UINT16 519 period[27] UINT16 519 period[28] UINT16 519 period[29] UINT16 519 period[30] UINT16 519 period[31] UINT16 519 period[32] UINT16 519 period[33] UINT16 519 period[34] UINT16 519 period[35] UINT16 519 period[36] UINT16 519 period[37] UINT16 519 period[38] UINT16 519 period[39] UINT16 519 period[40] UINT16 519 period[41] UINT16 519 period[42] UINT16 519 period[43] UINT16 519 period[44] UINT16 519 period[45] UINT16 519 period[46] UINT16 519 period[47] UINT16 519 period[48] UINT16 519 period[49] UINT16 519 period[50] UINT16 519 period[51] UINT16 519 period[52] UINT16 519 period[53] UINT16 519 period[54] UINT16 519 period[55] UINT16 519 period[56] UINT16 519 period[57] UINT16 519 period[58] UINT16 30879 period[59] UINT16 519 有人能帮忙吗? Re: S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition 你好@fede_ls , 你的轮询逻辑可能并非观察到的异常值的主要来源。这些数值强烈表明,周期计算没有正确处理所选计数器总线的翻转。当前表达式 (uint16_t)(A - B) 假设 16 位计数器在 65536 处完全翻转,但您的计数器总线 F 似乎在大约 35176 个时钟周期处翻转。因此,每当捕获的周期跨越计数器翻转时,都会添加 65536 - 35176 = 30360 刻度的额外偏移量,这与观察到的异常值完全匹配。   请检查 CH22 的周期/模数配置,该 CH22 用作 IPM 通道的计数器总线 F。周期应该使用实际的计数器总线模值来计算,而不是使用隐式的 16 位无符号减法。   顺祝商祺! 帕维尔
View full article
在配备双 MIPI CSI-2 摄像头的 i.MX8MP FRDM 上注册自定义摄像头时发生内核崩溃 尊敬的技术支持团队: 我们目前正在研究如何使用 i.MX8MP FRDM 板集成两个摄像头。 摄像机配置如下: * CSI2:0 连接到 OV5640 摄像机。 * CSI2:1 连接到定制的摄像头模块。 对于这两台相机,我们配置了设备树,使图像管道不使用 ISP 功能。计划的管道是: “传感器 → MIPI CSI-2 → ISI → 捕获” 设备树文件已附上,供您参考:“imx8mp-frdm-ov5640-cusdom.dts” 问题在于,自定义相机驱动程序成功完成了 I2C3 上的 I2C 探测过程,但在调用“v4l2_async_register_subdev_sensor()”时发生内核崩溃。 总而言之,内核崩溃的原因是,在注册自定义相机时,“mxc_isi.1”尚未创建或注册。 相关的内核崩溃日志已附上:“panic-log.txt” 我们还附上了自定义相机驱动程序的探测函数实现:“custom_driver_probe.c” 我们参考 i.MX8MP FRDM 板的默认设备树配置创建了“imx8mp-frdm-ov5640-cusdom.dts”。 OV5640摄像头工作正常。然而,自定义摄像头无法与 ISI 管道建立连接,最终导致内核崩溃。 在检查了设备树配置和自定义相机驱动程序之后,我们仍然无法确定问题的根本原因。 附件中的“imx8-media-dev.c”文件仅包含我们添加的额外调试信息,用于确定内核崩溃发生的位置。 我们的目标是通过 i.MX8MP 平台上的 MIPI CSI-2 接口同时操作两台不同的摄像机。 请您查看附件中的设备树和驱动程序代码,并指出哪些配置或实现部分可能不正确或缺失? 您的支持和指导将不胜感激。 谢谢! 此致, 西奥比
View full article
TJA1120A RGMII Auto-Ethernet We are working on TJA1120A RGMII Auto-Ethernet on our Custom Board based on TI AM62A7 Kindly help us with how to enable this interface on Yocto Linux  We have tried following DTS node format as in https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp%2Ctja11xx.yaml But driver didnt probe on Kernel dmesg We understand that this PHY has vendor ID D001B:B031 We have also enabled CONFIG_NXP_TJA11XX_PHY in kernel config CONFIG_NXP_C45_TJA11XX_PHY Re: TJA1120A RGMII Auto-Ethernet Hello @vikyhre , To narrow this down, could you please share: 1) Does U-Boot detect the PHY on the MDIO bus at the expected address? (e.g. output of “mdio list” / “mii info”) 2) Please share the relevant DTS snippets for the CPSW port node and the MDIO/PHY node (phy-handle, phy-mode, PHY reg/address), plus the boot log lines related to MDIO/PHY init: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" With these two items we can quickly determine whether the PHY is not visible on MDIO (HW/pinmux/reset/address) or if it’s a DT binding/reference issue. Best regards, Pavel Re: TJA1120A RGMII Auto-Ethernet We are using AM62A7 based iWave SoM, we didnt touch the u-boot/bootloader firmware residing in the eMMC as of now U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info  U-Boot firmware is something we didnt change, we just boot our Linux from SD-Card I have attached k3-am62a7-iwg55m.dtsi, where both ethernets eth0,eth1 are disabled &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; In k3-am62a7-iwg55s-prgjj-41.dts, i enabled both eth0 and eth1 with appropiate DT entries &cpsw_port1 and &cpsw3g_phy0 corresponds to our Auto-Ethernet &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; Here, my PHY TJA1120A has PHY Identification Register 1: 1B and PHY Identification Register 2: B030. So appropiate driver should be  compatible = "ethernet-phy-id001b.b030" Response for dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL I have also attached dmesg Re: TJA1120A RGMII Auto-Ethernet Hello @vikyhre , Please note that Community threads are actively monitored for 7 days after the last post. After this period, we only receive subscription email notifications for further updates, and such notifications can occasionally be missed.   If you need additional assistance in the future, we recommend creating a new Community query or supporting ticket https://support.nxp.com/s/?language=en_US . Anyway, here's my analyses. Please note that the Linux commands below are provided as suggested diagnostic checks. Since I do not have access to your exact build and runtime environment, I cannot directly verify them on your setup and minor adaptations may be needed depending on your system configuration. The following thread might be useful as a reference: No packet transmission with TJA1120 and i.MX8 Eval hardware From the log, the MDIO access itself seems to be working, because Linux detects two PHY devices on the MDIO bus: [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown So the TJA1120A appears to be visible at MDIO address 4, but it is not bound to the NXP C45 TJA11xx PHY driver yet. This is likely why the CPSW port later fails during RGMII validation. As a first step, please try updating the TJA1120A PHY node to explicitly specify Clause 45: &cpsw_port1 {     status = "okay";     phy-mode = "rgmii";      /* or rgmii-id / rgmii-rxid / rgmii-txid depending on your board delay design */     phy-handle = <&cpsw3g_phy0>; };   &cpsw3g_phy0 {     compatible = "ethernet-phy-id001b.b030", "ethernet-phy-ieee802.3-c45";     reg = <4>;     status = "okay"; }; Also, please remove this property from the TJA1120A node:  nxp,rmii-refclk-in; This property is related to RMII reference clock configuration and should not be used for your RGMII TJA1120A setup.   After rebuilding and booting with the updated DTB, please check whether the driver is attached, for example: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"   The expected result is that the PHY at address 4 is no longer shown as driver unknown , but is attached to the NXP C45 TJA11xx/TJA1120 driver. If it still remains driver unknown , please also confirm that the running kernel really contains the driver support: zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" find /lib/modules/$(uname -r) -name "*tja*"   Best regards, Pavel Re: TJA1120A RGMII Auto-Ethernet Hello @vikyhre , Thank you for the update. The new dmesg output looks much better now. The TJA1120A is detected on MDIO address 4 and is correctly bound to the NXP C45 TJA1120 driver: [    1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [    6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120]  So, the previous issue with the missing driver support seems to be resolved. Regarding your current link partner: the Microchip EVB-LAN8770M_MC is a 100BASE-T1 media converter, while TJA1120A is a 1000BASE-T1 PHY. These are different automotive Ethernet PHY standards/speeds, so the LAN8770M-based 100BASE-T1 converter should not be expected to establish a link with the TJA1120A 1000BASE-T1 PHY. Auto-negotiation cannot negotiate a common mode if one side supports 100BASE-T1 and the other side is a 1000BASE-T1 PHY. TJA1120 is an automotive 1000BASE-T1 PHY and in automotive Ethernet applications the link configuration is typically expected to be deterministic and explicitly defined. So, auto negotiation is not required and thus not supported. For testing the TJA1120A link, please use a 1000BASE-T1 capable link partner, for example another TJA1120/TJA1121 based board or a 1000BASE-T1 media converter. Please open a new question to the forum, if you require any further assistance, since this thread has been marked as solved. Best regards, Pavel Re: TJA1120A RGMII Auto-Ethernet Sure Pavel, sorry for late reply You were right, its just that the kernel didnt have support for TJA1120 eventhough i had CONFIG_NXP_C45_TJA11XX_PHY=y enabled in older kernel. It seems i should have checked driver source code where i found out TJA1120 isnt present for older kernel(https://github.com/torvalds/linux/blob/v6.12/drivers/net/phy/nxp-c45-tja11xx.c). root@am62axx-evm:~# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.383879] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.397521] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.438966] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.448696] NXP C45 TJA1120 8000f00.mdio:04: the phy does not support MACsec [ 1.466641] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.476820] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver NXP C45 TJA1120 [ 1.486189] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.494016] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512, Policers 32 [ 1.502639] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.521311] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.654104] am65-cpsw-nuss 8000000.ethernet eth0: PHY [8000f00.mdio:04] driver [NXP C45 TJA1120] (irq=POLL) [ 6.665485] am65-cpsw-nuss 8000000.ethernet eth0: configuring for phy/rgmii link mode [ 6.756195] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.767993] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode root@am62axx-evm:~# zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" CONFIG_PHYLIB=y CONFIG_PHYLIB_LEDS=y CONFIG_BCM_NET_PHYLIB=m CONFIG_NXP_C45_TJA11XX_PHY=y CONFIG_NXP_TJA11XX_PHY=y CONFIG_QCOM_NET_PHYLIB=y # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_TI_TLC4541 is not set PHY is detected and probed by the kernel. Right now i am using Microchip EVB-LAN8770M_MC Media Converter which supports 100BASET1 SPE. Will it be compatible with TJA1120A(1000BASET1) and autonegotiate?
View full article
MPC5777 BSDL BGA_512 こんにちは、このコンポーネントのBSDLファイルを探しています。 MPC5777 BGA-512 ファイルを送ってもらえますか? よろしくお願いします。 Re: MPC5777 BSDL BGA_512 こんにちは、 プライベートメッセージでお送りします。今後はチケットを上げてください NXP.com よろしくお願いいたします。 ピーター
View full article
External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Hello, I am trying to connect an external JTAG debugger to the FRDM-i.MX95 board. According to the board schematic, the JTAG/DAP signals appear to be routed to test points on the PCB, and some related components are marked as DNP. Based on this, I modified the board as follows: Connected the JTAG signals from the test points Mounted the DNP resistors related to the JTAG/DAP signal path Added a connector for an external debugger Connected VTref, GND, TCK, TMS, TDI, TDO, and RESET to the external debugger However, I cannot observe the expected JTAG signal output from the debugger/board side. For example, TCK/TMS/TDI do not appear as expected during the debugger connection sequence. Could you please confirm the following points? Is the above modification method correct for connecting an external JTAG debugger to the FRDM-i.MX95 board? Are there any additional resistors, jumpers, solder bridges, or board modifications required to enable the external JTAG/DAP interface? Is there any requirement for VTref voltage level or power sequencing before the external debugger starts driving JTAG signals? Does the i.MX95 on FRDM-i.MX95 require any boot mode, fuse setting, security setting, or software initialization before the JTAG/DAP interface becomes accessible? Can the external JTAG debugger access the Cortex-A55, Cortex-M33, and Cortex-M7 cores directly on this board, or is additional initialization by the bootloader/firmware required? Is there any recommended connector pin assignment or reference modification guide for using an external debugger with FRDM-i.MX95? I would appreciate it if you could provide any guidance, schematic references, or required modification details for enabling external JTAG debugging on the FRDM-i.MX95 board. Best regards, Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. Is your modification approach correct? In principle, yes. If the FRDM schematic exposes: TCK TMS TDI TDO nTRST or RESET VTref GND through test points and DNP stuffing options, then routing those signals to a connector is generally the correct approach. However, I cannot confirm that all required DNP resistors have been populated because the schematic itself was not returned by the search results. The user manual does not contain the JTAG circuitry. 2. Why would no TCK/TMS/TDI activity be seen? Normally, when a JTAG probe is connected: TCK/TMS/TDI are driven by the debugger. The target board does not generate them. If you see absolutely no toggling on TCK/TMS: Most common cause #1: VTref not detected Many probes (Lauterbach, J-Link, PE Micro, ULINK, etc.) will not drive JTAG pins until VTref is present and within a valid range. Check: VTref voltage at the connector. Common ground connection. Probe software reports the target voltage. For FRDM-i.MX95, the DAP I/O supply appears related to the 3.3 V domain (NVCC_CCM_DAP). The board documentation shows this domain powered from VDD_3V3. Most common cause #2: Board not powered Most debuggers use VTref for sensing only. They do not power the target. Verify: Board powered from J25. PMIC started. VDD_3V3 present. Board LEDs active. The board requires external PD power. Most common cause #3: Missing signal routing rework If the JTAG path contains: 0-Ω DNP resistors isolation resistors alternative stuffing options then missing even a single resistor can leave TCK/TMS disconnected. Since the schematic is not available in the search results, I cannot verify the exact resistor population list. Most common cause #4: Wrong pin mapping Verify with an ohmmeter: Probe pin → connector pin → resistor → test point → i.MX95 ball. Do not assume the test point labels match standard ARM 20-pin ordering. 3. Is a special boot mode required? For a non-secure device: No boot mode should be required just to observe JTAG clock activity. TCK/TMS should toggle as soon as the debugger detects VTref and starts a scan sequence. The boot switches affect: eMMC boot SD boot serial downloader and are unrelated to whether the debugger generates TCK. 4. Are security settings/fuses involved? Potentially. The i.MX95 implements authenticated debug and debug access control. [i.MX95RM_Rev4 | PDF], [i.MX95RM_Rev2 | PDF], [i.MX95 Sec...2026-final | PowerPoint] However: Security settings would usually prevent successful debug access. They would not normally prevent the debugger from generating TCK/TMS itself. Since you report no TCK activity at all, I would first investigate: VTref Probe configuration Cable pinout Missing population options before suspecting security. 5. Can A55, M33, and M7 be debugged? The i.MX95 debug architecture supports: Cortex-A55 Cortex-M33 Cortex-M7 through the CoreSight/DAP infrastructure. [i.MX95RM_Rev2 | PDF], [i.MX95RM_Rev5 | PDF] So from a silicon capability perspective, yes. Whether all domains are immediately visible depends on: system state, security configuration, debugger support. But no additional bootloader initialization is generally required for the debugger to detect the DAP itself. Recommended measurements Before further board rework, I would check: Power VTref = ? V VDD_3V3 present Board booting normally Continuity TCK connector ↔ SoC path TMS connector ↔ SoC path TDI connector ↔ SoC path TDO connector ↔ SoC path RESET connector ↔ SoC path Probe side Does the debugger software report target voltage? Does it show "target detected"? Does it report JTAG chain scan attempted? Oscilloscope Probe directly at: debugger connector pin SoC-side test point during connect attempt. If TCK is present at the debugger connector but absent at the SoC test point, the issue is almost certainly in the board rework. Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Thank you for your support. We reviewed our external JTAG debugger connection and found that the issue was caused by the wiring length between the FRDM-i.MX95 board and the external JTAG debugger. After shortening and rearranging the JTAG signal wires, the debugger was able to detect the target correctly and the JTAG signals were observed as expected. Therefore, this issue has been resolved by improving the JTAG wiring length and connection quality. Thank you again for your assistance.
View full article
FRDM-i.MX95 上的外部 JTAG 调试器连接未输出预期的 JTAG 信号 你好, 我正在尝试将外部 JTAG 调试器连接到 FRDM-i.MX95 板。 根据板原理图,JTAG/DAP 信号似乎被连接到 PCB 上的测试点,一些相关元器件被标记为 DNP。 基于此,我对电路板进行了如下修改: 连接测试点的 JTAG 信号 安装与 JTAG/DAP 信号路径相关的 DNP 电阻器 添加了外部调试器的连接器 将 VTref、GND、TCK、TMS、TDI、TDO 和 RESET 连接到外部调试器 但是,我无法从调试器/电路板端观察到预期的 JTAG 信号输出。 例如,在调试器连接序列期间,TCK/TMS/TDI 没有按预期出现。 请您确认以下几点? 上述修改方法是否适用于将外部 JTAG 调试器连接到 FRDM-i.MX95 板? 要启用外部 JTAG/DAP 接口,是否需要额外的电阻器、跳线、焊桥或板修改? 外部调试器开始驱动 JTAG 信号之前,VTref 电压等级或电源时序是否有任何要求? FRDM-i.MX95 上的 i.MX95 在 JTAG/DAP 接口可访问之前是否需要任何启动模式、熔丝设置、网络安全设置或软件初始化? 外部 JTAG 调试器能否直接访问该板上的 Cortex-A55、Cortex-M33 和 Cortex-M7 内核,还是需要引导加载程序/固件进行额外的初始化? 在使用 FRDM-i.MX95 时,是否有推荐的连接器引脚分配或参考修改指南,以便将外部调试器与 FRDM-i.MX95 配合使用? 如果您能提供在 FRDM-i.MX95 板上启用外部 JTAG 调试的任何指导、原理图参考或所需修改细节,我将不胜感激。 顺祝商祺! Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. 你的修改方法是否正确? 原则上,是的。 如果 FRDM 原理图显示: TCK TMS TDI TDO nTRST 或 RESET VTREF GND 通过测试点和 DNP 填充选项,然后将这些信号路由到连接器通常是正确的方法。 但是,由于搜索结果中没有返回原理图,因此我无法确认所有必需的 DNP 电阻器是否都已安装到位。用户手册中不包含 JTAG 电路图。 2. 为什么检测不到 TCK/TMS/TDI 活性? 通常情况下,当连接 JTAG 探针时: TCK/TMS/TDI 由调试器驱动。 目标板不会生成它们。 如果您在 TCK/TMS 上完全看不到任何切换: 最常见原因 1:未检测到 VTref 许多探针(Lauterbach、J-Link、PE Micro、ULINK 等)只有在 VTref 存在且在有效范围内时才会驱动 JTAG 引脚。 检查: 连接器处的 VTref 电压。 共用接地连接。 探针软件会报告目标电压。 对于 FRDM-i.MX95,DAP I/O 电源似乎与 3.3 V 功能域 (NVCC_CCM_DAP) 有关。板文档显示该功能域由VDD_3V3供电。 最常见原因二:电路板未通电 大多数调试器仅使用 VTref 进行检测。 它们不会为目标提供动力。 核实: 电路板由 J25 供电。 PMIC启动。 VDD_3V3 存在。 电路板上的LED指示灯亮起。 该板需要外部PD电源。 最常见原因#3:缺少信号路由重构 如果 JTAG 路径包含: 0Ω DNP电阻器 隔离电阻器 其他馅料选择 即使缺少一个电阻,也可能导致 TCK/TMS 断开连接。 由于搜索结果中没有原理图,我无法核实电阻器的确切配置。 最常见原因#4:引脚映射错误 用欧姆表验证: 探针引脚 → 连接器引脚 → 电阻器 → 测试点 → i.MX95 球。 不要假设测试点标签与标准的 ARM 20 引脚顺序一致。 3. 是否需要特殊的启动模式? 对于不安全的设备: 观察 JTAG 时钟活动不应该需要启动模式。 一旦调试器检测到 VTref 并开始扫描序列,TCK/TMS 就应该切换。 启动开关会影响: eMMC启动 SD启动 序列号下载器 这与调试器是否生成 TCK 无关。 4. 是否涉及安全设置/熔丝? 有可能。 i.MX95 实现了认证调试和调试访问控制。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] 然而: 网络安全设置通常会阻止成功的调试访问。 它们通常不会阻止调试器生成 TCK/TMS 本身。 由于您报告完全没有 TCK 活性,我首先会调查以下问题: VTREF 探针配置 电缆引脚排列 缺失的人口选项 在怀疑网络安全之前。 5. A55、M33 和 M7 可以调试吗? i.MX95调试架构支持: Cortex-A55 Cortex-M33 Cortex-M7 通过 CoreSight/DAP 基础设施。[i.MX95RM_Rev2 | PDF] , [i.MX95RM_Rev5 | PDF] 所以从硅芯片的性能角度来看,是的。 所有功能域是否立即可见取决于: 系统状态, 网络安全配置, 支持调试器。 但调试器通常不需要额外的引导加载程序初始化即可检测到 DAP 本身。 推荐测量方法 在进一步修改电路板之前,我会检查以下几点: 电源 VTref = ?V VDD_3V3 存在 板正常启动 连续性 TCK 连接器 ↔ SoC 路径 TMS连接器↔SoC路径 TDI 连接器 ↔ SoC 路径 TDO 连接器 ↔ SoC 路径 RESET 连接器 ↔ SoC 路径 探针侧 调试软件是否报告目标电压? 它是否显示“检测到目标”? 它是否报告尝试进行 JTAG 链扫描? 示波器 直接探测: 调试器连接器引脚 SoC侧测试点 连接尝试期间。 如果调试器连接器处存在 TCK,但 SoC 测试点处不存在 TCK,则问题几乎肯定出在电路板返工上。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 感谢您的支持。 我们检查了外部 JTAG 调试器连接,发现 问题是由FRDM-i.MX95板和电路板之间的线路长度引起的。 外部 JTAG 调试器。 缩短并重新排列 JTAG 信号线后,调试器…… 能够正确检测到目标,并观察到了JTAG信号。 预期的。 因此,通过改进JTAG接线方式,这个问题已经得到解决。 长度和连接质量。 再次感谢您的帮助。
View full article
iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error Hi, I am developing a dual camera application. Camera resolution and image format is 2592x1944, RAW8 Datapath and driver structure is Camera (sensor driver.c)--> MIPI-CSI2 (imx8-mipi-csi2-sam.c) --> ISI (imx8-isi-cap.c) --> RAM After modifying the drivers, I could get the video stream from CSI1 successfully with 2592x1944, RAW8, 50~60fps. Now I want to get another video stream from CSI2, but not working because of FIFO overflow error. [ 43.892406] mxc-mipi-csi2.1: Frame End events: 1 [ 43.897023] mxc-mipi-csi2.1: Frame Start events: 2 [ 43.901811] mxc-mipi-csi2.1: Non-image data after odd frame events: 0 [ 43.908248] mxc-mipi-csi2.1: Non-image data before odd frame events: 0 [ 43.914771] mxc-mipi-csi2.1: Non-image data after even frame events: 0 [ 43.921297] mxc-mipi-csi2.1: Non-image data before even frame events: 0 [ 43.927906] mxc-mipi-csi2.1: Unknown Error events: 0 [ 43.932868] mxc-mipi-csi2.1: CRC Error events: 0 [ 43.937484] mxc-mipi-csi2.1: ECC Error events: 0 [ 43.942097] mxc-mipi-csi2.1: FIFO Overflow Error events: 1209788 [ 43.948100] mxc-mipi-csi2.1: Lost Frame End Error events: 0 [ 43.953672] mxc-mipi-csi2.1: Lost Frame Start Error events: 0 [ 43.959413] mxc-mipi-csi2.1: SOT Error events: 0 I tried to change hs-settle and clk-settle parameters, but no success. Based on Reference Manual, CSI1 maximum operating frequency is 500MHz, but CSI2 is 266MHz. Does the lower CSI2 frequency limit frame resolution or frame rate? How can I solve this ?  i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error Hello, Has this been resolved? I am experiencing the same issue with a Vision Components IMX900C camera (2048x1536). It successfully streams at 30fps on CSI1 -> ISI0, but I get an overflow error on CSI2 -> ISI1 with the same settings. Thanks! Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error Hi, igorpardykov Thank you for your support. I checked below from Reference Manual again. • 2 unprocessed camera stream (i.e. no scaling) at 4Kp30, depending on system load and use case I want to get RAW8 format video stream (bypass csc), and then it corresponds unprocessed stream, am I right? Does this mean that ISI supports using two 4Kp30 video streams simultaneously? If I slow down 2nd frame rate (e.g under 30fps), can I solve FIFO overflow issue? When two ISPs are used simultaneously, each supports: • maximum resolution up to 1080p (1936x1188)" FYI, I don't use ISPs at all (all disabled at the device tree), and use ISI only. Thank you in advance. Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error Hi Dy yes you are right, fifo overflow may be caused by isi performance capabilities, as described in sect.13.1.2 Display Interface  i.MX 8M Plus Applications Processor Reference Manual "The key features of the ISI include:.. Image processing for • 2 processed camera stream at 1080p30 • 2 unprocessed camera stream (i.e. no scaling) at 4Kp30, depending on system load and use case.. When two ISPs are used simultaneously, each supports: • maximum resolution up to 1080p (1936x1188)" Best regards igor
View full article
S32K388 STCU BIST: STCU_WDGの値はオンラインウォッチドッグのタイムアウトに影響しますか? NXPのエキスパートの皆様、こんにちは。 私は S32K388 上で開発しており 、 STCU/BIST機能を実装するために SPD(セーフティ Peripheral ドライバ) v1.0.6 を基準にしています。 main.c では 、BIST テストを有効にしてから、 MC_RGM からリセット理由を読み取ります。返されたリセット理由は MCU_ST_DONE_RESET であることがわかりました 。 私には以下の質問があります。 STCU_WDG レジスタ に書き込まれた値は、 BIST実行中の オンラインウォッチドッグタイムアウト 期間に影響しますか?言い換えれば、 BIST実行時間が STCU_WDG 値を超えた場合、 WDTOSW フラグが直接トリガーされますか ? MCU_ST_DONE_RESET 報告 されたとき 、 LBISTもMBISTも正常に修了し合格 したと結論づけ ていい でしょうか?それとも、このリセット理由はタイムアウトが起きたかどうかに関わらず、STCUシーケンスが完了したことを示すだけでしょうか? 私の場合、ERR_STATレジスタはWDTOSW = 1、RFSF=1を示しています(添付のスクリーンショット参照)。これは、BISTの実行がタイムアウトし、早期に終了・中止されたため、メモリテストが完了する前に強制的に停止されたということでしょうか?それともWDTOSWが設定されてMCU_ST_DONE_RESETでも生成は可能でしょうか? また、SPDドライバーの Bist_IntegrityTest() フロー(添付コードのスクリーンショット参照)も確認しましたが、完成後にLBIST/MBISTの終了フラグ( LBESW0 / MBESW0)が1に設定され ていると期待されています。しかし、実際のデバッグ中に LBISTとMBISTのエンドフラグビットの両方が0であって1ではない ことがわかり ました。なぜMCU_ST_DONE_RESETが生成されているのに終了フラグが0になるのでしょうか ? 補足情報: 私はSPDの例に似たセーフティ Boot BIST設定表を使っています。 観測されたSTCU_WDG値: 0xC35E (49998)。 観測されたSTCU_ERR_STAT値: 0x80140 ( RFSW=1 、 WDTOSW=1 )。 STCU_WDG、WDTOSW、MCU_ST_DONE_RESET、そしてLBESW0/MBESW0のエンドフラグの関係を明確にしていただけますか? 事前に感謝いたします。 よろしくお願いします、 Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? こんにちは、 main.c では 、BIST テストを有効にしてから、 MC_RGM からリセット理由を読み取ります。返されたリセット理由は MCU_ST_DONE_RESET であることがわかりました 。 それは正しい行動です。 1. STCU_WDG レジスタ に書き込まれた値は、 BIST実行中の オンラインウォッチドッグタイムアウト 期間に影響しますか?言い換えれば、 BIST実行時間が STCU_WDG 値を超えた場合、 WDTOSW フラグは直接トリガーされますか ? いいえ。STCU_WDGはBIST実行の監視役です。そもそもSWTとは関係ありません。SWTモジュールもBISTでテストされるため、BIST中はSWTモジュールが機能しません。したがって、STCU_WDGを使用して実行時間を保護します。 MCU_ST_DONE_RESET 報告 されたとき 、 LBISTもMBISTも正常に修了し合格 したと結論づけ ていい でしょうか?それとも、このリセット理由はタイムアウトが起きたかどうかに関わらず、STCUシーケンスが完了したことを示すだけでしょうか? テスト手順は終わったとしか結論づけられない。結果は、STCU2オンラインLBISTステータス(LBSSW0)などのさまざまなレジスタに保存され、合格/不合格の条件を示します。 私の場合、ERR_STATレジスタはWDTOSW = 1、RFSF=1を示しています(添付のスクリーンショット参照)。これは、BISTの実行がタイムアウトし、早期に終了・中止されたため、メモリテストが完了する前に強制的に停止されたということでしょうか?それともWDTOSWが設定されてMCU_ST_DONE_RESETでも生成は可能でしょうか? MCU_ST_DONE_RESETはテスト後に必ず生成されます。結果に関係なく。テスト中は、レジスタとRAMがパターンを用いてテストされます。レジスタはデフォルト値に設定する必要があります。これらの値はリセット時にロードされます。そうしないと、すべてのレジスタがテストパターンでいっぱいになり、MCUはそのようなランダムな値で動作しません。 RAMはソフトウェアによって初期化される必要がある。なぜなら、BISTがRAM上でテストパターンを実行した後、ECCシンドロームがデータと一致しなくなるからである。 私の場合、ERR_STATレジスタはWDTOSW = 1、RFSF=1を示しています  これはテストが失敗したことを意味します。 また、SPDドライバーの Bist_IntegrityTest() フロー(添付コードのスクリーンショット参照)も確認しましたが、完成後にLBIST/MBISTの終了フラグ( LBESW0 / MBESW0)が1に設定され ていると期待されています。しかし、実際のデバッグ中に LBISTとMBISTのエンドフラグビットの両方が0であって1ではない ことがわかり ました。なぜMCU_ST_DONE_RESETが生成されているのに終了フラグが0になるのでしょうか ? 上記で説明したとおりです。 BISTはSTCU_WDGタイムアウト時間内に実行されませんでした。 よろしくお願いいたします。 ピーター Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? こんにちは、この質問は要約されていますか? Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? こんにちは、 回答を要約して、後ほど投稿します。 よろしくお願いいたします。 ピーター
View full article
Kernel Panic When Registering Custom Camera on i.MX8MP FRDM with Dual MIPI CSI-2 Cameras Dear Support Team, We are currently working on integrating two cameras using the i.MX8MP FRDM board. The camera configuration is as follows: * CSI2:0 is connected to an OV5640 camera. * CSI2:1 is connected to a custom camera module. For both cameras, we configured the device tree so that the image pipeline does not use ISP functionality. The intended pipeline is: "Sensor → MIPI CSI-2 → ISI → Capture" The device tree file is attached for your reference: "imx8mp-frdm-ov5640-cusdom.dts" The issue is that the custom camera driver successfully completes the I2C probe process on I2C3, but a kernel panic occurs when calling "v4l2_async_register_subdev_sensor()". In summary, the kernel panic occurs because "mxc_isi.1" has not been created or registered at the time when the custom camera is registered. The related kernel panic log is attached: "panic-log.txt" We have also attached the probe function implementation of the custom camera driver: "custom_driver_probe.c" We created "imx8mp-frdm-ov5640-cusdom.dts" by referring to the default device tree configuration of the i.MX8MP FRDM board. The OV5640 camera is working correctly. However, the custom camera cannot establish the connection with the ISI pipeline, which eventually causes the kernel panic. After reviewing both the device tree configuration and the custom camera driver, we have not been able to identify the root cause of the issue. The attached "imx8-media-dev.c" file only contains additional debug messages that we added to determine where the kernel panic occurs. Our goal is to operate two different cameras simultaneously through the MIPI CSI-2 interfaces on the i.MX8MP platform. Could you please review the attached device tree and driver code and advise which configuration or implementation part may be incorrect or missing? Your support and guidance would be greatly appreciated. Thank you. Best regards, Seobi
View full article
Problem with MCUXpresso for VSCode SWO Console output Hi! Setup MCUXpresso for VSCode Board KW47-LOC Project kw47loc_hello_world_swo_cm33_core0 LinkServer 25.6.131 or 26.3.123 Description I want to test the SWO capabilities so it can be used with my custom board. On MCUXpresso IDE, it's working well, but on MCUXpresso for VSCode, I have the issue where the SWO console will stop displaying serial output after ~30s. This is really constant. Steps to reproduce - Start a debugging session with the board and project - Halt on main, then press continue - Pause the execution, then configure SWO clock via the Analysis window - Run SWO ITM via the Probe window - Select MCUXpresso SWO console via Output, then resume the execution - Serial output start displaying, then after ~30s it hangs Thank you for your time!
View full article
S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition Hi, I'm writing a bare metal driver for the EMIOS module on my  S32K3X4EVB-T172 evaluation board. Currently, I'm using EMIOS_0 configured, with a 256x global prescaler, with channels as follows: CH_23 -> MC Up Counter ( Timebase for Emios Counter Bus A) @ 625 kHz  CH_17 -> Running in OPWMB mode (using Counter Bus A) CH_22 -> MC Up Counter ( Timebase for Emios Counter Bus F) @ 156.25 kHz CH_9 -> Running in IPM mode (using Counter Bus F ) I'm generating a 16.18hz signal with 50% duty cycle, validated by the oscilloscope, that I'm routing from the OPWMB channel (PTA0) to the IPWMB channel (PTA1). Every 10ms I'm acquiring a IPM sample, which consistently returns 9657/9658, giving me a measured period of 9657 * 0,0000064 = 0,0618048, resulting in a frequency of 1/0,0618048 = 16,18hz. The Issue I'm having is related the almost periodical acquisition of erroneous values (as shown below). period[0] UINT16 40017 period[1] UINT16 9658 period[2] UINT16 9657 period[3] UINT16 9658 period[4] UINT16 40017 period[5] UINT16 9658 period[6] UINT16 9657 period[7] UINT16 9658 period[8] UINT16 40017 period[9] UINT16 9658 period[10] UINT16 9657 period[11] UINT16 40018 period[12] UINT16 9657 period[13] UINT16 9658 period[14] UINT16 9657 period[15] UINT16 40018 Here's a code snippet explaining my current polling-based acquisition logic (no dma and no interrupts): if ((EMIOS0->UC[9].S & 1u) != 0u) { UINT16 a1 = (UINT16)EMIOS0->UC[9].A; UINT16 b1 = (UINT16)EMIOS0->UC[9].B; UINT16 a2 = (UINT16)EMIOS0->UC[9].A; UINT16 b2 = (UINT16)EMIOS0->UC[9].B; if (a1 != a2) { if (b1 != b2) { period[ Index ] = (UINT16)(a2 - b2); } else { period[ Index ] = (UINT16)(a1 - b1); } } else { period[ Index ] = (UINT16)(a2 - b2); } Index++; if (Index > 99u) Index = 0u; EMIOS0->UC[9].S = EMIOS_UC_CLEAR_STATUS_FLG; /* 80008001u */ } When testing different frequencies, the appearance of outliers is highly reduced but still present. Here's an example with 303hz: period[0] UINT16 519 period[1] UINT16 519 period[2] UINT16 519 period[3] UINT16 519 period[4] UINT16 519 period[5] UINT16 519 period[6] UINT16 519 period[7] UINT16 519 period[8] UINT16 519 period[9] UINT16 519 period[10] UINT16 519 period[11] UINT16 519 period[12] UINT16 519 period[13] UINT16 30879 period[14] UINT16 519 period[15] UINT16 519 period[16] UINT16 519 period[17] UINT16 519 period[18] UINT16 519 period[19] UINT16 519 period[20] UINT16 519 period[21] UINT16 519 period[22] UINT16 519 period[23] UINT16 519 period[24] UINT16 519 period[25] UINT16 519 period[26] UINT16 519 period[27] UINT16 519 period[28] UINT16 519 period[29] UINT16 519 period[30] UINT16 519 period[31] UINT16 519 period[32] UINT16 519 period[33] UINT16 519 period[34] UINT16 519 period[35] UINT16 519 period[36] UINT16 519 period[37] UINT16 519 period[38] UINT16 519 period[39] UINT16 519 period[40] UINT16 519 period[41] UINT16 519 period[42] UINT16 519 period[43] UINT16 519 period[44] UINT16 519 period[45] UINT16 519 period[46] UINT16 519 period[47] UINT16 519 period[48] UINT16 519 period[49] UINT16 519 period[50] UINT16 519 period[51] UINT16 519 period[52] UINT16 519 period[53] UINT16 519 period[54] UINT16 519 period[55] UINT16 519 period[56] UINT16 519 period[57] UINT16 519 period[58] UINT16 30879 period[59] UINT16 519 Any help? Re: S32K344 - EMIOS - IPM (Input Period Measurement) erroneous data acquisition Hello @fede_ls , Your polling logic is probably not the primary source of the observed outliers. The values strongly suggest that the period calculation does not handle the rollover of the selected counter bus correctly. The current expression (uint16_t)(A - B) assumes a full 16-bit counter rollover at 65536, but your counter bus F appears to roll over at approximately 35176 ticks. Therefore, whenever the captured period crosses the counter rollover, an additional offset of 65536 - 35176 = 30360 ticks is added, which exactly matches the observed outliers.   Please check the period/modulus configured for CH22, which is used as counter bus F for the IPM channel. The period should be calculated using this actual counter bus modulo value, not using implicit 16-bit unsigned subtraction.   Best regards, Pavel
View full article
关于 i.MX8Mplus 的有限状态机 (FSM) 我们公司使用的是 Toradex 的 Veridin i.MX8Mplus。 此时,输入 SOM_PW_ON 信号以控制 SoM 的电源。(直接连接到 i.mx8MPlusSoC 的 ON/OFF 信号)。*请参考所附示波器上的波形。   由于 SoM 侧的电路配置,电压应为高电压 (1.8V),但在启动后约 800 毫秒内,电压保持在约 0.3-0.4V 的中间电位。 我想知道 SoC 端是如何处理 0.3 至 0.4V 电压作为 ON/OFF 信号的。 该信息未包含在数据表或参考手册中。 我认为,在极短的开/关操作(<5秒)的情况下,系统可能会关机。操作检测标准是否应该是从高电平到低电平的转换以及低电平状态的持续时间? 我还想知道这些时间段的具体最短/最长时间。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MplusのFinite-State Machine (FSM)について 对于 i.MX8M Plus,ONOFF 被处理成一个按住按钮输入,可配置 0/50/100/500 毫秒的延迟和 5/10/15 秒的强制关机时间,并且观察到 0.3–0.4根据现有的输入阈值文档,1.8V ONOFF 网络上的 V 最常被解释为逻辑低电平。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档,观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下,您能否也告诉我一下逻辑上被解释为低电压的阈值是多少? 此外,如果解释为逻辑低,则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒,然后变为逻辑高。 在这种情况下,是否可以认为发生了按钮输入? 我担心按下按钮是否会导致系统在启动后立即自动关机。 Re: i.MX8MplusのFinite-State Machine (FSM)について 顺便问一下,您能否也告诉我一下逻辑上被解释为低电压的阈值是多少? 抱歉。我想知道逻辑值被解读时的电压阈值。 Re: i.MX8MplusのFinite-State Machine (FSM)について 感谢你的回复。 根据现有的输入阈值文档,观察到的 ONOFF 网络上的 V 值在 0.3–0.41.8V 范围内最一致地被解释为逻辑上的低值。 顺便问一下,您能否也告诉我一下被解释为逻辑高电平的电压阈值是多少? 此外,如果解释为逻辑低,则 ON/OFF 状态在启动后将保持逻辑低约 800 毫秒,然后变为逻辑高。 在这种情况下,是否可以认为发生了按钮输入? 我担心按下按钮是否会导致系统在启动后立即自动关机。 致恩智浦技术支持代表 你对此事有何看法? 我还有一个问题: ON/OFF 被处理为电平保持按钮输入,条件为 0/50/100/500 毫秒。 关于这一点,我认为默认值是 0。在这种情况下,如果由于噪声或其他因素导致电平瞬间超过逻辑高电平或逻辑低电平阈值,电平是否会被保持? 我担心,在这种默认设置下,如果接收到噪声,即使只是一瞬间,如果引入了导致逻辑判断与当前保持的逻辑电平相反的因素,也可能导致故障。 Re: i.MX8MplusのFinite-State Machine (FSM)について @Rita_Wang 我又补充了一些问题。 给您带来的不便,我们深表歉意,请您尽快回复。
View full article
MPC5777 BSDL BGA_512 Hello, i'm looking for the BSDL file for this component : MPC5777 BGA-512 Can you send me the file ? Thanks Re: MPC5777 BSDL BGA_512 Hello, I am sending it to you via private message. For future please rise the ticket on NXP.com Best regards, Peter
View full article
What is the reason for this error and how to solve it? Re: 请问这个报错是什么原因,如何解决 Please post questions directly in the forum. For new users many old versions of S32DS and patch packages may no longer be available for download. So the solution has changed. Re: 请问这个报错是什么原因,如何解决 I installed it and it still doesn't work. Re: 请问这个报错是什么原因,如何解决 Hi. This "opens the configuration .mex Error in: The current tool version does not support the processor version " This is usually caused by the S32DS Update n or S32K3 Development Package not having the version mentioned in the RTD Release Note installed. Please install in S32DS v3.4. 3.4.3_D2112   S32 Design Studio for S32 Platform v.3.4 Update 3 with support for S32K3 devices Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct " button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- 回复: 请问这个报错是什么原因,如何解决 Have you resolved this issue? I'm currently encountering a similar problem; the PlatformSDK S32K5 version doesn't support the S32K566 processor. 回复: 请问这个报错是什么原因,如何解决 Hi The S32K5 has not yet been officially released, and there are no public links on the NXP website to download software packages such as RTD and Development Pack. These types of problems are usually caused by these software packages not being installed correctly. Please contact your company's FAE for assistance. Our online technical support will only be available after the official release of this type of NPI product. Best Regards, Robin
View full article
iMX8M Plus 2nd MIPI CSIカメラ:FIFOオーバーフローエラー こんにちは、 私はデュアルカメラのアプリケーションを開発しています。 カメラの解像度と画像フォーマットは2592x1944、RAW8です。 データパスとドライバ構造は カメラ(センサ ドライバ.c)-->MIPI-CSI2 (imx8-mipi-csi2-sam.c) --> ISI (imx8-isi-cap.c)--> RAM ドライバーを改造した後、CSI1の映像ストリームは2592x1944、RAW8、50~60fpsで正常に受信できました。 CSI2から別のビデオストリームを取得したいのですが、FIFOオーバーフローエラーのためうまくいきません。 [ 43.892406] mxc-mipi-csi2.1:フレーム終了イベント情報:1 [ 43.897023] MXC-MIPI-CSI2.1:フレームスタートイベント情報:2回 [ 43.901811] MXC-MIPI-CSI2.1:奇数フレームイベント後の非画像データ:0 [ 43.908248] MXC-MIPI-CSI2.1:奇数フレームイベント前の非画像データ:0 [ 43.914771] MXC-MIPI-CSI2.1:偶数フレームイベント情報後の非画像データ:0 [ 43.921297] MXC-MIPI-CSI2.1:フレームイベント前の非画像データ:0 [ 43.927906] MXC-MIPI-CSI2.1:未知のエラーイベント情報: 0 [ 43.932868] mxc-mipi-csi2.1:CRCエラーイベント:0 [ 43.937484] MXC-MIPI-CSI2.1:ECCエラーイベント情報:0件 [ 43.942097] mxc-mipi-csi2.1: FIFOオーバーフローエラーイベント情報:1209788 [ 43.948100] MXC-MIPI-CSI2.1:ロストフレーム終了エラーイベント:0 [ 43.953672] MXC-MIPI-CSI2.1:ロストフレームスタートエラーイベント情報:0 [ 43.959413] MXC-MIPI-CSI2.1:SOTエラーイベント情報:0 hs-settleとclk-settleのパラメータを変更してみましたが、うまくいきませんでした。 リファレンスマニュアルによると、CSI1の最大動作周波数は500MHzですが、CSI2は266MHzです。 CSI2周波数が低いと、フレーム解像度やフレームレートが制限されますか? どうすれば解決できますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error こんにちは、 この問題は解決しましたか?私もビジョン ComponentsのIMX900Cカメラ(2048x1536)で同じ問題を経験しています。CSI1からISI0へのストリーミングは30fpsで正常に動作しますが、同じ設定でCSI2からISI1へのストリーミングを行うとオーバーフローエラーが発生します。 よろしくお願いします! Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error こんにちは、igorpardykov 再開まで今しばらくお待ちください。 下のリファレンスマニュアルを再度確認しました。 • 4Kp30で2つの未処理カメラストリーム(すなわちスケーリングなし)、 システム負荷とユースケース RAW8形式のビデオストリーム(CSCをバイパス)を取得したいのですが、それは未処理のストリームに対応しているということでしょうか? これはISIが2つの4Kp30動画ストリームを同時に使うことをサポートしているということでしょうか? 2fps未満のフレームレートを遅くした場合(例えば30fps未満)、FIFOオーバーフローの問題は解決できますか? 2つのISPが同時に利用されている場合、それぞれが以下をサポートしています: ・最大解像度1080p(1936x1188)」 ちなみに、私はISPを一切使用しておらず(デバイスツリーで全て無効化しています)、ISIのみを使用しています。 事前に感謝いたします。 Re: iMX8M Plus 2nd MIPI CSI Camera : FIFO Overflow Error こんにちは、Dy はい、おっしゃる通りです。FIFOオーバーフローはISIのパフォーマンス機能によって発生する可能性があります。 セクション13.1.2で説明されているi.MX 8M Plusアプリケーション プロセッサ リファレンス・マニュアル ディスプレイ・インターフェース 「ISIの主な特徴は以下の通りです。 画像プロセッシング ・1080p30で処理された2つのカメラストリーム ・2つの未処理カメラストリーム(すなわちスケーリングなし)は4Kp30で、 システム負荷とユースCASE... 2つのISPが同時に利用されている場合、それぞれが以下をサポートしています: ・最大解像度1080p(1936x1188)」 よろしくお願いします イゴール
View full article
S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? Hi NXP experts, I am developing on the S32K388 and using the SPD (Safety Peripheral Drivers) v1.0.6 as a reference to implement the STCU/BIST functionality. In my main.c, I enable the BIST test and then read the reset reason from MC_RGM. I observe that the reset reason returned is MCU_ST_DONE_RESET. I have the following questions: Does the value written to the STCU_WDG register affect the online watchdog timeout duration during BIST execution? In other words, is the WDTOSW flag directly triggered when the BIST execution time exceeds the STCU_WDG value? When MCU_ST_DONE_RESET is reported, can I conclude that both LBIST and MBIST completed normally and passed? Or does this reset reason only indicate that the STCU sequence finished, regardless of whether a timeout occurred? In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1 (see attached screenshot). Does this mean the BIST execution timed out and was prematurely terminated/aborted, so the memory tests were actually forced to stop before completion? Or can MCU_ST_DONE_RESET still be generated even if WDTOSW was set? I also checked the Bist_IntegrityTest() flow from the SPD driver (see attached code screenshot), which expects the LBIST/MBIST end flags (LBESW0/MBESW0) to be set to 1 after completion. However, during my actual debugging, I found that both the LBIST and MBIST end flag bits are 0, not 1. Why would the end flags be 0 even though MCU_ST_DONE_RESET was generated? Additional context: I am using the Safety Boot BIST configuration table similar to the SPD example. Observed STCU_WDG value: 0xC35E (49998). Observed STCU_ERR_STAT value: 0x80140 (RFSW=1, WDTOSW=1). Could you please help clarify the relationship between STCU_WDG, WDTOSW, MCU_ST_DONE_RESET, and the LBESW0/MBESW0 end flags? Thank you in advance. Best regards, Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? Hello, In my main.c, I enable the BIST test and then read the reset reason from MC_RGM. I observe that the reset reason returned is MCU_ST_DONE_RESET. That is correct behaviour. 1. Does the value written to the STCU_WDG register affect the online watchdog timeout duration during BIST execution? In other words, is the WDTOSW flag directly triggered when the BIST execution time exceeds the STCU_WDG value? No. STCU_WDG is watchdog for BIST execution. Not connected anyhow to SWT. SWT module is also tested by BIST, so the SWT module is not functional during the BIST. Therefore you guard execution time with STCU_WDG. When MCU_ST_DONE_RESET is reported, can I conclude that both LBIST and MBIST completed normally and passed? Or does this reset reason only indicate that the STCU sequence finished, regardless of whether a timeout occurred? You can only conclude that the test procedure ended. Results are stored in different registers like STCU2 Online LBIST Status (LBSSW0) - such will indicate you pass /fail conditions. In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1 (see attached screenshot). Does this mean the BIST execution timed out and was prematurely terminated/aborted, so the memory tests were actually forced to stop before completion? Or can MCU_ST_DONE_RESET still be generated even if WDTOSW was set? MCU_ST_DONE_RESET is always generated after test. No matter on the results. As during the test the registers and RAMs are tested with patterns. Reegisters need to be set to the default values - such are loaded during reset. Otherwise you will get all registers full of test patterns and the uC wont operate with such random values. RAMs need to be initialized by SW as the ECC syndromers will not match data after BIST execute test patterns on the RAMs. In my case, the ERR_STAT register shows WDTOSW = 1 and RFSF = 1  This means test fails. I also checked the Bist_IntegrityTest() flow from the SPD driver (see attached code screenshot), which expects the LBIST/MBIST end flags (LBESW0/MBESW0) to be set to 1 after completion. However, during my actual debugging, I found that both the LBIST and MBIST end flag bits are 0, not 1. Why would the end flags be 0 even though MCU_ST_DONE_RESET was generated? Explained above. Your BIST did not executed in the STCU_WDG timeout. Best regards, Peter Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? Hello, has this question been summarized? Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? Hello, let me summarize the answers and I will post them later. Best regards, Peter
View full article
デュアルMIPI CSI-2カメラを搭載したi.MX8MP FRDMでカスタムカメラを登録する際にカーネルパニックが発生する サポートチームの皆様、 現在、i.MX8MP FRDMボードを使用して2台のカメラを統合する作業を進めています。 カメラの構成は以下のとおりです。 * CSI2:0はOV5640カメラに接続されています。 * CSI2:1はカスタムカメラモジュールに接続されています。 両方のカメラで、画像パイプラインがISP機能を使わないようにデバイスツリーを設定しました。意図されたパイプラインは以下の通りです: 「センサ → MIPI CSI-2 → ISI → キャプチャー」 デバイスツリーファイルを添付しましたので、ご参照ください。「imx8mp-frdm-ov5640-cusdom.dts」 問題は、カスタムカメラドライバーがI2C3上でI2Cプローブ処理を正常に完了する一方で、「v4l2_async_register_subdev_sensor()」を呼び出すとカーネルパニックが発生することです。 要約すると、カーネルパニックが発生するのは、カスタムカメラが登録される時点で「mxc_isi.1」が作成または登録されていないためです。 関連するカーネルパニックログを添付します: "panic-log.txt" また、カスタムカメラドライバーのプローブ機能実装「custom_driver_probe.c」も添付しました i.MX8MP FRDMボードのデフォルトのデバイスツリー構成を参照して、「imx8mp-frdm-ov5640-cusdom.dts」を作成しました。 OV5640カメラは正常に動作しています。しかし、カスタムカメラはISIパイプラインとの接続を確立できず、最終的にカーネルのパニックを引き起こします。 デバイスツリーの設定とカスタムカメラドライバーの両方を確認しましたが、問題の根本原因を特定することはできませんでした。 添付の「imx8-media-dev.c」ファイルには、カーネルパニックが発生する場所を特定するための追加デバッグメッセージのみが含まれています。 私たちの目標は、i.MX8MPプラットフォーム上のMIPI CSI-2インターフェースを通じて、2台の異なるカメラを同時に操作することです。 添付のデバイスツリーとドライバーコードを確認し、どの設定や実装部分が誤っているか、あるいは欠けているかを教えていただけますか? 皆様のサポートとご助言をいただけると大変ありがたいです。 よろしくお願いします。 よろしくお願いします、 ソビ
View full article
S32K388 STCU BIST:STCU_WDG 值是否会影响在线看门狗超时? 各位NXP专家,大家好! 我正在使用S32K388进行开发,并以SPD (安全外设驱动程序) v1.0.6为参考来实现 STCU/BIST 功能。 在我的main.c 文件中,我启用了 BIST 测试,然后从MC_RGM读取复位原因。我观察到返回的复位原因是MCU_ST_DONE_RESET 。 我有以下几个问题: 写入 STCU_WDG 寄存器的 值是否会 影响 BIST 执行期间的 在线看门狗超时 时长?换句话说, 当 BIST 执行时间超过 STCU_WDG 值时, WDTOSW 标志是否会被直接触发 ? 当 报告 MCU_ST_DONE_RESET 时,我是否可以得出结论, LBIST 和 MBIST 都已正常完成并通过 ?或者,此 RESET 原因仅表示 STCU 序列已完成,而不管是否发生超时? 就我而言, ERR_STAT 寄存器显示 WDTOSW = 1 和 RFSF = 1 (见附件截图)。这是否意味着 BIST 执行 超时并被提前终止/中止 ,导致内存测试 在完成前 被迫停止 ?或者即使 WDTOSW 已设置, 是否 仍然可以生成 MCU_ST_DONE_RESET ? 我还检查了 SPD驱动程序中的 Bist_IntegrityTest() 流程(见附件代码截图),该流程预期LBIST/MBIST完成后结束标志( LBESW0 / MBESW0 )应设置为1。然而,在实际调试过程中,我发现 LBIST和MBIST结束标志位均为0,而非1。 为什么即使 生成了 MCU_ST_DONE_RESET, 结束标志位仍然为0? 补充信息: 我正在使用类似于 SPD 示例的功能安全启动 BIST 配置表。 观察到的STCU_WDG值: 0xC35E (49998)。 观察到的STCU_ERR_STAT值: 0x80140 ( RFSW=1 , WDTOSW=1 )。 请问您能否帮忙解释一下STCU_WDG 、 WDTOSW 、 MCU_ST_DONE_RESET和LBESW0 / MBESW0结束标志之间的关系? 提前谢谢您。 此致, Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? 你好, 在我的main.c 文件中,我启用了 BIST 测试,然后从MC_RGM读取复位原因。我观察到返回的复位原因是MCU_ST_DONE_RESET 。 这是正确的行为。 1. 写入 STCU_WDG 寄存器的 值是否会 影响 BIST 执行期间的 在线看门狗超时 时长?换句话说, 当 BIST 执行时间超过 STCU_WDG 值时, WDTOSW 标志是否会被直接触发 ? 不。STCU_WDG 是 BIST 执行的监视程序。与SWT没有任何关联。SWT 模块也需要通过 BIST 进行测试,因此 SWT 模块在 BIST 期间无法正常工作。因此,您可以使用 STCU_WDG 来保护执行时间。 当 报告 MCU_ST_DONE_RESET 时,我是否可以得出结论, LBIST 和 MBIST 都已正常完成并通过 ?或者,此 RESET 原因仅表示 STCU 序列已完成,而不管是否发生超时? 只能得出测试程序结束的结论。结果存储在不同的寄存器中,例如 STCU2 在线 LBIST 状态 (LBSSW0) - 此类寄存器将指示您是否通过/失败条件。 就我而言, ERR_STAT 寄存器显示 WDTOSW = 1 和 RFSF = 1 (见附件截图)。这是否意味着 BIST 执行 超时并被提前终止/中止 ,导致内存测试 在完成前 被迫停止 ?或者即使 WDTOSW 已设置, 是否 仍然可以生成 MCU_ST_DONE_RESET ? MCU_ST_DONE_RESET 总是在测试后生成。结果如何并不重要。测试过程中,寄存器和 RAM 将按照特定模式进行测试。寄存器需要设置为默认值——这些值在RESET期间加载。否则,所有寄存器都会被测试模式填满,微控制器将无法处理这样的随机值。 由于 BIST 在 RAM 上执行测试模式后,ECC 校验和将无法匹配数据,因此需要通过软件初始化 RAM。 就我而言, ERR_STAT 寄存器显示 WDTOSW = 1 和 RFSF = 1 这意味着测试失败。 我还检查了 SPD驱动程序中的 Bist_IntegrityTest() 流程(见附件代码截图),该流程预期LBIST/MBIST完成后结束标志( LBESW0 / MBESW0 )应设置为1。然而,在实际调试过程中,我发现 LBIST和MBIST结束标志位均为0,而非1。 为什么即使 生成了 MCU_ST_DONE_RESET, 结束标志位仍然为0? 如上所述。 您的 BIST 未在 STCU_WDG 超时时间内执行。 顺祝商祺! Peter Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? 您好,这个问题有总结吗? Re: S32K388 STCU BIST: Does STCU_WDG value affect the online watchdog timeout? 你好, 我先总结一下答案,稍后会发布。 顺祝商祺! Peter
View full article
请问这个报错是什么原因,如何解决 Re: 请问这个报错是什么原因,如何解决 请直接在论坛里发帖提问。 对于新用户很多老版本S32DS和patch软件包可能都已经无法下载了。所以解决方法也变了。 Re: 请问这个报错是什么原因,如何解决 安装了还是不行 Re: 请问这个报错是什么原因,如何解决 Hi 这类"打开配置 .mex 中出错: 当前工具版本不支持处理器 的 版本" 通常都是S32DS Update n或S32K3 Development Package未安装RTD Release Note里提到的版本导致的。 请在S32DS v3.4里安装 3.4.3_D2112   S32 Design Studio for S32 Platform v.3.4 Update 3 with support for S32K3 devices  Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- 回复: 请问这个报错是什么原因,如何解决 请问您这个问题解决了吗,我目前遇到了类似问题,不支持处理器S32K566的PlatformSDKS32K5版本 回复: 请问这个报错是什么原因,如何解决 Hi  S32K5尚未正式发布,NXP官网上没有公开的链接下载RTD、Development Pack 等软件包。这类问题通常就是这些软件包没有正确安装导致的。 请联系对接你们公司的FAE获取,我们线上技术支持要等这类NPI产品正式发布后才支持。 Best Regards, Robin
View full article