Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
i.MX 8M Plus(Scarthgap)上的 HDMI EDID 4 块读取失败 您好, 我正在 Yocto Scarthgap 电路板支持包 上使用 i.MX 8M Plus,在尝试读取 4 个 HDMI EDID 块(块 0 到 3)时遇到了问题。 [环境] SoC:i.MX 8M Plus 电路板支持包/操作系统:Yocto Project Scarthgap(内核版本:lf-6.6.52) [问题描述]尝试读取所有 4 个 EDID 块时,系统无法从块 2 开始读取(段 1)。区块 0 和区块 1(0 段)读取成功,但读取操作随即失败。 [根本原因/分析]经过调试,我发现问题与段切换命令后使用的 DDC 地址有关: 要读取区块 2 和 3,必须正确执行区段切换命令。 切换网段后,驱动程序应使用标准 DDC 地址0xA0/0xA1(I2C 地址 0x50)读取实际 EDID 数据。 但是,驱动程序错误地尝试使用地址0x60/0x61(即段指针地址)读取数据,导致读取错误。 看来驱动程序错误地在随后的数据读取序列中重复使用了分段指针地址。 [问题] 这是 i.MX 8M Plus Scarthgap BSP 上的 HDMI/DDC 驱动程序中的已知问题吗? 是否有任何现有的修补程序或变通方法来修复这种地址不匹配问题? 如能提供需要修改的相关驱动程序代码的指导或指点,将不胜感激。 先行致谢。 Re: HDMI EDID 4-block read failure on i.MX 8M Plus (Scarthgap) 这是一个已知的问题吗? 实际上是的。恩智浦社区上至少有一份先前的 i.MX8MP 报告指出,i.MX8MP 无法正确读取块 1 / 段 0 以外的 E-EDID,该报告特别指出用户应访问 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 进行调查。 是否有现成的变通办法? 是的。据报道,一种解决方法是绕过 HDMI 内部 DDC 引擎,通过在设备树中设置 ddc-i2c-bus 来使用普通的 SoC I2C 控制器进行 DDC。恩智浦社区线程报告称,将 HDMI DDC 引脚重新复用到 I2C5 并使用 ddc-i2c-bus = <&i2c5>; 解决了 i.MX8MP 上的多块 E-EDID 读取问题。 是否已经有公共补丁? 我在搜索结果中没有找到上游或 NXP 发布的公开补丁来专门修复你的 BSP 行的 dw-hdmi 中的这个 0x30 / 0x50 从属地址处理问题。公开可见的 dw-hdmi.c 代码仍然显示可以触发这种行为的 “从属地址取自第一条 I2C 消息” 逻辑。   如果你的主板布线允许,风险最低且已经报告的解决方法是将 HDMI DDC 从内部 dw-hdmi I2C 引擎移出常规 SoC I2C 控制器上。在 i.MX8MP 上,报告了一种解决方案 &i2c5 { 时钟频率 =<100000> ; pinctrl-names ="默认" ; pinctrl-0 =<& pinctrl_i2c5> ; status ="okay" ; };   &hdmi { ddc-i2c-bus = < & i2c5 >; status ="okay" ; }; HDMI DDC 引脚与 I2C5_SCL / I2C5_SDA 复用。恩智浦社区线程中的用户报告说,这一变更解决了 i.MX8MP 上的多块 E-EDID 读取问题。
記事全体を表示
我能否从 nxp 中取出胶带 我能否将我的芯片设计从 nxp 中剥离出来? Re: can i tape out from nxp 亲爱的拉吉-里特维克   感谢您联系恩智浦并对我们的产品感兴趣。 我们想澄清的是,恩智浦并不为外部芯片设计提供开放式代工或带出服务。通常情况下,需要定制硅带输出的客户会直接与台积电和 GlobalFoundries 等商业代工厂联系、 您能否告诉我们您的询问是否与任何特定的恩智浦产品或设备有关?如果需要,我们很乐意为您提供进一步的帮助。 如果需要,请随时提供更多详细信息,我们很乐意提供力所能及的帮助。 祝您愉快
記事全体を表示
U4N: 如何在 FH6 中改进油门控制 如果您在东京霓虹灯闪烁的街道和富士山的山路上肆意驰骋,那么您一定会发现自己已经在东京的大街小巷和富士山的山路上肆意驰骋了。在《极限竞速地平线 6》中驾驶富士山时,您可能会注意到驾驶物理效果比以往的作品更接地气。动力输出强劲有力。 如果你把正确的扳机或油门踏板当作开/关开关,那么你不是在开车,你只是在把橡胶变成烟雾。要让汽车干净利落地转弯,需要真正的细微差别。以下是如何在 FH6 中掌握油门控制、停止打滑并缩短单圈时间的实用数据分析。 1.首先修复死区(0-100 规则) FH6 开箱即用,将您的控制器触发死区设置为默认 15 个内部、90 个外部。这意味着你的前15%扣动扳机绝对不起作用,一旦你达到90%,游戏的油门将达到100%。简而言之,你在战斗中仅使用触发器物理行程的75%来调节你的力量。 进入设置> 高级控制,立即应用这些更改: 加速轴内死区:将此值从 15 降至 0 或 2。 加速轴外部死区:将其从 90 提升至 98 或 100。 为什么数学很重要:通过将内部死区降低到0并将外部死区提高到100,可以将输入窗口从触发器机械范围的75%扩大到整整100%。如果你驾驶一辆后轮驱动的怪兽驶出一个狭窄的弯道,有额外的物理空间可以呼吸,这意味着你可以保持稳定的 45% 油门,而不会意外陷入打滑的境地。 2.角出口分析:50-70-100 级进阶 让我们来看一个具体的比赛场景。假设你正驾驶着一辆 S1 级 2024 年款福特野马黑马在 90 度街角转弯。 如果你在到达顶点的瞬间将油门踩到 100% ,你的后轮会立即失去牵引力,遥测数据会显示 100% 的摩擦力损失,你的车尾会猛地甩出去,当汽车陷入困境或打滑时,你会损失大约 1.5 到 2 秒钟。 取而代之的是分阶段线性应用: 转角阶段 目标节气门输入 汽车行为 顶点(剪切点) 30% - 50% 稳定底盘;在不破坏牵引力的情况下,将重量平稳地转移到后轮胎上。 中途出口(开卷轮) 60% - 75% 与前轮校直相匹配。随着转向锁的减少,抓地力也会增加。 直达 100% 一旦车轮完全打直,汽车稳定下来,就会全力以赴。 在短短 1.5 秒的时间内,将油门控制在 50-70-100 级之间,就能将滑移角保持在最小范围内,并最大限度地提高前行咬合力。 3.管理启动控制和 Wheelspin 在 FH6 中将汽车冲出底线是对右手食指的一大考验。如果你使用手动变速箱,按住刹车和油门会同时启动游戏中的启动控制。但是,一旦你松开刹车,你仍然必须积极管理转速。 如果你的车库里装满了顶级版本,那么手动管理会变得容易得多。如果玩家希望快速扩充自己的收藏,获得能驾驭重型动力的高级车辆,查看 U4N 等第三方市场可以提供捷径,其中出售的 FH6 车轮旋转等物品可让您立即存入信用点和稀有的地平线版车辆来进行练习。 一旦进入电网,请记住车轮打滑等于浪费能量。如果让大马力汽车在静止状态下以 8,000 RPM 的转速跳过转速限制器,由于静摩擦损失,实际前进加速度最多会下降 40% 。最佳位置是将油门保持在汽车峰值扭矩曲线附近--跑车的峰值扭矩曲线通常在 4,500 至 5,500 RPM 之间--然后在轮胎咬合时慢慢踩下 100% 油门。 4.通过遥测可视化您的功率 如果您想知道您的油门到底有多大,请不要猜测。进入控制绑定,将遥测功能映射到一个按钮上(如 D 键盘上的向下)。 在自由漫游时切换到摩擦和输入页面。注意油门杆。如果发现输入瞬间从 10% 跳转到 100% ,请检查控制器硬件。例如,如果你使用 Xbox Elite 控制器,请确保背面的物理触发开关完全关闭。触发锁将模拟触发信号变成数字按钮,这使得实际的油门调制实际上是不可能的。 在一款街机风格的赛车游戏中,放慢输入速度会让人感觉不自然,但《FH6》奖励的是精准的驾驶。平稳地在汽油上滚动总是比砸碎扳机更胜一筹。
記事全体を表示
S32k344 RTD 中的 MDIO API? 您好, 我的定制主板将 S32K344 EMAC 的 MDIO 连接到 SJA1110 的 SMI_AP 接口。我想通过 MDIO 接口配置 SJA1110 的内部 100BASE-T1 PHY,但在实时驱动程序包中找不到任何 MDIO 读/写 API。能告诉我这些应用程序接口在哪里吗? 谢谢! 查尔斯 Re: MDIO APIs in S32k344 RTD? 你好@cmnxp、 MDIO 访问 API 在 S32K3 RTD 中可用,但它们是在 GMAC 驱动程序下提供的,而不是作为单独的独立 MDIO 模块提供的。在 GMAC RTD API 中,相关函数是 Gmac_Ip_MDIOWrite() 和 Gmac_Ip_MDIORead()。 对于您使用 SJA1110 SMI_AP 的特定用例,请注意内部 100BASE-T1 PHY 子系统是通过 Clause 45 寄存器映射管理的,因此您通常需要 Clause 45 API - Gmac_Ip_MDIOReadMMD()、Gmac_Ip_MDIOWriteMMD()。 顺祝商祺! 帕维尔 Re: MDIO APIs in S32k344 RTD? 你好,帕维尔、 感谢您的快速回复。也就是说,S32K344 只有一个 MDIO 接口,同时用于 EMAC 和 GMAC,对吗? 此致, 查尔斯 Re: MDIO APIs in S32k344 RTD? 你好@cmnxp、 是的,每个 EMAC/GMAC 通常有一个 SMI 接口。 顺祝商祺! 帕维尔
記事全体を表示
S32K314 FreeRTOS 待机转换和返回运行模式 我正在使用 S32K314 和 RDT 7.0.0 开发一个结合了中断和任务的项目、和 FreeRTOS 7.0.0。 中断和任务运行正常。我已经实现了从运行模式过渡到待机模式的代码,并在 RTC 测得的指定时间过后返回运行模式。 我已经确认系统从运行模式过渡到待机模式,之后会重置,导致 MCU 引导加载程序再次运行。  但是,在 MCU 初始化开始和 PLL 锁定之后,向 MCU 外围设备分配时钟的过程中会发生错误。由于在 P.O.R. 运行时可以正常工作,我认为在将系统切换到待机模式的过程中存在一些错误。 您能帮帮我吗? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 附加信息: 该项目定义了待机 RAM。RAM 从 BSS 开始分配为 32 千字节的区域。该区域在从待机模式恢复后存储必要的数据。 /*---过渡到待机模式---*/ /* 设置 RTC 计时器唤醒 WKPU0 的超时时间 */ Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds); /* 暂停所有操作系统任务 */ vTaskSuspendAll(); /* 将时钟模式初始化为待机 */ Mcu_InitClock(McuClockSettingConfig_Standby); /* 设置时钟模式 */ Mcu_SetMode(McuModeSettingConf_Standby); ..... (Reset Occur) /*---MCU 初始化---*/ /* 将待机 RAM 区域设置为不可缓存 */ MpuConfigurator_AllocateStandbyRamToNonCacheable(); /* 启用不可缓存模式 */ MpuConfigurator_Enable(); /* 初始化 MCU 模块 */ Mcu_Init(NULL_PTR); /* 运行时钟初始化设置模式 */ if (E_OK == Mcu_InitClock(McuClockSettingConfig_Run)) { /* 通过**轮询**等待 PLL 锁定 */ while (MCU_PLL_LOCKED != Mcu_GetPllStatus()) { /* 等到 PLL 锁定 */ } /* 将 PLL 时钟分配给系统 */ Mcu_DistributePllClock();  ← 这里出现错误 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 嗨,@Teruhiko、 您能找到有关该错误的更多信息吗?故障异常属于哪种类型? https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 您也可以逐步执行代码,以确定触发异常的确切位置。 检查 DCM_GPR 寄存器是否有任何错误。RM, 表 231。产品系列中由 DCM 控制的功能和可用性。 这可能是由于 RESET 后的 SRAM 初始化不正确。 有 ERM 可以对此进行监控,但默认情况下,模块的时钟处于封闭状态。 谢谢! BR,丹尼尔 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 你好,@Teruhiko、 MCU 退出待机模式后,就可以连接调试器了。 为了方便调试,可以考虑在应用程序开始时添加一个无限循环,这样就可以连接调试器,并从那里开始逐步执行。 volatile int var = 1; while(var){} 如果观察到的是 MCU_POWER_ON_RESET,而不是 MCU_WAKEUP_REASON,请检查下列寄存器:DCMROPP1-4. 谢谢! BR,丹尼尔 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 你好,丹尼尔-马蒂克先生、 对于延迟回复,我深表歉意。 由于在系统转换到待机模式时与 J-TAG 的通信会中断,因此我还无法获得详细的错误信息。我目前正在编写调试代码。 我想和大家分享一下我们目前了解到的情况。 我已经调查了以下条件下的重置原因: ・过渡到待机模式后 RTC 超时后自动恢复复位  → 重置原因:MCU_WAKEUP_REASON ・进入待机状态后,在待机模式下通过 WKPU 中断唤醒时重置恢复  → 重置原因:MCU_WAKEUP_REASON ・在过渡到待机模式后 RTC 超时后通过 WKPU 中断唤醒时重置恢复  → 重置原因:MCU_POWER_ON_RESET 我相信重置系数是正确的。 我怀疑每个重置因子的启动顺序差异是相关的。 一旦我掌握了有关错误的更多细节,我将另行回复。 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 你好,@Teruhiko、 时钟看起来不错。 一个问题:当你在 POR 之后独立运行 MCU 时(不带调试器),应用程序能运行吗? 我问这个问题的原因是,当应用程序通过调试器启动时,调试器会执行部分系统初始化。在独立组网 \\(SA\\) 操作中,应用程序必须自己处理此初始化。退出待机状态后,MCU 会重置并断开调试器的连接,因此其行为实际上与独立启动相同。 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 嗨,丹尼尔先生、 对于延迟回复,我深表歉意。 我对我们的电路设计有一些疑问,所以我在调查它与这个问题的关系。 结果,我发现电路中的端口分配有问题。 当从待机状态唤醒时发生 RESET 时,施加到 MCU 的电源电压变得不稳定。 我非常感谢你们迄今为止提供的所有支持。 非常感谢。 Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 你好,丹尼尔先生 谢谢您的建议。 重置后我能够重新连接。 当我逐步完成代码时,单片机外设初始化成功了,但当我在启动操作系统任务过程中调用 "xSemaphoreCreateRecursiveMutex() "时,程序却表现异常。 此外,当步进该函数时,在 `heap_4.c` 中函数 `void * pvPortMalloc( size_t xWantedSize )` 的以下部分,行为变得不稳定。 堆分配似乎失败了。 在过渡到待机模式之前,我应该采取哪些步骤? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 你好,@Teruhiko、 Mcu_InitClock(Standby) 配置是什么? 它仍然应该是时钟选项之一,例如 表 157.选项 A - 高性能模式(CORE_CLK @ 160 MHz)。 你说它表现不稳定或不稳定,到底是什么意思? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 嗨,丹尼尔先生、 本项目中 "运行 "和 "待机 "模式的设置如下所示。 我认为您提供的表 157 中的设置已应用于运行模式。 我还认为表 160 中的时钟值已应用于待机模式。我正在为这些方块设置时钟,这样 RTC 就可以测量时间,WKPU 可以触发重启。 当我逐步完成代码时,当前信息会显示在 IDE 控制台屏幕上。执行上述 "heapVALIDATE_BLOCK_POINTER() "时,控制台屏幕开始滚动,无法执行步骤 .   Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode 下面介绍如何过渡到待机模式。 在 MCAL MCU 模块设置中,"STANDBY "已被选为待机模式的运行模式。 ・ 在 Design Studio 的时钟工具中,我已经为 "运行 "和 "待机 "创建了不同的功能组。 1.在正常运行模式下,按 "Mcu_InitClock(Run) "和 "Mcu_SetMode(Run) "的顺序调用函数,即可在运行模式下工作。 ... 2.要过渡到待机模式,请调用 "Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds) "启动定时器,定时器将在指定时间后通过 RTC 自动唤醒处于运行模式的系统。 3.调用 "vTaskSuspendAll() "暂停所有正在运行的操作系统任务。 4. 调用 "Mcu_InitClock(Standby)",然后调用 "Mcu_SetMode(Standby) "过渡到待机模式。 调用 vTaskSuspendAll() 的原因是基于下面链接中的信息。 https://community.nxp.com/t5/S32K/S32K312-Does-FreeRTOS-need-to-be-shut-down-before-entering/m-p/1756857
記事全体を表示
VS code extension update broke RTOS viewer Hello, Until now we were using vscode tool version 1.9.20 (old), and we were using https://marketplace.visualstudio.com/items?itemName=mcu-debug.rtos-views to view the status of freertos threads (RT1189). After the update the tool no longer works and just shows "RTOS detection did not finish. It will be resumed on the next halt."  Any suggestions? Thanks Re: VS code extension update broke RTOS viewer Hi, MCUXpresso for VS Code has own RTOS viewer for a long time. Please check https://mcuxpresso.nxp.com/mcux-vscode/latest//html/RTOS-Details.html  Also, old change, the extension migrated from using Microsoft C/C++ Debug Adapter to own debug adapter based on Cortex-Debug. You have to create a new Debug Configuration that will automatically create one based on our debug adapter (you'll notice "mcuxpresso-debug" as type). PS. Please be aware that if you are using Segger debug probe, this requires special enablement for RTOS support (see https://mcuxpresso.nxp.com/mcux-vscode/latest//html/Debug-Views.html#enabling-rtos-awareness) Regards, Cristian Re: VS code extension update broke RTOS viewer Ok I got it working, we where compiling with -Og flag in debug and changing that to -O0 made the viewer work. But I guess the tool needs improvement as Og shall be default for standard edit-debug process?. Unrelated to this, I also see this warning in debug console "warning: could not convert ' \Main.cpp' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report." Thanks Re: VS code extension update broke RTOS viewer Thanks, In fact the message is coming from MCUXpresso RTOS view itself (I incorrectly referred a different plugin).  I have attached the launch.json and custom device script (it is same as MIMXRT1180-EVK.json for Linkserver 26.3.123, but the "connect-script" is "RT1180_reset.scp".  Our app runs in hyperram and uses SDK 2.16. Freertos variables are correctly set. I can debug an step through our app, but RTOS Details view still shows "RTOS detection did not finish. It will be resumed on the next halt."  Thanks Re: VS code extension update broke RTOS viewer @cristiantepus any updates on this? Re: VS code extension update broke RTOS viewer Today I found that MCUXpresso RTOS viewer does not work in release mode, and does not show anything. But https://marketplace.visualstudio.com/items?itemName=mcu-debug.rtos-views works with -Og and in release modes, but cannot work with current mcuxpresso vscode plugin (gets disabled?). Is there a way to bring that back? Re: VS code extension update broke RTOS viewer Hi @arunkumar_g, The RTOS details view we offer is relying on the existence of some symbols inside the ELF file (e.g. "FreeRTOSDebugConfig", "pxCurrentTCB", "uxCurrentNumberOfTasks", and many more). I agree that the "RTOS detection did not finish. It will be resumed on the next halt." does not guide on what went wrong and we'll make sure to make this clearer. Regarding the results you obtained for "debug" vs. "release", I'd say this is the result of compiler/linker optimizations -- required symbols are stripped-out so any consumer will not find these. In this case, not only the RTOS Details view will fail but the low-level GDB Thread Awareness (LinkServer, J-Link, PEmicro) will be unable to show and debug FreeRTOS tasks in Call Stack view. In this case, I can only suggest you make sure you update the code so that you ensure the presence of the required symbols in both, "debug" and "release" build modes. We'll make sure to update the documentation and the information from the tool to make it clear what symbols are required but are missing -- thus making the views unable to show data. You also mentioned that MCU Debug RTOS view is working in this particular case. Could be, but the last time I checked there was no support any kind of versioning support (version is found by inspecting "FreeRTOSDebugConfig"). And keep in mind that the FreeRTOS data structures are really specific to the RTOS version. To enable MCU Debug views you could ask the maintainers how to add the "mcuxpresso-debug" debug adapter (MCUXpresso specific) in the supported list. Given that you're using a project based on an old SDK 2.16, I'd also suggest switching to the latest MCUXpresso SDK based on CMake & Kconfig.   Some useful links: - RTOS Details: RTOS Details — MCUXpresso for VS Code 26.04 documentation - MCUXpresso SDK: MCUXpresso SDK Documentation — MCUXpresso SDK Documentation   Thanks, Adrian
記事全体を表示
RW612非セキュアフラッシュ設定によりリセット機能が破損する こんにちは、 FRDM-RW612上でARM TF-MとZephyr(NXPダウンストリームv4.3.0)を使用している際に、奇妙なバグが発生しています。フラッシュメモリの一部領域を、セキュリティ保護機能のないLittleFSファイルシステムに使用したいと考えています。NXPのガイド(リンク)に従ってNS領域を追加したところ、ファイルシステムにその領域を正常に使用でき、Zephyr/FS APIやアクセスに関する問題も発生しませんでした。 私の問題は、CONFIG_FLASH KConfigオプションを有効にすると、ボードをリセットできなくなることです。tfm_platform_system_reset()、NVIC_SystemReset() を呼び出したり、物理的なリセットボタンを押したりしても、プロセッサがロックされてしまい、実際にはボードがリセットされなくなります。 デバッガーを使ってステップ実行したところ、デバッガーが切り離される直前に実行された最後の行は core_cm33.h:2683 でした。(__NVIC_SystemReset内): SCB->AIRCR = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos) | (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) | SCB_AIRCR_SYSRESETREQ_Msk ); リセット後にデバッガを接続すると、GDBはアドレス0x20005840のプログラムが永久に停止すると報告します。 非常に基本的なプログラムで同じことを試してみましたが、Zephyrのhello worldプログラムにCONFIG_FLASHを追加しても、リセットが同じように失敗します。 どんなご協力でもありがたいです。ありがとうございます! Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、@jm-streametric さん。お元気でお過ごしでしょうか。 この動作をより詳細に分析するために、ハローワールドのサンプルで行ったテストにおいて、追加した設定はCONFIG_FLASHのみであることを確認してもらえますか?それとも、ガイドから作成した設定(CONFIG_TFM_CUSTOM_DATA_IMPORT_REGION=y)を使用して、追加したNS領域も有効にしていますか? 私はZephyr(v4.3.0 ダウンストリーム)のhello worldサンプルをCONFIG_FLASH設定のみを追加して実行しようとしましたが、ボードをリセットすることができました。 Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 投稿でボードを指定する際に誤りがありました。RW610を搭載したカスタムボードを使用していますが、フラッシュ構成はFRDM-RW612と全く同じです。CONFIG_FLASH=y に設定しても開発ボードをリセットすることはできますが、私のカスタムボードでは、以前の投稿で説明した問題が発生します。 TF-MとZephyrのリポジトリをFRDM-RW612のデフォルトに設定しても、CONFIG_FLASH=yの場合(カスタムデータ領域の有無に関わらず)、ボードをリセットできないという問題が発生します。RW610とRW612の間には、フラッシュメモリやFlexSPIに問題を引き起こす可能性のある違いはありますか?それとも、私のボードに別の問題があるのでしょうか? Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ジェイクさん。ご説明ありがとうございます。 RW610とRW612の違いは、RW610が802.15.4プロトコルをサポートしていないため、FlexSPI周辺機器との違いはないという点です。 これらの機能をテストする際に、FRDM-RW612ファイルを使用しているかどうか確認していただけますか?それとも、Zephyrでボード用のディレクトリを独自に作成しましたか? また、リセット機能を使わずにサンプルを正しく実行することは可能でしょうか?それとも、MCUはどこかの時点でハードフォルトを起こすのだろうか? Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 私のボードは同じフラッシュICを使用しているため、フラッシュ機能のテストには未修正のFRDM-RW612ファイルを使用しています。私のボードには様々な**ペリフェラル**が搭載されており、それぞれにオーバーレイを適用していますが、今回のフラッシュテストケースではそれらのオーバーレイは適用しません。 フラッシュメモリは正常に動作しており、カスタムリージョン内のフラッシュデータにも問題なくアクセスできます。カスタム領域外のフラッシュにアクセスするとエラーが発生しますが、これは想定内の動作です。唯一うまくいかないのは、物理的に、またはtfm_platform_system_reset()を使用してボードをリセットしようとすると、上記のようにボードがロックされてしまうことです。 ありがとう Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality ジェイクさん、情報ありがとうございます。 つまり、プロジェクトに「CONFIG_FLASH=y」設定を追加すると、アプリケーションは通常どおり実行できるが、リセット操作を行うとプログラムがアドレス0x20005840で無限ループに陥る、ということでしょうか? リセット原因が登録されているかどうかを確認するために、リセットステータスレジスタ( SYS_RST_STATUS )をご確認いただけますでしょうか?さらに、セキュリティ保護機能のないバージョンのボードで全てのテストを実施しましたか? FRDM-RW612ボードをお持ちでしたら、カスタムボードでのテストに追加しているのと同じ設定で、この現象が発生するかどうかをテストして教えていただけますでしょうか? Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 つまり、プロジェクトに「CONFIG_FLASH=y」設定を追加すると、アプリケーションは通常どおり実行できるが、リセット操作を行うとプログラムがアドレス0x20005840で無限ループに陥る、ということでしょうか? はい、その通りです。ボードの電源を一度切ってから入れ直す以外に、プログラムを再起動する方法がありません。 リセット原因が登録されているかどうかを確認するために、リセットステータスレジスタ( SYS_RST_STATUS )をご確認いただけますでしょうか? 現在、zephyrのサンプル「hello_world」を使ってこれらのテストを試しています。CONFIG_FLASH=y の有無に関わらず、またカスタムボードでも実際の FRDM-RW612 でも、SYS_RST_STATUS の値を取得できませんでした。物理的なリセットボタン(SOC上のPDnに接続)を押したり、printf文の後にtfm_platform_system_reset()を呼び出したり、NULLポインタにアクセスしてハードフォルトを発生させたりしてみましたが、いずれもリセットステータスレジスタに値が表示されませんでした。 リセット前、リセット後のアドレス 0x20005840 のループ内、およびリセット後の BL2 ステージでサンプリングを試しましたが、SYS_RST_STATUS が 0 であるかどうかは関係ありませんでした。チェック方法が間違っているかどうかわかりませんが、GDB (west attach 経由) を使用してデバッグし、 p *((PMU_Type*)0x40031000u)を印刷して PMU ブロック内の値を取得しました。参考までに、サンプリングしたときの SYS_RST_EN レジスタは常に 0x39 でした。 さらに、セキュリティ保護機能のないバージョンのボードで全てのテストを実施しましたか? はい、ビルドフォルダを削除してからwest build -b frdm_rw612/rw612/nsを実行することで、これらのテストをすべてクリーンにビルドします。 独自のボードでテストするために追加している設定と同じ設定で、この動作が発生するかどうか教えてください。 私の設定のほとんどは、Flexcommポート上のペリフェラルに関するものです。この問題に関する私のテストでは、TF-Mプロファイルに加えた変更点のみを残しました。TF-M FWUパーティションを使用して無線ファームウェアアップデートを実行できるように、私はTF-Mのラージプロファイルではなくミディアムプロファイルを使用しています。そのため、ZephyrのKConfigオプションを3つ追加しました。 CONFIG_TFM_PROFILE_TYPE_AROTLESS=y CONFIG_TFM_SFN=y CONFIG_TFM_ISOLATION_LEVEL=1 そして、TF-Mモジュールフォルダで編集したのは、modules/tee/tf-m/trusted-firmware-m/platform/ext/target/nxp/frdmrw612/config.cmakeにある以下のプロファイル設定だけです。 set(TFM_PROFILE "profile_medium_arotless" CACHE STRING "TF-Mプロファイル") これは「profile_large」から変更されたものです ご協力ありがとうございました。他に何か情報が必要な場合はお知らせください。 Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality ジェイクさん、質問に答えていただきありがとうございます。 FRDM-RW612でテストしたとのことですが、このボードでもリセット動作を再現できますか?あなたの設定とTF-Mのビルド変更(TF-Mプロファイル)を追加して試してみましたが、それでもあなたの動作を再現できませんでした。 もしこの現象を再現できるのであれば、FRDM-RW612でその動作を再現するために実行した詳細な手順を共有していただけますでしょうか? Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ローマンさん。 基板の回路図が間違っていたこと、そして私が使用していたフラッシュチップがFRDM-RW612のようなW25Q512ではなく、実際にはW25Q01だったことが分かりました。W25Q512を基板にはんだ付けしたところ、問題なくリセットできるようになりました。先ほどはお時間を無駄にしてしまい、申し訳ありませんでした。 私のチップに対応するようにフラッシュメモリの設定を再構成する方法に関する資料はありますか?flash_config.c に fc_flexspi_nor_config_t 構造体が見つかりました。これはW25Q512用に設定されているのですが、新しいチップに対応するために変更する必要がある箇所を具体的に説明したドキュメントやガイドはありますか? Re: RW612 Nonsecure Flash Setting Breaks Reset Functionality こんにちは、ジェイク。気にしないでください。根本原因を教えてくれてありがとう。 残念ながら、フラッシュメモリの再構成に関する具体的なガイドはありません。ただし、異なるフラッシュを使用する場合にどのような変更が必要になるかについては、RD-RW612-BGAボードのディレクトリ構造、またはIRIS-W1-EVKボードのディレクトリ構造(u-Blox社製)を参考にすることができます。これらのボードはどちらもFRDMボードとは異なるフラッシュICを搭載しています。 TF-Mの場合、RD-RW612-BGA非セキュアバージョンのボードのディレクトリも存在し、これも必要な変更の参考として利用できます。 お役に立てば幸いです!
記事全体を表示
如何使用 IFC-或非 启动模式在 LS2088ARDB 上启用/访问 QSPI 闪存设备。 HI 1) LS2088ARDB 可以使用 IFC-或非 启动或 QSPI 启动启动。 2) IFC-或非 和 QSPI 是混合的,因此一次只能启用其中一个。 3) 我相信选择 IFC / QSPI 的多路复用器配置是由引导程序根据 RCW 数据完成的。 4) 我的要求:使用 IFC-或非 启动模式启动后需要在 Linux 中访问 QSPI 闪存。这可能吗?如果是,能否提供 QSPI Linux 源代码。 5) 我们能否重新配置多路复用器选择(考虑 IFC-或非 启动模式)以在 Linux 级别启用 QSPI?如果是,请提供源代码。 谢谢。 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. 你好 不是 — 在 LS2088ARDB 上,如果你以 IFC-或非 模式启动,则不应指望以后会从 Linux 启用和使用 QSPI。可用的LS2088a/LayerScape文档表明,由于引脚多路复用,IFC和QSPI是相互排斥的,并且这种多路复用是在RESET期间在RCW中配置的,而不是在运行时动态重新配置。具体到 LS2088A,恩智浦指出,只有在 RCW 中才能实现引脚多路复用,"根据设计,在运行时不可能改变引脚多路复用"。, 你对启动的理解是正确的: RCW 源由复位时采样的复位配置引脚选择。 然后,预启动加载程序从 cfg_rcw_src 指定的源加载 RCW。 在 LS2088 级主板上,开关启动源可能需要更改 RCW 和不同的主板开关/跳线设置。 对于LS2088/LS2044的家庭行为,恩智浦明确证实: “当使用 QSPI 时,只能在 IFC 上使用 与非 控制器。所有其他 IFC 机器......都不能使用,因为它们的信号都经过混搭,以便在 QSPI 接口上使用"。 对于 LS2088A,必须在 RCW 中实现引脚多路复用,而且 "不可能在运行时更改引脚多路复用"。 因此,对你们问题的直接回答是 使用 IFC-NOR 启动模式启动后 Linux 能否访问 QSPI 闪存? 不,不在正常的 LS2088ARDB IFC 启动配置中。IFC 和 QSPI 是多路复用的,选择由 RCW/PinMux 在 RESET 时修复。, Linux 能否在运行时重新配置多路复用器选择以启用 QSPI,同时保持 IFC-或非 启动模式? 不。检索到的文件说,这种引脚复用只限于 RCW,不能在运行时更改。 我能得到 Linux 源代码来实现这种多路复用器切换吗? 我找不到任何 LS2088A/Linux 源代码或运行时 IFC↔QSPI 多路复用器开关的文档机制,而且硬件行为表明不支持这样的 Linux 实现。, 一个细微差别:Layerscape Linux 指南显示,可以使用不同的开关/跳线设置将 LS2088ARDB 配置为从 NOR 或 QSPI 启动,并指出更改引导设备配置可能需要更改 RCW 或其他映像。这支持了这样的结论,即这是启动/RESET 时的硬件配置选择,而不是 Linux-time 交换机   此致 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. 谢谢。这澄清了我的疑惑。
記事全体を表示
Ara240 DDR Speciification HI NXP Team, We have query Regarding Ara240 Does it support LPDDR 5 or it is restricted to LPDDR 4 only. Re: Ara240 DDR Speciification For the Ara240 only support the LPDDR4, no LPDDR5 by now. Ara240 Discrete Neural Processing Unit (DNPU) | NXP Semiconductors
記事全体を表示
添加 USB 设备 CDC 固件支持 我正在尝试将 USB CDC VCOM 设备功能添加到在基于 LPC55S26 的设计上运行的裸机固件中。我已经更新到最新的 MCUXpresso IDE 和 SDK(包括 USB 设备中间件)。当我通过外围设备工具将 USB 设备添加到项目中并配置引脚、时钟等时,会出现两个错误(均相同)和一个警告,如下所示: 错误:" USB 设备 CDC " 驱动程序在项目中缺失。 警告:工具链/IDE 项目中的 USB 通用接头版本不支持。要求:2.8.0,实际:2.12.1:要求:2.8.0,实际:2.12.1。项目可能无法正确编译。 如果我尝试添加 SDK 元器件 " USB Device CDC " 我会收到一条消息,说在 SDK 中找不到该元器件,但是当我查看可用的 SDK 元器件时,它确实存在。如有任何建议,不胜感激。 Re: Add USB Device CDC firmware support 你好@markpotts123、 感谢您的来信。我注意到你也有一个关于同一主题的私人案例,我已经在那里给你回复了。如果您有任何新的更新,请随时回复,我将继续支持您。 祝您愉快 BR 西莱斯特 Re: Add USB Device CDC firmware support 原来是 IDE 和 SDK 版本不匹配。旋转到最新版本后,症状得到了解决。
記事全体を表示
HSE_IP核无法添加 Hello nxp的技术支持, 我在使用S32DS IDE3.6.2版本,RTD6.0.0版本,我无法在外设配置的界面添加HSE的IP核,可能会导致配置文件无法自动生成hse_mu的driver,请问一下这个问题该怎么解决? BR/chenyuhang Re: HSE_IP核无法添加 Hi @lukaszadrapa , 感谢您的回复,我目前已经安装了6.0.0 QLP01的包并且已经可以在外设中添加HSE的IP核了。我还有一个疑问想问您,就是我在使用HSE的时候,已经将 C:\NXP\HSE_FW_S32K344_0_2_55_0\hse_full_mem\interface 下的全部文件添加到工程中了,那么 Framework 和 services 文件夹应该如何添加?(附录的图中展示的工程结构是C:\NXP\S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\Key Management\S32K344_DemoApp_SessionKeys 的示例工程),是否可以通过外设配置界面添加到工程中?还是说需要手动将这两个文件夹粘贴到我自己的工程中?另外我有查阅到nxp的中国团队有做过HSE_Lib2.0的内容,这些资料我应该如何获取? BR/chenyuhang Re: HSE_IP核无法添加 你好@chenyuhang 可能会出现并非所有模块都包含在 RTD 软件包中的情况。RTD 6.0.0 就是这种情况,当时还没有 Crypto 驱动程序。它后来在 6.0.0 QLP01 软件包中提供: 在版本说明文件中,您可以发现该软件包仅提供 Crypto 驱动程序,因此您可以将其安装在 6.0.0 软件包之上: 此致, Lukas Re: HSE_IP核无法添加 该框架只是纯 C 代码,不能通过外设配置界面添加。应手动将其添加到项目中。 让我分享一下我之前写给另一位客户的答案--可能是数据缓存出了问题: "我可以看到,该框架尚未完全准备好无缝实施 RTD 项目。我刚刚发现,我在这里的所有项目实际上都禁用了缓存。 该框架使用一个描述符数组,在运行时根据需要选择这些描述符。有一个定义 HSE_ENABLE_SHARED_MEM,可用于将数组强制转入共享区域。但是,默认情况下并不使用这个地址,而且我可以看到,它可能因为使用了一些奇怪的地址而无法工作。 那么,看看 hse_host.c 中的实现吧并将描述符数组也强制设置为 no_cachable 区域"。 关于 HSE_Lib,这是中国应用程序团队的一个项目,目前尚未公开。请与当地的恩智浦 FAE 或分销 FAE 讨论。 此致, Lukas
記事全体を表示
S32N55 模块中 FSS 的 GPIO 组不匹配 Rem_Cm 您好, 每个实例的 GPIO 库数量可以从参考手册中获得。 不过,在 EB 模块 Rem_Cm 中的 vGPIO 配置中,上述每个实例都可以选择三个组。    这是预期行为,还是说明存在潜在问题? BR 亚历克斯 RTD Re: S32N55 mismatch GPIO banks of FSS in the module Rem_Cm 嗨,@Alex_Liu、 在我看来,这个问题是 RTD 驱动程序的一个错误。我已就此问题向 RTD 团队提交了故障单(ARTDCMCR-1327)。 顺祝商祺! 丹
記事全体を表示
LS1028a TSN 网络配置:有其他接口吗? 你好,我计划使用 LS1028A 开发 TSN 端点设备。不过,我在 REALTIMEEDGEUG.pdf 文档中发现,要通过网络接口配置 TSN,需要将 PC 连接到 eneth 的 eno0 接口。问题是,我还需要用这个接口作为端点接口来连接外部交换机。我想知道是否可以使用 eneth 的 eno1 接口进行网络配置,或者是否可以将 PC 连接到交换机的一个端口(swp0-4)来执行 TSN 配置。
記事全体を表示
IMXRT1176 FBB_DISABLEヒューズはすでに設定されています こんにちは、 i.MX-RT1170 MCU を搭載した新しいカスタム ボードがいくつかあるのですが、ヒューズを確認すると、空になっているはずです。これらすべてのアドレスにはFBBを無効にするヒューズFBB_DISABLE[4]が設定されています。デフォルトではすべてのヒューズが設定されていないと予想していました。設定を解除することはできないからです。 ここで何が起こっているのですか? よろしくお願いいたします。 エイドリアン Re: IMXRT1176 FBB_DISABLE Fuse is already set @Gavin_Jiaご返信ありがとうございます。わかりました。 このヒューズが設定されていないボードもいくつかありました。しかし、これらは別の部品番号であった可能性があります。 このヒューズが設定されている部品番号と設定されていない部品番号のリストはありますか? Re: IMXRT1176 FBB_DISABLE Fuse is already set こんにちは@bia-bonobo さん、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 FBB_DISABLE は工場で設定されており、チップの部品番号に関連しています。フラグビットのように機能します。データシート/RM の注記を参照してください。 よろしくお願いします、 ギャビン   Re: IMXRT1176 FBB_DISABLE Fuse is already set こんにちは@bia-bonobo さん、 より正確な説明は、FBB_DISABLE はチップ自体に固有のものであり、工場で構成されているということです。RT1170 をオーバードライブ モードで動作させる必要がある場合、まず FBB_DISABLE を読み取り、次に FBB を有効にするかどうかを判断する必要があります。 部品番号に対応する公開リストはありません。これはプロセス/チップ自体の特定の特性によって異なります。したがって、データシートに記載されているように、ソフトウェア フローは最初に FBB_DISABLE を読み取る必要があります。 よろしくお願いします、 ギャビン Re: IMXRT1176 FBB_DISABLE Fuse is already set 分かりました。ありがとうございます!
記事全体を表示
LPC5411x PLL設定 こんにちは 現在のプロジェクトでは、LPC5411x の PLL モジュールを使用しています。データシートのセクション 6.5.49.6 によれば、PLL の N、M、および P 値は、対応するレジスタに書き込む前に計算する必要があります。 ただし、 SDK_2_9_0_LPCXpresso54114では、NDEC、MDEC、および PDEC の計算コードは実装されていません。代わりに、次に示すように、SDK は手動で事前に計算された値を syspllndec レジスタに直接書き込みます。(M=75 に設定したいので、MDEC=9637 を手動で計算し、 SYSCON_SYSPLLSSCTRL0_MDECに設定する必要があります) 今後の SDK リリースで、NDEC、MDEC、PDEC の計算機能を SDK に追加する予定はありますか? 現在、NDEC、MDEC、PDEC の設定は直感的ではなく、M、N、または P を変更するたびに、対応する NDEC、MDEC、PDEC 値を手動で再計算する必要があるため、維持が困難です。 よろしくお願いします。 LPC54xxx Re: LPC5411x PLL settings こんにちは@yhc123 ご投稿ありがとうございます。 現在、LPC5411 の新しい SDK バージョンをリリースする予定はありません。必要な計算はすべてお客様側で実装する必要があります。ご不便をおかけして申し訳ございません。
記事全体を表示
i.MX 93 EVK debug console relocation [Continued] Introduction. This is an update to the previous article i.MX 93/91 debug console relocation with Yocto Project. It was initiated because a customer wanted to replicate the mentioned document in newer BSPs. i.MX93EVK uses LPUART1 as the debug console, this article will contribute to relocate debug console to LPUART2, which is connected to USB-to-UART FTDI bridge, so it's very easy to confirm your changes. Key differences from the past article are we don't explore porting tools but provide specific instructions and code, you will follow this article to confirm changes made on your own or replicate this process, if you want to explore BSP customizing tools and process, review the other article. BSP version is LF-6.12.49 Yocto Walnascar. HW setup simplifies too. 1. Hardware Setup. i.MX93EVK featuring REV A1. Connect USB Type-C PD power source to J301. Connect USB type-C cable to USB debug J1401. Connect USB type-C cable to USB1 J401. [Optional] SD card for booting, eMMC is the other option. 2. Yocto Project setup for recipes development. Start by creating a fresh build. $ cd ~ $ mkdir Yocto-BSP $ cd Yocto-BSP $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-walnascar -m imx-6.12.49-2.2.0.xml $ repo sync You can build any image, custom projects may need multiple builds for development, then imx-image-core is a great option since it's light and compiling it requires less time. $ MACHINE=imx93-11x11-lpddr4x-evk DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b i.MX93 $ bitbake imx-image-core OE Connectivity Sanity Checker can cause issues if not configured, you can skip host connectivity tests. Patches provided in this document are for testing purposes, they lack upstreaming status to Yocto Project as they simulate an early starter porting process, you can disable QA errors that interrupt bitbaking and turn them to warnings. ERROR: do_patch: QA Issue: Missing Upstream-Status in patch Please add according to https://docs.yoctoproject.org/contributor-guide/ ERROR: do_patch: Fatal QA errors were found, failing task. ERROR: Task failed with exit code '1' Make the following modification. $ nano conf/local.conf CONNECTIVITY_CHECK_URIS = "" ERROR_QA:remove = "patch-status" WARN_QA:append = " patch-status" 3. Add debug-console-relocation layer to Yocto environment build. As said at the introduction, you are provided with the meta-layer zipped so you can just move it to your Yocto build directory. # Feel free to change this path to your download path $ cd ~ $ unzip meta-imx-console.zip $ cp -r meta-imx-console ~/Yocto-BSP/sources $ cd ~/Yocto-BSP/i.MX93 $ bitbake-layers add-layer meta-imx-console $ bitbake-layers show-layers You should be able to see the following output layer path priority ======================================================================================================== core /home/joseph/Yocto-Console/sources/poky/meta 5 yocto /home/joseph/Yocto-Console/sources/poky/meta-poky 5 openembedded-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-oe 5 multimedia-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-multimedia 5 meta-python /home/joseph/Yocto-Console/sources/meta-openembedded/meta-python 5 freescale-layer /home/joseph/Yocto-Console/sources/meta-freescale 5 freescale-3rdparty /home/joseph/Yocto-Console/sources/meta-freescale-3rdparty 4 freescale-distro /home/joseph/Yocto-Console/sources/meta-freescale-distro 4 fsl-bsp-release /home/joseph/Yocto-Console/sources/meta-imx/meta-imx-bsp 8 fsl-sdk-release /home/joseph/Yocto-Console/sources/meta-imx/meta-imx-sdk 8 imx-machine-learning /home/joseph/Yocto-Console/sources/meta-imx/meta-imx-ml 9 v2x-imx /home/joseph/Yocto-Console/sources/meta-imx/meta-imx-v2x 9 imx-demo /home/joseph/Yocto-Console/sources/meta-nxp-demo-experience 7 nxp-matter-baseline /home/joseph/Yocto-Console/sources/meta-nxp-connectivity/meta-nxp-matter-baseline 7 nxp-openthread /home/joseph/Yocto-Console/sources/meta-nxp-connectivity/meta-nxp-openthread 7 meta-arm /home/joseph/Yocto-Console/sources/meta-arm/meta-arm 5 arm-toolchain /home/joseph/Yocto-Console/sources/meta-arm/meta-arm-toolchain 5 clang-layer /home/joseph/Yocto-Console/sources/meta-clang 7 gnome-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-gnome 5 networking-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-networking 5 filesystems-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-filesystems 5 perl-layer /home/joseph/Yocto-Console/sources/meta-openembedded/meta-perl 5 qt6-layer /home/joseph/Yocto-Console/sources/meta-qt6 5 parsec-layer /home/joseph/Yocto-Console/sources/meta-security/meta-parsec 5 tpm-layer /home/joseph/Yocto-Console/sources/meta-security/meta-tpm 6 virtualization-layer /home/joseph/Yocto-Console/sources/meta-virtualization 8 meta-freescale-ml /home/joseph/Yocto-Console/sources/meta-freescale-ml 8 meta-imx-console /home/joseph/Yocto-Console/sources/meta-imx-console 9 * Remember to run all steps within the Yocto session, otherwise source your setup again. * $ cd Yocto-BSP $ source imx-setup-release.sh -b i.MX93 4. Rebuild the core image. Perform bitbake command again, it unpacks, patches, builds, deploys the source code and creates the root filesystem again with only running a few tasks. NOTE: Tasks Summary: Attempted 11106 tasks of which 10941 didn't need to be rerun and all succeeded.  You can find the images for flashing under the build folder. $ cd tmp/deploy/images/imx93-11x11-lpddr4x-evk/ $ zstd -d imx-image-core-imx93-11x11-lpddr4x-evk.rootfs-*.wic.zst imx-image-core-imx93-11x11-lpddr4x-evk.rootfs-20260207040424.wic.zst: 2596424704 bytes Flash the imx-boot firmware and imx-image-core root filesystem. $ uuu -b emmc_all imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot imx-image-core-imx93-11x11-lpddr4x-evk.rootfs-*.wic Conclusions. You can open the consoles for Cortex-A and Cortex-M to experiment booting a normal image and the relocated LPUART image. * This new image would require Cortex-M demos to change debug console to LPUART1. *  Debug console outputs through LPUART2 and prints a custom message.  Normal image debug console. Remember that the patches below are provided as is, they were developed under LF-6.12.49. When using them you are subject to the record of acceptance and legal compliance from EULA agreement in your Yocto build. If applying them under other circumstances (another BSP repository, another Yocto version, etc.) or the same circumstances, and they fail, please create a support ticket to help you. Extras. If you compare the differences at patch-level, you can see that only a file was relocated in U-boot, the file containing the environment variables was renamed and the syntax changes a little. The procedure performed was the same as the last article, if you are making your own layer, remember to modify conf/layer.conf with: BBFILE_PRIORITY_meta-imx-console = "9" #LAYERDEPENDS_meta-imx-console = "core" i.MX 93 EVK LF-6.12.49 patches
記事全体を表示
S32G:为什么 QSPI_IP_HyperflashProgram 每 2 字节发送一次写入命令? 专家们好 CTM: 法雷奥 平台:S32G3 模块:RTD 5.0.0QLP04 Fls 驱动程序 客户报告说,他们遇到的或非闪存写入吞吐量明显低于预期。 客户可能想知道为什么 QSPI_IP_HyperflashPro gram 函数 2 字节以 2 字节传输数据。看来这就是瓶颈所在。 是否有专家能就这一问题提供帮助? 感谢你的支持 狮子座 RTD Re: S32G: why the Qspi_Ip_HyperflashProgram sends write command for every 2 bytes? 你好@Nhi_Nguyen 谢谢您的帮助。但是在我们的驱动程序中一次写入 2 字节对客户来说太慢了吗?怎样才能提高性能? BR、 狮子座 Re: S32G: why the Qspi_Ip_HyperflashProgram sends write command for every 2 bytes? 你好@LeoLiAP、 这是因为 Hyperbus 支持以下两种类型的数据发送: 驱动程序支持将单个字写入内部缓冲(您的代码是每个地址数据的单个字),然后调用命令将缓冲区发送到 Fls(写入缓冲区)。 顺祝商祺! Nhi Re: S32G: why the Qspi_Ip_HyperflashProgram sends write command for every 2 bytes? 你好@LeoLiAP、 写入 2 字节遵循 Hyperbus 协议,所以我知道我们无法改变这一点。但 SW 团队将改进代码以节省时间,相关票据为ARTDCMEM-1247。 顺祝商祺! Nhi
記事全体を表示
Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hi Experts, The customer's new BMS project wants to use S32K358 + FS27 + BMS GEN2 SDK. I learned from the BMS team that: BMS GEN2 SDK AUTOSAR 4.4 R21-11 Version 0.9.1 CD05 and BMS GEN2 SL SDK AUTOSAR 4.4 R21-11 Version 0.9.1 CD05 will be available next week. This supports S32K3 RTD 6.0.0 integration. The BMS GEN2 SDK will be migrated to S32K3 RTD 6.0.0 in BMS release v1.0.0 somewhere in Q1 '26. In other words, the BMS GEN2 SDK will be compatible with S32K3 RTD 6.0.0 in the near future. The customer needs a 24V platform and therefore wants to use FS27 instead of FS26. I found the following two versions of FS27 from Automotive SW - SBC/PMIC - Real Time Drivers: S32K3xx SBC FS27 R21-11 0.8.0 based on S32K3 RTD 5.0.0 SBC FS27 R23-11 1.0.0 based on S32K3 RTD 7.0.0 Q1. The customer is concerned that the drivers for FS27 and BMS GEN2 SDK are incompatible because the S32K3 RTD versions do not appear to be consistent.  If S32K3 RTD 6.0.0 is selected in the BMS GEN2 SDK, will there be any problems if the customer uses S32K3xx SBC FS27 R21-11 0.8.0 or SBC FS27 R23-11 1.0.0? Q2. Does the FS27 have a driver based on S32K3 RTD 6.0.0? Would you please help me? Thank you for the help in advance! Best Regards, Robin Here is the information of customer: Contact Name                TengHsaing Wen Email (Contact)              [email protected] Company                        XINGMOBILITY AA SW - External Device Priority: MEDIUM Source: Direct Customer Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hi Viktor, Thank you for your information. The "BMS GEN2 SDK AUTOSAR 4.4 R21-11 Version 0.9.1 CD05" based on S32K3 RTD 6.0.0 is not yet available for download. Once it becomes available for download, I will at least test whether it can be compiled successfully. Best Regards, Robin Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hello Robin, there is no dedicated release for RTD 6.0.0, but the latest version (FS27 1.0.0) should be backwards compatible with it. In case of any issues, please let us know. Best regards, Viktor Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD The topic has been redirect to the team to investigate it. Contact point: Razvan Tilimpea / Cristian Durla or Viktor Obr Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hi Viktor, "BMS GEN2 SDK AUTOSAR 4.4 R21-11 Version 0.9.1 CD05" is now available for download.  The customer questioned whether the AUTOSAR versions of the two drivers, R23-11 and R21-11, would differ significantly and cause compatibility issues if they were paired with SBC FS27 R23-11 1.0.0. Best Regards, Robin Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hi @viktorobr , "BMS GEN2 SDK AUTOSAR 4.4 R21-11 Version 0.9.1 CD06" is now available for download.  The customer questioned whether the AUTOSAR versions of the two drivers, R23-11 and R21-11, would differ significantly and cause compatibility issues if they were paired with SBC FS27 R23-11 1.0.0. Best Regards, Robin Re: Consulting on the compatibility of FS27 RTD and BMS GEN2 RTD Hi Robin, compatibility between different Autosar versions is tricky, we would have to compare all of the drivers used by both of the components you try to integrate and I'm not 100% familiar with the BMS SDK. I can tell you that between the FS27 versions and the drivers it uses we didn't notice major changes between R21-11 and R23-11, there might be some minor differences that will appear right away when you combine the components in one project (version specific macros etc.), but from functional point of view it should still behave the same. Best regards, Viktor
記事全体を表示
LS1046カスタムボードにおけるDDR4キャリブレーションの問題 良い一日! 私たちはカスタム LS1046 ベースのボードを立ち上げようとしていますが、DDR4 のキャリブレーション手順に行き詰まっています。 モジュールのSPDデータは正常に表示され、キャリブレーションプロセスも正常に開始されますが、その後、この理由で失敗します(CodeWarriorのログ 😞  ################################# 実行 1 検索結果: wrlvl_searcher ###################################### テスト結果: [ ============================================================ 更新日: WRLVL_CNTL = 0x8655F605、WRLVL_CNTL_2 = 0x00000000、 WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F60A、WRLVL_CNTL_2 = 0x0B0B0C0F、 WRLVL_CNTL_3 = 0x0F10110D、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F60A、WRLVL_CNTL_2 = 0x0B0B0C0F、 WRLVL_CNTL_3 = 0x0F101115、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F60A、WRLVL_CNTL_2 = 0x0B0B0C0F、 WRLVL_CNTL_3 = 0x0F10111D、SDRAM_CLK_CNTL = 0x02800000 書き込みレベリングの開始値は正しいので、これ以上の変更は必要ありません。 しかし、他の問題によりテストは失敗しました。 最も一般的な障害の原因: -DDR4 DQn_MAPレジスタに設定された値が正しくない -ODT値が正しくない - 間違ったドライバー強度が選択されました -タイミング構成0プロパティ(TIMING_CFG_0レジスタ)に選択されたタイミング値が正しくありません <<テストに失敗しました!>> {{Write Leveling start values are correct and require no further modification, but the test failed due to other issues.}} えーっと。キャプチャレジスタ: 0xE20, 0xDEADBEEF 0xE24、0xDEADBEEF 0xE28, 0x00000000 0xE40, 0x00000000 0xE44, 0x00000000 0xE48, 0x0000001D 0xE4C、0x60FF2001 0xE50, 0x00001FC0 0xE54, 0x00000000 0xE58, 0x00010000 ############################################ DQ マッピングは問題ないようです。CPU から DDR スロットへのマッピングは 1:1 SO、DDR モジュール SPD からの DQ マッピングを変更せずに使用します。 何が問題なのでしょうか? Re: DDR4 calibration issues on LS1046 custom board お客様ボード上で利用可能な RCW はありますか? ASLEEP LED は点灯したり消えたりしましたか? DDRクロックの周波数はどれくらいですか? よろしくお願いします。 Re: DDR4 calibration issues on LS1046 custom board DDR キャリブレーションは、ハードコードされた RCW を使用して実行されます。 システムクロック - 100 MHz DDRバスクロック - 800 MHz、DDRデータレート - 1600 mt/s メモリ モジュール - 非 ECC。 興味深い点の 1 つは、タイマーから時間まで、キャリブレーションの第 1 段階 (wrtlvl 検索) が正常に通過したことです。 例: テスト結果: [ ===================================================== 更新日: WRLVL_CNTL = 0x8655F605、WRLVL_CNTL_2 = 0x00000000、 WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0E、 WRLVL_CNTL_3 = 0x0F10110D、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0E、 WRLVL_CNTL_3 = 0x0F101115、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新日: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0F、 WRLVL_CNTL_3 = 0x0F10111D、SDRAM_CLK_CNTL = 0x02800000 《テスト合格!》 Err.captureレジスタ: 0xE20, 0x00000000 0xE24, 0x00000000 0xE28,0x00000000 0xE40,0x00000000 0xE44,0x00000000 0xE48, 0x0000001D 0xE4C, 0x00000000 0xE50,0x00000000 0xE54,0x00000000 0xE58, 0x00010000 ごみ: 0xF00,0x00000000 0xF04, 0x00000002 0xF08, 0x0000000F 0xF0C,0x14000C20 0xF10, 0x00000000 0xF14, 0x00000000 0xF18, 0x00000000 0xF1C, 0x00000000 0xF20, 0x00000000 0xF24, 0x2F003000 0xF28, 0x32003400 0xF2C, 0x39003B00 0xF30, 0x3C003E00 0xF34, 0x00005000 0xF38, 0x00000000 0xF3C, 0x00000000 0xF40, 0x00000000 0xF44, 0x00000000 0xF48, 0x00000001 0xF4C, 0xD4000000 0xF50, 0x13001500 0xF54, 0x17001900 0xF58, 0x1D001F00 0xF5C, 0x21002200 0xF60, 0x3A000000 0xF64, 0x00009000 0xF68, 0x00000020 0xF6C, 0x00000000 0xF70, 0x0070006F 0xF74, 0x00000000 0xF78, 0x00000000 0xF7C, 0x00000000 0xF80, 0x00000000 0xF84, 0x00000000 0xF88, 0x00000000 0xF8C, 0x00000000 0xF90, 0x00000000 0xF94, 0x80000000 0xF98, 0x00000000 0xF9C, 0x34043104 0xFA0, 0x35043304 0xFA4, 0x31043304 0xFA8, 0x2F043104 0xFAC, 0x04040000 0xFB0, 0x00000003 0xFB4, 0x1F1E1F21 0xFB8, 0x1E1C1F1D 0xFBC, 0x1F1B1D1E 0xFC0, 0x1C1B1C1C 0xFC4, 0x1F1E1F22 0xFC8, 0x1F1F2120 0xFCC, 0x1F1E1F20 0xFD0, 0x1C1D201F 0xFD4, 0x1F1B1B1E 0xFD8, 0x1F1D1E1C 0xFDC, 0x1F1F1D1F 0xFE0, 0x1F1D1E1C 0xFE4、0x1F1C191A 0xFE8、0x1C1D1C1A 0xFEC、0x1F1E1C1E 0xFF0, 0x1E1F1E1A 0xFF4, 0x1F1F1F1F 0xFF8, 0x1F1F1F1F 0xFFC、0x1F000000 データ: 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000f 0x0000000f 0x00000010 0x00000011 0x0000001d   その直後に、(設定を変更せずに)キャリブレーション プロセスを再度開始すると、失敗します。 ######## ## Result for: wrlvl_searcher ## #### テスト結果: [ 更新: WRLVL_CNTL = 0x8655F605、WRLVL_CNTL_2 = 0x00000000、 WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0E、 WRLVL_CNTL_3 = 0x0F10110D、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0E、 WRLVL_CNTL_3 = 0x0F101115、SDRAM_CLK_CNTL = 0x02800000 ============================================================ 更新: WRLVL_CNTL = 0x8655F609、WRLVL_CNTL_2 = 0x0A0B0C0E、 WRLVL_CNTL_3 = 0x0F10111D、SDRAM_CLK_CNTL = 0x02800000 書き込みレベリングの開始値は正しく、それ以上の変更は必要ありませんが、テスト その他の問題により失敗しました。最も一般的な障害の原因: - DDR4 DQn_MAPレジスタに設定された値が正しくない - ODT値が正しくない - 間違ったドライバ強度が選択されました - タイミング構成0プロパティ(TIMING_CFG_0レジスタ)に選択されたタイミング値が正しくありません <<テストに失敗しました!>> {{Write Leveling start values are correct and require no further modification, but the test failed due to other issues.}} エラーキャプチャレジスタ: 0xE20, 0xDEADBEEF 0xE24, 0xDEADBEEF 0xE28, 0x00000000 0xE40, 0x00000000 0xE44, 0x00000000 0xE48, 0x0000001D 0xE4C, 0x60FF2001 0xE50, 0x00001FC0 0xE54, 0x00000000 0xE58, 0x00010000 ごみ: 0xF00, 0x00000000 0xF04, 0x00000002 0xF08, 0x0000000E 0xF0C, 0x14000C20 0xF10, 0x00000000 0xF14, 0x00000000 0xF18, 0x00000000 0xF1C, 0x00000000 0xF20, 0x00000000 0xF24, 0x2F003100 0xF28, 0x33003400 0xF2C, 0x3A003A00 0xF30, 0x3C003E00 0xF34, 0x00005000 0xF38, 0x00000000 0xF3C, 0x00000000 0xF40, 0x00000000 0xF44, 0x00000000 0xF48, 0x00000001 0xF4C, 0xD4000000 0xF50, 0x13001500 0xF54, 0x17001900 0xF58, 0x1D001F00 0xF5C, 0x21002200 0xF60, 0x3A000000 0xF64, 0x00009000 0xF68, 0x00000020 0xF6C, 0x00000000 0xF70, 0x0070006F 0xF74, 0x00000000 0xF78, 0x00000000 0xF7C, 0x00000000 0xF80, 0x00000000 0xF84, 0x00000000 0xF88, 0x00000000 0xF8C, 0x00000000 0xF90, 0x00000000 0xF94, 0x80000000 0xF98, 0x00000000 0xF9C, 0x31022F02 0xFA0, 0x33023102 0xFA4, 0x30023102 0xFA8, 0x2E022F02 0xFAC, 0x02020000 0xFB0, 0x10000003 0xFB4, 0x46444650 0xFB8, 0x45445142 0xFBC, 0x51445052 0xFC0, 0x46454544 0xFC4, 0x45434651 0xFC8, 0x44455045 0xFCC, 0x46455051 0xFD0, 0x45455146 0xFD4, 0x52505052 0xFD8, 0x52505246 0xFDC, 0x50464546 0xFE0, 0x51465042 0xFE4, 0x53464650 0xFE8, 0x52515145 0xFEC, 0x50454546 0xFF0, 0x45505142 0xFF4, 0x46464646 0xFF8, 0x52515350 0xFFC, 0x00000000   データ: 0x00000009 0x0000000a 0x0000000b 0x0000000c 0x0000000e 0x0000000f 0x00000010 0x00000011 0x00000025 ######################################################## また、DDR モジュールが非 ECC であり、プロジェクト設定で ECC が無効になっているにもかかわらず、キャリブレーション プロセス中にレーン 8 がプローブされていることに気付きました。   Re: DDR4 calibration issues on LS1046 custom board 1. QCVS はハードコードされた RCWオフィシャルをサポートしていないため、有効な RCW がRCW ソース フラッシュまたは SD カードに存在している必要があります。 まず RCW をフラッシュにプログラムし、次に QCVS DDR 検証を行ってください。 2. CCS で以下のコマンドを実行します。 (ビン)42%すべて削除 (bin)43%config cc cwtap (ビン)44%ccを表示 (bin) 45 % ccs::config_chain {ls1043a dap sap2} (bin) 46 % 表示 ::ccs::get_config_chain (bin) 47 % ccs::reset_to_debug ログを私に送ってください。 3.回路図を共有してレイアウトが以下の通りであることを確認してください。 AN5097、DDR4 SDRAMメモリインターフェースのハードウェアおよびレイアウト設計の考慮事項 よろしくお願いします。 Re: DDR4 calibration issues on LS1046 custom board この問題は、QCVS の新しいバージョン (4.27.0) にアップデートすることで解決しました。
記事全体を表示
MMA8693 加速度计的参考寄存器设置 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我能否使用 MMA8693 找到新项目的参考寄存器设置? 现在我只想让它感知到明显的动作。(例如:停止 → 移动) 我想可能是在图形用户界面上找到的。 加速度传感器 Re: Reference register setting for MMA8693 accelerometer <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,HJ、 对不起,我昨天不在办公室,耽误了您的回复。 无论选择的动态范围如何,运动和瞬态检测功能的阈值分辨率都是 0.0625g/LSB,而且无法提高。您说得没错,瞬态检测功能只适用于 MMA8652FC,而且除非 HPF_BYP 位被设置,否则它分析的是高通滤波数据。 此致, 托马斯 Re: Reference register setting for MMA8693 accelerometer <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,托马斯、 我删除了之前的问题,因为我找到了问题所在。 门槛有问题。 我还有一个问题。 是否有可能使 MMA8653 不受重力等直流因素的影响而变得更加灵敏? 我想,如果使用 MMA8652 及其 HPF,可能会很容易。 但我的客户想用 MMA8653 找到路。 请给我一点提示。 谢谢! Re: Reference register setting for MMA8693 accelerometer <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 谢谢! Re: Reference register setting for MMA8693 accelerometer <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨,HJ、 能否请您说明所用加速度计的确切零件编号?如果是 MMA8653FC,则可以使用嵌入式移动侦测功能。有关该功能的更多信息,包括寄存器设置示例,请参阅AN4070。 希望对您有所帮助。 此致, 托马斯 PS: 如果我的回答有助于解决您的问题,请标记为"正确" 或 "有帮助"。谢谢。
記事全体を表示