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=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=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=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 _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.pngPTD3 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コミュニティにご質問を提出してください。 よろしくお願いします、 ジュリアン

S32E2 IPCF 延迟时间介于 M33 和 R52 之间 我正在使用 S32E2 并配置 IPCF 框架，以下是我的设置。 设备：S32E288 IPCF 传输：共享内存 + MRU 通知 通信：M33 ↔ R52 IPCF通道类型：管理通道 配置了 1 个 IPCF 通道 中断模式（非轮询） 已实施 Ping/Pong RTT 测试 双向沟通正常。 我使用STM来测量两个核心之间的时序滴答数。 测量流程： R52： 时间戳 发送 PING   M33： 收到 PING 立即从 RX 回调发送 PONG 请求   R52： 收到 PONG 计算 RTT 计算得出，运行在 24Mhz 的 STM 的 RTT（往返时间）接近 200us。我的传输开销大约是 30 微秒，但传输本身占用了大部分时间。我尝试过各种方法，例如增加 MRU IRQ 通知，但并没有改善时序问题。代码优化级别从 -o0 到 -o1 有所提升，但 -o2 没有任何效果。有效载荷本身为 16 字节。 问题： 1. 托管/非托管通道的预期 IPCF 延迟是多少？ 2. 我们能否实现两位数的低延迟？ 如果您需要更多详细信息，请回复。 Re: S32E2 IPCF latency timings between M33 and R52 你好，PrabhanjanKopp 感谢您与我们联系。 对于您的测试场景，您可以参考 GreenVIP。循环时间约为 20-30 微秒。(S32ZE_GreenVIP_1.x.1/doc/UG_S32ZE_GreenVIP.pdf) Joey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.png Joey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.png 如果您还有其他问题，可以随时联系我们。 BR 乔伊 Re: S32E2 IPCF latency timings between M33 and R52 嗨，乔伊， 感谢你的回复。我目前使用 S32 DS 来设置我的核心，想知道 GreenVIP 是否有任何不同之处？另外，如果您能提供您在消息中提到的文档链接（或文档本身），将非常有帮助。是否有可供参考的项目，我可以将我的设置与之进行比较？我怀疑可能是配置不匹配的问题。 谢谢！ 普拉班詹 Re: S32E2 IPCF latency timings between M33 and R52 你好，普拉班詹 感谢您的回复。 GreenVIP下载链接如下： S32E2 安全可靠、高性能的实时处理器，支持执行器功能 | 恩智浦半导体 汽车软件代码包，软件包管理器 | 恩智浦半导体 Joey_z_0-1789452520972.pngJoey_z_0-1789452520972.png Joey_z_1-1789452649226.pngJoey_z_1-1789452649226.png EB tresos IDE 用于 GreenVIP，S32DS 和 EB tresos 都可用于开发 S32E 应用程序。希望这些信息对您有所帮助；如果您还有任何疑问，可以随时联系我们。 BR 乔伊

S32E2 IPCF latency timings between M33 and R52 I am working with S32E2 and configuring the IPCF framework and here is my setup Device: S32E288 IPCF transport: Shared Memory + MRU notification Communication: M33 ↔ R52 IPCF channel type: Managed channel 1 IPCF channel configured Interrupt mode (not polling) Ping/Pong RTT test implemented Communication is functioning correctly in both directions. I use STM to measure the timing ticks between the 2 cores. Measurement flow: R52: timestamp send PING   M33: receive PING immediately send PONG from RX callback   R52: receive PONG compute RTT The values computed for a STM running on 24Mhz are close to 200us RTT(Round trip time). My transport overhead is about 30us but the transfer itself takes up bulk of the time. I have tried various things like increasing MRU IRQ notification but has not improved the timings. Having optimisation in code from -o0 to -o1 helped but -o2 didnt make any difference. The payload itself is 16 bytes. Questions: 1. what is expected IPCF latency for managed /unmanaged channels. 2. can we acheive a low double digit latency? If you need any more details, please reply back. Re: S32E2 IPCF latency timings between M33 and R52 Hi,PrabhanjanKopp Thank you for contacting us. For your testing scenario, you can try to refer to GreenVIP. The Loop Time is about 20-30us.(S32ZE_GreenVIP_1.x.1/doc/UG_S32ZE_GreenVIP.pdf) Joey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.pngJoey_z_0-1789354232929.png Joey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.pngJoey_z_1-1789354243644.png If you have other issue, you can contact us at any time. BR Joey Re: S32E2 IPCF latency timings between M33 and R52 Hi Joey, Thank you for your reply. I am using S32 DS for setting up my cores and was wondering is GreenVIP is any different? Also , it will be most helpful to get the document link(or the doc itself)  that you referring in your message. Is there a reference project that I can compare my settings against? I suspect there might be some configuration mismatch. Thanks, Prabhanjan Re: S32E2 IPCF latency timings between M33 and R52 Hi,Prabhanjan Thank you for your reply. The link of GreenVIP download as the following: S32E2 Safe and Secure High-Performance Real-Time Processors with Actuation Support | NXP Semiconductors Automotive Software Package Manager | NXP Semiconductors Joey_z_0-1789452520972.pngJoey_z_0-1789452520972.png Joey_z_1-1789452649226.pngJoey_z_1-1789452649226.png The EB tresos IDE is used for the GreenVIP, both S32DS and EB tresos can be used to develop applications for S32E. Hope this information can help you; you can contact us at any time if you still have question about this. BR Joey

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.pngssong_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.pngssong_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.pngssong_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.pngdanielmartynek_0-1789469464382.png 谢谢！ BR，丹尼尔

FRDM-IMX93：Linux 无法访问 LPSPI3 寄存器（读取设备内存时出现总线错误）——外部 SPI 设备 摘要 我正在尝试在 FRDM-IMX93 板的P11 EXPI 接头上使用LPSPI3在 GPIO_IO08-11 上启动两个外部 MCP2515 CAN 控制器（Waveshare 2-CH CAN HAT，已确认在真正的 Raspberry Pi 上工作）（引脚与 UM12181 表 21 中 Raspberry Pi 兼容接头的位置相匹配）。 在修复了我能找到的所有设备树级问题（电源、引脚复用、片选、引脚控制断言-GPIO）之后，SPI 时钟 (SCK)始终无法在物理接头引脚上切换，并且直接读取 LPSPI3 块的寄存器会导致总线错误。另一个已知工作正常的外部设备（LPUART1）可以从相同的地址空间正常读取数据。这表明存在资源/总线访问限制（RDC 或类似限制），而不是 Linux 设备树中可以修复的问题。 板/软件 开发板：FRDM-IMX93（恩智浦），SoC：MIMX9352CVVXMAB BSP：NXP i.MX 发布发行版，内核版本 6.18.2-1.0.0-gf49f45233f7b 目标外设：lpspi3（spi@42550000，别名在 /aliases 中为 spi2，通过 /proc/device-tree/__symbols__ 确认实际 dts 标签为 lpspi3） 被测外部设备：CS0/CS1 上的 2 个 MCP2515（Waveshare 2 通道 CAN HAT） 已确认有效（已排除） 给排气歧管供电。reg_vexp_3v3 / reg_vexp_5v 是默认禁用的调节器固定节点（regulator_summary 显示 use=0）。通过覆盖片段添加了 regulator-always-on + regulator-boot-on，目标为 &reg_vexp_3v3 / &reg_vexp_5v（通过 __symbols__ 确认了真实标签）。事后验证 P11 上实际存在 3.3 V / 5 V 电压。 Pinmux。使用 imx93-pinfunc.h 中的官方宏，GPIO_IO08‑11 已正确复用到 LPSPI3_PCS0/SIN/SOUT/SCK。对于这三个函数，input_reg/input_val 均为 0x0000/0x0，因此不需要 DAISY 链选择（通过宏检查排除，不需要单独的寄存器）。 芯片选择。cs-gpios = , （位操作 GPIO CS，与 NXP 针对此节点的上游板级支持模式相匹配）。通过 cat /sys/kernel/debug/gpio 和万用表/逻辑分析仪确认： CS0 切换正常，并且物理上连接到了接头引脚。 pinctrl-assert-gpios。NXP自己的上游 &lpspi3 参考中包含 pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;（此行并未出现在大多数公开指南中，仅出现在板自己的 dts 补丁中）。已添加；通过 /proc/device-tree/__symbols__ 确认 pcal6408 已解析，并通过 cat /sys/kernel/debug/gpio 确认，一旦请求 lpspi3 的默认 pinctrl 状态，GPIO 就会被钳位（输出 hi）。 覆盖层涂抹顺畅。U-Boot 的 fdt apply 没有出现 FDT_ERR_NOTFOUND；/sys/bus/spi/devices/ 显示 SPI 内核已注册 spi2.0 和 spi2.1。 ERR051608（LPSPI TCR[PRESCALE] 勘误）。已检查 spi-fsl-lpspi.c历史记录——该修复（fsl、imx93-spi 的 prescale_max = 1）已于 2024 年 8 月合并到主线版本 / 稳定版 6.6.51。& 6.10.10 2024 年 9 月，远早于此内核版本 (6.18.2)，并且兼容字符串 (fsl,imx93-spi) 已存在于主板 dts 中，因此驱动程序应该自动应用此限制。虽然不能完全排除这种可能性（没有直接的注册确认实际写入了 PRESCALE 字段），但时间线强烈表明此事已经处理完毕。 实际症状 使用万用表探测物理 P11 引脚上的 CS0/CS1、MISO、MOSI、SCK，然后使用逻辑分析仪以 10–20 MSa/s 的采样率在 CS0 下降沿触发，同时不断重试传输（在循环中使用 spidev_test，以及通过 echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind 反复强制 mcp251x 重新探测）： CS0切换。经万用表和逻辑分析仪验证。 SCK 从不切换。平坦，无任何活动，无论持续尝试转移。 MOSI 从不切换。 两个 MCP2515 的故障情况完全相同：mcp251x spi2.0/spi2.1：MCP251x 在复位后未进入配置模式 / 探测失败，错误代码为 110 (ETIMEDOUT) — 即驱动程序自身的 SPI 级复位 + 读取 CANSTAT 序列未得到响应，这与 SCK 从未离开 SoC 的情况一致。 根本原因已缩小到时钟/总线访问，而非设备树。   # clk_enable_count is 0 despite the controller actively being used $ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3 lpspi3_root 0 0 0 50000000 0 0 50000 N deviceless no_connection_id lpspi3 0 0 0 50000000 0 0 50000 N 42550000.spi per 即使 42550000.spi（真正的、绑定的消费者）正在循环中积极尝试传输，lpspi3 的功能（每个）时钟也显示 enable_count=0——它并非只是“未使用”（与 lpspi1/2/4 相比，它们是无设备的，也显示 0，因此仅凭这一点并不能得出结论）。 决定性的测试——通过 devmem 直接读取寄存器：   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) 一个完全无关的、工作正常的外部设备（LPUART1，用于调试控制台）可以从相同的 CPU/总线上下文中正常读取数据。LPSPI3 的基地址在普通的 32 位读取中就会出现故障，甚至在任何时钟门控或引脚复用考虑之前就会发生这种情况。这看起来像是资源域控制器 (RDC) 或类似的访问控制机制，在硬件级别阻止 Cortex-A55 (Linux) 域访问此外围设备的地址范围，而与 Linux 设备树中的任何可配置项无关。 向恩智浦提出的问题 FRDM-IMX93 上的 LPSPI3 是否故意保留给另一个功能域（例如，该板默认的 RDC 配置中包含 Cortex-M33 / secure world 内核，导致在 Linux 系统下，如果不进行额外的 SPL/ATF/TF-A 级重新配置，则无法使用该内核？ 如果是这样，是否有记录在案的方法将 LPSPI3 总线访问权限重新分配给 Cortex-A55 非安全域（U-Boot SPL 中的 RDC 配置，或 OP-TEE/TF-A 更改），或者尽管 GPIO_IO08-11 已引出，但此板的 P11 接头上根本不支持外部 SPI？ 这是我的板/内核版本特有的问题，还是默认 FRDM-IMX93 电路板支持包的已知特性？如果存在参考文件 imx93-11x11-frdm-lpspi.dts（类似于 EVK 的 imx93-11x11-evk-lpspi.dts），将会非常有帮助。 如何重现 底板 dtb：随 i.MX 版本 发行版镜像一起提供的标准 imx93-11x11-frdm.dtb（未修改的 NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v 节点 — 全部通过 __symbols__ 确认存在）。 应用上述覆盖层（regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3）。 手动将 spidev（内置，CONFIG_SPI_SPIDEV=y）绑定到 spi2.0：   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override echo spi2.0 > /sys/bus/spi/drivers/spidev/bind spidev_test -D /dev/spidev2.0-s 1000000 -v — 传输“成功”（无 I/O 错误），但即使 MOSI/MISO 物理短路，RX 数据也不是 TX 的环回。 devmem 0x42550000 32 → 总线错误。 如果需要，我很乐意提供完整的 overlay 源代码、dmesg 和 clk_summary/gpio 转储。

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 こんにちは、 まだ解決していないようですので、社内のソフトウェアチームに確認して確認します。 よろしくお願いいたします。 アルド。

S32 Design Studio for ARM 2.2 cannot be activated. Install S32 Design Studio for ARM 2.2: 1. Selecting "online" during activation results in the error shown in Figure 1. Using https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/Troubleshooting-Activation-fails-with-error-message-FNP-ERROR-0/ta-p/1123259 results in the error shown in Figure 2. However, my computer's FlexNet service... Licensing Service in startup state 2. After following the official website's steps exactly when using offline activation, I encountered the error shown in Figure 3. How can I correctly activate and install this version of the software? Re: 安装S32 Design Studio for ARM 2.2无法激活 I followed the steps exactly, but it still doesn't work. Re: 安装S32 Design Studio for ARM 2.2无法激活 Hi @aether  The FNP Error 20 is usually related to components not being installed correctly or not being accessible to the current user. Could you please try the following: Fully uninstall S32DS for ARM v2.2 and remove any remaining files in C:\NXP\S32DS_ARM_v2.2. Back up and clear the contents of the hidden folder C:\ProgramData\FLEXnet\. Re-download and install the base S32DS for ARM v2.2 package (without Update 2). Run the installer with Administrator privileges and ensure that antivirus or security software is not blocking. BR, VaneB Re: 安装S32 Design Studio for ARM 2.2无法激活 Hi @aether  Could you please share the installation log file (.log)? It should be located under: C:\NXP\S32DS_ARM_v2.2\_S32 Design Studio for ARM Version 2.2_installation\Logs

S32 Design Studio Platform + SW32G2 + RTD version selection I refer to the S32G-VNP-RDB2 SOFTWARE ENABLEMENT GUIDE, the suggested software version was SW32G2_S32DS_3.4.0_D2012.zip + S32DS.3.4_b201217_win32.x86_64.exe + Real Time Drivers S32_RTD_4.4_1.0.0_HF01_D2102_DS_Updatesite.zip.  But I actually download 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.  When I want to new the Light Up RGB LED and open peripherals tool, It will show "Peripherals: [SDK] Failed to update code - Code generation failed“. I'm not sure if the different software version combination causing these error. Re: S32 Design Studio Platform + SW32G2 + RTD version selection Hi, guang1994 I will reply to you internally. BR Joey

ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free Hello This is a follow up from this PR on github. It seems that the patches provided were at the end not applied as it's not present in lf-6.18.y. The Kconfig commit is needed to make sure that the Enclave driver cannot be y when NVMEM_IMX_OCOTP_SCU is m, thus avoiding probe defers. Otherwise you get this: 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:~# On the second commit submitted, there has been some refactoring in the driver and I'm not sure if this has been addressed by NXP with commit 9703dfecc735 ("LF-15802: drivers: firmware: imx: Fix the SE driver remove") Could  maybe the SE team confirm? kinds regards Franz Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free Hello, I see that this has not been solved yet, will check with internal software team and confirm about this. Best regards/Saludos, Aldo.