ADC Self-Test (Square Check) Support for S32K314 Hello,  In the UM Square Check documentation that an ADC self-test mechanism is mentioned. However, when reviewing the Safety Mechanisms, the ADC self-test is marked as NONE, and we are also unable to find this option in the Square Check (SCheck) configuration for the S32K314 package. Please advise how this feature can be enabled or configured? Priority: HIGH Safety_SW Re: ADC Self-Test (Square Check) Support for S32K314 Hello Team, Is there any update? Thanks Re: ADC Self-Test (Square Check) Support for S32K314 Hello Team, Is there any update? Thanks Re: ADC Self-Test (Square Check) Support for S32K314 Hello Radoslav, What is the different between S32K3E and S32Kxx? It seems both of them are the group of S32K396, S32K394, S32K376, S32K374, S32K366 and S32K364? Can you please point out where to find the S32K3E specific RM and HW Safety Manual ? Thanks Re: ADC Self-Test (Square Check) Support for S32K314 Hello @JasonTsengSG , my understanding is that these are new K3 derivatives with higher performance and some additional support for traction inverters and motor control (eTPU): S32K3E_SW_Architecture.docx You can find RM and SM via intranet e.g. here (sometimes instead K3E you can use just specific K396 derivative name to address this K3 sub-group): Zebra - Documents - S32K396 - All Documents Automotive Safety Software - Release_1.0.6 - All Documents Kind Regards, Radoslav Re: ADC Self-Test (Square Check) Support for S32K314 Thank you, Radoslav, for the clear explanation.

SPIサンプルコード こんにちは。私は「Spi_Transfer_S32K312」というプロジェクトでNXP が提供する spi サンプル コードを勉強しています。コード内の各関数の意味を知りたいのですが、ヘッダーファイルの場所を知ることはCANですか? Re: spi example code こんにちは@mingimin ヘッダー ファイルは、プロジェクト ディレクトリ内の RTD → include の下にあります。 さらに、S32K3/S32M27x SPI ドライバ統合マニュアルと RTD に付属のユーザー マニュアルを確認することをお勧めします。これらのドキュメントには、ドライバの制限、ハードウェアとソフトウェアの要件、使用ガイドライン、構成手順など、ドライバに関する詳細情報が記載されています。これらは、ドライバの行動や能力をより深く理解するのに役立ちます。 これらのリソースは、たとえば次のパスにあります: C:\NXP\S32DS.3.5\S32DS\software\PlatformSDK_S32K3\RTD\Spi_TS_T40D34M50I0R0\doc 正確なパスは、S32DS のバージョンとインストール ディレクトリによって異なる場合があることに注意してください。 BR、ヴェインB

支持 S32K314 的 ADC 自检（方波检查 你好 在 UM Square Check 文档中，提到了一个 ADC 自检机制。但是，在审查功能安全机制时，ADC 自检被标记为 “无”，我们也无法在 S32K314 软件包的方格检查 (sCheck) 配置中找到此选项。 请告知如何 启用或配置该功能 ？ 优先级：高 SAFETY_SW Re: ADC Self-Test (Square Check) Support for S32K314 你好，团队、 是否有任何更新？ 谢谢！ Re: ADC Self-Test (Square Check) Support for S32K314 你好，团队、 是否有任何更新？ 谢谢！ Re: ADC Self-Test (Square Check) Support for S32K314 你好，拉多斯拉夫、 S32K3E 和 S32Kxx 有什么不同？ 它们似乎都是 S32K396、S32K394、S32K376、S32K374、S32K366 和 S32K364 的组群？ 你能否指出在哪里可以找到 S32K3E 专用 RM 和硬件功能安全手册？ 谢谢！ Re: ADC Self-Test (Square Check) Support for S32K314 你好 @JasonTsengSG ， 我的理解是这些新的 K3 衍生产品，具有更高的性能，并额外支持牵引反向器和电机控制 (eTPU)：S32K3E_SW_Architecture.docx 您可以通过内联网找到 RM 和 SM，例如这里（有时你可以只使用特定的 K396 衍生名称来称呼这个 K3 子组）： Zebra - 文档 - S32K396 - 所有文档 汽车功能安全软件 - Release_1.0.6 - 所有文件 谢谢， 拉多斯拉夫 Re: ADC Self-Test (Square Check) Support for S32K314 谢谢你，拉多斯拉夫，解释得很清楚。

S32K3XX的drivers配置 您好，我想请教一下，S32K3XX系列芯片新建设工程，在使用drivers时，每一个driver（1所对应位置的每一种driver类型）对应的配置界面中每一项配置（3所示位置），有没有文档或者教程说明？ 在实际工程应用中，我可以依据哪些资料来进行配置，我每次设置都是看设置项名称猜测其功能，并决定是配置成什么，感觉缺乏官方依据，让我觉得我的每一个设置很没有确定性和依据。 Re: S32K3XX的drivers配置 Hi@Aaron_LL AN13435下面的章节中有各组件的一些描述 并且在官网中有很多外设的配置培训教程，你可以在官网找到这些外设的培训教程。 https://www.nxp.com/products/S32K3

寻找兼容的压力传感器 大家好 我正在寻找一个兼容的压力传感器来替换原来的 125pc05d1。 125pc05d1 是原装压力传感器，属于压差型。 我附上了原压力传感器的外形图和技术规格。 125pc05d1 的灵敏度约等于 Δmv/Δp ≈ 70mv/5psi ≈ 14，由于后续放大电路复杂，我不知道如何调整。如果有与之兼容的具有相同灵敏度的新型压力传感器，那就再好不过了。 有关更详细的测试，请参阅下面的链接。 https://www.eevblog.com/forum/repair/replacing-the-pressure-sensor-requires-assistance/ 感谢您的帮助。 Re: Seeking a compatible pressure sensor 你好 请考虑使用 MPX10DP，因为它在外形和功能上都最接近原装 125pc05d1。如果您需要更宽的压力范围或更高的输出电压以获得更高的分辨率，请考虑 MPX5010DP，尽管它需要额外的信号调节。 BRs, Tomas Re: Seeking a compatible pressure sensor 谢谢！

IMX8MP 处理器出现 HAB 错误 亲爱的大家，正在尝试验证 i.MX8MP 板上的 HAB 签名我遇到了这些错误 HAB配置：0xf0，HAB状态：0x66 --------- HAB 事件 1 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0f 0xc0 0x00 0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00 0x00 0x00 0x00 0x50 STS = HAB_FAILURE (0x33) RSN = HAB_INV_INDEX (0x0F) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) --------- HAB 事件 2 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x42 0x5a 0x00 0x00 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HAB 事件 3 ----------------- 事件数据： 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x40 0x40 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) 它们来自这个开发环境 U-Boot SPL 2023.04-lf_v2023.04+g1e5b6c6bf2 谁能就这个问题给我点建议？预先致谢 Re: HAB Error on IMX8MP processor 你有没有可能解决这个问题，我也遇到了同样的问题，当我试图从 Srk1 转到 Srk2 时。 Re: HAB Error on IMX8MP processor 您好， RSN = HAB_INV_INDEX (0x0F) 表示给定索引中的密钥错误，或已安装密钥的目标索引不可用。检查 csf 文件。 请参阅 HAB API，您可以在其中找到有关这些错误的更多详细信息。API 与您下载的 CST 工具一起用于签名。 此致 哈维

i.mx93：使用 J-Link 和 SYSRESETREQ RESET Cortex-M33 不起作用 你好 我正在尝试使用 Segger J-Link 和 gdb 调试 i.MX93 上的 Cortex-M33 固件。我使用恩智浦的 J-Link 软件补丁建立了 SWD 连接，可以停止处理器、读取寄存器和内存等。 我的问题是，RESET处理器不起作用。寄存器的内容没有变化，所以我认为RESET被忽略了： (gdb) 监测 regs R0 = 40D000C0，R1 = 2001EFE3，R2 = 40D000C0，R3 = 00000000 R4 = 00000000，R5 = 00000000，R6 = FFFFFFFF，R7 = 2001EEE8 R8 = FFFFFFFF，R9 = FFFFFFFF，R10= 2000F000，R11= 00000000 R12= FFFFFFFF，R13= 2001EEE8，MSP= 2001EEE8，PSP= 00000000 R14(LR) = 0FFE219D，R15(PC) = 0FFE2248 XPSR 49000003，APSR 48000000，EPSR 01000000，IPSR 00000003 CFBP 00000000，CONTROL 00，FAULTMASK 00，BASEPRI 00，PRIMASK 00 网络安全扩展规则： MSP_S = 2001EEE8，MSPLIM_S = 00000000 PSP_S = 00000000，PSPLIM_S = 00000000 MSP_NS = 00000000，MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC，PSPLIM_NS = 00000000 CONTROL_S 00，FAULTMASK_S 00，BASEPRI_S 00，PRIMASK_S 00 CONTROL_NS 00，FAULTMASK_NS 00，BASEPRI_NS 00，PRIMASK_NS 00 (gdb) 显示器重置 重置目标 (gdb) 监视器 规则 R0 = 40D000C0，R1 = 2001EFE3，R2 = 40D000C0，R3 = 00000000 R 4 = 00000000，R5 = 00000000，R6 = FFFFFFF，R7 = 2001EEE8 R8 = FFFFFFF，R9 = 2000F000，R11= 00000000 R12= FFFFFF，R7 = R 8 = FFFFFFF，R9 =，R11= 00000000 R12= FFFFFF，R7 = = FFFFFFF，R9 =，R11= 00000000 R 12= FFFFFF，R7= = FFFFFFF 13= 2001EEE8，MSP= 2001EEE8，PSP= 00000000 R14 (LR) = 0FFE219D，R15 (PC) = 0FFE2248 XPSR 49000003、APSR 48000000、EPSR 01000000、IPSR 01000000、IPSR 00000003 CFBP 00000000、控制 00、故障掩码 00、BASEPRI 00、PRIMASK 00 网络安全扩展规则： MSP_S = 2001EEE8，MSPLIM_S = 00000000 PSP_S = 00000000，PSPLIM_S = 00000000 MSP_NS = 00000000，MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC，PSPLIM_NS = 00000000 CONTROL_S 00，FAULTMASK_S 00，BASEPRI_S 00，PRIMASK_S 00 CONTROL_NS 00，FAULTMASK_NS 00，BASEPRI_NS 00，PRIMASK_NS 00 J-Link的RESET策略是使用SYSRESETREQ而不是RESET信号，因为应该只RESET Cortex-M33内核。调试控制器是否可能没有写入 SYSRESETREQ 位所需的网络安全权限？ 使用 J-Link 执行 Cortex-M33 的正确 RESET 方法是什么？ 问候， Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 您好， ，能否也分享一下 [email protected] 的详细信息？ 这个话题已经过去一年多了，问题依然如故。 谢谢。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 感知上，它起作用了，我再也没有丢失过处理器，但是执行时间受到了严重影响，我不明白为什么。 每次操作都要多花 10 倍的时间。 执行冷RESET，但默认情况下在ROM中有一些代码（与恩智浦建议的没有SD卡的建议相反），然后将调试器连接到正在进行的程序并覆盖内存，这样做有感知吗？ Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好 可以使用这个 JLink 脚本吗？ https://kb.segger.com/images/8/86/Example_Reset_CortexM_Normal.JLinkScript 这是 CortexM 的标准策略。 此致 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好 能否分享一下您的解决方案？我目前也面临着同样的情况。 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，克日什托夫、 如上所述，我确实设法想出了一种使用 J-Link 在 i.MX93 中进行 RESET Cortex-M33 的方法。如果这正是您想要的，我很乐意与您分享细节。请告诉我您的电子邮件地址或其他直接联系您的方式。 问候， Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 嗨，我刚刚发现这个话题，想知道是否有人最终找到了一些可靠的解决方案，可以将 M33 与 A55 分离。最近，我开始为即将到来的项目创建开发环境，并在触发信号软件RESET时很快遇到了同样的麻烦。自话题打开以来已经有一段时间了，SEGGER现在（v8.10）为软件提供了内置IMX目标，尽管似乎仍然无法执行单核RESET。我用 SCB（SYSRESETREQ）和 SCR 寄存器做了一些试验，但就是无法达到稳定的效果。我还快速测试了适用于 VSCode 的 MCUXpresso 插件，但没有注意到任何自定义、有效的 RESET 策略的实现。 此致， 克日什托夫 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 嗨，马尔凯，我对解决方案非常感兴趣，因为我也遇到了同样的问题。 能否将您的解决方案或建议发给我？非常感谢。[email protected] 顺祝商祺！ 君书 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，马尔特 非常感谢。我的邮箱是[email protected] 顺祝商祺！ 尼尔斯 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 嗨，尼尔斯 多亏了恩智浦的技术支持，我终于找到了解决这个问题的办法。 如果您告诉我您的电子邮件地址或任何其他直接与您联系的方式，我将很乐意为您提供帮助。 亲切的问候， Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好@Sanket_Parekh 我的情况和原作者完全一样。看来恩智浦提供的jLink脚本实际上并没有执行RESET M33内核，而只是暂停了它。这使寄存器和处理器状态保持不变，如果遇到故障，如果不先通过Linux RESET 内核，我将无法继续正常调试。 除了使用jLink调试器之外，有什么办法可以触发信号RESET M33内核吗？ 顺祝商祺！ 尼尔斯 Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，桑凯特-帕雷赫、 (1) 在哪里可以获得 i.MX93 Cortex-M33 的恩智浦 J-Link 脚本补丁？ (2) 据 Segger 称，目前还没有在 J-Link 中支持 i.MX93 的路线图。但它会在第一/第二季度到来。还有其他调试 Cortex-M33 的可能性吗？ BR Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好@malkai、 希望你一切都好。 "恩智浦打算在i.MX93中RESET Cortex-M33内核的程序是什么？" -> 系统重置控制器 (SRC) 负责生成所有系统复位信号和启动参数锁定。 -> 它的主要功能如下： • 处理来自其他模块的所有全局系统 RESET 源并生成全局系统 RESET。 - 负责 MIX（片）的功率门控及其内存低功耗控制。 -> SRC 从 PAD 和熔丝位中获取 POR_B 以完成启动顺序，并提出 GPC 低功耗请求以 完成掉电/开机顺序。 请参阅第 33 章系统 RESET 控制器 (SRC)。 https://www.nxp.com/webapp/Download?colCode=IMX93RM 谢谢& ， Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，@Sanket_Parekhm、 谢谢您的答复。然而，这些信息无助于问题的解决。众所周知，i.MX93 中的 Cortex-M33 内核采用 Armv8-M 架构，该架构的 AIRCR 寄存器中没有 VECTRESET 位（参见 https://developer.arm.com/documentation/ddi0553/latest/ 中的 D1.2.3 ） 。因此，唯一可用的RESET请求是SYSRESETREQ，Cortex-M33内核和整个系统都不会对此做出任何反应。为什么会这样？ 我已经研究过J-Link使用的RESET策略。问题是，恩智浦的修补程序只是用停止 CPU 来代替这些，就像我告诉你的那样。而且这里不能使用RESET线，因为它会RESET整个 SoC。 因此，问题仍然存在：恩智浦打算采用什么程序来RESET i.MX93中的Cortex-M33内核？ 谢谢并致以诚挚的问候， Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好@malkai, 希望你一切都好。 -> RESET选择控制目标设备的RESET操作。所有RESET选项都适用于基于 Cortex-M 处理器的设备，在 JTAG 和 SWD 模式下可用，并在RESET后停止 CPU。 -> Core-只能通过设置 VECTRESET 位来执行 Cortex-M 内核的 RESET。片上外设未RESET。对于某些 Cortex—M 设备，这种 RESET 方法是重置它们的唯一方法。但是，在大多数情况下，不推荐使用这种方法，因为大多数目标应用程序依赖于某些外围设备（PLL、外部存储器接口等）的RESET状态，如果启动后可能会混淆，但外设已经配置好了。 -> resetPin-J-Link 将其 RESET 引脚拉低以重置内核和外围设备。通常，这也会导致设备的 CPU RESET 引脚变低，从而导致 CPU 和外围设备 RESET。如果目标设备的RESET引脚未拉至低电平，则此复位方法将失败。 请参阅以下链接中的RESET策略部分。 https://community.nxp.com/ pwmxy87654/attachments/ pwmxy87654/kinetis/28743/1/ UM08001_JLink.pdf 谢谢& ， Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，@Sanket_Parekh、 谢谢您的答复。遗憾的是，这些信息无助于解决我的问题。在此期间，我发现了很多事情： 1.恩智浦在i.MX93补丁中提供的J-Link脚本未实现RESET。它取代了重置 CPU，而只是停止 CPU。 2. 通过调试器手动将 AICR.SYSRESETREQ 写入 1 来请求 RESET 不会导致 Cortex-M33 内核 RESET。 所以，我最初的问题仍然是：通过调试器RESET Cortex-M33的可能性有多大？ 感谢和问候， Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working 你好，@malkai、 希望你一切都好。 请参考此链接，它将对您有所帮助。 https://community.nxp.com/t5/ i-MX-Processors-Knowledge- Base/all-boards-jtag/ta-p/ 1106822 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ------------------------------ ------------------------------ ------------------------------ ----------------------------- Thanks& Regards, Sanket Parekh

IMX8MPプロセッサのHABエラー 皆様、i.MX8MPボードでHAB署名を検証しようとしていますが、次のようなエラーが発生します。 HAB 構成：0xf0、HAB 状態：0x66 --------- HABイベント情報1 ----------------- イベント情報: 0xdb 0x00 0x14 0x45 0x33 0x0f 0xc0 0x00 0xbe 0x00 0x0c 0x00 0x03 0x17 0x00 0x00 0x00 0x00 0x00 0x50 STS = HAB_FAILURE (0x33) RSN = HAB_INV_INDEX (0x0F) CTX = HAB_CTX_COMMAND (0xC0) ENG = HAB_ENG_ANY (0x00) --------- HABイベント情報2 ----------------- イベント情報: 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x42 0x5a 0x00 0x00 0x00 0x00 0x00 0x20 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) --------- HABイベント情報3 ----------------- イベント情報: 0xdb 0x00 0x14 0x45 0x33 0x0c 0xa0 0x00 0x00 0x00 0x00 0x00 0x40 0x40 0x00 0x00 0x00 0x00 0x00 0x04 STS = HAB_FAILURE (0x33) RSN = HAB_INV_ASSERTION (0x0C) CTX = HAB_CTX_ASSERT (0xA0) ENG = HAB_ENG_ANY (0x00) これらは開発環境から来ています U-Boot SPL 2023.04-lf_v2023.04+g1e5b6c6bf2 誰かこのトピックに関してアドバイスをくれませんか？前もって感謝します Re: HAB Error on IMX8MP processor これを修正できた可能性はありますか？私もsrk1からsrk2に変更しようとすると同じ問題が発生します Re: HAB Error on IMX8MP processor こんにちは、 RSN = HAB_INV_INDEX (0x0F) は、指定されたインデックスのキーが間違っているか、インストールされたキーのターゲット インデックスが利用できないことを示します。csf ファイルを確認します。 これらのエラーの詳細については、HAB API を参照してください。API には、署名用にダウンロードする CST ツールが含まれています。 よろしくお願いします。 Harvey

LPC1768+SSP0+GPDMAに問題あり SSP0 で DMACR を開いて BUF にデータを送信した後、DMACR がゼロにリセットされ、SSP0DR は変化し続けますが、BUF データは変更されないのはなぜでしょうか。割り込み中に DMACR を再度開こうとしましたが、BUF データにはまだ変化がありませんでした。 コード構成は次のとおりです。 #定義 SPI_RX_LEN 5386 外部U8 SPIRXBUF[SPI_RX_LEN]; void DMAInit_SPI_RX(U8 *destAddr, U32 len) { U32 パート1 = (長さ > 4095) ?4095 : 長さ; U32 パート2 = (長さ > 4095) ?(len - 4095) : 0;// 拆分传输（单道最大4095字节）   LPC_SC->PCONP |= (1 << 29); // 使用GPDMA時間钟 LPC_GPDMA->DMACConfig |= (1 << 0);//GPDMA を使用する LPC_GPDMA->DMACIntTCClear |= 0x01; // 清除道0传输完了标志 LPC_GPDMA->DMACIntErrClr |= 0x01; // 清除道0错误标志   // 链表项1：传输part1字节 lli[0].srcAddr= (U32)&LPC_SSP0->DR; // ソース：SPI0データ寄存器 lli[0].宛先アドレス= (U32)destAddr; // 目的：缓冲区開始 lli[0].コントロール= (part1 & 0x0FFF) // 传输大小（字节数） | (0x00 << 12) // 源突発大小 | (0x00 << 15) // 目的発行大小 | (0x00 << 18) //ソースデータ宽度 | (0x00 << 21) //目的データ宽度 | (0x00 << 26) //源地址不变（外设寄存器） | (0x01 << 27) //目的地址自增 | (1U << 31); // 使用中断   // 链表项2：传输part2字节（若必要） (パート2 > 0)の場合 { lli[0].nextLLI = (U32)&lli[1]; // 指向链表项2 lli[1].srcAddr= (U32)&LPC_SSP0->DR; lli[1].destAddr= (U32)(destAddr +part1); // 缓冲区偏移 lli[1].コントロール= (part2 & 0x0FFF) // 传输大小（字节数） | (0x00 << 12) // 源突発大小 | (0x00 << 15) // 目的発行大小 | (0x00 << 18) //ソースデータ宽度 | (0x00 << 21) //目的データ宽度 | (0x00 << 26) //源地址不变（外设寄存器） | (0x01 << 27) //目的地址自增 | (1U << 31); // 使用中断 lli[1].nextLLI= 0; // 结束链表 } そうでない場合、 { lli[0].nextLLI = 0; }   // 配置DMA通道0 LPC_GPDMACH0->DMACCConfig = 0; LPC_GPDMACH0->DMACCLLI = (U32)&lli[0]; // 链表開始地址 LPC_GPDMACH0->DMACCSrcAddr = lli[0].srcAddr;// ソース地址（SPI0 DR） LPC_GPDMACH0->DMACCDestAddr = lli[0].destAddr;// 目的地址 LPC_GPDMACH0->DMACCコントロール = lli[0].control;// 制御文字 LPC_GPDMACH0->DMACCConfig = (0x01 << 15) //中断错误 | (0x01 << 14) //終端计数中断 | (0x02 << 11) // 传输種類：外设到内存 | (0x00 << 6) //目的外设：保存器 | (0x01 << 1) // ソース外设：SSP0 RX（参考手册） | (0x01 << 0); // 道使い能   GPDMAEnabe(); }     void DMA_IRQHandler(void) { if(LPC_GPDMA->DMACIntTCStat & 0x01) // 通道0転送完了 { LPC_GPDMA->DMACIntTCClear = 0x01; // 清除标志 //SSPSlave_Init(); // RUN_LAMP_GLITTER; // LPC_SSP0->DMACR |= (1 << 0); // LPC_GPDMACH0->DMACCConfig |= (0x01 << 0); LPC_GPDMA->DMACConfig |= (1 << 0);//GPDMA を使用する 時間++; } if(LPC_GPDMA->DMACIntErrStat & 0x01) // 通道0错误 { LPC_GPDMA->DMACIntErrClr = 0x01; // 清除标志 } } void SSPSlave_Init(void) { LPC_SC->PCONP |= (1 << 21); /* 打开SSP電源 */ /************************************************************************ * 初期化SSPの通信方式、データ長は8bit、フレーム形式はSPI、SCKは低能率に設定されています。 * データは SCK の 2 番目の時間にサンプリングされ、ビットレートが設定されます。 **********************************************************************/ LPC_SSP0->CR0 = (0x00 << 😎 | /* SCR 設定 SPI ビット速度 */ (0x01 << 7) | /* CPHA 時間钟输出相位 */ (0x00 << 6) | /* CPOL 時間钟出力性 */ (0x00 << 4) | /* FRF 帧格式 00=SPI，01=SSI, */ /* 10=マイクロワイヤー，11=保留 */ (0x07 << 0); /* DSS データ長度,0000-0010= 保持 */ /* 0011=4 位、0111=8 位、1111=16 位*/ LPC_SSP0->CPSR = 2; /* 時間钟分周波数寄存器*/   LPC_SSP0->CR1 = (0x00 << 3) | /* SOD 从机输出禁能，0=允许 */ (0x01 << 2) | /* MS 主从选择，1=从机 */ (0x01 << 1) | /* SSE SSP 使用能，1=使用能 */ (0x00 << 0); /* LBM 回写モード */   sysTimeDlay(5); LPC_SSP0->DMACR |= (1 << 0);   } LPC17xx Re: LPC1768+SSP0+GPDMA some problem こんにちは@Lee_Lee DMA は「空の SSP FIFO を読み取っている」と思いますが、アクセス幅が正しくないため、データがメモリに正しく書き込まれていません。 現在何を設定していますか (0x00<<18)//ソースデータ宽度 (0x00<<21)//目的データ宽度 しかし、LPC では次のようになります。 SSPのDRレジスタは16ビットのレジスタである。 8 ビット SPI モードを使用している場合でも、SSP0->DR への DMA アクセスは 16 ビット アクセスである必要があります。 DMAは実際にはメモリにデータを正しく書き込んでいない その結果、BUF は変更されません。 SO、ソースと des の幅を 16 に変更してみると CAN と思います。 BR ハリー

需要澄清 MK70 DDR 控制寄存器 21 规范 大家好， 我在 MK70FX512VMJ12 控制旧版板上的 DDR 时遇到了问题。 我们正在使用 MQX。问题来自引导加载程序中的以下一行： ddr->CR21 = 0x00060232; 我假设该行将 DDR_CR21 寄存器（如 K70 参考手册第 34.4.22 节所述）设置为 0x00060236。 参考手册指出，注册字段分为 2 个字段。 31–16 MR1DAT0 Data to program into memory mode register 1 for chip select . 15–0 MR0DAT0 Data to program into memory mode register 0 for chip select . 大多数 DDR 制造商将这些寄存器称为模式寄存器（MR 或 MRS）和扩展模式寄存器（EMR1、EMR2、EMR3）。我是否应该假定，字段 15-0 的数据将由状态机写入 DDR 的 MR（模式寄存器），字段 31-16 的数据将写入 EMR？ 我怀疑，无论 DDR_CR21 中设置的值是多少，状态机都会发出必要的控制信号，这一点需要得到支持工程师的确认。这是因为考虑到我在 DDR_CR21 (0x0006) 的第 31-16 位写入的数据为 3 个 MSB 位分配了 000，为了正常运行，这些位应按照 DDR 规范的要求设置为 001。 DDR 规格说明："写入扩展模式寄存器的方法是将 CS#、RAS#、CAS#、WE#、BA1 置低，将 BA0 置高，同时控制地址引脚 A0 ~ A12 的状态。" BA2、BA1 和 BA0 所需的设置为 "001"，而我写入 DDR_CR21 的值为 "000"。 DDR 同步动态随机存取存储器(SDRAM) 控制器是否会将在 DDR_CR21 中设置的值覆盖为正确的值？ 谢谢， dodocolby Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 感谢您使用我们的社区。我注意到了你的问题。 我需要一些时间进行研究，然后再给您答复。如果在此期间有任何更新，请随时与我们分享。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 能否请您告诉我芯片的掩码集？ 据我所知，掩膜组 3N96B 零件有勘误表e10521。   另外，您使用的是哪个版本的 MQX？我知道 MQX 4.x 存在与 SIM_MCR DDRDQSDIS RESET 状态有关的问题，这一点需要清除。   虽然 MQX 已不再受支持，但我注意到在以前的案例中，它们都使用了 ddr->CR21 = 0x00040232；而不是您提到的值： 0x00060232.   例如，随着温度升高，K70 DDR2 读取失败 - NXP Community K70 DDR2 温度影响读取数据 - NXP Community   这就是我提出上述问题的原因。   BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好， ，我使用的是MQX 4.2 和 5N96B。 随着温度的升高，我们实现了 " K70 DDR2 读取失败——恩智浦社区 K70 DDR2 温度会影响读取数据——恩智浦社区 "，看来该设备对温度不再敏感了。 谢谢   Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 是的，我之所以引用这两个链接，是因为我注意到他们提到的代码使用 ddr->CR21 = 0x00040232 而不是 60232 。我只是想确认这一点，因为我这边无法访问 MQX 代码，它已不再受支持。此外，我已经联系了内部团队，以帮助进一步解决您的问题。一有回音，我就告诉你们。感谢您的理解。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 抱歉让您久等了。我还没有收到我们内部团队的任何更新，可能是因为圣诞假期的缘故。 请注意，由于欧洲、中东和非洲地区以及 AMEC 时区的假期，我们的回复时间可能会比平时长。我也将从明天开始休假，直到 1 月 5 日。 如果此事很紧急，您可以考虑创建一个新的案例并提及此链接。其他同事将能通过此案例找到我的内部联系人，您有可能在 1 月 5 日之前收到更新信息。 如果不紧急，我回去后会继续跟进。我们衷心感谢您的理解和耐心。 祝您愉快 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 你好@dodocolby、 希望你一切顺利。对不起，我的回复晚了。请参阅我们内部团队的答复： " 由于 DDR 控制器可支持多种不同内存大小和配置，且地址引脚总数各不相同，因此加载到 MRnDATA 字段的模式寄存器数据不应包括组地址值。控制器将自动驱动正确的银行地址值（以及模式寄存器写入命令的其他控制信号）。寄存器值只需包括地址行部分。 " 希望对你有所帮助。如果您有其他问题，请告诉我。 BR 西莱斯特 Re: Clarification needed for MK70 DDR control register 21 specification 感谢您的确认。

MCUXpresso IDE 上的 ITM 与 UART 打印。 1. 简介 在嵌入式系统开发中，调试和日志输出对于确保代码正确性和优化性能至关重要。通过实时监控系统状态、捕获异常行为并记录关键数据，开发人员能够快速发现问题并验证功能。在资源受限的嵌入式环境中，选择合适的调试工具和方法显著影响开发效率。 MCXN947 是恩智浦上市的高性能微控制器，提供多种调试和记录解决方案，其中最常用的是ITM（仪器跟踪宏单元）和UART打印。ITM 利用 Cortex-M 内核的调试功能，通过调试接口高速传输数据，使其适用于具有严格实时要求的场景。UART 打印则通过 UART 外设输出日志，具有很强的通用性，适合生产环境。 本文解释了如何在MCUXpresso IDE 中使用这两种输出方法，以提高开发效率和系统可靠性。 2. ITM 和 UART 打印的原理和特点 2.1 ITM – 原理与特点 工作原理： ITM（Instrumentation Trace Macrocell）是 Cortex-M 内核提供的一项调试功能。它通过调试接口（例如 SWD/JTAG）使用 SWO 实时传输数据。开发人员可以使用 ITM_SendChar() 函数将调试信息发送到 ITM端口，然后由调试器捕获并显示在 IDE 的调试控制台中。 优势： 高速传输：ITM 利用调试接口的带宽，速度远超 UART（通常超过 10 Mbps）。 低 CPU 占用： ITM 由硬件处理，几乎不消耗 CPU 资源。 无额外外设： 不依赖 UART 或其他外设，节省硬件资源。 劣势： 调试器依赖： 需要连接调试器（如 MCU-Link、J-Link），不能直接用于生产环境。 配置复杂：需要正确的 ITM 端口和调试器设置，这对初学者来说可能具有挑战性。 2.2 UART 打印——原理和特点 工作原理： UART 打印通过 UART 外设将调试信息发送到串行终端。开发人员通常将 printf 函数重定向到UART，从而使标准库函数用于日志输出。数据通过 TX/RX 引脚传输，可以使用串行工具（例如 PuTTY、Tera Term）在 PC 上查看。MCUXpresso IDE 还内置了一个用于 UART 调试的终端。 优势： 高度通用：几乎所有嵌入式板都支持UART，使其广泛适用。 生产就绪：不需要调试器，可以直接在生产环境中使用。 易于实施：配置简单，非常适合初学者和快速原型制作。 劣势： 低速： 受限于 UART 波特率，导致传输效率降低。 外围资源使用： 占用 UART 外设和引脚，可能影响其他功能。 实时性能差： 由于中断延迟和波特率限制，不适合高实时场景。 2.3 对比总结 下表总结了 ITM 与 UART 打印的主要特点： 特性 ITM UART 打印 传输速度 高（10 Mbps 或更高） 低（通常为 115200 bps） CPU 开销 低 更高 外围依赖 无 需要 UART 外设和引脚 调试器依赖 需要 不需要 生产适用性 不合适 合适 配置复杂性 复杂 Simple 实时性能 高 低 使用场景： ITM： 非常适合开发阶段调试，且实时需求高（如电机控制、信号处理）。 UART 打印： 适合生产日志、初学者友好的设置以及一般调试需求。 3. 在 MCUXpresso IDE 中的实施步骤 3.1 使用 ITM 打印 硬件需求： 确保芯片的 SWO 引脚连接到调试器的 SWO 接口。 软件配置： 1）创建新项目时，选择“Redirect printf/scanf to ITM”以将 printf/scanf 重定向到 ITM。   2) 配置跟踪时钟： /*!< Switch TRACE to TRACE_DIV */ CLOCK_AttachClk(kTRACE_DIV_to_TRACE); /*!< Set up dividers */ /*!< Set TRACECLKDIV divider to value 3 */ CLOCK_SetClkDiv(kCLOCK_DivTraceClk, 3U);   3）在 MCUXpresso 集成开发环境中，打开 SWO ITM 控制台，配置核心时钟和跟踪时钟设置。     4）在 ITM 控制台中查看输出结果。 3.2 使用 UART 打印 1）创建新项目时，选择 SDK 调试控制台为 UART，设置 DebugConsole 使用 UART。          2）使用 MCUXpresso IDE 的外设工具配置 DebugConsole-UART。   3）使用引脚工具配置 UART TX/RX 引脚。 4）连接串行硬件，并在终端中查看输出结果。 4. 结论 ITM 和 UART 打印各有其优势。开发人员应根据项目需求选择合适的方法。ITM 更适合在开发过程中进行高实时调试，而 UART 打印则更适合生产环境和一般调试。

Imx95 verdin EVK、Aquantia10gbps 接口在 udp 上的速度限制为 1.2gbps 你好 我正在尝试通过两个 Imx95 verdin EVK A1 Silicon 版本板的 Aquantia 10 Gbps 接口在它们之间建立通信。两块板均运行 Debian 12（linux 内核 6.12.3），使用恩智浦安装程序（aquantia-firmware-utility/aq_api_2_9_7 at master 的 aquantia-firmware-utility/aq_api_2_9_7）正确安装了 aquantia10 G 固件（aqr-g4_v5.6.d-aqr_Marvell_noswap_xfi_id44834_ver2068.cld）aquantia-固件实用程序·GitHub)。它们使用 Cat6a 以太网电缆进行物理连接。 当我使用 iperf3 进行性能测试时，即使指定的目标带宽为 7 Gbps，我也能获得约 5 Gbps 的 TCP 带宽和 1.2 Gbps 的 UDP 带宽，损耗率为 0% ： # TCP 在第一块板上测试 iperf3-s # iperf3-c < Server_IP >-t 30 # 在第二块板上测试 iperf3-s # # UDP 测试 iperf3 -s iperf3 -c -u -b 7G -t 30 当我尝试使用 ip link set dev enp1s0 mtu 9000 激活巨型帧时，却得到一个错误提示，说我超出了限制（10Gbps 接口不接受巨型帧，这很奇怪）。 我还尝试增加 UDP 缓冲区的大小，但得到的是相同的位帧 当我在两侧运行 iperf3 时，CPU 负载不超过 40% 为了达到最大吞吐量（接近 10 Gbps），是否需要应用特定的 n 配置或安装额外的工具？Aquantia FW 版本是否良好？Linux 内核版本？FW 安装程序版本？ 有人尝试在该目标机上使用 10Gbps 接口吗？ 此致， Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 您好， 感谢您的反馈， 应用您的配置： cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 现在，我在发射端仅使用 iperf 而不是 iperf3，就能达到 10Gbps 的速度，有时甚至能达到 8,8 或 9,8Gbps 的速度，而在接收端，我只能达到 5.59Gbps 的速度，丢失帧数为 36% ，您能帮助解决这个问题吗？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1.尝试在两个系统上配置以下设置： cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 2。如果可能的话，使用不同的参考系统作为 iperf 服务器（例如英特尔至强） 3. iperf3 本身对每个测试流都是单线程的，请尝试使用 -P 选项： ，例如iperf3 -c -u -b 10G -t 30 -P 6 (6 条流) 4.检查正向和反向液流 (-R) iperf3 -c 192.168.1.1 -t 10 -b 10G -u -R Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 它将是一个小版本升级到 6.12.49 顺便提一下，您可能还需要考虑 DPDK 或 AF_XDP，以获得更好的吞吐量？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCP 与 UDP 的发送性能对比 使用 iperf3 发送 TCP 数据包时，每个 TCP 数据包为 128KB，数据包将被 ENETC 硬件的 LSO 功能分片。因此，你会看到更高的 TCP 传输性能。 iperf3 在创建 UDP 套接字时没有启用 UDP_SEGMENT。因此： -每个 UDP 数据包的大小约为 MTU（约 1500 字节）。 - 在数据量相同的情况下，UDP 需要比 TCP 发送更多的数据包。 更多数据包→更多内核处理→与带 LSO 的 TCP 相比性能降低。 => 为什么 TCP 的接收比发送低很多？ - 在 Linux 内核中，TX 和 RX 路径并不对称，因此内核中每个 RX 数据包和每个 TX 数据包的处理时间是不同的。 - RSC 在内核中默认未启用；我们需要禁用 TCP 时间戳，这样 ENETC 的 RSC 才能正常工作。目前，i.MX95 的 RSC 默认为禁用。 a) 启用 i.MX95 的 RSC（接收端）： ethtool -K eth1 large-receive-offload on b) 禁用 TCP 时间戳（发送端）： sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf 启用 RSC 后，接收端的 TCP 性能将会提高。 此外，您还可以尝试使用巨型帧来获得更高的吞吐量。（希望你运行的是最新版本）。 # 将两侧的 MTU 更改为 9000 ip link set dev eth1 mtu 9000 # 更改以太网驱动程序中的 RX 缓冲区长度。 ethtool -G eth1 rx-buf-len 16384 在多数据流模式下，我们可以看到 8 到 10 Gbps 的 UDP RX/TX。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 你好， ，我目前只对 UDP 感兴趣，对 TCP 不感兴趣，而且我认为卸载 机制不适用于 UDP ，我试图通过将 mtu 设置为 9000 来激活巨型帧，但我收到了一个错误，提示我超出了 1500 的限制（我使用的内核版本是 6.12.3）。 问候， Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 好吧，我试试看，然后告诉你我得到了什么， 你能精确地指出 LF-Q4 的 Linux 内核版本吗？正如我告诉你的那样，我现在使用的是 6.12.3，我不能升级到更高版本，因为我的硅片版本是 A1，我需要知道我是否必须升级到 B0 版本。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp RSC 设置还能提高 UDP 性能。 ENETC 中巨型帧的更改/修复将在两周后发布的 LF-Q4 版本中发布。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 使用 iperf 时，我的速度可以达到 10Gbps，有时甚至可以达到 9.8Bps；在并行数据流中，只有一个数据流的速度可以达到 5Gbps，但最大的问题是 Udp，在单个数据流中，我的速度可以达到 2Gbps，没有丢帧现象；但在并行数据流中，我的速度可以达到 5.5Gbps，丢帧率为 42% 。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 我不认为 AF_XDP 或 DPDK 有助于将 46% 的丢失减少到 0% ，我还验证了 IRQ 亲和性，我可以看到 10G 接口上有 6 个 IRQ，每个 IRQ 都影响到一个 CPU，而且在测试过程中我没有看到任何 CPU 负载问题，1 个 CPU 的最大 CPU 负载为 40% 、我仍然不明白为什么总是丢帧，也许是因为使用的内核版本不支持巨型帧， ，您是否在您的系统（NXP）中对 10G 接口进行了性能测试，我认为您应该在您的系统中进行测试，看看是否存在与我相同的问题。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP 或 DPDK 不使用内核网络协议栈。 DPDK 专门有一个不同的驱动程序，只能在用户空间工作。它针对网络和数据包处理进行了高度优化。 它可以为所有 IP 数据包提供真正的快速性能。 您可以登录 第 10 章：https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 此测试是在哪个硅修订版 A1 还是 B0 上进行的？ 您是否确认用于此测试 6.12.49 的内核版本仅适用于 B0 或者可能适用于 A1？？ 我在你的电路板支持包交付中看不到这个内核版本，最后一个是 6.12.34 https://www.nxp.com/pages/alpha-beta-bsps-for-microprocessors:IMXPRERELEASES Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 新的内核树和变更可从以下网址获取： https://github.com/nxp-imx/linux-imx/commits/lf-6.12.49-2.2.0 较新的 LF 版本中已取消对 A1 的支持。 您有以下选项 1。只需独立编译内核，仅在版本中替换内核即可。(可能有效） 2。请您的营销联系人将您的板替换为 B0，这样您就可以发布 LF-Q4'2025 版本。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 我不明白这几行的意思： Single UDP Stream send (1500 MTU): 2 Gbps（在单数据流中，MTU 为 1500 的 tx 速率似乎为 2Gbps） Multi UDP Stream send (1500 MTU).10Gbps（在多数据流中，MTU 为 1500 的 tx 速率似乎为 10Gbps）：10Gbps（在多数据流中使用 MTU 1500 发送时，速率为 10Gbps） 单 UDP 数据流发送（MTU 为 9000）：8.2 Gbps（在单数据流中，使用 MTU 900 的 tx 速率为 8.2 Gbps） 接收单 UDP 数据流（MTU 为 9000）：3.9 Gbps（在多数据流中，使用 MTU 1500 的 tx 速率为 10Gbps）：3.9Gbps（在单数据流中使用 MTU 为 9000 的接收端，速度为 3.9Gbps） 多 UDP 数据流接收（MTU 为 9000）：10Gbps（在多数据流中，使用 MTU 9000 的 Rx 速率为 2Gbps） 我没有看到： 单 UDP 数据流接收（1500 MTU） 多 UDP 数据流接收（1500 MTU） Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 好的，我明白了，但为了确保万无一失，您能否在接收端 MTU = 1500 的情况下进行测试，我想知道您在这个新版本上的测试结果是否与我相同，另外，我看到您在测试中将发送端设置为 1500，接收端设置为 9000，但这并没有改变任何情况，就好像您在两端都设置为 1500，如果您需要测试巨型帧，您需要在两端都设置为 9000，请使用以下配置重新进行测试： 1- RX/TX，MTU = 1500，两端均为单声道和多声道流 2- RX/TX，MTU = 9000，两端均为单声道和多声道流 谢谢您的帮助。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 是的，结果就是这样检验出来的。 所有情况下，双方的 MTU 都相同（都是 1500 或都是 9000） Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 见附件、 请注意，我也是在 A1 SOC 上运行的。 UBOOT 日志：- U-Boot 2025.04-g8c1de2e1deca(May 09 2025 - 15:29:26 +0000) CPU：1800MHz 时的 i.MX95 rev1.1 CPU：30 摄氏度时的汽车温度等级（-40 摄氏度至 125 摄氏度） LM 启动原因：sw，起源：2，错误：1 LM 关机原因：sw，起源：2，错误：1 型号：恩智浦 i.MX95 19X19 板 动态随机存取存储器(DRAM)：15.8GiB --- SM 日志 >$ info SM 版本 = 版本 633，Commit c37b26da SM Config = mx95evk，mSel=0 板 = i.MX95 EVK，attr=0x00000000 硅 = i.MX95 A1 启动模式 = 普通 引导设备 = MMC1 启动阶段 = primary 启动集 = 1 ECID = 0x6E5F04BA0000000500041D0899123F81 PMIC 0 (0x08) = 0x20，0x09，0x10，0x00，0x01 PMIC 1 (0x2A) = 0x54，0x22，0x00，0x0B PMIC 2 (0x29) = 0x55，0x22，0x00，0x0A 编译器 = gcc 14.2.1 20241119

S32k358 获得燃烧 您好， 请说明在与 AFE 通信时导致 MCD 损坏或烧毁的原因。 Re: S32k358 Getting Burn 你好@arun464、 在与外部模拟前端 (AFE) 通信时，MCU（例如 S32K358）可能损坏或出现故障的潜在原因有以下几种： 电压等级不匹配 如果 AFE 使用的逻辑电平（如 5 V）与 MCU 使用的逻辑电平（通常为 3.3 V）不同，则直接连接而不进行适当的电平转换可能会导致 MCU 引脚电压过高。 电源顺序不正确 如果 AFE 比 MCU 先上电（反之亦然），信号线可能会浮动或驱动意外电压，从而导致闩锁或损坏。 接地问题 较差的接地基准或接地回路会在设备之间产生电压差，从而导致通信线路上的电流涌动。 ESD 或 EMI 事件 缺乏适当的 ESD 保护或屏蔽会导致瞬态电压损坏 MCU I/O。 短路或接线错误 不正确的引脚映射或装配过程中的意外短路会导致永久性损坏。 I/O 线路电流过大 相互驱动输出（总线争用）或不正确的上拉/下拉配置会给引脚带来压力。 为了帮助我们进一步分析，请您分享一下： MCU-AFE 接口示意图（包括电源轨和信号线）。 AFE 部件号和使用的通信协议（SPI、I²C 等）。 故障发生前的任何观察条件（如开机期间、负载情况下）。 这将使我们能够提供更具体的保护和设计改进建议。 顺祝商祺！ 帕维尔

i.MX8Qを例に、gpioget/gpiosetでGPIO（libgpiod）を使用する方法 GPIO制御におけるgpiogetおよび「cat /sys/class/gpio」の違い。 gpioget : これは、 libgpiod ライブラリが提供するコマンドライン・ユーティリティです。最新のLinux GPIOキャラクタ・デバイス・インターフェース（ /dev/gpiochipN ）を介して、GPIOラインとやり取りするように設計されています。 /sys/class/gpio : これは、LinuxのGPIO制御のためのsysfsレガシー・インターフェースを指します。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、 libgpiod キャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 以下は、i.MX8Q-MEK、L6.12.3 BSPでテストされたlibgpiodの例です。 デバイスツリーの設定： この例では、GPIO1-05およびGPIO1-06を使用します。GPIO pinctrlを「gpio_test」のような特定のグループ、または「gpio-keys」のようなドライバの下に置くことができます。 gpio_test: gpio-test { pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_test_default>; pinctrl-1 = <&pinctrl_gpio_test_sleep>; status = "okay"; }; gpio-keys { compatible = "gpio-keys"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_example_default>; pinctrl-1 = <&pinctrl_gpio_example_sleep>; key_wakeup2{ label = "wakeup_key"; gpios = <&lsio_gpio2 1 GPIO_ACTIVE_LOW>; linux,code = ; wakeup-source; }; pinctrl_gpio_test_default: gpiotestgrp_default { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x06000061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x06000041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x06000021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x06000021 >; }; pinctrl_gpio_test_sleep: gpiotestgrp_sleep { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x07800061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x07800041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x07800021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x07800021 >; }; pinctrl_gpio_example_default: gpioexamplegrp_default { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x06000021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x06000021 >; }; pinctrl_gpio_example_sleep: gpioexamplegrp_sleep { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x07800021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x07800021 >; }; GPIO機能をテストするためのカーネル・コマンド： gpiodetect および gpioinfo コマンド： root@imx8qmmek:~# gpiodetect gpiochip0 [5d080000.gpio] (32 lines) gpiochip1 [5d090000.gpio] (32 lines) gpiochip2 [5d0a0000.gpio] (32 lines) gpiochip3 [5d0b0000.gpio] (32 lines) gpiochip4 [5d0c0000.gpio] (32 lines) gpiochip5 [5d0d0000.gpio] (32 lines) gpiochip6 [5d0e0000.gpio] (32 lines) gpiochip7 [5d0f0000.gpio] (32 lines) root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed input line 6: unnamed output line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie line 14: unnamed input line 15: unnamed input line 16: unnamed input line 17: unnamed input line 18: unnamed input line 19: unnamed input line 20: unnamed input line 21: unnamed input line 22: unnamed input line 23: unnamed input line 24: unnamed input line 25: unnamed input line 26: unnamed input line 27: unnamed input line 28: unnamed input line 29: unnamed input line 30: unnamed input line 31: unnamed input GPIO1-05およびGPIO1-06が設定される前の現在のGPIO設定を表示するには、 cat /sys/kernel/debug/gpio を使用します。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: gpioset コマンドを使用してGPIO出力を設定します。また、GPIOの方向を変更することもできます（入力→出力）。 #set gpiochip1-5 and 1-6 root@imx8qmmek:~# gpioset -c gpiochip1 6=1 & [1] 700 root@imx8qmmek:~# gpioset -c gpiochip1 5=1 & [2] 702 上記のコマンドの変更点を cat /sys/kernel/debug/gpio および gpioinfo -c 1 で確認してください。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-549 ( |gpioset ) out hi gpio-550 ( |gpioset ) out hi gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed output consumer=gpioset line 6: unnamed output consumer=gpioset line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie   レガシーGPIO SYSFS（L6カーネル以上ではデフォルトで無効）を有効にする方法 このコミットのコメントを参照してください。 https://github.com/nxp-imx/linux-imx/commit/3b4feb21158f873269ff3fbe2fe8d23a88d64b24 commit 3b4feb21158f873269ff3fbe2fe8d23a88d64b24 Author: Linus Walleij Date: Tue Nov 10 15:27:24 2020 +0100 gpio: sysfs: Enforce character device If users select sysfs support they get the character device as well so that end-users cannot complain that they "only have sysfs on my system". They should have the character device at all times. If someone is in so dire need of stripping out the character device while still enabling the sysfs ABI they can very well patch the kernel. Also only show this obsolete option to expert users. Signed-off-by: Linus Walleij Link: <> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 5d4de5cd6759..4dd566f7ea39 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -59,8 +59,9 @@ config DEBUG_GPIO that are most common when setting up new platforms or boards. config GPIO_SYSFS - bool "/sys/class/gpio/... (sysfs interface)" + bool "/sys/class/gpio/... (sysfs interface)" if EXPERT depends on SYSFS + select GPIO_CDEV # We need to encourage the new ABI help Say Y here to add the legacy sysfs interface for GPIOs. パッチから、GPIO_SYSFSを有効にするための最良の方法は、CONFIG_EXPERT= y、次に、CONFIG_GPIO_SYSFS= Yを有効にします。パッチを元に戻す必要はありません。 SYSFSは、LinuxのGPIO制御のためのレガシー・インターフェースです。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、libgpiodキャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 i.MX Processors

verify serial download port through USB2 on i.MX95-A1 EVK with DDR tool in i.MX config-tools Tested on i.MX95-19x19 EVK wit MX95 A1 version, since MX95 A1 has both USB1 and USB2 enabled as SDP. MX95 B0 will only enable one USB port as SDP, and SDP on USB1 and USB2 will be in different part-number. Need to test with config-tools version 25.03, since 25.06 and above only support MX95-B0.   Requirement: 1. USB2.0 cable with type-A male to type-A male. 2. rework on MX95 EVK: Remove R288 on base board, to disable VBUS output on USB2.(MX95 USB2 act as USB device in SDP mode, PC is USB host)     Connect USB cable from PC to MX95-EVk USB2 and power up MX95-EVK. On PC/laptop, in Window Device Manager, should be able to see new HID device popped up. change the configuration of config-tools, by default MX95 USB1 PID is set(0x015D), modify it to the PID of MX95 USB2(0x015C): =================================== Maybe customer could change the files for their USB2 ID 1. C:\\nxp\\i.MX_CFG_25.03\\bin\\python3\\spsdk\\data\\devices\\mimx9596\\database.yaml vid: 0x1FC9 pid: 0x015D 2. C:\\nxp\\i.MX_CFG_25.03\\bin\\python3\\memtool\\common\\sdp_interface.py "MIMX95": (0x1FC9, 0x015D) =================================== without modifying PID, you will see the following error when running DDR Tools: the test procedure shall also work on MX95-B0 with USB2 as SDP. On MX95, need to modify the configuration of the Config-Tools to run DDR test if the SDP is through USB2. MX95 A1(engineering version, not for production) has both USB1 and USB2 enabled as SDP. MX95 B0 will only enable one USB port as SDP, and SDP on USB1 and USB2 will be in different part-number. i.MX Processors

S32K3 的 CAN 采样点测试值太小的问题 你好，恩智浦 在使用 S32K311 进行开发时，选择了 16 MHz 的外部晶振。配置 CANFD 时，CAN 时钟源使用 60 MHz 的 AIPS_PLAT_CLK。为数据字段配置了 80% 的采样点，并启用 TDC。但是，在CANOE中实际测得的采样点只能达到72％。 在其他型号（如 S32K312 和 S32K342）的测试中也出现了这个问题。 以下是我们设置采样点和测试数据的配置之一。我们将采样点配置为 76% ，但实际测试结果为 67% 。 谨致问候， xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 你好@武仙龙 请与我分享您的项目，我会花时间进行测试。 Re: Problem of the CAN sampling point test value being too small for S32K3 你好，@Senlent 我们修改了多种配置。在 S32K3 配置为 80% 的条件下，CANoe 测试的最佳结果是 72% ，谢谢 xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 你好@武仙龙 对于 CAN FD 数据阶段 最新必须在 CANoe 中设置可能的最新采样点。然后，VH6501 发送帧并 延长然后 VH6501 发送帧，并在每个间隔后将各个比特位延长一个刻度。 这似乎是 VH6501 的配置问题。您可以尝试将此处的参数修改为 70%, 76.667%, 和 80% ，然后再次测试。 Re: Problem of the CAN sampling point test value being too small for S32K3 你好，@Senlent 我们咨询了几位经验丰富的工程师。他们介绍说，S32K1 和 K3 的小采样点测试也存在问题，这个问题可能与 MCU 关系不大。使用 CANoe 进行测试时，测试结果都偏低。他们建议，在 80% 的实际测试要求下，可以适当增加为 S32K3 配置的采样点。您可以使用任何恩智浦演示程序进行测试，这种现象应该是可以重现的。 敬上， xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 你好@武仙龙 客户的测试可能存在缺陷，请相信自己的测试。 我将花一些时间进行一些测试，但这不是我的优先事项，可能需要几个月的时间。 天内给您答复。 Re: Problem of the CAN sampling point test value being too small for S32K3 你好@武仙龙 这仍然应该是测试问题，而不是 MCU 引起的。 不过，我会花一些时间做一些简单的测试。我可能会使用示波器直接进行测试，这应该是最精确的测量方法。 Re: Problem of the CAN sampling point test value being too small for S32K3 您好，@Senlent 如果您有更有说服力的结果，也请与我们分享。 我们使用了其他一些仪器进行测试，得到的采样点与我们在设置中预期的比较接近。不过，对于客户来说，CANoe 的行业认可度非常高。 敬上， xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 好的 Re: Problem of the CAN sampling point test value being too small for S32K3 你好@武仙龙 很抱歉，我不能进行这项测试。 我没有合适的干扰设备来进行测试，而 FLEXCAN 报告中的测试结果已经证明测试通过。 我可以私下把相关证明发给你。 Re: Problem of the CAN sampling point test value being too small for S32K3 非常感谢。

Are you having trouble implementing AI/ML into your embedded devices? What can NXP's AI/ML solution, eIQ, do for you? (Japanese blog) Introduction Are you having trouble implementing AI/ML into your embedded devices? (From here on, AI/ML will be abbreviated as AI) Although there are ideas for incorporating AI into your company's products, there are likely to be some challenges, such as: ・Challenge 1: "I can't imagine to what extent AI/ML can be achieved with embedded devices." ・Challenge 2: "I don't know where to start." "I'm concerned about the cost of development tools and learning costs." ・Challenge 3: "I developed the AI components on a PC, but I'm worried about whether I can port it to embedded devices." ・Challenge 4: "I'm interested in the recently popular generative AI, LLM, but I'm not sure if it can be realized on embedded devices." In this article, we will introduce the benefits of NXP's AI solution, eIQ, in addressing these anticipated challenges ! What is eIQ?   Figure 1: eIQ Overview As shown in Figure 1, the eIQ ® ML software development environment is comprised of the software libraries and AI model development environment required to run AI applications on NXP's MCUs (microcontrollers) and MPUs (processors), and is provided free of charge . Issue 1: "I can't imagine how much AI/ML can be achieved with embedded devices."   Figure 2: AI hardware portfolio NXP is a semiconductor vendor with a wide portfolio, ranging from extremely lightweight microcontrollers equipped with the Cortex-M series, a CPU suitable for AI, to processors equipped with the multi-core Cortex-A series, as well as an AI accelerator NPU.   Figure 3: Go point / Application Code Hub   Various AI-related demos for various MCUs/MPUs are available at the links below. By checking the details of these demos, you can get an idea of how much AI processing is possible with each grade of MCU/MPU. ・MCU demo Application Code Hub | NXP Semiconductors ・MPU demo GoPoint for i.MX Applications Processors | NXP Semiconductors Additionally, the following page, modelzoo, has published various models converted for NXP devices along with evaluation data. By checking this page, you can get an idea of how much processing time will be required for each type of processing . modelzoo: GitHub - NXP/eiq-model-zoo: A collection of machine learning models for vision optimized for NXP products   Figure 4: Model Zoo Issue 2: "I don't know where to start" "I'm concerned about the cost of development tools and learning costs"   Figure 5: Model Convert The free eIQ Toolkit allows you to develop AI models using GUI operations from time-series data/image data from sensors you have prepared, without any complicated setup. By combining it with the various sample software mentioned above, you can start developing and evaluating embedded AI without incurring significant learning costs for AI tools. ・Time series model development tool (eIQ Time Series Studio) Figure 6: eIQ Time Series Studio Overview 　　        Figure 7: eIQ TSS training screen Using eIQ Time Series Studio (TSS), you can develop machine learning models that perform anomaly detection, classification, and regression (prediction) using a GUI. End-to-end development functionality reduces the cost of developing time-series AI models for edge devices. Input values from various sensors can be used as training data, making it useful for introducing AI to a variety of devices, as shown below.   Figure 8: eIQ Time Series Studio usage example Click here for "eIQ Time Series Studio (time series model development tool) Overview and Usage " ・Image processing model development tool (eIQ Portal)   Figure 9: eIQ image processing model development function Using the image processing model development function of eIQ Toolkit, you can develop deep learning-based object detection/image classification models using a GUI.It offers a complete set of functions, including an augmentation function that augments the training data by processing images, training with specified hyperparameters, exporting in a state optimized for NXP MCU/MPU, and testing the developed model.   Figure 10: Overview of eIQ Model Water Marking Technology Additionally, the eIQ model watermarking technology function helps protect your models by providing a way to prove whether your image processing models have been illegally copied. For details, please refer to the link below and the eIQ_Toolkit_UG.pdf included in the eIQ Toolkit. eIQ ® Model Watermark Technology | NXP Semiconductors   Issue 3: "I developed the AI components on a PC, but I'm worried about whether I can port it to embedded devices." ・eIQ Portal Model Convert function     Figure 11: eIQ Convert function overview   eIQ not only has a model development function, but also has a function to optimize users' own models for NXP MCUs/MPUs. During conversion, it is possible to specify options such as quantization format and per channel/per tensor, and it is configured so that assets built in a PC or rich SoC- based evaluation environment can be smoothly reused for NXP 's MCUs/MPUs suitable for embedded use in product development. ・Nvidia TAO Tool Extension   Figure 12: Nvidia Tao Toolkit Extension Overview   NXP is the first semiconductor vendor to directly integrate the NVIDIA TAO Toolkit API into its eIQ machine learning development environment, an AI enablement tool, enabling the deployment of NVIDIA pre-trained AI models on NXP edge processing devices. For details, please refer to the article below and the eIQ_Toolkit_UG.pdf included in the eIQ Toolkit. NXP Collaborates with NVIDIA to Accelerate AI Adoption by Making TAO Toolkit Available on NXP Edge Devices | NXP Semiconductors Issue 4: "I'm interested in the recently popular generative AI, LLM, but I'm not sure if it can be realized on embedded devices." ・LLM Solutions/GenAI Flow (Pre-release)   Figure 13: LLM Pipeline NXP is one of the industry's first companies to offer an embedded generative AI/LLM solution called Gen AI Flow. For detailed implementation instructions, please refer to the article " [Getting Started] i.MX 95: LLM_RAG Implementation Hands-on - eIQ Gen AI Flow - ". ------- [Added 4/7/2025] The first revision of eIQ genAI Flow was released in the BSP update for Q1 2025. Please see below for details. GitHub - nxp-appcodehub/dm-eiq-genai-flow-demonstrator: The eIQ GenAI Flow Demonstrator is a Conversational AI Pipeline application designed for NXP i.MX95 devices. ------ This can be achieved by providing an environment incorporating RAG (Figure 14), providing an environment that combines sufficient practicality and security for embedded devices.   Figure 14: RAG Overview   *LLM: Large Language Model *RAG: Retrieval Augmented Generation LLM support enables embedded devices to provide more intuitive, conversational user experiences, from smart home devices that support voice commands to industrial equipment that can be controlled with natural language, to in-vehicle infotainment systems that allow users to command and operate in-vehicle functions through hands-free, two-way conversation. Please also refer to the following white papers: https://www.nxp.jp/webapp/Download?colCode=GEN-AI-RAG-WHITEPAPER   summary NXP's eIQ provides the industry's highest level of functionality required for edge AI development, as shown below, reducing customers' AI implementation and development costs. ・We provide a free environment for developing time-series AI and image processing models using a GUI. - Model conversion function and collaboration with NvidiaTool allow for smooth migration from evaluation environments such as PCs ・By utilizing GenAI Flow , you can respond to the latest trend , generative AI (LLM) . ----- -This article is based on information current as of the time of writing (September 25, 2025). ========================= We are currently unable to respond to comments in the "Comment" section of this post. We apologize for the inconvenience, but when making inquiries, please refer to `` Technical Questions to NXP - How to Contact Us( Japanese Blog) ''. (If you are already an NXP distributor or have a relationship with NXP, you may ask the person in charge directly.) We will introduce the benefits of using NXP's AI/ML solution eIQ to address the challenges of introducing AI/ML to embedded devices. - Plan to release LLM+RAG solution -Developed time series AI and image processing AI models -Convert function allows smooth migration of existing AI/ML assets i.MX RT Processors i.MX Processors introduction MCX SW | Downloads Technology Focus Japanese blog

[Getting Started] Running the i.MX 93 Cortex-M SDK Sample Code - [Part 3] Automatically Starting the M Core with a Bootloader (Japanese Blog) This three-part series provides hands-on instructions on how to build and run SDK sample code for the Cortex-M33 core in the NXP i.MX 93 applications processor. In this article (Part 3), we will introduce the procedure for automatically starting the M Core using a bootloader as a way to automatically start a pre-built M Core image on an evaluation board. [Part 1 ] Building a development environment and M core image [Part 2] M-core execution using U-Boot and remoteproc [ Part 3] Automatic startup of M-core using bootloader (this article) Contents of the 3rd session 4. Automatic startup of M-core by bootloader 4.1 Single boot 4.2 Low Power Boot 4. Automatic startup of M-core by bootloader   This procedure assumes that imx-boot has already been built in Yocto.   To make the M33 boot automatically, you need to build a bootloader that includes the M core image . Therefore, copy the M core image to the imx-boot directory as follows:   $ cd ~/FRDM-93/6.6.36-2.1.0/frdm-imx93/tmp/work/imx93frdm-poky-linux/imx-boot/1.0/git $ cp ディレクトリ>/boards/mcimx93evk/demo_apps/power_mode_switch/armgcc/debug/power_mode_switch_rtos_imx93.bin iMX93/m33_image.bin   *Replace with the actual path.   You will need to create a boot loader suitable for each of the following two boot methods. The following explains how to build and write each. 4.1 Single boot: Normal boot mode ( starting from Cortex-A55 ROM) 4.2 Low-power boot: Starting from low-power state (starting from Cortex-M33 ROM)     4.1 Single boot   In a single boot, the Cortex-A55 ROM loads all containers and images, then jumps to the A55's firmware (FW).   If the container contains a Cortex-M33 firmware image, the Cortex-A55 ROM first loads the Cortex-M33 firmware image, places it in shared RAM (the Cortex-M33 TCM), and requests the EdgeLock Secure Enclave to verify the image. It then writes the CM33 firmware entry point address to the SRC GPR19 register, launches the CM33 core, and continues the A55 ROM boot process. For details, see "9.6.5 Single Boot Flow (Cortex-A55)" in the i.MX 93 Applications Processor Reference Manual .   ①Build the bootloader Applied build scripts flash_singleboot_m33: $(MKIMG) $(AHAB_IMG) u-boot-atf-container.img $(MCU_IMG) $(SPL_A55_IMG) ./$(MKIMG) -soc IMX9 -append $(AHAB_IMG) -c -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) $(MCU_TCM_ADDR_ACORE_VIEW) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) Build Procedure $ make SOC=iMX93 flash_singleboot_m33 $ cd iMX93 $ cp flash.bin flash_frdm_singleboot_m33.bin   ②Writing to SD card   If you use uuu: Change BOOT_MODE to Cortex-A55 serial downloader[1000] and run the following: $ sudo uuu -b sd Using the dd command This is a method to write an image directly from the host PC to the SD card. Connect the target SD card to the host PC using an SD card reader/writer. $ sudo dd if=flash_frdm_singleboot_m33.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync dev/sd[x] is the device name of the SD card. <参考記事> How to build a Linux BSP and write the generated image to the target board ③ Check the startup on the console For SD card boot, change BOOT_MODE to Cortex-A55 USDHC2 4-bit SD3.0[1100]. Turn on the EVK power and if you can see the following output on the PC console (teraterm/minicom, etc.), the setup was successful. Verify that the console display looks like this: A55 Console: M33 Console:   4.2 Low Power Boot In Low Power Boot (LPB), the Cortex-A55 core is asleep, so only the Cortex-M33 is running after POR (Power on Reset). The Cortex-M33 ROM loads the container and image, then jumps to the CM33 FW. For details, see " 9.6.6 Low Power Boot Flow (Cortex-M33) " in the i.MX 93 Applications Processor Reference Manual .   ①Build the bootloader Applied build scripts flash_lpboot: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) ./$(MKIMG) -soc IMX9 -append $(AHAB_IMG) -c \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) -out flash.bin   Build Procedure $ make SOC=iMX93 flash_lpboot $ cd iMX93 $ cp flash.bin flash_frdm_lpboot.bin   ②Writing to SD card   Posted by uuu Change BOOT_MODE to Cortex-A55 serial downloader[1000] and run the following: $ sudo uuu -b sd Writing with the dd command This is a method to write an image directly from the host PC to the SD card. Connect the target SD card to the host PC using an SD card reader/writer. $ sudo dd if=flash_frdm_lpboot.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync dev/sd[x] is the device name of the SD card. ③Consider starting up For SD card boot, change BOOT_MODE to Cortex-A55 USDHC2 4-bit SD3.0[1100]. Turn on the EVK power and check that the boot log is displayed on the PC console (teraterm/minicom, etc.). Verify that the console display looks like this: A55 Console: Nothing is displayed M33 Console: In this article, we explained two configurations for automatically booting the M core using the bootloader : Single Boot and Low Power Boot. ○ This time : [Part 3] Automatic startup of M-core by boot loader (this article) Previous article : [Part 2] M-core execution using U-Boot and remoteproc ←← Previous article : 【Part 1】Building a development environment and M core image     ========================= We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may ask the person in charge directly.) This series will cover three hands-on articles that explain how to build and run SDK sample code for the Cortex-M33 core in i.MX 93 using the low-cost, compact development board, the FRDM i.MX 93 Development Board . [Part 1] Building a development environment and M core image [Part 2] M-core execution using U-Boot and remoteproc [Part 3] Automatic startup of M-core using bootloader (this article) i.MX Processors Japanese blog

开源漏洞和商业使用文档查询 队员们好 我们的客户审查了 MCAL 代码（RTD 3.0.0P01）为该项目使用名为 Black Duck 的开源验证工具。结果，他们发现了 MCAL 中的一些似乎使用开源元器件的文件，如所附文件所示。 有人能对此发表评论吗？有报告吗？ 据我所知，RTD 采用的是恩智浦专有许可证，没有开放源码软件许可证。 顺祝商祺！ 丹尼尔 RTD Re: Open-Source Vulnerabilities and Commercial Usage Documentation Inquiry @danielmartynek 开发团队回复： 我检查了恩智浦社区网站上添加的文件，其中还有一些条目需要确认。也就是说，客户确实使用BlackDuck工具扫描了版本代码包，并生成了调查结果报告。 BlackDuck 工具能找到与我们现有代码和可能公开的代码相匹配的代码片段。这并不意味着任何匹配都是真实的，也不意味着代码是以某种方式窃取的。因此，该工具需要实际人员来分析结果，并根据需要确认或忽略结果。 在 RTD 中，我们很少使用开放源代码，除非有绝对必要，而且在使用时，我们一定会明确说明，并确保其符合恩智浦的许可证。   当 S32K3 RTD 3.0.0P01 版本于 2023 年 3 月 31 日，我们仍在使用 BlackDuck Protex，这是同一家供应商的旧工具，但搜索能力不如新工具。当时我们提交了一份 SCR 报告，其中列出了所有包含的元器件（附在本电子邮件中）。 附上 SCR 文件（SBOM 格式的前身，已在安装程序旁边提供）。它提到了所使用的元器件和许可证。如果调查仍在继续，我们将需要获取该版本并再次对其进行扫描，但要使用新的BlackDuck工具并为其提供新的报告（本质上是重做发布时已经完成的工作——扫描代码，提取每行代码，看看是否有任何问题）。

关于使用 RTD 进行功能安全配置的问题 你好，团队 请问 S32K314 的热电阻（MCAL/SPD）配置如何？ Q1.我没有在 RTD 上找到关于带中断的 PLL LOL 的 "配置"。 哪种配置（来自带有 SPD 的 MCAL RTD）可以配置 LOL 的 RESET 或中断？ Q2.对于带中断功能的低压检测 和 HVD，我没看清哪个与低压检测 和 HVD 有关。 请问哪一个是低压检测和 HVD 的中断反应，“MCU_ERROR_ISR_NOTIFICATION” 还是 “MCU_PMC_NOTIFICATION”？ Q3.对于 ERM0 配置，如何配置 ERM（使用 RTD/SPD），例如下面的代码？ 谢谢！ RTD S32_CONFIG_TOOL S32DS Re: Question about Safety configuration using RTD 是的 用户可在 EB Tresos 的此节点中配置其用户通知，MCU_ERROR_ISR_NOTIFICATION 将在 PMC_VoltageError_IRQHandler> 中调用 ...> 然后，Mcu_Ipw_ReportPowerErrorsCallback 将调用此通知 Re: Question about Safety configuration using RTD 你好@congnguyenphu 感谢您的回复。 为了再次确认，低压检测/HVD 与 MCU_ERROR_ISR_NOTIFICATION 有关，不是吗？ 谢谢！ (我将关闭此票......） Re: Question about Safety configuration using RTD 你好@Luke_Chun 1.要配置 PLL LOL 的中断，Platform 模块中指向的 IRQ 必须正确。应启用 SoC_PLL_IRQn（NVIC 212）。它在参考手册和我们的头文件中提到： 但是，我检查了 RTD 代码包，我们不为这个中断提供 ISR。我在 SPD 包中也找不到。因此，用户需要为该中断处理程序实现自己的 ISR。 2。NVIC 52 参考手册中提及的带中断的低压检测 和 HVD： 在 RTD 的 MCU 集成手册中，我们提供了名为 PMC_VoltageError_IRQHandler 的 ISR 来处理该问题： 您可以在 RTD 平台中通过 IRQ"PMC_IRQn" 配置并启用它。 在 PMC_VoltageError_IRQHandler() 中，它还通过"MCU_ERROR_ISR_NOTIFICATION "宏调用MCU 配置中用户自定义的回调通知 McuErrorIsrNotification。 3.如何配置 ERM： -在 RTD 代码包中：我们在 EB Tresos/S32CT 上没有配置来帮助用户配置 ERM 寄存器的值。但 RTD 在 BaseNXP/header/S32K314_ERM.h 中提供了宏，帮助用户设置该寄存器的值： 用户可以使用这些宏作为裸机代码来设置寄存器的值。 -在 SPD 代码包中：我指的是 emcem 插件，文件 emceM_ERM.C在函数 eMcem_Erm_Init()中，以下宏用于设置 ERM[CR] 寄存器的值：erm_cr_addr32()、safetybase_reg_write32()