Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
MHW-N1921デジタル高効率AC / DC共振電源 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 共振AC/DC電源は、高出力で優れた効率を発揮します。TEA1916は、共振LLC設計の複雑さを簡素化し、簡単なチューニングを提供するデジタルコントローラーです。これは、多くの共振スイッチモード電源で使用されている非常に一般的なTEA1716を継承します。PCやテレビですが、TEA1916は実際には75W>あらゆる電源に非常に適しています。医療、産業用、サーバー用電源。このTEA1916は、新しいデジタル・サイクル・バイ・サイクル・アーキテクチャ(Vcap制御)を使用して、低電力負荷での新しいタイプの動作を可能にします。これにより、正確に制御されたバーストモード動作を使用して、低出力電力での効率が向上します。また、このTEA1916は、スタンバイ状態またはオフ状態で非常に低い消費電力を実現します。競合他社と差別化するための主要なパフォーマンスパラメータです。最高の効率を得るために、TEA1916はNXPのTEA1995同期整流器と一緒に優れた働きをします。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 共振AC/DC電源は、高出力で優れた効率を発揮します。TEA1916は、共振LLC設計の複雑さを簡素化し、簡単なチューニングを提供するデジタルコントローラーです。これは、多くの共振スイッチモード電源で使用されている非常に一般的なTEA1716を継承します。PCやテレビですが、TEA1916は実際には75W>あらゆる電源に非常に適しています。医療、産業用、サーバー用電源。このTEA1916は、新しいデジタル・サイクル・バイ・サイクル・アーキテクチャ(Vcap制御)を使用して、低電力負荷での新しいタイプの動作を可能にします。これにより、正確に制御されたバーストモード動作を使用して、低出力電力での効率が向上します。また、このTEA1916は、スタンバイ状態またはオフ状態で非常に低い消費電力を実現します。競合他社と差別化するための主要なパフォーマンスパラメータです。最高の効率を得るために、TEA1916はNXPのTEA1995同期整流器と一緒に優れた働きをします。 セキュアモバイル |ヘルスケア&ウェアラブル
記事全体を表示
USBウェイクアップを備えた低電力モード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Kinetisファミリには、豊富な低消費電力モードがあります。お客様は、低電力モードからウェイクアップする別の方法を理解するのに混乱する可能性があります。 1) VLPR では、VLPW: NVIC は割り込みの影響を受け続けるため、割り込みはすべて処理されます。 2)停止、VLPSでは、デバイスは USB ウェイクアップ割り込みによってのみウェイクアップできます。 3)LLSでは、VLLSx:デバイスはどの USB ソースから もウェイクアップ できません。 4) LLWUは ウェイク アップに使用されるため、お客様は利用可能なLLWU ウェイク アップソースのいずれかから ウェイク アップできます。 USBモジュールに関しては 、 USB 再開イベントには2つの異なる割り込みがあります。1つは、 USB ライン の状態の変化によって トリガーされる低電力モードから ウェイクアップ できるようにするための非同期です。もう 1 つは同期しており、K 状態 (フル スピードの場合は D+ = 0、D- = 1) を検出してから 2.5 us 後にのみトリガーされます。アプリケーションは、必要なときにいつでも低電力モードに移行する責任があり、この目的のために 、USB スタックによって報告されたデバイスの状態を確認する必要があります。バス で サスペンド状態が検出されると、SLEEP割り込みがトリガーされ、スタックの状態がサスペンドに変わります。その後、アプリケーションは低電力モードに移行します。この SLEEP 割り込みが発生すると、非同期 ウェイク 割り込みが有効になり、トリガーされると無効になります (これは、モジュールが割り込みをクリアするために必要です)。通常の状態では、同期再開割り込みまたはリセット割り込みが後でトリガーされ、スタックの状態が中断以外に遷移します。その後、アプリケーションは通信が再びアクティブになったことを認識し、再び低電力モードに入るのを回避できます。
記事全体を表示
フリースケールのコンシューマ/産業用アナログ製品の紹介 - 広州 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、MMPF0100/200パワー・マネージメント集積回路(PMIC)を含むコンシューマおよび産業用アナログ製品を紹介し、この業界分野で既存の車載用アナログ製品を販売するための新しい戦略について説明します。 スティーブン・ヤンによる発表 2015年6月10日、広州市のDwF Kinetis MCUs Based on ARM®テクノロジで発表 セッションID: APF-IND-T1015 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このセッションでは、MMPF0100/200パワー・マネージメント集積回路(PMIC)を含むコンシューマおよび産業用アナログ製品を紹介し、この業界分野で既存の車載用アナログ製品を販売するための新しい戦略について説明します。 スティーブン・ヤンによる発表 2015年6月10日、広州市のDwF Kinetis MCUs Based on ARM®テクノロジで発表 セッションID: APF-IND-T1015 パワー・マネジメント センサ
記事全体を表示
AMF-ACC-T1647 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 以太网已成为汽车通信领域最受讨论的技术之一。本演示将概述汽车以太网的标准。并解决在不同应用程序中实施该技术所面临的挑战。
記事全体を表示
如何为 KSDK 和 PEx 项目的新 MQX RTOS 添加 MFS 和 Shell 支持 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大家好, 基于如何使用 KDS 和 KSDK 将 RTCS 添加到处理器专家项目,您可以在下面找到使用 KSDK1.2 和处理器专家将 MFS 和 Shell 包含到 KDS3.0 项目的步骤。 感谢Carlos_Musich提供的出色文档以及本文档的草稿。 此致, 艾萨克·阿维拉 文件系统 回复:如何为 KSDK 和 PEx 项目的新 MQX RTOS 添加 MFS 和 Shell 支持 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 感谢 Isaac 的演讲。 我使用 Shell 和适用于 K60D100M micro 的 shell 创建了 KDS3.0 项目。KSDK 1.2.0。 我遇到的唯一问题是构建变量。 在 Properties\C/C++ Build\Build Variables 中缺少 KSDK_PATH(参见插入的图像)。 我创建了几个任务并在调试器下运行应用程序。调试器下没有 TAD 信息。 我知道,只需查看 TAD 信息,调试器就应该在运行后在任务内部的某个地方停止。 也许你已经解决了这个问题。 谢谢! 列昂尼德·博尔夏克。
記事全体を表示
汽车模拟和传感器概述,包括 BCC 和高压传感器 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日,天安 MCU 和汽车解决方案大会 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日,天安 MCU 和汽车解决方案大会 传感器
記事全体を表示
BCM I.MX6 SMARCモジュール開発キット(SMARCモジュール、キャリアボード、ケーブル、オンボードeMMCにOSがプリロードされた電源アダプタを含む) <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 製品の特徴: Linux OSがプリロードされたSMARC開発キット キットに含まれるもの: (1).REV-SA01 SMARC評価キャリアボード、3.5インチSBCフォームファクタ (2).SMA-IMX6QI クアッドコアSMARCモジュール (3).電源アダプター: AC入力:100-240V DC出力:5.0V (4).電源ケーブル (5).ミニUSBケーブル (6).オンボードeMMCにOSをプリロード <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 製品の特徴: Linux OSがプリロードされたSMARC開発キット キットに含まれるもの: (1).REV-SA01 SMARC評価キャリアボード、3.5インチSBCフォームファクタ (2).SMA-IMX6QI クアッドコアSMARCモジュール (3).電源アダプター: AC入力:100-240V DC出力:5.0V (4).電源ケーブル (5).ミニUSBケーブル (6).オンボードeMMCにOSをプリロード 全般
記事全体を表示
示例 S32K146-Set_whole_FlexRAM-as_RAM v0_0 S32DS.ARM.2.2 ******************************************************************************** * 文件:main.c * 所有者:David Tosenovjan * 版本:0.0 * 日期:2021年3月12日 * 分类:一般商业信息 ******************************************************************************** * 详细说明: * 示例代码将整个 4kB FlexRAM 区域配置为 SRAM 使用。 *默认情况下或批量擦除后,S32K1设备只有地址范围 * 0x1400_0000-0x1400_0DFF (3.5kB) 可供 SRAM 使用。 * 要启用剩余的 0.5kB,需要执行程序分区命令 *(使用示例中所示的设置),但只能使用空白的新 * 设备(或之前已批量擦除)。设置地址范围 * 0x1400_0000-0x1400_0FFF 用于 SRAM。 * ---------------------------------------------------------------------------------------------- *测试硬件:S32K146EVB-Q144 * 微控制器:PS32K146UAVLQ 0N73V QAC1735D * Fsys: 默认 * 调试器:Lauterbach Trace32、OpenSDA * 目标:Debug_RAM * 终端:无 * EVB连接:默认 ********************************************************************************
記事全体を表示
MCUXpresso IDE v11.9.1现已推出 我们很高兴地宣布 MCUXpresso IDE v11.9.1(build 2170)现已推出。 本次为基于先前版本 MCUXpresso IDE v11.9.0 的维护版本,建议所有现有用户下载安装此新版本。   安装程序下载 要下载所有平台的安装程序,请登录我们的下载网站: https://www.nxp.com/mcuxpresso/ide/download   文档 更多信息可在更新后的用户指南及其他文档中查阅,这些文档可通过 IDE 的“帮助”菜单访问内置帮助系统,或以 PDF 格式从安装目录中获取。   未来版本的发布通知 如需接收有关未来版本发布的通知,请关注:MCUXpresso IDE - 发布历史   变更摘要 - 版本 11.9.1 - 2024 年 4 月 升级:更新的 LinkServer 软件 (v1.5.30) 升级:更新的 SEGGER J-Link 软件 (v7.96c)。 已升级:更新的 PEmicro 插件(v5.7.8)。 更新:MCUXpresso 配置工具升级至 v15.1 版本。 改进:[IDE] 更新了关于窗口的许可文本。 改进:[IDE] 启动配置中支持对 J-Link 脚本文件使用 Eclipse 变量。 已修复:[IDE][SDK 处理] 如果 IDE 未安装在默认位置,自动导入插件 SDK 会返回错误。 已修复:[IDE][SDK 处理] 自动导入插件 SDK 时未能导入某些 SDK。 修复:[IDE][配置工具集成] 解决部分性能问题。 修复:[IDE][欢迎页面] 新增功能章节的版本说明文本可能显示异常的问题。 修复:[KW45/K32W1][J-Link] 闪存擦除后调试功能失效的问题。   已知问题 请参阅安装布局中的 KnownIssues.txt 文件以获取详细列表。
記事全体を表示
Is Fatal Blackout Worth Trying in 2026 My Honest Fatal Blackout Review After Researching It Fatal Blackout is gaining major attention in 2026 as more families search for practical ways to prepare for power outages, grid failures, and emergency situations without relying on extreme survival tactics. Created by combat veteran Teddy Daniels, the program focuses on realistic blackout preparedness strategies using simple step-by-step guidance designed for everyday households. Check the official Fatal Blackout guide and latest details here: What makes Fatal Blackout stand out is its beginner-friendly approach. Rather than promoting expensive bunkers or extreme “doomsday prepper” tactics, the guide focuses on affordable preparedness methods like backup power planning, water storage, food security, EMP protection, and home readiness. Many people appreciate that the information is broken down into simple actions that can realistically be implemented over time. See how Fatal Blackout works and what’s included in the system: In 2026, concerns around grid instability, cyber attacks, inflation, and supply chain disruptions have pushed preparedness into the mainstream. Fatal Blackout taps into this growing interest by offering a structured survival roadmap for people who want to feel more prepared without completely changing their lifestyle. So, is Fatal Blackout worth trying? For people looking for a practical preparedness blueprint with a realistic focus, the program may provide useful insights and organization. However, like any survival system, its value depends entirely on whether users actually apply the strategies consistently in real life.   Re: Is Fatal Blackout Worth Trying in 2026 My Honest Fatal Blackout Review After Researching It Fatal Blackout has been attracting considerable attention in 2026 as more households look for realistic ways to prepare for emergencies such as power outages, grid disruptions, and unexpected crisis situations without adopting extreme survivalist methods. Created by combat veteran Teddy Daniels, the program is built around practical blackout preparedness strategies presented in a clear, step-by-step format intended for everyday families. Explore the official Fatal Blackout website and view the latest details here: One of the main reasons Fatal Blackout stands out is its beginner-friendly structure. Instead of encouraging expensive bunkers or intense “doomsday prepper” lifestyles, the guide emphasizes affordable and achievable preparedness steps. These include backup power planning, water storage solutions, food security basics, EMP awareness, and general home readiness measures. Users often value how the information is broken down into simple, manageable actions that can be implemented gradually over time. Discover how Fatal Blackout works and what the system includes:  In 2026, preparedness has become a mainstream topic due to growing concerns about grid reliability, cyber threats, rising living costs, and ongoing supply chain uncertainties. Fatal Blackout aligns with this shift by offering a structured framework that helps individuals and families feel more confident about handling potential disruptions while still maintaining a normal lifestyle. Yes, Fatal Blackout can be a useful option for those looking for a straightforward, well-structured preparedness guide focused on real-world scenarios. It offers clear direction and practical insights, and its value is best realized through consistent use of the strategies in everyday life, helping users gradually build stronger home readiness and preparedness confidence over time.
記事全体を表示
i.mx6 HabV4 启动失败:在生产板上成功加载 USB 后出现 “j4 错误” **目标:** 我们的目标是使用 `imx_usb` 加载程序绕过 eMMC 将我们的主板直接启动到 RAM 中。这是我们进行故障分析的关键一步。我们已经物理断开了生产板上的 eMMC 连接,以确保我们只测试 USB 启动路径。 **Board States:** 1. **开发板:** 熔丝未熔断。SoC 报告说它处于**开发模式**。 2。**制作板:** 熔丝已熔断,可安全启动。系统芯片报告已进入**生产模式**。 **结果摘要:*** 在使用 `imx_usb` 工具时,我们观察到两种不同的结果。 **1.成功:开发板** 在我们的开发板 上,有一个未签名的 `u-boot.imx`加载并完美执行。日志确认二进制文件已加载并且 SoC 跳转到入口点。 * 命令:** `sudo ./imx_usbu-boot.imx` ** 主要日志输出(`development.txt`):** ``` HAB 安全状态:开发模式 (0x56787856)... 加载二进制文件 (u-boot.imx)到 877ff400,skip=0,fsize=5faa4 type=aa 成功(状态 0x88888888)跳转到 0x877ff400 ```*(结果:主板启动到 U-Boot 提示符)* **2.故障:制作板** 在我们的制作板 上,我们使用**签名的 `u-boot.imx``**由我们的制造团队提供,使用相同的密钥签名,其哈希值在 SoC 中融合。`imx_usb`工具报告说 DCD 和二进制文件已成功加载。但是,最后的跳转命令失败了。 * 命令:** `sudo ./imx_usbu-boot-signed.imx` ** 关键日志输出(`production.txt`):** ``` HAB 安全状态:生产模式 (0x12343412)... 正在加载二进制文件 (u-boot.imx)到 877ff400,skip=0,fsize=5faa4 type=aa 成功(状态 0x88888888)在 err=0 中 跳到 0x8 77ff400 j4,last_trans=64 33 18 c0 00 ```*(结果:板无法启动。 无控制台输出)* **分析和关键问题:*** 关键区别在于 "跳转到 0x877ff400 "命令的结果。在生产板上,在映像成功传输到RAM之后,该过程在此时刻失败。这强烈表明 SoC 的启动 ROM 在*执行之前,正在对 RAM 中的映像执行**HABv4 签名验证**,但该验证失败了。 j4 err` 不是标准 USB 错误;它似乎是与跳转命令有关的 `imx_usb` 工具的内部状态代码。核心问题是跳跃不成功。 1。**HAB 身份验证失败:** “j4 错误”(或随后的无法启动)是否表示 HAB 身份验证失败?启动 ROM 成功接受了该映像,但似乎拒绝运行该映像。 2。**USB 启动的映像签名:** 对打算通过 USB 串行下载协议加载的 U-Boot 映像进行签名是否有特定的要求或格式?我们正在使用签名的 eMMC 启动镜像。预期的 IVT(图像矢量表)结构或其他元数据是否存在差异,导致 HAB 在以 `0x877ff400` 加载图像时拒绝图像? 3.**加载地址:** 图像正在加载到 `0x877ff400`。这是安全 i.MX6 上 USB 加载映像的正确地址吗?启动 ROM 是否期望映像在 RAM 中的不同位置进行身份验证? Re: i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board 你好 您的签名映像是为eMMC启动而构建的吗? 错误显示加载到 RAM 的步骤已成功,但由于一个 HAB 验证失败。 Re: i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board 使用 imx_usb_loader(串行下载协议),我们成功地从 RAM 完全启动 U-Boot 和 Linux。从那次 U-Boot 实时会话中,我们将以下镜像写入了 eMMC: # U-Boot IVT 强制位于 1 KiB 硬件偏移处 mmc dev 1 0 mmc 写入 0x82000000 0x2 0x400 # 将镜像适配到活动分区之外的原始扇区 mmc 写入 0x80800000 0x66000 0x3000 # 启动环境 setenv bootargs "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw" setenv loadfit "mmc dev 1 0; mmc read 0x80800000 0x66000 0x3000" setenv bootcmd "run loadfit; bootz 0x808000e8 - 0x80da4bc0" saveenv 从 U-Boot 提示符手动执行 run boot 命令可以正常工作——Linux 可以启动并挂载 /dev/mmcblk1p2,没有任何问题。邮件中附有工作日志。 故障状态: 在任何冷启动或硬件复位时,即使 USB OTG 电缆物理断开,电路板也不会产生任何 UART 输出,并且会静默地重新进入 USB 串行下载模式。ROM 似乎从未到达 eMMC。 Re: i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board 大家好,请问这个工单目前状态如何?如何才能推进进度?是否需要进行面对面(现场)会议? Re: i.MX6 HABv4 Boot Failure: `j4 err` After Successful USB Load on Production Board 你好 是的,镜像已签名,可用于emmc启动。在内存中运行完美,但无法刷入 eMMC。
記事全体を表示
RW612 TF-M NS:Flexcomm UART 无功能 - 时钟驱动器使用安全 CLKCTL1 地址 您好, 我发现了一个 Bug,当出现以下情况时,任何 Flexcomm UART 都会完全失效 为启用 TF-M 的 frdm_rw612/rw612/ns 构建。 根本原因:时钟驱动器使用安全 CLKCTL1 地址 (0x50021000) 启用 Flexcomm 时钟时。从 NS 世界中默默地写下这些文字 被忽视了,让外围没有了防护罩。所有 USART 寄存器的读数均为 0x00000000。 解决方法是在 UART 启动前通过 NS 别名手动启用时钟: volatile uint32_t *clkctl1_ns = (volatile uint32_t *)0x40021000UL; clkctl1_ns[0x508/4] = 0x01; clkctl1_ns[0x40/4] = (1UL<< 8); 我已经在 nxp-zephyr GitHub 上提交了一份错误报告: https://github.com/nxp-zephyr/nxp-zephyr/issues/35 有人遇到过这种情况吗?是否正在进行适当的修复? 谢谢! Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好,@chofmeister。 请与我们分享您复制这种行为的步骤。我无法通过 MCUXpresso for VS Code 使用 psa_protected_storage 示例来重现这种行为,该示例使用 TF-M 和 UART 控制台,信息正在打印,因此 UART 外设的时钟是正确的。 此外,对于 FRDM-RW612,时钟初始化是在 soc.c 文件的 clock_init 函数中完成的。 Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 感谢您提供的链接。确认一下 - 我运行的是 4.3.0 版来自 nxp-zephyr 下游仓库,那里存在错误。 我阅读了《时钟配置》一文。据我所知,外设 时钟应在 init.c 或 soc.c 中的 board_early_init_hook() 中启用。 查看 frdm_rw612 init.c、我可以看到 Board_early_init_hook() 已在 上实现,但并未启用任何 Flexcomm 时钟。 根本原因特定于 TF-M NS 版本:HAL 时钟函数 (fsl_clock.c)使用安全 CLKCTL1 地址(0x50021000)。在 NS 世界中,对该地址的写入将被静默忽略,从而使 Flexcomm0 完全处于无时钟状态 - 所有 USART 寄存器的读数均为 0x00000000。 我目前的解决方法是在 UART 启动之前,在应用代码中直接写入 CLKCTL1 NS 别名 (0x40021000),这虽然有效,但 显然不是正确的长期解决方案。 根据这篇文章,修复可能属于 init.c 中的 board_early_init_hook() 。在 CONFIG_TRUSTED_EXECUTION_NONSECURE 保护下,使用 NS 别名地址。不过,在尝试公关之前,我想确保这与 团队的方法一致。 这是基于 RW612 的 TF-M NS 版本 的已知差距吗,是否有 建议的修复正在进行中? Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好,@chofmeister,希望你一切都好。 我看到您在我们的下游存储库中提交的报告是您在 Zephyr 4.1.0 版本中发现的一个错误、能否请您确认一下,在我们最新的下游版本库(目前为 4.3.0)中是否仍然存在这种行为? 另外,我还建议查看Zephyr 中的时钟配置,因为 Zephyr 时钟管理子系统尚未支持时钟配置和启用。 Re: RW612 TF-M NS: Flexcomm UART non-functional — clock driver uses secure CLKCTL1 address 你好,RomanVR、 感谢您的回复。我可以在 soc.c 中看到时钟启动代码: #if (DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm0), nxp_lpc_usart, okay))&& CONFIG_SERIAL CLOCK_SetFRGClock(&(const clock_frg_clk_config_t){0, kCLOCK_FrgPllDiv, 255, 0}); CLOCK_AttachClk(kFRG_to_FLEXCOMM0); #endif 代码是正确的,但底层 HAL 函数 (CLOCK_AttachClk、CLOCK_SetFRGClock)使用的是安全的 CLKCTL1 地址 (0x50021000)。在 NS 世界中,对该地址的写入会被 默默忽略,从而使 Flexcomm0 处于无时钟状态。所有 USART 寄存器的读数均为 0x00000000。 我还在 nxp-zephyr GitHub 仓库(问题 #35)上提交了一个错误, 贡献者 waqar-tahir 证实了这个问题,并指出这个问题已经在即将发布的 4.4 下游版本中得到解决。 目前,我的解决方法是在 UART 启动之前,在应用代码中直接写入 CLKCTL1 NS 别名 (0x40021000)。 希望这有助于澄清根本原因。
記事全体を表示
利用 AAOS 14 在 i.MX8QuadMax 上启用双显示器 嗨,团队、 我正在使用 AAOS 14 在 i.MX8QuadMax 上启用多显示器,需要您的帮助。 目前,我连接了两个外部显示器,并测试了以下组合: 情况 i:LVDS0_CH0 + MIPI_DSI0 MIPI_DSI0 上出现 Android 屏幕 LVDS0_CH0 显示空白屏幕 情况 ii:LVDS1_CH0 + MIPI_DSI0 MIPI_DSI0 上出现 Android 屏幕 LVDS1_CH0 显示空白屏幕 情况 iii:LVDS0_CH0 + MIPI_DSI1 LVDS0_CH0 上出现 Android 屏幕 MIPI_DSI1 显示空白屏幕 情况 iv:LVDS1_CH0 + MIPI_DSI1 MIPI_DSI1 上出现 Android 屏幕 LVDS1_CH0 显示空白屏幕 要求: 我们需要任意两个端口(LVDS0_CH0、LVDS1_CH0、MIPI_DSI0、MIPI_DSI1)来同时显示 Android 屏幕。 此外,我还检查了 DRM 的状态: write /sys/class/drm/card0-HDMI-A-2/status on write /sys/class/drm/card1-HDMI-A-2/status on 输出显示已连接,但仍只有一个显示屏处于活动状态。 能否请您帮助我们了解启用双屏显示输出需要哪些配置或更改? 谢谢。 Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 您好@harshi03 ,能否分享一下您使用的是哪张 dtb 图像? 致敬, Zhiming Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 嗨,感谢您的回复 我附上了截图,显示了用于在 imx8qm 上闪烁的 dtbo 映像。 谢谢! Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14     您好, 感谢您的反馈, 按照要求,我分享了用于 i.MX8QM 闪存的 DTBO 映像。能否请您帮助我们了解启用双屏显示输出所需的正确配置步骤? 具体来说,我们希望得到以下方面的指导 启用两个活动显示管道 (LVDS/MIPI) 所需的设备树 (DTB/DTBO) 正确路由显示接口 (DCSS/LCDIF) 以实现同步输出 AAOS 14 支持多显示器所需的任何内核或 DRM 配置 是否需要对 init.rc 或显示服务配置进行额外更改 目前,虽然两个显示屏在 DRM 中都显示为"connected" ,但同时只有一个显示屏处于活动状态。 如果您能在 i.MX8QM 上共享支持双显示器的参考配置或示例设置,那将非常有帮助。 谢谢     Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@harshi03 AAOS 14 支持多显示器,dts 文件是 imx8qm-mek-car-m d.dts,请根据此 dts 进行修改。 android-imx_device_fsl/imx8q/mek_8q/BoardConfig.mk at android-14.0.0_2.2.0 - nxp-imx-android/android-imx_device_fsl - GitHub 致敬, Zhiming Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 要使用 AAOS 14 源代码在 imx8qm 上显示两个显示器,需要做哪些更改,请提供步骤。 谢谢& Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 我附上了 imx8qm-mek.dts 文件以供审查,显示映射是否正确,附上的 dtb 图像也请查看并指导我是否需要对第二台显示器进行任何更改。请尽快回复。 谢谢& Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 您好@harshi03 您使用的是 AOSP 还是汽车 AOSP? 最美好的祝愿, Zhiming Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 我使用的是汽车 AOSP(i.MX8 quad max 平台上的 AAOS 14)。 谢谢& 。 Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 感谢您的回复 按照建议,我们检查了 imx8qm-mek-car-md.dts 和 BoardConfig.mk(android-14.0.0_2. 2.0),并相应地更新了设置。 但是, imx8qm-mek-car-md.dts 文件似乎与源代码中已经存在的文件相同,我们 不清楚需要进行哪些具体修改。 即使验证了这一点,我们仍然只能看到一个活动的显示屏。请说明需要对 DTS 或配置进行哪些具体更改才能启用多显示器? 感谢并致意。 Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 我已经通过 MIPI_DSI0 将 LVDS0_CH0 和 MIPI_DSI0 连接到主板上,它显示的是主显示器,但是通过 LVDS0_CH0 它将其视为 HDMI 显示器。 DRM、HWC 和 SurfaceFlinger 都能正确检测到 HDMI 显示屏, adb shell dumpsys SurfaceFlinger --display-id 显示 了端口 0 和端口 1 的 显示屏。 logcat 还显示了 分辨率为 1920x1080 的 DisplayDeviceInfo{"HDMI 屏幕"}。 但是,重启后, adb shell dumpsys 显示 屏显示 HDMI, mIsEnabled=false。我启用了 config_enableMultiDisplay=true 和 config_enableDisplayPortInDisplayLayout=true,将占用映射从 INSTRUMENT_CLUSTER 改为 MAIN,添加了 /vendor/etc/displayconfig/display_layout_configuration.xml,并在 config_localPrivateDisplayPorts 中添加了端口 1 。我尝试了 和 XML 格式,但 LogicalDisplayMapper 仍然只应用了包含端口 0 的布局,因此 HDMI 端口 1 从未添加到活动布局中。 有时第二个显示屏会变成 mIsEnabled=true,但重启后 又会 变成 false 。您能否确认 display_layout_configuration.xml 的 XML 模式 是否 正确 ,以及 LogicalDisplayMapper/DeviceStateToLayoutMap 是否需要任何额外的框架覆盖、DTS 配置或 NXP 特定补丁才能永久启用 HDMI 逻辑显示? 谢谢,并致以问候。 Re: Dual Display Enablement on i.MX8QuadMax with AAOS 14 你好@刘志明、 现在我使用的是午餐 mek_8q_car-trunk_staging-userdebug 您能建议我们应该选择什么特定的午餐命令来启用多显示器功能吗? 谢谢!
記事全体を表示
如何通过 UART 接收不同长度的数据? 嘿 ! 我使用的是 s32k144 评估板,我使用 UART_PAL 库使用 MODBUS 协议通过 UART 接收数据。我在 while 循环中使用了 thenon 阻塞 uart_receivedata() API,并使用回调检查接收事件和接收数据。 在我确定要接收的数据长度之前,一切都很正常,但当要接收的数据长度不固定,而且每次都不一样时,我该怎么办呢? 我看到了许多相同的主题,但没有一个主题提供了绝对的解决方案,我请求您指导我一个正确的解决方案,如果可能的话,请提供相同的代码/屏幕截图。 我附上了一张截图,在开关语句中,不同情况下接收数据的长度是不确定的。 请@Robin_Shen为我们提供解决方案。 此致, 阿达尔什 Re: How to receive data of varying length over UART? 你好,我想问一下你们是否解决了在 485 上接收变长数据的问题。我目前也遇到了同样的问题,但一直无法解决。 Re: How to receive data of varying length over UART? 本指南中还缺少一样东西,但@Robin_Shen发送的链接中却有。我也会把它写在这里。 6.在 LPUART_DRV_StartReceiveDataUsingInt() 函数中,启用 CTRL[IDLE]。 非常感谢@Adarshnanda制作这份指南! Re: How to receive data of varying length over UART? HI 我正在尝试通过 LPC804 的 UART 接收数据,并使用 mcuxpresso ide,请问谁能提供代码并告诉我接收数据的步骤。 Re: How to receive data of varying length over UART? 嘿,@Robin_Shen、 我查看了该主题,它对我很有效。唯一令人困惑的是,该主题中有些答案与通过 DMA 接收数据有关,有些则与通过中断接收数据有关。 如果想使用 INTERRUPTS 实现 UART_IDLE_LINE_RECEIVE,让我总结一下需要遵循的步骤。 请注意,我们需要添加 LPUART 驱动程序。 1.在 LPUART_DRV_INIT 函数中,必须配置外设寄存器,以启用 IDLE LINE INTERRUPT& 设置 IDLE 标志设置前接收的空闲字符数。你应该看看参考手册。我已将其配置为 8 个空闲字符& ,在此附上截图。 2.在 LPUART_DRV_IRQHandler 中,必须检查 IDLE_LINE_DETECT 标志是否设置& ,如果设置了,则调用 LPUART_DRV_RxIdleCallback 函数(默认情况下没有,用户需要定义)。请注意 - 需要在启动 IRQ_Handler 时调用此函数。 3.在文件 - (callbacks.h) 的枚举 - uart_event_t 中,定义一个事件 UART_EVENT_IDLE_DETECT。 4.定义 LPUART_DRV_RxIdleCallback& 并提供其函数原型。 5.之后,您就可以在应用程序中使用它了。 谢谢@Robin_Shen & 我希望这对其他人有所帮助。 此致, 阿达尔什 Re: How to receive data of varying length over UART? 你好,阿达什、 很抱歉,最近的 S32K1 SDK/RTD 驱动程序没有实现空闲检测功能。您是否参考过S32K144 LPUART IDLE 线路中断配置中的讨论? 您需要更改 SDK 驱动程序,才能获得 LPUART 空闲线中断。 祝好, Robin ------------------------------------------------------------------------------- 注: - 如果本帖回答了您的问题,请点击"Mark Correct" 按钮。谢谢! - 我们会在最后一次发帖后的 7 周内跟踪主题,之后的回复将被忽略 如果您以后有相关问题,请另开新主题,并参考已关闭的主题。 ------------------------------------------------------------------------------- Re: How to receive data of varying length over UART? 7。调用 LPUART_DRV_GetReceiveStatus 函数来计算接收的长度,调用 LPUART_DRV_AbortReceivingData 函数以在处理第一帧后重新开始接收数据,这样接收缓冲区从 0 开始。 这是我添加的内容。现在调试成功了。感谢专家们分享之前的内容。谢谢大家。
記事全体を表示
imx8ulp 功能域间外设数据共享 你好 我正在尝试了解i.MX 8ULP上的外设和跨功能域数据共享,尤其是在一个功能域处于低功耗状态时。 从参考手册中的图 6(i.MX 8ULP 架构图)中,我了解哪些外设与实时域 (RTD) 和应用域 (APD) 相关。不过,我想确认一下在以下情况下哪些是可能的,哪些是不可能的: 1) 在 APD 低功耗状态下,RTD 访问 APD 外设 如果 APD 处于非常低的功耗模式(例如,挂起到 RAM 或其他低功耗状态),是否支持 RTD 从 APD 自有外设访问数据? 如果可以,建议采用什么方法(共享内存、DMA 等)? 是否存在电源模式限制,即由于时钟/电源受限而无法访问 APD 外围设备? 同样,反过来也是可能的: 2) RTD 处于低功耗时,APD 可访问 RTD 外围设备 当 RTD 处于最低/低功耗状态时,APD 能否访问 RTD 所有外设的数据?如果是,建议采用什么方法? 3) RTD 和 DSP 功能域之间的外围设备/数据共享(在 RTD 内) 我们也很好奇这是如何适用于 RTD 中的 DSP 功能域的: RTD 和 DSP 之间的外设/数据共享处理方式是否与 RTD↔APD 共享类似,还是因为 DSP 位于 RTD 内部而有所不同? 在图 6 中,我们注意到从 DSP 功能域横杆到 RTD 横杆(有一条线表示连接)的连接上似乎缺少了 Sx 标签。这是文档错误吗? 该图似乎暗示数据只能在 RTD → DSP 之间流动,而不是在 DSP → RTD 之间流动,这似乎不是故意的。您能确认正确的访问方向吗? 4) APD 访问 DSP 功能域数据 最后,APD 如何访问 DSP 功能域生成的数据? APD 是通过横梁链(APD → RTD → DSP)访问 DSP 资源,还是有更直接/标准的机制? 谢谢! i.MX8ULP Re: imx8ulp peripheral data sharing between domains 你好@ meketok 希望你一切都好。 这个问题问得好。 你可以从 U-启动 看看 imx8ulp.dtsi ,看看通过 Per_Bridge1 可以访问该外围设备。 但在 Linux 环境中不建议这样做,因为通过桥接器从 APD(Cortex A)访问 M33 外设会产生"侧信道。"如果 Cortex A 崩溃,它可能会挂起 M33 的总线,从而违背硬件隔离的目的。 顺祝商祺! 萨拉斯 Re: imx8ulp peripheral data sharing between domains 大家好, ,这的确是一个有趣的话题。 1) 是否可以使用 rpmsg 驱动程序?它有哪些限制(即带宽、延迟)? 2) 支持此功能需要在 M33 上运行哪些确切的 M33 固件? 至少 i.MX 8ULP EVK 使用 I2C0 和 I2C1(与 RTD 功能域相关的总线)与传感器和其他外围设备通信。 Re: imx8ulp peripheral data sharing between domains 你好@Spal_13 希望你一切都好。 实际上,这些功能域有自己的外围设备,这些外围设备不是共享的。 请看参考手册的图 6. i.MX 8ULP 架构图: 您可以看到无法从非所有者的功能域访问外围设备。 以 APD 为参考: 您可以看到 APD 可以访问的 GPIO 包括 GPIOE、GPIOF 和 GPIOD(GPIOD 通过 LPAVD)。 您可以在imx8ulp.dtsi 中确认这一点: 顺祝商祺! 萨拉斯 Re: imx8ulp peripheral data sharing between domains @Manuel_Salas 你能解释一下你向 @Spal_13 展示的连接图中各个功能域的紫色 AXI 总线吗? 您能解释一下为什么 A35 内存映射中会出现 RTD 外设桥 0 和外设桥 1 吗? 您能解释一下为什么 APD 外设桥 3 和外设桥 4 会出现在 M33 内存映射中吗? 表 2. A35 系统内存图 表 5. CM33 内存映射 Re: imx8ulp peripheral data sharing between domains @Manuel_Salas 能否请您解释一下这里的代码? u-boot 在 AP 功能域中运行并访问 RTD 功能域 i2c0。 端口(iomux)和 i2c0 模块。为什么? uboot-imx/板/freescale/imx8ulp_evk/imx8ulp_evk.c 位于 lf-6.12.3-1.0.0 · nxp-imx/uboot-imx · GitHub #define I2C_PAD_CTRL (PAD_CTL_ODE) static const iomux_cfg_t lpi2c0_pads[] = { IMX8ULP_PAD_PTA8__LPI2C0_SCL | MUX_PAD_CTRL(I2C_PAD_CTRL), IMX8ULP_PAD_PTA9__LPI2C0_SDA | MUX_PAD_CTRL(I2C_PAD_CTRL), }; #define TPM_PAD_CTRL (PAD_CTL_DSE) static const iomux_cfg_t tpm0_pads[] = { IMX8ULP_PAD_PTA3__TPM0_CH2 | MUX_PAD_CTRL(TPM_PAD_CTRL), }; void mipi_dsi_mux_panel(void) { int ret; struct gpio_desc desc; /* It is temp solution to directly access i2c, need change to rpmsg later */ /* enable lpi2c0 clock and iomux */ imx8ulp_iomux_setup_multiple_pads(lpi2c0_pads, ARRAY_SIZE(lpi2c0_pads)); writel(0xD2000000, 0x28091060);    Re: imx8ulp peripheral data sharing between domains 我对这个问题也非常感兴趣。 1.@Spal_13的问题都与芯片有关,包括各种可能情况的问题。 2。恩智浦的电路板支持包 Linux只是可以在iMX8ULP芯片上运行的众多场景之一。恩智浦的软件设计就是这样。只是恩智浦的电路板支持包 Linux不这样做。只是恩智浦电路板支持包 Linux 的应用场景不涉及这一点。你无法根据当前的 BSP 场景来解释芯片的功能。 3.你对图 6(即 MX 8ULP 架构图)的理解与@meketok完全相反。meketok 的问题直接指向了相反的答案。坦率地说,我目前认为 meketok 是对的,而你错了。 4.请逐一回答@meketok的问题。 Re: imx8ulp peripheral data sharing between domains 你好,@Manuel_Salas、 基本 8ULP 架构假定两个内核可以协同使用,以实现最佳功效。 例如,APD 可能会进入睡眠/掉电模式,而 RTD 保持活动状态,从传感器采集数据,然后将其独立保存到缓冲区。只有在检测到用户干预(触摸、按钮、运动)时,APD 才会激活。 但是,当你说M33总线可能会被挂起时,就会出现严重的限制。那我们为什么需要这个 M33 核心呢? 如果可能存在这种挂起的情况,那么我们大家(恩智浦和社区)应共同研究解决方法,并且必须清楚地描述"危险的" 场景。 此外,imx8ulp EVK(假设黄金样本)演示了与 APD 的 RTD 连接外围设备的交互式工作: 1) 我们可以访问 I2C0 (RTD) 总线设备: root@imx8ulpevk:~# i2cget -f -y 0 0x60 0x00 root@imx8ulpevk:~# i2cget -f -y 0 0x6c 0xc1 root@imx8ulpevk:~# i2cget -f -y 0 0x6c 2 0x61 2)与 DTS 相对应: &i2c_rpbus_0 { #address-cells =<1> ; #size-cells =<0> ; status ="okay" ;   mpl3115@60 { // 高度计 兼容 ="FSL,MPL3115" ; reg =<0x60> ; };   ite_bridge: it6161@6c { // MIPI 转 HDMI 兼容 ="ite,it6161" ; reg =<0x6c> ;          }; };   3)我们还可以看到按下与 RTD 相连的按钮 SW7/8 (PTB13/12) 所产生的事件:   root@imx8ulpevk:~# evtest /dev/input/event0 输入驱动程序版本为 1.0.1 输入设备 ID:总线 0x19 供应商 0x0 产品 0x0 版本 0x0 输入设备名称:" rpmsg-keys " 支持的活动 事件类型 0 (EV_SYN) 事件类型 1 (EV_KEY) 事件代码 114(KEY_VOLUMEDOWN) 事件代码 115(KEY_VOLUMEUP) 属性: 测试...(中断退出) 事件:时间 1748573575.153335、类型 1(EV_KEY),代码 115(KEY_VOLUMEUP),值 1 事件:时间 1748573575.153335、-------------- SYN_REPORT ------------ 事件:时间 1748573575.332514、类型 1(EV_KEY),代码 115(KEY_VOLUMEUP),值 0 事件:时间 1748573575.332514、-------------- SYN_REPORT ------------ 事件:时间 1748573579.152752、类型 1(EV_KEY),代码 114(KEY_VOLUMEDOWN),值 1 事件:时间 1748573579.152752、-------------- SYN_REPORT ------------ 事件:时间 1748573579.309757、类型 1(EV_KEY),代码 114(KEY_VOLUMEDOWN),值 0 事件:时间 1748573579.309757、-------------- SYN_REPORT ------------   Re: imx8ulp peripheral data sharing between domains 你有答案了吗?
記事全体を表示
i.MX8MP 板。show error DRM_CAP_DUMB_BUFFER"/dev/dri/card0 我将代码从 gui-guider 导出到 yocto。设置环境并 版本 bitbake imx-image-multimedia。运行 gui 应用程序(gui-guider)时部署到 板 上显示错误 DRM_CAP_DUMB_BUFFER " /dev/dri/card0 " 没有 dunb 缓冲区。 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 你好 /dev/dri/card0 是默认值,你需要在 GUI Guider 的项目设置中根据你的主板更改这个值。 只需在板上使用以下命令进行检查即可: $ ls-l /dev/dri/card * 顺祝商祺! 宗春 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 i use 8MPLUSLPD4-PEVK board. Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 我改为使用 /dev/dri/card1。但请遵循以下提示 错误:drmModeAtomicCommit 失败:Permission denied error:刷新失败 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 你好 请尝试使用 /dev/dri/card1。 最佳回复 宗春 Re: i.MX8MP board. show error DRM_CAP_DUMB_BUFFER "/dev/dri/card0 在板中,我找到了 /dri/card0 和 /dri/card1。
記事全体を表示
Power Optimization Strategies for NXP MCUs in Edge AI Applications Hello everyone, I’m currently designing a low-power edge computing device based on an NXP microcontroller and wanted to get some advice from the community. The system performs intermittent sensor sampling and local inference, then sends summarized results to a host system for further analysis. During development and testing, I’m using an ai enabled laptop to profile performance, validate inference output, and monitor power consumption patterns over extended runs. My main challenge is optimizing power usage on the MCU side while maintaining acceptable response time for inference tasks. Are there recommended low-power modes, clock scaling techniques, or SDK features in MCUXpresso that work well for this kind of workload? Any real-world experiences with balancing performance and power on NXP MCUs would be very helpful. Thanks in advance for your insights.
記事全体を表示
S32K344 悬挂问题 MCU:S32K344 OS:FreeRTOS S32Design Studio:3.4.3 问题:MCU 因 I2C 写阻塞(无超时)而挂起 嗨,团队、 我们正在使用基于 S32K344 MCU 的定制板。我们面临的问题是,在某些I2C错误状态下,MCU在运行时挂起。 我们有一个通过 I2C 接口连接的 IMU 从属设备。偶尔,当 IMU没有供电,或 I2C 写入操作失败(例如,没有 ACK /总线卡住), I2C 写入 API不会返回或进入超时状态。结果,执行 I2C 事务的 FreeRTOS 任务被无限期地卡住,最终导致应用程序挂起。 意见: 当从机没有响应或总线保持在低电平时,就会出现问题。 I2C 驱动程序似乎阻塞,等待传输完成。 在 RTOS 或驱动程序级别上不会触发超时或恢复机制。 请求支持: 如何在 S32K344 上添加或强制执行I2C 事务超时? 有没有推荐的方法来恢复卡住的 I2C 总线(SDA/SCL 保持在低电平)? 在 S32K3 设备上的 FreeRTOS 下安全使用 I2C 的最佳做法是什么? 恩智浦是否有稳健处理这种情况的驱动程序配置或示例? 任何指导或参考将不胜感激。 谢谢& , Vinay Re: S32K344 Hanging issue 嗨,@vinaykl、 你的 RTD 已经很老了。 有什么原因吗? 从 RTD 2.0.0 到当前的 RTD 7.0.0,已经修复了许多错误。 我猜您使用的是 I2C 驱动程序的阻塞 API。 请使用异步传输 API 以及 GetStatus() 和超时。 如果从设备一直将 SDA 保持在较低水平,则可以将其恢复,请参阅 I2C 用户手册: 第 3.1.16 节总线畅通 https://www.nxp.com/docs/en/user-guide/UM10204.pdf   RTD 驱动程序没有用于恢复的 API。 AN4803 中的一个例子 I2C 恢复功能定义 https://www.nxp.com/docs/en/application-note/AN4803.pdf 此致, 丹尼尔
記事全体を表示
S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? I am working on an S32K376 VCU POC board where an MSDI device is connected over SPI. From the schematic, the following MSDI-related signals are used: SPI signals: MSDI_CS, MSDI_SCLK, MSDI_MOSI, MSDI_MISO Control/status signals: MSDI_INTB, MSDI_WAKEB Analog / mux signal: MSDI_AMUX MSDI SGx / SPx pins used for digital inputs and outputs I want to implement this using MBDT (Simulink) with S32 Configuration Tools (S32CT), but I am not clear on the correct software approach. Specifically, I need guidance on: How to configure and use the SPI pins in S32CT so that they work with an external MSDI device How MSDI_INTB it MSDI_WAKEB should be configured (DIO vs ICU/EXTI) and handled in MBDT How MSDI digital inputs/outputs (SGx / SPx) are expected to be accessed in software Is there any MCAL support pattern? Or should this be implemented as custom SPI commands + application-level abstraction? How MSDI_AMUX should typically be handled (ADC path / usage expectation) I do not have a working reference or example showing this flow using MBDT + S32CT for S32K376/96 VCU & BMS Example POC project. Could you please suggest the recommended implementation approach (step-by-step or block-level) Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? Hi @mariuslucianand  could you please comment on this? Thanks in advance. BR, Petr Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? Hello everyone, Since no one replied, I tried multiple things on my end and found while working on the same VCU POC board using S32K396, where an external MSDI device is connected over LPSPI3. However, SPI initialization fails during runtime with a BusFault. Observed issue During execution of Lpspi_Ip_Init(), the code faults at: Base->CFGR1 = PhyUnitConfigPtr->Cfgr1; Debugger observation: Instance = 3 Base address = 0x40364000 The register reads: VERID = 53248 PARAM = 53249 CR = 53249 SR = 53249 Followed by: BusFault: imprecise data access error HardFault escalation: This happens on the register access to LPSPI3. Please help with: Which exact configuration/settings (refer to the attached) are incorrect? or What additional settings/MBDT Blockset are required to correctly access MSDI I/O pin data? Re: S32K376 VCU – How to implement SPI-based DIO (MSDI) in S32DS? Hello, Please check the following article to get help regarding the configuration of the SPI peripheral to retrieve data from the MC33CD1030 IC: How to: MSDI MC33CD1030 on S32K396BMS-EVB using NXP MBDT  Note that the article is focused on the SPI configuration to send and receive data from the MC33CD1030 IC. For further information about the CD1030, please consult its datasheet. Best regards, Sorin Bancila
記事全体を表示
只有 VDD(INTF)存在时 TDA8035 的行为,没有 VDDP 供电 我想知道 TDA8035 在下列情况下的表现: VDD(INTF)=3.3V VDDP= 0V(未通电) 看来 TDA8035 处于 RESET 模式但我不确定...你能确认一下吗? 这种情况是否可以持续很长时间(> 数小时)? 在这种情况下,VDD(INTF)消耗量是多少? 顺祝商祺! 顺祝商祺! 西尔万 接触式智能卡读卡器芯片 Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP 你好@sylvainbouriot 在 VDD (INTF) = 3.3V 和 VDDP = 0V 的情况下开机时: TDA8035 将保持重置状态,不会尝试启动智能卡。 允许这种状态持续较长时间而不会损坏芯片或导致异常行为。 当 VDDP = 0 且芯片处于 RESET/掉电模式时: VDD (INTF) 的典型电流非常小,通常在几微安到几十微安之间。目前的消耗量主要用于数字控股。 Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP 谢谢你,Kaily,非常准确的回答。 当 TDA8035 处于运行模式时,VDD (INTF) = 3.3 V 时 VDD (INTF) 的近似功耗是多少? 顺祝商祺! 西尔万 Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP VDDP = 3.3V 或 5V ...
記事全体を表示