Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
S32K144EVB-Q100 Rev D 原理图 你好。我正在寻找S32K144EVB-Q100 Rev D的原理图。我似乎无法让该板发送任何CAN消息。是否有可用于在该板上通过 CAN 0 发送消息的示例代码?我使用 SPI 确认了 CAN 收发器处于强制正常模式,因此 CAN 应该可以正常工作。 Re: S32K144EVB-Q100 Rev D Schematic 您可以查看 S32DS 中针对S32K144EVB 的示例代码……如果您有相关代码,请分享一下,因为我找不到…… Re: S32K144EVB-Q100 Rev D Schematic 你好@db16122 , 如果您还需要 S32K144EVB Rev. D 的设计文件,请告诉我。 此致, 朱利安 Re: S32K144EVB-Q100 Rev D Schematic 你好@rosejp03 , 关于设计文件,我已经通过社区私信联系你了。 关于 CAN 功能,Rev. C(我目前使用的电路板)和 Rev. D 具有完全相同的 CAN 设计和收发器 (UJA1169): S32K144EVB-Q100 Rev. DS32K144EVB-Q100 修订版 D S32K144EVB Rev. C1S32K144EVB 修订版 C1 你使用的是现有示例吗?是AN5413: S32K1xx 系列食谱,还是 RTD 软件包中包含的食谱? 你使用的是12V电源插孔吗?将J107 位置改为 1-2,并用 12V 电源为电路板供电。 你们是如何测试CAN通信的?您使用的是其他 EVB、CAN 分析仪还是其他设备?你能尝试用示波器探测一下总线吗? 此致, 朱利安
View full article
SJA1110 的连接问题 尊敬的恩智浦半导体成员们: 此工单可能与以下主题相关: SJA-1110-Qbv配置 SJA1110-Qbv-AdminBaseTime-Configuration 在配置 S32G-VNP-RDB3 板上的 SJA1110 交换机的 Qbv 时,我一直使用 NXP 的 S32G SJA1110 SDK 来设置 gPTP/Qbv 参数,编译新的sja1110_uc.bin文件,并将其部署到 A-core Linux 电路板支持包 的固件文件夹中。 最初,我使用 PFE0 接口(SJA1110 交换机端口 4)作为 gPTP 主服务器,并将 ADMINBASETIME 设置为 0。我进行了一些测试和验证,一切迹象都表明它的行为符合预期。 然而,在项目进行过程中,我不得不重新分配角色,以便现在 gPTP 主控节点将来自连接到端口 3 的外部设备。 从我连接这个外部设备的那一刻起,Qbv 的性能就会变得非常不稳定。 我进行了一些测试,例如从较大的循环值开始: Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 为了进行测试,我从客户端(S32G PFE0 接口)向连接在同一网络上的另一个 Linux 设备(作为服务器)发送 UDP 数据包。 我在服务器端使用 tcpdump 工具捕获数据包,并分析结果。 在这种情况下,传输会在几秒钟后开始,但一旦开始,它就会正常工作(1 秒周期,给定流量优先级的 25%): Screenshot 2026-07-08 084413.png 然后,我将 GATESTATUS 分成四个段,但将周期时间缩短至 200 毫秒: Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 这样做是可行的,但我需要等待 30 秒到 2 分钟才能开始传输数据包。 Screenshot 2026-07-08 085025.png   在随后的测试中,我观察到了同样的模式: 当循环时间缩短至 100 毫秒时,我需要等待 2 到 4 分钟才能开始传输; 当循环时间缩短到 50 毫秒时,我需要等待 5 到 6 分钟才能开始传输。 等等。因此,周期长度越短,Qbv 实际开始前的等待时间就越长。在此之前,交通一直处于阻塞状态。 但是,当我进行以下配置时,观察到了另一种奇怪的现象: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 在这种情况下,除了TC6之外,所有交通流量都将通过。 当我反转配置时: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 在这种情况下,只有 TC6 的流量会被传输,而其他 TC 的流量将被阻止。 我认为,这指向了时间同步问题。 以下是我在S32DS上配置gPTP的方法: Screenshot 2026-07-08 090805.png   Screenshot 2026-07-08 091033.png   值得一提的是,这个外部 gPTP 主服务器提供的同步时间戳基于当前的 Unix 纪元:   Screenshot 2026-07-01 110153.png 当 PFE0 用作主控时,它会提供从 0 开始的同步时间戳: Screenshot 2026-07-08 091440.png   这种行为该如何解释? 感谢您的支持! 顺祝商祺! 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G , 是的,请稍候,您将获得访问权限。除了保密协议外,汽车以太网还属于出口管制政策的范畴。 我认为,ECT 工具是交换机动态重配置相关代码的绝佳来源。 是的,将 Unix epoch gPTP时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63] 是正确的方法。 顺祝商祺! 帕维尔 Re: Connectivity issue in SJA1110 嗨@PavelL , 感谢您的反馈, 确实,这种ECT工具似乎是正确的选择。 但是,我仍然无法下载它。上面写着:“SJA11XX 标准软件 - 您的申请表已收到”。我可能需要等待一段时间才能获得访问权限。 同时,为了更清楚地说明,我们假设当前的 Unix 时间戳(精确到纳秒)是: 1784013205012345678 这在世界协调时 (UTC) 代表: 2026年7月14日星期二上午7:13:25 如何正确地将此时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63]? 顺祝商祺! 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G , 感谢您创建后续讨论帖——这有助于我们了解案件的最新进展。 感谢您一次性分享所有细节和测试结果。 我已检查所提供的数据,您的 gPTP 配置似乎是正确的。   根据您的观察,该行为强烈表明问题与 Qbv 调度激活时间有关,而非门控列表条目本身。如果外部 gPTP 主时钟提供基于纪元的 PTP 时间值,而 ADMINBASETIME 配置为 0,则 ADMINBASETIME = 0 相对于当前同步的 gPTP 时域而言非常遥远,交换机需要基于该值解析 Qbv 更改/启动时间。与 PTP 时间接近零的设置相比,这可能会导致意外的调度激活行为。因此,将 ADMINBASETIME 设置为当前同步的 PTP 时域中的未来值更为安全。   因此,对于此用例,我建议根据当前同步的 PTP/gPTP 时间动态配置 ADMINBASETIME(并在静态配置中仍然使用固定值 0)。 典型的序列如下: 1. 启动 gPTP 并等待交换机与外部主控交换机同步。 2. 从交换机读取当前的 PTP 时钟。 3. 将 ADMINBASETIME 设置为未来的时间值,例如当前 PTP 时间 + 足够的安全裕度。 4. 编写 TAS/Qbv 管理参数。 5. 触发 TAS/Qbv 配置更改。 您可以参考 ECT 服务器的实现。特别是请查看udp_traffic.c文件中的 udpReceiveCallback() 函数。无论您使用的是 ECT 服务器的 SDK 版本还是 RTD 版本,都无关紧要。 PavelL_0-1783939380327.png 在 TAS 配置处理中,ECT 服务器(SDK 版本)使用 SWITCH_DRV_GetPtpClk() 读取当前 PTP 时间,将此值赋给 TAS 基准时间,加上 2 秒的裕量,然后调用 SWITCH_DRV_WriteTasAdminParameters(),再调用 SWITCH_DRV_ChangeTasConfig()。   这种方法避免使用 ADMINBASETIME = 0,并将 Qbv 调度激活与实际同步的 PTP 时间域对齐。 顺祝商祺! 帕维尔
View full article
Yoctoのリリーノーズビルド失敗 imx-car-navigation こんにちは、 最新の6.18.20-2.0.0 BSP上でFRDM-IMX93用の「imx-image-full」をビルドしようとすると、次のように失敗します。 ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' これは100%再現可能であり、必ずここで失敗します。また、bitbakeが「コンパイル」ステップを実行しているにもかかわらず、リポジトリのダウンロードが失敗する点にもご注意ください。現状では、コンパイルの段階でダウンロードを行うべきではないことと、Bitbakeがネットワーク機能をダウンロード段階に限定していることが関係しているのではないかと考えています。最近このレシピを試した人はいますか? Re: Yocto wrynose build failure for 'imx-car-navigation' 私の直感は正しかったようだ。以下のパッチを適用することで、私の場合は問題が解決しました。 --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} ただし、これはあくまで一時的な回避策であることに注意してください。これがデフォルトで許可されていない理由があります。コンパイルステップはネットワークアクセスを行わないはずです。
View full article
新建项目向导失败:未自动添加 FreeRTOS 端口 大家好, 我正在尝试使用 MCUXpresso IDE V24.12 为 LPC5536 创建一个基于 freeRTOS 的项目。 “创建新的 C/C++ 项目”向导(可从快速入门面板获取)似乎提供了一种简单的方法,可以将 freeRTOS 支持添加到项目中(请参见下方屏幕截图中的标记): danielholala_0-1750771156912.png 如您所见,“新建项目向导”提供了一个复选框,用于添加 freeRTOS 作为“操作系统”。选中此复选框后,向导会自动添加 freeRTOS 的另一个关键部分——内存管理器(请参见下方标记的复选框): danielholala_1-1750771498221.png 然而,该向导未能添加freeRTOS 中最重要的部分,即 MCU 特定的代码(请参见下方屏幕截图中的标记): danielholala_2-1750771652430.png 如果您不自行选择此元器件,则生成的项目会抛出编译错误。我认为“新建项目向导”应该始终生成一个可编译的项目。此外,MCUXpresso IDE 手册明确指出:“同时,选择一个元器件会自动选择其所有依赖项。”(第 5.1.1 节)SDK 新建项目向导)。 我认为这至少是一个用户体验方面的缺陷。 我希望这个问题能在下一个 SDK / MCUXpresso 版本中得到修复。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 我使用 MCUXpresso IDE v25.6(撰写本文时的最新版本)和 LPC5536 SDK(版本 25.06,清单 3.15)进行了尝试,但 FreeRTOS 内核和 cm33 端口之间的依赖关系仍然缺失,需要手动选择。 Re: New Project Wizard fAiL: no freeRTOS port added automatically 你好@EdwinHz , 感谢您的及时支持。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 嗨@danielholala , 我重现了这个问题,这绝对是一个 bug,因为项目向导应该会自动选择所有依赖项。我会将此问题报告给 IDE 团队,以便他们可以在 MCUXpresso 项目向导的未来版本中进行修正。 感谢您报告此问题。 BR, 埃德温。
View full article
i.MX8M PLUS) 交換部品互換性 LPDDR4 NXP様、 I.MX8PLUS EVBで使用されたLPDDR4部品である*Z2BMは生産終了です。 部品供給業者は、交換部品として**Z2BMと***Z42BMを推奨しています。 *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB部品) **Z4BM: MT53E1536M32D4DE-046 WT:C (交換部品 1) ***Z42M: MT53E1G32D2FW-046 WT:BP (交換部品 2) これら2種類の交換部品を使用しても問題ないかどうかお伺いしたいのですが。 よろしくお願いします。 よろしくお願いいたします。 チョン・インホ Ace テクノロジ Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 こんにちは、 @Inho さん。 上記の2種類のDRAMは問題なく使えます。 BR
View full article
Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hello NXP Team and S32G Community, I have developed a complete PFE plugin for S32 Design Studio (S32DS) / S32 Configuration Tools. Previously, PFE configuration support was available only through EB Tresos. The new plugin includes: Full native integration within the S32DS environment Seamless integration with NXP’s official tcpip plugin for LWIP stack support Complete TSN traffic shaper configuration (TAS and CBS) Thorough testing with LWIP and LLCE, including offload scenarios In the process, I also identified and resolved several bugs in the official tcpip and LLCE plugins. This enhancement enables smoother development of advanced Ethernet and TSN applications on S32G platforms. I would like to contribute the full plugin, integration components, bug fixes, documentation, and test results to NXP. This could be integrated into future RTD or S32 Configuration Tools releases, or shared as an official reference for the community. Questions for the NXP Team: What is the recommended process to formally submit this contribution (e.g., via a technical support case or other channel)? Are there any particular requirements regarding documentation, packaging, or agreements (such as NDA)? I have prepared a comprehensive package including the plugin files, installation/integration guide, detailed changelog, and verification results. I am happy to share it privately and support any technical review or discussion. Thank you in advance for your guidance. I look forward to your feedback. Best regards, Arsal Imam SDV Architect @ GK Automobiltechnologie (Disrupt) GoldVIP Re: Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hi,arsalimam First of all, thank you for sharing this impressive work and for your willingness to contribute it to the NXP. The functionality you described—including native S32 Design Studio integration, LWIP/tcpip integration, TSN traffic shaping support (TAS/CBS), LLCE validation, and the related bug fixes—appears very valuable for S32G Ethernet and TSN development. At this stage, contributions of software components, plugins, and modifications to existing NXP tooling require review by the relevant product and software teams. As the acceptance process may involve technical evaluation as well as intellectual property and legal considerations. You can share your materials through our customer support system: https://support.nxp.com We appreciate your effort and your interest in improving the S32G software ecosystem. BR Joey
View full article
i.MX8M PLUS)替换部件兼容性 LPDDR4 尊敬的恩智浦: *Z2BM 是 I.MX8PLUS EVB 中使用的 LPDDR4 元器件,现已停产。 零件供应商推荐使用 **Z2BM 和 ***Z42BM 作为替换零件。 *Z2BM:MT53E1536M32D4DT-046 WT:A(EVB部件) **Z4BM:MT53E1536M32D4DE-046 WT:C(替换零件 1) ***Z42M:MT53E1G32D2FW-046 WT:BP(替换零件 2) 我想咨询一下,使用这两种类型的替换零件是否可以。 谢谢! 顺祝商祺! 全仁浩 艾斯科技 Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 嗨@Inho 您可以毫无问题地使用上述两种类型的动态随机存取存储器(DRAM)。 BR
View full article
i.MX8M PLUS) Replacement part compatibility LPDDR4 Dear NXP,  The *Z2BM, an LPDDR4 component used in the I.MX8PLUS EVB, has been discontinued. The parts supplier has recommended the **Z2BM and ***Z42BM as replacement parts. *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB Part) **Z4BM: MT53E1536M32D4DE-046 WT:C (Replacement Part 1) ***Z42M: MT53E1G32D2FW-046 WT:B P (Replacement Part 2) I would like to inquire if it is acceptable to use these two types of replacement parts. Thank you. Best Regards, Inho Jeon Ace Technologies Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 Hi @Inho  You can use  two types of DRAM mentioned above without any problems. B.R
View full article
Developing a Steering System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction The steering system is an essential and safety-critical component of any vehicle, responsible for controlling the direction of wheel movement and guiding the vehicle along the intended path. In our Hello World with MBDT project, the Steering subsystem delivers this capability by driving a steering motor to a desired angle and direction, transmitting the resulting torque to the road wheels through the steering column and rack-and-pinion assembly. Demo Setup - Steering.png Figure 1. Hello World with MBDT Demo – Steering system This article series presents the Electric Power Steering (EPS) system in Electric Vehicle (EV) architecture and covers the hardware, software, code generation, and vehicle network integration needed to implement the system using a Model-Based Design (MBD) workflow with MathWorks tools and NXP hardware. 3 Overview 2.1. What will this series of articles cover? The articles in this series will present the Steering System within an EV architecture and cover the following topics: Software and Hardware Environment Overview of the MathWorks and NXP tools used to develop, test, and validate the EPS control system. Logic Control Description of the model architecture, signal interfaces, and core control algorithms implemented in the Steering System. Deployment on Real Hardware Integration with physical hardware, the stepper motor, and configuration of the NXP MCU peripherals required for motor control. CAN Integration Definition of the CAN communication interface, including database design and integration on the target NXP platform. System Validation Presentation of the final implementation results and validation of the complete system behavior. 2.2. What is the Electric Power Steering System? Electric Power Steering (EPS) eliminates the hydraulic pump found in conventional steering systems, instead relying on an electric motor driven by an Electronic Control Unit (ECU). Torque and position sensors mounted on the steering column feed real-time measurements to the ECU, which computes the required assist level and commands the motor accordingly. This on-demand assist approach improves energy efficiency, enables precise tuning of steering feel, and provides a programmable interface for Advanced Driver Assistance Systems (ADAS). Electric Steering Rack and Pinion.png Figure 2. Electric Steering Rack and Pinion EPS systems are classified based on where the electric motor is mounted on the steering mechanism. Column Assist Type (C-EPS) - The electric motor and control unit are mounted directly on the steering column inside the cabin. Pinion Assist Type (P-EPS) - The electric motor is attached to the pinion shaft within the steering gear box. Dual-Pinion Assist Type (DP-EPS) - This system separates the assist function from the steering mechanism. One pinion gear connects the steering wheel, while the electric motor applies assistance to a second, separate pinion gear directly on the steering rack. Rack Assist Type (R-EPS) - The electric motor is mounted directly onto the main steering rack, either via a concentric motor around the rack or a belt drive. Steer-by-Wire (SbW) - The mechanical connection (steering column and intermediate shaft) between the steering wheel and the wheels is entirely removed. Key Characteristics of Steer-by-Wire EPS: The wheel's movement is handled completely by electronic sensors, algorithms, and actuators It allows for completely customizable steering ratios Frees up interior cabin space Relies heavily on redundant electronics and fail-safes 2.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric power steering systems, including the following audiences: Mechanical and Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the example vehicle architecture used throughout this series, the Steering System is located in the front zone of the vehicle. The Steering ECU is built around the NXP S32K312 microcontroller, which provides both CAN and LIN connectivity. Note: The NXP S32K312 microcontroller provides the processing performance, peripheral set, and communication interfaces (CAN, LIN) required for automotive steering control applications. The ECU drives the stepper motor to the commanded position and communicates desired angle and direction requests over CAN to the Zonal Controller, which coordinates these signals with the central vehicle control node. 5 References Steering column - Wikipedia Power steering - Wikipedia Electric Power Steering (EPS) System Parts Solutions | NXP Semiconductors Electric power steering system (EPS) Clemson Vehicular Electronics Laboratory: Electric Power-Assisted Steering Electric Steering Rack and Pinion 6 Conclusion This article introduced the Electric Power Steering system architecture, its core components, and its position within a modern EV platform. It outlined the Model-Based Design approach using MATLAB/Simulink and NXP hardware as the development foundation, from algorithm modeling through automatic code generation and hardware deployment. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the EPS control system using MathWorks and NXP solutions.
View full article
DOC_S32K3x1_S32K3x2_S32K3x4_eMCEM_DCM_Mapping_v1_0_SPD1.0.5_Unofficial Mapping between SPD eMCEM and DCM for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344.
View full article
PN7642 - ULPCD evaluation in NFC Cockpit This article describes how to evaluate ULPCD feature together with PN7642 EVK (OM27642EVK) and NFC Cockpit.  1// Disable DC-DC in EEPROM  OM27642EVK does not required any HW changes for ULPCD (**). User is only required to change the following settings in EEPROM  (disable DC-DC converter). Address: 0x0000 (Secure_Lib_Config) Value: 0x21  Reset the board after writing the value.  Tomas_Parizek_0-1745904468298.png **Note: To ensure an accurate and reliable ULPCD evaluation—particularly for ULPCD current measurements. We strongly recommend implementing the following hardware modifications on the OM27642EVK. PN7642_MB.png Note: New revision of the board already have R4=DNP, R8=0Ω. Kindly check this on your board. 2//Set required ULPCD settings in EEPROM  ULPCD VDDPA -> Typically 1.5V. If the HF attenuator is 0x00, increase e.g. to 1.8V. Since the detection range does not significantly depend on the power level, there is no need to set VDDPA above 2 V. Higher VDDPA results in increased current consumption in ULPCD, but does not significantly improve detection performance. RF On Guard time -> This value can be reduced to the minimum -> 5.2 us RSSI Guard time -> Recommended value is 25 RSSI Threshold -> Typically 4~6 Number of RSSI samples -> Typically -> 0 (4 rounds) PN7642_EEPROM_ULPCD.png 3// Perform "Reads HF Attenuator"  Once the required ULPCD settings is set (Guard times, Threshold....). Then User has to perform "Reads HF Attenuator". Make sure that the "HF Attenuator" option is checked.  As written above, the value must not be 0x00. If so, increase VDDPA. 4// Perform ULPCD Calibration and check RSSI Value  For OM27642EVK, the RSSI value for unloaded antenna is typically around 1400dec - 1600dec. 5//Enter ULPCD mode  User can enter the ULPCD mode. The board will again be connected once the load change is detected (e.g. NFC card or smartphone in the antenna proximity). 6// Typical detection performance for 65 mm x 65 mm Antenna tuned to 35Ω. Tomas_Parizek_0-1782466647959.png MIFARE DESFire EV3: Class 1 Antenna  ICODE SLIX: Class 1 Antenna  ICODE 3: Class 6 Antenna  NFC Controller Solutions
View full article
Monitor the CPU loading using ebpf to reduce system call overhead A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. How it works   Kernel (eBPF) User space (C + libbpf) ----------------------- ------------------------- sched_switch tracepoint poll BPF maps every 1 s -> record on-CPU time per core -> compute active % and idle % -> accumulate in BPF Array map print per-core + average   The sched_switch tracepoint context structure is defined manually in cpu_monitor_bpf.c. Output The monitor displays per-core active/idle percentages, with the idle column matching top's id field for easy comparison:   CPU Core   | Active %   | Idle % (=top id) ------------------------------------------- CPU 0      |     0.34%  |         99.66% CPU 1      |    21.89%  |         78.11% CPU 2      |     0.15%  |         99.85% CPU 3      |     0.03%  |         99.97% ------------------------------------------- TOTAL AVG  |     5.60%  |         94.40%   To compare with top, press 1 in top to show per-core stats, then compare the id column with the Idle % column above. Prerequisites Host (build machine) Package Purpose clang + llvm version 21 Compile BPF C source to BPF ELF bpftool Generate BFP skeleton headers aarch64 Poky Toolchain Corss-compile the user-space binary   Install on Ubuntu/Debian: wget https://apt.llvm.org/llvm.sh chmod +x llvm.sh ./llvm.sh 21 apt update apt install -y llvm-21 clang-21 lld-21 lldb-21 update-alternatives --install /usr/bin/llvm-link llvm-link /usr/bin/llvm-link-21 100 update-alternatives --install /usr/bin/clang clang /usr/bin/clang-21 100 update-alternatives --install /usr/bin/llc llc /usr/bin/llc-21 100 llvm-link --version clang --version # install bpftool apt install linux-tools-$(uname -r) Target board Tested Linux kernel == 6.18.20-2.0.0 Tested image == imx-image-full Most BPF configurations are enabled by default. In addition, you need CONFIG_FTRACE=y to enable tracepoint support (required for the sched_switch hook). Build Build the project on your host machine: TOOLCHAIN_PATH=/opt/fsl-imx-internal-wayland/6.18-whinlatter/environment-setup-armv8a-poky-linux ./build_and_deploy.sh   The script will: Source the Poky toolchain environment Run make clean && make all (compiles BPF object, generates skeleton, cross-compiles user-space binary) Install the binary to ./board_deploy/cpu_monitor Deploy and run   # Copy binary to the board scp board_deploy/cpu_monitor root@<board-ip>:/usr/bin/ # Run on the board (root required for eBPF) ssh root@<board-ip> ./cpu_monitor   Press Ctrl+C to exit.   Benchmarking: eBPF vs top A scheduler stress test script is included to compare monitoring overhead between cpu_monitor and top under high scheduling pressure. Run the stress test On the target board, open three terminals:   # Terminal 1: start scheduler pressure (200 threads, 30 seconds) ./stress_sched.sh -t 200 -d 30 # Terminal 2: measure eBPF monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions timeout -s KILL 10 ./cpu_monitor # Terminal 3: measure top monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions top -b -d 1 -n 10 Compare task-clock, instructions, and context-switches from perf stat output. Try different thread counts to observe scaling behavior:   ./stress_sched.sh -t 50 -d 30     # low pressure ./stress_sched.sh -t 200 -d 30    # medium pressure ./stress_sched.sh -t 500 -d 30    # high pressure Result Test environment: i.MX943 (4x Cortex-A55), Linux 6.18.20, 10-second measurement window. Comparison results in free system load: Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.0 ms 263.9 ms 22x CPU usage 0.1% 2.8% 28x instructions 3.38M 197M 58x context-switches 12 17   sys time (kernel time) 5.0ms 199.5ms 40x user time 0 62.1ms     Comparison results in high scheduling pressure (200 threads): Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.6ms 690ms 54x CPU usage 0.1% 6.1% 61x instructions 4.8M 538M 112x context-switches 122 9019 75x sys time (kernel time) 4ms 461ms 115x user time 0 206ms     Project structure ebpf_cpu_usage/ ├── cpu_monitor_bpf.c      # Kernel-side eBPF program (C, compiled to BPF) ├── cpu_monitor.c          # User-space program (C, cross-compiled to aarch64) ├── Makefile               # Build rules ├── build_and_deploy.sh    # One-shot build + package script ├── stress_sched.sh        # Scheduler stress test for benchmarking └── README.md   A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. i.MX Processors
View full article
lowlight opensource ai-isp test on imx95       There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability FPGA Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Very High Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium High EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) Low FLOL cidautai/FLOL Lightweight CNN High Low SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low Low KinD zhangyhuaee/KinD Retinex + CNN Medium Medium RetinexNet-lite Derived Light CNN Medium High EnlightenGAN-lite Derived Small CNN Very High Low Fast LLIE CNN Various Small CNN High Medium We selected some open-source models and used UVC to perform performance tests on the exip-os08a20 module with no HDR mode. We found that SCI(GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexible, and Robust Low-Light Image Enhancement". · GitHub) computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed. Image (7).jfif
View full article
Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)   1 Table of Contents • Introduction • Context • Component Overview • Design and Implementation • Results • Common Pitfalls & Troubleshooting • Summary & Next Steps • References 2 Introduction This article explains how virtual scenes and driving scenarios can be created and used within a Model-Based Design workflow using MathWorks tools. It focuses on how MATLAB® and Simulink® integrate with RoadRunner and Unreal Engine to enable realistic, repeatable, and scalable simulation environments for developing and validating advanced automotive systems. The article is aligned with the NXP Model-Based Design Toolbox (MBDT) workflow and targets users working on control, perception, and system-level validation. In our demo setup, the same workflow presented in this article was applied to build a Driver-in-the-Loop simulation scenario. By leveraging MATLAB®, Simulink®, RoadRunner, and Unreal Engine, we created a realistic virtual environment that allowed direct interaction with the system running on NXP hardware. This approach highlights the practical value of these simulations, not only for early validation and testing, but also for closing the loop between model-based design and real-time execution on target hardware, enabling faster iteration, safer validation, and improved system reliability. 3 Context As automotive systems become more complex, early validation is increasingly important. Engineers must assess advanced functionality under tight development timelines, often before hardware is available. Model-Based Design supports this need by enabling system logic and behavior to be verified early using executable models. Virtual scenes extend this approach by embedding those models in realistic, controlled environments that reflect real-world operating conditions. Within an NXP-based development workflow, virtual scenes enable teams to explore a wide range of driving situations quickly, safely, and repeatably. Complete applications can be evaluated at Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Processor-in-the-Loop (PIL) stages, helping uncover issues early and reducing risk before hardware integration. This structured use of virtual validation supports smoother transitions from simulation to deployment on automotive microcontrollers. 4 Component Overview Creating and using virtual scenes with MathWorks relies on several tightly integrated components: MATLAB and Simulink – used for algorithm development, control logic, and system modeling. RoadRunner – a dedicated environment for building detailed road networks, traffic infrastructure, and driving scenarios. Unreal Engine – responsible for high-fidelity 3D visualization and sensor realism. Simulation interfaces – enabling data exchange between Simulink, RoadRunner, and Unreal Engine during runtime. 5 Design and Implementation This section describes the design principles and implementation flow used to create virtual scenes and scenarios. The process emphasizes modularity, repeatability, and tight integration with control and system models. 5.1 System Requirements The following prerequisites must be satisfied to build and execute virtual scenes with MATLAB and Simulink and follow our path: MATLAB and Simulink with Automated Driving Toolbox and Simulink 3D Animation Toolbox installed. RoadRunner. Adequate GPU resources for real-time rendering and sensor simulation. These requirements ensure smooth interaction between simulation models and the visualization environment. 5.2 Architecture & Model Description At a higher level, the architecture consists of a Simulink model acting as the system under test, connected to a virtual world generated by RoadRunner and Unreal Engine. The Simulink model publishes vehicle states and receives environmental feedback, such as lane boundaries, traffic participants, or sensor detections. Clear interface definition between the model and the virtual environment is essential. Signals representing vehicle position, velocity, and actuator commands are exchanged at each simulation step, enabling closed-loop execution. vladmitroi_0-1782905875750.png 5.3 MATLAB/Simulink Implementation Connecting to RoadRunner and Loading a Scenario MATLAB connects directly to RoadRunner to open projects and load driving scenarios: % Launch RoadRunner and open a project rrApp = roadrunner('C:\RoadRunnerProjects\VirtualScenes'); openProject(rrApp, 'HelloWorld_Project'); % Open a RoadRunner scenario and start simulation scenarioName = 'Intersection_CrossTraffic'; openScenario(rrApp, scenarioName); rrSim = createSimulation(rrApp); start(rrSim); Integrating RoadRunner with Simulink Once configured, Simulink and RoadRunner run synchronously. RoadRunner updates the virtual environment, while Simulink computes vehicle behavior and control actions. sim('ConfiguredVirtualVehicleModel'); close(rrApp); 5.4 Integration (RoadRunner ↔ Unreal Engine) RoadRunner is used to design road geometry, traffic signs, intersections, and actor paths. These assets are exported to Unreal Engine, which provides photorealistic rendering and sensor simulation. % Open the Simulink model open_system('ConfiguredVirtualVehicleModel'); % Path to the RoadRunner project containing the scene scenarioPathFull = 'C:\RoadRunnerProjects\VirtualScenes\HelloWorld_Project'; % Configure the Simulation 3D Scene Configuration block set_param('ConfiguredVirtualVehicleModel/Visualization/3D Engine/3D Engine/Simulation 3D Scene Configuration', ... 'RoadRunnerProjectPath', scenarioPathFull); vladmitroi_0-1782905795216.png 5.5 Creating a Custom Scene from Real Map Data Custom scenes can be created by importing real-world map data into RoadRunner. Geographic information such as road layouts and elevation profiles can be converted into editable road networks. This is an example of how to create a custom scene for recreating the Silverstone Racing Circuit in RoadRunner, using OpenStreetMap and Driving Scenario Designer. (function() { var wrapper = document.getElementById('lia-vid-6399904467112w960h540r872'); 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) And the result using Simulink 3D with Unreal Engine. vladmitroi_1-1782906964231.png vladmitroi_2-1782906974722.png 5.6 Testing & Validation Once scenarios are defined, automated simulation runs can be executed to validate system behavior across multiple variants. Key metrics such as trajectory tracking, sensor coverage, and control stability can be evaluated offline. This systematic testing approach increases confidence before integrating software with NXP hardware targets. (function() { var wrapper = document.getElementById('lia-vid-6399905825112w960h540r143'); 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) 6 Results Using virtual scenes significantly reduces development time. Engineers can identify functional issues early, explore edge cases, and refine algorithms without hardware constraints. In practice, this results in higher software quality at the time of hardware deployment and a smoother transition to real-world testing. 7 Common Pitfalls & Troubleshooting Simulation time overhead can become noticeable when RoadRunner scenes are used directly in the Simulation 3D Scene Configuration block, as Unreal Engine re-imports RoadRunner assets at the start of each simulation. While this is well suited for iterative development and scene refinement, it can slow down repeated runs. Note: For final validation or deployment-oriented testing, improved performance can be achieved by using a precompiled Unreal Engine project, which avoids repeated asset import and significantly reduces startup time. In addition, repeatedly launching RoadRunner for each simulation introduces unnecessary overhead. A recommended practice is to keep RoadRunner running across multiple simulations and reuse the existing connection. This can be achieved using the RoadRunner roadrunner.connect API, allowing MATLAB and Simulink to reconnect to an active RoadRunner instance instead of restarting it for every run, thereby improving iteration speed and overall workflow efficiency. 8 Summary & Next Steps Virtual scenes turn simulation into experience. Combined with an NXP Model-Based Design workflow, MathWorks tools enable engineers to innovate faster, validating complex behavior early while reducing risk, cost, and development effort. Next, these environments can be expanded with high-fidelity sensor models, automated regression testing, and hardware-in-the-loop execution, closing the gap between virtual validation and real-world deployment. 9 References Import OpenStreetMap Data into Driving Scenario — MathWorks Help Driving Scenario Designer App — MathWorks Help RoadRunner — MathWorks Product Page Simulink 3D Animation Toolbox — MathWorks Help OpenStreetMap Automated Driving Toolbox — MathWorks Product Page Visualize 3D Scenes with Unreal Engine — MathWorks Help roadrunner.connect API — MathWorks Help NXP Model-Based Design Toolbox — Community
View full article
S32K388 MemAcc 消去 PFLASH がフリーズ こんにちは!MemAcc_Example_S32K388を使用し、DFLASHをPFLASHに変更しました。しかし、pFlashを消去すると、MEMACC_JOB_PENDING == MemAcc_GetJobStatus(TEST_AREA)で処理が停止してしまいます。 TEST_AREAを1に設定することで、比較プログラムを修正しました。 こちらが修正されたプログラムです。私のミスを見つけて指摘してくれることを願っています。とても感謝します。 S32K3 Re: S32K388 Use MemAcc Erase PFLASH Stuck こんにちは@zhangyu5454さん 一つ問題があります。接頭辞が間違っています。正しくは Mem_43_INFLS です。 danielmartynek_0-1783597121888.png Re: S32K388 Use MemAcc Erase PFLASH Stuck Mem_43_INFLSに変更しようとしましたが、それでも動作しませんでした。ルーチンのDFLASHでMem_43_INFLSをabc123に変更したら、普通に動作します。ついにMemAcc Mem InvocationのDIRECT_STATIC それをINDIRECT STATICに変えれば問題が解決します
View full article
MPC574xP BCTRL こんにちは: 私のお客様はMPC5741Pを車載ESCのアプリケーションに使っています。 現在、エンドOEMからBCTRLピンの特性(電圧領域など)について問い合わせを受けている。 確認と確認を手伝ってもらえますか?ありがとう。 下は波形で、三角形で、OEMからMCU側からベースコントロール出力ピンのCap.デカップルを追加してほしいと依頼されました。 BoxLi_0-1783050842506.png Re: MPC574xP BCTRL データシートでは異なるトランジスタを推奨しており、以下の通りです。 davidtosenovjan_0-1783063352184.png また、適切にバイパス/分離する必要がある。VDD_LV_CORに特に注意してください。 davidtosenovjan_1-1783063654558.png Re: MPC574xP BCTRL こんにちは、デビッドさん。 了解しました、ありがとうございます。
View full article
S32K3 bootloader and HSE - best practice ? Hi NXP team, We are implementing a robust OTA update architecture on an S32K312 using HSE full-block A/B swap. Our target architecture is: - S32K312 with 2 MB PFlash split into two 1 MB physical blocks. - HSE AB_SWAP is used via the passive-block activation service. - OTA package is received over Modbus/serial. - Bootloader stages the signed image into the passive PFlash block. - HSE verifies the passive image/SMR. - Bootloader requests AP_SWAP. - After reset, the newly swapped bank boots provisionally. - A confirm command makes the swap permanent; otherwise the device rolls back. Originally we tried to keep one global bootloader in DFlash, outside the two PFlash banks. That bootloader would receive OTA, program the passive PFlash bank, request HSE AP_SWAP, and then continue to manage confirm/rollback. We ran into architectural and runtime complexity with that approach: 1. HSE AB_SWAP appears to operate on full PFlash block boundaries, not arbitrary app partitions. 2. A single DFlash bootloader is outside the swapped/authenticated bank image. 3. The active PFlash bank still needs valid boot/IVT/reset structure after swap. 4. We had difficult execution hazards when DFlash was also involved in bootloader runtime/record handling. 5. It became unclear whether a global DFlash bootloader is compatible with a clean full-bank HSE AB_SWAP production design. We therefore moved to a duplicated PFlash bootloader mode for now: - Each 1 MB PFlash bank contains its own IVT + bootloader + application. - The bootloader has a reserved slot at the base of each bank. - The application starts after the bootloader slot. - The signed OTA image is a full bank image containing bootloader + application. - After HSE AB_SWAP, the newly active bank is self-contained and bootable. This appears much cleaner for HSE full-block A/B swap, but I would like to confirm the intended/production-safe approach. This is suboptimal as it partially defeats the purpose of a factory bootloader. Questions: 1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? We have seen that code and IVT can be linked into DFlash by modifying the linker script (and we tried that), but our question is specifically about whether that is appropriate when using HSE full-block A/B swap and secure boot/SMR verification. Thank you. Re: S32K3 bootloader and HSE - best practice ? Hi @coratron  1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? There are no limitations from HW point of view. Both options are possible. If the size of data flash is sufficient and you do not plan to use it for your data, the bootloader can be placed in the data flash. If you need data flash for other purposes then having two copies of the bootloader in both partitions is common practice. 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? No, there’s no such requirement. It is sufficient to have valid IVT only in data flash (bootloader’s IVT). Common practice is that bootloader is always started after reset and then then the bootloader jumps to user application. 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? There are no specific requirements coming from SBAF or HSE. Once bootloader is started, it can decide if it should jump to application or if it should download new application or if it should do rollback, etc. and then it should reset the device (in case of rollback/swap) or jump to the application. 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? We don’t have such example. 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? I would not classify either approach as universally safer. The suitability of a particular architecture depends on the overall system design, security requirements, OTA workflow and rollback strategy. Both concepts can be implemented in a robust production solution. Regards, Lukas Re: S32K3 bootloader and HSE - best practice ? Thanks for your prompt reply @lukaszadrapa . That clarifies and helps substantially - we have been able to re-evaluate our bootloader implementation in DFlash and were successful. The team is used to the documentation / accessibility from other vendors and finds NXP to be surprisingly confusing compared to them despite being a leader in automotive applications. Your prompt feedback makes up for these gaps, so thanks again for your help - much appreciated. I will mark your reply as the solution, with the following feedback directed at your team: - A Dflash bootloader + HSE demo would have been great to save time (yours included). I am sure this is the natural setup for people that use AB_SWAP. - NXP should unify and get the documentation and software stack organised (long term) - compatibility / versions are scattered, there is no one source of information which leads to confusion. Regards 
View full article
WhisperはNPU上で動作しています こんにちは、 私は95 i.MX でCPUに縛られたささやきを動かしています NPUを使ってプロセッシング速度を上げる方法はありますか?opsetは主にCNN向けのようですが、いずれにせよ聞いてみる価値はあるでしょう。 具体的な例を見たことがないので、可能かどうかは分かりません(NPUはCNN専用のようですが?)。 既にこれをやった人はいますか?何か例はありますか?
View full article
RT1064:引脚配置,用于从内部闪存启动 你好, 这可能听起来像个愚蠢/新手问题,但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源(通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC),但没有列出内部闪存,就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存,但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出,只有两种启动模式可用(QSPI 或 SD 卡),并且还声称不支持 QSPI 启动(参见 2.7 段),因此 SD 卡是唯一的启动源…… 非常感谢您的帮助! i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat , 如 AN12290 中所述,MIMXRT1064 只能从 FlexSPI2 启动,FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存,该接口可用于保存数据或其他功能,但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源,即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC;通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI,并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动,引导设备开关 (SW7) 设置应为: SW7-1 关闭,SW7-2 关闭,SW7-3 打开,SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0,才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时,BOOT_CFG2[2:0]引脚也必须设置为0,以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR, 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好,埃德温, 确实有道理。我感到很困惑,因为外部闪存和内部闪存都是 QSPI 接口的,很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”,并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。
View full article
RT1064:内部フラッシュから起動するためのピン構成 こんにちは、 これは初心者や初心者の質問に聞こえるかもしれませんが、RT1064を内蔵フラッシュメモリから起動させるためにBOOT_MODE1/BOOT_MODE0とBT_CFG[11..0]ピンで何をすべきか正確にはわかりません。 参考マニュアルの表9.9には、3つのブートソース(FlexSPI経由のNORフラッシュ、SDCARD、eMMC)のみが記載されていますが、内部フラッシュは記載されていません。まるでこのセクションがRT1060からコピー&ペーストされたかのようです... AN12290はこの内部フラッシュへのFlexSPI2内部バスについて言及していますが、上記の3つの起動ソースで選択する方法は示していません。 MIMXRT1060/1064 Evaluation Kit Board Hardware ユーザーガイドの表5では、起動モードはQSPIかSDCARDの2種類のみが利用可能であり、QSPIブートは利用できないと主張しています(2.7段落からの注釈)、SDカードのみが唯一の起動源となっています... どんなご支援でも大変ありがたく思います。 i.MXRT 106x Re: RT1064 : pin configuration to boot from internal flash こんにちは、 @batmat さん。 AN12290で述べたように、MIMXRT1064では、内部QSPIフラッシュ専用のFlexSPI2からのみブートが可能です。外部フラッシュはFlexSPI1インターフェース経由で接続でき、起動以外のデータ保存やその他の機能に使えます。このため、リファレンス・マニュアルの表9.9には、3つのブートソースのみが記載されています。NORフラッシュ(FlexSPI、SDCARD、またはeMMC)、FlexSPI2経由のNORフラッシュが起動時に唯一利用可能なFlexSPIで、デフォルトでオンボードフラッシュにルーティングされています。 内部QSPIフラッシュから起動するためには、ブートデバイススイッチ(SW7)の設定は以下の通りであるべきです。 SW7-1 オフ、SW7-2 オフ、SW7-3 オン、SW7-4 オフ。 ブートデバイスとしてFlexSPI経由のシリアルNORブートを選択するには、BOOT_CFG1[7:4]ピンを0に設定する必要があります。また、BOOT_CFG2[2:0]ピンも0に設定しなければならず、内部のQSPIフラッシュが選択されます。MIMXRT1064-EVKは、デフォルトで以下のピン設定になっています。 BR、 エドウィン。 Re: RT1064 : pin configuration to boot from internal flash こんにちは、エドウィンさん。 確かにその通りだ。外部フラッシュと内部フラッシュの両方がQSPI対応なので、どちらがどちらなのか判別しづらくて混乱しました。 RT1064の表9.9のドキュメント進化を提案します。 「FlexSPIを経由したNORフラッシュ」ではなく、「FlexSPI2を経由した内部NORフラッシュ」と記載し、「FlexSPIを経由した外部NORフラッシュからの起動はRT1064では利用できません」と付け加えるべきです。 こうすれば混乱を避けられると思う。 改めて、素晴らしく迅速なサポートに感謝します。
View full article