MatterスタックのMIMXRT700-EVK(MIMXRT798S)への移植 — 永続的なストレージ初期化の失敗 こんにちは、 現在、MCUXpresso SDKとVS Codeを使ってNXP MatterスタックをMIMXRT700-EVK(MIMXRT798S)に移植する作業を進めています 。このボードはIW612チップセットをベースにした外付けのMurata Type 2EL無線モジュールを使用しています。 開発環境のセットアップと変更 VS Codeを通じてマター MCUXpresso SDKワークスペースをダウンロードし、セットアップしました。ワークスペースはmatter_mcuxpresso/mcuxsdkにあります。 以下の点において、RT700専用の変更を加えました。 マター:RT700プラットフォーム統合のためにミドルウェア/マター上でファイルを修正しました。 ワイヤレスフレームワーク: 外部村田タイプ2EL(IW612)無線モジュールのRT700専用プラットフォームサポートと統合を追加。 リンカースクリプト:RT700 SDKが提供するMIMXRT798Sxxxx_cm33_core0_flash.ldを参照として使用し、MatterアプリケーションのメモリレイアウトおよびNVSストレージ構成に合わせて修正しました。 問題の説明 Matterアプリケーションは正常にビルドでき、LinkServerを使ってプログラム可能です。しかし、src/platform/nxp/common/NXPConfigNVS.cppの以下の呼び出しでCHIP_ERROR_PERSISTED_STORAGE_FAILEDが実行されると実行時の初期化が失敗します。 flash_init(fa->fa_dev) CHIP_ERROR_PERSISTED_STORAGE_FAILED リンカースクリプトの添付ファイル 参照のために修正されたMIMXRT798Sxxxx_cm33_core0_flash.ldリンカースクリプトを添付します 。これはRT700 SDKが提供するリンカースクリプトを基にしており、MatterアプリケーションのメモリレイアウトおよびNVSストレージ構成の変更を含んでいます。 サポートが必要です もう少し詳しく教えていただけますか: RT700-EVKのマター永続保存ストレージ用にフラッシュデバイスとドライバーはどのように設定すべきでしょうか? RT700専用のフラッシュドライバーやNVS統合の追加ステップは必要ですか? 修正されたリンカースクリプトやNVSメモリレイアウトがflash_init()の失敗に影響している可能性はありますか? この問題の解決について、ご指導いただければ幸いです。 よろしくお願いします。 評価ボード Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、@Aparna1 さん。 ご質問ありがとうございます！ 提供されたリンカースクリプトを確認しました。現在、以下のFlexSPI関連オブジェクトを参照しています。 *(EXCLUDE_FILE( ... *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o* ) .text*) ただし、MIMXRT700はXSPIコントローラを使用しています。アプリケーションが正しいRT700 XSPIフラッシュバックエンドとリンクされており、他のRTプラットフォームで使われるFlexSPIバックエンドではなく、このデバイスを指している i.MX fa->fa_dev 確認してください。 また、マップファイルで flash_init() 、フラッシュ消去/プログラム機能、および関連する XSPI_* 機能を確認してください。これらの機能およびそれらに必要な設定データは、XIPフラッシュ領域ではなく、RAMに配置する必要があります。 ポートの確認は以下の順序で行うことをお勧めします。 SDKの公式RT700 XSPI NORフラッシュ例を確認してください。 fa->fa_dev 正しいXSPIバックエンドを使用していることを確認してください。 フラッシュ操作コードが実際にRAMから実行されることを確認する。 次にNVSアドレス、セクターアライメント、ドライバが絶対アドレスかデバイス相対オフセットを期待しているかを確認します。 よろしくお願いします、 ギャビン Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、 @Gavin_Jia ご提案いただいた変更に基づいてリンカーファイル（ MIMXRT798Sxxxx_cm33_core0_flash.ld ）を修正し、XSPI関連の設定を更新しました。しかし、問題は依然として解決せず、 flash_init()関数が引き続き失敗します。 修正済みのMIMXRT798Sxxxx_cm33_core0_flash.ldファイルを共有してご覧いただきます。リンク設定を確認し、XSPIフラッシュの初期化問題を解決するために追加で何の変更が必要か教えていただけませんか? よろしくお願いします。 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、@Aparna1 さん。 最新情報のご提供ありがとうございます。 ベースラインとして、`mimxrt700evk_flash_component_octal_xspi_cm33_core0` プロジェクトと、それに関連するリンカースクリプト (LD ファイル) を使用することをお勧めします。マターに移行する前に、フラッシュ操作に関連するコードが正常に移植されていることを確認してください。 リンカースクリプトだけで移植プロジェクトを完全に診断することはできないため、いくつかの提案しかできません。ご理解いただきありがとうございます。 あなたのスクリプトをレビューした結果、いくつか問題点が見つかりました。以下にその点を記載します。 1.XSPIコードはXIP領域にリンクされている可能性がある .text セクションでは、スクリプトはまず XSPI および NVS 関連のオブジェクトファイルを除外します。 *(EXCLUDE_FILE( ...​​ *fsl_xspi_nor_flash.c* *mflash_drv.c.o* *fsl_xspi.c.o* ） 。文章*） しかし、スクリプトには後ほど無条件のルールが含まれる。   *（。文章） *（。文章*） *(.rodata) *(.rodata*) これらの後のルールは、以前に除外された入力セクションを再び収集し、外部XSPI Flash領域にある m_text に戻すことができます。 したがって、現在の EXCLUDE_FILE ルールでは、XSPI/NVS実行パスがRAMから実行されることが保証されません。 2. RAMセクションには、RT700のXSPIオブジェクトではなく、FlexSPIオブジェクトが依然として含まれています。 .data セクションは現在、以下のコードを RAM に配置します。 *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o*   しかし、RT700はXSPIコントローラを使用しています。 3. fsl_xspi_nor_flash 定数は一貫してRAMに移動されません fsl_xspi_nor_flash .text* 除外リストには含まれていますが、 .rodata* 除外リストには含まれていません。 変更したリンカースクリプトや最終イメージについて不明な点がある場合は、マップファイルから重要な情報を抽出するというデバッグ手法を試してみる価値があります。 よろしくお願いします、 ギャビン Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、 @Gavin_Jia さん。 以前報告されたflash_initの問題(CHIP_ERROR_PERSISTED_STORAGE_FAILED)は解決されました。アプリケーションはフラッシュ初期化プロセスを正常に完了しました。 しかしながら、現在、RT700-EVK上で外部のMurata Type 2EL (IW612) M.2モジュールを使用してIW612 Wi-Fiを初期化する際に、新たな問題に直面しています。 起動時に以下のエラーメッセージが表示されます。 [wifi_io] Error: SDIO - FW Ready Registers not set [wifi] Error: sd_wifi_init failed. status code -1 [wlcm] Error: wifi init/reinit failed. status code -1 ASSERT ERROR " WM_SUCCESS == ret "  この問題の調査に協力していただき、必要なSDIO設定、ファームウェアダウンロードシーケンス、またはIW612初期化に必要なRT700固有の変更をご提案いただけますか? ありがとうございます

时钟-电源关系：MIMXRT685-EVK 你好， 对于某个应用，我将核心时钟频率提升到最大可能值，即从默认的 250 MHz 提升到 297 MHz。我想知道从权力角度来看，这会造成哪些影响。虽然目前还没有出现任何问题，但根据数据手册中的静态特性，我认为我需要做一些更改，以避免将来出现硬故障。我非常希望得到一些指导。 提前感谢！ 什里 Re: Clock - power relationship : MIMXRT685 - EVK 嗨@shri00 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 对于 MIMXRT685-EVK 的 297 MHz 运行，请检查 VDDCORE 电压以及时钟配置。板目前运行无故障这一事实并不一定意味着 VDDCORE 满足您目标频率和温度范围的运行要求。   提高时钟频率时，首先将 VDDCORE 设置为目标频率所需的电平，然后再切换到更高的频率。   有关 VDDCORE 与时钟频率的关系，请参阅 RT600 数据手册的表 20 和表 21。 采用 32 位 Cortex®-M33 和 Xtensa HiFi4 音频 DSP CPU 的双核微控制器 祝你今天过得愉快。 顺祝商祺！ 刘梅

HSE [等待中断(WFI)] 状态理解 目前，我正在进行 MCU 时钟初始化，并等待 HSE 进入 WFI 状态（CLOCK_IP_WFI_EXECUTED == 0x80000000U），然后再进行时钟配置。 目前的实现方式如下所示。但是，我担心如果 HSE 始终无法转换到 WFI 状态，ECU 将无限期地陷入等待循环。请问能否建议一种合适的保护措施或超时机制来安全地处理这种情况？ 做 { WfiStatus = (IP_MC_ME->PRTN0_CORE2_STAT & MC_ME_PRTN0_CORE2_STAT_WFI_MASK); } while (CLOCK_IP_WFI_EXECUTED != WfiStatus); Re: HSE [Wait for Interrupt(WFI)] status understanding 你好@ManuSharma1 最糟糕的情况是 HSE 固件的安装、更新或恢复，正如 HSE-B 固件参考手册中所述，这可能需要大约 1 秒钟。因此，我建议超时时间设置为大约 1.3 秒，以便留出一些余地，避免在未达到预期 WFI 状态时出现无限等待。 此致， Lukas Re: HSE [Wait for Interrupt(WFI)] status understanding 亲爱的@lukaszadrapa 谢谢你提供的详细信息。 根据建议，我计划使用大约1.3 秒的基于定时器的超时时间，等待 HSE 进入 WFI 状态。如果在此超时时间内未达到 WFI 状态，我打算执行故障保护措施。 故障保护操作方面，我正在考虑执行MCU RESET，因为 HSE 将无法处于处理进一步请求的适当状态。在继续之前，我希望您能就以下几点提供指导： 对于 HSE WFI 超时情况，执行 MCU RESET 是否是正确的处理方法？ 如果建议RESET，应该使用哪种RESET方式： 功能 RESET（FES），或 破坏性RESET（DES）？ 在 S32K312 架构中，HSE 作为独立的引擎运行，负责网络安全相关的功能。如果发出 MCU RESET 指令，HSE 引擎也会 RESET 吗，还是会继续独立运行？ 您的意见将有助于确保超时处理机制得到正确、稳健的实现。 谢谢，此致敬礼！ 马努·夏尔马 Re: HSE [Wait for Interrupt(WFI)] status understanding 你好@ManuSharma1 通常，第一步是检查 0x4039_C028 处的 HSE GPR是否设置了位 0。如果RESET后第 0 位为“0”，则 HSE 固件根本不存在，由于某些致命错误而被完全擦除。 如果 HSE GPR 中的第 0 位为“1”（HSE 固件存在），但 RESET 后 HSE_STATUS_INIT_OK 仍为“0”，则表示需要启动握手过程。参见“14.6.7有关详细信息，请参阅 HSE FW RM 中的“HSE 固件握手”。如该部分所述，您应该触发几次功能重置。 不能使用外部复位，因为它会触发信号破坏性复位。另一种方法是通过软件触发功能重置。您可以看看这篇文章： https://community.nxp.com/t5/S32K/S32K344-How-to-manually-trigger-one-Function-Reset/m-p/1506101/highlight/true#M17079 简而言之： RESET 后，检查 0x4039_C028 处的 HSE GPR 寄存器中的第 0 位。如果值为 0，则表示固件已被擦除，您可以尝试重新安装。如果结果是 1，则进行下一步。 等待 FSR 寄存器中的 HSE_STATUS_INIT_OK 位置位。如果已设置，则 HSE 固件已启动并运行。如果在复位后约 1 秒内未设置（使用约 1.3 秒或更长的超时时间），则触发功能复位。 重复此步骤，直到固件恢复或擦除为止。如果固件被擦除，则需要重新安装固件。 另请注意，如果您使用 AB_SWAP 版本，并且由于某些致命错误导致固件被 SBAF 擦除，则重新安装固件的唯一选项是“通过 MU 接口安装”方法。在这种情况下，通过 IVT 进行安装或通过默认位置进行安装的方法均无效。 更多详情请参阅 HSE 固件参考手册中的“10 错误和警告管理”部分。 此致， Lukas

iMX8 支持的端点数量 iMX8 使用 DWC3 作为 USB 控制器，DWC3 是一款 xHCI 控制器。从 iMX8 的寄存器中读取数据后，我发现它最多可以支持 64 个设备。但是当我连接几个设备时，之前就出现了 xHCI 资源错误。似乎端点数量存在某种限制，而且似乎还取决于传输类型（批量、控制等）。在我使用的这类设备（包括集线器）中，似乎在连接 80 个终端后就会出现问题。请问能否提供一些确切的数字/公式，说明支持多少个端点？ Re: Number of supported endpoints on the iMX8 你好， i.MX8 xHCI MaxSlots = 64 值指定了可启用 USB 设备插槽的最大数量，而不是端点总容量。xHCI 每个设备最多支持 31 个端点上下文，但控制器不保证所有 64 个插槽都能同时使用最大数量的端点。可用总量主要取决于周期带宽、设备速度、端点间隔和数据包大小、集线器拓扑结构、事务转换器分配和 DWC3 实现资源。   详细信息请参考xHCI规范。 Re: Number of supported endpoints on the iMX8 我查阅了xHCI规范，但没有找到任何相关说明。xHCI 唯一明确规定控制器可以返回资源错误（就是我上面提到的那个错误）的地方是…… 例如。英特尔表示，他们的一款 xHCI 控制器支持多达 2048 个批量/控制 EP 或多达 128 个中断/同步 EP。 https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/servers/platforms... 我们有一个测试装置（仅限 USB 2.0），它在 Intel 芯片上运行良好（数百个 EP），但在 iMX8MP 上的部分设备（前面提到的 80 个 EP）上失败。 但是，要了解我们可以支持多少种以及哪些类型的设备，我们需要知道 iMX8MP/DWC3 的限制是什么。如果您能像英特尔那样，为我们提供一些公式或限制条件，那将非常有帮助。

MPC5777C Nexus 跟踪，eTPU A/B 时钟停止。 您好， 经发现，如果通过 SIU_HLT1.ETPUA 位停止 eTPU A/B 时钟，则 Nexus 端口控制器 (NPC) 的 MDO 和 MSEO Nexus 输出将卡在 0V（死机）。即使其他 Nexus 客户端（例如e200) 正在生成 Nexus 跟踪数据。 如果稍后将 SIU_HLT1.ETPUA 写入“0”（时钟不再停止），则来自 e200 Nexus 客户端的 Nexus 跟踪流将到达 NPC 和外部世界。 经过一些测试，似乎 HLT1 寄存器中的其他时钟停止请求不会在 MSEO/MDO 引脚上产生相同的行为。 因此，核心问题似乎是 eTPU A/B 时钟停止会影响 Nexus 跟踪操作的总体情况。 无论 NPC 中的时钟分频器或端口宽度如何，都会发生这种情况。 我通过反复试验找到的解决方法是，首先通过各自的 ECR.MDIS 位禁用每个（A 和 B）eTPU 引擎，然后通过 HLT1.ETPUA 禁用整个模块时钟，如果从其他 Nexus 客户端（例如，）发起跟踪，则 MSEO/MDO 引脚仍会正常工作。e200 核心）。   然而，这种变通方法并非最佳方案，因为它需要对用户应用程序进行更改。我想知道调试器是否可以采取一些措施来缓解这种行为？   Re: MPC5777C Nexus trace while eTPU A/B clock halted 你好， 我从未遇到过这样的问题，因为我们一直使用 Codewarrior 的 Ashware 提供的 eTPU 模拟器。 我会仔细查看并尽快回复您。 顺祝商祺！ Peter Re: MPC5777C Nexus trace while eTPU A/B clock halted 您好， 谢谢你调查此事。问题在于，作为调试人员，我们尽量避免修改 SoC 外设相关寄存器，因为这会影响用户应用程序。 在这种情况下，问题在于 SIU_HLT1[ETPUA] = 1 是由用户应用程序写入的，而不是由我们作为调试器写入的。因此，调试器无法知道用户应用程序何时会执行该操作，因此调试器无法在应用程序写入 SIU_HLT1[ETPUA] = 1 之前写入 ECR[MDIS]； 我们将建议用户更新应用程序，使其在 SIU_HLT1[ETPUA] = 1 之前写入 ECR[MDIS]。 Re: MPC5777C Nexus trace while eTPU A/B clock halted 你好， 这种现象似乎与 MPC5777C 时钟门控实现有关。我们目前还没有发现任何 NPC 配置可以阻止 eTPU A/B 停止请求影响 Nexus 输出。 作为调试器的变通方法，请在设置 SIU_HLT1[ETPUA] = 1 之前执行以下序列： 将 eTPU 引擎 ECR[MDIS] 的两个位都设置为 1。 请等待发动机完成当前工作后再进行操作。 将 SIU_HLT1[ETPUA] 设置为 1。 这个步骤可以在调试器停止脚本中自动完成。但是，它会停止两个 eTPU 引擎，因此对应用程序来说并不透明。这个问题也应该由芯片设计团队进行审查，作为可能的设备勘误。 顺祝商祺！ Peter

S32 Design Studio version v.3.5 license Hello NXP Support Team, My S32 Design Studio version v.3.5 license expired on Oct 19, 2026. Could you please help extend the license? Activation Code: 30E0-0F7D-F883-9AFB Thank you for your support. Eclipse IDE Usage and Settings

Request for Hall Sensor-Based Motor Control Reference Firmware and Training Material Dear NXP Team, We are working with a customer developing an air-cooling system using a 24 V, 3.47 A motor. We have successfully completed a demonstration using sensorless FOC-based motor control. The customer now wants to integrate Hall sensors for rotor position detection using the FRDM-MCXA156 EVK (control card) with the FRDM-MC-LVPMSM (power card). Could you please suggest a suitable reference firmware or application example for implementing Hall sensor-based motor control on this hardware combination? I reviewed the Hall-sensored BLDC example for the LPC55S36 available on GitHub. However, I could not locate the corresponding FreeMASTER configuration file (.pmpx) for this example. Could you please help us with the following? Reference firmware for Hall sensor integration on the FRDM-MCXA156 with the FRDM-MC-LVPMSM. The corresponding FreeMASTER project/configuration file (.pmpx), if available. Relevant application notes, training materials, or implementation guides for integrating Hall sensor feedback into an existing sensorless FOC project Based on FRDM-MCXA156 EVK. Your technical guidance and recommendations would be greatly appreciated. Best Regards  Darshan J L  WPG India  Board Design Development Board FRDM-Training Hands-On Training MCXA Motor Control Re: Request for Hall Sensor-Based Motor Control Reference Firmware and Training Material Hello @Darshan_J_L , Thanks for your post. The MCUXpresso SDK includes multiple motor control example projects. You can find more information for FRDM-MCXA156 on the following page. MCUXpresso SDK for Motor Control | NXP Semiconductors.   The pmsm_enc example for the FRDM-MCXA156 + FRDM-MC-LVPMSM combination is in the SDK v25.06. It supports sensorless and sensored FOC and includes the pmsm_float_enc.pmpx FreeMASTER project. You can refer to UG10247.pdf for more details.   About the corresponding FreeMASTER configuration file (.pmpx) for LPC55S36 demo, you can find it here: an-lpc55s36_mc_bldc_whall/LPC5536_mc_bldc_wHall.pmpx at main · nxp-appcodehub/an-lpc55s36_mc_bldc_whall · GitHub   Hope it helps. Please let me know if you still have any other questions.   BR Celeste    

S32 Design Studio for Power Architecture 2017.R1 はライセンス満了後に「ライセンス不足」と表示します 私はWindowsの S32 Design Studio for Power Architecture 2017.R1 を使っています 。IDEでは「 ライセンス不足」 と表示 され、ライセンスは期限切れのようです。 アクティベーション | インストール | ライセンス | インストーラーのダウンロード

S32 Design Studio for Power Architecture 2017.R1 shows “License missing” after license expired I am using S32 Design Studio for Power Architecture 2017.R1 on Windows. The IDE now shows “License missing”, and it seems the license has expired. Activation | Installation | Licensing | Installer Download

MBDのキャリアアドバイスが必要です 私は5年前に自動車ソフトウェアのモデルベースデザインでキャリアをスタートしましたが、今はとても単調でツール面での学習もあまり感じていません。この状況にどう対処しましたか? 私が月に関わる仕事の量は、Simulinkのモデリングが10%、モデルのテストと報告が50%、残りは手動のコンプライアンス文書作成です。

HSE [割り込み待ち(WFI)] ステータスの理解 現在、MCUのクロック初期化作業に取り組んでおり、HSEがWFI状態(CLOCK_IP_WFI_EXECUTED == 0x80000000U)に入るのを待ってからクロック設定を進めています。 現在の実装は以下の通りです。しかし、私の懸念は、HSEがWFI状態に移行しなければ、ECUが無限に待機ループに閉じ込められることです。このシナリオを安全に処理するための適切なセーフガードやタイムアウトの仕組みを提案していただけますか? どうぞ { WfiStatus = (IP_MC_ME->PRTN0_CORE2_STAT & MC_ME_PRTN0_CORE2_STAT_WFI_MASK); } 一方(CLOCK_IP_WFI_EXECUTED != WfiStatus); Re: HSE [Wait for Interrupt(WFI)] status understanding こんにちは、 @ManuSharma1さん 最悪の場合はHSEファームウェアのインストール、アップデート、または復旧で、HSE-Bファームウェアのリファレンスマニュアルに記載されているように約1秒かかることもあります。したがって、WFIの想定状態に達しない場合に無限待機状態になるのを避けるため、タイムアウト時間を約1.3秒に設定することをお勧めします。 よろしくお願いいたします。 ルーカス Re: HSE [Wait for Interrupt(WFI)] status understanding @lukaszadrapa様 詳細を教えていただきありがとうございます。 ご提案いただいた通り、HSEがWFI状態に入るまでの間、約1.3秒のタイマーによるタイムアウトを使用する予定です。このタイムアウト期間内にWFIステータスが達成されない場合は、フェイルセーフアクションを実行する予定です。 フェイルセーフ対策として、HSEが今後のリクエストを処理できる適切な状態ではないため、 MCUリセットを検討しています。先に進む前に、以下の点についてご指導いただければ幸いです。 HSE WFIのタイムアウト条件を扱う上で、MCUリセットを行うのが正しい方法でしょうか? リセットが推奨される場合、どのリセットタイプを使用すべきか。 機能リセット（FES）、または 破壊的リセット（DES）？ S32K312アーキテクチャでは、HSEはセキュリティ関連機能を担当する独立したエンジンとして動作します。もしMCUリセットが発行された場合、HSEエンジンもリセットされるのか、それとも独立して動作を続けるのか? 皆様からのご意見は、タイムアウト処理メカニズムが正しくかつ堅牢に実装されることを保証する上で役立ちます。 よろしくお願いいたします。 マヌ・シャルマ Re: HSE [Wait for Interrupt(WFI)] status understanding こんにちは、 @ManuSharma1さん 一般的に、最初のステップは、ビット0が設定されているかどうかを確認するために、0x4039_C028にあるHSE GPRをチェックすることです。リセット後にビット0が「0」の場合、HSEファームウェアは全く存在せず、何らかの致命的なエラーにより完全に消去されています。 HSE GPRのビット0が「1」（HSE FWが存在する）であるにもかかわらず、リセット後もHSE_STATUS_INIT_OKが「0」のままである場合、ハンドシェイク手順を開始する必要があることを意味します。「14.6.7」を参照詳細については、HSE FW RM の「HSE ファームウェア ハンドシェイク」を参照してください。そのセクションで説明されているように、複数の機能リセットを実行する必要があります。 外部リセットは破壊的なリセットを引き起こすため使用できません。ソフトウェアによる機能リセットをトリガーするオプションもあります。こちらの投稿をご覧ください: https://community.nxp.com/t5/S32K/S32K344-How-to-manually-trigger-one-Function-Reset/m-p/1506101/highlight/true#M17079 まとめると： リセット後、0x4039_C028にあるHSE GPRレジスタのビット0を確認します。もし0なら、ファームウェアはすでに消去されているので、再度インストールを試みることができます。値が1の場合は、次のステップに進みます。 FSRレジスタのビットHSE_STATUS_INIT_OKがセットされるまで待機してください。設定されていれば、HSEファームウェアは起動して動作しています。リセット後約1秒以内に設定されない場合（タイムアウトは約1.3秒以上）、機能リセットをトリガーする。 ファームウェアが復旧または消去されるまで、この手順を繰り返してください。消去された場合は、ファームウェアを再インストールする必要があります。 また、AB_SWAPバージョンを使っていて、致命的なエラーでSBAFによってファームウェアが消去された場合、再度インストールする方法は「MUインターフェース経由でインストールする」方法だけです。この場合、IVTやデフォルトロケーションによるインストール方法は機能しません。 詳細については、HSE Firmwareリファレンスマニュアルの「10 Error and Warning マネジメント」セクションをご覧ください。 よろしくお願いいたします。 ルーカス

S32DSはS32G399Aに対してPCFS ClockSourceFrequency = 0を生成します。 こんにちは、 S32 Design Studioでクロック設定を生成すると、MCUコンポーネント(画像添付)が正しい値を示しているにもかかわらず、PCFSのソース周波数が0に設定されていることに気づきました。これにより、無効なレジスタがプログラムされることになる。 「クロック」タブで「Clock_Ip_ _PBcfg.c」のプレビューを見ると、期待値を確認しました。 /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 300000000U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, }, しかし、実際に「コードの更新」でコードを生成すると、次の出力が表示されます。 /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 0U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, }, 800000000Uと300000000Uが0に設定されている点にご注意ください。ファイルの残りの部分は同じです。これらの値が設定されていないため、クロックの立ち上がりが期待どおりに行われず、デバッガーが切断されるという問題が発生しています。生成されたコードを修正して値を元に戻すようにすると、問題なく動作します。 これは既知の問題ですか？ファイルを手動で修正することなく、生成されたコードに値を組み込む方法はありますか？ バージョン: S32 Design Studio 3.6.0(ビルド 3.6.0.202411280511) S32 Configuration Tools 1.8.0(クロック14.0、ペリフェラル15.0) RTD 5.0.0(S32_RTD_5_0_0_D2410)、構成データPlatformSDK_S32XX_4_0_0 S32G399A、CortexM7_0 ありがとうございます! Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A こんにちは、 @cpearson 投稿ありがとうございます。 1.RTD5.0.0については、リリースノートに記載されている通り、S32 Design Studioのアップデートサイトとして提供されています。「S32 Design Studio IDE 3.5 - Update 13」と設定コンポーネントは「S32 Design Studio IDE 3.5 - Update 13」を使って開発されました。問題があるかどうか、S32DS3.5.13以降のバージョンでもテストされたことはありますか? 2. 3.5.13でも問題が表示される場合、トリガーとなる手順について、より詳細な説明をいただけますか？（RTDの既存のサンプルプロジェクト、またはカスタマイズされたプロジェクトなどを用いて）。私はそれを再現して調査するつもりです。 BR チェイン Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A こんにちは、チェンインさん ご返信ありがとうございます。 1. 3.5.13 ではテストしていません。弊社では S32DS 3.6.0 を使用しています。RTD 5.0.0 は 3.6.0 をサポートしていますか？ 3.6.0 のリリースアナウンスによると、サポートされているようです。 2. 3.6.0でも問題を再現できますRTD 5.0.0 サンプルプロジェクト Mcu_Example_S32G399A_M7 を使用 - クロックツールで、クロック構成Config1を選択します。MC_CGM_0_MUX_0で「MCU制御下でPCFS12をクロックする」を有効に設定してください。 - ペリフェラルツールで、Mcu_1 > McuModuleConfiguration > McuClockSettingConfig > 1 > McuCgm0SettingConfig > McuCgm0PcsConfig を選択します。「MCU制御下のMCUクロックPCFS」PCFS_12を確認してください。ソース周波数は800000000と表示されるはずです。 その後、ClocksツールのClock_Ip_PBcfg.cのコードプレビューが表示されます。clock_Cfg_1 PCFSエントリは{ CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U }として表示されるはずです。 「Update Code」を実行した後、generate/src/Clock_Ip_PBcfg.c には clock_Cfg_1 PCFS エントリが { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U } と表示されるはずです。 再現手順についてさらに詳しい説明が必要な場合はお知らせください。 よろしくお願いします、 カーター Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A こんにちは、 @cpearson 詳細な説明をありがとうございます。 こちら側でも同様の現象を確認しましたので、現在調査中です。 最新情報が入り次第、随時お知らせいたします。       BR チェイン

关于 FS2643D 空白 OTP 变体 OTP 编程的查询 您好， 我计划在我的 24 V 应用中使用 FS2643D 型号，特别是 MFS2643HMDA0AD 空白 OTP 型号。 我了解到 KITFS26SKTEVM 插座板可用于 OTP 配置和编程。但是，使用插座板可能会使工作流程复杂化，因为需要将 IC 放入插座中进行编程，然后再将其焊接到目标 PCB 上。 是否有其他方法可以使用外部编程器或目标板直接在目标 PCB 上配置和编程 OTP，而无需 KITFS26SKTEVM 插座板？ 请问这种方法是否可行，并能否推荐一个合适的解决方案？ https://www.nxp.com/part/MFS2643HMDA0AD 谢谢。 Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant 你好，萨克希， 对于原型设计，建议使用插座板、我们的其他硬件和 NXP Ringo GUI 进行基准测试。设计原型板时，请参考 FS26 数据手册和我们的其他文档。尤其是AN12995。 要下载这些机密文件，您需要与 NXP 签订有效的保密协议。如果您还没有保密协议，并且想要签署一份，请在此处创建一个新工单，恩智浦代表将协助您完成该流程。 如果没有 FS26 数据表和其他机密文件，就无法使用 FS26。 一旦您有了原型原理图，我们就可以帮您检查了。请注意，我们不检查布局。或者您可以联系我们的授权代理商，他们有工程师可以帮您检查原理图。 最诚挚的问候， 约瑟夫 Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant 嗨，约瑟夫， 感谢您的反馈。由于我们目前处于原型制作阶段，因此我们的初始产量较低，我们主要专注于台式评估和系统验证。 鉴于目前处于小批量原型阶段，您能否与我们联系，告知我们您建议我们如何进行首批电路板的开发？您建议我们与授权代理商（例如 Arrow 或 Avnet）合作进行小批量编程，还是您建议采用其他途径进行早期基准测试？ 我们希望在开发定制目标原型时，确保符合 NXP 的功能安全和验证准则。 此致， Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant 你好，萨克希， 请注意，我们的评估板和插座板仅设计用于评估我们的元器件，并且推荐用于此用途。只有 NXP 或我们授权的代理商才能对我们的元器件进行 OTP 编程。根据特定元器件的年产量而定。请告知您使用 FS2643D 空白 OTP 变体的项目的年度产量。 我们不允许客户对我们的元器件进行OTP编程。如果客户自行编程，我们不保证这些元器件的安全性和正确性。 最诚挚的问候， 约瑟夫

i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted Hi NXP Community, I am working with the i.MX 8ULP and booting from an SPI NAND flash (Winbond W25N04LW). My understanding is that if FCB0 is corrupted, the Boot ROM should automatically fall back to FCB1. However, when FCB0 is corrupted, the system fails to boot. Specifically, it appears that the Boot ROM does not even attempt to read FCB1. Here are my "SPI NAND boot parameters" Fuse settings: FlexSPI NAND Search Stride : 00 (64 pages) FlexSPI NAND Search Count : 00 (2) FlexSPI NAND CS Interval : 00 (100ns) FlexSPI NAND Column Address Width : 01 (13) All other Fuses are left at their default values. I monitored the SPI communication using a protocol analyzer. Upon power-on, the i.MX 8ULP issues a Page Data Read (13h) to read FCB0 at Page Address 0x000000. Since FCB0 is corrupted, I expected the Boot ROM to read FCB1 at Page Address 0x000040 (based on the 64-page search stride). Instead, it simply attempts to read FCB0 again without trying FCB1. For context, my SPI NAND memory map is as follows: 0x00000000 ┌─────────────────────────────────┐ │ Block 0 : FCB0 │ 0x00040000 ├─────────────────────────────────┤ │ Block 1 : FCB1 │ 0x00080000 ├─────────────────────────────────┤ │ Block 2 : DBBT0 │ 0x000C0000 ├─────────────────────────────────┤ │ Block 3 : DBBT1 │ 0x00100000 ├─────────────────────────────────┤ │ Block 4–15 : Primary firmware │ 0x00400000 ├─────────────────────────────────┤ │ Block 16–31 : Secondary firmware│ 0x00800000 └─────────────────────────────────┘ I tried two different methods to intentionally corrupt FCB0, but the behavior was identical in both cases (FCB1 was never read): Erased Block 0 completely. Modified the FCB fingerprint from 'NFCB' to 'NFC@'. Question: Are there any additional Fuse settings or specific configurations required to enable the fallback mechanism to read FCB1 when FCB0 is corrupted? Thanks in advance for your support. i.MX8ULP Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted As an update, I would like to add a follow-up observation and question. Could it be that if the Boot ROM fails to read a given FCB, it is designed to retry reading that same FCB exactly once before stopping? If this hypothesis is correct, increasing the "FlexSPI NAND Search Count" fuse might resolve the issue by forcing the Boot ROM to search further. Although this is not explicitly detailed in the i.MX 8ULP Reference Manual, the Fusemap for the i.MX 91 (which I believe shares a compatible SPI NAND boot architecture) describes the Search Count as follows: FlexSPI NAND Search Count 00 - 2 01 - 2 10 - 4 11 - 8 Is it correct to assume that this search count specification is identical for the i.MX 8ULP? Any insights would be greatly appreciated. Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted Hi Rita, Thank you for your prompt reply and support! Just to clarify, the issue we are observing occurs purely during the internal Boot ROM execution phase, which is before any BSP or user software is loaded or executed. Because of this, the BSP version should not be a factor in this specific behavior. My core question is strictly about the internal Boot ROM specifications: under what exact conditions does the i.MX 8ULP Boot ROM attempt to read FCB1 when FCB0 is corrupted? Also, as I mentioned in my previous follow-up, could this fallback behavior be tied to the "FlexSPI NAND Search Count" fuse setting, similar to how it works on the i.MX 91? I would greatly appreciate it if you could consult with the Boot ROM engineering team regarding this internal logic. Thanks again for your time and assistance! Best regards, mizo Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted Hi @DaisukeMizobuchi , Which version BSP are you using? Wish you have a nice day Best Regards Rita Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted Hi Rita, Just a gentle follow-up on this thread. Have you had a chance to check with the internal engineering team regarding the Boot ROM fallback behavior and the Search Count fuse? Even if it is still under investigation, any quick update would be greatly appreciated. Thanks, mizo

i.MX95 LPDDR4x READ simulation pass/fail criteria specifically Hi Team for the Processor i.MX95 can i have LPDDR4x Read Timing margins & simulation pass/fail criteria Automotive Industrial

KinetisとLPC用のデバッグインターフェースのおすすめはありますか? 私は主にKinetisシリーズで開発をしており、近い将来LPCのパーツもいくつか手がけるかもしれません。P&E Microのデバッグインターフェースが引き出しいっぱいにあり、よく使っているCyclone ACPも含まれています。 時々、600ドルのCycloneから20ドルのLPC-Link2に切り替えることがあります。なぜなら、CycloneはMCUXpressoに多くの奇妙な問題があるからです。正直なところ、LPC-Link2は私の必要な機能のほとんどを満たしてくれるのですが、少し動作が遅いのが難点です。 Seggerインターフェースを検討しるべきでしょうか?MCUXpresso(そしてできればCodeWarrior 11でも)で十分にサポートされ、クラッシュや走行中のターゲットを止められない信頼性が高く、そこそこ高速なインターフェースを誰かおすすめできませんか?トレースサポートがあれば助かります。 よろしくお願いします！ Re: Debug interface recommendations for Kinetis and LPC? こんにちは、@swetie42 さん。 NXP製品にご関心いただきありがとうございます。 あなたの用途には、MCU-Link Pro Debug Probeを検討してみてください。 標準のCMSIS-DAPファームウェアを使用したMCUXpresso IDEと良好に動作し、ベースのMCU-Linkとは異なり、MCU-Link ProはJ-Link LITEのファームウェアオプションも提供しています。CodeWarriorはJ-Linkをサポートしているため、Kinetisデバイス上でMCUXpresso IDEとCodeWarriorの両方を扱う必要がある場合に役立ちます。 MCU-Link ProはSWOプロファイリングもサポートし、エネルギー測定やアナログ信号監視などの追加機能も提供しています。   もちろん、SEGGERのエコシステムを好む場合や、より高度なデバッグ／トレース機能が必要な場合は、SEGGER J-Linkも良い選択肢です。正確なトレース能力はプローブモデルとターゲットデバイスによって異なります。詳細については、直接Seggerサポートにお問い合わせください:チケット |SEGER - The Embedded Experts(組み込みエキスパート)   つまり、一言で言えば、まずMCU-Link Proを検討する価値があると思います。   お役に立てば幸いです。   BR セレステ

S32K358 MC33FS6523CAE(FS6500 SBC)を用いた電源設計 Hello 私はS32K358を使用して設計しており、MC33FS6523CAEシングルボードコンピュータを使用する予定です。これはサポートされている組み合わせですか？また、S32K3の内蔵SMPSを考慮すると、VDD_HV_A/B、VREFH、V15にはどのSBC出力（VCORE、VCCA）を推奨しますか？ よろしくお願いします。 https://www.nxp.com/products/FS6500?page=9&nrnd=false Re: S32K358 power supply design with MC33FS6523CAE (FS6500 SBC) こんにちは、サクシさん。 MC33FS6523CAEは、S32K358と互換性のあるシングルボードコンピュータです。しかしながら、以下に述べる理由から、S32K358に推奨するコンパニオンSBCはFS26であることを強調しておきたいと思います。 FS26は、S32K3シリーズ(S32K358を含む)向けに設計された専用のセーフティSBC取り付けソリューションです。S32K358デザインに特に関連するいくつかの利点を提供します。 - 専用のドキュメント:AN13850(FS26実装および動作)にはFS26とS32K358の接続に関する明示的なセクションが含まれています。 - ASIL D機能安全保障:FS26ファミリはS32K3搭載のASIL Dアプリケーション向けに特別に開発・検証されており、専用のRTDソフトウェアドライバとセーフティアプリケーションノートの組み合わせが本番環境で利用可能です。 - より高い電流LDO出力：FS26のLDO1とLDO2は、VDD_HV_AとVDD_HV_BをS32K358に直接供給します。当社のFRDM-A-S32K358評価ボードはFS26を伴うSBCとして使用しており、LDO1はVDD_HV_A(+3.3 V)、LDO2はVDD_HV_B(+3.3 V)を供給しています。 - 既製品ソフトウェア:S32K3 + FS26向けの本番対応RTDパッケージが利用可能で、ソフトウェア開発の労力を大幅に削減します。 MC33FS6523CAEは、単一のSBCパッケージに統合されたCAN FD + LINトランシーバが必要な場合、S32K358としてサポートされ機能的なSBCの選択肢として依然として存在します。 BRs、トーマス

DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input Hello NXP Community, I am troubleshooting an ADC offset issue on a board using the DSP56F807PY80E. The following voltages are measured at the device pins: Pins Function Measured voltage 102–109 ANA0–ANA7 inputs 1.60 V 99 and 110 VREF and VREF2 3.20 V 88, 100 and 111 VDDA 3.30 V For a single-ended conversion with no offset correction, I expect approximately 2048 counts, since the input voltage is half the reference voltage: ADC count = (1.60 / 3.20) × 4096 = 2048 However, the ADC readings differ from this expected value. Could someone please advise: Which ADC configuration and offset registers should I check? Could the difference be related to how the ADC result register is read or shifted? What is the recommended procedure to reset or reinitialize the ADC and verify its offset? Any guidance or example initialization code would be appreciated. Thank you for your support. Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input Hello @Hari0369 , Thanks for the detailed information. Your calculation is correct for an ideal 12-bit conversion. With a 1.60 V input and a 3.20 V reference, the expected result is about 2048 counts. The first thing I suggest checking is how the ADC result is read. On the DSP56F807, the 12-bit ADC result is stored in ADRSLT bits 14–3. With no offset applied, 2048 counts would appear as about 0x4000 in the raw ADRSLT register. So please shift the raw result right by 3 bits before comparing it with 2048: ADC value = ADRSLTn >> 3 For your test condition, you should see approximately: Raw ADRSLT value : 0x4000 After >> 3       : 0x0800 = 2048 I also suggest checking the following ADC settings: - Check ADLST1/ADLST2 and make sure the correct analog input is selected. - Check ADCR1.CHNCFG and make sure single-ended operation is selected. - Check ADSDIS and make sure the sample slot you are using is enabled. - Check the corresponding ADOFS register. For this test, please set the offset to 0x0000. - Check ADCR2 and make sure the ADC clock and sampling configuration are correct. - Make sure the ADRSLT register you read matches the sample slot you configured.   For a clean test, I suggest using only one ADC channel. First, stop the ADC and wait until ADSTAT.CIP indicates that the ADC is idle. Then disable the unused sample slots and configure one known channel. Set the corresponding ADOFS register to 0x0000 and enable only the sample slot you want to test. After that, start one conversion and save the raw ADRSLT value. Then shift this value right by 3 bits and compare the result with the expected ADC count.   If the result is still different from expected, could you please send us the following values? - ADCR1 - ADCR2 - ADLST1/ADLST2 - ADSDIS - The corresponding ADOFS value - The raw ADRSLT value These values should help us determine whether the difference comes from the result format, ADC configuration, offset setting, or the analog input path. Hope it helps. BR Celeste Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input Hi @Celeste_Liu, Thank you for sharing the details and troubleshooting suggestions. I have used the same firmware to program approximately 500 DSP controllers. Most units operate as expected, but around 10 units show ADC readings that differ from the expected count under the same test conditions. I understand that the datasheet specifies an ADC offset voltage range of −90 mV to +10 mV, with a typical value of −25 mV. Could you please clarify whether resetting or reinitializing the DSP or ADC could bring the reading closer to the expected 2048 counts at a 1.60 V input and 3.20 V reference? If so, could you please share the recommended procedure? Thank you for your support. Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input Hello @Hari0369 , Thanks for the additional information. Reinitializing the ADC can help rule out an ADC configuration or state issue, but it normally will not change the inherent ADC offset of the device. The datasheet specifies an ADC offset voltage from -90 mV to +10 mV, with -25 mV typical. With VREF = 3.20 V, 1 LSB is approximately 0.781 mV, so some difference from the ideal 2048 counts may be expected. For the affected units, I suggest the following check: Stop the ADC and wait until ADSTAT.CIP indicates that the ADC is idle. Reinitialize the ADC with the same configuration used on the normal units. Make sure the corresponding ADOFS register is set to 0x0000. Perform several conversions and compare the averaged result before and after reinitialization. Repeat the test after a complete power cycle. If the same units consistently show the same offset, please send us the actual ADC counts from one normal unit and one affected unit at 1.60 V input and 3.20 V reference. We can then compare the difference with the ADC specification. BR Celeste

DSP56F807PY80E：在 1.6V 输入电压下，ADC 读数与预期的 2048 个计数不符 NXP社区的各位朋友，大家好！ 我正在排查一块使用DSP56F807PY80E的电路板上的 ADC 偏移问题。在设备引脚上测得的电压如下： 引脚功能测量电压 102–109 ANA0–ANA7 输入 1.60伏 99 和 110 VREF 和 VREF2 3.20伏 88、100 和 111 VDDA 3.30伏 对于没有偏移校正的单端转换，我预计计数约为 2048 ，因为输入电压是参考电压的一半： ADC计数 = (1.60 / 3.20) × 4096 = 2048 然而，ADC读数与预期值有所不同。 请问有人能提供一些建议吗？ 我应该检查哪些ADC配置和偏移寄存器？ 这种差异是否与 ADC 结果寄存器的读取或移位方式有关？ RESET或重新初始化ADC并验证其偏移的推荐步骤是什么？ 任何指导或初始化代码示例都将不胜感激。 感谢您的支持。 Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input 你好@Hari0369 ， 感谢您提供如此详细的信息。 对于理想的 12 位转换，您的计算是正确的。输入电压为 1.60 V，参考电压为 3.20 V，预期结果约为 2048 个计数。 我建议首先检查的是如何读取ADC结果。 在 DSP56F807 上，12 位 ADC 结果存储在 ADRSLT 位 14-3 中。如果没有应用偏移量，2048 个计数在原始 ADRSLT 寄存器中将显示为大约 0x4000。 所以，请先将原始结果右移 3 位，然后再与 2048 进行比较： ADC 值 = ADRSLTn > 3 根据您的测试条件，您应该看到大致如下： 原始 ADRSLT 值：0x4000 之后 > 3 : 0x0800 = 2048 我还建议检查以下ADC设置： - 检查 ADLST1/ADLST2，确保已选择正确的模拟输入。 - 检查 ADCR1.CHNCFG 并确保已选择单端操作。 - 检查 ADSDIS 并确保您使用的采样槽已启用。 - 检查相应的 ADOFS 寄存器。本次测试请将偏移量设置为 0x0000。 - 检查 ADCR2，确保 ADC 时钟和采样配置正确。 - 确保您读取的 ADRSLT 寄存器与您配置的采样槽相匹配。   为了获得清晰的测试结果，我建议只使用一个ADC通道。 首先，停止 ADC，并等待 ADSTAT.CIP 指示 ADC 处于空闲状态。然后禁用未使用的采样槽，并配置一个已知的通道。将相应的 ADOFS 寄存器设置为 0x0000，并仅启用要测试的采样槽。 之后，开始一次转换并保存原始 ADRSLT 值。然后将此值右移 3 位，并将结果与预期的 ADC 计数进行比较。   如果结果仍然与预期不符，请您提供以下数值？ - ADCR1 - ADCR2 - ADLST1/ADLST2 - ADSDIS - 相应的 ADOFS 值 - 原始 ADRSLT 值 这些值应该有助于我们确定差异是来自结果格式、ADC 配置、偏移设置还是模拟输入路径。 希望对您有所帮助。 BR 塞莱斯特 Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input 你好@Celeste_Liu ， 感谢您分享详细信息和故障排除建议。 我使用相同的固件对大约 500 个 DSP 控制器进行了编程。大多数设备运行正常，但约有 10 台设备的 ADC 读数与相同测试条件下的预期计数不同。 据我了解，数据手册规定ADC偏移电压范围为-90 mV至+10 mV，典型值为-25 mV。请问 RESET 或重新初始化 DSP 或 ADC 是否可以使读数更接近在 1.60 V 输入和 3.20 V 参考电压下预期的 2048 个计数？如果可以的话，能否请您分享一下推荐的步骤？ 感谢您的支持。 Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input 你好@Hari0369 ， 感谢您提供的补充信息。 重新初始化 ADC 可以帮助排除 ADC 配置或状态问题，但通常不会改变设备固有的 ADC 偏移。 数据手册规定 ADC 偏移电压范围为 -90 mV 至 +10 mV，典型值为 -25 mV。当 VREF = 3.20 V 时，1 LSB 约为 0.781 mV，因此与理想的 2048 个计数可能会有一些差异。 对于受影响的单元，我建议进行以下检查： 停止 ADC，并等待 ADSTAT.CIP 指示 ADC 处于空闲状态。 使用与正常单元相同的配置重新初始化ADC。 确保相应的 ADOFS 寄存器设置为 0x0000。 执行多次转换，并比较重新初始化前后的平均结果。 完成一次断电重启后，重复测试。 如果同一组设备始终显示相同的偏移，请将一台正常设备和一台受影响设备在 1.60 V 输入和 3.20 V 参考电压下的实际 ADC 计数发送给我们。然后我们可以将该差异与ADC规格进行比较。 BR 塞莱斯特

采用 MC33FS6523CAE (FS6500 SBC) 的 S32K358 电源设计 Hello 我正在使用 S32K358 进行设计，并计划使用 MC33FS6523CAE SBC。这种搭配是否受支持？考虑到S32K3内部采用开关电源，您推荐将VDD_HV_A/B、VREFH和V15分别连接到哪些SBC输出（VCORE、VCCA）？ 谢谢！ https://www.nxp.com/products/FS6500?page=9&nrnd=false Re: S32K358 power supply design with MC33FS6523CAE (FS6500 SBC) 你好，萨克希， MC33FS6523CAE 是与 S32K358 兼容的 SBC。不过，我想强调的是，我们推荐与 S32K358 搭配使用的 SBC 是 FS26，原因如下所述。 FS26 是专为 S32K3 系列（包括 S32K358）设计的功能安全 SBC 连接解决方案。它为S32K358设计提供了一些特别相关的优势： - 专用的参考文档：AN13850（FS26 实现和行为）包含一个专门介绍 FS26 与 S32K358 连接的章节。 -ASIL D 功能安全覆盖范围：FS26 系列专用的 ASIL D 应用而开发和验证，采用 S32K3，并配备专用的 RTD 软件驱动程序和安全应用笔记组合，可随时用于生产。 - 更高电流的 低压差线性稳压器\(LDO\) 输出：FS26 低压差线性稳压器\(LDO\)1 和 LDO2 直接向 S32K358 提供 VDD_HV_A 和 VDD_HV_B。我们的 FRDM-A-S32K358 评估板使用 FS26 作为配套 SBC，其中 LDO1 提供 VDD_HV_A (+3.3 V)，LDO2 提供 VDD_HV_B (+3.3 V)。 - 现成的软件：适用于 S32K3 + FS26 的生产就绪 RTD 软件包已可用，大大减少了软件开发工作量。 如果您需要在单个 SBC 封装中集成 CAN FD + LIN 收发器，MC33FS6523CAE 仍然是 S32K358 的一个受支持且功能齐全的 SBC 选择。 BRs，托马斯