imx93 – UUU 串行下载器启动期间 USB 断开连接 尊敬的恩智浦团队： 我们目前正在使用 MIMX9352AVTXMAC 处理器调试我们的 i.MX93 定制板。我们的主板采用双列LPDDR4内存配置。 我们正在尝试使用 UUU（通用更新实用程序）对板载 eMMC 进行编程。该板配置为串行下载器/USB启动模式。 UUU 已正确检测到 i.MX93： uuu -lsusb 适用于 NXP imx 芯片的 uuu（通用更新实用程序）-- libuuu_1.5.243-10-g59c7638 已连接的已知 USB 设备 路径芯片专业版视频 PID BCD版本 序列号 ==================================================================== 3:1 MX93 SDPS：0x1FC9 0x014E 0x0001 我们使用以下命令对 eMMC 进行编程： sudo uuu -v -b emmc_all \ imx-boot-imx93evk-sd.bin-flash_singleboot \ image-imx93evk-20260905081644.rootfs.wic.zst UUU 检测到 i.MX93 并启动 SDPS 启动命令。然而，启动引导加载程序传输后，USB 连接立即断开。 相关的UUU日志如下： 适用于 NXP imx 芯片的 uuu（通用更新实用程序）-- libuuu_1.5.243-10-g59c7638 内置配置： PCTL芯片VID PID BCD版本 序列号 ================================================== SDPS：MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS：MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS：MX8DXL 0x1fc9 0x0147 SDPS：MX28 0x15a2 0x004f SDPS：MX815 0x1fc9 0x013e SDPS：MX865 0x1fc9 0x0146 SDPS：MX8ULP 0x1fc9 0x014a SDPS：MX8ULP 0x1fc9 0x014b SDPS：MX93 0x1fc9 0x014e SDPS：MX91 0x1fc9 0x0159 SDPS：MX95 0x1fc9 0x015d SDPS：MX95 0x1fc9 0x015c SDPS：MX943 0x1fc9 0x0027 SDPS：MX952/IMX937 0x1fc9 0x0028 SDP：MX7D 0x15a2 0x0076 SDP：MX6Q 0x15a2 0x0054 SDP：MX6D 0x15a2 0x0061 SDP：MX6SL 0x15a2 0x0063 SDP：MX6SX 0x15a2 0x0071 SDP：MX6UL 0x15a2 0x007d SDP：MX6ULL 0x15a2 0x0080 SDP：MX6SLL 0x1fc9 0x0128 SDP：MX7ULP 0x1fc9 0x0126 SDP：MXRT106X 0x1fc9 0x0135 SDP：MX8MM 0x1fc9 0x0134 SDP：MX8MQ 0x1fc9 0x012b SDPU：SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV：SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV：SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU：SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU：SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV：SPL1 0x3016 0x1001 [0x0500..0x9998] FBK：0x066f 0x9afe FBK：0x066f 0x9bff FBK：0x1fc9 0x0153 FB：0x0525 0xa4a5 FB：0x18d1 0x0d02 FB：0x3016 0x0001 FB：0x1fc9 0x0152 FB：0x0483 0x0afb FB：0x1d6b 0x0104 运行内置脚本： uuu_version 1.4.149 # @_flash.bin| 引导加载程序，可以从 WIC 镜像中提取 # @_image [_flash.bin]| 将 WIC 镜像刻录到 EMMC。 # 此命令将在 i.MX6/7、i.MX8MM、i.MX8MQ 运行时运行 SDP：boot -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # 当 ROM 支持流模式时，将运行此命令 # i.MX8QXP，i.MX8QM SDPS：boot -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # SDPU 将被弃用。请使用 SDPV 代替 SDPU # { SDPU：延迟 1000 SDPU：写入 -f imx-boot-imx93evk-sd.bin-flash_singleboot -offset 0x57c00 SDPU：跳转 -scanlimited 0x800000 # } # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # 如果（SPL 支持 SDPV） # { SDPV：延迟 1000 SDPV：写入 -f imx-boot-imx93evk-sd.bin-flash_singleboot -skipspl -scanterm -scanlimited 0x800000 SDPV：跳转 -scanlimited 0x800000 # } FB：ucmd setenv fastboot_dev mmc FB：ucmd setenv mmcdev ${emmc_dev} FB：ucmd mmc dev ${emmc_dev} FB：flash -raw2sparse all imx-boot-imx93evk-sd.bin-flash_singleboot FB：flash -scanterm -scanlimited 0x800000 bootloader imx-boot-imx93evk-sd.bin-flash_singleboot FB: ucmd 如果环境变量 emmc_ack 存在；则；否则设置环境变量 emmc_ack 为 0；结束； FB：ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB：完成 等待已知 USB 设备出现…… 新的 USB 设备已连接到 3:1-6A440AB426084436 3:1-6A440AB426084436>启动命令：SDPS：启动 -scanterm -f imx-boot-imx93evk-sd.bin-flash_singleboot -scanlimited 0x800000 3%3:1-6A440AB426084436>失败 HID(W): LIBUSB_ERROR_NO_DEVICE (-4)(0.024秒) 在发送启动命令的同时，我们还使用 dmesg 监测了 Linux USB 消息。 i.MX93 USB 设备已断开连接，然后再次枚举，请参考附件中的 dmesg 屏幕截图。 我们希望您能就以下问题提供指导： 在使用 UUU 时，i.MX93 SDPS 引导加载程序切换过程中是否预期会出现 USB 断开/重新枚举的情况？ 在这种特定情况下，以下错误表明了什么？HID(W) 失败：LIBUSB_ERROR_NO_DEVICE (-4) 在 SDPS 到 SPL/U-Boot 的切换过程中，以下信号是否有任何特殊要求，我们需要在定制板上进行验证？ POR_B RESET_b USB_VBUS USB_DP/DM 处理器电源轨 LPDDR4 电源轨 系统/参考时钟   能否提供采用双列 LPDDR4 内存配置的 i.MX93 MIMX9352AVTXMAC 的参考设计或软件/启动配置示例？具体来说，我们希望确认双列内存设计中推荐的 LPDDR4 设备配置、内存初始化/训练配置以及相应的 IMX_BOOT/SPL 配置。 我们希望您能就上述问题提供指导，并请您提供双列 LPDDR4 配置的相关细节、推荐配置和参考设计/代码。 谢谢 & 此致敬礼， 阿比舍克 Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@pengyong_zhang ， 请参考附件中的 LPDDR4 原理图和配置 .mex 文件。供您参考。 此致， 阿比舍克 Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@AbishekDevan 1.这并非预期行为。 2. 此错误是由于设备在刷机过程中断开连接造成的。请分享客户的DDR原理图文件和配置页面。 B.R Re: imx93 – USB Disconnect During UUU Serial Downloader Boot 嗨@AbishekDevan 我无法导入您的 .mex 文件。文件已成功提交。请分享一下您的DDR配置页面截图。 B.R

KE18F512VLH16 ECC RAM 单比特纠错 我有一个与@sean_dvorscak前几天的帖子（ KE1 ECC RAM 单比特纠错）相关的后续问题。 @Celeste_Liu回复道： 如果要实现可选的清理功能，请根据实际访问大小或清理粒度来对齐访问，而不是盲目地依赖原始的 MCM_LMFAR 值。此外，除非您已正确对齐地址并确认访问大小有效，否则请勿使用固定的 4 字节访问。 MCM_LMFATR[PEFSIZE] 能否用于确定访问大小？如果可以，能否将其与 MCM_LMFAR 结合使用，以实现读取-正确-写回操作？例如，如果 MCM_LMFATR[PEFSIZE] 为 3'b000，表示 8 位访问，我能否从 MCM_LMFAR 指示的地址执行 8 位读取，然后对同一地址执行 8 位写入以纠正错误？同样地，如果 MCM_LMFATR[PEFSIZE] 为 3'b010，表示 32 位访问，我是否可以对 MCM_LMFAR 指示的地址执行 32 位写入，而无需担心对齐问题？ Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 我已看过你的帖子。我需要一些时间来调查这个问题，一旦有更多信息，我会尽快回复您。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction 嗨@Celeste_Liu - P7 是最终应用程序的名称。 Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 关于您的问题，我需要将其上报给内部团队进行进一步调查。根据我们的流程，请提供最终应用程序名称。 谢谢您的合作。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction @Celeste_Liu你好，请问这件事有任何进展吗？ Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 抱歉，我还没有收到内部回复。 我会再次跟进此事，并将其作为我的首要任务。一旦收到回复，我会立即通知你。 BR 塞莱斯特 Re: KE18F512VLH16 ECC RAM Single Bit Correction 感谢@Celeste_Liu的回复，但这并没有回答我关于MCM_LMFATR[PEFSIZE] 的问题： “ MCM_LMFATR[PEFSIZE] 能否用于确定访问大小？如果可以，能否将其与 MCM_LMFAR 结合使用，实现读取-纠错-写回操作？例如，如果 MCM_LMFATR[PEFSIZE] 为 3'b000，表示 8 位访问，我能否先从 MCM_LMFAR 指示的地址读取 8 位数据，然后再向同一地址写入 8 位数据以纠正错误？类似地，如果 MCM_LMFATR[PEFSIZE] 为 3'b010，表示 32 位访问，我能否直接向 MCM_LMFAR 指示的地址写入 32 位数据而无需考虑对齐问题？” Re: KE18F512VLH16 ECC RAM Single Bit Correction 你好@rseigle77 ， 感谢您的耐心等待。我收到了内部回复。 ECC“纠错”是指将纠正后的数据返回给CPU，而不是修复存储在SRAM中的底层位。自动修复需要单独的擦除/回写机制。 使用软件清理的推荐流程： ECC在读取时纠正数据。 引发单比特错误中断/状态。请参阅 RM 6.3.1.1确定中断源。MCM_LMPECR [ER1BR] =1 软件读取故障地址。MCM_LMPEIR [PEELOC] = 5'h08 - 来自 SRAM_L 的 1 位可纠正 ECC 事件，MCM_LMFAR 指示故障地址。 软件会将更正后的值写回原地址。 生成并存储新的 ECC 综合征。 BR 塞莱斯特

Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi NXP,       Can LPC55S0x support 1Mbps in arbitration stage and 8Mbps in data stage ?       I can't find in LPC55S0x datasheet.      Thanks very much. LPC55xx Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi Harry,       Got it.       Thanks. Re: Can LPC55S0x CANFD support 1Mbps (arbitartion stage) and 8Mbps(data stage) Hi @jimmyli  Yes— the LPC55S0x CAN-FD controller can be configured for 1 Mbit/s arbitration and 8 Mbit/s data , provided the MCAN functional clock is 96 MHz and the external CAN-FD transceiver and physical network support 8 Mbit/s. The reason this is not listed directly in the datasheet is that the bit rates are derived from the MCAN clock and the NBTP / DBTP timing registers rather than specified as a fixed maximum. The CAN clock can use main_clk with CANCLKDIV = 0 (divide-by-1), and the LPC55S0x maximum clock frequency is 96 MHz. BR Harry

AT&Tの担当者と直接話すにはどうすればよいですか？ 自動音声メニューにうんざりして、実際に人と話したいと思いませんか？AT&T カスタマーサポートチーム (米国)

运行 OpenGL 程序时出现多次 GPU 崩溃/无效输出 您好， 三年多来，我们一直在销售基于 i.MX6QuadPlus 的设备，该设备基于 Yocto hardknott 构建，并搭载了基于 Weston 的 Qt 6.3.2。随着产品的发展，我们开始收到越来越多的用户崩溃报告，但我们在自己的代码或 Qt 中都找不到原因。我们已经修复了一些问题——通过重新调整 DDR 时序、禁用某些视图中的阴影、增加一些内部缓冲大小以及使用 GPU_VIV_EXT_RESOLVE=0 运行应用程序——但我们仍然会收到报告，其中很大一部分与 GPU 相关，并在日志中显示如下： 内核：*** GPU DRV 配置 *** 内核：Galcore 版本 6.4.3.336687 内核：Galcore 选项： ... 内核: [galcore]: 停止驱动程序以保持场景。 这是驱动程序自身的挂起报告——监测计时器未见任何进展，gckKERNEL_Recovery 转储 GPU 状态，并且由于 recovery=0，驱动程序停止服务而不是重置核心（recovery=1 对我们来说不是一个选项，因为需要重新启动每个 GUI 应用程序）。屏幕彻底冻结，即使使用 SIGKILL 也无法杀死 Weston，唯一的解决办法是断电——这对我们的客户来说非常糟糕。 由于我们已经在 Qt 和应用程序层面尝试了很多方法，但都只得到了变通方案，所以我决定停止测试高级功能，而是直接测试 OpenGL ES 入口点——如果它们运行正常，那就是我们的问题；如果它们运行不正常，那就是驱动程序/硬件的问题（至少是部分问题）。 我使用 VK-GL-CTS（ https://github.com/KhronosGroup/VK-GL-CTS ）实现了这一点。首先移植到 Rust 以便于交叉编译（仍在进行中，因此目前只能检查大约一半的相关情况）。案例名称与上游 deqp-gles2/gles3/gles31 相同，并且在 Mesa llvmpipe 和运行 Ubuntu 24.04 的普通笔记本电脑上，所有测试均通过，并且也安装了 mesa 驱动程序，因此板上的失败说明板存在问题。我利用周末时间在硬件上运行了它，并在人工智能的帮助下，找到了 14 个不同的缺陷并将其最小化，每个缺陷现在都可以独立复现：一个没有任何依赖项的纯 Rust 项目，仅使用 cargo build 构建，GLSL 代码放在单独的文件中。 （只需运行- 在本地运行，您可以提取仅 arm部分，只需构建步骤即可收集二进制文件（您需要先安装cargo install --locked cargo-zigbuild ）） 6.4.11.p4 版本（我们能为该部件构建的最新驱动程序）仍然存在问题： 0001 GPU 锁死 - synchronization.inter_invocation.ssbo_atomic_read_write，独自一人，站在一块刚启动的板上。只有重启才能清除它，而且该进程无法终止，因此重启本身需要 8-10 分钟。 0002 GPU 锁定 - synchronization.inter_invocation.ssbo_atomic_overwrite，单独发生。 0003 GPU 锁死 - 二十个 synchronization.inter_invocation.* 中的十个个别案例单独存在，其他十个案例则不存在，因此这是一个边界，而不是“计算出错”。所有原子 ssbo/图像变体。所有二十台设备都进行了十次运行，每次运行都是从它自己的重启开始。 0010 链路故障 - 7 个 ubo 案例，其中两个阶段读取了同一个 std140 块的 47 个成员。单独一个阶段可以连接，但两个阶段一起连接则不行，glGetProgramInfoLog 为空，并且没有任何东西接近驱动程序本身报告的限制（每个阶段 3 个块 vs 16 个，704 字节 vs 65536）。至少需要 47 次阅读，46 个链接。 0011 结果错误 - shaders.invariance.highp.loop_*:两个着色器使用相同的表达式计算不变的 gl_Position，结果相差几个像素的深度。 0013 错误状态枚举 - fbo.completeness.size.distinct：请求的上下文是 ES 2.0，但报告的是 ES 3.1，然后根据 ES 2.0 规则回答完整性问题，并返回一个 ES 3.x 未定义的枚举。 已在 6.4.3.p2 版本中修复-> 6.4.11.p4 跳转： 0004 GPU 死锁 - image_load_store.cube.qualifiers.*_r32f（旁边的 r32ui/r32i 型号都没问题） 0006 GPU 锁死 - image_load_store.* 每当图像分层时都会发生，21 层中有 8 层发生，而 2D 图像上 7 层中没有发生，间歇性发生 0005 客户端冻结 - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange 永远不会返回 0014 客户端冻结 - 同样，通过 upload_buffer.empty_command 命令实现。一旦调度任务已经完成映射 0007 结果错误 - 计算着色器中包含十八个 && 的链，并且声明了一个原子计数器，当每个项都为真时，结果为假（2007 个 ssbo.layout 案例中的 44 个） 0008 编译器 - 保留字表适用于错误的语言版本，正反两面都是如此。 0009 结果错误 - 对于两个相等的向量，vec3 == vec3 为 false，这是通过 inout 参数返回的结构体成员的结果。 0012 编译器 - mediump vec2(1.0,1.0) 可以编译，其中 ESSL 1.00 语法中没有精度限定符的位置。 两次测试均在同一块主板上进行：i.MX6QP 硅 rev 1.0，2 GiB DDR，LVDS 1280x1024@60，Weston on fbdev with use-g2d=1，GL_RENDERER "Vivante GC2000+"。 旧版本：hardknott，BSP imx-5.10.52-2.1.0，内核版本 5.10.52galcore 6.4.3.p2.336687，imx-gpu-viv 1:6.4.3.p2.2-aarch32，Weston 9.0.0.imx，Qt 6.3.2 新增：wrynose，BSP imx-6.18.20-2.0.0，内核 6.18.20，galcore 6.4.11.p4.1190909，imx-gpu-viv 1:6.4.11.p4.6-aarch32Weston 10.0.5.imx，Qt 6.11.0 CONFIG_MXC_GPU_VIV=y，recovery=0 和 stuckDump=0 在两者上；超时时间为 20000 -> 30000 毫秒，并且 6.4.11.p4 添加了 softReset=1。 所以版本升级有所帮助，但一些问题仍然存在。由于 i.MX6 的供货情况，我们将很快迁移到 i.MX8，但我们现有的用户群无论如何都会继续使用 i.MX6 硬件，因此我们希望这些问题在未来能够得到解决。 这些问题有没有可能在新版本的驱动程序中得到修复，即使这意味着我们需要升级 Yocto 版本？ 我担心 i.MX8 也可能存在某种程度的此类问题，那么是否已经对 Vulkan/OpenGL CTS 进行过测试，现在是否正在进行测试，或者是否有计划进行测试？因为如果不通过那项测试（再加上一些模糊测试，例如随机执行cts函数），我认为我们遇到的随机崩溃问题无法在驱动程序之上的层级中得到修复。 Re: Several gpu crashes/invalid output, when running opengl es cts 你好， i.MX 6/7 的最新公开发布驱动程序是 imx-gpu-viv 6.4.11.p4.6 ，随附 wrynose 电路板支持包 (imx-6.18.20-2.0.0)。发行说明将此次升级描述为对 i.MX 6/7/8 系列进行了“错误修复和性能优化”，这与您的观察结果相符，即 .p2 和 .p4 之间解决了 14 个缺陷中的 8 个。是的，这确实正在发生——但各个平台都有一些重要的限制条件。对于配备 Vivante (VSI) GPU 的 i.MX8，CTS 正在运行。作为每个版本候选周期的一部分，内部 Linux Factory 测试流程都会针对 i.MX8 板运行 opengl-es-cts 和 vulkan-cts 软件包。在 Linux Factory Jira 项目 CTS 中跟踪在 i.MX8M Nano、i.MX95 上发现的缺陷。这意味着 i.MX8M Plus、i.MX8QuadMax 等产品中的 Vivante GC7000 系列 GPU 在每次正式版本前都会经过系统的符合性测试。 适用于配备 Mali / OSS Mesa 的 i.MX9 版本说明明确指出，对于采用 Mesa OSS GPU 堆栈的 i.MX 95/952：“OpenGL ES11、Vulkan 1.4.5 和 OpenCL 3.0 的基本功能可以正常工作，但一致性测试未通过。” 这i.MX9 上的 Mali DDK 默认路径通过了 CTS 测试，但开源 Panfrost/PanVK 路径仍在努力使其符合标准。 特别是对于 i.MX6 (GC2000+) 而言，CTS 的覆盖范围非常有限。 在当前的 Linux Factory 流水线中，没有发现针对 GC2000+ 的系统性 deqp/CTS 运行的内部证据。GC2000+ 仅支持 OpenGL ES 3.0（不支持 3.1/3.2）。测试基础设施似乎针对的是较新的 i.MX8/9 板。您与 VK-GL-CTS 的合作是对该特定 IP 进行的最彻底的一致性级别测试，在任何内部渠道中都是可见的。   总之：虽然不能保证未来会发布 i.MX6 驱动程序补丁，但通过您开放的支持帖子提供独立的重现步骤才是正确的做法。对于您的 i.MX8 迁移，Vivante GC7000 系列的兼容性情况比 GC2000+ 要好得多，并且系统性的 CTS 测试是发布过程的一部分——尽管即便如此， galcore 6.4.11.p4 中的活跃驱动程序错误仍然不断被发现和提交。   此致 Re: Several gpu crashes/invalid output, when running opengl es cts 我没看到附件，看来是我忘记添加了，所以我再添加一次。

NX20P0477UKZを使用した水分検出 こんにちは、チームの皆さん、 当社は、部品番号NX20P0477UKZを使用したカスタム基板を開発しました。水分検知機能は搭載しておりません。 私たちの設計では、携帯電話を接続するために1.5メートルのケーブルを使用しています。つまり、ケーブルの片端はカスタムボードで接続され、もう片方はモバイル接続のために外部に露出しています。 外部に曝露されたケーブルからの湿気を検出しようとすると、水分を検知できません。この問題を解決するための方法をご教示ください。 よろしくお願いします。 Re: Moisture detection using NX20P0477UKZ こんにちは、カダム 良い一日！ このNX20P0477は、デバイスが接続されていない状態で動作することを想定しており、主な目的は事前にFLAGBを主張することで湿気条件下での接続を防ぐことです。 ケーブルや機器が接続されると(モバイル電話はケーブルを介して接続されます)、CCラインの電気的条件はより複雑になり、水の存在とアクティブな接続が組み合わさると予測不能な挙動を引き起こします。したがって、これらの条件下では装置は水分イベント情報を確実に識別または検出できません。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: Moisture detection using NX20P0477UKZ こんにちは、ラファール。 迅速なご対応ありがとうございます。 私たちは、いかなる機器も接続せずにテストを実施しています。私たちのアプリケーションでは、ケーブルの片方を搭載タイプCコネクタに接続し、もう一方の端は開いたままにしています。ケーブルの開いた端を水に浸していますが、フラッグピン(C1)は常に高さにあり、湿気を検出できません。 水分を検出するために、CP_EN(B2)ピンをハイレベルに設定しています。 機能の検証方法を教えていただけますか? よろしくお願いします。

关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug 我使用的GUI Guider版本是2.0.0。当我为Top Layer添加事件时，生成的gg_event_layer_top.c中关于Top Layer的事件回调函数名会异常，目前的情况是，事件回调函数名的中间会被插入一对括号，就像这样“ static void lv_layer_top () _event_handler ( lv_event_t * e ）”。事实上，对于Bottom Layer也存在相同的问题，而Screens则未出现类似的问题。希望能尽快修复bug。谢谢！ 回复： 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug Hi @UENG , 感谢您的反馈，该问题已经在V2.0.1中修复，请下载安装该版本：GUI Guider Best Regards, Wenbin

i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi Team, We are currently working on importing a private key to an i.MX95 device following the guidelines in application note AN14898. Environment & References: Target Device: i.MX95 Demo Application: imx_sec_apps/imx-ele-apps SPSDK Version: Latest standard toolset Activities Completed So Far: Installed Python, pip, and the SPSDK toolset. Successfully built both the Host and Device applications. Copied device/bin/ele_key_import and device/scripts/run_test_on_board.sh to our target i.MX95 hardware. Executed the device-side flow to generate nxp_prod_ka_puk.bin. Transferred nxp_prod_ka_puk.bin back to our host environment. Generated SRK keys (secp384r1) using the SPSDK utility according to the SPSDK Documentation since we do not have final production keys yet. Generated the signed_msg.bin on the host side using the standard key import template (with the -k parameter set to secp384r1). Transferred the generated signed_msg.bin to the i.MX95 hardware. Command used to generate signed message: nxpimage signed-msg export -c key_exchange_temp.yaml -w assets Attached key_exchange_temp.yaml for reference. When running run_test_on_board.sh on the i.MX95 target device, all files are found, but the EdgeLock Enclave rejects the signature on the signed message block.Here is our target terminal log: nxp_prod_ka_puk.bin exists. oem_public_key.pem exists. signed_msg.bin exists. Hello, World! Jul 16 2026:06:54:40 9547bbd Signed Message: 728 bytes 02d802890200000000000000b8000000000000000000000000000000000000000000000000000000000000000000000000000000e6a7000000004701000000000000000000000000000000004707000000454c45090102090000000000920001010000000040000009010008000000000100000000000070577819deccdf2670d801e8f4291d3539081da49b1e1b63d55039e5993242b30f0000000000000000000000000000000000000000000000000000000000000000011c029000001000b40100000000000000a4015a01000000d7340143e14c00270102000030003000c2a99777d1fc00dc7e14d3d43ac3f68a44d9b52c882d3c09eac0db7fac1901242576bac6143785e5815db546e385d81000000000000000000000000000000000e14c00270102000030003000e358e1159c0cb645e7059c1b04b49e39b3563167472507278245d4dee439dd32e7ce3da413e397cbd7959cf147d25c2300000000000000000000000000000000e14c00270102000030003000482fb4f1ceb6e266221b0a13dbbb04c637a1c238b76b108397e98eb4557cafb2075036e05b9a0ee4fa6aa09a5f3951e500000000000000000000000000000000e14c00270102000030003000c93a6b4881ae912da31da8249e4f58473eb88cc1dc46f5ec6d363dc52b8a5c12c91e711ad726153d382dabbe6bef27cc000000000000000000000000000000000068005d00000000a5e31e11bfb02c62756d9d3ba5152768e5bea9aab8f3f13ccf3bd287a0438e9708088cafc5671e2aaf1bc3b413457b6a59a691dcef672fa65dac12ed328effac963c41ec0200b0a9acf67e0f2755f752872f77d2c20d6987f80e8008ac26de3d006800d800000000f4cf9cc965b3643d5dc5c5070a506196649daf898d328afd18e88eb9ece96e39646bf6385b9d42e1fc2f93f07f66e9c8c914becef9394c0c3cf549766483c7f94b6a9325bea51b79280eb76484e064637570c0ef7387ec0ffb8398ec36966c3a00000000 OEM Import PUK: 65 bytes 0451c46d24d30864c5275c634a3a339949654b34c0a4f294a8c107c504360ff4b55044918b71b16109a7bbfba8fbcf49b91720ad8e9c0109e6b2eed8f6a504ab64 hsm_open_session success hsm_open_key_store_service success hsm_open_key_management_service success SAB Error: SAB CMD [0x47] Resp [0x1829] - Invalid Signature in SIGNED message. hsm_key_exchange failed err:0xfe Key exchange failed: 254 Any insight on resolving this signature verification issue for the i.MX95 would be greatly appreciated. Thanks, Ankit Agrawal Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Ankit_Agrawal  I am wondering if you burn SRKH  after SRK generation.  for necessary sign.yaml file please check my attached file.  Please try below command (precondition is you should have flash.bin: bootloader of system) to generate SRKH.   nxpimage ahab sign -c sign.yaml -b flash.bin -o flash_directsign.bin -fs outputs output will be as below. Jessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.pngJessie_Lee_0-1786699088609.png and from the ouputs folder, you could see bcf file(ahab_oem0_srk0_hash_nxpele.bcf).  you could follow below fuse command  (index 128 ~143) that you need to fuse for SRKH.  # nxpele AHAB SRKH fuses programming script # Generated by SPSDK 3.4.0 # Family: mimx9596, Revision: latest # Value: 0xCCC0605919B6400771CF88A002FB6BF27DFA9CE09BAD94516DD7E4D399369A8FF5A6A1A671809DF4A71A7CB208B4EDC009CDF3FF25EC074DECBBEE8300D5D44C # Description: SHA512 hash digest of hash of four SRK keys # Grouped register name: SRKH # OTP ID: OEM_SRKH0, Value: 0x5960C0CC write-fuse --index 128 --data 0x5960C0CC # OTP ID: OEM_SRKH1, Value: 0x0740B619 write-fuse --index 129 --data 0x740B619 # OTP ID: OEM_SRKH2, Value: 0xA088CF71 write-fuse --index 130 --data 0xA088CF71 # OTP ID: OEM_SRKH3, Value: 0xF26BFB02 write-fuse --index 131 --data 0xF26BFB02 # OTP ID: OEM_SRKH4, Value: 0xE09CFA7D write-fuse --index 132 --data 0xE09CFA7D # OTP ID: OEM_SRKH5, Value: 0x5194AD9B write-fuse --index 133 --data 0x5194AD9B # OTP ID: OEM_SRKH6, Value: 0xD3E4D76D write-fuse --index 134 --data 0xD3E4D76D # OTP ID: OEM_SRKH7, Value: 0x8F9A3699 write-fuse --index 135 --data 0x8F9A3699 # OTP ID: OEM_SRKH8, Value: 0xA6A1A6F5 write-fuse --index 136 --data 0xA6A1A6F5 # OTP ID: OEM_SRKH9, Value: 0xF49D8071 write-fuse --index 137 --data 0xF49D8071 # OTP ID: OEM_SRKH10, Value: 0xB27C1AA7 write-fuse --index 138 --data 0xB27C1AA7 # OTP ID: OEM_SRKH11, Value: 0xC0EDB408 write-fuse --index 139 --data 0xC0EDB408 # OTP ID: OEM_SRKH12, Value: 0xFFF3CD09 write-fuse --index 140 --data 0xFFF3CD09 # OTP ID: OEM_SRKH13, Value: 0x4D07EC25 write-fuse --index 141 --data 0x4D07EC25 # OTP ID: OEM_SRKH14, Value: 0x83EEBBEC write-fuse --index 142 --data 0x83EEBBEC # OTP ID: OEM_SRKH15, Value: 0x4CD4D500 write-fuse --index 143 --data 0x4CD4D500 you could use below command to burn SRKH nxpele -f mimx9596 batch outputs\ahab_oem0_srk0_hash_nxpele.bcf If you burn the SRKH already but failed with below invalid singing, please share the singed_message.bin to us.  with your SRKH (including srk output all).  Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hello @Ankit_Agrawal, Our internal team is reviewing your issue and will update you accordingly. In the meantime, please review the case below, which is similar to the issue you are encountering. The suggested solution is to verify that the fuse_version matches correctly. https://community.nxp.com/t5/i-MX-Processors/hsm-import-key-returns-with-0xF0-Bad-Signature/td-p/2163777 Thank you. Best Regards, Richard Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Jessie_Lee , Thanks for the information. We have located the flash.bin file and are able to perform the necessary steps to generate the SRKH. After generating the SRKH, we need to fuse it to the hardware. To perform the fuse operation, the hardware/board must be in Fastboot mode. Could you please help us switch the device to Fastboot mode? While attempting to fuse the keys, we are encountering the following error: Ankit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.pngAnkit_Agrawal_0-1787636692485.png It appears that the device is not currently in Fastboot mode. Any guidance on how to enable Fastboot mode on the board would be greatly appreciated. Thanks,  Ankit Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Ankit_Agrawal  Please follow up below steps to burn SRK using SPSDK step#1. when you boot device, stop at u-boot console , run  u-boot=> fastboot 0 step#2.  In SPSDK console , you must there is no ahab events) using below command. nxpele -f mimx9596 get-events  step#3. If there is no event,  you could burn SRK key now in SPSDK console. nxpele -f mimx9596 batch outputs\ahab_oem2_srk0_hash_nxpele.bcf BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) @Jessie_Lee  It is reported that things are not working as shown below. Is it possible to get some support? -------------------------------------------------------------------------------------------------------------- However, when I execute the command to perform the fuse operation, I encounter the error below. I tried resetting the hardware too, but I'm still facing the same issue. Do you have any ideas on why this might be happening? rakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.pngrakhyoung_0-1789101296622.png @Ankit_Agrawal  Feel free to provide additional explanation if necessary. Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) from @Ankit_Agrawal  , there was fastboot entering issue.  @rakhyoung  Do you mean you are also having issue to enter fastboot ? did you try to  below command..? that I shared.. above?  what is error when you try to below fastboot 0 at uboot stage?  step#1. when you boot device, stop at u-boot console , run  u-boot=> fastboot 0 BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hello @Jessie_Lee  Sorry for the delayed response. I successfully managed to stop at the U-Boot console on the device side. However, when trying to fuse the key from the host side using the following command: nxpele -f mimx9596 -p /dev/ttyUSB1 batch outputs/ahab_oem2_srk0_hash_nxpele.bcf I encountered the following error: Screenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.pngScreenshot from 2026-09-13 21-29-30.png I tried resetting the hardware too, but I'm still facing the same issue. Do you have any ideas on why this might be happening? Thanks, Ankit Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hello @Jessie_Lee , Please find attached logs for the fastboot entry, the host-side steps to check events and fuses, and the debug log file. Thanks, Ankit Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) HI @Ankit_Agrawal  From your attached log, I could not find A core's uboot console log. (target board) when you enter fastboot on uboot console,   Could you please check this? Please share full uboot log from POR  it seems that SPSDK detect uboot console by "=>" character.  What's your boot delay value(check by uboot command "printenv bootdelay")? Or can you add the bootdelay with uboot command "setenv bootdelay 3; saveenv" and try again? BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) HI @Ankit_Agrawal  Could you please share all step log from fastboot entering at uboot (console), execute spsdk by host side? I believe you entered fastboot thru uboot. right? please share all steps (fastboot entering, ahab event check , try to fuse.. etc on host side log). It would be helpful to see all logs thru files not snapshot.  BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hello @Jessie_Lee , Please find the attached logs. I have performed the steps as suggested by you. Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Ankit_Agrawal  I am wondering if you check your uboot log for fastboot entering . Below is part of your log  and it show "unknown command" log. this fastboot is u-boot community feature which NXP's BSP also has but not in your SW env.  You need to discuss with your BSP team if BSP team remove this function.  BTW, NXP shared Updated ELE/V2X FW recently but your FW seems to be not latest.  Please discuss with your security internal team to sync up the FW version.  (btw, this FW version is not related with fastboot feature enablement or not)  Jessie_Lee_0-1789613044617.pngJessie_Lee_0-1789613044617.png BRs jessie BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Ankit_Agrawal  I checked with your BSP team and fastboot is removed from default u-boot. So, you could not use fastboot mode directly to fuse SRK. Instead of SPSDK tool for burning SRK, you could use one of below method. As I know your team already use fuse_access application to handle fuse access (read/write) at kernel level.  any method could be okay to burn your srk.   Jessie_Lee_0-1789713874158.png BRs jessie Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Jessie_Lee , Thank you very much for your continued guidance and support as we navigate our integration. We reviewed the proposed procedure and steps for the i.MX95 Secure Enclave, but because the suggested methods require pre-build or static configuration, they will not be feasible for our current architecture. Our implementation strictly requires provisioning and managing keys at run time. Could you let us know if there is an alternative approach or a dedicated Runtime Import Key API available to meet our requirements? For context, the Import Key API is mandatory for our implementation due to two specific use cases: Runtime Certificate Installation: During the flow, the application receives an encrypted contract certificate and private key. After decrypting this on the application side, the private key must be dynamically imported or stored into the Secure environment at run time. Testing and Validation: For our current development and verification phase, we need to inject existing, pre-generated test keys (such as Contract Certificates, and Root Certificate keys) into the application-side Secure environment to validate the end-to-end communication flow and message signatures. We would appreciate your insights on how we can achieve this dynamic injection without a pre-build setup cycle. Best Regards, Ankit       Re: i.MX95: EdgeLock Enclave Key Import Error - SAB CMD [0x47] Resp [0x1829] (Invalid Signature) Hi @Ankit_Agrawal  To move further about the way of key import feature, May I ask your current status? Does it work on your side now with our current method?  To review your request for changing the way of key import feature , we need to understand firstly Other end side environment.  could you help us to understand your side situation ?  We need to understand "end to end protection" is secure enough For example,    * How other end generate this encrypted contract certificate and private key? * Or How the encrypted key of the blob is generated in LG/GM side?  * Could you please provide GM spec or GM spec numbers on this part?  then we can understand your concept and discuss with our security core team to support such way.   BRs Jessie 

OpenGL es ctsを実行しているときに、いくつかのGPUがクラッシュしたり無効な出力が出たりします こんにちは、 3年以上にわたり、私たちはi.MX6QuadPlusでデバイスを出荷してきました。これはYocto hardknott上で構築され、WestonのQt 6.3.2で構築されています。製品が成長するにつれて、ユーザーからクラッシュ報告が増え、自分たちのコードやQtの中に原因が見つかりませんでした。一部は修正できました。DDRのタイミングを調整したり、特定のビューでシャドウを無効にしたり、内部バッファのサイズを増やしたり、アプリをGPU_VIV_EXT_RESOLVE=0で動かしたりしましたが、それでもレポートは届き、その多くはGPU関連でログに次のように表示されます。 カーネル: *** GPU DRV 設定 *** カーネル:Galcore バージョン 6.4.3.336687 カーネル:Galcoreオプション: ... カーネル:[galcore]: シーンを保つためにドライバを止めてください。 これはドライバ自身のハングレポートで、モニタータイマーは進行状況を認識せず、GPUの状態をダンプgckKERNEL_Recovery、recovery=0なのでドライバはコアをリセットせずサービスを停止します(recovery=1は私たちには選択肢にありません。なぜなら、すべてのGUIアプリケーションを再起動する必要があるからです)。画面は完全にフリーズし、ウェストンはSIGKILLを使っても倒せないことが多く、唯一の脱出方法は停電で、これはお客様にとって非常に悪いことです。 Qtやアプリケーションレベルで多くのことを試しましたが、回避策しか得られなかったため、高レベルの機能テストをやめ、OpenGL ESのエントリポイントを直接テストすることにしました。正常に動作すれば問題は私たちの責任、そうでなければドライバやハードウェアの故障(少なくとも部分的)です。 私はVK-GL-CTS（ https://github.com/KhronosGroup/VK-GL-CTS ）を使ってそれをやりました。クロスコンパイルを簡単にするために最初はRustに移植されました(まだ進行中で、関連するケースの約半分しか確認できませんでした)。ケース名は上流のdeqp-gles2/gles3/gles31と同じで、Mesa llvmpipeやUbuntu 24.04のカジュアルノートPC(Mesaドライバー付き)でもすべてパスされます。つまり、ボードの故障はボード自体の問題です。週末にハードウェア上で実行したところ、AIの助けを借りて14個の異なる欠陥を発見し、最小限に抑えることができました。それぞれが独立した再現可能なコードになっています。具体的には、依存関係のないシンプルなRustプロジェクト、cargoビルドのみ、そしてGLSLを独自のファイルに記述したものです。 (JUst Run - ローカルで実行、 Armパーツだけ を抽出して、ビルドステップのみでバイナリを集められます(最初の カーゴインストールが必要で、ロックされたカーゴ・ジグビルド) この部分のために構築可能な最新ドライバー、6.4.11.p4で依然として問題が残っています: 0001 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_read_write,一人きり、新しく履き替えたばかりのボードの上で。再起動しないとクリアできませんし、プロセス自体は壊せないので8〜10分かかります。 0002 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_overwrite、単体で。 0003 GPUのロックアップ - 20 synchronization.inter_invocation中10件。*ケースは単独で起こるが、他の10個はそうではないため、これは境界であり「計算が壊れている」とは言えない。すべての原子SSBO/イメージのバリアント。20人全員がそれぞれ10回のレースを制覇し、すべてのレースはリブート版から始まった。 0010リンク障害 - 同じstd140ブロックの47個のメンバーが両段階で読み取れた7件のUBOケース。どちらのステージだけでもリンクしますが、一緒にはリンクしません。glGetProgramInfoLogは空で、ドライバー自体が報告する制限(ステージあたり3ブロック対16ブロック、704バイト対65536バイト)はほとんどありません。最低でも47回の閲覧と46のリンクが必要です。 0011 結果が間違っています - shaders.invariance.highp.loop_*:同じ式から不変なgl_Positionを計算する2つのシェーダーが、深度に関して数ピクセルの差を生じます。 0013 ステータス列挙型が間違っています - fbo.completeness.size.distinct: ES 2.0 として要求されたコンテキストが ES 3.1 を報告し、その後 ES 2.0 ルールで完全性に応答し、ES 3.x で定義されていない列挙型を返します。 6.4.3.p2で修正済み-> 6.4.11.p4 ジャンプ: 0004 GPUロックアップ - image_load_store.cube.qualifiers.*_r32f（隣にあったr32ui/r32iは問題なかった） 0006 GPUのロックアップ - image_load_store.* 画像がレイヤー化されるたびに、21枚中8枚、2Dでは7枚中0枚、断続的です 0005 クライアントフリーズ - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange は決して戻りません 0014 クライアントフリーズ - upload_buffer.empty_command 経由、同じ一度、配車がすでにマッピングされている場合 0007 誤った結果 - 18 &&の連鎖で、原子カウンタも宣言される場合、すべての項が真である場合にfalseになります(2007年のssbo.layoutケース中44件) 0008 コンパイラ - 保留ワードテーブルは間違った言語バージョン用、両方向に適用されます 0009 誤った結果 - 入力パラメータを介して返される構造体メンバーに対して、2 つの等しいベクトルに対して vec3 == vec3 が false になります 0012 コンパイラ - mediump vec2(1.0,1.0) コンパイルは成功するが、ESSL 1.00 文法には精度修飾子を入れる場所がない。 両方のテストは同じボードで行いました：i.MX6QPシリコンリビジョン1.0、2 GiB DDR、LVDS 1280x1024@60、fbdev上のWeston、use-g2d=1、GL_RENDERER "Vivante GC2000+"。 古い: hardknott、BSP imx-5.10.52-2.1.0、カーネル 5.10.52、Galcore 6.4.3.p2.336687、IMX-GPU-VIV 1:6.4.3.p2.2-aarch32,Weston 9.0.0.imx、Qt 6.3.2 new: wrynose、BSP imx-6.18.20-2.0.0、kernel 6.18.20、galcore 6.4.11.p4.1190909、imx-gpu-viv 1:6.4.11.p4.6-aarch32,Weston 10.0.5.imx、Qt 6.11.0 CONFIG_MXC_GPU_VIV=y、recovery=0、stuckDump=0 の両方でタイムアウトが発生し、20000 -> 30000 ms となり、6.4.11.p4 で softReset=1 が追加されました。 バージョンアップは助けになりますが、いくつかの問題は残っています。i.MX6の入手可能性のため、近いうちにi.MX8に移行する予定ですが、既存の基盤はいずれにせよi.MX6のハードウェアを保持しているので、将来的にこうした問題が解決されるのを見たいです たとえYocto版をやめざるを得なくても、新しいドライバーでこれらの問題が修正される可能性はありますか? この問題はi.MX8にもある程度存在しているのではないかと懸念していますが、Vulkan/OpenGL CTSでテストは行われていますか?現在行われているのか、それとも計画されているのでしょうか?それを通さなければ(さらにcts関数のランダム実行などのファズ処理も)、ドライバーの上層でランダムクラッシュは修正できないと思います Re: Several gpu crashes/invalid output, when running opengl es cts こんにちは、 i.MX 6/7の最新公開ドライバーは imx-gpu-viv 6.4.11.p4.6 で、wrynose BSP(imx-6.18.20-2.0.0)が付属しています。リリースノートでは、そのジャンプが i.MX 6/7/8ラインの「バグ修正、パフォーマンス最適化」をもたらしたと説明されており、これはあなたの観察と一致しています。 .p2 と .p4 の間に14の欠陥のうち8つが解決されたという点です。そして確かに、それは行われていますが、プラットフォームごとに重要な条件があります。Vivante(VSI)GPU搭載のi.MX8では、CTSが動作しています。Linux Factory内部のテストパイプラインでは、各リリース候補サイクルの一環として、i.MX8ボードに対して opengl-es-cts および vulkan-cts パッケージの両方を実行させます。発見された欠陥は、Linux Factory JiraプロジェクトCTSのi.MX8M Nano、i.MX95上で追跡されています。これは、i.MX8M Plus、i.MX8QuadMaxなどに搭載されているVivante GC7000シリーズGPUは、各GAリリース前に体系的な適合性テストを受けていることを意味します。 i.MX9（Mali / OSS Mesa搭載）向け リリースノートには、Mesa OSS GPUスタック搭載 i.MX 95/952について明記されています:「OpenGL ES11、Vulkan 1.4.5、OpenCL 3.0の基本機能は動作していますが、適合性テストは合格していません。」そのi.MX9上のMali DDKのデフォルトパスはCTSに合格していますが、オープンソースのPanfrost/PanVKパスはまだ適合化の作業中です。 i.MX6 (GC2000+) に関しては、CTS のカバー範囲は最小限です。 現在のLinux Factoryパイプラインにおいて、GC2000+に対して体系的なdeqp/CTS実行が行われているという内部証拠は見つかりませんでした。GC2000+はOpenGL ES 3.0のみをサポートしており(3.1/3.2はサポートしていません)、テストインフラストラクチャは新しいi.MX8/9ボードをターゲットにしているようです。VK-GL-CTSでの作業は、この特定のIPに対する内部チャネルで見られる最も徹底した適合レベルのテストです。   結論として、FUTURE i.MX6ドライバーパッチが保証されているわけではありませんが、オープンサポートThreadを通じてスタンドアロンのリプロダクションを提供するのが正しい方法です。i.MX8移行に関しては、Vivante GC7000シリーズの適合状況がGC2000+よりも大幅に優れており、体系的なCTSテストもリリースプロセスの一部となっていますが、それでもなお galcore 6.4.11.p4 のドライバーバグは依然として発見・報告されています。   よろしくお願いします。 Re: Several gpu crashes/invalid output, when running opengl es cts 添付ファイルが見当たらず、追加を忘れたようだったので、もう一度追加しました

KE18F512VLH16 ECC RAM シングルビット訂正 先日@sean_dvorscakさんが投稿された記事（ KE1 ECC RAM シングルビット訂正）に関連して、追加の質問があります。 @Celeste_Liuは答えた。 ->> オプションのスクラブを実装する場合は、アクセスを実際のアクセスサイズやスクラブの粒度に基づいてアライメントし、生の MCM_LMFAR 値に盲目的に合わせないでください。また、アドレスを適切にアラインメントし、アクセスサイズが有効であることを確認しない限り、固定4バイトのアクセスは使わないでください。 MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを判定できますか?もしそうなら、これをMCM_LMFARと組み合わせて読み取り・正解・書き込み操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、同じアドレスに8ビットの書き込みをして誤りを訂正することは可能でしょうか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビット書き込みを行うことはできますか? Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 あなたの投稿を拝見しました。この件について少し調査させてください。詳しい情報が分かり次第、改めてご連絡いたします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは@Celeste_Liu - P7は最終アプリケーションの名前です。 Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 ご質問につきましては、社内の担当チームに調査を依頼する必要があります。当社の手続きに従い、 最終的な申請 名を記載してください。 ご協力ありがとうございました。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @Celeste_Liu さん、この件について何か進展はありますか？ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 申し訳ありませんが、まだ社内からの返答がありません。 再度連絡を取り、これを最優先事項として取り組みます。何か返事が来たらすぐにお知らせします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @rseigle77 さん、 ご辛抱いただきありがとうございます。社内から返信がありました。 ECCの「訂正」とは、SRAMに格納されている基となるビットを修正するのではなく、修正されたデータをCPUに返すことを意味します。自動修復には、別途スクラブ／ライトバック機構が必要です。 ソフトウェアスクラブを使用する際の推奨フロー: ECCは読み取り時にデータを訂正します。 シングルビットエラー割り込み／ステータスが発生します。RM 6.3.1.1を参照してください。割り込みの発生源を特定する。MCM_LMPECR [ER1BR] =1 ソフトウェアが故障アドレスを読み込みます。MCM_LMPEIR[PEELOC] = 5'h08 - SRAM_Lからの1ビット訂正可能なECCイベントで、MCM_LMFAR故障アドレスを示します。 ソフトウェアは修正された値を同じアドレスに書き換えます。 新たなECC症候群が生成され、保存される。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction @Celeste_Liu さん、ご回答ありがとうございます。しかし、 MCM_LMFATR[PEFSIZE]に関する私の質問には答えていません。 「MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを決定できますか?もし可能なら、これをMCM_LMFARと併用して読み込み・正書き書き返し操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、その後同じアドレスに8ビットの書き込みを行いエラーを訂正できますか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビットの書き込みを行うことは可能でしょうか?

How to Speak Directly to an AT&T Agent? Tired of automated menus and just want to talk to a real person? AT&T Customer Support Team ((USA))

画面の最上位レイヤーにおけるイベントコールバック関数名の生成が正しく行われないことに関連するバグ。 私が使用している GUI Guider のバージョンは 2.0.0 です。Top で作業しているときに...レイヤーにイベントを追加する際、生成されるgg_event_layer_top.cファイル内のトップレイヤーのイベントコールバック関数名が異常です。現在、イベントコールバック関数名の途中に括弧が挿入されており、例：「static void lv_layer_top () _event_handler ( lv_event_t * e )」のようになっています。実際、ボトムレイヤーでも同様の問題が発生しますが、スクリーンでは同様の問題は発生しません。このバグが早急に修正されることを願っています。よろしくお願いいたします。 回复： 关于屏幕顶层(Top Layer)的事件回调函数名生成异常的bug こんにちは@UENGさん フィードバックありがとうございます。この問題はバージョン2.0.1で修正されました。GUI Guiderをダウンロードしてインストールしてください。 よろしくお願いします、 ウェンビン

S32K358 中TCP 客户端握手包接收不到 现在我建立了一个TCP 客户端线程，当执行到握手端函数时，通过wireshark 能够看到客户端发给服务器得报文，也能看到服务器给客户端得报文，但是最后一步TCp客户端没有返回帧。我一直监控GMAC接收中断，发现一直卡死在循环中。MCU TCP客户端一直没有接收到最后的确认返回帧，所以没有发出去最后一帧的确认握手协议。是什么原因那？ Re: S32K358 中TCP 客户端握手包接收不到 你好@sunshine88 ， 你使用的是RTD包中提供的lwip示例吗？如果可以，能否分享一下您的即饮版本？ 您能否也分享一下RxStatus 返回的是哪个状态？ 根据您在另一篇社区帖子（ LWIP TCP/IP 服务器客户端实践）中的要求，我已经向您发送了一条包含 S32K148 的 Lwip_HandsOn 项目的私信。 此致， 朱利安

S32K322およびS32K312:CMU割り込み、リセット反応、検出レイテンシに関するクエリ 故障 イベント情報 を それぞれの CMU インスタンス(CMU0、 CMU1、 CMU2) に マッピング していただけますか? 割り込み ドキュメント には 合計 7回 の 割り込み が記載 されています が、 各 CMU インスタンス が どの 障害 イベント情報 と それに対応する 障害 アクション を 処理 しているかは 明確 ではありません 。 添付画像をご覧ください システムクロックの監視.png Interruptmapping.png 「リセット 反応 割り込み 」 の 正確な 意味 は 何 ですか ？ この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア が 介入 できるように なるのでしょうか? The clock monitoring レイテンシ can be configured from 1 µs to 1 ms. レイ テンシ を 低 くすることで 、 デバウンスやフィルタリング の時間を 短縮 し、 クロック 障害検出 の 感度 や速度 が 向上 するのでしょうか? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@ WadkarY 1. 障害発生 イベント情報 と それぞれ の CMU インスタンス （CMU0、 CMU1、 CMU2 ） と の マッピング を 提供していただけ ます か ？ image.png image.png ご覧のとおり、CMU_FC_0、CMU_FM_1、CMU_FM_2のみが割り込みとして設定可能です。その他の割り込みは、標準のCMU割り込みとしてではなく、デフォルトでは破壊的なリセットの発生源として扱われるべきです。 CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMUリセット反応割り込み CMU_FC_4->AIPS_PLAT_CLK_FAIL CMUリセット反応割り込み CMU_FC_5->HSE_CLK_FAIL CMUリセット反応割り込み CMU_FC_6->CM7_CORE_CLK_FAIL CMUリセット反応割り込み 2. この 割り込み は 破壊的な リセット の前に 生成 され、 リセット が 起こる 前に ソフトウェア の 介入 を可能にする のか? いいえ、MC_RGM/DCM破壊リセット割り込みバイパスが意図的に構成されていない限り、破壊リセット動作が予想されます。 以下にその例をご紹介します。 1. CMU_FC_4 は、AIPS_PLAT_CLK 周波数がしきい値を超えていることを検出します。 ↓ 破壊的リセットが主張され、同時にIRQ 215が発行されました。 ↓ ほぼ瞬時に MCUのリセット → リセットベクターからの再起動 ↓ ソフトウェアはMC_RGMを読みます。DES[AIPS_PLAT_CLK_FAIL]でリセット原因を特定します 3. レイテンシを低く設定することで、デバウンス/フィルタリング時間を効果的に短縮し、クロック障害の検出感度や検出速度を向上させることができますか？ このパラメータはREF_CNTに関連しています。 •RCCR[REF_CNT]の値が高いほど測定ウィンドウが長くなり、監視対象のクロックチェックの精度が向上します。 ・RCCR[REF_CNT]の値が低いと測定ウィンドウが短くなり、FHHおよびFLLの反応が速くなりますが、報告結果の誤差が高まります。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@WadkarY 「CMUリセット反応割り込み」は、破壊的なリセットの前に発生する早期警告割り込みとして解釈すべきではありません。これらのCMU障害発生源の場合、破壊的リセット反応が設定されている場合、リセット要求とそれに対応するMC_RGMリセット反応割り込みはほぼ同時に生成されます。したがって、ソフトウェアは破壊的なリセットが起こる前にISRに入力し、復旧動作を完了することに依存してはなりません。 割り込みはMC_RGMリセットリアクション機構の一部であり、該当するリセットリアクションを割り込みにリダイレクト/バイパスできる構成に関連しています。ソースが破壊的リセットに設定されたままであれば、通常のソフトウェア戦略はリセットを待ってから、再起動後に対応するMC_RGMを確認することです。リセット原因を特定するためのDESステータスフラグ。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、チームの皆さん、 ご回答ありがとうございます。 しかし、「リセット反応割り込み」の意味と目的が理解できません。 CMU_FC_3->CORE_CLK_FAIL CMUリセット反応割り込み CMU_FC_4->AIPS_PLAT_CLK_FAIL CMUリセット反応割り込み CMU_FC_5->HSE_CLK_FAIL CMUリセット反応割り込み CMU_FC_6->CM7_CORE_CLK_FAIL CMUリセット反応割り込み これらの割り込みが、破壊的なリセットが生成される前にソフトウェア介入の機会を提供するかどうか、明確にしていただけますか? もしそうなら、ソフトウェアはどのように介入してリセットを防止または処理できるのでしょうか? そうでない場合、破壊的なリセットが直後に発生するのであれば、これらの割り込みを生成する目的は何ですか？ Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency こんにちは、@WadkarY PLLには適用されないため、別途大偏差仕様は存在しません。PLLの出力周波数精度は、基準水晶の精度に、データシートのPLL特性表で「JPLL_acc」として定量化されている小さなジッタ成分を加えた値に等しくなります。 Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency お返事ありがとうございます。 PLLクロックの場合に可能な最大偏差について教えてもらえますか? データシートから、FIRCおよびSIRCの場合に許容される最大偏差、すなわち5%および10%の誤差が示されました。 DLLの逸脱については、DSには記載されていないので、もう少し説明していただけますか?

LWIP TCP/IP Server-Client Hands-On       你好，我们有没有关于S32K358 的TCP 客户端握手例程，我现在遇到了一些问题，我在上一篇帖子中发出了这个问题。我看到之前有一篇帖子是关于S32K148相关问题的已解决: LWIP TCP/IP Server-Client Hands-On - NXP Community，不知道是否能够帮我我！       如果有，麻烦您发一份，我的邮箱是[email protected].。万分感谢！  Re: LWIP TCP/IP Server-Client Hands-On 你好@sunshine88 ， S32K358 没有像 lwip_s32k148_HandsOn 工作坊那样的参考项目。我已向您发送了包含 lwip_s32k148_HandsOn_Server 和 lwip_s32k148_HandsOn_Client 的私信。 此致， 朱利安

S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)? The interrupt documentation lists a total of seven interrupts, but it is not clear which failure events are handled by each CMU instance and their corresponding failure actions.  Please see attached images  system clock monitoring.png Interruptmapping.png What is the exact meaning of the "Reset Reaction Interrupt"? Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs? The clock monitoring latency can be configured from 1 µs to 1 ms. Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster? Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY 1.Could you please provide the mapping of failure events to the respective CMU instances (CMU0, CMU1, and CMU2)? image.png image.png As can be seen, only CMU_FC_0，CMU_FM_1,CMU_FM_2 is configurable as an interrupt; the others should be treated by default as sources of a destructive reset, rather than as standard CMU interrupts. CMU_FC_0->CMU0 CMU_FM_1->CMU1 CMU_FM_2->CMU2 CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt 2.Does this interrupt get generated prior to a destructive reset, allowing software intervention before the reset occurs? No， expect destructive reset behavior unless the MC_RGM/DCM destructive-reset interrupt bypass is deliberately configured for example: 1.CMU_FC_4 detects AIPS_PLAT_CLK frequency exceeding the threshold ↓  Destructive Reset asserted + IRQ 215 issued simultaneously ↓ Almost instantaneously MCU reset → Restart from Reset Vector ↓ Software reads MC_RGM.DES[AIPS_PLAT_CLK_FAIL] to identify the reset cause 3.Does selecting a lower latency effectively reduce the debounce/filtering time and make clock failure detection more sensitive or faster? This parameter is related to REF_CNT. •Higher values of RCCR[REF_CNT] results in longer measurement window, leading to better accuracy in monitored clock check. •Lower values of RCCR[REF_CNT] results in shorter measurement window, leading to faster FHH and FLL event response, but higher inaccuracy in reported result. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY The “CMU reset reaction interrupt” should not be interpreted as an early-warning interrupt before the destructive reset. For these CMU fault sources, when configured with their destructive-reset reaction, the reset request and the corresponding MC_RGM reset-reaction interrupt are generated essentially at the same time. Therefore, software must not rely on entering the ISR and completing recovery actions before the destructive reset occurs. The interrupt is part of the MC_RGM reset-reaction mechanism and is relevant to configurations where the applicable reset reaction can be redirected/bypassed to an interrupt. If the source remains configured for destructive reset, the normal software strategy is to allow the reset to occur and, after restart, check the corresponding MC_RGM.DES status flag to determine the reset cause. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Thank you for your reply. Could you help to understand the maximum deviation possible in case of PLL clock? From data sheet we got maximum deviation allowed in case of FIRC and SIRC i.e. 5% and 10% resp. Could you please clarify deviation of PLL as it is not mentioned in DS. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hi@WadkarY There is no separate large deviation spec for the PLL because it is not applicable. The PLL output frequency accuracy equals the reference crystal accuracy, plus a small jitter contribution that the datasheet quantifies as "JPLL_acc" in the PLL characteristics table. Re: S32K322 and S32K312 : Queries Regarding CMU Interrupts, Reset Reaction, and Detection Latency Hello Team, thank you for your response. But I am not able to understand the meaning of "Reset Reaction Interrupt" and its purpose? CMU_FC_3->CORE_CLK_FAIL CMU reset reaction interrupt CMU_FC_4->AIPS_PLAT_CLK_FAIL CMU reset reaction interrupt CMU_FC_5->HSE_CLK_FAIL CMU reset reaction interrupt CMU_FC_6->CM7_CORE_CLK_FAIL CMU reset reaction interrupt Could you please clarify whether these interrupts provide an opportunity for software intervention before a destructive reset is generated? If yes, how can the software intervene and prevent or handle the reset? If no, what is the purpose of generating these interrupts if a destructive reset will occur immediately afterward?

S32k344 using green hills toolchain How can I relocate the vector section such that it stores vector table  in flash memory at 0x00400000, but at runs time, copies to DTCM memory and runs from there? How do I implement that in the Green hills linker file? Re: S32k344 using green hills toolchain Hi @XRen_Parker  Since this question is specifically related to the Green Hills toolchain and its integration, I would recommend contacting Green Hills directly. They should be able to provide the appropriate guidance and resources. https://support.ghs.com/ Regards, Lukas

i.MX 9は「もう完成形」と言えるのでしょうか？ 数年前にプロジェクトを始めたのですが、NXPの i.MX 9シリーズMPUがリリースされ始めていましたが、ほとんど入手困難だったため、重い i.MX 8 にしました。現段階では、これは私の必要以上の性能なので、もっと小型のMPUに移行したいと考えています。最小の1 i.MX 8を買うつもりでしたが、i.MX91が彼らのCPUの中で最も小さいです。より成熟した8よりも91の方が良いのではないかと考えていました。サーマルが一番気になるので、新品の方が良いと思いますが、まだ新しいので「まだ成熟している」かはわかりません。8に移植されるのがより公平な動きも動機になるかもしれません。 Re: Is i.MX 9 "there yet"? こんにちは、 @ceva156さん あなたのプロジェクトの主な目的は何ですか？現在どのIMX8シリーズ製品を使っていますか? BR Re: Is i.MX 9 "there yet"? こんにちは、 i.MX8のような重いマルチメディアGPU機能は不要です。i.MX91の方がずっと合いやすく、シンプルで低消費電力の設計ができるかもしれません。 Re: Is i.MX 9 "there yet"? こんにちは。もし熱性能とサイズを最優先事項とするなら、i.MX91をお勧めします。

Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK We are trying to integrate an ST VL53L8CX ToF (Time-of-Flight) sensor over SPI on an NXP i.MX8MP LPDDR4 EVK using Yocto Linux. The objective is initially to achieve basic SPI communication and successfully detect the VL53L8CX device from a custom Linux kernel driver. Full ranging functionality is not required at this stage. Hardware Board: NXP i.MX8MP LPDDR4 EVK Sensor: VL53L8CX ToF sensor Interface: SPI EVK connector: J21 expansion connector SPI controller: ECSPI2 Chip select: ECSPI2 SS0 GPIO used for CS: GPIO5_IO13 SPI device: spi1.0 SPI speed: 1 MHz SPI mode: Mode 0 The device-tree configuration currently uses:   &ecspi2 { pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; status = "okay"; stmvl53l8cx: spi@0 { reg = <0>; compatible = "st,stmvl53l8cx"; spi-max-frequency = <1000000>; }; }; meta-vl53l8cx_8mp/ ├── conf/ │ └── layer.conf ├── recipes-kernel/ │ ├── linux/ │ │ ├── files/ │ │ │ └── 0001-add-vl53l8cx-spi-node.patch │ │ └── linux-imx_%.bbappend │ │ │ └── vl53l8cx/ │ ├── files/ │ │ ├── Makefile │ │ └── driver.c │ └── vl53l8cx.bb The SPI device is successfully created:   root@imx8mp-lpddr4-evk:~# ls -l /sys/bus/spi/devices/ spi0.0 spi1.0   The custom driver is also registered:   root@imx8mp-lpddr4-evk:~# ls -l /sys/bus/spi/drivers/ stmvl53l8cx   The driver probe() function is being called successfully. Could someone please advise what we should verify on the i.MX8MP EVK ECSPI2/J21 hardware and Device Tree configuration to make sure the VL53L8CX is communicating correctly over SPI? In particular, we would like to confirm: Is ECSPI2 / spi1.0 the correct SPI controller/device for the J21 expansion connector on the i.MX8MP LPDDR4 EVK? Is GPIO5_IO13 / ECSPI2_SS0 the correct chip-select for J21? Are the ECSPI2 SCK, MOSI, MISO and CS pinmux settings correct for this connector? Is any additional Device Tree configuration required for the VL53L8CX, such as: spi-cpol spi-cpha GPIO1/interrupt LPn/reset/power GPIO power-supply/regulator properties? Does the VL53L8CX require a particular SPI mode, timing, or initialization sequence before reading its device ID? Is there anything specific on the i.MX8MP ECSPI controller that needs to be configured for the VL53L8CX? Since spi_write() and spi_read() return 0, is there a recommended way to verify the actual MOSI/MISO electrical communication (for example with a logic analyzer) and determine whether the sensor is responding? We have also attached our custom driver.c driver and kernel logs for reference. Any guidance on the correct i.MX8MP EVK + J21 + ECSPI2 + VL53L8CX SPI configuration would be appreciated. I have attached custom driver file driver.c also I have attached logs Thank you. Re: Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK Hello @Manuel_Salas  Thank you for your response. We tried reading the device ID before proceeding with any further configuration. However, we are not able to read the device ID successfully. Our SPI driver is probing correctly, but the register read for the chip ID does not return the expected value. Because of this, we are unable to verify communication with the VL53L8CX and cannot proceed with the sensor initialization. We are currently checking our SPI configuration, device tree, and hardware connections to identify the issue. We will also attach our driver, logs and module image so you can review it. If you have any suggestions on what else we should verify for basic SPI communication with the VL53L8CX, we would greatly appreciate your guidance. Best regards, yogi96 Re: Enable SPI Communication for VL53L8CX ToF Sensor on i.MX8MP EVK Hello @yogi96  Hope you are doing very well. In general, all your steps looks good. The next step what yocan try is read any register of the sensor, for example, in your probe() function, read the ID from the chip. If ID is correct read, continue with the configuration. Also, I could not saw the driver attached. Please attach is possible. Best regards, Salas.

MIMXRT700-EVK Flashing Error Hi, I am unable to flash my application to the MIMXRT700-EVK using NXP LinkServer. Hardware/Software: Board: MIMXRT700-EVK MCU: MIMXRT798S Debugger: On-board MCU-Link MCU-Link firmware: V3.172 LinkServer: 26.6.137 OS: Ubuntu Linux Power is supplied through J54 During flashing, LinkServer reports: Error: Wire Ack Fault - target connected? Error: Wire not connected Failed on connect: Ee(42). Could not connect to core. No connection to chip's debug port Flash operation exited with code 1 The MCU-Link is detected correctly by the PC, and LinkServer can detect the probe. The important hardware observation is that the D4 red LED is not glowing. According to the MIMXRT700-EVK documentation, D4 indicates the MCU/reset status, where ON indicates normal processor activity and OFF indicates that the processor is in reset. I also executed the RT700 preconnect script, but the SWD connection still fails with: Error: Wire Ack Fault - target connected? Error: Wire not connected Support Request Could you please advise: Why is the D4 LED OFF when the board is powered through J54? How can I bring the RT700 processor out of the reset state? Is there any required reset, boot, or hardware configuration that needs to be checked? What recovery procedure should I use to restore LinkServer connectivity so that I can flash the application? Evaluation Board Re: MIMXRT700-EVK Flashing Error Hi @Aparna1, It's likely that the power is not being properly distributed to the MCU/rest of the board, but rather just to the on-board debugger. Is the green D10 LED also OFF? Please make sure that the jumper position of J2 is shorting pins 7 and 8. BR, Edwin. Re: MIMXRT700-EVK Flashing Error Hi, Yes, I have verified the following: The green D10 LED is ON. J2 is shorting pins 7 and 8 . Please let me know if any additional checks are required from my side. Regards, Aparna Re: MIMXRT700-EVK Flashing Error    This is the Status after connecting USB  Re: MIMXRT700-EVK Flashing Error Hi, could you please provide an update on my ticket? I am still waiting for a response.   Thank you.