Ethernet Pin Conflict on S32K344 Mini-EVB Hello Team, i am using S32K344 Mini-EVB for ethernet bring up activity. From its user manual i can see that pin no PTD16 for MDC and PTD17 for MDIO. But when i am doing ethernet pin configuration in S32DS i can see PTD16 can be only routed to MDIO and PTD17 is routed to MDC and also i verified it from S32K344_IOMUX from that excel also i can see that PTD16 --> MDIO and PTD17 --> MDC. So is there any mistake in user manual documentation if yes will it affect the ethernet communication. Re: Ethernet Pin Conflict on S32K344 Mini-EVB Hello @MySterio_1 , Yes, you are right. Pins MDC and MDIO were swapped. I've already reported that - it will be fixed in the next release of UM12406 - the release date is not known yet. Feel free to refer to my lwIP example related to this board: Example S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0    Best regards, Pavel

S32K328 MCUの電力推定ツールについて 私のアプリケーションでは、機能用MCUとしてS32K328を、安全用MCUとしてS32K341を使用しています。これらのICに対応した電力推定ツールがあるかどうか知りたいです。 もしそうであれば、私の用途に合ったものをどこで入手できるか教えてください。 ありがとう。 Re: Regarding power estimation tool for S32K328 MCU こんにちは、 @Abhinavv_007 さん。 現時点では、 S32K電力推定ツール（PET）を参照してください。 対応機器の数は限られているが、役に立つ可能性はある。S32K3X8デバイスに関する予備情報について、コミュニティのプライベートメッセージでもお送りしました。 最後に、S32K3XXのデータシートの第6.7章（供給電流）をご参照ください。そこには、スタンバイ時、低速動作時、および動作時の供給電流が記載されています。これは参考情報として役立つかもしれません。 よろしくお願いします、 ジュリアン

LS1012Aの自動起動が開始されない こんにちは、私はls1012aボードを問題なく使用していました。 起動時に、先ほどの画像のような状態になりません。 何が問題なのか知りたい。

集成 CAN 上的 UDS 引导加载器和 J1939 堆栈   说明： 嗨，团队、 我在 S32K344 上使用 S32DS 3.6.5 和 RTD 3.0.0。 目前正在实施： FlexCAN CAN 通信 通过 ISO-TP 的 UDS 引导加载程序 J1939 应用通信 GCC 编译器 AUTOSAR RTD 驱动器 我需要有关以下方面共存的指导： UDS 诊断（ISO14229） ISO-TP 传输层 J1939 通信栈 如何在 S32k344 中通过软件选择 CAN 终端电阻配置？ 解释如何在收发器和 MCU 中设计 CAN 终端 问题 在同一个 CAN 控制器上同时运行 UDS 和 J1939 的推荐架构是什么？ 是否建议为 UDS 和 J1939 使用不同的 CAN 报文缓冲器？ 如何配置 CAN ID 过滤？ 恩智浦是否有以下参考示例： UDS 引导加载程序 J1939 堆栈 共享使用 FlexCAN RTD 3.0 在这种使用情况下有什么已知限制吗？ 控制器： S32K344 RTD 3.0 S32DS 3.5 谢谢。

UDSブートローダーとCAN上のJ1939スタックの統合   説明： チームの皆さん、こんにちは。 私はS32DS 3.6.5とRTD 3.0.0を使用してS32K344で作業しています。 現在の実装： FlexCAN CAN通信 ISO-TP経由のUDSブートローダー J1939アプリケーション通信 GCCコンパイラ AUTOSAR RTDドライバ 以下のものの共存に関して指導が必要です。 UDS診断（ISO14229） ISO-TPトランスポート層 J1939通信スタック S32k344ではCAN終端抵抗の設定をソフトウェアで選択する必要がありますが、その方法を教えてください。 トランシーバとMCUにおけるCAN終端の設計方法について説明します。 質問: 同じCANコントローラ上でUDSとJ1939を同時に実行するための推奨アーキテクチャは何ですか？ UDSとJ1939用に別々のCANメッセージバッファを使用することは推奨されますか？ CAN IDフィルタリングはどのように設定すべきですか？ NXPの参考例はありますか？ UDSブートローダー J1939スタック FlexCANの共有利用 このユースケースに関して、RTD 3.0に既知の制限事項はありますか？ コントローラ: S32K344 RTD 3.0 S32DS 3.5 ありがとう。

SPI NAND boot on i.MX8ULP Hello, I'm trying to boot from a SPI NAND on i.MX8ULP. The evk has a SPI NOR attached and I was able to boot from it, but when trying with a NAND on our boards I cannot get this to work. I've configured BT*_CFG* pins and I see the boot ROM tries to read the NAND, but neither the M33 nor the A35 cores seem to boot, so I'm thinking the boot image is not correct. I'm building the image with imx-mkimage flash_singleboot_m33_flexspi target, which uses the fspi_header file as header block, but the comments in this file seem to indicate that this is for Serial NOR and not for NAND, so I'm looking into this flexspi configuration block header. How would one go about making an appropriate header file for our target? I found kobs-ng but it doesn't seem to be intended for 8ulp (no GPMI NAND controller, and doesn't work even after patching lightly to run anyway) I couldn't find any documentation about the FCFB block in the 8ulp documentation either. I found some documentation about it in the i.MX 8M Mini Applications Processor reference manual (and the u-boot patch adding options about it in u-boot mkimage), but even if it is indeed the same format then how to use it for i.MX8ULP (in particular what LUT table to use) would be appreciated. Thank you, Dominique Martinet

[S32K328およびS32K358] HSE-Bの性能について 親愛なるNXP S32K328GHT1MJBSTとS32K358GHT1MPCSTの間で、HSE-B（サイバーセキュリティエンジン）のセキュリティ機能や性能に違いがあるかどうかを知りたいです。 ありがとう、 ブライアン Re: [S32K328 and S32K358 ] About performance for HSE-B こんにちは、 @bryan_hong さん。 違いはありません。S32K328とS32K358は、同じバージョンのHSEファームウェアを共有しています。また、両デバイスともクロック周波数の制限は同じです。つまり、セキュリティ機能とHSE（環境・安全・衛生）性能は全く同じになります。 よろしくお願いいたします。 ルーカス

CAN 驱动程序恢复 你好 我正在 FRDM-A-S32K344 平台上开发 FlexCAN 驱动程序（中断模式）。我想验证 CAN 驱动程序是否支持在没有系统或点火重置的情况下从 CAN 总线故障中自动恢复。如果 SDK 版本 3.0.0 中存在此恢复功能、在驱动程序中，它是如何实现或反映的？ Re: CAN driver recovery 嗨，@ganavi1、 正如 @shep 所提到的，RTD 包中的 FlexCan 驱动程序可以启用 " AutoBus Recovery " 功能。 这是默认设置，无需额外设置。启用该位后，FLEXCAN 将自动尝试从总线关闭状态恢复到正常状态（假设导致总线断开的外部条件已消除）。 致以最诚挚的问候， Julián Re: CAN driver recovery S32K FlexCAN 寄存器支持自动总线断路恢复。我没有 SDK 手册，但你可以搜索相关部分，看看它是否与参考手册中描述的部分相互作用。 以下是参考手册中的文本： CTRL1 注册 BOFFREC 总线关闭恢复 确定 FlexCAN 如何从总线关闭状态中恢复。如果为 0，则根据 CAN 规范 2.0B 自动从总线关闭状态中恢复。如果为 1，则禁用从 Bus Off 自动恢复。在您向该字段写入 1 之前，模块将保持总线关闭状态。 如果在 CAN 总线上检测到 11 个隐性位的 128 个序列之前，此字段变为 0，则总线关闭恢复就好像该字段从未变成 1 一样。如果在出现 128 个包含 11 个隐性位的序列之后此字段变为 0，则 FlexCan 会重新同步到总线。在加入总线之前，它会等待 11 个隐性位。 此字段变为 0 后，它可以在总线关闭期间再次变为 1，但它仅在模块下次进入总线关闭时生效。如果模块处于 “总线关闭” 状态时此字段变为 0，则向该字段写入 1 对当前的 Bus Off 恢复无效。 有关详细信息，请参阅 CAN 协议标准 ISO 11898-1:2015 中的 总线 Off。 注意 0b-已启用 1b-已禁用 该位的默认值为 0，因此默认情况下它将自动执行总线断开恢复。 Re: CAN driver recovery 下面是一些纠错功能，希望对你有所帮助。 检测和纠正内存读取访问中的错误： —FlexCan 内存的每个字节都与五个奇偶校验位相关联。 -纠错机制可确保纠正 13 位字中一位的错误（可纠正错误）。 -可以检测到两个比特的错误，但无法纠正（不可纠正错误）。

RTD 版本迁移到 3.0.0 的原因和目的 嗨，团队、 我们目前正在从RTD 2.0.0 向 RTD 3.0.0迁移。并希望了解对我们现有引导加载器实施的影响。 请您澄清以下问题： RTD 2.0.0 和 RTD 3.0.0 之间的配置字段或 API是否有重大变化？是否会影响现有的实施？ 对于使用 RTD 2.0.0 开发的现有引导加载程序代码，我们是否需要进行修改以使其与 RTD 3.0.0 保持一致？ 是否可以在 RTD 3.0.0 源文件中直接重用 RTD 2.0.0 引导加载程序代码，还是建议继续使用 RTD 2.0. 0 进行引导加载程序开发？ 如能就如何处理这一迁移提供任何指导或最佳做法，我们将不胜感激。 提前感谢！ Re: RTD version migrated reason and purpose of version migrate to 3.0.0 你好，@Aravind_Togaralli、 我们目前使用的是 RTD 7.0.1，而 RTD 3.0.0追溯到 2023 年 3 月。 发行说明确实列出了已知问题和更改，但主要侧重于错误修复。 没有任何文档可以跟踪 RTD 版本中的 API 或配置更改。 您应该预期 API 和生成的代码会有所不同，因此并非总是可以重复使用为较旧 RTD 版本编写的代码。 此致， 丹尼尔

TFLM 推理问题：在 同步动态随机存取存储器(SDRAM) 中使用大型 ASR 模型时出现意外输出 (i.MX RT1170 EVK) 恩智浦支持团队，您好、 在 i MX 上使用微控制器 TensorFlow Lite（TFLM）运行大型声学语音识别（ASR）模型时，我们遇到了推理准确性/行为问题。 i.MXRT1170。 由于模型和所需的张量范围超过了内部 SRAM，因此两者都明确放置在外部 同步动态随机存取存储器(SDRAM)。应用程序运行流畅，没有任何内存故障或崩溃，但是模型的数学输出不正确。 环境： MCU：MIMXRT1170（Cortex-M7） 操作系统：FreeRTOS 框架： eIQ/TFLM 内存：模型和 Tensor Arena 完全位于外部 SDRAM 中 问题描述： 我们将模型数据加载 到外部 SDRAM 中并配置 MP U。 TFLM 微型解释器已初始化，AllocateTensors() 成功完成 (kTfLiteOk)。 我们将预先计算的浮点特征输入输入张量。为确保 DMA/内存一致性，我们会在推理之前手动使输入缓冲区的 DCache 失效。 interpreter.Invoke() 执行并成功完成，没有出现崩溃或 HardFaults。 问题：与在台式电脑上运行完全相同的模型和输入数据相比，解释器返回的输出日志完全不正确（或空白）。 已 采取的故障排除步骤： 输入验证：已验证输入到 MCU 张量的逐字节输入数据是否与我们成功的 PC Python 基准中使用的输入完全匹配 。 缓存管理：为 同步动态随机存取存储器(SDRAM) 区域配置 MPU，并确保 dCache 在推理之前失效，这样 Cortex-M7 就不会读取过时的内存。 OpResolver：验证模型所需的每个 TFLite 操作都已注册并得到支持。 团队要问的问题： 当大量矩阵操作完全 由外部同步动态随机存取存储器(SDRAM)执行时，恩智浦的TFLM实现中是否存在已知的精度损失问题或数学差异 ？ Cortex-M7 是否需要为外部 同步动态随机存取存储器(SDRAM) 配置特定的 MPU 属性配置（例如，强排序内存与普通内存），以确保 TFLM 准确计算权重/激活次数？ 如果我们强制 TFLM 在紧密耦合内存 (DTC/ITC) 之外运行操作，是否应该禁用特定 eIQ 硬件加速器标志？ 如能就调试 MCU 输出与 PC 基线之间的差异提供指导，将不胜感激。 谢谢、 普里耶什-沙希

FRDM-MCXN947 能否通过 J7 PMOD 连接 LCD-PAR-S035 FRDM-MCXN947 能否通过 J7 PMOD 连接到 LCD-PAR-S035？有没有相关的 Zephyr 例子？#LVGL MCX N Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD 不客气。如有任何新问题，欢迎创建新帖。 Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD 感谢您的答复。 FRDM-MCXN947 通过 J8 连接器与 LCD-PAR-S035 连接，运行良好。 Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD 你好@chaohang021、 谢谢您的帖子。 不，在 FRDM-MCXN947 上，LCD-PAR-S035 不是 J7 Pmod 连接路径。主板用户手册说，28针FlexIO接头J8支持液晶显示屏，并明确指出该接头旨在支持 LCD-PAR-S035 显示屏。J7 接头单独记录为用于连接外围模块的通用 Pmod 接头，而不是本主板的 LCD_PAR_S035 连接。 是的，恩智浦 Zephyr 显示器便携性演示和 FRDM-MCXN947 + LCD-PAR-S035 的 Zephyr LVGL 演示流程与此相关。 对于 FRDM-MCXN947，Zephyr/LVGL 示例使用样本/模块/lvgl/demos，板为：FRDM MCXN947 (CPU0) 和 SHIELD= " lcd_par_s035_8080 "。 希望对您有所帮助。 BR 西莱斯特

TFLM推論の問題：SDRAM（i.MX RT1170 EVK）における大規模ASRモデルでの予期しない出力 NXPサポートチームの皆様、こんにちは。 i.MX RT1170 上でTensorFlow Lite for Microcontrollers（TFLM）を使用して大規模な音響音声認識（ASR）モデルを実行している際に、推論精度や動作に問題が発生しています 。 モデルと必要なテンソル領域が内部SRAMの容量を超えるため、両方とも外部SDRAMに明示的に配置されます。アプリケーションはメモリ障害やクラッシュを起こすことなくスムーズに動作しますが、モデルの数学的な出力は正しくありません。 環境： MCU: MIMXRT1170 (Cortex-M7) OS: FreeRTOS フレームワーク：eIQ / TFLM メモリ：モデルとテンソルアリーナはすべて外部SDRAMに格納されます 問題の説明： モデルデータを外部SDRAMにロードし、MPUを設定します。 TFLMマイクロインタープリタが初期化され、AllocateTensors()が正常に完了しました（kTfLiteOk）。 事前に計算された浮動小数点特徴量を入力テンソルに入力します。DMA/メモリの一貫性を確保するため、推論の前に入力バッファのDCacheを手動で無効化します。 interpreter.Invoke() はクラッシュやハードフォールトを起こすことなく正常に実行され、完了します。 問題点：インタープリタによって返される出力ロジットが、デスクトップPCで全く同じモデルと入力データを実行した場合と比較して、完全に間違っている（または空白である）。 トラブルシューティング手順： 入力検証：MCUテンソルに入力されたバイト単位の入力データが、正常に動作したPC Pythonベースラインで使用された入力データと完全に一致することを確認しました。 キャッシュ管理：SDRAM領域用にMPUを設定し、推論前にDCacheが無効化されるようにすることで、Cortex-M7が古いメモリを読み取らないようにしました。 OpResolver: モデルに必要なすべての TFLite 操作が登録され、サポートされていることを確認しました。 チームへの質問： NXPのTFLM実装において、大規模なマトリックス演算を外部SDRAMのみで実行する場合、既知の精度損失問題や数学的な不一致はありますか？ Cortex-M7では、TFLMが重み/活性化を正確に計算できるようにするために、外部SDRAMに対して特定のMPU属性構成（例：強順序メモリ対通常メモリ）が必要ですか？ TFLMに密結合メモリ（DTC/ITC）外での操作を実行させる場合、無効にすべきeIQハードウェアアクセラレータの特定のフラグはありますか？ MCUの出力とPCの基準値との間のこの不一致をデバッグするためのアドバイスをいただければ大変ありがたいです。 ありがとう、 プリイェシュ・シャヒ

Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD? Is there any relevant Zephyr example? #LVGL MCXN Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD You are welcome. Any new issues, welcome to create a new post. Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD Thanks for your reply. FRDM-MCXN947 connect to LCD-PAR-S035 via J8 connector works well. Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD Hello @chaohang021 , Thanks for your post.  No, on FRDM-MCXN947, the LCD-PAR-S035 is not the J7 Pmod connection path. The board user manual says the LCD display support is on the 28-pin FlexIO header J8 , and explicitly states that this header is intended to support the LCD-PAR-S035 display. The J7 header is documented separately as a general Pmod header for connecting peripheral modules , not as the LCD_PAR_S035 connection for this board. Yes, the NXP Zephyr display portability demo and the Zephyr LVGL demo flow for FRDM-MCXN947 + LCD-PAR-S035 are relevant. For FRDM-MCXN947, the Zephyr/LVGL example uses samples/modules/lvgl/demos with Board: FRDM MCXN947 (CPU0) and SHIELD="lcd_par_s035_8080". Hope it helps. BR Celeste

FRDM-MCXN947はJ7 PMODを介してLCD-PAR-S035に接続できますか？ FRDM-MCXN947はJ7 PMODを介してLCD-PAR-S035に接続できますか？関連するZephyrのサンプルはありますか？#LVGL MCX N Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD どういたしまして。何か新しい問題があれば、遠慮なく新しい投稿を作成してください。 Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD ご返信ありがとうございます。FRDM-MCXN947をJ8コネクタ経由でLCD-PAR-S035に接続すると、正常に動作します。 Re: Can FRDM-MCXN947 connect to LCD-PAR-S035 via J7 PMOD こんにちは、 @chaohang021 さん。 投稿ありがとうございます。 いいえ、FRDM-MCXN947では、LCD-PAR-S035はJ7 Pmodの接続パスではありません。ボードのユーザーマニュアルには、LCDディスプレイのサポートは28ピンFlexIOヘッダーJ8で行われると記載されており、このヘッダーはLCD-PAR-S035ディスプレイをサポートすることを目的としていると明記されています。J7ヘッダーは、このボードのLCD_PAR_S035接続としてではなく、ペリフェラルモジュールを接続するための一般的なPmodヘッダーとして別途文書化されています。 はい、 NXP Zephyrディスプレイのポータビリティデモと、FRDM-MCXN947 + LCD-PAR-S035向けのZephyr LVGLデモフローは関連しています。FRDM-MCXN947の場合、Zephyr/LVGLのサンプルでは、samples/modules/lvgl/demosを使用し、Board: FRDM MCXN947 (CPU0)、SHIELD="lcd_par_s035_8080"を指定します。 お役に立てば幸いです。 BR セレステ

TFLM Inference Issue: Unexpected Outputs with Large ASR Model in SDRAM (i.MX RT1170 EVK) Hello NXP Support Team, We are experiencing an issue with inference accuracy/behavior while running a large Acoustic Speech Recognition (ASR) model using TensorFlow Lite for Microcontrollers (TFLM) on the i.MX RT1170. Because the model and the required tensor arena exceed internal SRAM, both are explicitly placed into external SDRAM. The application runs smoothly without any memory faults or crashes, but the mathematical output of the model is incorrect. Environment: MCU: MIMXRT1170 (Cortex-M7) OS: FreeRTOS Framework: eIQ / TFLM Memory: Model and Tensor Arena residing entirely in external SDRAM Problem Description: We load the model data into the external SDRAM and configure the MPU. The TFLM MicroInterpreter is initialized, and AllocateTensors() completes successfully (kTfLiteOk). We feed pre-computed float features into the input tensor. To ensure DMA/memory coherency, we manually invalidate the DCache for the input buffer prior to inference. interpreter.Invoke() executes and completes successfully with no crashes or HardFaults. The Issue: The output logits returned by the interpreter are completely incorrect (or blank) compared to running the exact same model and input data on a desktop PC. Troubleshooting Steps Taken: Input Verification: Verified that the byte-for-byte input data fed into the MCU tensor exactly matches the input used in our successful PC Python baseline. Cache Management: Configured the MPU for the SDRAM region and ensured DCache is invalidated before inference so the Cortex-M7 doesn't read stale memory. OpResolver: Verified that every TFLite operation required by the model is registered and supported. Questions for the Team: Are there known precision loss issues or mathematical discrepancies with NXP's TFLM implementation when heavy matrix operations execute entirely out of external SDRAM? Does the Cortex-M7 require a specific MPU attribute configuration (e.g., Strongly Ordered vs. Normal memory) for the external SDRAM to ensure TFLM calculates the weights/activations accurately? Are there specific eIQ hardware-accelerator flags that should be disabled if we are forcing TFLM to run operations outside of the tightly coupled memory (DTC/ITC)? Any guidance on debugging this discrepancy between the MCU output and the PC baseline would be greatly appreciated. Thank you, Priyesh shahi

确认 VSYS=0V 时 NX20P0407 SBU1 的下拉电阻 恩智浦专家，您好、 当我进行运输模式验证时，我发现 NX20P0407 在运输模式下 VSYS=0V 时出现异常电流泄漏； 异常发现：当 VSYS=0V 时，NX20P0407 在 SBU1 线路（系统侧）上有一个 75K 的等效 下拉电阻，这在数据手册框图中没有定义。 示意图 系统侧 SBU1 只与 MCU 的 SWDIO（MCU：nRF52840）相连，SWDIO 有 13K 上拉电阻（V_pullup=3.3V）； 在我的应用程序的出货模式下，MCU 处于活动状态，但是 NX20P0407 将断开电源（VSYS=0V）；当我在 SBU1 引脚上进行测量时，发现 SBU1 引脚的电压为 2.8147V，这意味着 SBU1 线路上有 75K 的下拉电阻，还造成了 37uA 的电流泄漏； 我还尝试对 NX20P0407 进行脱焊，37uA 的漏电流消失了，这再次证实了 NX20P0407 是造成电流泄漏的原因； 因此，我想确认一下我的发现是否正确，如果正确，为什么数据表中没有说明，非常感谢！ Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V 嗨，宗、 我怀疑漏电流是从SBU1引脚流向VSYS，而不是通过下拉电阻流向GND。请尝试完全断开 VSYS 引脚的连接，看看漏电流是否会降低。32uA 的泄漏电流最接近您看到的泄漏电流。当 NX20P0407 未使用时，请确保将 SBUEN 引脚拉至接地。让 SBUEN 保持浮空可能会因电磁干扰而将其拉高。 致以最崇高的敬意 约瑟夫 Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V 添加与 NX20P0407 相关的简化方框图以供参考。 Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V 你好 Jozef， 感谢你的快速回复，请看我的回复如下：你将 VSYS 连接到 GND 了吗？还是你让它浮空？ --回复：在 PP3V3 电源轨和 NX20P0407 的 VSYS 之间有一个负载开关；在出货模式下，MCU 将关闭负载开关，以去除 NX20P0407 的电源； 在运输模式下，NX20P0407 的其余引脚是如何连接的 --CC1&CC2 连接到 PD 控制器的 CC 线路，该线路在运输模式下也会去电，SBUEN 连接到同一个 PD 控制器的一个 GPIO；SBU2 连接到 MCU 的 SWDCLK，该线路有内部下拉电阻； Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V 嗨，宗、 感谢您的详细描述和示意图。请确认您在运输模式下是如何连接 VSYS 引脚的（当您在 SBU1 引脚上测量到 37uA 电流时）。您将 VSYS 连接到 GND 了吗？还是你让它浮空？在运输模式下，NX20P0407 的其他引脚是如何连接的？ 致以最崇高的敬意 约瑟夫

[S32K328 and S32K358 ] About performance for HSE-B dear nxp I would like to know whether the HSE-B (Cyber Security Engine) differs in terms of security functions or performance between S32K328GHT1MJBST and S32K358GHT1MPCST. Thanks, Bryan Re: [S32K328 and S32K358 ] About performance for HSE-B Hi @bryan_hong  There’s no difference. S32K328 and S32K358 share the same version of HSE firmware. And both devices have also the same clock limitations. So, security features and HSE performance will be exactly the same. Regards, Lukas

CANドライバの復旧 こんにちは、 私はFRDM-A-S32K344プラットフォーム上でFlexCANドライバ（割り込みモード）の開発に取り組んでいます。CANドライバが、システムリセットやイグニッションリセットなしでCANバス障害からの自動復旧をサポートしているかどうかを確認したい。このリカバリ機能がSDKバージョン3.0.0に存在する場合、ドライバのどこに実装または反映されているのか、また、どこで確認すればよいのか教えてください。 Re: CAN driver recovery こんにちは、 @ganavi1 さん。 @shepさんが指摘したように、RTDパッケージに含まれるFlexCANドライバを使用すると、「AutoBus Recovery」機能を有効にできます。 これはデフォルトで設定されており、追加の設定は必要ありません。このビットが有効になると、FLEXCANは自動的にバスオフ状態から正常状態への復旧を試みます（バスオフの原因となった外部条件が解消された場合）。 よろしくお願いします、 ジュリアン Re: CAN driver recovery S32K FlexCANレジスタは、バスオフ時の自動復旧機能をサポートしています。SDKのマニュアルは持っていませんが、関連するセクションを検索して、リファレンスマニュアルに記載されている部分と連携しているかどうかを確認してみてください。 以下はリファレンス・マニュアルからの抜粋です。 CTRL1レジスタ BOFFREC バスの事故復旧 FlexCANがバスオフ状態からどのように復旧するかを決定します。0の場合、CAN仕様2.0Bに従ってバスオフ状態からの自動復旧が行われます。1の場合、バス停止からの自動復旧は無効になります。このフィールドに1を書き込むまで、モジュールはバスオフ状態のままです。 CANバス上で11ビットの劣性ビットのシーケンスが128回検出される前にこのフィールドが0になった場合、バスオフからの復旧は、このフィールドが一度も1になったことがないかのように行われます。11ビットの劣性ビットのシーケンスが128回発生した後にこのフィールドが0になった場合、FlexCANはバスと再同期します。バスに加わる前に、11個の劣性遺伝子を待つ。 このフィールドが0になった後、バスオフ中に再び1になることができますが、それはモジュールが次にバスオフになったときにのみ有効になります。モジュールがバスオフ状態のときにこのフィールドが0になった場合、このフィールドに1を書き込んでも、現在のバスオフからの復旧には効果がありません。 詳細については、CANプロトコル規格ISO 11898-1:2015の「バスオフ」の項を参照してください。 注記 0b - 有効 1b - 無効 このビットのデフォルト値は0なので、デフォルトではバスオフからの復旧が自動的に実行されます。 Re: CAN driver recovery 以下にいくつかのエラー訂正機能を示します。お役に立てば幸いです。 メモリ読み出しアクセスにおけるエラーの検出と訂正： FlexCANメモリの各バイトは、5ビットのパリティビットに対応しています。 誤り訂正機構により、この13ビットワードの1ビットにおける誤り（訂正可能な誤り）を訂正することが可能になります。 —2ビットのエラーは検出できますが、訂正することはできません（訂正不可能なエラー）。

[S32K328 和 S32K358 ] 关于 HSE-B 的绩效 亲爱的 我想知道 HSE-B（网络安全引擎）在 S32K328GHT1MJBST 和 S32K358GHT1MPCST 的网络安全功能或性能方面是否有所不同。 谢谢， Bryan Re: [S32K328 and S32K358 ] About performance for HSE-B 你好@bryan_hong 没有区别。S32K328 和 S32K358 共享相同版本的 HSE 固件。而且这两款设备也有相同的时钟限制。因此，安全功能和HSE性能将完全相同。 此致， Lukas

Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi NXP expert, When I do shipping mode validation, I found an abnormal current leakage in NX20P0407 when VSYS=0V in shipping mode; Abnormal finding: NX20P0407 has an equivalent 75K pull down resistance on SBU1 line(system side) when VSYS=0V, which is not defined in datasheet's block diagram. Schematic: The system side SBU1 is only connected to MCU's SWDIO(MCU: nRF52840), which has 13K pullup resistor(V_pullup=3.3V); In my application's shipping mode, MCU is alive but NX20P0407 will be disconnected from power(VSYS=0V); When i did measurement on the SBU1 pin, found SBU1 pin's voltage is 2.8147V, which means there is 75K pull down resistor on SBU1 line and also caused 37uA current leakage; I also tried to de-soldering the NX20P0407, and the 37uA current leakage disappear which double confirmed that NX20P0407 caused the current leakage; So i would like to confirm whether my finding is correct or not, and if that's correct, why it is not specified in the data sheet, many thanks! Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Zong, I suspect the leakage current is flowing from the SBU1 pin to VSYS, than to the GND through the pull-down resistor. Please try to disconnect the VSYS pin completely and see if the leakage current will decrease. The 32uA leakage current is closest to the leakage current you see. Please make sure you have pulled the SBUEN pin to GND when the NX20P0407 is unused. Leaving the SBUEN floating may pull it high by an EMI.  With Best Regards, Jozef Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Adding the simplified block diagram related to NX20P0407 for reference. Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Jozef， Thanks for you quick response, please see my reply as below: Have you connected the VSYS to GND? Or have you left it floating? --Reply: There is a load switch between PP3V3 power rail and NX20P0407's VSYS; MCU will turn off the load switch to de-power NX20P0407 in shipping mode; How is the rest of the NX20P0407 pins connected in shipping mode --CC1&CC2 are connected to PD controller's CC lines which is also being de-powered in shipping mode, SBUEN is connected to the same PD controller's one GPIO; SBU2 is connected to MCU's SWDCLK which has internal pull down resistor; Re: Confirming the NX20P0407 SBU1's pull down resistor when VSYS=0V Hi Zong, thank you for detailed description and schematic. Please confirm how you have connected the VSYS pin in shipping mode (when you measured 37uA on SBU1 pin). Have you connected the VSYS to GND? Or have you left it floating? How is the rest of the NX20P0407 pins connected in shipping mode?  With Best Regards, Jozef