NXP S32 配置工具如何添加更多端口引脚 大家好。 我的项目刚开始使用 FRDM Automotive S32K344 开发板和 Simulink (MBDT)。 但是，当我尝试创建额外的端口引脚时遇到了困难，因为我没有创建更多端口引脚/端口容器的选项。 请问有人能告诉我我的设置哪里出了问题吗？或者我需要先做一些事情吗？ Rizqu_0-1789455084038.png Re: NXP S32 Config Tools How to add more port pin 你好@Rizqu ， 端口/引脚容器不是手动管理的，这意味着如果您想添加一个额外的引脚，则必须在“引脚”视图中进行配置，该引脚将自动链接到端口/引脚容器。 端口配置与功能组名称相关联，请参阅以下社区帖子了解更多信息： 功能组问题 港口集装箱和功能组问题 已解决：外设配置 - NXP 社区 了解 S32 平台 IDE 中 S32 设计工作室的功能组的资源 如果您在使用 MBDT 时遇到其他问题，请将您的问题提交到基于模型的设计工具箱 (MBDT) - NXP 社区，以帮助我解决问题。 此致， 朱利安

NXP S32 Config Tools How to add more port pin Hello everyone. I just started using FRDM Automotive S32K344 Development Board and simulink (MBDT) for my project. But I have difficulties when try to make additional port pin because I don't have the option to make more portpin / portcontainer. Can anyone tell me what's wrong with my setting or maybe there are some things that I need to do first? Rizqu_0-1789455084038.png Re: NXP S32 Config Tools How to add more port pin Hello @Rizqu, The Port/Pin container is not managed manually, meaning that if you want to add an additional pin, you must configure it in the 'Pins' view, which will be automatically linked to the Port/Pin container. The Port configuration is linked with the functional group names, please refer to these community thread for more information:  functional group issue Port Container and Functional Group issue Solved: Peripherals configuration - NXP Community Resources to understand functional groups in S32 Design Studio for S32 platform IDE If you have further issues with MBDT specifically, please help me by submitting your question to the Model-Based Design Toolbox (MBDT) - NXP Community. Best regards, Julián

Accessing Micro Safety Manual Hi, On date 12/06/2026 i should have been enable to view secure resources for S32K3. I'm looking for the Safety Manual of S32K358 and i still can't find it at all. I tried in secure documentation here: https://www.nxp.com/products/S32K3#myDocument and in My NXP Account -> Secure Resources but i couldn't find it. Could someone help me? Thanks, Simon Re: Accessing Micro Safety Manual Hi @simon98  We have reviewed your account and our internal records and were unable to locate any previous request for the S32K3 Safety Manual. Could you please help us by requesting higher access permissions to obtain this document? BR, VaneB Re: Accessing Micro Safety Manual Hi @simon98  Please take a look at the NXP SECURE ACCESS RIGHTS FIRST-TIME USER REGISTRATION GUIDE, as you may find it useful.  Re: Accessing Micro Safety Manual hi @VaneB , Could you please tell me how could i request the access of S32K358 safety manual?  I thought having access to secure resourses (which was campleted in 12/06) i'd been able to acces it... BR, Simon Re: Accessing Micro Safety Manual Hi @VaneB  I've already got access to secure resources but i couldn't find the safety manual in secure resources section. I tried to apply a higher rights request specifying my needs. Is it correct? Thanks, Simon

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part Hello Freescale team, ​Please help to advise the meaning marking* " ( ) B "* of NXP : AFT09MS015NT1 what is it? Thanks, ​ Thanks & Best regards. Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part ( ) means circular recess on the top of the package. Please look at the AFT09MS015NT1 Datasheet, page 14. N & B is internal trace code. Have a great day, TIC   ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! -----------------------------------------------------------------------------------------------------------------------

访问微型功能安全手册 您好， 截至 2026 年 12 月 6 日，我应该能够查看 S32K3 的安全资源。 我正在寻找S32K358的功能安全手册，但我仍然找不到。 我尝试在以下安全文档中查找： https://www.nxp.com/products/S32K3#myDocument以及“我的 NXP 帐户”->“安全资源”，但都找不到。 请问有人能帮帮我吗？ 谢谢， 西蒙 Re: Accessing Micro Safety Manual 嗨@simon98 我们已查阅您的账户和我们的内部记录，但未能找到任何之前对 S32K3 功能安全手册的请求。请您帮忙申请更高的访问权限，以便我们获取这份文件？ BR，VaneB Re: Accessing Micro Safety Manual 嗨@simon98 请查阅《NXP 安全访问权限首次用户注册指南》 ，您可能会觉得它很有用。 Re: Accessing Micro Safety Manual 嗨@VaneB ， 请问如何申请获取S32K358功能安全手册？ 我以为有了安全资源访问权限（这项权限已于 12 月 6 日完成），我就能访问它了…… BR， 西蒙 Re: Accessing Micro Safety Manual 嗨@VaneB 我已经获得了访问安全资源的权限，但我在安全资源部分找不到功能安全手册。 我尝试申请更高的权限，并详细说明了我的需求。这样说对吗？ 谢谢！ 西蒙

FS32K144WAT0WLFT 将 PTD3 设置为 ADC，导致硬故障 你好呀亲爱的 我将 FS32K144WAT0WLFT PTD3 设置为 ADC，这将导致 MCU 发生硬故障。 我之前也遇到过146型电脑出现这个问题——你能帮我检查一下吗？ _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=5985335687075369917&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=3466386037717124085&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=4296127546010911231&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=1072804753289865017&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 我从未遇到过因选择 PTD3 作为 ALT0 (ADC1_SE3) 而导致 MCU 出现硬故障的情况。关于硬故障，我建议阅读： S32K14x 上的故障处理。或者告诉我调试过程中函数中的哪一行触发了硬故障。 我已查看您提供的原理图： 调试和编程接口： 请阅读AN5426 S32K1xx 微控制器硬件设计指南（2021 年 12 月第 6 版）.pdf中的“4 调试和编程接口”部分： 对于PTC4 (SWD_CLK)，建议使用外部下拉电阻而不是上拉电阻。 时钟电路： 我无法对晶体振荡器电路发表评论，电阻和负载电容值取决于晶体的规格和电路的板的电容。建议客户与零件制造商一起，对PCB上的晶体进行评估和表征。 但是，您截图中显示的R44 （限流串联电阻）的电阻值（ 470Ω ）似乎偏高。 请参阅“3.2”部分AN5426 S32K1xx 微控制器硬件设计指南（2021 年 12 月修订版 6）中的振荡器电路 PCB 布局建议.pdf 。 在 S32K1xx 数据手册中，您可以找到最小值。EXTAL 所需的 Vpp（表 27。外部系统振荡器的电气规格），所以我建议测量一下。另外，您需要确保 gmXOSC > 5 * gm_crit。 关于振荡器的反馈电阻，如果SOSC工作在“低增益”模式（SCG_SOSCCFG[HGO]=0），则可以省略。客户可以根据自身需求选择更低功耗（HGO=0）或更高抗噪性（HGO=1）。当 SOSC 以 HGO=1 高增益模式使用时，需要安装反馈电阻。 ADC： ADC 输入电压范围 (VADIN) 应介于 VREFL 和 VREFH 之间。 Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 嗨，罗宾 PTD3 选择 ALT0 (ADC1_SE3)，您是否遇到过这种情况，导致 MCU 进入硬故障状态？ 谢谢您！ Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault 你好 抱歉，我不明白你为什么要附上原理图。 请您澄清一下，您在 PTD3 的 PORT_PCR[MUX] 设置中选择的是 ALT0 (ADC1_SE3) 还是 ALT7 (NMI_b)？ PTD3 MUX ALT0 ALT7.png 此致敬礼， Robin

FS32K144WAT0WLFTがPTD3をADCに設定し、ハードフォルトにつながる こんにちわ、あなた PTD3 FS32K144WAT0WLFT ADCに設定しました。MCUはハードフォールトに導きます。 146で以前この問題に遭遇したことがありますが、試していただけますか? _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=5985335687075369917&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=3466386037717124085&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=4296127546010911231&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg _cgi-bin_mmwebwx-bin_webwxgetmsgimg__&MsgID=1072804753289865017&skey=@crypt_95413994_e700c76ddea301ac9db53cf62f314d73&mmweb_appid=wx_webfilehelper.jpg Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault PTD3をALT0(ADC1_SE3)として選択したことでMCUでハードフォルトが起きたことはありません。ハードフォルトに関しては、 「S32K14x でのフォルト処理」を読むことをお勧めします。もしくは、デバッグ中にハードフォルトが発生する関数の行を教えてください。 添付いただいた回路図を確認しました。 デバッグおよびプログラミングインターフェース: AN5426 S32K1xxマイクロコントローラ向けハードウェア設計ガイドライン(2021年12月6日改訂)の「4 デバッグおよびプログラミングインターフェース」セクションをお読みください.pdf: PTC4 （SWD_CLK）の場合、プルアップ抵抗ではなく、外部プルダウン抵抗の使用を推奨します。 クロック回路: XTAL回路についてはコメントできません。Rsや負荷コンデンサの値は、結晶の仕様や基板の静電容量に依存します。顧客は部品メーカーと共にPCB上の結晶の評価と特性評価を行うことが推奨されます。 しかし、スクリーンショットに示されているR44 （電流制限用の直列抵抗）の抵抗値（ 470Ω ）は、やや高い値であるように思われます。 「3.2」の項を参照してください。発振回路のPCBレイアウトに関する提案」は、 S32K1xxマイクロコントローラ向けAN5426ハードウェア設計ガイドライン(2021年12月6日改訂).pdf。 S32K1xxのデータシートには、最小量が記載されています。EXTAL で必要な Vpp (表 27)。外部システム発振器の電気仕様なので、測定することをおすすめします。また、gmXOSC > 5 * gm_crit であることを確認する必要があります。 発振器用のフィードバック抵抗については、SOSCを「低利得」モード(SCG_SOSCCFG[HGO]=0)で使用すれば廃止可能です。顧客の選択は、消費電力を抑える(HGO=0)か、高いノイズ耐性(HGO=1)かです。SOSCをHGO=1の高利得モードで使用する場合は、フィードバック抵抗を接続する必要があります。 ADC: ADCの入力電圧範囲（VADIN）は、VREFLとVREFHの間である必要があります。 Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault こんにちは、ロビンさん PTD3がALT0を選択しました(ADC1_SE3)、このような状況に遭遇したことがありますか?MCUがハードフォールに入る原因になります。 よろしくお願いします！ Re: FS32K144WAT0WLFT set PTD3 to ADC, lead to hard fault こんにちは 申し訳ありませんが、なぜ回路図を添付されたのか理解できませんでした。 PTD3のPORT_PCR[MUX]設定でALT0(ADC1_SE3)かALT7(NMI_b)を選んだのか、もう少し詳しく教えていただけますか? PTD3 MUX ALT0 ALT7.png よろしくお願いいたします ロビン

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> 请告知零件标记的含义 您好，Freescale团队， 请帮忙解释NXP的标记*“（）B”*的含义： AFT09MS015NT1 是什么 对吧？ 谢谢！ ​ 谢谢 & 此致敬礼。 Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> （ ）表示包装顶部的圆形凹槽。请参阅 AFT09MS015NT1 数据手册第 14 页。 N&B 是内部跟踪代码。 祝你有美好的一天， 信息通信技术   ----------------------------------------------------------------------------------------------------------------------- 注：如果此回复解答了您的问题，请点击“正确答案”按钮。谢谢你！ -----------------------------------------------------------------------------------------------------------------------

045-1299-001ZNT // NXP : AFT09MS015NT1 >>> 部品のマーキングの意味を教えてください フリースケールチームの皆様、こんにちは。 NXPの「( ) B」という表記の意味についてご教示ください。 AFT09MS015NT1とは 向上するのですよね？ ありがとうございます ​ ありがとうございます。よろしくお願いいたします。 Re: 045-1299-001ZNT // NXP : AFT09MS015NT1 >>> Please advise meaning marking of part <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ()はパッケージ上部の円形のくぼみを意味します。AFT09MS015NT1のデータシートの14ページをご覧ください。 NとBは内部トレースコードです。 良い一日をお過ごしください。 TIC   ----------------------------------------------------------------------------------------------------------------------- 注：この記事があなたの質問への回答になっている場合は、「正解」ボタンをクリックしてください。ありがとう！ -----------------------------------------------------------------------------------------------------------------------

KW47：WDOG 等待/停止模式与电源模式（睡眠/深度睡眠）之间的关系 你好， 我正在阅读 KW47 参考手册，但我对 WDOG 低功耗模式和系统电源模式之间的关系感到困惑。 在 WDOG 章节中，控制和状态寄存器包含以下位： - 等待： “使 WDOG 在芯片处于等待模式时也能运行。” - 停止： “使 WDOG 在芯片处于停止模式时也能运行。” WDOG章节还指出： - 在停止模式下，选定的 WDOG 时钟源必须保持活动状态。 - 对于调试模式和停止模式，必须使用总线时钟以外的时钟源。 另一方面，“电源模式”章节描述了： 睡眠模式： CPU执行已停止。 - 核心时钟已关闭 系统时钟和总线时钟可能会继续运行 深度睡眠模式： - 核心时钟已关闭 系统时钟已关闭 总线时钟已关闭 基于以上描述，可以合理地解释如下： - 等待模式 ≈ 睡眠模式 - 停止模式 ≈ 深度睡眠模式 然而，我尚未在参考手册中找到任何明确说明来证实这种映射关系。 我的问题是： 1. WDOG 等待模式是否对应于 KW47 的电源模式睡眠模式？ 2. WDOG 停止模式是否对应于 KW47 的电源模式深度睡眠模式？ 3. 或者说，Wait/Stop WDOG 是 CPU 特有的状态，与 SoC 电源模式不同？ 4. 是否有参考手册章节或应用笔记明确描述了这种关系？ 感谢您的帮助。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 你好，希望你一切都好。   KW47 参考手册中使用的术语与将 WDOG 控制寄存器中的 WAIT 和 STOP 字段解释为对芯片/内核低功耗状态的引用，而不是对 WDOG 特定 CPU 状态的引用是一致的。我会将这种关系描述为功能对应，而不是严格的等价关系。 从这个意义上讲，WDOG WAIT 对应于等待/睡眠类条件，其中 CPU 执行停止，但系统和总线时钟可能仍然可用。WDOG STOP 对应于停止/深度睡眠类条件，其中内核、系统和总线时钟被门控，看门狗只有在配置为使用在该模式下保持活动的时钟源时才能继续工作。   此致， 索菲亚。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 你好，索菲亚， 感谢您之前的解释。 根据您的回复，我的理解是： - WDOG WAIT 对应于等待/睡眠类低功耗状态。 - WDOG STOP 对应于停止/深度睡眠级别的低功耗状态。 - 这种关系是一种功能对应关系，而不是严格的一对一映射关系。 再次查阅KW47参考手册后，我发现了以下章节： 28.4 模块在低电源模式下的运行 表 225：Cortex M33 核心模块在低电源模式下的运行情况 对于 WDOGx，表格显示： - 睡眠：开启 - 深度睡眠：可选 - 关机：可选 深度关机：关闭 从这张表中，我了解到 WDOG 操作至少可以在深度睡眠和关机模式下配置。 为了更好地了解其行为，我使用 KW47-Loc 评估板进行了测试。 测试条件： - 已启用 WDOG - WDOG 刷新由 vApplicationIdleHook() 执行 - PWR_EnterLowPower() 由 FreeRTOS vPortSuppressTicksAndSleep() 执行 - 观察进入低功耗状态后是否发生看门狗复位 测试结果： 案例 1 等待=0，停止=0 → 未发生看门狗RESET 案例 2 等待=1，停止=0 → 看门狗复位发生 案例3 等待=0，停止=1 → 未发生看门狗复位 我的理解是，当看门狗复位时，设备进入低功耗状态，vApplicationIdleHook() 不再执行，而看门狗继续运行，最终超时。 但是，只有当 WAIT=1 且 STOP=0 时才会发生看门狗 RESET，而当 STOP=1 时则不会发生看门狗 RESET。 由于这个结果，我很难理解在低功耗电源模式下，WAIT 和 STOP 位是如何实际应用于看门狗操作的。 请您澄清以下几点？ 1.当设备通过 PWR_EnterLowPower() 进入低功耗模式时，WDOG 操作是由 WAIT 位控制还是由 STOP 位控制？ 2. 观察到的结果表明设备实际上进入了睡眠模式而不是深度睡眠模式，还是应该解释为进入了深度睡眠模式？ 3. STOP 位是否对应于电源模式章节中描述的深度睡眠模式，还是指不同的低功耗状态？ 4. 表 225 中的下列条目应该如何解释与 WDOG WAIT 和 STOP 控制位相关的内容？ - WDOGx：可选的（深度睡眠） - WDOGx：可选的（掉电） 感谢您的支持。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @sofiaurueta 我进行了一些额外的测试，并将我的发现更新到了上面的帖子中。 请问我的理解是否正确？ 谢谢！ Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @hyama你好，很抱歉回复晚了。   您是否使用 SDK 中的示例进行测试？您如何确认设备已进入深度睡眠模式？ 根据你描述的情况，设备可能只是进入了睡眠模式。如果设备进入深度睡眠状态，结果则相反：STOP=1（情况 3）应该会导致超时，而 WAIT=1（情况 2）应该不会产生任何影响。WAIT=1 触发 RESET 这一事实表明设备进入了睡眠模式，而不是深度睡眠模式。   回答您的问题： 1.当设备通过 PWR_EnterLowPower() 进入低功耗模式时，WDOG 操作是由 WAIT 位控制还是由 STOP 位控制？ CS[WAIT] 和 CS[STOP] 是独立模式的独立控制，其中 CS[WAIT] 控制睡眠模式下的 WDOG 操作，CS[STOP] 控制深度睡眠模式下的 WDOG 操作。 如果设备进入睡眠模式，则 CS[WAIT] 为活动控制。CS[STOP] 在这里不起作用，因为没有进入深度睡眠状态。如果设备配置为进入深度睡眠状态，则 CS[STOP] 将是活动控制。   2. 观察到的结果表明设备实际上进入了睡眠模式而不是深度睡眠模式，还是应该解释为进入了深度睡眠模式？ 结果与进入睡眠模式相符，与深度睡眠不符。根据三个测试用例，系统进入睡眠模式。   3. STOP 位是否对应于电源模式章节中描述的深度睡眠模式，还是指不同的低功耗状态？ 根据文档，CS[STOP] 对应于深度睡眠，测试中观察到的行为与此一致（假设没有进入深度睡眠）。   4. 表 225 中的下列条目应该如何解释与 WDOG WAIT 和 STOP 控制位相关的内容？ 对于深度睡眠，“可选”意味着如果 CS[STOP]=1 并且配置了总线时钟以外的时钟源，则 WDOG 可以在深度睡眠中运行。对于调试模式和停止模式，必须使用总线时钟以外的时钟源。使用总线时钟，看门狗在架构上可以“启用”，但它的时钟就消失了，除非选择不同的时钟源，例如 32K_CLK。 此致， 索菲亚。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) 嗨@sofiaurueta 感谢您之前的解释。 > 您是否使用 SDK 中的任何示例进行测试？您如何确认设备已进入深度睡眠模式？ 关于您的问题，该测试并非在 SDK 示例项目上进行。这是在我们基于 NXP SDK 的应用程序上执行的。 为了验证设备是否进入深度睡眠模式，我进行了一些额外的调查，发现进入低功耗模式时会执行以下路径： vPortSuppressTicksAndSleep() -> PWR_EnterLowPower() -> PM_EnterLowPower() -> PM_EnterLowPowerMode() -> CMC_EnterLowPowerMode() 在 CMC_EnterLowPowerMode() 中，SDK 在执行 WFI 之前设置 SCB->SCR 寄存器中的 SLEEPDEEP 位。 我们理解，设置 SLEEPDEEP 位并执行 WFI 意味着设备进入深度睡眠模式。请问您对KW47的理解是否正确？ 我这样问是因为我的 WDOG 测试结果似乎取决于 WAIT 位而不是 STOP 位。 感谢您的帮助。

NXP S32 設定ツール ポートピンを追加する方法 こんにちは、みんな。 私は最近、プロジェクトでFRDM オートモーティブ S32K344 開発ボードとsimulink(MBDT)を使い始めました。 しかし、ポートピンを追加しようとすると、ポートピン/ポートコンテナを増やすオプションがないため、問題が発生します。 設定のどこが問題なのか、あるいはまずやるべきことがあるのか教えてもらえますか? Rizqu_0-1789455084038.png Re: NXP S32 Config Tools How to add more port pin こんにちは、 @Rizqu さん。 ポート/ピンコンテナは手動で管理されません。つまり、ピンを追加する場合は、「ピン」ビューで設定する必要があり、その設定内容はポート/ピンコンテナに自動的にリンクされます。 ポート構成は機能グループ名とリンクされています。詳細は以下のコミュニティスレッドを参照してください。 官能基の問題 ポートコンテナと機能グループの問題 解決済み:ペリフェラルの設定 - NXPコミュニティ S32プラットフォームIDE用のS32 Design Studioにおける機能グループを理解するためのリソース もしMBDTに関してさらに問題がある場合は、モデルベース設計ツールボックス(MBDT)- NXPコミュニティにご質問を提出してください。 よろしくお願いします、 ジュリアン

KW47：WDOG待機/停止モードと電源モード（スリープ/ディープスリープ）の関係 こんにちは、 KW47リファレンスマニュアルを読んでいるのですが、WDOGの低消費電力モードとシステムの電源モードの関係について混乱しています。 WDOGの章では、制御およびステータスレジスタには次のビットが含まれています。 - 待って： 「チップが待機モードのときにWDOGが動作できるようにします。」 - 停止： 「チップが停止モードのときにWDOGが動作できるようにします。」 WDOGの章には、次のようにも記載されています。 - 選択したWDOGクロックソースは、停止モードでもアクティブな状態を維持する必要があります。 デバッグモードおよび停止モードでは、バスクロック以外のクロックソースを使用する必要があります。 一方、「電源モード」の章では、以下のことが説明されています。 スリープモード: - CPUの実行が停止しました - コアクロックゲートオフ システムクロックとバスクロックは引き続き動作する可能性があります。 ディープスリープモード： - コアクロックゲートオフ - システムクロックゲートがオフになっています バスの時計が閉まっている これらの記述に基づくと、以下のように解釈するのが妥当と思われる。 - 待機モード ≈ スリープモード - 停止モード ≈ ディープスリープモード しかし、リファレンス・マニュアルにはこのマッピングを裏付ける明確な記述は見つかっていません。 私の質問は以下のとおりです。 1. WDOG待機モードはKW47のパワーモードスリープモードに対応しますか? 2. WDOG停止モードはKW47のパワーモードのディープスリープモードに対応しますか? 3. それとも、待機/停止はWDOG特有のCPU状態で、SoCの電源モードとは異なるのでしょうか? 4. この関係を明示的に説明したリファレンス・マニュアルのセクションやアプリケーションノートはありますか? ご協力ありがとうございます。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) こんにちは、お元気でお過ごしでしょうか。   KW47リファレンスマニュアルで使用されている用語は、WDOG制御レジスタのWAITおよびSTOPフィールドを、WDOG固有のCPU状態ではなくチップ/コアの低消費電力状態を参照として解釈するものと一致しています。両者の関係は、厳密な等価関係というよりは、機能的な対応関係と表現するのが適切でしょう。 その意味で、WDOG WAITは待機/スリープクラスの状態に相当し、CPUの実行は停止するものの、システムクロックとバスクロックは引き続き使用可能となる。WDOG STOPはStop/Deep-Sleepクラス条件に対応し、コア、システム、バスのクロックがゲートされており、ウォッチドッグはそのモードでアクティブなクロックソースを使用するように設定されて初めて継続できます。   よろしくお願いします、 ソフィア。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) こんにちは、ソフィアさん。 先ほどのご説明、ありがとうございました。 あなたの回答に基づくと、私の理解は以下のとおりです。 - WDOG WAITは、待機/スリープクラスの低電力状態に対応します。 - WDOG STOPは、停止/ディープスリープクラスの低電力状態に相当します。 この関係は、厳密な一対一の対応関係ではなく、機能的な対応関係である。 KW47リファレンスマニュアルを改めて確認したところ、次のセクションを見つけました。 28.4 低消費電力モードでのモジュール動作 表225:低消費電力モードでのCortex M33コアモジュールの動作 WDOGxの場合、表には以下が示されています。 - スリープ：オン - ディープスリープ：オプション - 電源オフ：オプション - ディープパワーダウン：オフ この表から、WDOGの動作は少なくともディープスリープと電源オフモードで設定可能だと解釈しました。 挙動をよりよく理解するために、KW47-Loc評価ボードを使ってテストを行いました。 試験条件： - WDOGが有効 - WDOG の更新は vApplicationIdleHook() から実行されます - PWR_EnterLowPower() は FreeRTOS の vPortSuppressTicksAndSleep() から実行されます。 低電力状態に入った後にウォッチドッグリセットが発生するかどうかを観察する テスト結果： CASE 1 待機=0、停止=0 → ウォッチドッグのリセットは発生しませんでした CASE 2 WAIT=1、STOP=0 → ウォッチドッグリセットが行われました ケース3 WAIT=0、STOP=1 → ウォッチドッグのリセットは発生しませんでした 私の解釈では、ウォッチドッグリセットが発生した際、デバイスは低電力状態に入り、vApplicationIdleHook()は実行されなくなったものの、ウォッチドッグは実行を継続し、最終的にタイムアウトしたと考えられます。 しかし、ウォッチドッグリセットはWAIT=1かつSTOP=0の場合にのみ発生し、STOP=1の場合はウォッチドッグリセットは発生しなかった。 この結果から、低電力モード時のウォッチドッグ動作において、WAITビットとSTOPビットが実際にどのように適用されるのか理解に苦しんでいます。 以下の点について説明していただけますか? 1.デバイスが PWR_EnterLowPower() によって低電力モードに入った場合、WDOG の動作は WAIT ビットと STOP ビットのどちらによって制御されますか？ 2. 観測された結果は、デバイスがディープスリープモードではなくスリープモードに入っていることを示しているのでしょうか、それともディープスリープモードに入っていると解釈すべきでしょうか？ 3. STOPビットは、電源モードの章で説明されているディープスリープモードに対応していますか、それとも別の低電力状態を指していますか？ 4. 表225の以下の項目は、WDOG WAITおよびSTOP制御ビットに関してどのように解釈すべきですか？ - WDOGx：オプション（ディープスリープ） - WDOGx：オプション（電源オフ） 再開まで今しばらくお待ちください。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) @sofiaurueta 追加のテストを実施し、その結果を上記の記事に追記しました。 私の解釈が正しいか教えていただけませんか? よろしくお願いします。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) こんにちは、 @hyama さん。返信が遅くなり申し訳ありません。   SDKの例を使ってテストしていますか?デバイスがディープスリープモードに入っていることをどのように確認していますか？ ご説明いただいた動作から判断すると、デバイスは単にスリープモードに入っているだけかもしれません。もしデバイスがディープスリープに入っていたら、結果は逆になります。STOP=1(CASE 3)がタイムアウトを引き起こし、WAIT=1(CASE 2)は影響がないはずです。WAIT=1がリセットをトリガーするという事実は、デバイスがディープスリープではなくスリープモードに入ったことと一致している。   皆様からのご質問にお答えします。 1.デバイスが PWR_EnterLowPower() によって低電力モードに入った場合、WDOG の動作は WAIT ビットと STOP ビットのどちらによって制御されますか？ CS[WAIT]とCS[STOP]は、それぞれ独立したモードを制御する独立した制御装置であり、CS[WAIT]はスリープモードでのWDOGの動作を制御し、CS[STOP]はディープスリープモードでのWDOGの動作を制御します。 デバイスがスリープモードに入る場合、CS[WAIT]がアクティブコントロールとなります。CS[STOP]はここでは効果がありません。なぜなら、ディープスリープには入らないからです。デバイスが代わりにディープスリープに入るように設定されている場合、CS[STOP]がアクティブな制御になります。   2. 観測された結果は、デバイスがディープスリープモードではなくスリープモードに入っていることを示しているのでしょうか、それともディープスリープモードに入っていると解釈すべきでしょうか？ この結果はスリープモードへの移行とは一致するが、ディープスリープとは一致しない。3つのテストケースに基づき、スリープモードに入っています。   3. STOPビットは、電源モードの章で説明されているディープスリープモードに対応していますか、それとも別の低電力状態を指していますか？ ドキュメントによると、CS[STOP]はディープスリープに対応し、テストで観察された挙動はこれと一致しています(ディープスリープが入力されていないと仮定した場合)。   4. 表225の以下の項目は、WDOG WAITおよびSTOP制御ビットに関してどのように解釈すべきですか？ ディープスリープの「オプション」とは、CS[STOP]=1かつバスクロック以外のクロックソースが設定されている場合にWDOGがディープスリープで動作できることを意味します。デバッグモードおよび停止モードでは、バスクロック以外のクロックソースを使用する必要があります。バスクロックを用いることで、ウォッチドッグはアーキテクチャ的に「有効化」できますが、そのクロックは失われており、例えば32K_CLKなど別のクロックソースが選択されない限りは消えています。 よろしくお願いします、 ソフィア。 Re: KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep) こんにちは、 @sofiaurueta さん 先ほどのご説明、ありがとうございました。 >SDKの例を使ってテストしていますか?デバイスがディープスリープモードに入っていることをどのように確認していますか？ ご質問についてですが、テストはSDKのサンプルプロジェクトで実施されたものではありません。これはNXP SDKをベースにした私たちのアプリケーションで実施されました。 デバイスがディープスリープモードに入るかどうかを確認するため、追加調査を行ったところ、低電力モードに入る際に以下のパスが実行されることが分かりました。 vPortSuppressTicksAndSleep() -> PWR_EnterLowPower() -> PM_EnterLowPower() -> PM_低電力モードに入る() -> CMC_EnterLowPowerMode() CMC_EnterLowPowerMode()では、SDKはWFIを実行する前にSCB->SCRレジスタのSLEEPDEEPビットを設定します。 SLEEPDEEPビットを設定してWFIを実行すると、デバイスがディープスリープモードに入るというのが私たちの理解です。この理解がKW47に対して正しいか確認していただけますか? 私が質問しているのは、WDOGテストの結果がSTOPビットではなくWAITビットに依存しているように見えるからです。 助けてくれてありがとう。

s32设计工作室许可证已过期 您好。 我的S32设计工作室许可证即将到期。 能否续签许可证？ 许可证代码为 085B-C474-AA78-FC99。 谢谢！ Re: s32 design studio license expired 你好， 您的S32DS许可证已延期。 Re: s32 design studio license expired 你好， 我刚刚查看了您的账户，许可证有效期至 2030 年。您可以等到许可证真正过期后再操作，或者退回现有许可证并使用旧代码重新激活。 Re: s32 design studio license expired 您好。 ssong_0-1789444671642.png 看起来还没有扩展。您能再检查一遍吗？谢谢。

s32 design studio license expired Hello. My S32 Design studio license will be expired soon.  Could you renew the license? License code is 085B-C474-AA78-FC99. Thank you! Re: s32 design studio license expired Hi,  your S32DS license has been extended.  Re: s32 design studio license expired Hi,  I checked your account right now and the license is valid till 2030. You can wait till license is not really expired or return existing one and activate it again with your old code.  Re: s32 design studio license expired Hello. ssong_0-1789444671642.png It looks not extended yet. Could you check this again? thanks.

S32 デザインスタジオのライセンスが切れました こんにちは、 私のS32デザインスタジオライセンスはもうすぐ期限切れになります。 免許の更新は可能ですか? ライセンスコードは085B-C474-AA78-FC99です。 ご回答をお待ちしています。 Re: s32 design studio license expired こんにちは、 お客様のS32DSライセンスが延長されました。 Re: s32 design studio license expired こんにちは、 今あなたのアカウントを確認したところ、ライセンスは2030年まで有効です。ライセンスが本当に期限切れでないまで待つか、既存のライセンスを返却して古いコードで再度有効化することもできます。 Re: s32 design studio license expired こんにちは、 ssong_0-1789444671642.png まだ延長されていないようです。もう一度確認してもらえますか?ありがとう。

S32 设计工作室平台 + SW32G2 + RTD 版本选择 我参考了《S32G-VNP-RDB2 软件启用指南》，建议的软件版本为 SW32G2_S32DS_3.4.0_D2012.zip + S32DS.3.4_b201217_win32.x86_64.exe + 实时驱动程序 S32_RTD_4.4_1.0.0_HF01_D2102_DS_Updatesite.zip。 但我实际下载的是 S32DS.3.4_b201217_win32.x86_64.exe +SW32G2_S32DS_3.4.1_D2104.zip +SW32G_RTD_4.4_3.0.2_HF01_DS_updatesite_D2204.zip。 当我尝试添加新的 RGB LED 灯并打开外设工具时，它会显示“外设：[SDK] 更新代码失败 - 代码生成失败”。我不确定不同的软件版本组合是否会导致这些错误。 Re: S32 Design Studio Platform + SW32G2 + RTD version selection 你好， guang1994 我会内部回复你。 BR 乔伊

S32K358 about Cache operation 我在S32DS 中编写S32K358 的程序，建立OTA 升级程序需要操作内部FLASH，当调用上述函数时，我能够编译通过，但是CTRL+鼠标左键却无法找到上述函数，这是正常现象吗？  屏幕截图 2026-09-15 141928.png 屏幕截图 2026-09-15 141953.png Re: S32K358 about Cache operation 嗨@sunshine88 ， 您能尝试重建索引吗？ danielmartynek_0-1789469464382.png 谢谢！ BR，丹尼尔

imx95 AHAB SGKサポート こんにちは、 私はi.MX95でAHABのセキュアブートサポートに取り組んでおり、サポートされている署名キーの階層を確認したいと思っています。 i.MX9の一部のバリアント、例えばi.MX93は現在、AHABコンテナ署名のためのサブリグネーミングキー(SGK)をサポートしておらず、SRKベースの署名のみがサポートされていると理解しています。ここで説明しています: https://community.nxp.com/t5/i-MX-Processors/imx93-AHAB-SGK-support/td-p/2181212 i.MX95が、SRK証明書にCAフラグを付けた下位キー(SGK)を使ってAHABブートコンテナに署名できるのか、それとも現在リリースされたELEファームウェアが直接SRKベースの署名のみをサポートしているのか、確認していただけますか? SGKがサポートされている場合、サポートはi.MX95シリコンリビジョン、ELEファームウェアバージョン、AHABコンテナフォーマット、またはBSPリリースによって異なるのかも教えていただけますか? Re: imx95 AHAB SGK support どなたか助けていただけますか? Re: imx95 AHAB SGK support こんにちは、 返信が遅れて申し訳ございません。もしまだお役に立つようでしたら、チームに確認したところ、AおよびBのどちらのシリコンリビジョンでもサポートされていないことが分かりました。 よろしくお願いいたします。 アルド。 Re: imx95 AHAB SGK support ご説明ありがとうございます、@AldoG さん。

imx95 AHAB SGK support Hello, I am working on AHAB secure boot support on i.MX95 and would like to confirm the supported signing-key hierarchy. I understand that some i.MX9 variants, such as i.MX93, currently do not support subordinate signing keys (SGK) for AHAB container signing, and only SRK-based signing is supported, as discussed here: https://community.nxp.com/t5/i-MX-Processors/imx93-AHAB-SGK-support/td-p/2181212 Could you please confirm whether i.MX95 supports signing AHAB boot containers using subordinate keys (SGK), with the SRK certificate carrying the CA flag, or whether the current released ELE firmware supports only direct SRK-based signing? If SGK is supported, could you also clarify whether support depends on the i.MX95 silicon revision, ELE firmware version, AHAB container format, or BSP release? Re: imx95 AHAB SGK support Can anyone help me here? Re: imx95 AHAB SGK support Thanks for the clarification @AldoG. Re: imx95 AHAB SGK support Hello, Please do accept my apologize for the lack of response, if it is still useful, after confirmation with team, it is not supported on either A or B silicon revisions. Best regards/Saludos, Aldo.

問題: IMX_SEC_ENCLAVE の依存関係と解放後使用を修正する Hello これは、GitHub のこのプルリクエストのフォローアップです。 提供されたパッチは最終的に適用されなかったようで、lf-6.18.y には含まれていません。 Kconfigコミットは、NVMEM_IMX_OCOTP_SCUがmである場合にエンクレイブドライバがyになれないようにするためで、プローブのディフェースを回避するために必要です。 そうしないと、こうなります。 root@colibri-imx8x-14985125:~# dmesg -l err [ 1.708145] rtc-ds1307 1-0068: hctosys: unable to read the hardware clock [ 2.072996] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.078636] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.084513] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.111555] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.117209] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.123110] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.141671] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.147303] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.153200] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 2.171418] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 2.177065] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 2.182929] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.744448] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.750217] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.756186] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 5.877660] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 5.888247] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 5.894232] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 10.324138] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 10.349783] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 10.374692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 11.731697] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 11.738134] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 11.747692] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.284910] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.295720] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.307723] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.410541] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.426771] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.443446] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.644550] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.655906] debugfs: '5f1a0000.phy' already exists in 'regmap' [ 12.670039] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.688813] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.696063] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.765923] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.775810] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.786887] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.839515] fsl-se secure-envlave-1: Fail to read FIPS fuse [ 12.847285] fsl-se secure-envlave-1: Failed to fetch SoC Info. [ 12.853801] fsl-se secure-envlave-1: failed[-EPROBE_DEFER] to fetch SoC Info [ 12.936721] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 12.951328] nvmem imx-scu-ocotp0: cell mac raw len 6 unaligned to nvmem word size 4 [ 13.708903] genpd_provider mu_a1: failed to power off resource 214 ret -22 [ 16.701904] Bluetooth: hci0: unexpected event for opcode 0x0000 root@colibri-imx8x-14985125:~# 2回目のコミットではドライバにリファクタリングが行われており、NXPが対応しているかはわかりません コミット9703dfecc735(「LF-15802: ドライバ: ファームウェア: imx: SEドライバーの削除を修正」) SEチームに確認してもらえますか? よろしくお願いいたします フランツ Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free こんにちは、 まだ解決していないようですので、社内のソフトウェアチームに確認して確認します。 よろしくお願いいたします。 アルド。