FRDM-IMX93 — LPSPI3/EXPI (P11) SPI 引脚无法与任何外部设备产生有效的 SPI 通信； 主题：FRDM-IMX93 — LPSPI3/EXPI (P11) SPI 引脚无法与任何外部设备产生有效的 SPI 通信；怀疑与板载三频模块 (MAYA-W27x) 冲突 NXP团队您好， 我正在尝试启动一个外部SPI设备（Waveshare 2通道CAN HAT（ https://www.waveshare.com/wiki/2-CH_CAN_HAT ）），在 FRDM-IMX93 板的 EXPI 40 针接头 (P11) 上使用 LPSPI3 (GPIO_IO08–11，与 RPi 兼容的引脚位置匹配) 连接双 MCP2515)。我已经确认 HAT 本身功能齐全（在具有标准 dtoverlay=mcp2515 配置的真正 Raspberry Pi 上进行了测试并运行正常）。 板/电路板支持包。 FRDM-IMX93，型号 NXP FRDM-IMX93 NXP i.MX 发布发行版 6.18-whinlatter，内核版本 6.18.2-1.0.0-gf49f45233f7b 我已配置好（所有配置均已在设备树级别验证正确）： Overlay 在 &lpspi3 下添加了 mcp2515@0/mcp2515@1，其中 cs-gpios = <&gpio2 8 1>, <&gpio2 7 1>; (GPIO_IO08/GPIO_IO07)，与我在 NXP 自己的上游补丁中找到的基于 GPIO 的 CS 模式相匹配，该补丁用于类似的 FRDM-IMX93 SPI3 外设（pixpaper 显示覆盖层）。 将 &pinctrl_lpspi3 扩展为将 GPIO_IO07 (CS1) 复用为 GPIO，因为它之前在 /sys/kernel/debug/pinctrl/ 中是 (MUX UNCLAIMED)。 禁用了与 CS0 冲突的已存在的 spidev0 节点。 启用 reg_vexp_3v3/reg_vexp_5v（稳压器始终开启）——这些默认是禁用的，如果没有这些，EXPI 标头将无法供电。 已确认 /dev/spidev2.0 已创建，引脚复用显示所有 4 个 SPI 引脚上的功能分配 (lpspi3grp) 正确。 症状： mcp251x 驱动程序始终失败：spi2.0：无法初始化MCP2515。接线错误？（错误代码=19）和 spi2.1：RESET后 MCP251x 未进入配置模式（错误代码=110）——以上所有设备树变体均完全不变。 使用 spidev_test（兼容 lwn、bk4）对 /dev/spidev2.0 进行原始 SPI 级测试：无论 MOSI/MISO 是物理短路（环回）、开路还是用分流器桥接，RX 缓冲区都会返回逐字节相同的数据。这表明 P11 接头引脚 19/21/23/24 处的 SPI3 信号没有反映在控制器的实际总线活动中——也就是说，这些信号可能根本没有到达接头，或者有其他东西在干扰。 疑似根本原因： 根据 UM12181（FRDM-IMX93 板用户手册，第 2.11 节“三射频模块接口”），SPI3 信号（CLK、MOSI、MISO、CS0 — 在 GPIO_IO08-11 上复用）通过双向 1.8V 电平转换器 (U729)（电阻选择）在板载 MAYA-W27x 三射频模块和 M.2 连接器之间共享。该文档没有说明当 SPI3 备用功能由 SoC 端驱动时，EXPI 接头 (P11) 是否/如何与此共享路径电气隔离。 问题： P11 的 GPIO_IO08-11 引脚在电气上是否独立于 U729 转换器/三路无线电路径？或者，在 P11 上使用 SPI3 是否需要任何额外的配置（例如，禁用三路无线电模块、GPIO 扩展位或电阻器改造）才能正确地将信号路由/隔离到接头？ 是否有经过验证的参考设备树（类似于 EVK 的 imx93-11x11-evk-lpspi.dts），专门用于在 FRDM-IMX93 板上外部使用 LPSPI3？ 能否提供 SPI3/U729 信号路径的原理图片段，以确认 P11 连接拓扑结构？ 提前感谢您的帮助。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 如果有什么遗漏，我可以补充。 root@imx93-11x11-lpddr4x-frdm:/sys/firmware/devicetree/base# ls '#address-cells' clock-osc-24m 固件 mcp2515_clock pmu regulator-hmisc-vddio regulator-vexp-3v3 soc@0 usbphynop2 '#size-cells' clock-osc-32k imx93-lpm memory psci regulator-usdhc2 regulator-vexp-5v sound-mqs usdhc3_pwrseq __symbols__兼容中断控制器@48000000 型号 regulator-adc-vref regulator-usdhc3 remoteproc-cm33 sw-keys 别名 cpus 中断父级 mqs1 稳压器-avdd 稳压器-vdd-12v 保留内存 热区 选定的显示子系统 ldb-display-controller mqs2 regulator-can2-stby regulator-vdd-5p0v secure-enclave timer clock-ext1 ethosu ldb-phy 名称 regulator-dvdd regulator-vddo 序列号 usbphynop1 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 是的，我在p11接头上测得3.3V和5V电压。 为什么我的电脑会出现错误？ imx93-11x11-lpddr4x-frdm 登录：root root@imx93-11x11-lpddr4x-frdm:~# dmesg | grep -iE 'mcp251|lpspi3' [ 8.989639] mcp251x：模块布局没有符号版本 [ 10.032864] mcp251x spi2.1：MCP251x RESET 后未进入配置模式 [ 10.033021] mcp251x spi2.1：探测失败，错误代码=110 [ 10.033034] mcp251x spi2.1：使用驱动程序 mcp251x 进行探测失败，错误代码为 -110 [ 10.074097] mcp251x spi2.0：无法初始化 MCP2515。接线错误？ [ 10.074256] mcp251x spi2.0：探测失败，错误代码=19 root@imx93-11x11-lpddr4x-frdm:~# ip link show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 链接/回环 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc mq 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 90:a9:f7:80:42:26 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 90:a9:f7:80:42:27 brd ff:ff:ff:ff:ff:ff 4: mlan0: mtu 1500 qdisc mq 状态 UP 模式 DORMANT 组 default qlen 1000 链接/以太 80:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff 5: uap0: <广播,组播> mtu 1500 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链路/以太网 82:a1:97:50:4f:0d brd ff:ff:ff:ff:ff:ff 6: wfd0: <广播,组播> mtu 1500 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 82:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff 7: can0: mtu 16 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 10 链接/罐 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi FRDM-IMX93：LPSPI3（P11 EXPI 接头）SCK 引脚无信号输出 问题 我正在尝试使用 P11 EXPI 接头上的 LPSPI3 (GPIO_IO08-11, spi@42550000) 操作外部 SPI 设备 (2× MCP2515 CAN)。驱动程序处于活动状态，外设似乎正在“内部”运行，但没有信号输出到物理 SCK 引脚 (GPIO_IO11)。 证据 覆盖层应用无误；spi2.0/spi2.1 已在 SPI 内核中注册。 电源、引脚控制、引脚控制断言-GPIOS、CS-GPIOS 和时钟源——全部正确，并且已经过验证。 CS0（同一组，GPIO 交替功能，模式=0）工作完美——用万用表和逻辑分析仪都能看到脉冲。 在逻辑分析仪上，SCK（模式=1，原生 LPSPI3_SCK）完全平坦/0V——无论 HAT 是否连接，对连续触发回路都没有影响。 然而，LPSPI3 的 IRQ（GIC 97）实际上是在 /proc/interrupts 中触发的（一次传输尝试产生了 220 次中断）——外设的内部逻辑（状态/IER 寄存器）处于活动状态。 使用 /dev/mem 读取 LPSPI3 基地址 (0x42550000) 时返回“总线错误”——但是运行在同一总线上的 flexcan2 (0x425b0000) 也返回相同的错误，这意味着这是 /dev/mem 的一般限制，而不是 LPSPI3 特有的限制（已通过控制组排除）。 DMA 理论经过测试并被排除：当使用无效句柄覆盖 dmas 时，驱动程序回退到 PIO 并显示消息“dma 设置错误 -19，请使用 pio”，但 SCK 信号仍然没有出现。 `clk_ignore_unused` 启动参数也没有任何作用。 结束语 LPSPI3 外设的内部逻辑正在工作（产生中断），但 SCK 信号始终无法到达外部引脚 (GPIO_IO11)——尽管同一引脚控制组中的 CS0（GPIO 模式）输出正确，但 SCK（LPSPI3 原生替代功能）却无法输出。这似乎指向与焊盘驱动器/硅相关的配置细节，或者指向 NXP 应该了解的配置细节，而这些细节无法通过设备树或软件来解释。 问题 在 FRDM-IMX93 上，是否需要在设备树之外通过 P11 为 LPSPI3_SCK（GPIO_IO11，本机替代功能）添加额外的硬件/固件使能步骤？ 已知有一个例子表明，LPSPI3 可以使用 i.MX93 EVK 上的相同引脚（community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ）——可能FRDM是否存在特殊差异？ Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 根据日志，我怀疑您尝试通过 spidev_test 访问 SPI 设备，但该设备由 MCP 驱动程序处理。 我需要知道的是您使用的完整设备树（.dts）文件，例如： imx93-11x11-frdm.dts 另外，如果您对它进行了修改，请告诉我您的修改之处。 另外，我也会尝试弄一个 mcp2515 CAN 模块，以便我这边进行集成测试。 顺祝商祺！ 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 你好@irfanktm 希望你一切都好。 实际上，i.MX93 FRDM PAD 与 P11 GPIO_IO08-IO11 引脚之间存在直接连接： Manuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.png曼努埃尔_萨拉斯_0-1789421014211.png 能否请您提供一下重现问题的步骤？ 顺祝商祺！ 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 你好@irfanktm 我刚才做了一些测试： Manuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.png曼努埃尔_萨拉斯_0-1789495251012.png 我的 i.MX93 FRDM 上的 SPI 工作正常。 Manuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.png曼努埃尔_萨拉斯_1-1789495295645.png 我的环境和你一样。 最后一个问题。 你的i.MX93 FRDM板的3V3和5V引脚有电压吗？ 如果不行，请点击以下链接启用董事会监管功能： https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Enable-3-3-V-and-5-V-Regulators-for-Expansion-Header-on-i-MX9/ta-p/2299415 顺祝商祺！ 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 请您提供完整的设备树。 或者只是与 lpspi3 节点和引脚复用相关的。 顺祝商祺！ 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 不，imx93-11x11-frdm.dts 文件是原始文件；我编辑了 mcp2515-can-hat.dtbo 覆盖文件， https://www.waveshare.com/wiki/2-CH_CAN_HAT我只将 INT_1 从默认的 GPIO_25 改为 GPIO_24（物理引脚 18）。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技术支持请求 MCP2515（Microchip）SPI 通信故障，i.MX93（NXP）SPI2/LPSPI3 1. 总结 两个 MCP2515 CAN 控制器（Waveshare 2-CH CAN HAT、MCP2515-I/SO、16 MHz 晶振）通过 LPSPI3（SPI2、CS0/CS1）连接到 i.MX93-11X11-LPDDR4X-FRDM 板，上电或 SPI/硬件 RESET 后始终无法进入配置模式。所有寄存器读取都返回固定不变的值，而不是预期的 CANSTAT = 0x80。内核 mcp251x 驱动程序持续报告探测失败（err=-110“RESET 后未进入配置模式”，或 err=-19“接线错误？”）。 2. 环境 SoM/板：i.MX93-11X11-LPDDR4X-FRDM 内核：6.18.2-1.0.0-gf49f45233f7b（NXP 下游），CONFIG_SPI_FSL_LPSPI=y（内置），ERR051608 预分频修复程序已存在 SPI 总线：LPSPI3 (spi@42550000)，2 个片选信号，自定义设备树覆盖（16 MHz 固定时钟，IRQ GPIO3-23 / GPIO3-24） CAN 模块：Waveshare 2 通道 CAN HAT，MCP2515-I/SO，标记“E3 2335BK5”（Microchip 原装标记格式） 驱动程序：mcp251x（主线），已使用内核驱动程序和基于 spidev 的自定义测试工具进行测试。 3. 已执行的故障排除 已更正设备树覆盖目标（&spi1/&lpspi3 与错误的 &spi2 标签相比）——覆盖现在已正确应用，mcp2515 子节点已存在于实时设备树中 已根据运行中的设备树验证 LPSPI3 pinctrl、cs-gpios 和 interrupt-parent/GPIO 映射——全部正确 使用逻辑分析仪验证了主端SPI信号的完整性：在多次捕获中，i.MX93均能正确且一致地生成MOSI、SCK和CS信号。 已确认两个 CAN 模块的 VDD = 3.3V 和空闲 MISO = 3.3V（无对地短路） 已确认两个模块的 RESET 引脚（引脚 17，SOIC-18）均为 3.3V（未激活） 测试了 SPI 模式 0,0 和模式 1,1 (CPOL/CPHA)，时钟频率为 100 kHz 至 8 MHz — 行为未发生变化 在 CS0/CS1 上添加了 10k 上拉电阻，以解决两个并联 MCP2515 器件之间的 MISO 总线争用问题——这稳定了（但并未纠正）回读数据。 自定义 spidev 测试工具：RESET 指令 + 复位后立即/连续轮询 CANSTAT（1 毫秒间隔，300 毫秒窗口）— CANSTAT 立即稳定到一个固定值，且永远不会达到 0x80。 强制写入 CANCTRL (0x80) 后执行读取操作——读取操作不受写入操作的影响，表明 SPI 事务未被 CAN 控制器逻辑处理。 4. 关键观察 CS0 设备：CANSTAT/CANCTRL/所有寄存器始终读取回 0x00（在数十次复位+读取周期中 100% 可重复，与寄存器地址、SPI 模式或写入值无关）。 CS1 设备：CANSTAT/CANCTRL/所有寄存器始终读取回 0xFF（100% 可重复，MISO 在事务处理期间从不翻转）。 两个设备均显示来自主控端的干净、时序正确的 MOSI/SCK/CS，但无论指令、地址或 CS 拉取配置如何，都返回一个固定值——这种模式无法用主机端的 SPI 模式/时序/接线来解释，并且与 MCP2515 CAN 内核永远不会离开其复位后/振荡器不稳定状态一致。 5. 请求 鉴于逻辑分析仪已验证主机端 SPI 信号传输正确，且设备树/内核驱动程序配置也已确认正确，我们希望获得以下方面的指导： 此故障特征（固定寄存器回读，CANSTAT 始终不等于 0x80）是否与已知的 MCP2515 晶振（晶体振荡器）启动问题一致，以及 OSC1/OSC2 的推荐示波器/验证程序。 MCP2515 和 i.MX93 LPSPI 之间是否存在已知的兼容性问题（除已解决的 ERR051608 之外） 如果怀疑MCP2515模块存在硬件缺陷，建议采取以下后续诊断步骤或RMA流程。 如果您需要提供额外的逻辑分析仪捕获文件、设备树文件或内核日志，请告知我们。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi MCP2515 / i.MX93 LPSPI3 — 根本原因更新 这是我们之前报告的后续报道。一项新的隔离测试现在完全指向了 i.MX93 LPSPI3 SPI 控制器/驱动程序，而不是 MCP2515 模块。 已执行测试： 使用用户空间 spidev 工具，我们反复对 LPSPI3（500 kHz，模式 0）发出 RESET + CANSTAT 读取周期，同时仅改变 MISO 线的物理状态： MISO 连接到真正的 MCP2515 芯片：不稳定，很少达到预期的 0x80。 MISO 物理断开（浮空，未连接芯片）：仍会出现结构化的重复字节模式（0x00 / 0xFF / 0xFB），周期约为 10-11 毫秒。 MISO 通过 10kΩ 电阻连接到 GND：仍然出现相同的重复模式，基本没有改变。 MISO 直接短接到 GND (~0Ω)：图案完全消失——读取结果变为平坦的恒定值 0x00。 主要发现： 完全相同的字节序列，毫秒级的时序完全相同，在不同的运行（不同的进程 ID、不同的时间）和不同的物理 MISO 条件（断开连接、10kΩ 下拉电阻、连接到真实芯片）中反复出现。SPI ioctl() 调用本身每次都会返回成功（无错误）——这不是被掩盖的传输失败；每次调用都会将真实数据记录到时钟中。 解释： 真正浮空或电阻负载的输入引脚不应该在不同的进程调用中精确到毫秒地重现与主机无关的相同位模式。这种确定性表明，读取回来的字节值并不代表实际的 MCP2515 SO/MISO 线，而是来自 LPSPI3 外设或其 Linux 驱动程序的固定、可重复的内部状态（例如，过时的 RX FIFO 内容，或者无论输入引脚的实际逻辑电平如何，读取的固定模式）——只有硬短路到 GND 才能覆盖它。 向 NXP 提出问题：在某些情况下，LPSPI3（或其 Linux 驱动程序 spi-fsl-lpspi）是否会返回固定/过时的 RX FIFO 内容，而不是引脚的实际采样值？是否存在已知的错误或驱动程序行为可以解释这种确定性的、与线路无关的读取模式？ Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技术支持请求 — i.MX93 LPSPI3 上的 MCP2515 多个 MCP2515 CAN 控制器（测试了 3 个单元，2 个不同的制造商/板，8/16 MHz 晶振）通过 LPSPI3 (SPI2) 连接到 i.MX93-11X11-LPDDR4X-FRDM 板，RESET后间歇性地无法进入配置模式（CANSTAT 应读取 0x80）。 环境：内核 6.18.2（NXP 下游），CONFIG_SPI_FSL_LPSPI 内置，ERR051608 预分频修复已存在。设备树/引脚控制已验证正确（LPSPI3 SIN/SOUT/SCK 已正确复用，CS 通过 cs-gpios）。逻辑分析仪捕获结果证实主机能够正确且一致地生成 MOSI/SCK/CS。 关键观察结果： 对于新打开的 spidev 句柄，第一次 RESET + CANSTAT 读取操作大约有 50-60% 的概率成功（~0x80），且计时稳定在 2-6 毫秒左右。 如果对同一个仍然打开的 SPI 文件描述符发出额外的 RESET+读取周期，则之后会持续失败，并稳定为可重复的 ~10-11 毫秒周期性固定值 (0x00 / 0xFF / 0xFB) 模式，永远不会再次达到 0x80。 所有 3 个物理 MCP2515 单元和 2 种不同的电路板设计都出现了相同的故障特征，排除了单个芯片/模块存在缺陷的可能性。 添加传输间延迟（delay_usecs）、虚拟“刷新”SPI 传输，并将周期之间的间隔增加到 100 毫秒，结果都没有改变（一旦模式开始，成功率就为 0/10）。 VDD、GND、RESET 引脚和空闲 MISO 电平均已确认正常（3.3 V）。 主线 mcp251x 内核驱动程序自身的 probe() 也显示出同样的不稳定性：连续 5 次绑定尝试（取消绑定/清除 driver_override/绑定）全部失败，错误信息在 err=-19（“接线错误？”）和 err=-110（“重置后未进入配置模式”）之间交替出现，且模式具有规律性，并非随机性。 这种模式（打开后第一次传输正常，然后在同一会话中的后续传输中出现固定的可重复故障特征——内核驱动程序自己的探测也重现了该故障）表明，连续的 LPSPI3 传输/CS 周期之间没有完全清除状态，而不是 MCP2515 单元本身存在缺陷。 向 NXP 提出的问题：这是否与已知的 LPSPI3 (i.MX93) 行为一致——例如：在同一 SPI 文件描述符上连续进行数据传输时，FIFO/CS 状态无法干净地重置——是否有推荐的驱动程序级解决方法（例如，使用 FIFO/CS 进行数据交换）？除了 ERR051608 之外，还需要延迟、FIFO 刷新或 CS 处理吗？ Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 你好，亲爱的@irfanktm 请查看我针对您的情况发布的帖子： https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/2-CH-CAN-HAT-with-FRDM-IMX93/ta-p/2415467 本文解释了如何在我们的 电路板支持包 和 i.MX93 FRDM 中使用2 通道 CAN HAT 。 顺祝商祺！ 萨拉斯。

Ara2 Windows ファクトリーテスト/ランタイムパッケージが利用できません 私はWindowsでAra2 PCIeアクセラレータを使っています。ハードウェアは正しく検出され、PCIe/DMAの初期化は成功し、AraProxyServiceが実行されています。しかし、デバイスの初期化は、以下のエラーで失敗します。 デバイスのファームウェアバージョンがサポートされていません：0。ファームウェアをアップデートしてください。 現在の環境： ファームウェア: 14.34.0.0 プロキシ: 1.1.0.0 SysAPI: 1.1.56.0 Windows ARA2ユーザーガイドにはfactory-test-package-windows.zipファイルとQwen Windowsデモパッケージが記載されていますが、記事ではそれらの添付ファイルは入手できません。 NXPのどなたか、現在のWindows工場出荷時テストパッケージとAra2対応のランタイム/ファームウェアパッケージへのアクセスを提供していただけませんか? 現在、これによりアクティブなWindows展開中のアクセラレータの検証がブロックされています。

i.MX8QXP – 防止在 Yocto Scarthgap 系统上使用 A/B 分区时，USB 刷写中断后无法正常启动 您好，NXP团队： 已安装的 UUU 可执行文件报告： libuuu_1.5.21-0-g1f42172 我们使用： sudo uuu -b emmc_all ~/Downloads/flash.bin *.wic 内置的 emmc_all 脚本使用以下命令写入完整的 .wic 镜像： FB：flash -raw2sparse 所有_image 然后写入引导加载程序，配置 eMMC 引导选择，最后显示 FB: done。 该脚本不包含显式的持久性闪存进行中完成元数据处理或回读哈希验证步骤。 如果在 .wic 期间闪光灯闪烁中断写入后，集群即可启动并显示更新后的 HMI。我们怀疑现有的可用引导加载程序和足够的已写入启动、根文件系统内容允许这样做，但所选插槽及其内容的完整性尚未得到确认。 请问如何添加一个断电容错完成检查，在工厂刷机中断后阻止从两个插槽正常启动，同时保留 USB 恢复功能？元数据必须独立于完整的 .wic 文件保持有效。写入和引导加载程序更新。 Re: i.MX8QXP – Prevent normal boot after interrupted USB flashing on Yocto Scarthgap with A/B partit 你好， 虽然没有官方的解决方案，但您可以自定义 uuu 脚本，内置的 emmc_all 流程只是一个基于 Fastboot 和 U-Boot 命令的 UUU 脚本，它可以被修改或替换为自定义的 uuu.auto 文件。U-Boot 命令也可以通过 FB:ucmd 执行。这意味着您应该添加自定义步骤，例如在编程前设置“闪存正在进行中”标志，并在验证成功后才清除该标志。 U-Boot 启动次数/启动限制 U-Boot 库包含对以下功能的支持： 配置启动次数限制 启动计数 启动限制 altbootcmd 配置启动计数_FS 当启动次数超过启动限制时，U-Boot 会执行 altbootcmd 而不是正常的 bootcmd。此机制可用于将系统重定向到恢复模式，例如 Fastboot 模式。 启动次数限制 — Das U-Boot 未知版本文档

CLEV6630B評価ボード（OM26630FDK） 評価ボード(OM26630FDK)のPDfファイルCLEV6630B入手しましたが、カスタム設計で使うために同じAltiumのPCBファイルを入手できますか? Re: CLEV6630B eval board(OM26630FDK) こんにちは、 @R_Tony さん。 あなたの調子が良いといいのですが。 申し訳ありませんが、このデバイスで利用可能な設計ファイルはPDF形式の CLRC6630B回路図とレイアウトのみです。 ご迷惑をおかけして申し訳ございません。 よろしくお願いいたします。 エドゥアルド。

CLEV6630B 评估板（OM26630FDK） 我获得了 CLEV6630B 评估板 (OM26630FDK) 的 PDF 文件，请问我能否获得相同板型的 Altium PCB 文件，用于我们的定制设计？ Re: CLEV6630B eval board(OM26630FDK) 你好@R_Tony ， 希望你一切都好。 非常抱歉，该设备的唯一可用设计文件是CLRC6630B 原理图和布局图，以 PDF 格式提供。 给您带来的不便，敬请谅解。 问候， 爱德华多。

PTN3460 サポート チームの皆さん、こんにちは。 PTN3460Iのデータシートには「ファームウェアおよびEDIDアップデートのためのI2Cバスユーティリティおよびプログラミングガイド」という文書が記載されています。I2CバスユーティリティやEDID更新ツールに関するドキュメントは見つかりません。 さらに、DP Auxを使ってPTN3460Iの内部フラッシュをフラッシュできますか?もしそうなら、同じ用途のユーティリティはありますか?PTN3460(Flash-over-AUX)ユーティリティはファームウェアアップデート専用ですか?それともEDIDアップデート用ですか? Re: PTN3460 Support こんにちは、 PTN3460Iデータシートで「ファームウェアおよびEDID更新のためのI2Cバスユーティリティおよびプログラミングガイド」として参照されている文書は、AN11606 – PTN3460I PTN3460I向けプログラミングガイド(向け)および AN11128 – PTN3460 プログラミングガイド(商用PTN3460向け)に対応しています。両者とも NXP.com で一般公開されています: AN11606 – PTN3460Iプログラミングガイド(Rev. 1.4) — I²Cバス構成テーブル構造、EDIDプログラミング(最大7種類のEDIDデータ構造)、すべてのレジスタ定義、およびI²Cを介してPTN3460I内部フラッシュにEDIDおよび設定データを書き込む手順を段階的に扱っています。 AN11128 – PTN3460 プログラミング ガイド (Rev. 1.8) — 商用版 PTN3460BS に対応するドキュメント。 DP AUXインターフェースおよびFlash-over-AUX(FoA)ユーティリティに関するご質問について: DP AUXによる内部フラッシュのフラッシュ:はい、PTN3460I DP AUXチャネル経由で内部フラッシュのプログラミングをサポートしています。レジスタはI²CバスインターフェースまたはDP AUXのいずれかからアクセスできます。 Flash-over-AUX (FoA) ユーティリティスコープ: PTN3460/PTN3460I には、2 つの独立した FoA ツールがあります。 FoAファームウェアアップサ(PTN3460IBS F2用の別のツール)— DP AUXチャネルを通じたファームウェアのバージョンアップグレード専用。 FoA EDID Updater — DP AUXチャネルを経由したEDID更新専用のユーティリティです。 下記に添付しておりますのでご確認ください。 BRs、トーマス

i.MX93 电源时序 我正在设计一款基于 i.MX93 及其推荐的 PMIC (PCA9451) 的低功耗 PCB。 AN13917 功耗测量文档表明，在其最低功耗模式下（第 6.7.8 节），SoC+DRAM 的功耗应为 ~174mW。然而，文档中目前的测量数据是在电源管理集成电路（PMIC）之后采集的，因此并未包含任何效率损失。 在计算实际预期功耗时，vdd_ana_0p8 电源轨的能耗非常高。该电源轨上的 16.5mA 电流消耗会导致 PMIC 低压差线性稳压器 (LDO) 耗散 69mW（输入电压为 5V）。这相当于约 60% 的效率损失。 我希望使用单独的 SMPS 模块 (TI TPSM82821) 为该电源轨供电，以减少这些损耗，但是 i.MX93 数据手册在电源轨时序要求中没有对 Tstep 或 Toff_step 进行定义。是否存在时间上的要求，还是只需要对顺序有要求？ 使用 VDD_SOC 作为外部开关电源的使能触发信号（通过比较器）是否合理？或者是否有更好的选择？我假设在掉电期间，由于 TPMS82821 具有输出主动放电功能，0V8 的放电速度会比 VDD_SOC 快。 Re: i.MX93 power sequencing 你好， 表 6 中有 Tstep 或 Toff_step 的时间。 PWRUP 模式： tSTEP（从前一个电源轨开启到下一个电源轨开启所需的时间）：2 毫秒 tOFF_STEP（从前一个电源轨关闭到下一个电源轨关闭所需的时间）：8 毫秒 此外，您还可以使用 VDD_SOC 作为参考，在上电/关电序列中触发外部稳压器。 顺祝商祺！

FRDM-IMX93 — LPSPI3/EXPI (P11) SPIピンは、外部デバイスとの間で有効なSPIトランザクションを生成しません。 件名:FRDM-IMX93 — LPSPI3/EXPI(P11)SPIピンは外部デバイスとの有効なSPIトランザクションを発生させません。オンボードトライラジオモジュール(MAYA-W27x)との競合が疑われています。 こんにちは、NXPチームの皆さん、 外部のSPIデバイス(Waveshare 2-CHのCAN HAT https://www.waveshare.com/wiki/2-CH_CAN_HAT)を起動しようとしています。FRDM-IMX93ボードのEXPI 40ピンヘッダー(P11)にデュアルMCP2515を搭載し、LPSPI3(GPIO_IO08–11、RPi互換ピン位置に一致)を使用しています。HAT自体が完全に機能することを確認しました（標準のdtoverlay=mcp2515構成の純正Raspberry Piでテストし、動作確認済みです）。 理事会 / BSP: FRDM-IMX93、モデルNXP FRDM-IMX93 NXP i.MX リリースディストリビューション 6.18-whinlatter、カーネル 6.18.2-1.0.0-gf49f45233f7b 私が設定した内容（デバイスツリーレベルで全て正しいことを確認済み）： オーバーレイは &lpspi3 の下に mcp2515@0/mcp2515@1 を追加します。cs-gpios = <&gpio2 8 1>、<&gpio2 7 1>;(GPIO_IO08/GPIO_IO07)で、これは NXP 自身のアップストリームパッチで見つけた類似の FRDM-IMX93 SPI3 ペリフェラル(pixpaper display overlay)の GPIO ベースの CS パターンに対応しています。 以前は /sys/kernel/debug/pinctrl/ で (MUX UNCLAIMED) であったため、&pinctrl_lpspi3 を拡張して GPIO_IO07 (CS1) を GPIO として mux しました。 CS0と競合していた既存のspidev0ノードを無効化しました。 reg_vexp_3v3/reg_vexp_5v (レギュレータ常時オン) を有効にしました。これらはデフォルトでは無効になっており、これがないと EXPI ヘッダーに電源が供給されませんでした。 /dev/spidev2.0が作成され、pinmuxで4つのSPIピンすべてに正しい機能割り当て（lpspi3grp）が表示されていることを確認しました。 症状： MCP251Xドライバは常に失敗します:spi2.0:MCP2515を初期化できません。配線が間違っている？(err=19) および spi2.1:MCP251x はリセット後に設定モードに入りませんでした (err=110) — 上記のすべてのデバイスツリーのバリエーションでまったく変わりません。 /dev/spidev2.0 上で spidev_test (互換性のある lwn、bk4) を使用して SPI レベルの生テストを実行します。RXバッファは、MOSI/MISOが物理的に短絡（ループバック）、開放状態、またはシャントでブリッジされているかどうかに関わらず、バイト単位で同一のデータを返します。これは、P11ヘッダーピン19/21/23/24にあるSPI3信号がコントローラの実際のバス活動に反映されていないことを示唆しています。つまり、信号がヘッダーに届いていないか、他の何かが干渉している可能性があります。 疑われる根本原因: UM12181(FRDM-IMX93ボードユーザーマニュアル、セクション2.11「トライラジオモジュールインターフェース」)によると、SPI3信号(CLK、MOSI、MISO、CS0 — GPIO_IO08-11で多重化)は、オンボードのMAYA-W27xトライラジオモジュールとM.2コネクタ間で、双方向の1.8Vレベルトランスレーター(U729、抵抗選択)を介して共有されます。この文書では、SPI3代替機能がSoC側から駆動される場合に、EXPIヘッダー（P11）がこの共有パスから電気的に絶縁されるかどうか、またどのように絶縁されるかについては明確にされていません。 質問： P11のGPIO_IO08-11の露出はU729トランスレーター/トライラジオパスから電気的に独立しているのでしょうか?それともP11でSPI3を使う場合、信号を正しくヘッダーにルーティング・隔離するために、トライラジオモジュールの無効化、GPIOエキスパンダービットの無効化、抵抗の再作業などの追加設定が必要でしょうか? FRDM-IMX93ボード上でLPSPI3を外部で使用するための、検証済みのリファレンスデバイスツリー（EVK用のimx93-11x11-evk-lpspi.dtsのようなもの）はありますか？ P11接続トポロジーを確認するために、SPI3/U729信号経路の回路図抜粋を共有できますか? ご協力に感謝いたします。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi はい、p11ヘッダーには3.3Vと5Vがあります。 なぜエラーが発生するのでしょうか？ imx93-11x11-lpddr4x-frdm ログイン:ルート root@imx93-11x11-lpddr4x-frdm:~# dmesg |grep -iE 'mcp251|lpspi3' [ 8.989639] MCP251X:module_layoutのシンボルなしバージョン [ 10.032864 mcp251x spi2.1: リセット後、MCP251xがコンフットモードに入らなかった [ 10.033021] mcp251x spi2.1: プローブ失敗、err=110 [ 10.033034] MCP251x SPI2.1: ドライバー付きプローブ MCP251x エラー -110 で失敗 [ 10.074097] MCP251x spi2.0: 初期化できませんMCP2515。配線が間違っているのですか? [ 10.074256] mcp251x spi2.0: プローブ失敗、err=19 root@imx93-11x11-LPDDR4x-frdm:~# IP リンク 表示 1: lo: MTU 65536 qdisc noqueue state 不明モード デフォルトグループ default qlen 1000 リンク/ループバック 00:00:00:00:00:00 BRD 00:00:00:00:00:00:00 2: eth0: MTU 1500 QDISC MQ 状態 ダウンモード デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 90:A9:f7:80:42:26 BRD FF:FF:FF:FF:FF:FF 3: eth1: MTU 1500 QDISC MQ STATE DOWN MODE デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 90:A9:f7:80:42:27 BRD FF:FF:FF:FF:FF:FF 4: mlan0: MTU 1500 QDISC MQ STATE UP モード 休眠グループ デフォルト QLEN 1000 リンク/エーテル 80:A1:97:50:4E:0d BRD FF:FF:FF:FF:FF:FF 5: uap0: MTU 1500 qdisc noop state DOWN mode デフォルトグループ デフォルト qlen 1000 リンク/エーテル 82:A1:97:50:4f:0d brd ff:ff:ff:ff:ff 6: wfd0: MTU 1500 QDISC NOOP 状態 ダウンモード デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 82:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff:ff 7: can0: MTU 16 QDISC NOOP 状態 ダウンモード デフォルトグループ デフォルト qlen 10 リンク/CAN Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi FRDM-IMX93: LPSPI3 (P11 EXPIヘッダー) のSCKピンに信号が出力されません 問題 私はP11 EXPIヘッダー上のLPSPI3(GPIO_IO08-11、spi@42550000)を使って外部SPIデバイス(2× MCP2515 CAN)を操作しようとしています。ドライバーはアクティブで、ペリフェラルは「内部」で動作しているように見えますが、物理的なSCKピン(GPIO_IO11)には信号が出力されていません。 証拠 オーバーレイはエラーなく適用され、SPIコアにspi2.0/spi2.1が登録されました。 電源、pinctrl、pinctrl-assert-gpios、cs-gpios、およびクロックソースはすべて正しく、検証済みです。 CS0（同一バンク、GPIO代替機能、モード=0）は完璧に動作し、マルチメーターとロジックアナライザーの両方でパルスが確認できます。 SCK(モード=1、ネイティブLPSPI3_SCK)はロジックアナライナ上で完全にフラット/0Vで、HATが接続されているかどうかにかかわらず、連続トリガーループには影響しません。 それにもかかわらず、LPSPI3のIRQ(GIC 97)は実際には/proc/interrupts(220回の割り込みで生成される単一の転送試み)でトリガーされており、ペリフェラルの内部ロジック(ステータス/IERレジスタ)がアクティブです。 /dev/memでLPSPI3のベースアドレス(0x42550000)を読み取ると「バスエラー」が返されますが、同じバス上で動作しているflexcan2(0x425b0000)も同じエラーを返します。つまり、これはLPSPI3特有のものではなく、一般的な/dev/memの制限であり(コントロールグループで除外されています)。 DMA理論は検証され、無効とされました。無効なphandleでDMASを上書きすると、ドライバーは「dma setup error -19, use pio」というメッセージとともにPIOにフォールバックしましたが、SCK信号は依然として表示されませんでした。 `clk_ignore_unused` ブート引数も効果はありませんでした。 まとめ LPSPI3ペリフェラルの内部ロジックは動作しており(割り込みを発生)、SCK信号は外部ピン(GPIO_IO11)に到達しません。同じpinctrlグループのCS0(GPIOモード)は正しく出力しますが、SCK(LPSPI3のネイティブ代替機能)はそうではありません。これは、パッドドライバーやシリコンに関連する設定の詳細、あるいはNXPが認識すべき設定の詳細を示しているように見えますが、これはデバイスツリーやソフトウェアでは説明できません。 質問 FRDM-IMX93において、P11を介したLPSPI3_SCK（GPIO_IO11、ネイティブ代替機能）のために、デバイスツリーとは別にハードウェア/ファームウェアの有効化手順は追加されていますか？ LPSPI3がi.MX93 EVK(community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ)と同じピンで動作する例があります—可能かもしれませんFRDM特有の違いはあるのでしょうか？ Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi こんにちは、 @irfanktm お元気でお過ごしのことと思います。 実際には、i.MX93 FRDM PADとP11 GPIO_IO08-IO11ピンの間には直接的な接続があります。 Manuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.png 私のそばで再現するための手順を教えていただけますか? よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi ログを見る限り、あなたはspidev_test上でSPIデバイスにアクセスしようとしているようですが、デバイスはMCPドライバーによって処理されています。 私が知りたいのは、使用しているデバイスツリー（.dts）全体です。例えば、以下のようなものです。 imx93-11x11-frdm.dts また、もし変更を加えた場合は、変更内容をお知らせください。 また、MCP2515のCANモジュールを手に入れて統合を試してみようと思います。 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi お使いのデバイスツリー全体を共有していただけますでしょうか。 あるいは、lpspi3ノードとピンマルチプレクサに関連するものだけかもしれません。 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi こんにちは、 @irfanktm 私は自分の側でいくつかテストを行いました。 Manuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.png 私のi.MX93 FRDMではSPIは正常に動作しています。 Manuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.png 私もあなたと同じ環境にいます。 もう一つ質問があります。 i.MX93 FRDMボードの3V3ピンと5Vピンに電圧はかかっていますか？ そうでない場合は、以下のリンクを参照して、委員会の規制当局に通知してください。 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Enable-3-3-V-and-5-V-Regulators-for-Expansion-Header-on-i-MX9/ta-p/2299415 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi いいえ、imx93-11x11-frdm.dtsファイルがオリジナルです。私はmcp2515-can-hat.dtboのオーバーレイファイルを編集しました、https://www.waveshare.com/wiki/2-CH_CAN_HATINT_1をデフォルトのGPIO_25からGPIO_24（物理ピン18）に変更しただけです。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi もし何か足りなければ、私が追加できます。 root@imx93-11x11-lpddr4x-frdm:/sys/firmware/devicetree/base# ls '#address-cells' クロック-OSC-24Mファームウェア mcp2515_clock PMU レギュレーター-HMISC-VDDIOレギュレーター-vEXC-3v3 soc@0 USBphynoP2 「#size-Cells」クロック-OSC-32K IMX93-LPM メモリ PSCI レギュレーター-USDHC2 レギュレーター-VEXP-5V サウンド-MQS usdhc3_pwrseq __symbols__ 互換割り込みcontroller@48000000モデル レギュレーター-ADC-VREF レギュレーター-usDHC3 リモートプロック-CM33 SW-キー 別名 CPUS 割り込み親 MQS1 レギュレーター-AVDD レギュレーター-VDD-12V リザーブドメモリ熱ゾーン 選択したディスプレイサブシステム LDB-ディスプレイ-コントローラ MQS2 レギュレーター-CAN2-STBYレギュレータ-VDD-5P0V セキュア・エンクレーブ タイマー クロック-ext1 エトス LDB-PHY名 レギュレーター-DVDD レギュレーター-VDDOシリアルナンバーUSBYyNOP1 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi MCP2515 / i.MX93 LPSPI3 — 根本原因の更新 前回の報告の続報です。新たな隔離テストでは、MCP2515モジュールから離れ、i.MX93 LPSPI3 SPIコントローラ/ドライバに向けられています。 実施されたテスト: ユーザー空間のspidevツールを使用して、MISOラインの物理状態のみを変化させながら、LPSPI3（500kHz、モード0）に対してRESET + CANSTAT読み取りサイクルを繰り返し発行します。 MISOを実際のMCP2515チップに接続した場合：不安定で、期待される0x80に到達することはまれです。 MISOが物理的に切断された状態（フローティング状態、チップが接続されていない状態）：それでも、約10～11ミリ秒の周期で、構造化された繰り返しバイトパターン（0x00 / 0xFF / 0xFB）が表示されます。 MISOを10kΩの抵抗器を介してGNDに接続した場合、同じ繰り返しパターンが依然として現れ、本質的に変化はありません。 MISOをGND（約0Ω）に直接短絡すると、パターンは完全に消え、読み取り値は平坦で一定の0x00になります。 主な調査結果： まったく同じバイトシーケンスが、ミリ秒ごとに同じタイミングで、独立した実行(異なるプロセスID、異なる時間)や異なる物理的なMISO条件(切断、10kΩプルダウン、または実際のチップに接続した場合)でも再表示されます。SPI ioctl() 呼び出し自体は毎回成功（エラーなし）を返します。これは転送の失敗が隠蔽されているわけではなく、実際のデータが呼び出しごとにクロックインされています。 解釈： 真にフローティング状態または抵抗負荷状態の入力ピンは、異なるプロセス呼び出し間で、ミリ秒単位まで同一のホスト非依存のビットパターンを再現してはならない。この決定性のレベルから、読み戻されるバイト値は実際のMCP2515 SO/MISOラインを代表するものではなく、LPSPI3周辺機器やそのLinuxドライバの固定的で再現可能な内部状態(例:古いRXのFIFOコンテンツや、入力ピンの実際の論理レベルに関係なく固定パターンの読み取り)から来ていることを示唆しています。これを上書きするのはGNDへのハードショートだけです。 NXPへの質問です:LPSPI3(またはそのLinuxドライバーであるspi-fsl-lpspi)は、ピンの実際のサンプリング値の代わりに固定または古びたRX FIFOコンテンツを返すことはあり得ますか?このようなデターミニスティックで配線に依存しないリードバックパターンを説明する既知のエラタムやドライバの挙動はありますか? Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技術サポートの要請 MCP2515 (Microchip) と i.MX93 (NXP) の SPI2/LPSPI3 との SPI 通信障害 1. 要約 2つのMCP2515 CANコントローラ(Waveshare 2-CHAN HAN、MCP2515-I/SO、16 MHzクリスタル)は、LPSPI3を介してi.MX93-11X11-LPDDR4X-FRDMボードにコネクテッドされています(SPI2、CS0/CS1)は、電源アップやSPIやハードウェアリセット後に構成モードに入ることはありません。すべてのレジスタ読み取りで、期待されるCANSTAT = 0x80ではなく、固定された不変の値が返されます。カーネルmcp251xドライバは常にプローブの失敗を報告します(err=-110「リセット後にconfモードに入らなかった」またはerr=-19「配線が間違っている?」)。 2. 環境 SoM/ボード: i.MX93-11X11-LPDDR4X-FRDM カーネル: 6.18.2-1.0.0-gf49f45233f7b (NXP ダウンストリーム)、CONFIG_SPI_FSL_LPSPI=y (組み込み)、ERR051608 プリスケール修正が既に適用済み SPIバス：LPSPI3（spi@42550000）、チップセレクト2系統、カスタムデバイスツリーオーバーレイ（16MHz固定クロック、IRQ GPIO3-23 / GPIO3-24） CANモジュール:Waveshare 2CHキャンハット、MCP2515-I/SO、「E3 2335BK5」(正規のマイクロチップマーキングフォーマット) ドライバ:mcp251x(メインライン)、カーネルドライバーおよびカスタムspidevベースのテストユーティリティでテスト済み 3. トラブルシューティングを実施 デバイスツリーのオーバーレイターゲット(&spi1/&lpspi3 対 誤り & spi2 ラベル)を修正しました — オーバーレイが正しく適用され、MCP2515の子ノードがライブDTに存在します LPSPI3のpinctrl、cs-gpios、割り込み親/GPIOマッピングを、実行中のデバイスツリーに対して検証しました。すべて正しいです。 ロジックアナライザを使用してマスター側のSPI信号の完全性を検証しました。複数のキャプチャにおいて、i.MX93によってMOSI、SCK、およびCSが正しく一貫して生成されていることが確認されました。 両CANモジュールでVDD = 3.3V、アイドルMISO = 3.3Vが確認(GNDへのショートなし) 両方のモジュールで、リセットピン（SOIC-18の17番ピン）が3.3V（非アクティブ）であることを確認しました。 SPIモード0,0とモード1,1（CPOL/CPHA）、100kHz～8MHzクロックでテストしましたが、動作に変化はありませんでした。 2つの並列MCP2515デバイス間のMISOバス競合を解消するため、CS0/CS1に10kΩのプルアップ抵抗を追加しました。これにより、読み出しデータは安定しましたが、修正はされませんでした。 カスタムspidevテストツール：リセット命令＋リセット後の即時/連続CANSTATポーリング（1ms間隔、300msウィンドウ）—CANSTATは瞬時に固定値に落ち着き、0x80に達することはありません。 WRITEをCANCTRL(0x80)に強制し、その後READに続けます — 読み戻しは書き込みの影響を受けず、SPIトランザクションがCANコントローラロジックで処理されていないことを示します 4. 重要な観察事項 CS0 デバイス: CANSTAT/CANCTRL/すべてのレジスタは一貫して 0x00 を読み出します (数十回のリセット + 読み取りサイクルにわたって 100% 再現可能、レジスタ アドレス、SPI モード、または書き込み値に関係なく)。 CS1デバイス：CANSTAT/CANCTRL/すべてのレジスタは常に0xFFを読み出す（100%再現可能、トランザクション中にMISOが切り替わることはない）。 両デバイスともマスターからはクリーンで正しくタイミングされたMOSI/SCK/CSを表示しますが、命令、アドレス、CSプルの設定に関係なく固定値を返します。このパターンはホスト側のSPIモード/タイミング/配線では説明できず、MCP2515 CANコアがリセット後/発振器不安定な状態から決して離れないことと一致しています。 5. リクエスト ホスト側のSPIシグナリングがロジックアナライザーで正確であることが確認され、デバイスツリーやカーネルドライバの設定も正しいことが確認されたため、以下の点についてのガイダンスを望みます。 この障害シグネチャ（レジスタの読み取りが固定され、CANSTATが0x80にならない）が、既知のMCP2515水晶発振器の起動問題と一致するかどうか、およびOSC1/OSC2に対する推奨オシロスコープ/検証手順 MCP2515とi.MX93 LPSPIの間には、既知の互換性の問題が存在するか（既に解決済みのERR051608以外）？ MCP2515モジュールにハードウェアの欠陥が疑われる場合の推奨される次の診断手順またはRMAプロセス 追加のロジックアナライザキャプチャ、デバイスツリーファイル、またはカーネルログが必要な場合はお知らせください。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技術サポートリクエスト — i.MX93 LPSPI3 MCP2515 複数のMCP2515 CANコントローラ(テスト済み3台、2つの異なるメーカー/ボード、8/16 MHzのクリスタル)がLPSPI3(SPI2)経由でi.MX93-11X11-LPDDR4X-FRDMボードに接続されていると、リセット後に断続的に構成モードに到達できません(CANSTATは0x80を認識すべきです)。 環境: カーネル 6.18.2 (NXP ダウンストリーム)、CONFIG_SPI_FSL_LPSPI 組み込み、ERR051608 プリスケール修正あり。デバイスツリー/pinctrlが正しいことを確認しました（LPSPI3のSIN/SOUT/SCKは適切に多重化され、CSはcs-gpios経由）。ロジックアナライザによるキャプチャ結果から、MOSI/SCK/CSがホストによって正しく一貫して生成されていることが確認されました。 重要な観察事項： 新しく開いたspidevハンドルでは、最初のRESET + CANSTAT読み取りが約50～60%の確率で成功し（~0x80）、タイミングは常に約2～6msです。 同じ、まだ開いているSPIファイルディスクリプタに対して追加のRESET+読み取りサイクルを発行すると、その後は一貫して失敗し、0x80に再び到達することのない、約10～11ミリ秒周期の固定値（0x00 / 0xFF / 0xFB）の繰り返しパターンに落ち着きます。 この同じ故障シグネチャは3つの物理MCP2515ユニットと2つの異なる基板デザインすべてで再現されており、単一の欠陥チップやモジュールを除外しています。 転送間隔遅延（delay_usecs）の追加、ダミーの「フラッシュ」SPI転送、およびサイクル間のギャップを100msに増やしても、結果は変わりませんでした（パターンが開始されると、10回中0回成功）。 VDD、GND、RESETピン、およびアイドル時のMISOレベルはすべて正常（3.3V）であることが確認されています。 メインラインのmcp251xカーネルドライバーのプローブ()も同じ不安定さを示しています。5回連続のバインド試行(アンバインド/クリアdriver_override/バインド)すべて失敗し、err=-19(「配線が間違っている??」)とerr=-110(リセット後にコンフィングモードに入らなかった)を交互に繰り返すパターンです。 このパターン(開いた後の最初の転送で良好、その後同じセッション内のその後の転送で固定された再現可能な失敗署名が現れる)は、MCP2515ユニット自体の欠陥というよりも、連続するLPSPI3転送やCSサイクル間で完全にクリアされていない状態を示唆しています。 NXP への質問: これは、既知の LPSPI3 (i.MX93) の動作と一致していますか?同じSPIファイルディスクリプタ上で連続転送間でFIFO/CSの状態がきれいにリセットされないことについて — そして推奨されるドライバーレベルの回避策はありますか(例:ERR051608を超える遅延、FIFOフラッシュ、またはCS処理が必要ですか？ Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi こんにちは、親愛なる@irfanktmさん あなたのCASEのために私が作成した投稿をご覧ください: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/2-CH-CAN-HAT-with-FRDM-IMX93/ta-p/2415467 BSPとi.MX93 FRDMで2チャネルCAN HATを使う方法も説明されています。 よろしくお願いいたします。 サラス。

i.MX93 電源シーケンス 私はi.MX93とその推奨PMIC（PCA9451）をベースにした低消費電力PCBを設計しています。 AN13917の消費電力測定に関する文書によると、最低電力モード（セクション6.7.8）では、SoC+DRAMの消費電力は約174mWになるはずです。ただし、文書内の現在の測定値はPMICの後に行われているため、効率損失は含まれていません。 実際の予想消費電力を計算すると、vdd_ana_0p8レールが非常に高いエネルギー消費量を示すことが際立っています。このレールでの16.5mAの電流消費により、PMIC LDOで69mWの電力損失が発生します（5V入力時）。これは効率損失の約60％に相当する。 これらの損失を低減するために、この電源レールを別のSMPSモジュール（TI TPSM82821）から給電したいのですが、i.MX93のデータシートには、電源レールのシーケンス要件にTstepまたはToff_stepの定義がありません。実際にタイミングに関する要件はありますか？それとも順序付けに関する要件だけですか？ 外部SMPSの有効トリガーとしてVDD_SOCを使うのは賢明でしょうか?それとももっと良い選択肢がありますか?TPMS82821には出力のアクティブ放電機能があるため、0V8は電源を切る際にVDD_SOCより速く放電すると思います。 Re: i.MX93 power sequencing こんにちは、 表6にTstepまたはToff_stepの時刻が記載されています。PWRUPモード： tSTEP（前の電源レールがオン状態から次の電源レールがオンになるまでの時間）：2ms tOFF_STEP（前の電源レールがオフになってから次の電源レールがオフになるまでの時間）：8 ms また、VDD_SOCを基準として外部レギュレーターを起動・電源オフのシーケンスで作動させることもできます。 よろしくお願いいたします。

PTN3460 Support Hi Team, Datasheet of PTN3460I mentions a "I2C-bus utility and programming guide for firmware and EDID update" document. I am not able to find the document related to I2C bus utility and EDID update tool.  Further, Can we flash the internal flash of PTN3460I using DP Aux. If so, is there a utility for the same.? PTN3460 (Flash-over-AUX) utility is only for firmware update or for EDID update also? Re: PTN3460 Support Hi, The document referenced in the PTN3460I datasheet as "I2C-bus utility and programming guide for firmware and EDID update" corresponds to AN11606 – PTN3460I Programming Guide (for the PTN3460I) and AN11128 – PTN3460 Programming Guide (for the commercial PTN3460). Both are publicly available on NXP.com: AN11606 – PTN3460I Programming Guide (Rev. 1.4) — covers I²C-bus configuration table structure, EDID programming (up to 7 EDID data structures), all register definitions, and step-by-step procedures for writing EDID and configuration data into the PTN3460I internal flash via I²C. AN11128 – PTN3460 Programming Guide (Rev. 1.8) — the equivalent document for the commercial PTN3460BS variant. Regarding your questions about the DP AUX interface and the Flash-over-AUX (FoA) utility: Flashing the internal flash via DP AUX: Yes, PTN3460I supports programming its internal flash through the DP AUX channel. The registers can be accessed either via the I²C-bus interface or via DP AUX. Flash-over-AUX (FoA) utility scope: There are two separate FoA tools for PTN3460/PTN3460I: FoA firmware updater (a separate tool for PTN3460IBS firmware F2) — used exclusively for firmware version upgrades via the DP AUX channel. FoA EDID Updater — a separate utility used specifically for EDID updates via the DP AUX channel. Please find them attached below. BRs, Tomas

使用 EB Tresos 生成的 RTD 驱动程序，并结合 FreeRTOS + MPU 你好， 我们使用 RTD 6.0.0 和 电池管理系统 0.9.1。使用 EB Tresos 中的 SDK 生成我们的驱动程序代码。它在不使用 MPU 的 FreeRTOS Cortex M7 移植版下运行良好。 现在，我们想切换到使用 MPU 的 FreeRTOS 移植版。我想分两步完成这件事： 1）将所有任务设为特权任务，但使用MPU，即每次上下文切换时都对MPU进行重新编程。 2）将所有任务设为非特权任务。这意味着我必须在非特权任务使用的驱动程序中启用“启用用户模式支持”。 目前，我在1点上遇到了困难。驱动程序功能不稳定。例如，SPI 只能间歇性地工作。MPU区域似乎无法正常工作。即使这个问题得到解决，第 2) 点又该如何实现呢？监控调用处理程序由 FreeRTOS 和 RTD 提供。我应该把它们合并吗？ Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@Julián_AragónM ， 我从他们的网站下载了 FreeRTOS，并使用了一个同时支持 Cortex M7 和 MPU 的移植版本。如果我理解正确的话，我需要使用 NXP 提供的 FreeRTOS。我只找到了 NXP 的 FreeRTOS 可以在 S32DS 中配置，而没有找到 EB Tresos 的 FreeRTOS。我的问题如下： 我可以使用提供正确 M7+MPU 端口的通用 FreeRTOS 吗？ 如果没有，NXP 是否提供了可在 EB Tresos 中配置的 FreeRTOS？ 我们迟早需要使用通过 ASIL-D 认证的操作系统。如果 NXP 提供的 FreeRTOS 没有获得 ASIL-D 认证，我们需要切换到其他方案。 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@PhilippH ， 首先，FreeRTOS 7.0.0 中添加了对 MPU 的初始支持。CD1，请确认这是你正在使用的软件包吗？（或最新版本 0.8.0 CD1）。 1）能否告知哪些MPU区域无法正常工作？如果可以，请分享配置信息和运行流程。 此外，请遵循 S32K3 FreeRTOS 用户手册中的建议： 启用“使用 MPU”和“使用 MPU 包装器 v1”选项。 将第一个可配置区域设置为 9 而不是 0，以避免与 RTD 中的 MPU 区域发生冲突。 注意：将 FreeRTOS 与 MPU 支持集成需要修改 RTD 链接器文件，以定义 FreeRTOS 使用的所需内存段。在对应用程序进行更改时，请参考示例文件。 2) 我认为不需要合并，因为 FreeRTOSConfig.h声明以下宏： /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler 这会将 FreeRTOS 的 SVC 调用重定向到 exceptions.c 中 RTD 提供的 SVC_Handler。 此致， 朱利安 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@PhilippH ， 我可以使用提供正确 M7+MPU 端口的通用 FreeRTOS 吗？ 您可以使用通用的 FreeRTOS 移植版；但是，您需要为 S32K3 的特定配置实现自己的解决方案，而 NXP FreeRTOS 软件包中已经提供了大部分解决方案。请尝试使用此端口启动，看看是否能解决问题。 如果没有，NXP 是否提供了可在 EB Tresos 中配置的 FreeRTOS？ 不，目前提供的 NXP 软件包仅兼容 S32DS。能否请您解释一下为什么您需要在 EB Tresos 中使用 FreeRTOS？ 通常情况下，EB Tresos 用于符合 AUTOSAR 标准的应用，但是，我们提供的 FreeRTOS 软件包仅供客户评估，不建议在生产中使用，因为它不符合汽车认证 (ISO26262)。您可以看到它以代码发布（CD）质量发布，这是因为 FreeRTOS 是一个开源软件，NXP 将其作为参考软件提供，而没有任何功能安全认证。 如果您的应用需要经过功能安全认证的操作系统，您可以考虑其他选择，甚至可以考虑我们合作伙伴提供的操作系统： SafeRTOS（基于 FreeRTOS 功能模型，易于迁移）： https://www.highintegritysystems.com/safertos/ AUTOSAR操作系统 µ速度 embOS-Safe NXP RTOS 客户可以自行选择适合其项目的第三方实时操作系统、协议栈、集成开发环境、编译器等。 此致， 朱利安 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 非常感谢您的解答。 我使用 NXP 提供的 SafeRTOS 和端口成功运行了它，因为 NXP 提供的端口已经解决了我在使用 SafeRTOS 提供的通用 Cortex M7 + MPU 端口时遇到的问题。 关于我们对 EB Tresos 的需求：我们最初使用的是 S32DS，但由于我们使用的 IC，我们需要最新版本的电池管理系统 SDK，而 S32DS 中没有提供该 SDK（至少当时没有）。我们希望尽可能少地使用 Autosar。目前可行的办法是生成驱动程序函数，然后从 FreeRTOS 调用它们。我们目前未使用，也不打算使用 Autosar RTE。 关于第三方操作系统：“易于迁移”是否意味着 SafeRTOS 也存在同样用户友好的移植版本？我们之前使用过 SafeRTOS，但不是使用 Autosar 驱动程序，而是完全手写的驱动程序。 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@PhilippH ， 很高兴听到它运行正常！ 使用 FreeRTOS 时，迁移到 SafeRTOS 通常是最简单的途径，因为它们都基于相同的功能模型，并且都提供了一些专门的迁移工具。遗憾的是，NXP 没有为 S32K3 提供 SafeRTOS 移植版本。 从WHIS 的页面上，我可以看到S32Kxx 设备通过我们的 RTD 得到支持，为 AUTOSAR 和非 AUTOSAR 应用提供完整的 IP 和功能覆盖，这意味着您可以选择不使用 Autosar。 此致， 朱利安 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 供您参考，我需要编辑 system.c 文件。由 S32K3 RTD 6.0.0 提供： LOCAL_INLINE void Direct_GoToUser(void) { ASM_KEYWORD("push {r0}"); //ASM_KEYWORD("ldr r0, =0x1"); <---- Before: CONTROL.SPSEL changes stack when invoked from FreeRTOS Task. ASM_KEYWORD("ldr r0, =0x3"); // My edit: CONTROL.SPSEL does not change in my case (always invoked from FreeRTOS Task) ASM_KEYWORD("msr CONTROL, r0"); ASM_KEYWORD("pop {r0}"); } 需要进行此修改，因为在 r0 的 push 和 pop 操作之间，所使用的堆栈不能改变。 RTD 假定始终使用 MSP，但 FreeRTOS 任务使用 PSP。 NXP 提供的 FreeRTOS 端口的 SVC 处理程序在提升权限时能够正确清除 CONTROL.nPRIV，而不会更改 CONTROL.SPSEL。你应该修改 Direct_GoToUser() 函数，设置 CONTROL.nPRIV，同时保留其他位，而不是将 CONTROL 设置为常量值。就我而言，CONTROL=0x3 就足够了，因为我总是从 FreeRTOS 任务中调用 Direct_GoToUser()，但在一般情况下，它也可以从非特权 main() 中调用。 此外，我想知道在更改 CONTROL 之后是否应该添加 ISB 指令，就像 ARM 建议的那样。

Question regarding removal of W8997 firmware from imx-firmware Hello NXP team, I’m contacting you regarding the following commit in the imx-firmware repository: “Remove SD/PCIE W8997 support from BSP from 26Q1 onwards” Could you please clarify whether the W8997 firmware was only removed from the standard  imx-firmware package or wheter support for these devices has been discontinued entierly ?  We can retrieve the last W8997 firmware files from the Git history, so our main question is about the recommended way to maintain W8997 support while continuing to use the latest imx-firmware releases. Is it supported to install the latest imx-firmware package and add the W8997 firmware files from the last release that contained them? If so, is there any recommended procedure or packaging approach to do this cleanly and avoid conflicts with future imx-firmware updates? Our goal is to keep systems on the latest i.MX firmware package while preserving support for older deployed hardware based on the 88W8997. Best regards, Antoine Gennart Re: Question regarding removal of W8997 firmware from imx-firmware Hello @agennart, hope you are doing well. I'm checking this with the internal team. I will get back to you once I get a response. Re: Question regarding removal of W8997 firmware from imx-firmware Hi @agennart, Could you please provide more details on your project? As well as the W8997 module that you are using and the interface you have implemented (PCIe or SDIO). Re: Question regarding removal of W8997 firmware from imx-firmware I don't have a project using W8997. I am trying to bump the `imx-firmware` version in the Buildroot project. Buildroot aims to maintain compatibility with older hardware, while also supporting newer hardware, hence the update. The problem is that this update would break compatibility with older hardware, so I need a way to preserve that compatibility. I see two possible scenarios: 1. NXP has simply removed support for the older hardware. In that case, the Buildroot project needs a way to select the appropriate version of `imx-firmware` in order to maintain compatibility with older hardware. 2. NXP has moved support for the older hardware to another package/project. In that case, the Buildroot project needs to update or integrate that package/project to maintain compatibility. Re: Question regarding removal of W8997 firmware from imx-firmware Hi @agennart, Support for 88W8997 will be provided through dedicated hotfix branches on Github for both W8997 drivers and firmware based on the LF 6.12.49_2.2.0 release baseline. These branches will contain all future off-cycle releases targeting W8997. Hence, you may update your environemnt to reference the below hotfix branches: Driver branch - GitHub - https://github.com/nxp-imx/mwifiex/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 Firmware branch - GitHub -https://github.com/nxp-imx/imx-firmware/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 For compatibility with W8997, the suggested path is to point to the shared hotfix branches as the main branch will not receive further support for this device. Please let me know if this information fits your requirements.

烧断的熔丝 IMXRT1024是否有办法在不将电路板置于串行下载器模式的情况下（例如通过JTAG或UART）烧毁熔丝？ Re: Burning fuse 你好@Abhay2080 ， 您可以使用 OCOTP 模块通过软件烧断熔丝，如参考手册第 23.6.1.2.2 章“功能”中所述。请参考名为 ocotp_example 的 SDK（版本 26.06）示例，以了解其工作原理。您可以通过SDK Builder找到它。 另请参阅 23.3.1.2熔丝和影子寄存器读取和 23.3.1.3熔丝和阴影寄存器写入 RM 中的部分，以提供附加信息。 BR 哈比卜 Re: Burning fuse 根据我的研究，烧断熔丝是可行的。 1. SPT（最简单）- 但我们需要将启动模式更改为 ISP，并且需要 UART 或 USB 接口。 2. CST（制造工具） - 这里我们也需要将启动模式更改为 ISP，并且需要 USB 接口。 3. 如您所说，通过 OCOTP 模块——无需插入 ISP，只需刷入未签名镜像（包含 OCOTP 驱动程序和待烧录的熔丝），烧录熔丝后，电路板即可锁定。 我的理解是否正确？或者我是否遗漏了其他编程方式，例如通过 JTAG/SWD 等方式？ Re: Burning fuse 你好@Abhay2080 ， 您无需进入串口下载器模式即可使用 OCOTP 模块。例如，在这篇社区帖子中，Kerry 描述了这种用于对熔丝进行编程的替代方法。 请记住，熔丝只能烧一次，所以请小心操作。 安全配置工具可以根据您选择的配置帮助确定所需的值，您可以将其用作指导，以确保对正确的熔丝进行编程。另请参阅 RM 中的第 9.4.1 章“启动 eFuse 说明”，其中提供了熔丝及其用途的详细说明。 BR 哈比卜

EB Tresos生成のRTDドライバをFreeRTOS + MPUで使用する こんにちは、 当社ではRTD 6.0.0とBMS 0.9.1を使用しています。EB TresosのSDKを使ってドライバーコードを生成します。MPUを使わないCortex M7ポートのFreeRTOSでは問題なく動作します。 今度はMPUを使うFreeRTOSポートに切り替えたいです。これを2つのステップで行いたい。 1) すべてのタスクを特権的に設定しつつMPUを使用する、すなわち各コンテキストスイッチでMPUを再プログラムすること 2) すべてのタスクを非特権にする。つまり、非特権タスクで使われるドライバーで「ユーザーモードのサポートを有効にする」を有効にする必要があります 今のところ、私は1)で苦戦しています。ドライバ機能は安定して動作しません。例えば、SPIは断続的にしか動作しない。MPU領域が正しく動作していないようです。たとえこれが解決したとしても、2)どうやって実装できるのでしょうか?スーパーバイザコールハンドラは、FreeRTOSとRTDによって提供されます。それらを統合するべきでしょうか？ Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @Julián_AragónM。 私はFreeRTOSを公式サイトからダウンロードし、Cortex M7とMPUの両方に対応しているポートを使っていました。私の理解が正しければ、NXPが提供するFreeRTOSを使用する必要があるということですね。私はS32DSで設定可能なNXPのFreeRTOSしか見つけられず、EB Tresosは見つかりませんでした。私の質問は以下の通りです: - 正しいM7+MPUポートが付いている汎用FreeRTOSを使えますか? - もしなければ、NXPが提供するFreeRTOSでEB Tresosで設定できるものはありますか? いずれはASIL-D認証済みのOSを使用する必要がある。NXPが提供するFreeRTOSがASIL-D認証を受けていないなら、別のものに切り替える必要があります。 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @PhilippH さん、 まず、FreeRTOS 7.0.0でMPUの初期サポートが追加されましたCD1、これがあなたが使っているパッケージであることを確認できますか?（または最新リリースである0.8.0 CD1）。 1) どのMPUリージョンが正しく動作していないか教えてもらえますか?可能であれば、設定と手順を共有してください。 また、S32K3 FreeRTOSユーザーマニュアルに含まれる推奨事項に従ってください: 「Use mpu」および「Use mpu wrappers v1」オプションを有効にします。 RTDのMPU領域との競合を避けるため、最初の設定可能領域を0ではなく9に設定してください。 注記: FreeRTOSをMPUサポートと統合するには、FreeRTOSで使用される必要なメモリセクションを定義するためにRTDリンカーファイルを修正する必要があります。アプリケーションに変更を適用する際は、サンプルファイルを参考にしてください。 2) FreeRTOSConfig.h なのでマージは不要だと思います以下のマクロを宣言します。 /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler これにより、FreeRTOSのSVC呼び出しが、exceptions.cにあるRTD提供のSVC_Handlerにリダイレクトされます。 よろしくお願いします、 ジュリアン Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @PhilippH さん、 - 正しいM7+MPUポートが付いている汎用FreeRTOSを使えますか? 汎用版FreeRTOSポートを使うこともできますが、S32K3専用の設定については、NXP FreeRTOSパッケージにほとんど提供されている独自のソリューションを実装する必要があります。まずこのポートから始めてみて、問題が解決するかどうか確認してください。 - もしなければ、NXPが提供するFreeRTOSでEB Tresosで設定できるものはありますか? いいえ、提供されているNXPパッケージは現時点でS32DSのみに対応しています。なぜEB TresosでFreeRTOSが必要なのか教えていただけますか? 通常、EB TresosはAUTOSAR準拠のアプリケーションに使われますが、私たちが提供したFreeRTOSパッケージはお客様評価用であり、オートモーティブ認証(ISO26262)を満たしていないため、生産での使用は推奨されていません。FreeRTOSはオープンソースソフトウェアであり、NXPがセーフティ認証なしでリファレンスソフトとして提供しているため、コードドロップ(CD)品質としてリリースされているのがわかります。 もしセーフティ認証済みOSが必要な場合は、パートナーの方からも他の選択肢を検討できます。 SafeRTOS(FreeRTOS機能モデルに基づく、単純な移行付き):https://www.highintegritysystems.com/safertos/ AUTOSAR OS µ-velOSity embOS対応 NXP RTOS プロジェクトに適したサードパーティRTOS、スタック、IDE、コンパイラなどを選ぶのはお客様次第です。 よろしくお願いします、 ジュリアン Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU ご回答ありがとうございました。 NXPが提供するSafeRTOSとPortで動作させることができました。NXPが提供するポートは、SafeRTOSが提供する汎用Cortex M7 + MPUポートで抱えていた問題をすでに解決していました。 EB Tresosの必要性について:最初はS32DSから始めましたが、使用しているICの関係で、当時S32DSには使えなかった最新のBMS SDKが必要でした。Autosarはできるだけ控えめにしたいです。今のところうまくいっていたのは、ドライバ関数を生成し、FreeRTOSから呼び出すことでした。私たちはAutosar RTEを使用しておらず、今後も使う予定はありません。 サードパーティ製OSについて:「簡単な移行で」というのは、SafeRTOSにも同じくらい使いやすいポートが存在するという意味でしょうか?以前SafeRTOSを使っていましたが、AUTOSARドライバではなく、完全に手書きのドライバでした。 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU こんにちは、 @PhilippH さん、 期待通りに動作していると聞いて安心しました！ FreeRTOを使用する場合、SafeRTOSへの移行は一般的に最も簡単な方法です。なぜなら、両者は同じ機能モデル上で動作し、専用の移行ツールを提供しているからです。残念ながら、NXPはS32K3用のSafeRTOSポートを提供していません。 WHISのページを見ると、S32KxxデバイスはRTDでサポートされており、AUTOSARアプリケーションと非AUTOSARアプリケーションの両方で完全なIPと機能カバレッジを提供しているため、Autosarを使わない選択が可能です。 よろしくお願いします、 ジュリアン Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 参考までに、system.cを編集する必要がありました。S32K3 RTD 6.0.0 によって提供されます: LOCAL_INLINE void Direct_GoToUser(void) { ASM_KEYWORD("push {r0}"); //ASM_KEYWORD("ldr r0, =0x1"); <---- Before: CONTROL.SPSEL changes stack when invoked from FreeRTOS Task. ASM_KEYWORD("ldr r0, =0x3"); // My edit: CONTROL.SPSEL does not change in my case (always invoked from FreeRTOS Task) ASM_KEYWORD("msr CONTROL, r0"); ASM_KEYWORD("pop {r0}"); } この編集が必要な理由は、r0のプッシュとポップの間で、使用されるスタックが変更されてはならないためです。 RTDは常にMSPが使用されることを前提としているが、FreeRTOSのタスクはPSPを使用する。 NXPが提供するFreeRTOSポートのSVCハンドラは、特権昇格時にCONTROL.SPSELを変更せずにCONTROL.nPRIVを正しくクリアします。Direct_GoToUser() 関数を変更して、CONTROL を定数値に設定する代わりに、CONTROL.nPRIV を設定し、他のビットは保持するようにしてください。私の場合、CONTROL=0x3で十分です。なぜなら、私はいつもFreeRTOSタスクからDirect_GoToUser()を呼び出すからですが、一般的には非特権のmain()からも呼び出すことができるからです。 さらに、ARMが推奨するように、CONTROLを変更した後にISB命令を追加すべきかどうかも気になります。

HB200x AUTOSAR R21-11 バージョン 0.8.0 S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_2025 がサポートしていません こんにちは、NXPさん。 HB200x AUTOSAR仕様SDKをS32 Design Studioに統合しようとしましたが、以下のエラーメッセージが表示されます。 問題点:Mc33hbはツールチェーン/IDEプロジェクトに存在しません。プロジェクトはコンパイルできません！ レベル: エラー タイプ：検証 ツール:ツールチェーン/IDEプロジェクト 起源:ペリフェラル ターゲット:ツールチェーン/IDEプロジェクト:M7_0 リソース:platform.driver.mc33hb CDD_Mb33Hb.c ファイルでさえCDD_Mb33Hb.hなどは、SDKがS32 Design Studioアプリケーション(v3.6.4)にインストールされた際には追加されていませんでした。 Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ こんにちは、 どうやら間違ったRTDバージョンを使用しているようです。HB200x AUTOSAR R21-11 0.8.0リリースノートに基づき、このソフトウェアはSW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip(S32 Design Studio IDE v3.5にインストールする必要があります)上で使用可能です。 PetrS_0-1789471295419.png BR、ペトル Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ 最新のAUTOSARライブラリを使いたい場合、RTD 6.0.0以上をサポートするHB200x SDKの他バージョンはありますか?

燃える導火線 IMXRT1024には、ボードをシリアルダウンローダーモードにすることなく（JTAGやUARTなどを介して）ヒューズを焼却する機能はありますか？ Re: Burning fuse こんにちは、 @Abhay2080。 OCOTPモジュールを使えば、 リファレンスマニュアルの23.6.1.2.2章「機能」に記載されているように、ソフトウェアを通じてヒューズを焼くことができます。動作については、SDK(バージョン26.06)の例「ocotp_example」を参照してください。SDK Builderを通じて見つけることができます。 23.3.1.2も参照してください。ヒューズとシャドウレジスタの読み取りと23.3.1.3フューズレジスタとシャドウレジスタは、追加情報を提供するセクションをRMに書き込みます。 BR ハビブ Re: Burning fuse 私の調査によると、ヒューズを焼く方法について 1. SPT(最もシンプル) - ただし、起動モードをISPに変更し、UARTかUSBインターフェースが必要です。 2. CST(製造ツール) - ここでも起動モードをISPに変更し、USBインターフェースが必要です。 3. あなたが言及したOCOTPモジュールを経由します - ISPを入れる必要はなく、署名のないイメージ(OCOTPドライバとヒューズを焼き捨てる)をフラッシュしてヒューズを焼き、基板をロックします 私の理解は正しいでしょうか?それともJTAGやSWDのようなプログラム方法が他に見落としているのでしょうか Re: Burning fuse こんにちは、 @Abhay2080 さん。 OCOTPモジュールはシリアルダウンローダーモードに入らずに使用できます。例えば、この コミュニティ投稿 ではケリーがこの別のヒューズプログラミング方法について説明しています。 ヒューズの焼きは一度きりなので、慎重に燃やしてください。 Secure Provisioning Toolは、選択した構成に基づいて必要な値を決定し、正しいヒューズがプログラムされているかを確認するためのガイドとして利用できます。ヒューズとその目的の詳細な説明については、RMの9.4.1章「ブートeFuseの説明」もご参照ください。 BR ハビブ

Rom Bootloader WriteMemory Command CRC16 calculation I'm currently trying to program a KL17 microcontroller using another microcontroller and the KL17's built in UART ROM bootloader. I got pinging and erasing done, at least on the paper, but I'm struggling with writing data to the KL17. The example in the datasheet (page 43) says that for those bytes (framing packet,  excluding CRC16 bytes + memory write command packet):   0x5A, 0xA4, 0x0C, 0x00, 0x04, 0x00 , 0x00, 0x02, 0x00, 0x04, 0x00, 0x20, 0x64, 0x00, 0x00, 0x00  the CRC16 bytes would be 0x06 0x5A. However the CRC16 algorithm provided on page 27 outputs 0x2b 0x56 for me. I've also tried various CRC16 calculators online with many different variants of CRC16 calculation but none of them gave me 0x06 0x5A. Noay_0-1790003799652.png My assumption is that I'm either missing bytes that must be included into the caluclation (I wouldn't know which since the data packets following afterwards all got their own CRC16 bytes) or that someone just messed up the datasheet (which is also unlikely because this example is also exactly like that in the KL17 Sub-Family Reference Manual).  Re: Rom Bootloader WriteMemory Command CRC16 calculation Hello @Noay , Thanks for your post. I think the "0x06 0x5A" value in the Reference Manual is incorrect and most likely a documentation issue. Based on what you provided, your CRC calculation result of "0x2B 0x56" looks correct. You can still use blhost tool to debug Bootloader commands. The parameter "-d" will provide all communication process between Host and Target. I have tried this function on my KL27 board, and please see the screenshot below. We don't have a KL17 EVB board available, could you try the same approach on your KL17 device and see what result you get? Apologies for the documentation mistake. I'll share this with the internal team and recommend updating the documents accordingly. BR Celeste

关于从 imx-firmware 中移除 W8997 固件的问题 您好，NXP团队， 我联系您是关于imx-firmware仓库中的以下提交： “从 26 年第一季度开始，从电路板支持包中移除 SD/PCIE W8997 支持” 请问W8997固件只是从标准imx固件包中移除，还是已经完全停止对这些设备的支持？ 我们可以从 Git 历史记录中检索到最新的 W8997 固件文件，因此我们的主要问题是，在继续使用最新的 imx-firmware 版本的同时，保持对 W8997 支持的推荐方法是什么。 是否支持安装最新的 imx-firmware 软件包，并添加包含这些文件的上一版本中的 W8997 固件文件？ 如果是这样，是否有推荐的步骤或打包方法可以干净利落地完成此操作，并避免与未来的 imx 固件更新发生冲突？ 我们的目标是在保持对基于 88W8997 的旧已部署硬件的支持的同时，使系统保持最新的 i.MX 固件包。 顺祝商祺！ 安托万·热纳尔 Re: Question regarding removal of W8997 firmware from imx-firmware 你好@agennart ，希望你一切都好。 我正在和内部团队核实此事。我收到回复后会尽快回复你。 Re: Question regarding removal of W8997 firmware from imx-firmware 嗨@agennart ， 您能否提供更多关于您项目的信息？除了您正在使用的 W8997 模块和您实现的接口（PCIe 或 SDIO）之外。 Re: Question regarding removal of W8997 firmware from imx-firmware 我没有使用 W8997 的项目。我正在尝试提升 Buildroot 项目中的 `imx-firmware` 版本。Buildroot 的目标是在保持与旧硬件兼容性的同时，也支持新硬件，因此进行了此次更新。 问题在于这次更新会破坏与旧硬件的兼容性，所以我需要一种方法来保持这种兼容性。 我认为有两种可能的情况： 1. NXP 已停止对旧硬件的支持。在这种情况下，Buildroot 项目需要一种方法来选择合适的 `imx-firmware` 版本，以保持与旧硬件的兼容性。 2. NXP 已将对旧硬件的支持转移到另一个代码包，软件包/项目中。在这种情况下，Buildroot 项目需要更新或集成该软件包/项目以保持兼容性。 Re: Question regarding removal of W8997 firmware from imx-firmware 嗨@agennart ， 我们将通过 Github 上的专用热修复分支为 88W8997 提供支持，包括基于LF 6.12.49_2.2.0 版本基线的 W8997 驱动程序和固件。这些分支将包含所有面向 W8997 的未来非周期性版本。因此，您可以更新您的环境以引用以下热修复分支： 驱动程序分支 - GitHub - https://github.com/nxp-imx/mwifiex/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 固件分支 - GitHub - https://github.com/nxp-imx/imx-firmware/tree/hotfix/lf-6.12.49_2.2.0_hotfix_w8997 为了与 W8997 兼容，建议指向共享的热修复分支，因为主分支将不再获得对该设备的进一步支持。 请告诉我这些信息是否符合您的要求。

S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_2025 不支持 HB200x AUTOSAR R21-11 版本 0.8.0 您好，NXP， 我尝试将 HB200x AUTOSAR 规范 SDK 集成到 S32 Design Studio 中，但收到以下错误消息： 问题：在工具链/IDE 项目中找不到 Mc33hb。该项目无法编译！ 级别：错误 类型：验证 工具：工具链/IDE 项目 来源：外围设备 目标：工具链/IDE 项目：M7_0 资源：platform.driver.mc33hb 甚至包括 CDD_Mb33Hb.c 文件在 S32 Design Studio 应用程序 (v3.6.4) 中安装 SDK 时，尚未添加 CDD_Mb33Hb.h 等文件。 Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ 你好， 您似乎使用了错误的RTD版本。根据 HB200x AUTOSAR R21-11 0.8.0 发行说明，该软件可以基于 SW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip 使用（该软件需要安装在 S32 Design Studio IDE v3.5 中）。 PetrS_0-1789471295419.png BR，彼得 Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ 是否有其他版本的 HB200x SDK 支持 RTD 6.0.0 或更高版本？因为我们希望在我们的用例中使用最新的 AUTOSAR 库。

ROM引导加载程序写入内存命令CRC16计算 我目前正在尝试使用另一个微控制器和 KL17 内置的 UART ROM 引导加载程序对 KL17 微控制器进行编程。我已经完成了 ping 和擦除操作，至少在纸面上是这样，但是我在向 KL17 写入数据时遇到了困难。数据手册（第 43 页）中的示例指出，对于这些字节（帧数据包，不包括 CRC16 字节 + 内存写入命令数据包）： 0x5A, 0xA4, 0x0C, 0x00, 0x04, 0x00 , 0x00, 0x02, 0x00, 0x04, 0x00, 0x20, 0x64, 0x00, 0x00, 0x00 CRC16 字节为 0x06 0x5A。但是，第 27 页提供的 CRC16 算法对我输出的是 0x2b 0x56。我也尝试过网上各种 CRC16 计算器，以及许多不同的 CRC16 计算方法，但它们都没有给出 0x06 0x5A 的结果。 Noay_0-1790003799652.png 我的假设是，要么是我漏掉了计算中必须包含的字节（我不知道是哪些，因为后面的数据包都有自己的 CRC16 字节），要么是有人把数据表搞砸了（这也不太可能，因为这个例子和 KL17 子系列参考手册中的例子一模一样）。 Re: Rom Bootloader WriteMemory Command CRC16 calculation 你好@Noay ， 感谢你的帖子。我认为参考手册中的“0x06 0x5A”值不正确，很可能是文档错误。根据您提供的信息，您的 CRC 计算结果“0x2B 0x56”看起来是正确的。 您仍然可以使用 blhost 工具来调试引导加载程序命令。参数“-d”将提供主机和目标之间的所有通信过程。 我已在我的 KL27 板上尝试了这个功能，请参见下面的屏幕截图。 我们没有 KL17 EVB 板，您能否在您的 KL17 设备上尝试相同的方法，看看结果如何？ 对于文档错误，我深表歉意。我会将此情况反馈给内部团队，并建议相应地更新文档。 BR 塞莱斯特