Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
ADC应用模块选择 我想围绕 MXP 开发板开发一个应用程序,但我很难选择可以使用的具体计算模块。种类繁多,我有点不知所措,不确定哪些产品真正能满足我的需求。 据我了解,有多家片上系统 (SoC) 提供模数转换器 (ADC)。我需要一台计算能力更强、至少有 4 个 ADC 通道的设备。我可以使用哪些具体的开发板?我可以使用哪些模块和开发板来构建这个应用程序?是否有供应商可以协助我选择要购买的具体板? Re: Module selection for ADC application 我认为使用 MPU 可以确保有足够的处理能力,而且我们并不太担心功耗或成本。我们也对使用Profinet很感兴趣。然后它应该至少有 4 个 ADC 通道,每个通道的采样率超过 100ksps。据我了解,i.MX 9 MPU 可能适用。 我想到的一种替代方案是购买一台树莓派 Pico,并配备一个独立的 ADC 模块和以太网模块。但我认为恩智浦的系统应该能够满足我的所有需求。即使我选定了某个特定的芯片,市面上的产品种类也很多,而且我通常也不清楚能否得到合适的ADC,而ADC对我来说是最重要的特性。 Re: Module selection for ADC application 你好, 你要买什么? 它是微控制器(MCU)吗?还是微处理器(MPU)? 如果您能提供更多关于该项目的信息,我们可以为您提供帮助。 此外,我们的网页上还有产品搜索功能。 https://www.nxp.com/design/design-center/development-boards-and-designs:EVDEBRDSSYS?collection=devBoardsDesigns&start=0&max=12&language=en&query=typeTax %3E% 3Et633_t763 此致敬礼/Saludos, 阿尔多。 Re: Module selection for ADC application 你好, 是的,i.MX9 系列的任何一款处理器都可以使用,具体哪一款更适合您的使用场景,取决于您的显卡和其他外设。 为此,i.MX91、i.MX93 和 i.MX95 这三款芯片都采用了 FRDM 板,并且 ADC 的规格相同: • 它包含八个通道,其中四个通道连接到封装中的引脚。 • 支持 1MS/s 的工作频率 • 多种启动转换模式(正常、注入式) 普通模式支持单次拍摄和扫描(连续)转换 注入模式仅支持单次转换 • 支持 TRGMUX,允许任何 ADC 通道使用 16 个触发通道 i.MX93 https://www.nxp.com/products/i.MX93 i.MX93 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 i.MX91 https://www.nxp.com/products/i.MX91 i.MX91 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91 i.MX95 https://www.nxp.com/products/i.MX95 i.MX95 FRDM https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX95 另外,您也可以查看每个 EVK 的相关信息,但既然您提到了 RPI,我认为 FRDM 板可能会让您感兴趣。 此致敬礼/Saludos, 阿尔多。
記事全体を表示
imx95 在挂起到内存时关闭 vdd_soc 你好, 我们尝试在IDLE状态后关闭VDD_SOC。 例如在 m33 控制台上: lm 暂停 lm M7 挂起 闲置的 然后我们关闭 VDD SOC(通过设置 pf09 待机模式并关闭 VDD SOC) 然后松开备用销, m33 上的 VDD_SOC 从头开始,我们仍然节省了 RAM。 我们在 spl 中修改代码,使其在 bl31 中使用热启动路径,并成功启动到内核。 然而,之后内核就卡住了,您可以查看以下最新日志。 我想知道这两个案例之间可能存在哪些区别: - 正常挂起情况:(保留 vdd_soc) - 如果出现异常情况(vdd_soc 关闭),我们是否应该在 m33 启动时执行其他操作来重新初始化某些内容? [2026-07-06 10:39:55.070]注意:BL31:已恢复 NS 上下文 [2026-07-06 10:39:55.074][ 1018.529356][T3251] 调用 its_restore_enable+0x0/0x1ac [2026-07-06 10:39:55.080][ 1018.529356][T3251] 调用 cpu_pm_resume+0x0/0x5c [2026-07-06 10:39:55.084][ 1018.529356][T3251] 调用 kvm_resume+0x0/0x68 [2026-07-06 10:39:55.089][ 1018.529356][T3251] 调用 irq_gc_resume+0x0/0x110 [2026-07-06 10:39:55.094][ 1018.529356][T3251] 调用 irq_pm_syscore_resume+0x0/0x24 [2026-07-06 10:39:55.100][ 1018.529356][T3251] 调用 timekeeping_resume+0x0/0x188 [2026-07-06 10:39:55.105][ 1018.529356][T3251] 调用 sched_clock_resume+0x0/0xd0 [2026-07-06 10:39:55.110][ 1018.529619][T3251] 启用非启动 CPU... [2026-07-06 10:39:55.142][ 1018.559214][T0] 在 CPU1 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3:CPU1:找到分发器 100 区域 0:0x0000000048080000 [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1:已启动辅助处理器 0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1 已启动 [2026-07-06 10:39:55.191][ 1018.608610][T0] 在 CPU2 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3:CPU2:找到重新分发器 200 区域 0:0x00000000480a0000 [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2:已启动辅助处理器 0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2 已启动 [2026-07-06 10:39:55.240][ 1018.657836][T0] 在 CPU3 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3:CPU3:找到 redistributor 300 区域 0:0x00000000480c0000 [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3:已启动辅助处理器 0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3 已启动 [2026-07-06 10:39:55.289][ 1018.707065][T0] 在 CPU4 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3:CPU4:找到 400 号分发器区域 0:0x00000000480e0000 [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4:已启动辅助处理器 0x0000000400 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4 已启动 [2026-07-06 10:39:55.339][ 1018.756298][T0] 在 CPU5 上检测到 VIPT 指令缓存 [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3:CPU5:找到 500 重分发器区域 0:0x0000000048100000 [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5:已启动辅助处理器 0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5 已启动 [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-lifecycle rpmsg-lifecycle:PM:调用 rpmsg_lifecycle_resume_noirq @ 3251,父级:平台 [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle:PM:rpmsg_lifecycle_resume_noirq 在 1 微秒后返回 0 [2026-07-06 10:39:55.383][ 1018.802181][T3251]arm-smmu-v3 490d0000.iommu:PM:调用 arm_smmu_resume [arm_smmu_v3] @ 3251,父级:49000000.总线 [2026-07-06 10:39:55.394][ 1018.812966][T3251]arm-smmu-v3 490d0000.iommu:PM:arm_smmu_resume [arm_smmu_v3] 在 60 微秒后返回 0 [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM:正在调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:44000000.总线 [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 3 微秒后返回 0 [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 2 微秒后返回 0 [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM:调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 1 微秒后返回 0 [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM:正在调用 imx_mu_resume_noirq [imx_mailbox] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM:imx_mu_resume_noirq [imx_mailbox] 在 0 微秒后返回 0 [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM:调用 lpuart_resume_noirq [fsl_lpuart] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM:lpuart_resume_noirq [fsl_lpuart] 在 2 微秒后返回 0 [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM:调用 lpuart_resume_noirq [fsl_lpuart] @ 3251,父级:44000000.总线 [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM:lpuart_resume_noirq [fsl_lpuart] 在 4 微秒后返回 0 [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 1 微秒后返回 0 [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:42000000.总线 [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM:调用 lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251,父级:44000000.总线 [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM:lpi2c_resume_noirq [i2c_imx_lpi2c] 在 0 微秒后返回 0 [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.中断控制器:PM:调用 genpd_resume_noirq @ 3251,父级:soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM:GENPD_RESUME_NOIRQ dev=4b0b0000.中断控制器domain=display task=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD 功能域=13 状态=开启 任务=kworker/4:5 进程 ID=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram 日志中没有错误,但 a55 就此停止运行。 正常情况下(未关闭vddsoc),它会继续运行。 我们试图降低睡眠模式下的功耗,因此我们尝试通过这种方式关闭 vddsoc,同时保持 RAM 的运行。 Re: imx95 turn off vdd_soc when suspend to ram 日志中似乎没有任何错误信息。是否关闭电压可能会导致电流消耗的差异。你注意到功耗方面有任何变化吗?为什么要关闭VDDSOC? Re: imx95 turn off vdd_soc when suspend to ram 嗨@thinkembedsw VDD_SOC(及相关数字电源)电压降低至“挂起模式”电压。它不支持直接关闭。 BR
記事全体を表示
imx95はRAMへのサスペンド時にvdd_socをオフにする こんにちは、 アイドル状態になった後、VDD_SOCをオフにしようとしています。 例えば、m33コンソールでは次のようになります。 lm サスペンド lm M7 サスペンション アイドル 次に、vdd socをオフにします(pf09のスタンバイモードをvdd socオフに設定することによって)。 次にスタンバイピンを放します。 m33 の VDD_SOC は最初からやり直しますが、RAM は保存されたままです。 bl31でウォームブートパスを実行するようにsplのコードを変更し、カーネルへの起動に成功しました。 しかしその後、カーネルが詰まってしまい、以下の通りの「最新のログ」が確認できます。 2つのCASEで何が違うのか気になります。 - CASEノーマルサスペンド:(保持vdd_soc) - Case Abnormal(vdd_soc オフ) この場合、M33の起動時に何か再初期化するために別のことをすべきでしょうか? [2026-07-06 10:39:55.070]通知: BL31: ウォームレジュームNSコンテキストが復元されました [2026-07-06 10:39:55.074][ 1018.529356][T3251] its_restore_enable+0x0/0x1ac を呼び出しています [2026-07-06 10:39:55.080][ 1018.529356][T3251] cpu_pm_resume+0x0/0x5c を呼び出しています [2026-07-06 10:39:55.084][ 1018.529356][T3251] kvm_resume+0x0/0x68 を呼び出しています [2026-07-06 10:39:55.089][ 1018.529356][T3251] irq_gc_resume+0x0/0x110 を呼び出しています [2026-07-06 10:39:55.094][ 1018.529356][T3251] irq_pm_syscore_resume+0x0/0x24 を呼び出しています [2026-07-06 10:39:55.100][ 1018.529356][T3251] timekeeping_resume+0x0/0x188 を呼び出しています [2026-07-06 10:39:55.105][ 1018.529356][T3251] sched_clock_resume+0x0/0xd0 を呼び出しています [2026-07-06 10:39:55.110][ 1018.529619][T3251] ブート以外のCPUを有効にする... [2026-07-06 10:39:55.142][ 1018.559214][T0] CPU1でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3: CPU1: 再分配器100の領域0:0x0000000048080000が見つかりました [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1: 起動済みのセカンダリプロセッサ0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1が起動しました [2026-07-06 10:39:55.191][ 1018.608610][T0] CPU2でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3: CPU2: 再分配器200の領域0:0x00000000480a0000が見つかりました [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2:起動されたセカンダリプロセッサ0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2が起動しました [2026-07-06 10:39:55.240][ 1018.657836][T0] CPU3でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3: CPU3: 再分配器300領域0:0x00000000480c0000が見つかりました [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3: 起動された二次プロセッサ0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3が起動しました [2026-07-06 10:39:55.289][ 1018.707065][T0] CPU4でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3: CPU4: 再分配器400領域0:0x00000000480e0000が見つかりました [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4:セカンダリプロセッサ0x0000000400起動 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4が起動しました [2026-07-06 10:39:55.339][ 1018.756298][T0] CPU5でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3: CPU5: 再分配器500領域0:0x0000000048100000が見つかりました [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5:起動したセカンダリプロセッサ0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5が起動しました [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-ライフサイクル rpmsg-lifecycle: PM: 呼び出し rpmsg_lifecycle_resume_noirq @ 3251、親: プラットフォーム [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle: PM: rpmsg_lifecycle_resume_noirq が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.383][ 1018.802181][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] @ 3251 を呼び出し中、親プロセス: 49000000.bus [2026-07-06 10:39:55.394][ 1018.812966][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] が 60 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 3 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 42000000.bus [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 44000000.bus [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 4 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.interrupt-controller:PM: genpd_resume_noirq @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM: GENPD_RESUME_NOIRQ dev=4b0b0000.interrupt-controllerドメイン=display タスク=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD ディスプレイ ドメイン=13 状態=オン タスク=kworker/4:5 pid=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram ログにはエラーは記録されていませんが、a55はそこで停止してしまいます。 通常の場合(vddsoCを切らさずに)、そのまま動作を続けます スリープモードでの消費電力を減らそうとしているので、この方法でvddsocをオフにしつつRAMは残しています。 Re: imx95 turn off vdd_soc when suspend to ram ログにはエラー情報がないようです。電圧を遮断するかどうかによって、消費電流に差が生じる可能性があります。消費電力に違いを感じますか?また、VDDSOCをオフにしたい理由は何ですか? Re: imx95 turn off vdd_soc when suspend to ram こんにちは@thinkembedsw VDD_SOC(および関連するデジタル電源)電圧は、「サスペンドモード」電圧まで低下します。直接電源を切ることはサポートしていません BR
記事全体を表示
GuiGuiDer2.0.0构建目标设备时出错 我现在创建了一个基于frdm_mcx947的guiguider工程,使用的版本是2.0.0,选用的ARM GCC为14.4.1。 我已经配置好了arm gcc工具。 编译时报错信息如下:C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. 我使用在cmd中查找编译工具是成功的: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
記事全体を表示
对 Guiguider 许可证合规性的担忧 尊敬的恩智浦半导体公司: 我写信是为了举报贵公司 Guider 软件可能违反许可协议的情况。 据我们了解,您的 Guider 软件许可明确禁止将其用于基于非 NXP 系列芯片的产品开发中的商业用途。然而,一家大型跨国公司目前正在使用该软件开发基于瑞芯微系列主控芯片的商业产品,这显然违反了您的许可条款。 我想请问:NXP是否计划采取任何强制措施来保护其在此事中的知识产权?此外,如果我要就此违规行为提出正式投诉,您需要哪些具体证据才能启动调查? 期待您的回复。 回复: Concern about Guiguider License Compliance guiguider违反许可证使用问题。 贵公司的guider软件许可证明确禁止使用于非nxp系列芯片的商业开发。现有某大型跨国企业公司违反了该许可证条例,将该软件应用于瑞芯微系列主控芯片的商业产品上。贵公司是否会展开维权活动?如果我想举报,应该提供什么证据。
記事全体を表示
i.MX RT1050 ダウンロードアルゴリズム 現在使用している開発環境は、i.MX RT1050 を使用した MCUXPRESSO IDE です。i.MX RT1050 には内蔵フラッシュメモリがないため、外部フラッシュメモリを使用する際にはアルゴリズムをダウンロードする必要があることは理解しています。しかし、ダウンロードするアルゴリズムは使用するフラッシュメモリによって異なります。公式ドキュメントには、目的のアルゴリズムを迅速かつ容易に入手する方法が記載されていますか? Re: i.MX RT1050 下载算法 こんにちは、SDFDSFSFさん、 以下の順序で行うことをお勧めします。 1. プロジェクトのプロパティで、外部のFlashダウンロードアルゴリズムを選択します。NXPは、いくつかの主要なFlashダウンロードアルゴリズムを提供しています。 プロジェクトを右クリックして「プロパティ」→「MCU設定」→「メモリの詳細」を選択し、NXPがサポートするフラッシュドライバを選択してください。 MCUXpresso 用のフラッシュドライバは通常、nxp\LinkServer_xx.x.xx\binaries\Flash ディレクトリにあり、拡張子は .cfx です。 2. 選択したフラッシュメモリがSFDPをサポートしている場合は、まずSFDPドライバを試してください。 MCUXpressoでは、MIMXRT1050_SFDP_QSPI.cfxのようなドライバを選択できます。このタイプのSFDPドライバの重要な点は、フラッシュメモリに自己記述パラメータを組み込むことで、特定の部品番号固有のアルゴリズムへの依存度を低減できることです。 3. テンプレートを使って自分で作成する。 アプリケーションマニュアルを参照してください:https://www.nxp.com/docs/en/application-note/AN13386.pdfカスタムCFXファイルを生成します。変更する際は、主要なパラメータは、外部フラッシュデータシートのテスト結果とSDKに含まれるflexspi_nor_pollingデモから取得する必要があります。 ダウンロードアルゴリズムに加えて、XIP/ブートヘッダーの設定も必要です。詳細については、「解決済み:フラッシュインターフェースの初期化 - NXPコミュニティ」を参照してください。 上記は基本的な方法です。使用しているFlashの機種や、現時点でどのような問題に直面しているかなど、より詳細な情報を提供していただければ、より的確なサポートを提供できます。 よろしくお願いします、 シェリー・チャン
記事全体を表示
IMX8Mini上のソフトウェアISP 弊社ではIMX8miniを使用していますが、以前はハードウェアISPを内蔵したimx8mplusを使用していました。しかし、IMX8miniにはハードウェアISPのサポートがありません。 デベイヤリング、3A、ガンマ補正、その他のISP機能を実行するためのオプションにはどのようなものがありますか?調査の結果、NXP Soft ISPはimx8miniでは利用できず、libcameraはimx8miniで公式にはサポートされておらず、またlibcameraとそのパイプラインハンドラー関連の統合に関する経験もありませんでした。 もう一つ、imx8mplusでは、ビデオをISP経由でルーティングするか、キャプチャモードでISI経由でビデオをルーティングする機能があります。iMX8miniでは、vvcamスタックなどの機能がないのに、どうやってそれが起こるのですか? ちなみに、当社のカメラには内蔵ISPが搭載されていないため、プロセッサ上でソフトウェアISPを実行する必要があります。 皆さんの中には、このことをご存知の方もいらっしゃると思います。 ありがとうございます。 S ヴィシュヌ i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Software ISP on the IMX8Mini こんにちは、 @SiddavatamVishnu さん。 i.MX8M Miniでは、カメラデータはCSI+ISIを使用してセンサから直接メモリに転送されます。ISIはISPではありません。画像を移動させたり、多少サイズ変更したりできるだけです。i.MX8M PlusのようにRAW画像を処理できるステージはなく、vvcamやSoft ISPスタックも利用できません。 Libcameraはi.MX8M Miniでは非常に限定的な形でしかサポートされていません。この機能は、センサー内部にISP(画像信号プロセッサ)を内蔵したカメラ(いわゆる「スマートカメラ」)でのみ動作します。i.MX8MMに搭載されているLibcameraは、ISP機能を追加するものではなく、単にキャプチャの管理を支援するものです。これは、失われたISPの代わりにはなりません。 CPU上で完全なソフトウェアISPを実行することは技術的には可能ですが、CPU負荷、消費電力、複雑さが高いため推奨されません。また、NXPはi.MX8M Miniでそのようなソリューションを提供またはサポートしていません。 i.MX8M Miniはカメラのキャプチャ専用です。ISP機能が必要な場合は、SoCの外部で処理する必要があります。 よろしくお願いします、 チャビラ Re: Software ISP on the IMX8Mini libcameraにはSoftISPのGPU実装があり、i.MX8MMで使えるかもしれませんが、i.MX8MMのGPUはそれほど大きくないため、高いスループットが得られないかもしれません。動作はしますが、高フレームレートではないので、あなたの要件次第でしょう。
記事全体を表示
6.12 内核中的 i.MX6ULL 以太网时钟错误 6.12 中的设备树示例对以太网 Phy 进行了硬编码,而不是修复我们在使用的 NXP 5.15 内核中不存在的这个错误。 我们最终编写了一个补丁,因为我们希望内核能够灵活地检测 PHY,而 fec 模块中存在这个问题。该补丁使得在加载驱动程序时读取物理寄存器,而不是在设备树中进行规避。 On i.MX6UL boards that hang both RMII PHYs on FEC2's MDIO bus, PHY@0 uses the FEC1 (ENET1) RMII reference clock. Kernel 6.12 routes that clock through ENET1_REF_SEL, which may not be active when FEC2 reads PHY@0's ID during of_mdiobus_register(), yielding a bogus ID (0x01080108) and binding the generic PHY driver. Briefly enable FEC1's enet_clk_ref (looked up from DT, not via probe defer) around of_mdiobus_register() so the PHY ID read succeeds without changing FEC probe order and breaking FEC_QUIRK_SINGLE_MDIO. --- drivers/net/ethernet/freescale/fec_main.c | 59 +++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 811a66062..46f37be0c 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -2540,6 +2540,39 @@ static int fec_enet_mii_probe(struct net_device *ndev) return 0; } +static bool fec_enet_mdio_has_phy_addr0(struct device_node *mdio) +{ + struct device_node *child; + u32 reg; + + for_each_available_child_of_node(mdio, child) { + if (of_property_read_u32(child, "reg", ®)) + continue; + if (reg == 0) { + of_node_put(child); + return true; + } + } + return false; +} + +static struct clk *fec_enet_get_rmii_master_refclk(void) +{ + struct device_node *np = NULL; + struct clk *clk; + + while ((np = of_find_compatible_node(np, NULL, "fsl,imx6ul-fec"))) { + if (of_get_child_by_name(np, "mdio")) { + of_node_put(np); + continue; + } + clk = of_clk_get_by_name(np, "enet_clk_ref"); + of_node_put(np); + return clk; + } + return NULL; +} + static int fec_enet_mii_init(struct platform_device *pdev) { static struct mii_bus *fec0_mii_bus; @@ -2553,6 +2586,8 @@ static int fec_enet_mii_init(struct platform_device *pdev) u32 mii_speed, holdtime; u32 bus_freq; int addr; + struct clk *rmii_master_refclk = NULL; + bool peer_ref_enabled = false; /* * The i.MX28 dual fec interfaces are not equal. @@ -2662,7 +2697,26 @@ static int fec_enet_mii_init(struct platform_device *pdev) fep->mii_bus->priv = fep; fep->mii_bus->parent = &pdev->dev; + if (node && fec_enet_mdio_has_phy_addr0(node)) { + rmii_master_refclk = fec_enet_get_rmii_master_refclk(); + if (IS_ERR(rmii_master_refclk)) { + err = PTR_ERR(rmii_master_refclk); + goto err_out_free_mdiobus; + } + if (rmii_master_refclk) { + err = clk_prepare_enable(rmii_master_refclk); + if (err) + goto err_out_free_mdiobus; + peer_ref_enabled = true; + usleep_range(100, 200); + } + } + err = of_mdiobus_register(fep->mii_bus, node); + if (peer_ref_enabled) + clk_disable_unprepare(rmii_master_refclk); + if (!IS_ERR_OR_NULL(rmii_master_refclk)) + clk_put(rmii_master_refclk); if (err) goto err_out_free_mdiobus; of_node_put(node); Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel 你只需要查看设备树的变化,就会发现新的 FEC 驱动程序偷工减料,不再有时钟,因此物理寄存器最初无法读取。如果你不打算使用多个物理供应商,那么这样做没问题。兼容行用于指定在没有时钟信号时值错误的物理层寄存器: https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi#L205 在较旧的内核(我们设备树的遗留版本)中,phy 不存在兼容行。此修复允许在读取 PHY 之前打开时钟,以便正确读取寄存器,因此不需要兼容线路,因为旧设备树中没有该线路: https://github.com/nxp-imx/linux-imx/blob/lf-5.4.y/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi#L224 我还没时间测试你们的电路板,因为我正忙着调试我们自己的电路板。我认为这是内核的退步。 Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel 你好, 感谢分享分析和补丁。 您是否已在 NXP EVK 开发板上验证过这一点? 顺祝商祺!
記事全体を表示
imx8mplusでlibcameraをセットアップして使用する方法 libcameraソフトウェアのISPをimx8mplusボード上で実行して、その動作効率を理解する必要があります。公式のlibcameraドキュメントによると、ハードウェアISPとISIの両方でIMX8MPをサポートしています。ISIからすると、ソフトウェアISIだと思います。しかし、この手順を実行するためのドキュメント/ガイドは不明瞭で、非常に分かりにくい。私はlibcameraを使い始めたばかりで、それが具体的にどのように動作するのか、そしてこのソフトウェアISPの部分でどのように役立つのかについて、多くの疑問があります。GStreamerのbayer2rgb要素もテストしましたが、結果には満足していません。 当社のSOMはimx8mplusで、カーネルバージョンは6.6.52-compulab-4.1-g94ac18e782b4-dirtyです。 ありがとうございます。 ヴィシュヌS i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How to setup and use the libcamera on the imx8mplus こんにちは、   libcameraをBSPに実装する方法については、 i.MX Linuxユーザーガイド の 7.3.9章「Libcamera」 を参照してください。   参考までに、GitLab にオープンソースのリポジトリがあります。https://gitlab.com/ideasonboard/nxp/libcamera Re: How to setup and use the libcamera on the imx8mplus libcameraの正しいアップストリーム参照はhttps://gitlab.freedesktop.org/camera/libcameraです。また、ISPを持たないNXPデバイス向けにi.MX8MPやISI、SoftISPに対して非常に良好なサポートをしています。 しかし、6.6カーネルではi.MX8MPでlibcameraをサポートするには、6.6 NXP BSPにない追加のカーネルパッチが必要かもしれません。NXP BSPにこれらのパッチを追加できる https://git.ideasonboard.com/camera/meta-libcamera を始めましたが、これはFRDM-IXM8MPボード上でしかテストされていません。レイヤーにプラットフォームを追加するなら、どなたと協力してみたいと思っています。 マトリックスチャネルでコミュニケーションや質問をしたり、より直接的なlibcameraサポートを求めるメーリングリストに参加することもできます。 https://matrix.to/#/#libcamera:matrix.org https://lists.libcamera.org/listinfo/libcamera-devel
記事全体を表示
i.MX6ULLの6.12カーネルにおけるイーサネットクロックバグ デバイスツリーの例は、6.12のハードコードで、このバグを修正する代わりにイーサネット物理を使いました。NXP 5.15カーネルには存在しませんでした。 最終的にパッチを作成することになったのは、fecモジュールで不具合が生じているPHY検出の柔軟性をカーネルに求めたかったからです。このパッチにより、デバイスツリー内の回避ではなく、ドライバがロードされた際にphyレジスタが読み込まれるようになっています。 On i.MX6UL boards that hang both RMII PHYs on FEC2's MDIO bus, PHY@0 uses the FEC1 (ENET1) RMII reference clock. Kernel 6.12 routes that clock through ENET1_REF_SEL, which may not be active when FEC2 reads PHY@0's ID during of_mdiobus_register(), yielding a bogus ID (0x01080108) and binding the generic PHY driver. Briefly enable FEC1's enet_clk_ref (looked up from DT, not via probe defer) around of_mdiobus_register() so the PHY ID read succeeds without changing FEC probe order and breaking FEC_QUIRK_SINGLE_MDIO. --- drivers/net/ethernet/freescale/fec_main.c | 59 +++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 811a66062..46f37be0c 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -2540,6 +2540,39 @@ static int fec_enet_mii_probe(struct net_device *ndev) return 0; } +static bool fec_enet_mdio_has_phy_addr0(struct device_node *mdio) +{ + struct device_node *child; + u32 reg; + + for_each_available_child_of_node(mdio, child) { + if (of_property_read_u32(child, "reg", ®)) + continue; + if (reg == 0) { + of_node_put(child); + return true; + } + } + return false; +} + +static struct clk *fec_enet_get_rmii_master_refclk(void) +{ + struct device_node *np = NULL; + struct clk *clk; + + while ((np = of_find_compatible_node(np, NULL, "fsl,imx6ul-fec"))) { + if (of_get_child_by_name(np, "mdio")) { + of_node_put(np); + continue; + } + clk = of_clk_get_by_name(np, "enet_clk_ref"); + of_node_put(np); + return clk; + } + return NULL; +} + static int fec_enet_mii_init(struct platform_device *pdev) { static struct mii_bus *fec0_mii_bus; @@ -2553,6 +2586,8 @@ static int fec_enet_mii_init(struct platform_device *pdev) u32 mii_speed, holdtime; u32 bus_freq; int addr; + struct clk *rmii_master_refclk = NULL; + bool peer_ref_enabled = false; /* * The i.MX28 dual fec interfaces are not equal. @@ -2662,7 +2697,26 @@ static int fec_enet_mii_init(struct platform_device *pdev) fep->mii_bus->priv = fep; fep->mii_bus->parent = &pdev->dev; + if (node && fec_enet_mdio_has_phy_addr0(node)) { + rmii_master_refclk = fec_enet_get_rmii_master_refclk(); + if (IS_ERR(rmii_master_refclk)) { + err = PTR_ERR(rmii_master_refclk); + goto err_out_free_mdiobus; + } + if (rmii_master_refclk) { + err = clk_prepare_enable(rmii_master_refclk); + if (err) + goto err_out_free_mdiobus; + peer_ref_enabled = true; + usleep_range(100, 200); + } + } + err = of_mdiobus_register(fep->mii_bus, node); + if (peer_ref_enabled) + clk_disable_unprepare(rmii_master_refclk); + if (!IS_ERR_OR_NULL(rmii_master_refclk)) + clk_put(rmii_master_refclk); if (err) goto err_out_free_mdiobus; of_node_put(node); Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel こんにちは、 分析結果とパッチを共有していただきありがとうございます。 NXP EVKボードでこれを検証できましたか? よろしくお願いいたします。 Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel デバイスツリーの変更を見れば、新しいFECドライバが手抜きし、クロックがなくなり、物理レジスタが最初に読み取れないことがわかります。PHY に複数のベンダーを使用する予定がない場合は、これで問題ありません。互換性のある行は、クロック信号がない場合に不正な値を持つPHYレジスタを指定するために必要です。 https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi#L205 古いカーネル(デバイスツリーの起源)では、phy の互換性ラインは存在しませんでした。この修正により、物理を読み取る前にクロックをオンにしてレジスタを正しく読み取ることが可能になり、互換性のあるラインは不要になります。以前のデバイスツリーにはなかったためです。 https://github.com/nxp-imx/linux-imx/blob/lf-5.4.y/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi#L224 自社の基板の動作確認に追われているため、御社の基板をテストする時間がありませんでした。これはカーネルの退行だと考えています。
記事全体を表示
TEA2016 USB-I2C Programmer Unable to Program TEA2017AAT IC Hello, our customer is using NXP's "TEA2016 USB-I2C Programmer" to program the IC TEA2017AAT on the target board, and the previous burner can be used on Ringo software, including read/write. However, I bought some new programmers, and they look exactly the same as the previous ones, but I can't read/write the ICs of the target board with the same Ringo software. The specific connection is: PC- >burner- >target board. Just replacing the burner, all other conditions remain the same, but the new burner just doesn't work, the old burner works, and I can rule out the issue of the newly purchased burner being damaged, as the 3 new ones all have the same problem. Please advise me where the problem might be and what I need to do. The problem is shown in the attached picture. Thank you very much! Alternator Regulator Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC Your email with 126 is a low priority, please register with your company email to ask questionsticket via the link below: Home Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC What kind of company are you? Or you can leave a company e-mail address. Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC Hello. guoweisun One: Our burners are purchased from NXP's regular distributors, and we bought five of them for our customers. Second: These five burners are not unable to burn on all the customer's target boards, some boards are able to burn. But on the boards that can't be burned, they can be burned with the previous burners, so the customer finds it very strange, where exactly is the difference between the newly purchased ones and the old ones? I looked at the PCBs of both the new and old burners and they are the same version. It may be difficult to connect the photos of the boards, because the factory does not allow photos. But the old burner and the new burner are connected exactly the same way, with the same connecting wires, just replacing the burner gives two different results: the old one works, the new one does not. But the new burner can be recognized by the computer as a serial port, just that the serial port number is different from the one recognized by the old burner, for example, one is COM3 and the other is COM4, and I see that the software RINGO interface can't select the serial port, so it should be able to self-recognize internally. Third: the old burner When connecting to the computer, the customer's computer (one of the test) has three versions of RINGO, I have tested only one of the versions can be burned, this I do not think clear why? Fourth: burn the line with the burner's 6Pin interface, using four wires, two for the I2C interface, two for the power supply and ground, his board has no other power supply, directly with the burner's output power supply, I used a multimeter to measure, actually have 24V or so, so is it right? Of course, it is possible to burn. But when the new burner is connected, the power supply outputs the same 24V, but I can't burn it. Please help me to analyze how exactly I need to solve this problem, our customers are urging us every day because many boards cannot be burned with the new burner. Thank you very much! Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC Where did you purchase the burner? Also can you take a picture of the chip you burned? The whole connection Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC Hello, please allow me to describe the problem again, I have now changed to my company email as requested to re-register a user to ask the question. We are Dongguan Diyou Instrument Co., Ltd, we in DigiKey TECHNOLOGY through the agent to the customer on behalf of the purchase of a number of TER2016 burner: TEA2016DB1514USB-I2C interface board. The product diagram is shown in the attached picture. Now the problem encountered is described as follows: One: Our burners are purchased from NXP's regular distributors, and we bought five of them for our customers. Second: Because the customer also has old burners of the same model. These five new burners are not burnable on all the customer's target boards, some boards are burnable. But on the boards that couldn't be burned, it was possible to do so with the previous burners, so the customer found it very strange to find out what the difference was between the new ones and the old ones. I looked at the PCBs of both the new and old burners and they are the same version. It may be difficult to connect the photos of the boards, because the factory does not allow photos. But the old burner and the new burner are connected exactly the same way, with the same connecting wires, just replacing the burner gives two different results: the old one works, the new one does not. But the new burner can be recognized by the computer as a serial port, just that the serial port number is different from the one recognized by the old burner, for example, one is COM3 and the other is COM4, and I see that the software RINGO interface can't select the serial port, so it should be able to self-recognize internally. Third: the old burner When connecting to the computer, the customer's computer (one of the test) has three versions of RINGO, I have tested only one of the versions can be burned, this I do not think clear why? Fourth: burn the line with the burner's 6Pin interface, using four wires, two for the I2C interface, two for the power supply and ground, his board has no other power supply, directly with the burner's output power supply, I used a multimeter to measure, actually have 24V or so, so is it right? Of course, it is possible to burn. But when the new burner is connected, the power supply outputs the same 24V, but I can't burn it. Please help me to analyze exactly what needs to be done to solve this, the customer is urging us to solve this because many boards cannot be burned with the new burner. extremely grateful Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC Hello, I apologize for the delay in responding to the previous question after half a year, as the customer recently needed to reuse the programmer. Following up on the previous question: 1: The PCB is programmed without powering on. The power supply is directly drawn from the approximately 24V output of the programmer. 2: The new programmer cannot be used for programming, but the old programmer can be used for programming. 3: Actually, the version number and other information on the programmer board are all the same, and we bought it from an authorized distributor. I've attached an attachment with pictures. Please feel free to offer your advice; I'm currently unsure which direction to take to check for the problem.
記事全体を表示
i.MX6ULL Ethernet Clock Bug in 6.12 kernel The device tree example in 6.12 hard codes the Ethernet Phy rather than fixing this bug which did not exist in the NXP 5.15 kernel we were using. We ended up writing a patch because we would like the flexibility of the kernel detecting the PHY which is broken in the fec module.  This patch causes the phy registers to be read when the driver is loaded, rather than circumvention in device tree. On i.MX6UL boards that hang both RMII PHYs on FEC2's MDIO bus, PHY@0 uses the FEC1 (ENET1) RMII reference clock. Kernel 6.12 routes that clock through ENET1_REF_SEL, which may not be active when FEC2 reads PHY@0's ID during of_mdiobus_register(), yielding a bogus ID (0x01080108) and binding the generic PHY driver. Briefly enable FEC1's enet_clk_ref (looked up from DT, not via probe defer) around of_mdiobus_register() so the PHY ID read succeeds without changing FEC probe order and breaking FEC_QUIRK_SINGLE_MDIO. --- drivers/net/ethernet/freescale/fec_main.c | 59 +++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 811a66062..46f37be0c 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -2540,6 +2540,39 @@ static int fec_enet_mii_probe(struct net_device *ndev) return 0; } +static bool fec_enet_mdio_has_phy_addr0(struct device_node *mdio) +{ + struct device_node *child; + u32 reg; + + for_each_available_child_of_node(mdio, child) { + if (of_property_read_u32(child, "reg", ®)) + continue; + if (reg == 0) { + of_node_put(child); + return true; + } + } + return false; +} + +static struct clk *fec_enet_get_rmii_master_refclk(void) +{ + struct device_node *np = NULL; + struct clk *clk; + + while ((np = of_find_compatible_node(np, NULL, "fsl,imx6ul-fec"))) { + if (of_get_child_by_name(np, "mdio")) { + of_node_put(np); + continue; + } + clk = of_clk_get_by_name(np, "enet_clk_ref"); + of_node_put(np); + return clk; + } + return NULL; +} + static int fec_enet_mii_init(struct platform_device *pdev) { static struct mii_bus *fec0_mii_bus; @@ -2553,6 +2586,8 @@ static int fec_enet_mii_init(struct platform_device *pdev) u32 mii_speed, holdtime; u32 bus_freq; int addr; + struct clk *rmii_master_refclk = NULL; + bool peer_ref_enabled = false; /* * The i.MX28 dual fec interfaces are not equal. @@ -2662,7 +2697,26 @@ static int fec_enet_mii_init(struct platform_device *pdev) fep->mii_bus->priv = fep; fep->mii_bus->parent = &pdev->dev; + if (node && fec_enet_mdio_has_phy_addr0(node)) { + rmii_master_refclk = fec_enet_get_rmii_master_refclk(); + if (IS_ERR(rmii_master_refclk)) { + err = PTR_ERR(rmii_master_refclk); + goto err_out_free_mdiobus; + } + if (rmii_master_refclk) { + err = clk_prepare_enable(rmii_master_refclk); + if (err) + goto err_out_free_mdiobus; + peer_ref_enabled = true; + usleep_range(100, 200); + } + } + err = of_mdiobus_register(fep->mii_bus, node); + if (peer_ref_enabled) + clk_disable_unprepare(rmii_master_refclk); + if (!IS_ERR_OR_NULL(rmii_master_refclk)) + clk_put(rmii_master_refclk); if (err) goto err_out_free_mdiobus; of_node_put(node); Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel You only need to look at device tree changes to see that the new fec driver cuts corners and no longer has a clock, so the phy registers do not read initially. This is fine if you do not plan on having multiple vendors for the phy. The compatible line is needed to specify the phy register which has a bad value when there is no clock: https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi#L205 In older kernels (the heritage of our device tree) the compatible line was not present for the phy. This fix allows the clock to be turned on before reading the phy so registers can be read properly, so the compatible line is not required, as it was not there in older device trees: https://github.com/nxp-imx/linux-imx/blob/lf-5.4.y/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi#L224 I have not had time to test your boards as I am busy getting our boards to work. I consider this to be a regression in the kernel. Re: i.MX6ULL Ethernet Clock Bug in 6.12 kernel Hello, Thanks for sharing the analysis and patch. Have you been able to validate this on an NXP EVK board? Best regards.
記事全体を表示
GuiGuiDer2.0.0を使用してターゲットデバイスを構築中にエラーが発生しました。 バージョン2.0.0を使用し、ARMを選択してfrdm_mcx947をベースにしたguiguiderプロジェクトを作成しました。GCCのバージョンは14.4.1です。 既にarm gccツールを設定済みです。 コンパイル中に次のエラーメッセージが発生しました: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. cmdを使ってコンパイラツールを見つけることに成功しました。 C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
記事全体を表示
TPL+33664+33774 I have been working on a BMS project recently and encountered the following issues.   The publicly available MC33664 datasheet downloaded from NXP’s official website does not contain any register descriptions for the MC33664 transceiver. In addition, the official demo code package I downloaded also lacks any routines for accessing and operating MC33664 internal registers. Does TPL3 communication require read/write access to MC33664’s registers?   If register operations are mandatory, could anyone share a complete MC33664 datasheet with full register specifications, as well as a sample demo project that implements MC33664 register read/write logic? Many thanks! Re: TPL+33664+33774 Hi, The datasheet you have downloaded is already the complete, full document. The MC33664 does not contain any internal registers and therefore does not require register read/write operations for TPL communication. The device acts as a transparent TPL physical-layer transceiver. It converts the MCU SPI transmit stream into TPL pulse-encoded signals and converts received TPL traffic back into SPI signals. As a result, communication with devices on the TPL network is performed by sending and receiving TPL frames through the SPI interface. You may be referring to the newer MC33665A gateway device, which does include internal registers, message queues, routing functions and a register-access protocol. The MC33665A full datasheet (available as a Secure file under NDA) therefore contains extensive register descriptions. We have SW device drivers available for both the MC33664 and MC33665 as part of the Gen1 SDK. As for the MC33664, the CDD layer on the MCU handles tasks such as pin timing to execute a wake-up sequence, configuring and managing two independent SPI blocks on the MCU simultaneously, interrupt routing etc. BRs, Tomas
記事全体を表示
An error occurred while building the target device using GuiGuiDer2.0.0. I have now created a guiguider project based on frdm_mcx947, using version 2.0.0, and selected ARM. The GCC version is 14.4.1. I have already configured the arm gcc tool. The following error message occurred during compilation: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe 11:41:00INFObuild-target Started11:41:00INFOTarget Executor initialized11:41:00INFOBuilding target with armgcc toolchain...11:41:00INFOStarting ARM GCC build...11:41:00INFOSearching for ARM GCC toolchain in system PATH...11:41:00INFOExecuting: where arm-none-eabi-gcc11:41:00INFO'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ���11:41:00ERRORARM GCC not found in system PATH: Command failed with code 1: 'where' �����ڲ����ⲿ���Ҳ���ǿ����еij��� ���������ļ��� 11:41:00ERRORARM GCC build error: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERRORBuild failed: ARM GCC toolchain not found. Please install it and add to system PATH.11:41:00ERROROperation failed: ARM GCC toolchain not found. Please install it and add to system PATH. I was successful in finding the compiler tools using cmd: C:\Users\liujianhua>where arm-none-eabi-gcc D:\tools\GCC14\14.2\bin\arm-none-eabi-gcc.exe
記事全体を表示
TEA2016 USB-I2C プログラマーは TEA2017AAT IC をプログラムできません。 皆様、こんにちは。弊社のお客様はNXPの「TEA2016 USB-I2Cプログラマ」を使用して、ターゲットボード上のTEA2017AAT ICをプログラムされています。以前のプログラマはRingoソフトウェアで読み書きを含め問題なく動作していました。しかし、最近、以前のものと全く同じ外観の新しいプログラマをいくつか購入したのですが、同じRingoソフトウェアを使用してもターゲットボードのICの読み書きが全くできません。接続はPC -> プログラマ -> ターゲットボードです。プログラマのみを交換し、それ以外はそのままです。新しいプログラマは動作しませんが、古いものは動作します。新しいプログラマ3台すべてに同じ問題が発生しているため、新しいプログラマが破損している可能性は排除できます。問題の原因と対処方法についてご教示いただけますでしょうか?問題は添付画像をご覧ください。どうぞよろしくお願いいたします。 オルタネーターレギュレーター Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 126 のメールアドレスの優先度は非常に低いです。以下のリンクから、会社のメールアドレスを使用して質問チケットをご登録ください。 家 Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC どのような会社ですか? または、会社のメールアドレスを残すこともできます。 Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC こんにちは、グオウェイスン 1. 当社のプログラマーは NXP の正規代理店から購入しており、お客様用に 5 台購入しました。 2つ目:これら5つのプログラマは、すべてのお客様の対象ボードと互換性があるわけではありません。一部のボードはプログラム可能です。しかし、プログラムできなかったボードでも以前のプログラマはプログラムできたため、お客様を困惑させていました。新旧のプログラマの違いは一体何でしょうか?新旧のプログラマのPCBを調べたところ、同じバージョンでした。工場では写真撮影が禁止されているため、接続したボードの写真を提供することは困難です。ただし、新旧のプログラマの接続方法はまったく同じで、同じケーブルを使用しています。プログラマを交換するだけで、古いプログラマは動作しましたが、新しいプログラマは動作しませんでした。新しいプログラマは、コンピューターによってシリアルポートとして認識されますが、ポート番号が古いものと異なります(たとえば、1つはCOM3、もう1つはCOM4)。RINGOソフトウェアインターフェースではシリアルポートを選択できないため、内部に自己認識機能があるはずです。 3つ目に、古いバーナーをコンピュータに接続すると、お客様のコンピュータ(テスト用コンピュータの1台)にはRINGOの3つのバージョンがインストールされているのですが、テストしたところ、1つのバージョンしか書き込めませんでした。理由はわかりません。 4. プログラミングケーブルはプログラマの6ピンコネクタに接続し、4本のワイヤー(I2C用2本、電源とグランド用2本)が接続されています。ボードには他に電源はなく、プログラマの出力を直接使用しています。マルチメーターで測定したところ、約24Vを示しました。これは正しいでしょうか?はい、プログラミングは可能です。しかし、新しいプログラマを接続すると、出力も24Vになりますが、プログラミングに失敗します。 この問題の解決方法を分析していただければ幸いです。新人プログラマーが多くのボードをプログラムできないため、お客様から毎日問い合わせをいただいています。 どうもありがとうございます! Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC プログラマーはどこで買えますか? プログラムしたチップの写真も撮っていただけますか?接続方法全体も教えていただけますか? Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC こんにちは。問題について再度ご説明させてください。この質問をするために、メールアドレスを会社のメールアドレスに変更し、新しいユーザーアカウントを登録しました。 東莞迪有儀器有限公司でございます。お客様向けに、DigiKey社よりTER2016プログラマ( TEA2016DB1514 USB-I2Cインターフェースボード)を販売代理店経由で複数個購入しました。製品画像を添付しております。現在発生している問題は下記の通りです。 1. 当社のプログラマーは NXP の正規代理店から購入しており、お客様用に 5 台購入しました。 2つ目: お客様は同じ古いプログラマーも使用していました。これらの5台の新しいプログラマーは、お客様のすべてのターゲットボードと互換性があるわけではなく、一部のボードはプログラムできました。しかし、プログラムできなかったボードでは古いプログラマーが動作したため、お客様は新しいプログラマーと古いプログラマーの違いが何なのかと非常に混乱しました。私は新旧のプログラマーのPCBをチェックしましたが、それらは同じバージョンでした。工場では写真撮影が許可されていないため、接続されたボードの写真を撮るのは難しいかもしれません。しかし、新旧のプログラマーの接続方法はまったく同じで、同じ接続ケーブルを使用していました。プログラマーを交換するだけで、古いプログラマーは動作しましたが、新しいプログラマーは動作しませんでした。ただし、新しいプログラマーは、古いプログラマーとはシリアルポート番号が異なっているだけで、コンピューターによってシリアルポートとして認識されました(たとえば、1つはCOM3、もう1つはCOM4)。 RINGO ソフトウェア インターフェイスではシリアル ポートを選択できないことに気付きました。そのため、内部的に自己認識する必要があるようです。 3つ目に、古いバーナーをコンピュータに接続すると、お客様のコンピュータ(テスト用コンピュータの1台)にはRINGOの3つのバージョンがインストールされているのですが、テストしたところ、1つのバージョンしか書き込めませんでした。理由は分かりません。 4. プログラミングケーブルはプログラマの6ピンコネクタに接続し、4本のワイヤー(I2C用2本、電源とグランド用2本)が接続されています。ボードには他に電源はなく、プログラマの出力を直接使用しています。マルチメーターで測定したところ、約24Vを示しました。これは正しいでしょうか?はい、プログラミングは可能です。しかし、新しいプログラマを接続すると、出力も24Vになりますが、プログラミングに失敗します。 この問題の解決方法を分析していただけますか?新しいプログラマーでは多くのボードをプログラムできないため、お客様から解決を強く求められています。 どうもありがとう Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC こんにちは。前回の質問への回答が半年も遅れてしまい、申し訳ありません。お客様が最近、プログラマーを再利用する必要が生じたためです。 前の質問に続いて: 1:基板は電源を入れずにプログラムされます。電源はプログラマの約24V出力から直接供給されます。 2:新しいプログラマーはプログラミングに使用できませんが、古いプログラマーはプログラミングに使用できます。 3:実際、プログラマボードのバージョン番号やその他の情報はすべて同じで、正規代理店から購入しました。 写真を添付しました。何かアドバイスがあればぜひお聞かせください。現在、問題の原因究明のためにどの方向から調べれば良いのか分からずに困っています。
記事全体を表示
TPL+33664+33774 最近、BMSプロジェクトに取り組んでいて、以下の問題に遭遇しました。   NXPの公式ウェブサイトからダウンロードされた公開MC33664データシートには、MC33664トランシーバのレジスタ説明は含まれていません。さらに、私がダウンロードした公式デモコードパッケージには、内部レジスタへのアクセスや操作MC33664ルーチンが一切含まれていません。 TPL3の通信にはMC33664のレジスタへの読み書きアクセスが必要ですか?   レジスタ操作が必須なら、完全なMC33664データシートと、レジスタ読み書きロジックを実装したサンプルデモプロジェクトMC33664誰か共有できますか?どうもありがとうございました! Re: TPL+33664+33774 こんにちは、 ダウンロードされたデータシートは、既に完全な文書です。MC33664には内部レジスタが含まれていないため、TPL通信においてレジスタの読み書き操作は必要ありません。 このデバイスは透過的なTPL物理層トランシーバとして機能します。MCU SPIの送信ストリームをTPLパルス符号化信号に変換し、受信したTPLトラフィックを再びSPI信号に変換します。その結果、TPLネットワーク上のデバイスとの通信は、TPIインターフェースを通じてTPLフレームの送受信によって行われます。 あなたが言及しているのは、内部レジスタ、メッセージキュー、ルーティング機能、レジスタアクセスプロトコルを含む新しいMC33665Aゲートウェイデバイスのことかもしれません。そのため、MC33665Aの完全なデータシート(NDAに基づきセキュアファイルとして入手可能)には、詳細なレジスタの説明が含まれています。 Gen1 SDKの一部として、MC33664とMC33665の両方にSWデバイスドライバーを提供しています。MC33664については、MCUのCDD層が、ウェイクアップシーケンスを実行するピンタイミング、MCU上の2つの独立したSPIブロックを同時に設定・管理、割り込みルーティングなどのタスクを処理します。 BRs、トーマス
記事全体を表示
How to setup and use the libcamera on the imx8mplus We need to perform the libcamera software ISP on the imx8mplus board to understand how efficiently it can work. According to official libcamera documents it have the support for the IMX8MP for both hardware ISP and also with ISI. I think from the ISI it is with software ISI. But the documentation/guide to perform this is unclear and very confusing. I am new to libcamera and a lot of confusions on how it works exactly and how it is going to help us in this software ISP part. we have tested the gstreamer bayer2rgb element also, not satisfied with results.  Our som is imx8mplus & kernel version  6.6.52-compulab-4.1-g94ac18e782b4-dirty. Thanks and regards  Vishnu S i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How to setup and use the libcamera on the imx8mplus Hello,   For the implementation of libcamera in our BSP you can refer to chapter 7.3.9 Libcamera in the i.MX Linux User's Guide    Also as reference there is an open source on GitLab  https://gitlab.com/ideasonboard/nxp/libcamera  Re: How to setup and use the libcamera on the imx8mplus The correct upstream reference for libcamera is https://gitlab.freedesktop.org/camera/libcamera and has very good support for i.MX8MP or the ISI and SoftISP for the NXP devices without an ISP. Howveer, on a 6.6 kernel, for libcamera support on i.MX8MP you might need benefit from additional kernel patches which are not in the 6.6 NXP BSP.  We've started https://git.ideasonboard.com/camera/meta-libcamera which can add these patches to the NXP BSP - but it's only been tested on the FRDM-IXM8MP board. We'd be happy to work with anyone to add more platforms to the layer. You can communicate and ask questions on the matrix channel or join the mailing list for more direct libcamera support: https://matrix.to/#/#libcamera:matrix.org https://lists.libcamera.org/listinfo/libcamera-devel
記事全体を表示
TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC         大家好,我司的客户使用NXP的“TEA2016 USB-I2C 编程器” 对目标板的IC TEA2017AAT进行编程,之前的烧录器可以在Ringo软件上进行使用,包括读写。但是新买了几台 烧录器,看起来和之前的烧录器一模一样,但是就是无法在同样的Ringo软件上对目标板的IC进行读写。具体的连接为:PC->烧录器->目标板子。只是更换烧录器,其他条件不变,但是新的烧录器就是不能用,旧的烧录器可以用,可以排除新买烧录器损毁的问题,因为新买的3台都一样的问题。请教各位,可能是哪里的问题,我需要怎样做。问题如附图所示。非常感谢! Alternator Regulator Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 您用126的邮箱是优先级很低的,请用公司邮箱注册提问ticket通过下面的链接: Home Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 你们是什么公司? 或者你留个公司的邮箱 Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 您好,guoweisun             一:我们的烧录器是向NXP的正规代理商进行购买的,我们给客户买了五个。            二:这五个烧录器并不是在所有的客户的目标板子上都不能烧录,有的板子是可以烧录的。但是在不能烧录的板子上,用之前的烧录器是可以烧录的,所以客户觉得非常奇怪,到底新买的和旧的之间的差异在哪里?我看了新的和旧的烧录器的PCB都是同一个版本的。连接板子的照片可能很难,因为厂里面不允许拍照。但是旧的烧录器和新的烧录器的连接方式一模一样,用的是同样的连接线,只是替换掉烧录器,就出现两种不同结果:旧的可以,新的就不行。但是新的烧录器是可以被电脑识别为一个串口的,只是串口号和旧的烧录器识别的串口号不一样,比如一个是COM3,一个是COM4,我看软件RINGO界面也不能选择串口,所以应该内部可以自识别。        三:旧的烧录器 在连接电脑的时候,客户的电脑(其中进行测试的一台)有三个版本的RINGO,我测试过也是只有其中一个版本可以进行烧录,这个我也想不清楚为什么?        四:烧录的线用烧录器的6Pin的接口,用了4根线,2根为I2C接口,两根为电源和地,他的板子没有其他电源供电,直接用烧录器的输出电源,我用万用表量过,居然有24V左右,这样是对的吗?当然,是可以烧录的。但是新的烧录器接上后,电源一样是输出24V,但是无法烧录。        请帮我分析一下到底需要如何解决,客户天天催我们,因为新的烧录器很多板子都不能烧录。 非常感谢! Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 烧录器哪里购买的? 另外您烧写的芯片能拍个照片吗?整个的连接方式 Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 您好,请允许我再次描述问题,我现在已经按照要求更换为公司邮箱来重新注册一个用户进行提问。         我们是东莞帝佑仪器有限公司,我们在DigiKey得捷上通过代理商给客户代购了多个TER2016的烧录器:TEA2016DB1514 USB-I2C接口板。产品图如附图所示。现在遇到的问题描述如下: 一:我们的烧录器是向NXP的正规代理商进行购买的,我们给客户买了五个。 二:因为客户也有同款的旧的烧录器。这五个新的烧录器并不是在所有的客户的目标板子上都不能烧录,有的板子是可以烧录的。但是在不能烧录的板子上,用之前的烧录器是可以烧录的,所以客户觉得非常奇怪,到底新买的和旧的之间的差异在哪里?我看了新的和旧的烧录器的PCB都是同一个版本的。连接板子的照片可能很难,因为厂里面不允许拍照。但是旧的烧录器和新的烧录器的连接方式一模一样,用的是同样的连接线,只是替换掉烧录器,就出现两种不同结果:旧的可以,新的就不行。但是新的烧录器是可以被电脑识别为一个串口的,只是串口号和旧的烧录器识别的串口号不一样,比如一个是COM3,一个是COM4,我看软件RINGO界面也不能选择串口,所以应该内部可以自识别。 三:旧的烧录器 在连接电脑的时候,客户的电脑(其中进行测试的一台)有三个版本的RINGO,我测试过也是只有其中一个版本可以进行烧录,这个我也想不清楚为什么? 四:烧录的线用烧录器的6Pin的接口,用了4根线,2根为I2C接口,两根为电源和地,他的板子没有其他电源供电,直接用烧录器的输出电源,我用万用表量过,居然有24V左右,这样是对的吗?当然,是可以烧录的。但是新的烧录器接上后,电源一样是输出24V,但是无法烧录。 请帮我分析一下到底需要如何解决,客户催促我们解决,因为新的烧录器很多板子都不能烧录.        非常感谢 Re: TEA2016 USB-I2C 编程器 无法编程TEA2017AAT IC 您好,抱歉时隔半年才来继续之前的问题,因为最近客户需要重新使用烧录器。 接之前的问题: 1:PCB板上进行烧录,PCB不上电,直接取烧录器输出的24V左右的电源来供电。 2:新的烧录器不能进行烧录,但是旧的烧录器可以进行烧录。 3:其实烧录器的板子上版本号等都一样,而且我们是从正规代理商买入。 我附上附件,里面有图片,请各位不吝指教,现在不知往那个方向检查问题。
記事全体を表示
需要协助解决NBP8FD4ST1压力传感器SPI通信问题 您好, 我正在使用NBP8FD4ST1压力传感器和S32K146微控制器。传感器的CS_B/WAKE-UP引脚连接到微控制器的 GPIO 引脚。 逻辑分析仪的信号映射关系如下: D0 → SCLK D1 → CS_B D3 → 就绪 D5 → 中同轴 D7 → MOSI 在通信序列中,当我将CS_B引脚拉低以请求 SPI 通信时, READY引脚如预期般置位。READY 变为高电平后,我发送SPIOPS 寄存器 READ命令 (0x00E1) 。但是,该传感器在 MISO 上始终返回0x0000 。因此,固件验证失败,随后 CS_B 引脚被拉高以终止事务。 请问您能否帮我确认一下我的 SPI 通信序列是否正确,或者我是否遗漏了任何必要的步骤,例如数据手册中描述的唤醒序列、虚拟传输或 SPIOPS 处理? 我还附上了逻辑分析仪的截图供您参考。 感谢您提前给予的支持。 此致, 普拉蒂尤莎。 压力传感器 Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor 你好, Pratyusha, 请注意,NXP 的 MEMS 传感器业务(包括 NBP8FD4ST1 等压力传感器)已转让给意法半导体。自 2026 年 2 月 2 日起,这些传感器的技术支持、产品文档和开发活动将由 STM 负责。因此,很遗憾,我们无法再为 NBP8FD4ST1 提供技术支持。 我建议您直接通过STM的支持渠道或社区论坛联系他们,那里的传感器专家可以帮助您解决实施和通信方面的问题。 BRs,托马斯
記事全体を表示