Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
I.MX6 VPU 编码特性 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我们正在评估 i.mx6 VPU 对从摄像头图像流编码为 H.264 的性能。 由于我对 i.MX6 的流媒体编码完全不熟悉,所以在选择传感器时遇到了困难。我对此有些疑问。 1. VPU 对 H.264 编码支持的最大分辨率是多少? 2. H.264 编码在最高分辨率下支持的最大帧速率是多少? 3. VPU 支持的 H.264 编码输入色彩空间有哪些? 4. 如果分辨率较低,例如 640*480 像素,与 1920*1080 像素相比,H.264 编码能否获得更高的帧速率? 5. 帧速率是否受比特率限制? 6.是否可以将流从IPU路由到VPU进行编码? 谢谢! 古纳 图形与显示 i.MX6 四核 Linux 多媒体 Yocto Project Re: I.MX6 VPU Encoding Features 你好,Artur 是否可以在解码 1920x1080 30FPS 视频的同时,对 1920x1080 30FPS 视频进行编码?此外,也没有任何文件说明此信息是否属实? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 太感谢了 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1.水平分辨率限制为 1080 像素,但 MJPEG BP 配置文件的最大图像尺寸可达 8192x8192 像素。 2. 没有直接的像素/秒与工作频率的关系规范。此外,VPU 的吞吐量对于编码和解码操作是不同的。它可以编码一个 1920x1080@30fps 流,并解码一个 1920x1080@30fps 流和一个 D1@30fps 流。 阿图尔 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 阿图尔·佩图霍夫 谢谢你的回复。 为了澄清一下,这是否意味着即使 VPU 运行频率为 352MHz,我也无法使用 VPU 进行 1600 x 1200 (UXGA) h264 编码? 如何计算VPU工作频率下的吞吐量?我查阅资料得知,266MHz 运行频率下的吞吐量约为72,576,000像素/秒。你能帮我解决这个问题吗? Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Q1.VPU对H.264编码支持的最大分辨率是多少? Q2.H.264编码在最高分辨率下支持的最大帧速率是多少? A1-2。i.MX6系列处理器的视频处理单元(VPU)可以 以最高 1920x1080@30fps 分辨率/帧速率对视频流进行编码/解码。 Q3.VPU支持的H.264编码输入色彩空间有哪些? A3. 支持的输入色彩空间为 YUV4:2:0,但 MJPEG 编解码器除外。 支持 4:2:0、4:2:2、2:2:4、4:4:4 和 4:0:0。 第四季度。如果分辨率较低,例如 640*480 像素,与 1920*1080 像素相比,使用 H.264 编码能否获得更高的帧速率? A4。是的。 Q5.帧速率是否受比特率限制? A5. 您指的是编码视频流的比特率吗?如果真是这样,答案是:帧速率和比特率之间没有直接关系,最终的比特率主要取决于所使用的编解码器和编码配置文件。 Q6.是否可以将流从IPU路由到VPU进行编码? A6. 是的,可以使用系统内存中的帧缓冲区。例如,IPU 使用双缓冲方案将摄像头捕获的帧存储到系统内存中,然后 VPU 从那里获取帧进行编码。 祝你有美好的一天, 阿图尔 ----------------------------------------------------------------------------------------------------------------------- 注:如果此回复解答了您的问题,请点击“正确答案”按钮。谢谢你! ----------------------------------------------------------------------------------------------------------------------- Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢。我开始玩那个了。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我无法给你答案,你可以联系http://www.chipsnmedia.com/ 。 我查阅的所有资料都无法解答这个问题。 http://www.chipsnmedia.com/data/goodsImages/1289972906&&CNM_Brochure_CODA960.pdf https://community.nxp.com/external-link.jspa?url=http %3A% 2F %2Fwww.chipsnmedia.com% 2Fsupport %2Fdown% 2Fcnm-codadx6-datashe… 我建议你在船上试试。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武, 如果真是这样,那么有可能实现 640 x 480 @ 90 fps 的分辨率吗? 谢谢! 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> #1 我不在乎最大比特率或最大时钟频率。 我认为任何小于“1920*1080*30”的常规“宽度*高度*帧率”都适合h264编码。 #2 i.MX 平台必须具有“物理内存分配器 API”,该 API 可处理 DMA 和缓存一致性。 如果“IPU 输出”和“VPU 输入”共享同一内存和同一图像格式,则无需复制或转换。 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 杜武, 感谢您的回复。 我有些疑问。 1.对于 4 和 5, 如果限制条件是宽度*高度*帧率,那么VPU支持的最大比特率是多少?我在他们的文档中找不到相关信息。据我所知,VPU 的运行速度最高可达 352MHz。 2. 对于 6, SDMA 可以用于此吗?如果答案是肯定的,那么这样做有什么限制吗? 谢谢! 古纳 Re: I.MX6 VPU Encoding Features <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 简称: #1,2 1920x1080@30fps #3 YUV422(NV12)、YUV420 #4,5 我认为限制条件是“宽度*高度*帧率”。 # 6 我认为你可能需要进行格式转换或使用 memcpy 命令。 详情如下: http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=1337699481071706174845&Parent_pageType…
View full article
DSP Implementation: Microcontrollers or FPGAs Hi, I know this is a topic which has come up again and again on this sub, but I just needed some domain-specific advice from the people in the field here. What I wanted to know is that, if am interested in the DSP applications in Communications field and want to work on implementations for the same, is it worthwhile spending my time learning about microcontroller programming? Am an ECE undergrad, so I was wondering if I should directly focus on FPGAs, which are more interesting to me, honestly. I am confused because I have seen people recommend that you really do need embedded software programming skills to work with the SOCs that are being used more and more now. Really apologise if it's a redundant question! I just haven't been able to find a proper answer regarding the same, and am at a point right now where I might have to prioritise things just a tad bit. Would really appreciate any advice! Re: DSP Implementation: Microcontrollers or FPGAs Hello @endros , If your main interest is DSP for communications, focusing on FPGAs is definitely worthwhile, especially for high-throughput or real-time implementations. That said, having basic embedded C skills is still useful because many SoC/FPGA platforms involve software control, drivers, and system integration. I’d prioritize FPGA/DSP fundamentals, but spend enough time on MCU programming to be comfortable with embedded workflows. You don’t need to become a pure embedded software engineer, but you shouldn’t ignore it completely. Hope it helps. BR Celeste
View full article
IMX95LPD5EVK-19CM:L6.18.2 版本的 UUU eMMC 闪存出现故障(Linux 和 Windows 系统均出现 LIBUSB 错误) 您好,NXP团队, 我需要帮助将 IMX95LPD5EVK-19CM 从工厂 BSP 升级到 LF_v6.18.2-1.0.0,以便进行 eIQ Neutron NPU YOLO 推理。UUU eMMC 刷写在 Linux 和 Windows 系统上均失败,在 SDPS:启动 处出现不同的 libusb 错误。详情如下。 --- 1. 硬件 | 项目 | 详情 | |------|--------| | 板 | IMX95LPD5EVK-19CM(i.MX 95 19×19 EVK,SOM + 基板)| | Yocto 机器/主机名 | imx95-a1-19x19-lpddr5-evk | | 硅 | i.MX 95 A1 | | 存储 | 64 GB eMMC(出厂预装 Linux 系统) | | 电源 | J5 接 12V,SW4 打开 | | 调试 | J31 USB-C → 主机(串口,115200) | | 闪存端口 | J8 USB1 OTG USB-C → 主机 | | 摄像头 | 罗技 C920,J7 接口 (/dev/video13) | --- 2. 软件版本 ### 当前版本(出厂 eMMC — Linux 正常启动) | 元器件 | 版本 | |-----------|---------| | BSP | LF6.12.34_2.1.0| | 内核 | 6.12.34-lts-next-gbe78e49cb433 | | 启动命令行 | root=/dev/mmcblk0p2 | | Neutron 委托 | v1.0.0-be8bf399 | | libneutron_delegate.so | /usr/lib/libneutron_delegate.so | |主机变流器(旧)| eIQ 工具包 1.17 / 中子变流器 2.1.3| ### 目标(已下载,尚未刷写到 eMMC) | 组件 | 版本/文件 | |-----------|----------------| | BSP 版本 | LF_v6.18.2-1.0.0 (SCR-6.18.2-1.0.0) | | 内核(预期) | 6.18.2-1.0.0 | | 图像包 | LF_v6.18.2-1.0.0_images_IMX95 | | 启动镜像 | imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all| | 根文件系统 | imx-image-full-imx95evk.wic (约 11 GB) | | Neutron 委托(预期) | v1.0.0-7399a58e | | 主机变流器(主机端已准备就绪) | eIQ Neutron SDK 3.0.1(变流器 3.0.1+0Xd5d7918e)| 参考:NXP 论坛工程师 (Zhiming_Liu) 在 i.MX95 上使用 L6.18.2 + eIQ Neutron SDK 3.0.1 + delegate 7399a58e 验证了 YOLOv8m。 --- 3. 应用目标 使用 YOLO (v8n / v11n) 进行 USB 网络摄像头人脸检测: - INT8 TFLite 导出(Ultralytics) - 中子变流器 --target imx95 - 板载 tflite_runtime + libneutron_delegate.so 基于当前 BSP (6.12.34): - NXP 论坛 yolov8m_full_integer_quant_converted.tflite → NPU 调用时发生段错误(退出代码 139) - 自定义 yolov8n_neutron.tflite → 调用成功,但未检测到任何人 - 无头骨架构在 NPU 上运行 → 持续输出垃圾数据(~1.13);CPU拆分流水线工作正常(检测率56%–90%) 结论:在验证使用 SDK 3.0.1 转换的 NPU 模型之前,需要在 eMMC 上使用 L6.18.2 BSP。 --- 4. 主机设置 | 主机 | UUU 版本 | 路径 | |------|-------------|------| | Ubuntu 24.04 (x86_64) | Ubuntu 24.04 (x86_64) libuuu_1.5.243-0-g230f1b1 | /usr/local/bin/uuu | /usr/local/bin/uuu | /usr/local/bin/uuu | Windows 10/11 | libuuu_1.5.243-0-g230f1b1 | uuu.exe(来自 mfgtools uuu_1.5.243 版本) | 两台主机上的镜像目录: LF_v6.18.2-1.0.0_images_IMX95 --- ## 5. 启动开关 SW7(根据 IMX95LPD5EVK-19CM 快速入门指南,1=开,0=关) | 模式 | SW7-1 | SW7-2 | SW7-3 | SW7-4 | |------|-------|-------|-------|-------| |串行下载 (UUU) | 1 | 0 | 0 | 1 | | eMMC 启动(正常) | 1 | 0 | 1 | 0 | eMMC 启动(SW7=1010)工作正常。每次更改SW7之前,都需执行完整的电源循环。 --- ## 6. 闪存程序(通过 UUU 的 eMMC) 板准备(Linux 和 Windows 系统相同): - SW7 = 1001(序列号下载) - J8(USB1 OTG)连接到主机(不是 J31) - J31 连接可选的串行控制台 - J5 已连接 12V 电源 - 当 uuu 显示“等待已知的 USB 设备”时,板已通电 命令: uuu -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_allimx-image-full-imx95evk.wic (Linux:sudo uuu ... | Windows:uuu.exe ... 从镜像目录运行) --- ## 7. UUU 错误 — Linux (Ubuntu 24.04) sudo /usr/local/bin/uuu -b emmc_all \ imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all\ imx-image-full-imx95evk.wic 输出: 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 成功 0 失败 1 1:6-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all... 笔记: - lsusb 命令短暂显示 NXP USB 设备 (1fc9:015d) 处于 SDP 模式 - uuu 有时会打印“已连接新 USB 设备”,然后在 SDPS: 启动时失败。 - 未使用 sudo:权限被拒绝(错误号=13) - eMMC 未修改(闪存未完成) --- ## 8. UUU 错误 — Windows 主机:Windows 10/11,PowerShell,uuu.exe 1.5.243 工作目录:C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95 ### 尝试 — flash_all(预期正确的启动映像) PS C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95> & '..\uuu (2).exe' -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_allimx-image-full-imx95evk.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 成功 0 失败 1 1:3-E3C50910 1/1 [HID(W): LIBUSB_ERROR_PIPE (-9)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all... 各主机USB错误汇总: | 主机 | 启动映像 | libusb 错误 | |------|------------|--------------| | Ubuntu 24.04 | flash_all | LIBUSB_ERROR_NO_DEVICE (-4) | | Windows | flash_all | LIBUSB_ERROR_PIPE (-9) | 所有故障都发生在同一步骤:SDPS:启动(在 eMMC 写入进度之前)。 --- 9. 如今哪些方法行之有效 - SW7=1010 → 正常启动出厂 eMMC Linux (6.12.34)。 - 通过 eth0 进行 SSH 连接正常 检测到 USB 网络摄像头 (/dev/video13) - libneutron_delegate.so 存在 (be8bf399) - CPU端推理已验证;当前电路板支持包。上的NPU输出不正确 --- 10.向恩智浦提出的问题 1.对于在 IMX95LPD5EVK-19CM (A1) 上,使用 uuu 1.5.243 版本,设备 1fc9:015d,SW7=1001,J8 时 SDPS:启动 失败的情况,Linux 上出现 LIBUSB_ERROR_NO_DEVICE (-4) 错误的原因是什么?而 Windows 上出现 LIBUSB_ERROR_PIPE (-9) / LIBUSB_ERROR_IO (-1) 错误的原因又是什么? 2. 是否有已知的 uuu 1.5.243+ IMX95 A1 兼容性要求(驱动程序、Windows 上的 WinUSB/Zadig、Linux 上的 udev 规则)? 3. 确认 imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all + imx-image-full-imx95evk.wic 是 IMX95LPD5EVK-19CM eMMC 闪存的正确配对(除非是 ECC RAM,否则不是 sd-ecc)。 4. be8bf399 (6.12.34) 和 7399a58e (6.18.2) 之间是否存在已知的中子代表差异,从而影响 YOLOv8 INT8 模型? 5. 如果在 Linux 和 Windows 系统上 UUU USB 路径均失败,是否有其他受支持的方法将 L6.18.2 刷写到 eMMC? --- 11.日志可应要求提供 - 完整的 uuu 详细日志:uuu -v -b emmc_all ...(Linux 和 Windows) - 当主板进入 SDP 模式时,运行主机 lsusb / 设备管理器 / dmesg 命令 - 串口控制台日志(工厂 eMMC 启动 — 正常) - 板:uname -r,字符串 libneutron_delegate.so,NPU 测试结果(版本 6.12.34) 感谢您对 Neutron NPU 开发中 eMMC 升级到 L6.18.2-1.0.0 的指导。 顺祝商祺! Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) i.MX 95 的 A1 芯片已不再受我们最新的 BSP 支持,6.12.34 似乎是最后一个支持 A1 的版本。 没有变通办法,你不能让最新的 电路板支持包。 在 A1 芯片上运行,你需要用新的子卡升级你的 EVK。A1硅卡为蓝色,B0硅卡为绿色。 我没有使用 6.18.2 .wic 文件在旧款 EVK 上测试过 UUU 下载。图片显示正常,但我预计它在您那边出现的问题与之前一样。我会在接下来的几天里完成这件事。你可以用SD卡做个测试,对.wic文件进行编程。将电脑上的镜像文件复制到 SD 卡上,然后尝试在 EVK 上运行该镜像文件,并将启动模式设置为 SD 卡。 问候, 伯恩哈德。 Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) 你好, 谢谢回复。我还有关于同一板的另一个问题。 我正在尝试运行一个 M7 应用程序 IMX95LPD5EVK-19 下列的 AN14748 ,但我无法刷机。 flash.bin 用 UUU。短暂检测到电路板后,SDPS 启动立即失败。 硬件: IMX95LPD5BB-19 修订版 A1 (2024 NXP BV) 启动开关(SW7[1:4]): 1001(序列号下载) 目标: eMMC 主持人: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 尝试过的 SDK(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 两者产生的结果相同。 命令: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   错误: 成功 0 失败 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: 启动 -f flash.bin   执行步骤(根据 AN14748): 在电路板断电的情况下,将 SW7 设置为 1001 将 USB 连接到主机 跑步 sudo uuu -b emmc flash.bin 电源循环板 每次 SDPS 启动都失败 问题: 哪个 MCUXpresso SDK 版本经过验证? IMX95LPD5BB-19 REV A1 M7 闪烁? 构建目标 imx95-a1-19x19-lpddr5-evk 对这套硬件来说合适吗? 针对此电路板版本,是否存在已知的 UUU 问题或除 AN14748 之外的额外步骤? 我应该使用 -b emmc 或者 -b sd 首先,应该使用哪个USB端口?
View full article
S32K358 SWAP AB的MCAL-XDRC配置 有3个问题请帮忙解答一下: 1. 目前我需要使用SWAP功能。在RM模块里的XDRC的memory congfig中还需要对flash B-block:0x800000-0xbfffff进行定义吗? 2. HSE占用的flash空间0x7D4000-0x7FFFFF需要在memory congfig里删除吗? 3. 我把core0定义为主核,跑OS。把core2定义为副核,跑算法。那么我在Domain_Assgnment_0里分配了CM7_0,CM7_1,GMAC,uSDHC,eDMA内容;在Domain_Assgnment_1中分配了CM7_2;这样对吗?实际应用中没有使用的master是不是可以不用出现在配置里? Re: S32K358 SWAP AB的MCAL-XDRC配置 嗨@scott071209 1.应用程序或引导加载程序需要:擦除、编程、验证和读取被动分区中映像的详细信息。这意味着被动分区也应该由 XRDC 覆盖。 2. 对于 AB_SWAP 固件,RESET 期间会自动配置 XRDC,以保护 HSE FW 活动闪存区域、HSE FW 无源闪存区域、HSE FW 数据闪存和 HSE UTEST 区域。描述符 12-15 用于此目的,并且此配置已锁定,因此用户无法修改。详细信息请参阅 HSE 固件参考手册的以下章节: “14.6.3.3默认 MRC 0 配置 (AB_SWAP)” 因此,您无需通过自己的 XRDC 配置来涵盖 HSE 资源。 3. 是的,您可以使用这样的设置。如果未使用主服务器,则可以在配置中省略它。 但是,如果您使用 HSE,则还需要为 HSE 配置功能域 3。这不是为了保护 HSE 资源,而是为了赋予 HSE 访问用户数据的权限,以便能够执行加密操作。 S32K358 有四个功能域,HSE 总是被分配到最高可用功能域。以 S32K358 为例,它是功能域 3。这是硬编码的,无法更改。在新版本的 RTD 中,HSE 主站甚至不在 XRDC 配置的列表中,因为它无法重新配置。如果您只想在功能域 3 中拥有 HSE,则无需为此功能域分配任何主服务器。HSE(健康、安全和环境)功能已自动启用。 在较早的 RTD 版本中,可以将 HSE 分配给其他域,但这种配置没有任何效果。因此它被移除了。 问候, 卢卡斯
View full article
IMX95LPD5EVK-19CM:L6.18.2のUUU eMMCフラッシュが失敗(LinuxおよびWindowsでのLIBUSBエラー) NXPチームの皆様、こんにちは。 純正BSPからIMX95LPD5EVK-19CMをeIQ Neutron NPU YOLO推論のためにLF_v6.18.2-1.0.0にアップグレードするのに助けが必要です。UUU eMMCのフラッシュは、LinuxとWindowsの両方でSDPS:bootで異なるlibusbエラーで失敗します。詳細は下記をご覧ください。 --- ## 1. ハードウェア |アイテム|詳細 | |------|--------| |ボード|IMX95LPD5EVK-19CM(i.MX 95 19×19 EVK、SOM + ベースボード) | |Yocto マシン / ホスト名 |IMX95-a1-19x19-LPDDR5-EVK | |シリコン |i.MX 95 A1 | |ストレージ |64GB eMMC(工場出荷時の事前フラッシュ済みLinux) | |パワー|J5に12V、SW4オン | |デバッグ |J31 USB-C →ホスト(シリアル番号115200) | |フラッシュポート |J8 USB1 OTG USB-C →ホスト | |カメラ |J7上のLogitech C920(/dev/video13) | --- ## 2.ソフトウェアのバージョン ### 現在(純正eMMC — Linuxは通常起動) | コンポーネント | バージョン | |-----------|---------| | BSP | LF6.12.34_2.1.0| |カーネル |6.12.34-lts-next-gbe78e49cb433 | |Boot cmdline |root=/dev/mmcblk0p2 | |Neutron delegate |v1.0.0-be8bf399 | |libneutron_delegate.so |/usr/lib/libneutron_delegate.so | |ホストコンバータ(旧) |eIQツールキット1.17 / Neutronコンバーター2.1.3| ### ターゲット(ダウンロード済み、eMMCへの書き込みはまだ完了していません) |コンポーネント |バージョン / ファイル | |-----------|----------------| |BSPリリース |LF_v6.18.2-1.0.0 (SCR-6.18.2-1.0.0) | |カーネル(期待値) |6.18.2-1.0.0 | |画像パッケージ |LF_v6.18.2-1.0.0_images_IMX95 | |ブートイメージ |imx-boot-imx95-19x19-lpddr5-evk-sd.bin flash_all| |根源 |imx-image-full-imx95evk.wic(~11 GB) | |Neutron代理(期待) |v1.0.0-7399A58E | |ホストコンバータ(ホストで準備完了) |eIQ Neutron SDK 3.0.1 (converter 3.0.1+0Xd5d7918e)| 参考:NXPフォーラムエンジニア(Zhiming_Liu)がi.MX95上でYoloV8mをL6.18.2+eIQ Neutron SDK 3.0.1+delegate 7399a58eで検証しました。 --- ## 3.アプリケーション目的 YOLO(v8n / v11n)でのUSBウェブカメラの人物検出方法: - INT8 TFLite エクスポート(Ultralytics) - Neutron コンバータ --ターゲットIMX95 - tflite_runtime + libneutron_delegate.SO 搭載 現在のBSP(6.12.34)では: - NXPフォーラム yolov8m_full_integer_quant_converted.tflite → NPU呼び出しでセグメンテーション違反 (終了コード139) - カスタム yolov8n_neutron.tflite → 呼び出しは成功しましたが、人物検出数は0です - NPU上のヘッドレスバックボーン → 常にガベージ出力(約1.13)CPU分割パイプラインは正常に動作する(検出率56~90%) 結論:SDK 3.0.1で変換されたNPUモデルを検証するには、eMMC上でL6.18.2 BSPが必要です。 --- ## 4. ホスト設定 | ホスト | UUU バージョン | パス | |------|-------------|------| | Ubuntu 24.04 (x86_64) | libuuu_1.5.243-0-g230f1b1 | /usr/local/bin/uuu | | Windows 10/11 | libuuu_1.5.243-0-g230f1b1 | uuu.exe (mfgtools uuu_1.5.243 リリースより) | 両ホスト上のイメージディレクトリ: LF_v6.18.2-1.0.0_images_IMX95 --- ## 5.ブートスイッチSW7(IMX95LPD5EVK-19CM QSGごと、1=ON 0=OFF) | モード | SW7-1 | SW7-2 | SW7-3 | SW7-4 | |------|-------|-------|-------|-------| |シリアルダウンロード (UUU) | 1 | 0 | 0 | 1 | | eMMC ブート (通常) | 1 | 0 | 1 | 0 | eMMCブート(SW7=1010)は正常に動作します。SW7の交換前には必ず、電源の完全な投入サイクルを実施してください。 --- ## 6. フラッシュ手順 (UUU 経由の eMMC) 基板準備(LinuxとWindowsでも同様): - SW7 = 1001(シリアルダウンロード) - J8(USB1 OTG)はホストPCにコネクテッド(J31ではありません) - オプションのシリアルコンソール用にJ31コネクテッド - J5 12 V電源コネクテッド - 「既知のUSBデバイスを待機中」と表示されたときにボードが電源オン コマンド: uuu -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_allimx-image-full-imx95evk.wic (Linux: sudo uuu ... |ウィンドウズ:uuu.exe...画像ディレクトリより) --- ## 7.UUU errors — Linux (Ubuntu 24.04) sudo /usr/local/bin/uuu -b emmc_all \ imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all\ imx-image-full-imx95evk.wic 出力: NXP IMXチップ用uuu(Universal Update Utility)-- libuuu_1.5.243-0-g230f1b1 成功 0 失敗 1 1:6-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all... 注: - lsusb は、NXP USB デバイス (1fc9:015d) が SDP モードであることを短時間表示します。 - uuu は時々「新しい USB デバイスが接続されました」と表示した後、SDPS: ブートで失敗します - sudoなしの場合:権限が拒否されました(errno=13) - eMMCは変更されませんでした(フラッシュ書き込みが完了しませんでした) --- ## 8. UUUエラー — Windows ホスト: Windows 10/11、PowerShell、uuu.exe 1.5.243 作業ディレクトリ:C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95 ### 試行 — flash_all (正しいブートイメージが期待される) PS C:\Users\Hardware.Team\Downloads\LF_v6.18.2-1.0.0_images_IMX95> & '..\uuu (2).exe' -b emmc_all imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_allimx-image-full-imx95evk.wic NXP IMXチップ用uuu(Universal Update Utility)-- libuuu_1.5.243-0-g230f1b1 成功 0 失敗 1 1:3-E3C50910 1/1 [HID(W): LIBUSB_ERROR_PIPE (-9)] SDPS: boot -scanterm -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all... 各ホストにおけるUSBエラーの概要: | ホスト | ブートイメージ | libusb エラー | |------|------------|--------------| | Ubuntu 24.04 | flash_all | LIBUSB_ERROR_NO_DEVICE (-4) | | Windows | flash_all | LIBUSB_ERROR_PIPE (-9) | すべての障害は同じステップで発生します:SDPS:ブート(eMMC書き込み処理前)。 --- ## 9. 今日通用するもの - SW7=1010 →通常、工場出荷時のeMMC Linux(6.12.34)を起動します - eth0上のSSH作業 - USBウェブカメラ(/dev/video13)を検出 - libneutron_delegate.so present(be8bf399) - CPU側の推論検証;現在のBSPでのNPU出力が不正確です --- ## 10.NXPへの質問 1.IMX95LPD5EVK-19CM(A1)、デバイス1fc9:015d、SW7=1001、J8でuuu 1.5.243を搭載したSDPS:ブート失敗の場合、LinuxでLIBUSB_ERROR_NO_DEVICE(-4)がLIBUSB_ERROR_PIPE(-9)/LIBUSB_ERROR_IO(-1)になる原因は何ですか? 2. 既知のuuu 1.5.243はありますか?+ IMX95 A1の互換性要件(ドライバ、WindowsのWinUSB/Zadig、Linuxのudevルール)について? 3. imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all + imx-image-full-imx95evk.wic が IMX95LPD5EVK-19CM eMMC フラッシュ (ECC RAM でない限り sd-ecc ではない) の正しい組み合わせであることを確認します。 4. be8bf399(6.12.34)と7399a58e(6.18.2)の間に、YOLOv8 INT8モデルに影響を与える既知のNeutronデリゲートの違いはありますか? 5. LinuxとWindowsの両方でUUUのUSBパスが失敗した場合に、L6.18.2をeMMCにフラッシュする代替の方法はありますか? --- ## 11.ログはご要望に応じて提供いたします。 - 完全なuuuu詳細ログ:uuu -v -b emmc_all...(LinuxおよびWindows) - ボードがSDPモードに入った際のホストLSUSB / デバイスマネージャー / dmesg - シリアルコンソールログ(工場出荷時のeMMC起動 — 動作中) - ボード:uname -r、文字列libneutron_delegate.so、NPUテスト結果は1934年12月6日 Neutron NPU開発のためのeMMCアップグレードをL6.18.2-1.0.0に完成させるためのご指導ありがとうございます。 よろしくお願いいたします。 Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) i.MX 95のA1シリコンは、最新のBSPではサポートされなくなりました。6.12.34がA1をサポートする最後のバージョンと思われます。 回避策はありません。最新のBSPをA1シリコンで動かすことはできません。EVKを新しいドーターカードでアップグレードする必要があります。A1シリコンカードは青色、B0シリコンカードは緑色です。 6.18.2の.wicファイルを使用して古いEVKにUUUダウンロードをテストしていません。画像ですが、おそらくそちら側と同じように失敗すると思います。数日中にやります。SDカードでテストして、.wicをプログラムすることもできますPC上のイメージをSDカードにコピーし、ブートモードをSDカードに設定してEVKで実行してみてください。 よろしくお願いいたします。 ベルンハルト。 Re: IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) こんにちは、 ご回答ありがとうございます。同じ掲示板に関して、もう一つ質問があります。 IMX95LPD5EVK-19 follow AN14748 でM7アプリケーションを実行しようとしていますが、フラッシュできません flash.binUUUと共に。ボードは短時間検出されるが、その後すぐにSDPSの起動に失敗する。 ハードウェア: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) ブートスイッチ(SW7[1:4]): 1001(シリアルダウンロード) ターゲット: eMMC ホスト: Ubuntu Linux うーん: libuuu_1.5.243-0-g230f1b1 試したSDKs(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 どちらも同じ結果を生み出す。 コマンド: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   エラー: 成功 0 失敗 1 1:2-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   実施された手順(AN14748に基づく): ボードの電源をオフにした状態で、SW7を1001に設定します。 USBをホストに接続します 走る sudo uuu -b emmc flash.bin 電源サイクルボード SDPSの起動に毎回失敗する 質問: どのMCUXpresso SDKバージョンが IMX95LPD5BB-19 REV A1 M7のフラッシュに有効ですか? ビルドターゲット imx95-a1-19x19-lpddr5-evk このハードウェアには正しいですか? この基板改訂版に関して、既知のUUUに関する問題や、AN14748以外に追加の手順はありますか? 使うべきでしょうか -b emmc または -b sd まず、どのUSBポートを使用すればよいでしょうか?
View full article
DSPの実装:マイクロコントローラまたはFPGA こんにちは、このサブで何度も話題になっている話題だと知っていますが、この分野の方々からドメイン特有のアドバイスが欲しかったのです。私が知りたかったのは、通信分野のDSPアプリケーションに興味があり、その実装に関わりたい場合、マイクロコントローラプログラミングを学ぶことに時間を費やす価値があるのかということです。私はECEの学部生なので、正直なところFPGAの方が興味があるので、直接集中すべきか悩んでいます。混乱しています。なぜなら、最近ますます使われているSOCを扱うには組み込みソフトウェアのスキルが必要だと勧める人を見たからです。 重複した質問でしたら、本当に申し訳ありません!それに関して適切な答えが見つからず、今は少し優先順位をつけなければならない状況にある。どんなアドバイスでもいただけると大変ありがたいです! Re: DSP Implementation: Microcontrollers or FPGAs こんにちは、 @endros さん。 通信分野のDSPに興味があるなら、特に高スループットやリアルタイムの実装にはFPGAに注力する価値があります。とはいえ、基本的な組み込みCスキルは依然として有用です。なぜなら、多くのSoC/FPGAプラットフォームはソフトウェア制御、ドライバ、システム統合を伴うからです。FPGA/DSPの基礎を優先しつつ、組み込みワークフローに慣れるためにMCUプログラミングにも十分な時間を割くべきです。純粋な組み込みソフトウェアエンジニアになる必要はありませんが、完全に無視すべきではありません。 お役に立てば幸いです。 BR セレステ
View full article
Radar – Processing Chain – NXP Radar SDK 1 Table of Contents • Introduction • FMCW Radar Signal • The Radar Cube • Processing Chain Overview • Mapping the Processing Chain onto the S32R45 • Range FFT • Doppler FFT • Non-Coherent Combining • CFAR Detection • Clustering (DBSCAN) • Angle Estimation (MUSIC DoA) • NXP Radar SDK Integration • Tools and Ecosystem • Conclusion 2 Introduction In the previous articles of this series, we introduced the fundamentals of automotive radar in the Radar Overview and the hardware/software setup in Radar SW & HW Environment. Building on that foundation, this article follows the radar data on its journey through the complete processing chain — from digitized ADC samples to a final target list describing each object’s range, velocity, and angle. The chain is modeled and prototyped in MATLAB® using Radar Toolbox™ and deployed on the NXP S32R45 radar processor through the NXP Model-Based Design Toolbox for RADAR. The key processing stages are distributed across the S32R45 Cortex-A53 cores, the SPT accelerator, the BBE32 DSP accelerator, and the LAX accelerator, using optimized kernels from the NXP Radar SDK. 3 FMCW Radar Signal Frequency-Modulated Continuous Wave (FMCW) radar transmits a continuous chirp whose frequency increases linearly over time. The received echoes are mixed with the transmitted signal, producing a beat frequency (also called intermediate frequency, IF) proportional to the round-trip delay, which directly encodes target range. iulianbulancea_0-1784543595345.png Figure 1: FMCW Radar Transmit and Receive Chirp Diagram The diagram plots frequency (vertical axis) against time (horizontal axis) and shows two piecewise-linear signals. The transmitted signal Tx (blue) rises linearly across the chirp, while the received signal Rx (orange) has the same shape but is delayed in time: Tx(t) = A Tx · cos( 2π f c t + 2π (f B / 2T) t² + φ 0 ) Rx(t) = A Rx · cos( 2π f c (t − t d ) + 2π (f B / 2T) (t − t d )² + φ 0 ) The relevant variables are summarized below: Symbol Meaning Tx(t) Transmitted signal (blue curve) Rx(t) Received signal (orange curve) t d Propagation delay between Tx and Rx IF Frequency difference between Tx and Rx during the chirp T Chirp (ramp) duration f c Chirp starting frequency f B Chirp bandwidth R 0 Range of detected target v Velocity of detected target The three key physical intuitions of FMCW radar are: Range comes from the beat frequency, since the propagation delay t d = 2(R 0 + v·t)/c produces a frequency offset IF = (2 f B )/(T·c) · R 0 during the linear ramp. Velocity comes from the phase evolution across successive chirps via the Doppler effect. A moving target introduces a Doppler frequency f v = (2 f c / c) · v. The chirps repeat at a fixed pulse repetition frequency (PRF), which must be high enough to capture this Doppler shift. Angle comes from the phase differences introduced across multiple receive antennas, enabling direction estimation and spatial separation of targets. Chirp parameters are chosen according to sensing requirements: the chirp duration must exceed the round-trip time to the farthest target plus the additional time needed for mixing and signal formation. 4 The Radar Cube After mixing and sampling, the acquired data is organized into a 3D structure called the radar cube, which is the input to the entire digital processing chain. For a single antenna, each chirp produces a sequence of time samples (fast time) arranged into a column — one column per chirp. Stacking chirps side by side forms a 2D matrix (samples × chirps), and repeating this for every receive antenna and stacking along a third dimension produces the cube: samples × chirps × antennas. iulianbulancea_0-1784543663487.png Figure 2: The radar cube Every subsequent stage operates on this cube, progressively collapsing its dimensions and transforming raw echoes into higher-level target information. 5 Processing Chain Overview The FMCW processing chain converts the radar cube into a compact target list through a sequence of well-defined stages. Before looking at each block in detail, the table below provides a roadmap of the inputs and outputs at every step: Stage Input Output Range FFT Radar cube Range cube Doppler FFT Range cube Range–Doppler cube Non-Coherent Combining Range–Doppler cube Range–Doppler map CFAR Detection Range–Doppler map Detections DBSCAN Clustering Detections Target clusters MUSIC DoA Clusters + antenna data (range, velocity, angle) iulianbulancea_0-1784543716938.png Figure 3: Processing Chain Overview The process begins at the ADC, where analog signals are digitized. Range and Doppler FFTs extract distance and velocity, forming a range–Doppler representation. Data from multiple antennas is then combined to improve robustness, CFAR detects potential targets using adaptive thresholding, DBSCAN groups detections into individual targets, and MUSIC DoA estimates each target’s angle — converting raw samples into structured outputs of range, velocity, and angle. 6 Mapping the Processing Chain onto the S32R45 A key advantage of the NXP platform is that each stage of the chain is mapped onto the most suitable compute resource of the S32R45. The FFT-based stages and Non-Coherent Combining run on the SPT accelerator, the CFAR detection runs on the BBE32 DSP, the clustering runs on the Cortex-A53 cores, and the linear-algebra-heavy MUSIC estimation is offloaded to the LAX accelerator: iulianbulancea_1-1784543746920.png Figure 4: Radar processing chain hardware mapping This mapping is what allows developers to prototype the entire chain in MATLAB and then deploy each stage to dedicated radar hardware without leaving the Model-Based Design environment. 7 Range FFT The first stage operates on the radar cube by processing the fast-time samples within each chirp. For every antenna and chirp, the time-domain signal — containing superimposed beat frequencies from multiple targets — is transformed into the frequency domain using an FFT, separating the frequency components that each correspond to a distinct propagation delay, and therefore a specific range. In this application, the radar front end does not perform in-phase and quadrature (I/Q) demodulation, so the acquired signal is purely real-valued. The resulting FFT spectrum is therefore symmetric, carrying redundant positive and negative frequency components. Since only the positive frequencies correspond to physically meaningful beat frequencies here, the negative-frequency half of the spectrum is discarded. The radar cube is thus converted into a set of range profiles, where each sample index becomes a range bin. The output preserves the chirp and antenna dimensions but now contains complex values indexed by range — magnitudes indicating reflection strength, and phases retained for later processing. iulianbulancea_2-1784543782860.png Figure 5: Range FFT output On the S32R45, this stage is executed on the SPT accelerator using the rangeFFT kernel provided by the NXP Radar SDK and exposed through the NXP Model-Based Design Toolbox for RADAR. 8 Doppler FFT Building on the range-transformed data, the second stage processes the slow-time dimension by examining how the complex samples evolve across consecutive chirps. For a given range bin, a moving target produces a small phase difference between the corresponding Range FFT outputs of consecutive chirps. This progressive phase shift is a manifestation of the Doppler effect and encodes the target’s radial velocity. By analyzing these phase variations over time using a second FFT, the processing chain extracts the Doppler frequency components associated with motion. This step converts the phase evolution observed across successive Range FFT outputs into velocity information, effectively mapping stationary and moving targets into different Doppler bins. The output is a set of range–Doppler maps, one per antenna, where each cell represents a specific combination of distance and radial velocity and holds a complex value describing the target echo. The Doppler FFT output is shifted (typically via an FFT-shift operation) so that the zero-Doppler component is centered and negative Doppler frequencies appear first, giving a more intuitive velocity axis: negative values for targets moving in one direction, positive for the other. iulianbulancea_3-1784543808220.png Figure 6: Doppler FFT output As with the Range FFT, this stage is accelerated on the SPT accelerator through the Radar SDK dopplerFFT kernel. 9 Non-Coherent Combining At this point, each antenna provides its own range–Doppler map, differing mainly in phase due to the direction of arrival. These maps are combined across the antenna dimension, typically by computing magnitudes and aggregating them through averaging. The input is a set of complex-valued maps; the output is a single range–Doppler magnitude matrix in which the antenna dimension has been collapsed. This suppresses uncorrelated noise and reinforces consistent target reflections, producing a cleaner, more robust representation well suited for detection. iulianbulancea_4-1784543832714.png Figure 7: Non-Coherent Combining output Note: the pre-combining per-antenna data is retained, because it is required later for MUSIC direction-of-arrival estimation. This stage corresponds to the Non-Coherent Combining kernel ( NonCohComb ) of the NXP Radar SDK, executed on the SPT accelerator. 10 CFAR Detection The combined range–Doppler magnitude matrix is then scanned to identify potential targets. Each cell is evaluated against a locally adaptive threshold derived from its surrounding neighborhood: nearby training cells estimate the noise level, while guard cells are excluded to avoid contaminating the estimate with the target’s own energy. Through this process, the continuous-valued matrix becomes a discrete set of detections — cells whose magnitude significantly exceeds the estimated noise background. These are effectively points in range–velocity space representing likely target reflections. CFAR runs on the BBE32 DSP accelerator. 11 Clustering (DBSCAN) CFAR detections often include several neighboring points from the same physical target, as well as isolated points caused by noise. To organize them, DBSCAN clustering is applied in the range–velocity domain, grouping points based on spatial density. Taking the detection coordinates as input, DBSCAN forms clusters where dense regions correspond to real targets, while sparse detections are discarded as noise. The output is a set of target clusters, each consolidating a single target’s range and velocity. This stage runs on the Cortex-A53 cores. 12 Angle Estimation (MUSIC DoA) For each cluster, the detections are traced back to the complex per-antenna data from the range–Doppler stage. These per-antenna samples form vectors encoding the phase differences related to the direction of arrival. Combining multiple detections within a cluster, a covariance matrix is estimated to capture the spatial characteristics of the received signals. An eigenvalue decomposition separates signal and noise subspaces, and criteria such as AIC determine the number of significant sources. The MUSIC algorithm then scans possible directions and identifies those that best match the signal subspace. MUSIC has important practical limitations: the number of detectable signals must be strictly smaller than the number of antennas, otherwise the covariance matrix cannot be properly decomposed. It is also sensitive to low signal-to-noise ratio, correlated reflections, and array calibration errors — constraining its use in scenarios with many closely spaced targets or too few antenna elements. On the S32R45, the MUSIC implementation is offloaded to the LAX accelerator through the NXP Model-Based Design Toolbox for RADAR, demonstrating how computationally intensive linear-algebra operations can be accelerated directly from MATLAB-generated code. The result is a direction-of-arrival estimate for each clustered target, completing its spatial characterization. 13 NXP Radar SDK Integration The NXP S32R45 Radar SDK (RSDK 1.2.0) provides optimized radar processing kernels designed for the S32R45 radar processor. Through the NXP Model-Based Design Toolbox for RADAR, these kernels are callable directly from MATLAB and are automatically integrated into the generated application, so developers work at the algorithm level while the toolbox handles deployment to the accelerators. In the processing chain presented in this article, the Radar SDK supplies optimized implementations for: Range FFT — SPT accelerator ( rangeFFT ) Doppler FFT — SPT accelerator ( dopplerFFT ) Non-Coherent Combining — SPT accelerator ( NonCohComb ) CFAR — BBE32 DSP accelerator This lets developers prototype and validate the full chain in MATLAB while leveraging the S32R45 SPT, BBE32 DSP, and LAX hardware accelerators in the final deployed application, and it supports both standalone and Processor-in-the-Loop (PIL) execution. 14 Tools and Ecosystem This processing chain brings together products from both MathWorks and NXP. MathWorks MATLAB® Radar Toolbox™ MATLAB Coder™ Embedded Coder® NXP S32R45 radar processor (Cortex-A53 + SPT + BBE32 DSP + LAX) NXP S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 NXP Model-Based Design Toolbox for SPT 1.9.0 S32 Design Studio 3.6.1 S32R45 – High-Performance Processor for Imaging Radar 15 Conclusion The FMCW radar processing chain transforms the raw radar cube into a compact set of target descriptors through a sequence of well-defined stages. Starting from time-domain samples, range and velocity are extracted with FFT operations, detections are found through adaptive thresholding and grouped into targets, and angle estimation leverages antenna diversity to determine direction. Each final target is characterized by the tuple (range, velocity, angle). By mapping these stages onto the S32R45 Cortex-A53, SPT, BBE32 DSP, and LAX resources through the NXP Radar SDK and the NXP Model-Based Design Toolbox for RADAR, the entire chain can be prototyped in MATLAB and deployed to dedicated radar hardware within a single Model-Based Design workflow.
View full article
Radar - SW & HW Environment 1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model. Automated Driving - Bird's-Eye Plot.png   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation S32R45 Radar MPU Block Diagram.png   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX
View full article
Implementing MCUboot Using SEC Tool This video is currently being processed. Please try again in a few minutes. (view in My Videos) announcement Re: Implementing MCUboot Using SEC Tool This video shows how to implement MCUboot using the SEC Tool on the FRDM-MCXN947 board, step by step.
View full article
Processor-in-the-Loop (PIL) 1 Table of Contents •Introduction •Overview •Context •Component Overview •Design and Implementation •Results •Common Pitfalls & Troubleshooting •Summary & Next Steps •References 2 Introduction A virtual vehicle can reproduce vehicle dynamics, driver inputs, road scenarios, sensor stimuli, and network communication long before the complete physical vehicle is available. However, a successful desktop simulation answers only one part of the engineering question: does the algorithm behave correctly as a model? Processor-in-the-Loop (PIL) adds the target processor to the validation loop. The plant, scenario, and test harness remain in MATLAB ® and Simulink ® , while selected generated algorithm code is cross-compiled, downloaded, and executed on the NXP processor. Inputs are sent from the host to the target, and the computed outputs are returned to the simulation for comparison and analysis. This makes PIL the bridge between a virtual vehicle that behaves correctly on the development computer and embedded software that must produce equivalent results on its intended processor. It also provides target-based execution-time measurements, helping engineers assess whether an algorithm is not only functionally correct, but also suitable for its timing budget. 3 Overview This article presents how Processor-in-the-Loop fits into a Model-Based Design workflow for virtual vehicle development. The goal is to show where PIL adds value between desktop simulation and deeper hardware integration, and how the same virtual vehicle and scenario can be reused to validate generated code on the target processor. In this workflow, the model remains the starting point. The virtual vehicle provides the plant behavior, the simulated environment provides repeatable driving conditions, and the selected algorithm is generated and executed on target hardware. PIL therefore supports a controlled transition from model behavior to target implementation behavior. vladmitroi_0-1784549882563.png Figure 1. PIL connects virtual vehicle simulation with generated algorithm execution on target hardware. 4 Context The practical context for this article is the Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. project. In that setup, driver inputs come from a physical steering wheel and pedals, the vehicle is driven through a RoadRunner simulated environment, and an S32N processor communicates with the host simulation while making vehicle-level decisions. The virtual vehicle is created with MathWorks tools and reused as the common integration point for driver inputs, vehicle behavior, RoadRunner scene interaction, Unreal Engine visualization, CAN communication, and closed-loop feedback from the physical setup. From that perspective, PIL is not used to move the entire virtual world to the processor. Instead, the virtual vehicle and simulated scenario remain on the host while selected generated algorithms are executed on the target. This keeps the environment flexible and repeatable while bringing processor behavior into the validation loop. 5 Component Overview A PIL-enabled virtual vehicle workflow combines the following elements: Virtual vehicle - represents vehicle dynamics, driver interaction, powertrain, steering, braking, CAN communication, and feedback paths. Virtual scene and scenario - provides roads, lanes, signs, intersections, actors, traffic movement, and repeatable test conditions using RoadRunner and Unreal Engine. PIL component - contains the selected generated algorithm code that is cross-compiled and executed on the target processor. S32N main node - acts as an aggregator and decision-maker, receiving information from sensing nodes and sending high-level commands to actuator nodes. S32N positioning: S32N is a suitable solution for running complex central-compute algorithms in PIL because it is positioned at the point where vehicle-level decisions, aggregated data, CAN communication, and actuator commands come together. 6 Design and Implementation A practical PIL workflow starts by selecting a bounded algorithm and keeping the plant, scene, and test harness on the host. This makes the test setup easier to control and keeps the comparison focused on the generated target implementation. 6.1 Select the algorithm boundary Relevant candidates include data aggregation, vehicle-level decision logic, Automated Emergency Braking logic, actuator command generation, CAN signal processing, and telemetry preparation. 6.2 Create repeatable virtual tests Use the simulated environment to define controlled driving conditions such as road geometry, actors, traffic movement, obstacle placement, and driver commands. The same scenario can be replayed for model and PIL execution. 6.3 Establish the model baseline Run the selected scenario with the original Simulink implementation and log the component inputs, outputs, and vehicle-level signals required for comparison. 6.4 Run the generated implementation in PIL Generate and build the selected component for the supported S32N5 target configuration. During the PIL run, Simulink sends test vectors to the target and receives the target results while the rest of the virtual vehicle continues to execute on the host. 6.5 Compare and profile Compare model and PIL outputs using the acceptance criteria defined for the algorithm. Where supported, collect target-side execution-time data to evaluate whether the generated component fits its timing budget. (function() { var wrapper = document.getElementById('lia-vid-6401636318112w386h386r961'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) PIL Setup on S32N5. 7 Results The result of this workflow is a direct comparison between model behavior and generated code running on the target. A useful result set shows whether target outputs remain equivalent to model outputs, whether decision thresholds and state transitions occur under the same scenario conditions, and whether the target-side execution time fits the assigned budget. Because the virtual scenes are controlled and repeatable, failing cases can be preserved as regression scenarios and rerun after model, configuration, or implementation changes. (function() { var wrapper = document.getElementById('lia-vid-6401636809112w960h540r168'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) 8 Common Pitfalls & Troubleshooting The PIL boundary is too large - keep the virtual world, visualization, and detailed plant on the host. Simulation time is confused with target execution time - use target-side profiling for algorithm timing conclusions. Model and target interfaces differ - keep signal definitions, data types, scaling, units, and sample times consistent. CAN definitions are inconsistent - reuse the same DBC definitions across the simulation and physical network. PIL is treated as complete system validation - PIL validates selected generated code on the processor; full distributed-system behavior still requires later integration stages. 9 Summary & Next Steps PIL connects the virtual vehicle, simulated scenarios, and S32N5 target execution into one validation flow. The host continues to simulate the driver, vehicle, road, actors, and environment, while selected generated main-node algorithms execute on the S32N5. A practical next step is to select one bounded S32N5 function, define its acceptance criteria, and replay a representative RoadRunner scenario first with the model and then in PIL. Suitable starting points include data aggregation, AEB decision logic, high-level actuator command generation, or CAN signal processing. 10 References Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. Creating virtual vehicle with MathWorks - Overview Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine) MathWorks: Processor-in-the-Loop Simulation
View full article
Newbie setting up an autosar environment xmrchen_0-1783048422915.png When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can be reset so that downloads can proceed normally. Thank you. When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can reset this so that the download can proceed normally. Thank you. Re: 新手搭载autosar环境 Hello, Please try it now. It should be working. Best regards, Peter S32K新手搭载autosar环境 Thank you very much, teacher. The first problem is solved. However, when installing the S32DS_ARM_Win32_v2.2.exe integrated development environment, an activation failure message appeared. The cause was found to be an expired Activation Code. Therefore, I am requesting an extension. Thank you. 新手搭载autosar环境 Thank you very much for the teacher's support. The environment has been set up.
View full article
新手搭载autosar环境 xmrchen_0-1783048422915.png 下载S32 Design Studio for ARM 2.2 – Windows/Linux 的时候,提示如上 希望能官网能重置一下,可以进行正常下载  谢谢 When downloading S32 Design Studio for ARM 2.2 – Windows/Linux, the above message appears. Hopefully, the official website can reset this so that the download can proceed normally. Thank you. Re: 新手搭载autosar环境 你好, 请立即尝试。应该可以正常运行了。 顺祝商祺! Peter S32K新手搭载autosar环境 非常感谢老师 ,第一个问题解决了,但是在安装S32DS_ARM_Win32_v2.2.exe集成开发环境时,提示激活失败,查明原因是Activation Code过期导致,特申请延期   谢谢 新手搭载autosar环境 非常感谢老师支持    环境已经搭建完成
View full article
初心者がAUTOSAR環境をセットアップする xmrchen_0-1783048422915.png S32 Design Studio for ARM 2.2 – Windows/Linux をダウンロードする際に、上記のメッセージが表示されます。 公式サイトが復旧し、ダウンロードが正常に行えるようになることを願っています。よろしくお願いいたします。 S32 Design Studio for ARM 2.2 – Windows/Linux をダウンロードする際に、上記のメッセージが表示されます。公式サイトがこの問題を解決し、ダウンロードが正常に進むようにしてくれることを願っています。ありがとう。 Re: 新手搭载autosar环境 こんにちは、 今すぐお試しください。動作するはずです。 よろしくお願いいたします。 ピーター S32K新手搭载autosar环境 先生、どうもありがとうございました。最初の問題は解決しました。しかし、S32DS_ARM_Win32_v2.2.exe統合開発環境をインストールする際に、アクティベーションエラーメッセージが表示されました。原因はアクティベーションコードの有効期限切れであることが判明しました。つきましては、有効期限の延長をお願いいたします。よろしくお願いいたします。 新手搭载autosar环境 先生のご支援に心より感謝申し上げます。環境は整いました。
View full article
i.MX RT1010 フラッシュの問題 カスタムボードで@i.MX RT1010を使っていて、フラッシュの問題に直面しています。 すべての電源レールは安定しており、仕様を満たしています。 リセットピンは安定しています(電源投入後HIGH)。 デバッガーはターゲットを検出するが、フラッシュ書き込みは必ず失敗する。 既にハードウェアのショートやはんだ付け不良がないか確認済みです。 開発ボード Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123。 より良くサポートするために、次の情報を教えてもらえますか? -RT1010-EVKと同じ外部フラッシュ機器を使っていますか?もしなければ、カスタムボードに使われているフラッシュデバイスの部品番号を教えていただけますか? -どの画像をプログラムしようとしているのですか?SDKの例ですか、それともご自社のカスタムアプリケーションですか? -デバイスのプログラミングにはどのツールを使用していますか?例えばMCUxpresso IDEやSecure Provisioning Toolなどはどうでしょうか? -JTAGかSWDで繋がっていますか? もし他に役立ちそうな詳細があれば、遠慮なくお知らせください。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、 @keerthisri123 さん、 UARTインターフェースを通じてデバイスに接続できるか確認していただけますか?もしそうなら、Secure Provisioning Tool ユーザーガイド v26.03のセクション6.15.2「RT10xx/RT116x/RT117xデバイスの基板接続」に記載されている手順に従い、結果を教えていただけると助かります。これにより、問題がSWD接続に関連しているのか、それとも別のハードウェアの問題なのかを判断するのに役立ちます。 Secure Provisioning Toolから「Help → User Guide」から直接ユーザーガイドにアクセスできます。 Habib_MS_0-1783375355897.png さらに、ハードウェア開発ガイドの第5章「デバッグとプログラミング」の復習 MIMXRT1010 プロセッサをおすすめします。この章では、ハードウェア設計の検証や信頼性の高いデバッグ動作の確保に役立つデバッグコネクタ実装に関するいくつかの推奨事項やベストプラクティスを提供します。 電源投入時に測定したブートモードピンとブート構成ピンの状態はどうなっていますか?彼らは安定していますか? 最後に、パワーアップシーケンスのオシロスコープキャプチャを提供してもらえますか?これにより、電源投入タイミングと初期化シーケンスが正しく実行されていることを確認できます。 BR ハビブ Re: i.MX RT1010 Flashing Issue こんにちは、ハビブさん。 ご返信ありがとうございます。 詳細は下記をご覧ください。 外部フラッシュ:カスタムボードにはAT25SF128A-SHB-T QSPI NORフラッシュを使用しています。EVKと同じです。 画像: evkmimxrt1010_igpio_input_interrupt SDKの例 をプログラムしようとしています 。 プログラミング ツール: SEGGER J-Link Commander V9.56およびSEGGER J-Flash Lite V9.56 。 デバッグインターフェース:JTAGで、RT1010-EVKと同じインターフェースを使用します。 参考のために画像も添付しました。 keerthisri123_0-1783355889230.png すべての電源シーケンスリセットラインは正常に動作しています。 Re: i.MX RT1011 Flashing Issue こんにちは、ハビビさん、 私が使用しているセキュアプロビジョニングツールの参考画像をいくつか添付しました。 JTAGとUARTの両方のインターフェースを使っていますが、下のエラーログに示されているように 「接続、電源、ISPモードへのリセットを確認」 というメッセージが出続けます。 この問題のトラブルシューティングの次のステップについてアドバイスをいただけますか? セキュアなプロビジョニングプロセスにおいて、従うべき特定の手順はありますか?また、これらの手順を進める前に、実施しておくべきハードウェアのチェックはありますか? サポートにあらかじめ感謝いたします。 Re: i.MX RT1011 Flashing Issue こんにちは、 @keerthisri123。 このThreadは公開されているので、よりプライベートなコミュニケーションチャネルで調査を続け、設計図を安全に確認できるようにサポート チケット を開いていただけませんか?これにより、問題のさらなる分析が可能になり、ハードウェア接続に関する潜在的な問題を排除することができます。 チケットを開く際は、この投稿を参照して私の名前をお知らせください。引き続きサポートいたします。 初期レビューを円滑に進めるため、基板の回路図一式を添付してください。特に以下の点にご注意ください。 -ブートモードピンとブート構成ピン。 外部フラッシュ接続。 -コアとデバッグインターフェース接続。 電源回路。 -クロック接続。 -電源投入シーケンス、および電源投入中のブートモードピンとブート構成ピンの状態をオシロスコープでキャプチャします。 BR ハビブ Re: i.MX RT1011 Flashing Issue こんにちは、ハビブ ご回答ありがとうございます ブートオプションが正しく設定されておらず、Qspiが動作していないという問題が見つかりました。この問題を解決します。 よろしくお願いします。 マハラジャM
View full article
MIMXRT1186:首次 LPIT 触发未能进入 ADC 中断。 我正在使用 FRDM MIMXRT1186 EVK 板,SDK V26.03。我烧录了 LPIT ADC 演示项目,以学习外设触发的 ADC 触发信号转换。但是,当我更改 LPIT 触发频率时——具体来说,是通过将 app.h 中的宏定义 LPIT_PERIOD 修改为 50,从而得到 20 kHz 的触发速率——我遇到了一个问题:第一个 LPIT 触发无法进入 ADC 中断。 为了找出根本原因在于 LPIT 还是 ADC 外设,我进行了两项测试: 交换了ADC和LPIT模块的初始化顺序(先初始化ADC,再初始化LPIT); 在 ADC1_IRQHandler 函数中增加了 GPIO 切换操作,并通过 XBAR (kXBAR1_OutputIomuxXbarInout19) 将 LPIT 触发信号路由到外部引脚。然后捕获引脚上的波形。 示波器测量结果证实 LPIT 触发信号已正确生成,但 ADC 没有响应,没有进入其中断服务程序。 我无法理解为什么提高触发信号频率会引入这个问题。请问有人能提供一些故障排除方面的建议吗?提前致谢。测试代码附后供参考。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 感谢分享代码。 我目前正在进行一些测试,稍后会将测试结果反馈给您。 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 仅在第一次中断时看到的额外延迟是由 CM33 向量表和 ISR 代码位于非 TCM 存储器(通过缓存访问的 XSPI 闪存/OCRAM)中引起的。 您能否帮我测试一下,将所有 CM33 代码(向量表和 ISR)放入 TCM 后,该行为是否仍然存在? 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨@ChandlerY , 由于这种行为与外围设备无关,而是与代码所在位置有关,因此一种选择是在非 XIP 模式下运行应用程序,这意味着图像存储在 Flash 中,而代码从 RAM 执行。 您可以通过以下链接中的安全配置工具找到配置步骤: 处理器特定工作流程 — 安全配置工具 26.06 此致, 巴勃罗 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. 嗨,帕布罗 感谢您的回复,我已经测试过了,当 cm33 代码在 TCM 中运行时,第一次 LPIT 触发并进入 ADC 中断,它是有效的。但是当 cm33 代码在 flash 中运行时,如何解决这个问题?能否提供一些解决方法?非常感谢。
View full article
Android 16:なぜNXPはvendor_bootでデバイスツリーを処理する独自の方法を考案したのか Android 16 1.4.0リリースに含まれていた最後のu-bootブートローダーを調べたところ、設定オプション「CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT」がブートローダーに追加されていることがわかりました。 古いAndroidバージョンでは「dtbo」パーティションを使ってメインデバイスツリーを保存していたという問題が解決すると思っていました。私の理解ではそれは間違いでした。なぜなら、メインデバイスツリーは「vendor_boot」パーティション(少なくともvendor_boot v4では)に配置されるべきで、DTBOパーティションはデバイスツリーのオーバーレイで埋められ、それをメインデバイスツリーに適用してハードウェアバリアントをサポートするからです。 S32デバッグ・プローブのセットアップの詳細については、 https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions 文書化されているように、vendor_boot 内には 1 つのデバイス ツリーのみが存在する必要があります。 しかし現在、NXPは「dtbo」パーティションを廃止し、vendor_boot内の「dt_table_header」構造体を使用して、複数の完全なデバイスツリーをvendor_bootに直接追加する実装を行っています。このヘッダーは通常、「dtbo」パーティション内で複数のデバイスツリーオーバーレイを整理するために使用されますが、「vendor_boot」内では使用されません。 このNXP特有のデバイスツリー処理方法は、DTBOからのメインデバイスツリーとデバイスツリーオーバーレイを使った標準的なAndroid方法と矛盾しています。これにより、デバイスツリーオーバーレイの概念を使ってAndroidポートを維持するユーザー(私のような)にとっては難しいです。 NXPはなぜデバイスツリーのバリアントをそのような方法で実装することを選んだのでしょうか? この挙動をAndroidで記録されているやり方に戻す予定はありますか? Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot こんにちは、 Androidでは複数のデバイスツリーは必須ではありませんので、OSのアーキテクチャに必須の変更がない限り、これまで多くのバージョンでデフォルトとなっているため、BSPの提供方法に変化はないと思います。 また、デバイスツリーを選択するには、ブートローダーが以下のことを行う必要があることに注意してください。 1> SoCを識別し、対応する.dtbファイルをロードします。ストレージからメモリへ。 2> ボードを識別し、対応する.dtboファイルをロードします。ストレージからメモリへ。 3> .dtb を重ね合わせる.dtbo はマージされた DT になります。 4> マージされたDTのメモリアドレスを指定してカーネルを開始します。 そのため、同じハードウェアを使用し、異なる実装/デモンストレーションのためにわずかな変更を加えるだけなので、どちらのデバイスツリーを使用すべきかを識別する方法がありません。同じSOM(同じ基本構成のSoC+DDR+電源IC)を使用しながら異なるハードウェアを扱っている場合にのみ、これが役立つと思います。つまり、これは私たちの作業・ソフトウェアの提供方法に合わず、追加してもメリットが見当たりません。 よろしくお願いいたします。 アルド。
View full article
RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello, we are testing the signing and encryption process on RT1176 CPU. Our basic System setup is: UART/JTAG <-> RT1176 <-> SPI Nor Flash The Software we use for testing is: - RT1176 testfirmware (simple firmware which does active an LED after boot) - NXP MCUXpresso Secure Provisioning / blhost (for signing and encryption via UART) - Segger JFlash (for Flash access via JTAG) So far, we carried out the following tests: 1) While the CPU is unlocked and signing is off, the firmware (unsigned / not encrypted) boot as expected and we can access the flash without problems via JTAG. 2) While the CPU is unlocked and signing is active, the firmware (signed / not encrypted) boot as expected and we can access the flash without problems via JTAG. 3) While the CPU is locked and signing is on, the firmware (signed / encrypted) will not boot and access to the flash becomes unstable via JTAG. So, we have some kind of encryption issue. But before we examine the big encryption issue we want to understand the unstable flash behavior in step 3. During a few tests, it became apparent that the flash problem always occurs as soon as BT_FUSE_SEL is blown (BT_FUSE_SEL intact: full flash access via jtag, BT_FUSE_SEL blown: unstable flash access via JTAG). Since we're still testing, we haven't disabled JTAG via fuse setting. So the Question is: Why does BT_FUSE_SEL cause us to lose access to flash? (Is there some read-out-protection active when the CPU is locked? Does the segger jflash tool have problems with the locked CPU? ...) Also see: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/m-p/2044051 -> same issue: BT_FUSE_SEL > no flash access Thanks in advance. Best regards, Florian Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hi @florian_arndt , Thanks for your interest in NXP MIMXRT series! BT_FUSE_SEL does not directly enable SPI NOR read-out protection or disable JTAG. Its function is to force the Boot ROM to use the boot configuration stored in eFuse instead of the BOOT_CFG pins. If the OTFAD/encrypted-XIP configuration has also been programmed into eFuse, burning BT_FUSE_SEL makes that configuration effective on every boot and removes the possibility of bypassing it through the BOOT_CFG pins. An incorrect OTFAD context, key, address range, or encrypted image can therefore cause the Boot ROM to fail before the application starts. Therefore, I believe the most likely cause at this point is that the GPIOs related to boot have been bypassed, but the corresponding eFuse has not been properly configured. BT_FUSE_SEL itself does not affect the JTAG connection. I suggest you conduct an A/B test to quickly pinpoint the issue. Best regards, Gavin Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello @Gavin_Jia, thanks for your answer! Today we fixed the encryption process (bug in our firmware). Our Firmware is now booting with signing/encryption activated in the CPU. So the big issue is fixed. Whats left is the spi-flash read out issue via JTAG after setting BT_FUSE_SEL. Attached you will find our fusemap. Do you see anything which could lead to our problem? Thanks in advance. Florian
View full article
MIMXRT1186:最初のLPITトリガーがADC割り込みに入るのに失敗しました。 私はFRDM MIMXRT1186 EVKボード、SDK V26.03を使っています。LPITのADCデモプロジェクトをフラッシュして、ペリフェラルでトリガーされたADC変換を学びました。しかし、LPITトリガー周波数を変更したところ(具体的には、app.hのマクロ定義LPIT_PERIODを50に変更し、20kHzのトリガーレートを実現したところ)、問題が発生しました。最初のLPITトリガーがADC割り込みに入らないのです。 根本原因がLPITにあるのかADCペリフェラルにあるのかを調べるために、2つのテストを行いました。 ADCモジュールとLPITモジュールの初期化順序を入れ替えました(最初にADCを初期化し、次にLPITを初期化)。 ADC1_IRQHandler関数内にGPIOトグル操作を追加し、LPITトリガー信号をXBAR(kXBAR1_OutputIomuxXbarInout19)を介して外部ピンにルーティングしました。次に、ピン上の波形をキャプチャした。 オシロスコープによる測定では、LPITトリガー信号が正しく生成されていることが確認されたが、ADCは割り込みサービスルーチンに入って応答しない。 トリガー周波数を上げるとなぜこの問題が起きるのか分かりません。どなたかトラブルシューティングのアドバイスをいただけませんか?どうぞよろしくお願いいたします。参考のためにテストコードを添付します。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、 @ChandlerY さん。 コードを共有していただきありがとうございます。 現在、それを使っていくつかテストを行っており、結果が出次第ご連絡いたします。 よろしくお願いします、 パブロ Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは@ChandlerY。 最初の割り込みでのみ見られる追加の遅延は、CM33ベクターテーブルとISRコードが非TCMメモリ(キャッシュ経由でアクセスされるXSPIフラッシュ/OCRAM)に存在していることが原因です。 すべてのCM33コード(ベクターテーブルとISR)をTCMに配置した後も、この動作が続くかどうかテストするのを手伝ってもらえますか? 敬具 パブロ Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、パブロさん。 ご返信ありがとうございます。テストしたところ、TCMでcm33コードを実行すると、最初のLPITがトリガーされてADC割り込みに入ると正常に動作しました。でも、cm33コードがflashで動くときにこの問題をどう解決すればいいのか、何か回避策を教えていただけますか?本当にありがとうございました。 Re: MIMXRT1186 :first LPIT trigger fails to enter ADC interrupt. こんにちは、 @ChandlerY さん。 この動作はペリフェラルではなく、コードの所在地に関係しているため、アプリケーションを非XIPモードで実行するという選択肢があります。つまり、画像はFlashに保存され、コードはRAMから実行されます。 以下のリンクでSecure Provisioning Toolを使って設定手順を確認できます: プロセッサ固有のワークフロー — Secure Provisioning Tool 26.06 敬具 パブロ
View full article
MPC5746C hangs (no boot, no UART) at 115°C ambient Part: MPC5746C (Power Architecture Z4, SDK: NXP MPC57xx platform SDK) During thermal chamber testing at 115°C ambient, our MPC5746C-based board becomes completely unresponsive on boot — no UART console output at all, and this happens on every boot attempt at that temperature. The part appears to fully recover after cooling: reflashing/rebooting at room temperature restores normal operation with no persistent damage. Interestingly, we can still successfully reprogram flash via PEMicro JTAG debug probe while the board is at 115°C — we've confirmed this by flashing a build with an incremented version string at temperature and reading back the new version after cooling down. So the debug-probe flash path works at 115°C; only the application boot path hangs/bad state. From manual it states MCU can with hold upto 125°C.  Could you please help us to root cause the issue and how fix this issue. Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Hello, From manual it states MCU can with hold upto 125°C. Yes, that is not an issue. Could you please help us to root cause the issue and how fix this issue. Since this is your custom board and issue disappear after cooling I suspect: 1. Clock startup issue (highest probability) At 115°C: External crystal (FXOSC) startup time increases. Oscillator gain margin decreases. Load capacitors shift value with temperature. PCB leakage increases. The debugger can still access the part because debug logic uses its own infrastructure and does not depend on the application reaching main(). FXOSC status bits CMU clock-monitor faults FIRC-only boot experiment Run entirely from FIRC and disable external crystal temporarily The fact that JTAG programming continues to work at 115°C is the strongest clue that the core infrastructure remains alive and the failure is occurring very early in the application boot path rather than in the flash array itself best regards, Peter Re: MPC5746C hangs (no boot, no UART) at 115°C ambient Thank you for the insight @petervlna. Following up on this, my colleague @mnargund and me investigated further, we were able to get the MPC5746C booting successfully at 115°C. Here is a summary of what we found. Root Cause: During pre-initialization, we configured the system to bring up FIRC, FXOSC, and PLL, and then switched the system clock from FIRC to PLL. Following this, we triggered a mode transition to DRUN mode (even though the system was already in DRUN mode by default, a transition to the same mode is required for the new configuration to take effect, as mentioned in the manual), and polled MC_ME_GS.MTRANS to wait for the transition to complete. However, even after MC_ME_GS.MTRANS cleared, the code faulted with an IVOR1 exception, maybe indicating the transition had not fully stabilized by the time execution continued. At elevated temperatures (115°C), the transition appears to take longer than at room temperature, causing the system to be in an inconsistent state when the next instructions were executed. Workaround applied: We inserted an explicit software delay after the MC_ME_GS.MTRANS poll and before proceeding with the rest of initialization. With a 500 ms delay, the boot is consistently successful at 115°C. We also tested a 100 ms delay, which also works reliably in our setup.  Is there a maximum recommended software delay that can safely be inserted at this point in initialization? Is there a recommended practice to ensure reliable clock stabilization before proceeding, across the full operating temperature range up to 125°C?
View full article
RTCの例がfrdm_mcxw72ボード上でうまく構築できません こんにちは、 RTCの例は私のワークベンチではうまく構築できません。基本的な設定情報は以下のスナップショットで確認できます anliu114036_1-1784022974445.png 以下はビルドプロセス中のログメッセージです: 設定タスク開始... ワークスペースはd:\ABC\rtcです Zephyrのデフォルトモジュール(Zephyrベース(キャッシュ))を読み込み中。 -- アプリケーション:D:/ABC/rtc -- CMakeバージョン:3.30.0 -- Python3 を見つけました:C:/users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe(適切なバージョン「3.12.12」が見つかり、最低必要条件は「3.12」です)発見されたコンポーネント:インタプリタ -- キャッシュファイルは以下のアドレスに書き込まれます:D:/ABC/zephyr/zephyr/.cache -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr) -- Found west(適切なバージョン「1.5.0」が見つかり、最低必要条件は「0.14.0」) -- ボード:frdm_mcxw72、予選:mcxw727c -- ホストツールを見つけました:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見ツールチェーン:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見されたdtc: C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe(適切なバージョン「1.6.1」が見つかりました)最低必要値は「1.4.6」です。 -- BOARD.dts が見つかりました:D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- デバイスツリーオーバーレイ発見:D:/ABC/rtc/boards/frdm_mcxw72.overlay -- 生成されたzephyr.dts:D:/ABC/rtc/build/zephyr/zephyr.dts -- 生成されたピクルドedt: D:/ABC/rtc/build/zephyr/edt.pickle -- 生成devicetree_generated.h: D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h Parsing D:/ABC/zephyr/zephyr/Kconfig ロード済み設定 'D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig' マージされた構成 'D:/ABC/rtc/prj.conf' 設定は「D:/ABC/rtc/build/zephyr/.config」に保存されます Kconfigヘッダーは'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h'に保存されています。 -- Found GnuLd: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe(foundバージョン「2.43.1」) -- Cコンパイラ識別はGNU 14.3.0です -- CXXコンパイラの識別はGNU 14.3.0です -- ASMコンパイラ識別はGNUです -- 見つけたアセンブラ:C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-Zephyr-eabi/bin/Arm-Zephyr-eabi-gcc.exe -- D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ でデバイスMCXW727Cを探しています -- デバイスフォルダーを見つけました:D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- 見つけたgen_kobject_list:D:/ABC/Zephyr/Zephyr/scripts/build/gen_kobject_list.py -- 設定完了(26.9秒) -- 生成完了(1.8秒) -- ビルドファイルは以下の通りに書き込まれています: D:/ABC/rtc/build 終了コード0で終了する設定 * ターミナルはタスクで再利用されます。どのキーを押しても閉じてください。 * タスクを実行中: CMake: build ワークスペースはd:\ABC\rtcです ビルドタスク開始...... C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] include/genated/zephyr/version.h 生成中 -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr)、ビルド:v4.4.1 [2/156] 雑多/生成/syscalls.json、雑多/生成/struct_tags.json [3/156] include/generated/device-api-sections.ld、include/generated/device-api-sections.cmake を生成中 [4/156] include/generated/zephyr/driver-validation.h 生成中 [5/156] include/generated/zephyr/kobj-types-enum.h, include/generated/zephyr/otype-to-str.hを生成中,include/generated/zephyr/otype-to-size.h [6/156] include/generated/zephyr/syscall_dispatch.c、include/generated/zephyr/syscall_exports_llext.cの生成、syscall_weakdefs_llext.c、include/genated/zephyr/syscall_list.h [7/156] ビルドCオブジェクト zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] 生成中.../../include/generated/zephyr/heap_constants.h [9/156] ビルディングCオブジェクト zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] include/genent/zephyr/offsets.h 生成中 [11/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] Cオブジェクトのビルディング CMakeFiles/app.dir/src/main.c.obj [13/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] ASMオブジェクトのビルディング zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init。S.obj [32/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/traceing/tracing_none.c.obj [39/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] ASMオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi_on_reset をビルディングすること。S.obj [41/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault_s.S.obj [43/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/fatal.c.obj [44/156] linker_zephyr_pre0.cmd [45/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi.c.obj [46/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/reset.S.obj [47/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/tls.c.obj [48/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/vector_table.S.obj [49/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fpu.c.obj [50/156] リンクC静的ライブラリ zephyr\arch\common\libisr_tables.a [51/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/svc.S.obj [52/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/scb.c.obj [53/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault.c.obj [54/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/prep_c.c.obj [55/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_manage.c.obj [56/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread.c.obj [57/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/swap_helper。S.obj [58/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/__aeabi_read_tp。S.obj [59/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/cpu_idle.c.obj [60/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/exc_exit.c.obj [61/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_init.c.obj [62/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread_abort.c.obj [63/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/isr_wrapper.c.obj [64/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_core_mpu.c.obj [65/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/cmse/CMakeFiles/arch__arm__core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu_regions.c.obj [67/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/assert.c.obj [68/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu.c.obj [69/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/cbprintf.c.obj [70/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/chk_fail.c.obj [71/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/errno_wrap.c.obj [72/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/exit.c.obj [73/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/time/time.c.obj [74/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/locks.c.obj [75/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/fnmatch.c.obj [76/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/abort.c.obj [77/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/stdio.c.obj [78/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/malloc.c.obj [79/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getentropy.c.obj [80/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getopt_shim.c.obj [81/156] ビルディングCオブジェクト zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] ビルディングCオブジェクト zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__gpio.dir/gpio_mcux.c.obj [85/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] ビルディングCオブジェクト zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] ビルディングCオブジェクト zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_arm.c.obj [91/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] Cの静的ライブラリ app\libapp.a のリンク [133/156] Cの静的ライブラリ zephyr\libzephyr.a のリンク [134/156] リンクC静的ライブラリ zephyr\arch\arch\common\libarch__common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__arm__core.a [136/156] リンクC静的ライブラリ zephyr\arch\arch\arm\core\cortex_m\cmse\libarch ARM__core__mpu.a__arm__core__cortex_m__cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ [138/156] リンクC静的ライブラリ zephyr\arch\arch\arch\arm\core\cortex_m\libarch__arm__core__cortex_m.a [139/156] Cの静的ライブラリ zephyr\lib\libc\common\liblib__libc__common.a のリンク [140/156] リンクC静的ライブラリ zephyr\lib\posix\c_lib_ext\liblib__posix__c_lib_ext.a [141/156] リンクC静的ライブラリ Zephyr\ドライバ\clock_control\libdrivers__clock_control.a [142/156] リンクC静的ライブラリ zephyr\lib\libc\picolibc\liblib__libc__picolibc.a [143/156] c静的ライブラリ zephyr\drivers\console\libdrivers__console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__gpio.a のリンク [145/156] リンクC静的ライブラリ Zephyr\ドライバ\pinctrl\libdrivers__pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__serial.a [147/156] リンクC静的ライブラリ Zephyr\ドライバ\rtc\libdrivers__rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__timer.a [149/156] C静的ライブラリ modules\hal_nxp\libmodules__hal_nxp.a をリンクしています。 [150/156] リンクC静的ライブラリ zephyr\kernel\libkernel.a [151/156] C実行ファイルzephyr\zephyr_pre0.elfのリンク 失敗:zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd .&& C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.aZephyr/libzephyr.aゼファー/アーチ/コモン/リバルク__common.a zephyr/arch/arch/arm/core/libarch__arm__core.AZephyr/arch/arch/Arm/core/cortex_m/libarch__arm__core__cortex_m.AZEPHYR/ARCH/ARCH/ARM/CORE/cortex_m/CMSE/Libarch__arm__core__cortex_m__cmse.a zephyr/arch/arch/arm/core/mpu/libarch__ARM__core__MPU.AZephyr/lib/libc/picolibc/liblib__libc__picolibc.azephyr/lib/libc/common/liblib__libc__common.aZephyr/lib/posix/c_lib_ext/liblib__posix__c_lib_ext.aZephyr/ドライバ/clock_control/libdrivers__clock_control.AZephyr/ドライバ/Console/LibDrivers__console.a zephyr/drivers/gpio/libdrivers__GPIO.azephyr/ドライバ/pinctrl/libドライバ__pinctrl.a zephyr/drivers/rtc/libdrivers__rtc.aZephyr/ドライバ/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.amodules/hal_nxp/libmodules__hal_nxp.a-Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a-fuse-ld=bfd -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=降順 -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-zephyr-eabi/bin/../lib/gcc/Arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space」-lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /D:\ABC\RTC\BUILD\ZEPHYR && C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/ユーザー/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe:app/libapp.a(main.c.obj): 関数「k_sleep」で: D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94):`__device_dts_ord_92`への未定義の参照 collect2.exe:エラー: ld が終了ステータス 1 を返しました ninja: ビルドが停止しました: サブコマンドが失敗しました。 ビルドはエラーで終了しました。 * 端末プロセスは終了コード1で終了しました。 * ターミナルはタスクによって再利用されます。閉じるには任意のキーを押してください。 問題の確認にご協力いただき、誠にありがとうございました。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 例:Zephyr/samples/ドライバ/counter/alarm は問題なく動作しましたが、 RTCの例 はスナップショットと同じオーバーレイファイルを作成してもビルド中に問題が発生します。 anliu114036_0-1784094520929.png 以下はビルドプロセス中に発生した主要なエラーメッセージです。このメッセージは、皆様のご協力のもと問題を解決するためのヒントとなるはずです。本当にありがとうございます! [5/64] ビルドCオブジェクト zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj 失敗:zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj C:\ユーザー\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/。-ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/。-ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCX/MCXW/MCXW727C/ドライバ -isystem D:/ABC/Zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=常に -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/Arm-zephyr-eabi/Arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-セキュリティ -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -MF zephyr\ドライバ\rtc\CMakeFiles\ドライバ__rtc.dir\rtc_counter.c.obj.d-o zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -c D:/ABC/Zephyr/Zephyr/ドライバ/rtc/rtc_counter.c In file included from D:/ABC/Zephyr/zephyr/include/zephyr/toolchain.h:52, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel_includes.h:23, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel.h:17, from D:/ABC/Zephyr/zephyr/include/zephyr/drivers/rtc.h:26, from D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/Zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "RTC init priority must be bigger than counter" 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: note: in expansion of macro 'BUILD_ASSERT' 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。お元気でお過ごしでしょうか。 現在のMCXW72のRTCドライバの実装はcounter.hと共に使用することを想定していますゼファー図書館。この点を踏まえて、例えば zephyr/samples/drivers/counter/alarmを使ってRTC機能をテストすることをお勧めします。下の画像に示すように: RomanVR_0-1784070722139.png このプロジェクトテンプレートは、RTCをアラーム機能を備えたカウンターとして構成します。テストするには、 /boardsフォルダにオーバーレイファイル[frdm_mcxw72.overlay]を作成してください。そして、以下の内容をファイルに追加してください。 / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; これらの変更が開発に役立つかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 RTCのサンプルを正しくビルドするには、 prj.confファイルに以下の設定を追加する必要があります。 CONFIG_RTC_INIT_PRIORITY=70 これがあなたにとって有効かどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.conf ファイルの設定を追加しました CONFIG_RTC_INIT_PRIORITY=70 anliu114036_0-1784163152280.png それでも建築は通過できず、エラープロンプトのメッセージも同じです。建築ログは添付ファイルで確認できます。問題のポイントを見つける助けになれば幸いです。 よろしくお願いいたします! Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 prj.confというファイル内に設定を追加していただけますか?frdm_mcxw72.confという名前で作成されたファイルに追加しても、オーバーレイファイルのようにZephyrビルドシステムによって自動的に取得されません。 RomanVR_0-1784217266337.png これが役に立つかどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。サンプルが正しくビルドできたようで良かったです。 RTC機能に関しては、現在Zephyr(rtc.h)のRTCドライバーはMCXW72のRTCノード(counter_mcux_rtc.c)で使用している低レベルのドライバーと互換性がなく、W72のRTCはcounter.h経由で使用すべきですAPIが下位レベルのドライバで定義されているものと互換性があるため、ドライバを選びます。 先ほど紹介したアラームの例(Zephyr/samples/drivers/counter/alarm)は、RTCドライバの現在の全機能を示しています。 この情報で疑問が解消されたかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.confに設定を追加したらうまくいきました。ご協力ありがとうございました! しかし、EVKにイメージをフラッシュした後も、RTC機能がまだ壊れているように見えるという問題が残っています。これは、プリントメッセージからの時刻情報がそのままになっているためです。 anliu114036_0-1784258576109.png チェックを手伝ってもらえますか?ありがとうございます!
View full article