EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 这个McuPGOOD_POLARITYControl配置项在该路径下找不到 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 Hi@WeiCh 我不确定你是否可以下载，你可以尝试一下，如果不可以，请联系你的代理商或者FAE来获取评估权限。 https://www.nxp.com/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 在哪可以下载30.0.0吗？30.0.0能打开29.0.0的工程吗？ Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 Hi@WeiCh 我看这个版本适配的EB Tresos版本应该是30.0.0,不是你所使用的版本。 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 Hi@WeiCh 你这界面的风格不对阿，新版本的风格和之前旧的完全不一样的，你的界面还是老版本的风格。 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 Hi@WeiCh ok,不客气 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 Hi@WeiCh 在下载界面有这样的提示，你要修改后缀 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 好像有点问题，运行setup提示没有安装包，可以解压EBtresosStudio_EBtresosStudio.zip后直接打开应用，但应用界面还是旧的： Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 这是30.0.0的界面，好像还是没有这个配置项。 Re: EB更新RTD 7.0.0_QLP03时报告McuPGOOD_POLARITYControl配置错误 已经可以了，感谢！

如何替换自定义板的 Yocto 电路板支持包中的 DDR 二进制文件？ 你好 正在尝试替换自定义板的 Yocto 电路板支持包 中的 DDR 二进制。 新计算机已创建，配方 ddr-firmware 的目录也是在自定义元层中创建的，其中包含所需的文件。但是，为 SRC_URI 分配新值并删除配方附加中的原始值并不能阻止 Bitbake 在评估板的原始路径中搜索。不使用配方追加也不会改变本次搜索的任何内容。 似乎唯一有效的方法是掩盖原始配方并在自定义层中创建新配方。 但我不认为这是一种可取的方式。使用为自定义计算机创建的 DDR 二进制文件应该很容易做到这一点。这里可能遗漏了什么？ 谢谢您！ 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 好的，它能用。似乎与 NXP_FIRMWARE_LOCAL_DIR 中设置的文件夹不一致。但不管怎么说，它还是有用的。 还有一个问题，如何关闭自定义层 .bbappend 中的 NXP-EULA 许可证？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 感谢您的回复。 客户的 DDR 还应该有 DDR 固件，你能否尝试参考 S32G3_Linuxbsp_44.0_user_Manual.pdf 在 Yocto 中版本电路板支持包期间添加 DDR 固件。 BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 你好，乔伊、 感谢您的回复。 它是 S32G3，电路板支持包 是 "bsp44.0"。 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您与我们联系。 你使用的是哪个版本的电路板支持包？ 您使用的是 S32G3 还是 S32G2 芯片？ BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 添加 .bbappend 时尝试过，但不起作用用于定制板。 ERROR: /home/crane/work/yocto/sources/meta-alb/meta-alb-bsp/recipes-bsp/ddr-firmware/ddr-firmware.bb: Unable to get checksum for ddr-firmware SRC_URI entry NXP-EULA: file could not be found The following paths were searched: 尝试了 .bbappend只有 SUMMARY，LICENSE ="CLOSED" 和 LIC_FILES_CHKSUM ="" ，也试过不使用 .bbappend、都得到了相同的错误信息。 这是处理自定义 DDR 二进制文件的唯一方法是掩盖恩智浦的原始配方并创建自定义配方，而不是根据原始配方添加配方附加吗？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 请尝试修改文件夹 (fsl-auto-yocto-电路板支持包-build_s32g274ardb2/conf) 中 local.conf 文件。 accept_fsl_eula ="1" BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 您是否在文件夹中添加了 NXP-EULA 文件？ BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 我试图将这个文件复制到原始配方或自定义配方中，但都不起作用。两种方法都能找到文件，但都会产生以下错误信息： ERROR: No recipes in default available for: /home/crane/work/yocto/sources/meta-crane/recipes-bsp/ddr-firmware/ddr-firmware_%.bbappend 由于我没有使用恩智浦的DDR二进制文件，我认为使用恩智浦生成的NXP-EULA没有意义。禁用检查 NXP-EULA 是感知的，对吧？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您的回复。 我们应该找到问题的根源。请尝试在 Yocto 中版本 BSP44 以使用恩智浦的 DDR 固件和 NXP-EULA 文件。如果你能成功版本 BSP44，你可以尝试更换 DDR 固件，然后重新版本。 BR 乔伊

针对同步动态随机存取存储器(SDRAM)版本构建的 RT1170 调试 您好， 我正在使用 MCUXpresso 及其 SDK 为 RT1170 开发一个应用程序。 所提供的示例项目似乎都是使用 “DTC” RAM 版本的。与许多其他用户一样，我的应用程序太大了，无法容纳在那里，所以我正在尝试使用“同步动态随机存取存储器(SDRAM)”。 在尝试了论坛上其他一些帖子（尤其是https://community.nxp.com/t5/i-MX-RT/MCUXpresso-and-RT1050-download-and-debug-in-SDRAM/m-p/896979）中提出的解决方案后现在，我可以执行我的程序，如果应用程序已闪存，我还可以调试程序。 但是，如果我使用 “将应用程序链接到RAM” 进行版本和执行，那么一旦遇到断点，应用程序通常会卡在那里。 我的假设是这是因为我没有正确初始化同步动态随机存取存储器(SDRAM)。上述文章使用 “rt1050_SDRAM_init.scp 作为调试器初始化 同步动态随机存取存储器(SDRAM) 控制器的连接脚本”。如果我使用这个文件，失败也就不足为奇了。 我不知道如何调整这个脚本才能在 RT1170 上运行。有没有人这样做过，或者能提供如何生成的建议？ 感谢您提供的任何帮助。 Re: RT1170 debugging when application is built for SDRAM 你好@ Jingpan 按照提供的步骤，使用 RT1170_BriefOverview_v210.pdf 中提到的修改刷新 hello world，我可以在调试模式下使用同步动态随机存取存储器(SDRAM)。 但是在这种变化之后，同步动态随机存取存储器(SDRAM)也用于存储代码。 在我的应用程序中，我希望代码存储在闪存中，而 BOARD_SDRAM 仅用于堆和堆栈部分。 我将把我的应用程序闪存到闪存中，该应用程序的堆和栈部分将使用 BOARD_SDRAM。 请指导我进行所需的更改。 Re: RT1170 debugging when application is built for SDRAM 谢谢@ Jingpan、 我只需要添加 .scp文件，结果成功了。 我已经掌握了第 5、第 6 和第 8 步，但我会试试其他步骤。 如果有帮助我还在 board.c 中做了以下更改，我认为这等同于<https://community.nxp.com/t5/i-MX-RT/MCUXpresso-and-RT1050-download-and-debug-in-SDRAM/m-p/896979>中描述的 RT1170_SDRAM_NOT_CACHED： #ifdef USE_SDRAM #ifndef RT1170_SDRAM_NOT_CACHED /* 区域 9 设置：内存为普通类型，不可共享，外部/内部回写 */ MPU->RBAR = ARM_MPU_RBAR(9, 0x80000000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 0, 0, 1, 1, 0, ARM_MPU_REGION_SIZE_64MB)； #else MPU->RBAR = ARM_MPU_RBAR(9, 0x80000000U); MPU->RASR = ARM_MPU_RASR(0, ARM_MPU_AP_FULL, 1, 0, 0, 0, ARM_MPU_REGION_SIZE_64MB); #endif /* RT1170_SDRAM_NOT_CACHED */ #endif Re: RT1170 debugging when application is built for SDRAM 你好@robert_s、 此脚本适用于 RT1050/60，但不适用于 RT1170/60。您可以使用附带的脚本。除脚本文件外，您还需要执行其他步骤。 在 C/C++ 版本 > MCU 属性设置中的内存详细信息中，将 BOARD_SDRAM 移至 SRAM_DTC_M7 上方。 连接脚本使用 RT1170_connect_M7_wake_M4_SDRAM_init.scp。 在附加选项中添加 --cachelib libm7_cache.so。 如果使用 USB/以太网/SDHC，请将 DMA 缓冲区放入非缓存区。 在 MCU C 编译器> 预处理器中添加 USE_SDRAM。 在属性中选择链接到 ram->设置->受管链接器脚本 如果项目与 USB 关联，则在 MCU C 编译器> 预处理器中添加 DATA_SECTION_IS_CACHEABLE=1。 如果项目与不带 freertos 的 USB 主机相关联，则将堆放入 DTCM 或不可缓存区域 (bm) 此致， 景

报告 K5 RTD 引脚配置 嗨，团队 我有一份报告与 K5 引脚配置有关。(0.8.0 CD3) GPIO 258 需要一些限制。 所以我用了下面的方法。 我认为这与下文有关。 顺便说一下，如果我使用 MCAL，它看起来会正常工作... 谢谢。 RTD 来源：恩智浦内部来源：恩智浦内部 Re: Report K5 RTD pin configuration 嗨，@Luke_Chun、 如果使用 Dio_WriteChannel 向 GPIO258 写入数据，则该函数将通过 GPDO 寄存器向 GPIO258 写入数据。 但 Siul2_Dio_Ip_WritePins() 函数将写入 PGPDO 寄存器。GPIO258 相当于 PGPDO16 寄存器，但硬件不包含该寄存器。因此，这可能是硬件问题，用户不能使用 Siul2_Dio_Ip_WritePins() 函数向 GPIO258 写入数据。在 Siul2_Ip 层中，我建议你可以使用 siul2_dio_IP_setGPDO 或 siul2_dio_IP_ClearGPDO 函数在 u8siul2Instance = 3 和 gpdoNum = 258 的情况下设置/清除 GPIO258（取自 RTD_DIO_UM.pdf 文件中的图 3.1 GPIO 分配）。 目前，RTD 驱动程序尚未通过有关此解决方法的验证，但我认为你可以尝试这样做 。 顺祝商祺！ 丹

LS1046A RDB: LinuxのGPIO割り込み処理パフォーマンスをテストするためのGPIO こんにちは、 私は LS1046ARDB を使用しており、割り込みレイテンシを測定したいと考えています。私の目標は、外部信号発生器 (入力 GPIO) を介して割り込みをトリガーし、それに応じて別のピン (出力 GPIO) を切り替えて、オシロスコープで遅延を測定することです。 GPIO として多重化できるボード ヘッダー上のアクセス可能なピンを探しています。 私のアイデアは、IEEE-1588 ヘッダー (J11) を使用することですが、これが機能するかどうか、また何をしなければならないかはわかりません。 リファレンス・マニュアルには、EC2 ピンは RCW (EC2 = 1) を介して GPIO3 として設定できると記載されています。 RCW で EC2=1 を設定すると、これらの信号は J11 にルーティングされますか? LS1046A RDB には、これに使用できる他の簡単にアクセスできるピンはありますか? ご協力いただきありがとうございます QorIQ LS1デバイス Re: LS1046A RDB: GPIOs for testing gpio interrupt handling performance of linux ご協力いただきありがとうございます！これで動作するはずです。GPIO_2[1]、GPIO_2[2]、GPIO_2[3]はTP14、TP13、TP11に対応していることがわかりました。 Re: LS1046A RDB: GPIOs for testing gpio interrupt handling performance of linux SPI 信号と多重化されたGPIOを使用できます。 GPIO_2[1]、GPIO_2[2]、GPIO_2[3] SPIインターフェースはRDBでは使用されず、テストポイントに終端されます。 「表3-8」を参照してください。詳細については、LS1046ARM の「SPI 信号構成」を参照してください。

k344中心对齐pwm中心点触发adc bctu采样 基于https://community.nxp.com/t5/S32K-Knowledge-Base/RTD400-K344-Center-Aligned-PWM-Trigger-ADC-BCTU/ta-p/2034211、我想知道为什么需要三次 BCTU 触发信号中断才能触发 BCTU 水印。我想实现只触发信号一次中断，然后在中断中修改PWM周期，读取ADC值等。在 EB MCAL 开发的基础上，有哪些好的解决方案或示例例程可以实现相同的功能？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您关注我们的产品并为我们的社区做出贡献。 您可以直接回复帖子，以获得帖子主人的反馈。 另一方面，你可以参考另一种方法，使用单个 BCTU 触发信号： S32M27x/S32K3 - eMIOS/BTCU/ADC/DMA - [RTD600] -> https://community.nxp.com/t5/S32M-Knowledge-Base/S32M27x-S32K3-eMIOS-BTCU-ADC-DMA-RTD600/ta-p/2155542 有关 MCAL 的实现，请参阅 ADC 到 PWM 的硬件抽象层示例： 前往 S32K3 页面 -> 设计资源-> 软件-> S32K3 参考软件-> 汽车软件-S32K3-硬件抽象层-> SW32K3 HAL 集成示例 2025.07 它执行以下 ADC 触发信号： 同时，它根据捕获的 ADC 值更新占空比。 希望这些信息对您有所帮助。 Re: K344中心对齐PWM中心点触发ADC BCTU采样 感谢您的解决方案。我想知道多次触发信号中断的原因以及避免此类中断的方法。或者，我是否有可能通过配置禁用该中断源？ Re: K344中心对齐PWM中心点触发ADC BCTU采样 您好， 如果启用 BCTU 触发信号通知，则在 BCTU 触发信号 ADC 时调用。如示例中的 BCTU CL 包含 3 个项目，每个输入 (EMIO) 触发信号将触发三次 ADC。 只需在“触发信号”选项中输入 NULL 即可禁用此通知。 BR, Petr

在 SNVS 内的 HPRTC 上定期& 警报中断 您好，NXP团队： 我正试图配置每 1 秒一次的周期性中断和 30 秒后的警报中断。我的 ISR 看起来是这样的 void SNVS_HP_NON_TZ_IRQHandler(void) { volatile uint32_t flagStatus = SNVS_HP_RTC_GetStatusFlags(SNVS); volatile uint32_t result = flagStatus & kSNVS_RTC_PeriodicInterruptFlag; snvs_hp_rtc_datetime_t rtcDate; if (result) { __asm(" NOP"); SNVS_HP_RTC_GetDatetime(SNVS, &rtcDate); dbg_info("Periodic Interrupt @ %04hd-%02hd-%02hd %02hd:%02hd:%02hd\r\n", rtcDate.year, rtcDate.month, rtcDate.day, rtcDate.hour, rtcDate.minute, rtcDate.second); if (rtcDate.second == 30U) { __asm(" NOP"); __asm(" NOP"); __asm(" NOP"); } SNVS_HP_RTC_ClearStatusFlags(SNVS, kSNVS_RTC_PeriodicInterruptFlag); } if (SNVS_HP_RTC_GetStatusFlags(SNVS) & kSNVS_RTC_AlarmInterruptFlag) { __asm(" NOP"); dbg_info("Alarm:\r\n"); /* Clear alarm flag */ SNVS_HP_RTC_ClearStatusFlags(SNVS, kSNVS_RTC_AlarmInterruptFlag); } SDK_ISR_EXIT_BARRIER; } 我的初始化过程是这样的 SNVS_HP_RTC_GetDefaultConfig(&snvsRtcConfig); snvsRtcConfig.periodicInterruptFreq = 15; SNVS_HP_RTC_Init(SNVS, &snvsRtcConfig); dbg_info("SNVS HP example:\r\n"); /* Set a start date time and start RT */ rtcDate.year = 2014U; rtcDate.month = 12U; rtcDate.day = 25U; rtcDate.hour = 19U; rtcDate.minute = 0; rtcDate.second = 0; /* Set RTC time to default time and date and start the RTC */ SNVS_HP_RTC_SetDatetime(SNVS, &rtcDate); SNVS_HP_RTC_StartTimer(SNVS); dbg_info("\r\n"); SNVS_HP_RTC_GetDatetime(SNVS, &rtcDate); rtcDate.second = 30u; SNVS_HP_RTC_SetAlarm(SNVS, &rtcDate); /* Get alarm time */ SNVS_HP_RTC_GetAlarm(SNVS, &rtcDate); /* Print alarm time */ dbg_info("Alarm will occur at: %04hd-%02hd-%02hd %02hd:%02hd:%02hd\r\n", rtcDate.year, rtcDate.month, rtcDate.day, rtcDate.hour, rtcDate.minute, rtcDate.second); /* Enable SNVS alarm interrupt */ SNVS_HP_RTC_EnableInterrupts(SNVS, kSNVS_RTC_AlarmInterrupt); SNVS_HP_RTC_EnableInterrupts(SNVS, kSNVS_RTC_PeriodicInterrupt); NVIC_EnableIRQ(SNVS_HP_NON_TZ_IRQn); 在我的 ISR 中，我观察到当警报中断和定期中断同时发生时（HPSR 中的两个位都被设置），定期定时器标志将在 ISR 中首先被清除，因为它具有隐含优先级（如果检查定期 ISR，则优先）。在 if 块中，当定期计时器状态标志被清除时，由于某种原因，我看到我的警报状态标志也被清除，而定期计时器的定时器标志将再次转换为 1。只有下一次才会清除。正因为如此，我的闹钟中断服务完全失灵了。 是否在实施过程中出了什么问题？ 谢谢！ Re: Periodic & alarm interrupts on HPRTC within SNVS 您好！ 了解。目前，我将只使用周期定时器来充当警报中断的角色。 感谢您的及时支持！ Re: Periodic & alarm interrupts on HPRTC within SNVS 你好@AmanKumbhani， ，我复制了你的问题。我将在内部进行检查，以确认这是否是一个错误，或者这两个功能是否相互排斥。这可能需要一些时间。 不过，就您的应用而言，我认为以下 if 条件可以起到警报中断的作用： if (rtcDate.second == 30U) { __asm(" NOP"); __ asm(" NOP"); __asm(" NOP"); } BR Habib Re: Periodic & alarm interrupts on HPRTC within SNVS 嗨，哈比卜 感谢您的回复。老实说，我没有固定的用途。我正在对此进行测试，以便通过包装器为应用程序层提供功能，因此遇到了这个问题。 您能在自己的电脑上重现这个问题吗？ 谢谢您！ Re: Periodic & alarm interrupts on HPRTC within SNVS 你好，@阿曼-库姆巴尼、 对延迟回复表示歉意。为了更好地为您提供支持，能否请您说明申请的目的？ 在我看来，您似乎可以完全依赖于周期性中断，因为您已经在每秒钟输入一次中断。你可以像在以下几行代码中一样简单地轮询秒值：i f (rtcDate.Second == 30U) { __asm(" NOP"); __ asm (" NOP "); __asm (" NOP "); } 最终，两种方法都会触发信号相同的中断，因此仅使用定期中断可能会简化您的实现。 BR Habib. Re: Periodic & alarm interrupts on HPRTC within SNVS 您好@AmanKumbhani， ，我将运行测试来复制这一问题，并详细查看这一行为。感谢您的耐心等待。 BR Habib. Re: Periodic & alarm interrupts on HPRTC within SNVS 嘿、 谢谢你的澄清！我会研究一下，并按照您的建议进行一次测试。 最好的 安缦 Re: Periodic & alarm interrupts on HPRTC within SNVS 你好，@阿曼-库姆巴尼、 造成这一问题的根本原因有两个。第一个问题与您配置 RTC 警报的方式有关： SNVS_HP_RTC_EnableInterrupts(SNVS, kSNVS_RTC_AlarmInterrupt); SNVS_HP_RTC_EnableInterrupts(SNVS, kSNVS_RTC_PeriodicInterrupt); 如第 24.6.1.3 章所述在 RM 中的 "SNVS_HP 控制寄存器（HPCR）"中，使能警报 "HPTA_EN "的位与 32 kHz 时钟同步。这意味着，当您设置其值时，需要等待它的更新，因为内核的运行速度通常比 32 kHz 快得多。这种等待机制的一个示例可以在启用 "RTC_EN "位的函数"SNVS_HP_RTC_StartTimer" 中看到，如下图所示： 另一方面，第二个问题与函数 "SNVS_HP_RTC_ClearStatusFlags "的工作方式有关。该函数对寄存器执行 OR 运算。下面就是一个例子： 寄存器：11 （两个标志都已设置。） 屏蔽：10（kSNVS_RTC_PeriodicInterruptFlag） OR：11 因此，当调用 "SNVS_HP_RTC_ClearStatusFlags "时，它将向 HPSR 寄存器写入 "0b11"，从而清除周期和警报标志，因为这些位通过写入 1 来清除。因此，在清除状态标志之前，必须先读取这两个状态标志。因此，以下代码将导致错误： if (SNVS_HP_RTC_GetStatusFlags(SNVS) & kSNVS_RTC_AlarmInterruptFlag) { __asm(" NOP"); dbg_info("Alarm:\r\n"); /* Clear alarm flag */ SNVS_HP_RTC_ClearStatusFlags(SNVS, kSNVS_RTC_AlarmInterruptFlag); } 希望对您有所帮助。 BR Habib

S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 現在、SimulinkでPWM生成にFlexIOピンを使用する方法を理解しようとしています。Simulinkには、PWM生成にFlexIOピンを使用するためのブロックは見当たらず、I2C、SPI、およびUARTのみに使用されています。どんな助けでも大歓迎です。 Re:S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 教えて頂きありがとうございました

CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hello NXP Community  I’m using the CLRC66301B NFC reader IC and trying to activate Power-down mode by driving the PDOWN pin high (3.3 V), as specified in the datasheet. However, the current draw remains at 2 mA, while the datasheet indicates it should be between 8 nA and 40 nA in power-down. Setup Details: PDOWN pin: 3.3 V (constant high) VDDs: VDD(TX), VDD(AUX), VDD(MCU) all at 3.3 V Interface: I²C (idle during test) XTAL: 27.12 MHz crystal connected No communication or activity during current measurement Measured current: ~2 mA Questions: 1. Are any register configurations required before asserting PDOWN? 2. Could IRQ, XTAL, IFSEL, or other GPIOs prevent entry into true power-down mode? 3. Does PDOWN require additional timing or sequencing with VDD or reset? Any insights or suggestions would be appreciated. Thanks, Umasankar NFC Controller Solutions Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hi, When you mention that current consumption is reduced when SDA and SCL are physically disconnected, does it mean that you are removing all connections on this pin (removing both Host MCU and pull-up resistors), or is it that those lines are only disconnected from the Host MCU? Also, could you please describe the method, equipment and test point you are using for the measurement? Regards, Eduardo. Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Dear NXP Team, I conducted power-down current testing using the official CLEV6630ARD board with the CLRC66303B chip. The current reaches ~40 nA only when SDA and SCL are physically disconnected before any I²C communication. If I²C is used even once, current remains above 2 mA, even after asserting PDOWN high. Could you please clarify what should be done with the I²C lines before entering PDOWN? Specifically: Should the MCU set SDA and SCL to high-impedance (input, no pull) before asserting PDOWN? Does any prior I²C communication prevent the chip from entering true hard power-down? Thank you. Follow-Up: CLRC66303 – High Current in Hard Power-Down Mode (CLEV6630ARD-Based Design) Dear NXP Team, I previously raised a query regarding hard power-down current with the CLRC66301HN, and your response recommended migrating to the CLRC663 Plus family (CLRC66303). I have since switched to CLRC66303B, using a custom board based on the CLEV6630ARD reference design, and I would like to follow up with updated test results. Your earlier reply focused on LPCD behavior and AN11783, but this issue concerns only hard power-down via the PDOWN pin, with no RF field or LPCD active. Power-Down Current Measurements (CLRC66303B): >When PDOWN is LOW (chip active, RF field on): ~100 mA >When PDOWN is HIGH and I²C pull-ups are present: ~1.2 mA >When PDOWN is HIGH and I²C lines are driven LOW: ~6.6 mA >When PDOWN is HIGH and I²C lines are physically disconnected before any use: ~40 nA  Only when SDA and SCL are physically disconnected before any I²C communication does the chip draw ~40 nA in PDOWN. If I²C is used even once, current remains high even after PDOWN is asserted HIGH. Hardware Setup Summary: Chip: CLRC66303B, I²C mode. MCU: TI CC2652R7, 100 kHz I²C Voltage: 3.3 V regulated Pull-ups: 4.7 kΩ to 3.3 V on SDA/SCL Unused pins: Pulled as per datasheet No RF or LPCD features enabled Schematic design: Based on CLEV6630ARD (attached) Questions for Clarification: 1. Are SDA/SCL internally biased during PDOWN mode? 2. Does any prior I²C activity prevent true power-down, even if PDOWN is later set HIGH? 3. Is it necessary to set MCU I²C pins to Hi-Z (input, no pull) before asserting PDOWN? 4. Is there an NXP-recommended method to reliably achieve <100 nA in hard PDOWN mode without physically disconnecting I²C lines? We aim to ensure battery longevity and must achieve the datasheet-stated low-power behavior. Any guidance or documentation specifically about PDOWN behavior and I²C leakage would be greatly appreciated. Schematic is attached for reference. Best regards, Umasankar C Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hello @Umasankarc Hope you are doing well.  I understand you are using a custom board based on CLRC66301HN (non-plus), is this correct? If so, please consider that we recommend using the CLRC663 plus family (CLRC66303) instead. HIGH level on pin PDOWN should enable a hard power-down. Power-down current (Ipd) stated in the Data Sheet corresponds to the sum of all supply currents in CLRC663 chip; however, additional power might be consumed by external components embedded in the board. Some recommendations for a low power design are described in AN11783 CLRC663 plus Low Power Card Detection, Section 3.4. Regards, Eduardo.

在 MPC5748G MCU 的扩展 SPI 模式下，EOQF 标志未被设置 你好，团队、 我在 MPC5748G MCU 中使用扩展 SPI 模式进行 32 位帧传输，发现传输结束时 EOQF 标志没有被设置。我在 MPC5777C MCU 上使用了相同的代码，一切正常。 你知道为什么会出现这个问题吗？任何建议或想法都会被极大地采纳。 期待您的真知灼见。 谢谢！ 此致， 克里希纳 用于 i.MX RT 的 eIQ 机器学习软件 Re: EOQF flag is not getting set in EXTENDED SPI mode in MPC5748G MCU 你好，伊谢、 谢谢您的答复。我已正确配置 SPI 模块以传输 32 位帧，如果不查看 EOQ 标志，读取和写入均可在 MPC5748 中正常工作。我还设置了 EOQ 标志，以便传输最后一个字，但模块不承认这一点。 仅供参考，我不在 EOQ 中使用中断我正在轮询寻找那个标志。 您提到"虚假队列结束语" ，能否请您解释一下这是什么意思？ 谢谢！ 此致， 克里希纳

下一代功能安全架构 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 概述 S32x 下一代安全架构，涵盖 ASIL B 至 ASIL D。有哪些新功能以及我们如何更好地为客户提供全套安全附属品，包括 MCU HW、SW 和 SBC HW。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 概述 S32x 下一代安全架构，涵盖 ASIL B 至 ASIL D。有哪些新功能以及我们如何更好地为客户提供全套安全附属品，包括 MCU HW、SW 和 SBC HW。

FTF-ACC-F1276.pdf This session will explain how Freescale can enable customers to develop 76-81 GHz short and long range radar applications using the MPC577xK MCU, it will explain the concepts of the radar algorithms, including practical aspects such as SDADC or MIPI CSI sampling, Chirp Generation, Data Compression, R,V FFT, Detection and Tracking algorithms, and the benefits of the new Freescale IP that can allow them to improve their system resolution and accuracy. In this session customers will take away a detailed understanding of how to develop fast modulation radar systems using the MPC577xK MCU including the BOM cost advantages it also brings. This session will explain how Freescale can enable customers to develop 76-81 GHz short and long range radar applications using the MPC577xK MCU, it will explain the concepts of the radar algorithms, including practical aspects such as SDADC or MIPI CSI sampling, Chirp Generation, Data Compression, R,V FFT, Detection and Tracking algorithms, and the benefits of the new Freescale IP that can allow them to improve their system resolution and accuracy. In this session customers will take away a detailed understanding of how to develop fast modulation radar systems using the MPC577xK MCU including the BOM cost advantages it also brings.

FreeRTOS 与 MQX RTOS 的快速概述 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> FreeRTOS 与 MQX RTOS 的快速概述 MQX实时操作系统是专为单处理器、多处理器和分布式处理器嵌入式实时系统设计的。飞思卡尔半导体公司在其微处理器中采用了该软件平台。这包括 Kinetis、Coldfire、PowerPC、ARC、ARM、StrongARM、xscale CPU。MQX RTOS 的主要特点是可扩展的大小、面向组件的架构和易于使用。 FreeRTOS 是一种流行的嵌入式设备实时操作系统内核，已移植到 35 种架构。它在 GPL 下分发，但有一个可选例外。FreeRTOS 占用空间非常小，开销很低，执行速度非常快。内核本身仅由三或四个 C 文件组成。最少 4-8k 字节闪存。 类似功能：[待完成] 任务、事件、信号量、互斥量、消息队列、空闲省电                                                                  Freertos 的独特功能： 1 任务通知：每个 RTOS 任务都有一个 32 位通知值，该值在创建 RTOS 任务时初始化为零。RTOS 任务通知是直接发送给任务的事件，可以解除对接收任务的阻塞，并可选择更新接收任务的通知值。 2 递归互斥锁：递归使用的互斥锁可以被所有者反复“获取”。直到所有者为每次成功的 xSemaphoreTakeRecursive() 请求调用 xSemaphoreGiveRecursive() 之后，互斥锁才会再次可用。例如，如果某个任务成功“获取”同一个互斥锁 5 次，则该互斥锁将无法供任何其他任务使用，直到该任务也将互斥锁“归还”5 次为止。 3 堆栈溢出钩子/通知：每个任务维护自己的堆栈。任务堆栈使用的内存在任务创建时自动分配，并由传递给 xTaskCreate() API 函数的参数确定大小。堆栈溢出是导致应用程序不稳定的一个常见原因。因此，FreeRTOS 提供了两种可选机制，可用于协助检测和纠正此类事件 4 延迟中断处理：从应用程序中断服务程序中使用，将功能的执行延迟到 RTOS 守护进程任务。提供了一种机制，允许中断直接返回到随后将执行挂起功能的任务。这使得回调函数能够与中断连续执行 - 就像回调在中断本身中执行一样 5 多个对象上的阻塞：队列集是 FreeRTOS 的一项功能，它使 RTOS 任务能够在同时从多个队列和/或信号量接收时阻塞（挂起）。队列和信号量被分组为集合，然后，任务不再阻塞在单个队列或信号量上，而是阻塞在集合上。 MQX 的独特功能： 1 基于所有权的资源破坏：[待完成] 2 名称服务：任务可以将一个 32 位数字与一个字符串或符号名称关联起来。MQX RTOS 将这种关联存储在名称数据库中，该数据库中的所有任务 处理器可以使用。数据库避免使用全局变量。 3 处理器间通信：应用程序可以在多个处理器上同时运行，每个处理器上都有一个 MQX RTOS 的可执行映像。图像使用由内存或通过处理器间通信的通信链路传输的消息进行通信和协作。每个图像中的应用任务不必相同，而且实际上通常是不同的。 4 看门狗：看门狗是可选组件，可让用户检测任务级别的任务饥饿和死锁情况。 5 任务队列调度：您可以使用任务队列来显式调度任务，或创建更复杂的同步机制。由于任务队列提供的功能很少，因此速度很快。应用程序可以在创建任务队列时指定先进先出 (FIFO) 或循环 (Round Robin) 调度策略。

DAC PDB DMA Vybrid The attached project shows a configuration for the DAC and its functionality is explained in the below points: The PDB triggers the next DAC conversion. The DAC features an internal buffer (DAC_DATx) that contains that data to be converted. The DAC data to be converted is determined by  an internal pointer. This internal pointer increases or moves to the next element in the buffer on every PDB trigger The DAC uses the Data Buffer as normal mode. This means that the buffer works as a circular buffer. When the internal pointer reaches some point in the internal buffer, the DMA is triggered and it transfers the new data from an iRAM buffer to the DAC internal buffer. In this specific example the DMA treats the source as a circular buffer, because the source buffer size is 512 bytes but the destination (DAC_DATx) buffer is 8 bytes. The below figure represents the configuration of the example: The frequency of each output sample is determined by the source frequency of the PDB and the DACINT value. Sample_Output_Frequency =  Source_Frequency/ [(PDB_MULT * PDB_PRESCALER) * (DACINT + 1)] In the attached example the Bus Clock = 66MHz., PDB_MULT = 1 ,  PDB_PRESCALER = 128, DACINT = 63 For the 256 elements to convert the frequency of the output signal is 31.47Hz. (Sine Wave) VF6xx

s32k344 罐 你好，我正在使用 s32k344 电机驱动器代码，并有几个原型。我发现其中一台 CAN 机器在运行一段时间后会脱机，发送和接收都会出现异常。我打开了离线回复，发现信息会丢失 200 毫秒的帧。我更换了 CAN 收发器，但同样的现象依然存在。我已经阅读了勘误手册，是否是芯片本身存在这个错误？ Re: s32k344 can Hi@qicbeng 示例代码"MCSPTE1AK344_PMSM_FOC_2Sh_ll" 不提供 FLEXCAN 功能；您必须自行添加 CAN 相关功能。 请提供您的 CAN 测试项目，以便我检查您的配置是否正确。

FRDM-MCXN947：Ee(42) 刷新 tflm_modelrunner 后无法连接到内核 刷新 tflm_modelrunner SDK 示例（FreeRTOS + lwIP，定义 USE_RTOS）后，我的 FRDM-MCXN947 不再响应 SWD。LinkServer v25.6 和 MCU-Link V3.128 报告 Ee(42)。所有操作（包括大量擦除）都无法连接到核心。在 “设备管理器” 中可以正确检测到 MCU-Link 探测器。按下 SW3+RESET 时，Windows 会检测到 USB 枚举，但未安装驱动程序，blhost 报告未找到任何设备。 我怎样才能找回板？ 更新：我能够在 Linux 上下载 led_blinky 示例，但在 Windows 10 上问题依然存在。 此外，在这两个操作系统上，我通常会收到以下警告： " 项目是为设备 MCXN947 配置的，但选定的探测器报告已连接到设备 MCXN947VDFT。你确定要继续吗？" 第一次尝试下载程序时（不知道是否与此有关）。 Re: FRDM-MCXN947: Ee(42) Could not connect to core after flashing tflm_modelrunner 最新情况--决议 通过从 Windows 设备管理器中卸载 MCU-Link 设备条目并允许 Windows 在重新连接时重新枚举这些条目，该问题得到了解决。 具体而言，删除了两个条目：通用串行总线设备下的 " MCU-LINK FRDM-MCXN947 CMSIS-DAP "，以及端口 (COM & LPT) 下相应的 MCU-Link vCom 端口。重新连接 USB 电缆后，Windows 自动重新安装了这两个驱动程序，LinkServer 可以正确打开探针。 根本原因似乎是Windows中USB设备状态损坏，很可能是在之前使用tflm_modelrunner固件（FreeRTOS + LwIP）的会话中触发的。该探针在系统中可见并被正确枚举，但其句柄无法被 redlinkserv.exe 打开，导致在所有操作（包括大量擦除、闪存和 gdbserver）中出现 Ee(42)。重新安装集成开发环境，替换 redlinkserv.exe、清除 USB 注册表项也无法解决这个问题。只有从设备管理器重新枚举设备才能解决问题。

当 PN7160 设置为 LPCD 模式时，不能使用 2×2 厘米天线从 LPCD 模式激活它。 使用 “NFC 天线工具”，我们为 PN7160 设计了一个 2 cm × 2 cm 的板载天线，Q 系数为 20，目标阻抗为 11 Ω。由于这是一个小型天线，我们根据 "PN7160 常见问题 [AN13892]"启用了 PN7160 的 DPC。 在这种情况下，如果我们不启用 PN7160 的 LPCD 模式，两台 PN7160 设备可以通过 P2P 进行正常通信。但是，如果我们启用 PN7160 的 LPCD 模式，PN7160 将无法从 LPCD 模式唤醒。不过，使用相同的驱动器，我们可以用 2 厘米 × 4 厘米的天线从 LPCD 模式激活它。 来自 2 厘米 × 2 厘米天线的 LPCD TRACE 信息如下： D (6358097) PN7160_I2C：NCI<< 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6358597) PN7160_I2C：NCI<< 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6359107) PN7160_I2C：NCI<< 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 D (6359617) PN7160_I2C：NCI<< 0x6f 0x13 0x04 0x80 0x83 0x80 0x03 有关天线设计参数，请参阅附件。 并将 CORE_SET_CONFIG_CMD 设置为 ： uint8_t NxpNci_CORE_CONF_EXTN[]={0x20, 0x02, 0x6B, 0x05, /* CORE_SET_CONFIG_CMD */ 0xA0, 0x40, 0x01, 0x81、 /* TAG_DETECTOR_CFG */ 0xA0, 0x41, 0x01, 0x10, /* TAG_DETECTOR_THRESHOLD_CFG */ 0xA0, 0x42, 0x01, 0x0F、 /* TAG_DETECTOR_PERIOD_CFG */ 0xA0, 0x43, 0x01, 0x00, /* TAG_DETECTOR_FALLBACK_CNT_CFG */ 0xA0, 0x0B, 0x57, 0xE5, 0x05, 0x90, 0x6E, 0x0F, 0x4E, /* DPC_CONFIG*/ 0x00, 0x40, 0x95, 0xB7, 0xAA, 0x40, 0x9F, 0xA7, 0x99、 0x53, 0x9F, 0x97, 0x99, 0x5D, 0x9F, 0x97, 0x99, 0x5F, 0x9F, 0x97, 0x00, 0x68, 0x9F, 0x07, 0x00, 0x6A, 0x1F, 0x07, 0x00, 0x74, 0x1F, 0x07, 0x00, 0x78, 0x1F, 0x07, 0x00, 0x7F, 0x1F, 0x07, 0x00, 0x81, 0x1F, 0x07, 0x00、 0x8B, 0x1F, 0x04, 0x00, 0x8C, 0x1F, 0x04, 0x00, 0x96, 0x1F, 0x04, 0x00, 0x98, 0x1F, 0x04, 0x00, 0xA1, 0x1F、 0x02、0x00、0xA9、0x1F、0x00、0x00、0xAF、0x1F、0x00、 0x00、0xB8、0x1F、0x00、0x00、0xC2、0x1F、0x00、0x00 }； 这个问题是由天线匹配还是寄存器设置引起的？ Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn 您好，感谢您对我们的产品感兴趣。 您的设置有一些局限性，我想谈谈。 尽管可以使用 2x2 厘米的天线，但建议尝试使用尺寸稍大的天线。 我还想澄清一点，NFC 论坛不推荐使用 P2P，我们强烈建议使用 HCE 和读/写模式。 启动器的天线尺寸很可能太小，不会导致目标失调。 您是否尝试过用普通的 PICC（如卡片）唤醒 LPCD 读取器？这样做的结果是什么？ 请分享史密斯手推车和原型图，以便进一步审查。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn 您能测量天线的阻抗吗？ 似乎相对较低。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn 非常感谢您的答复，但我现在没有 VNA。如果还是不能解决问题，我就去买一个。您还有其他建议吗？ Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn 非常感谢您的回复。 目前，我们使用 P2P 是为了兼容性而做出的妥协。我们重新优化了天线形状和 PCB 布局，但问题依然存在。附件中的第一张图片是天线原理图，其中包含使用 "NFC 天线工具 "生成的参数；第二张图片是 PN7160 及其外围电路的原理图；第三和第四张图片显示了 PCB 布局的顶视图和底视图；第五张图片显示了我们输入 NFC 天线工具的参数。 根据 AN13219（PN7160 天线设计和匹配指南）第 23 页，我们将非对称和对称调谐方案的 Q 值、目标阻抗、fEMC 截止频率和 L0 分别设置为 20、13 Ω、22 MHz 和 20、11 Ω、14.6 MHz。但是，在这两种情况下，LPCD TRACE 的通知信息仍然是： D (564760) PN7160_I2C：NCI<< 0x6f 0x13 0x04 0x80 0x83 0x80 0x03。 无论我们用手指还是金属物体靠近天线，测量结果都不会改变。 Re: When the PN7160 is set to LPCD mode, it cannot be activated from LPCD mode using a 2×2 cm antenn 我们还参考了 "PN7160 天线设计与匹配指南"，并使用该程序读取了 AGC 值： 无效 Get_AGC(SemaphoreHandle_t Semaphore_PN7160_IRQ) { uint8_t 获取[] ={0x2F, 0x3D, 0x04, 0x02, 0xC8, 0x60, 0x03}; uint8_t 答案[255]; uint16_t 答案大小; 虽然(1)     { printf("\n");   NxpNci_HostTransceive(Semaphore_PN7160_IRQ, 获取, sizeof(获取), 答案, 大小(答案), &答案大小); 如果((答案[0] != 0x4F) ||(答案[1] != 0x3D) ||(答案[3] != 0x00)) { printf("错误，无法获取参数值\n");      } 不然 { printf("\n"); printf("测量的 AGC 值 (LSB)= %.2Xh", 答案[4]); printf("\n"); printf("测量的 AGC 值 (MSB)= %.2Xh", 答案[5]); printf("\n");      }    } }   不过，我们得到的结果很奇怪，它并没有列在 UM11495 号文件的 TEST_ANTENNA_RSP 返回值列表中。我们读取的值是 0x06： (7600) PN7160_I2C：NCI>> 0x2f 0x3d 0x04 0x02 0xc8 0x60 0x03 D (7600) PN7160_I2C：NCI<< 0x4f 0x3d 0x01 0x06 但 UM11495 只提到四种可能的结果： 0x00: STATUS_OK 0x01: 拒绝执行测试（PN7160 处于错误状态） 0x04: STATUS_TEST_EXEC_FAILED 0x09: STATUS_INVALID_PARAM 其他：RFU

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 此致， 丹尼尔

Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi, I am working with S32K144 using S32 Design Studio 3.4. I tried debugging the dio_ToggledLED_S32K144 example project. The code flashes successfully, and I can see the LED toggling output initially. However, after some time, an error window appears, and after that, I am not able to continue debugging. Due to this issue, I am unable to debug the application properly. Could you please help with the following: What could be the possible reason for this debug error appearing after flashing? Is this related to debugger connection (J-Link / PEMicro), watchdog, or clock configuration? Are there any known issues with the dio_ToggledLED_S32K144 example in S32 Design Studio 3.4? What are the recommended steps to resolve this issue and debug the project correctly? Any guidance to resolve this issue would be very helpful. Thank you for your support. Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi Julián, Thank you for your response. Please find the details below: The issue appears after running the project for a few seconds to about one minute. Initially, the code runs correctly and the LED toggles, but after some time, a debug error window appears, and the debug session stops. When the issue occurs, I am not able to continue debugging. In some cases, I need to terminate the debug session and restart S32 Design Studio to flash the MCU again. I will recheck and confirm the PEmicro driver version. Currently, I am using the default PEmicro version installed with S32 Design Studio 3.4. To clarify, this issue is not only with the Dio example code. I created a separate user application (custom GPIO project) from scratch. In this user-created project, I enabled the following MCAL components: Mcu Port Dio Dem Ecuc In the Dio configuration, I selected RED LED (Dio channel 15). When I debug this user-created GPIO application, I face the same debug issue, similar to the one shown in the attached image. Based on this, the problem seems to be related to the debug configuration or PEmicro connection, rather than the Dio example logic itself. Please let me know if you need any additional details or logs from my side. Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi @KAVIN7, No, there should not be any problems with the Dio example, as the project only toggles a LED. Could you provide a bit more information about how to reproduce your issue? 1. How long are you running the project before the issue appears? 2. When the issue happens, are you able to reload the debug session and flash the MCU again? 3. Can you confirm you have the latest Pemicro version available? 4. Have you modified the project in any way? This issue seems to point to PEmicro drivers or debug configuration, as the Dio example does not configure anything related to watchdog or power modes. Best regards, Julián Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi @KAVIN7, Looking through your configuration, I can see you do not have any pins configured in the "UnTouchedPortPin" container. In order to be able to use the debug capabilities, the JTAG and Reset pins need to be configured in the Port driver using mechanism B. This means that the following pins/functionalities need to be added in the UnTouchedPortPin list: 4, 5, 10, 68 & 69. This may not be your root cause, since your issue appears after running the project for some time, but it does not hurt to try. Like I've said in my previous response, you can also try updating your SW. Latest versions are: S32DS: 3.6.5 S32K1 RTD: 3.0.0 Pemicro: 6.1.7  Lastly, please try sharing a log form the debug interface, as well as debug configuration, as it is very difficult to pinpoint an issue like this, as it cannot be reproduced on my side. Here is my debug configuration which seems to work correctly: Best regards, Julián Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi, Thank you for the information. However, I believe the issue discussed in this thread (Unable to Debug dio_ToggledLED_S32K144 Example — Debug Error…) is not the exact problem I’m facing. My issue is described in this other ticket instead, where I’m getting a PE Micro Connection Assistant error due to missing port configuration: https://community.nxp.com/t5/S32K/PE-Micro-Connection-Assistant-Error-Due-to-Missing/m-p/2303757#M56494 In my case: I created a custom GPIO application for LED toggle. I enabled only the RED LED pin in Dio/Port configuration. I did not enable the “UntouchedPortPin” debug pins (JTAG/RESET/XTAL/EXTAL). This results in the PE Micro connection failure, as shown in the attached image in that ticket. I believe the issue is related to missing port pin configuration required for debug interfaces (JTAG/RESET/XTAL/EXTAL), and not a problem with the dio example itself. I need this resolved because I cannot proceed with further implementation until the basic debug connection works. Could someone please review the linked ticket and advise on the correct pin configuration or steps to fix the debug connection issue? Thank you.

RDB3 Linux 以太网配置 本文档为在恩智浦 S32G-VNP-RDB3 开发板上配置和测试网络连接提供了实用指南。它概述了准备硬件和软件环境、设置网络参数以及验证主板与主机系统之间通信的基本步骤。该指南还解释了板网络架构的关键方面，并提供了在 Linux 和 U-Boot 级别调整配置的说明。其目的是为从事汽车网络应用以太网支持和验证的工程师提供参考。 本文档是对之前的 S32G-VNP-RDB2 参考设计以太网支持指南的更新，其中纳入了特定于 RDB3 平台和更新 电路板支持包 版本的更改和注意事项。 S32G