问题：修复 IMX_SEC_ENCLAVE 和释放后使用依赖项。 Hello 这是对 GitHub 上这个 PR的后续跟进。 提供的补丁似乎最终没有应用，因为 lf-6.18.y 中没有这些补丁。 需要 Kconfig 提交来确保当 NVMEM_IMX_OCOTP_SCU 为 m 时 Enclave 驱动程序不能为 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:~# 在提交的第二个版本中，驱动程序进行了一些重构，我不确定NXP是否已经解决了这个问题。 提交 9703dfecc735（“LF-15802：驱动程序：固件：imx：修复 SE 驱动程序移除”） SE团队能否确认一下？ 此致敬礼 弗朗茨 Re: ISSUE: fix dependency for IMX_SEC_ENCLAVE and use-after-free 你好， 我看到这个问题还没有解决，我会和内部软件团队确认一下。 此致敬礼/Saludos， 阿尔多。

FRDM-IMX93:LinuxからLPSPI3レジスタにアクセスできない(devmem読み取り時のバスエラー) — 外部SPIデビック 概要 FRDM-IMX93ボードの P11 EXPIヘッダーに LPSPI3 を使って、2つの外部MCP2515 CANコントローラー(Waveshare 2-CHAN HAT、本物のRaspberry Piで動作確認)を起動しようとしています(GPIO_IO08 UM12181表21参照、Raspberry-Pi互換ヘッダー位置に一致するピンです)。 見つけたデバイスツリーレベルの問題(電源、ピンマックス、チップセレクト、pinctrl-assert-gpio)をすべて修正した後、SPIクロック(SCK)は物理ヘッダーピンを切り替え ず 、LPSPI3ブロックの直接レジスタ読み込みは バスエラーを引き起こします。別の既知の動作ペリフェラル(LPUART1)は同じアドレス空間から問題なく読み返します。これはLinuxデバイスツリーから修正できるものではなく、リソース/バスアクセス制限(RDCなど)を示しています。 ボード/ソフトウェア ボード：FRDM-IMX93（NXP）、SoC：MIMX9352CVVXMAB BSP: NXP i.MX リリース ディストリビューション、カーネル 6.18.2-1.0.0-gf49f45233f7b ターゲット周辺機器:lpspi3(spi@42550000、/aliasesでエイリアスされたspi2、/proc/device-tree/で確認された本物のdtsラベル__symbols__ lpspi3) テスト中の外部デバイス:CS0/CS1上の2× MCP2515(Waveshare 2-CH CAN HAT) 既に動作が確認されているもの（除外されたもの） ヘッダーに電力を供給します。reg_vexp_3v3 / reg_vexp_5v は、デフォルトで無効になっているレギュレータ固定ノードです (regulator_summary では use=0 と表示されています)。レギュレーター常時オン+レギュレーターブートオンを追加し、オーバーレイフラグメントのターゲティング&reg_vexp_3v3/&reg_vexp_5vを追加しました( __symbols__で実際のラベルが確認されました)。その後、P11に3.3V/5Vの電圧が物理的に存在していることを確認しました。 Pinmux。GPIO_IO08-11 は、imx93-pinfunc.h の公式マクロを使用して、LPSPI3_PCS0/SIN/SOUT/SCK に正しく多重化されています。input_reg/input_valはこれら3つの機能に対して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 でメインラインに取り込まれました。2024年9月6.10日は、このカーネルバージョン(6.18.2)よりずっと前のもので、互換文字列(fsl、imx93-spi)はすでにベースボードのdtsに存在しているため、ドライバはこの制限を自動的に適用すべきです。完全に否定できるわけではないが（実際にPRESCALEフィールドが書き込まれたという直接的なレジスタ確認はない）、タイムラインから判断すると既に処理済みである可能性が高い。 実際の症状 CS0/CS1、MISO、MOSI、SCKが物理的なP11ピン(マルチメーター、CS0落ち込みエッジで10〜20 MSa/sのロジックアナライザーをトリガー)でプローブしつつ、転送を繰り返し再試行(ループ内でspidev_testし、Echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bindを経て繰り返しMCP251xの再プローブを強制することで別々に実行しました): CS0の切り替え。マルチメーターとロジックアナライザーの両方で確認済み。 SCKは切り替えません。継続的に転送を試みても、変化はなく、活動は見られない。 MOSIは切り替えません。 両方のMCP2515が同じように失敗します：mcp251x spi2.0/spi2.1：リセット/プローブ失敗後、MCP251xはコンフモードに入らなかった。err=110(ETIMEDOUT)。つまり、ドライバ自身のSPIレベルのリセット+read-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 LPSpi3の機能クロック(per)クロックはenable_count=0と表示されますが、42550000.SPI(実際のバインドされた消費者)がループ内で転送を試みている間も、単に「未使用」ではありません(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デバイスツリーから設定可能なものとは無関係です。 NXPへの質問 FRDM-IMX93 の LPSPI3 は、別のドメイン (例:Cortex-M33 / Secure World)をボードのデフォルトのRDC構成に含めて、追加のSPL/ATF/TF-Aレベルの再構成なしでLinuxからは使えなくなるのでしょうか? もしそうなら、LPSPI3バスアクセスをCortex-A55の非セキュアドメインに再割り当てする方法(U-Boot SPLのRDC設定やOP-TEE/TF-Aの変更)は文書で記載されているのでしょうか?それとも、GPIO_IO08-11が壊れているにもかかわらず、このボードのP11ヘッダーで外部SPIとしては単純にサポートされていないのでしょうか? これは私のボード/カーネルビルド特有の問題でしょうか、それともデフォルトのFRDM-IMX93 BSPの既知の特性でしょうか？参照用の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__経由で存在が確認されています）。 上記で説明したオーバーレイを適用します（レギュレータ常時オン、&lpspi3 上の pinctrl + cs-gpios + pinctrl-assert-gpios）。 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 → バスエラー。 必要であれば、オーバーレイのソースコード、dmesgログ、clk_summary/gpioダンプなど、すべての情報を提供いたします。

S32K358 about Cache operation I am writing an S32K358 program in S32DS. To create an OTA upgrade program, I need to manipulate the internal FLASH. When I call the above function, I can compile it successfully, but I cannot find the above function by pressing CTRL+left mouse button. Is this normal? Screenshot 2026-09-15 141928.png Screenshot 2026-09-15 141953.png Re: S32K358 about Cache operation Hi @sunshine88, Can you try rebuilding the index? danielmartynek_0-1789469464382.pngdanielmartynek_0-1789469464382.png Thank you, BR, Daniel

S32K358 キャッシュ操作について 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、ダニエル

S32K312用RTDの取り付け 私はS32K312のために、S32 Design Studio v 3.6.6 で以下の開発環境を設定しようとしています。 1. SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip をダウンロードしました。 2. S32 Design Studio 3.6.6で「S32拡張とアップデート」を開いたWindows 11で動作し、S32K3のリアルタイム・ドライバをインストールしました(示す通り): durga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.png 3. IDEを再起動するよう促されたら(PCの再起動も試しました) これではK3ファミリのサポートが見当たりません。「新規プロジェクト」ダイアログには、このオプションは表示されません。 durga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.png 下記のように「S32K3XX」ドライバーをインストールしようとすると: durga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.png 以下のようなエラーが表示されます。 durga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.png この一連のプロセスをS32DS v.6.2で繰り返すと少し改善されました。「新しいプロジェクト」ダイアログにK312のオプションが表示されていますが、SDKは表示されていません。 durga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.png 私は何が間違っているのでしょうか？ Re: Installing RTD for S32K312 こんにちは、 @VaneBさん 残念ながら、S32DS 3.6.6 には同等の機能がありません。また、RTDのバージョンを7.0.1から6.0.0にダウングレードしてみました。 3.6.6で動作する特定のバージョンはありますか？ Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん このスクリーンショットは私のS32DS 3.6.10のものです。インストール;しかし、あなたのIDEでも同様のセットアップが見られるはずです。 VaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.png また、あなたが共有してくれたスクリーンショットを見る限り、RTD 7.0.1をインストールできているのがわかります。RTD 7.0.1はS32K3開発パッケージに依存しているため、すでにそのパッケージがインストールされている可能性が高いです。 Re: Installing RTD for S32K312 こんにちは、 @VaneBさん あなたのコメントについて、もう少し詳しく説明してください。 S32K1xx用の「開発パッケージ」がインストールされているのを確認しました(これも私が使っているMCUファミリです): durga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.png しかし、K3には同様のものは見当たらない。 では、どうやってインストールすればいいのでしょうか?繰り返しますが、これまでに私がやったことは以下の通りです: 1. SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip をダウンロードしました 2. S32 DS v 3.6.6にアップデートサイトとして追加しました。 3. 以下のものをインストールしました。 durga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.png Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん S32DS 3.6.6からインストール時には、S32K3開発パッケージがインストールされていないようです。 S32DS 3.6.2に関して、RTD 7.0.1はS32DS 3.6.4を使用して開発および検証されたことにご注意ください。したがって、S32DS 3.6.4 の使用をお勧めします。または、互換性を確保し、潜在的な問題を回避するために、より新しいリリースを使用してください。 他に確認すべき点として、ツールチェーンが挙げられます。プロジェクトを作成する際は、NXP GCC 10.2.0がインストールされ、プロジェクトツールチェーンとして選択されていることを確認してください。 BR、VaneB Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん 私の環境では、RTD 7.0.0を使用しています。S32DS 3.6.6と共にインストールされました。しかし、前述のとおり、これらのバージョン間でセットアップ方法が非常に似ているため、RTD 7.0.1は問題なく動作するはずです。 設置の詳細を教えていただけますか? Re: Installing RTD for S32K312 こんにちは、 @VaneBさん サポートありがとうございます。URLをもう一度確認してもらえますか?この方法でアップデートしようとすると、S32 DS から次のようなエラーが発生します。 durga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.png 例えば、RESTタイプのアプリケーションでアクセスしようとすると、wgetを実行すると、HTTPエラー404（見つかりません）が発生します。 それはNXP内部の問題かもしれません(つまり、（公開サーバーではない）？ Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん 以下の方法を試していただけますか?S32DSでは「新しいソフトウェアをインストールする→ヘルプ」へ行きます...これによりインストールウィンドウが開きます。「作業対象:」フィールドに、次の更新サイトを入力します。 https://www.nxp.com/lgfiles/updates/Eclipse/S32DS_3.6 利用可能なアップデートの一覧が、以下に示すような形で表示されます。リストにS32 Design Studio S32K3xx開発パッケージが見つかるか確認し、インストールを試してみてください。 VaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.png パッケージが表示されなかったりインストールが失敗した場合は、最新のS32DSバージョンへのアップデートをおすすめします。現在のインストール環境に一部のコンポーネントが不足しているか、インストール／アップデート中に何らかの破損が発生した可能性があります。 Re: Installing RTD for S32K312 こんにちは、 @VaneBさん 以下に、私が試した2つのファイルを示します（どちらも同じ問題が発生しました）。 durga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.png S32DSに関する情報は以下のとおりです。 durga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.png 以下に、インストール手順の詳細を、1枚のスクリーンショットに収まる範囲で示します。他に何か情報が必要ですか？ durga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.png Re: Installing RTD for S32K312 こんにちは、 @VaneBさん 残念ながら、私の環境では動作しません。 durga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.png Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん 提供されたリンクは通常のウェブアドレスではないことにご注意ください。これはS32DSが利用可能なソフトウェアパッケージやアップデートにアクセスするためのアップデートサイトに対応しています。 更新サイトの完全なリストを表示するには、S32DS拡張機能と更新ウィンドウを開き、「サイトの管理」を選択します。そこにはIDEが認識するすべての更新サイトが見つかります。 Re: Installing RTD for S32K312 こんにちは、 @durga_choudhuryさん 別のマシンでテストしていただけますか? また、アップデートサイトへのアクセスを妨げるファイアウォールやプロキシ、セキュリティポリシーがないかITチームに確認する価値があります。 Re: Installing RTD for S32K312 これは確かに、当社のプロキシサーバーに何らかの問題があるようです。企業ネットワーク外のコンピュータで動作します。 サポートありがとうございます。

KW45：编程/调试期间间歇性线路确认故障和闪存擦除失败 大家好， 我目前正在使用基于 KW45 的定制板，在固件编程和调试过程中遇到了间歇性问题。 我分别使用 SEGGER J-Link 和 NXP MCU-Link 调试探针测试了该电路板，两种探针都出现了该问题。 定制板的启动配置与 KW45 EVK 相同，JTAG/SWD 连接也已检查，看起来是正确的。 然而，我发现出现了以下情况： 当我尝试转储或编程一个已知可以正常运行的应用程序时： 有时应用程序编程成功，但在编程或启动调试会话后，设备最终会跳转到故障地址。 调试器随后在该位置停止。 在某些编程或转储尝试过程中，我收到 Wire ACK 故障。 MCUXpresso 在其他时候报道： 执行 MI 命令时出错 我还尝试使用 MCUXpresso 擦除闪存，但闪存擦除操作本身并未成功完成。 已执行的检查 已检查 JTAG/SWD 连接，连接似乎正常。 我们使用 SEGGER J-Link 和 NXP MCU-Link 调试探针测试了该问题。 已将启动配置与 KW45 EVK 进行了比较。 我使用一个已知可以正常运行的应用程序进行测试。 该问题是间歇性的：有时编程成功，但有时会出现 Wire ACK 故障或 MI 命令错误。 也尝试过闪存擦除，但未能成功完成。 我的问题 什么原因会导致 KW45 在转储或编程代码时间歇性地报告 Wire ACK 故障？ 执行 MI 命令时出错？ 编程后跳转到或停止在意外或无效的内存地址？ 即使尝试完全擦除闪存也失败了吗？ 由于该问题包括间歇性 Wire ACK 故障和闪存擦除期间的故障，我怀疑这可能与调试接口、SWD/JTAG 信号完整性、电源稳定性、RESET 序列、闪存控制器状态、设备安全/配置、启动配置或其他硬件级问题有关，而不是应用程序本身的问题。 请问您能否提供以下方面的推荐操作流程： 恢复或擦除 KW45 设备。 确认调试接口功能正常。 检查设备是否已锁定或处于阻止正常编程的状态。 确定 Wire ACK 故障是由目标硬件、调试探针、电源/复位行为还是 SWD/JTAG 信号完整性引起的。 如有需要，我可以提供以下信息： MCUXpresso IDE 版本：25.6.1 测试的调试探针：SEGGER J-Link 和 NXP MCU-Link 完整的错误日志，包括 Wire ACK 故障详情。 调试控制台输出 JTAG/SWD 和启动连接示意图 SWD/JTAG时钟频率 电源和 RESET 配置 来自故障状态的内存/寄存器信息 非常感谢您能提供任何故障排除步骤方面的指导。 先行致谢。 Re: KW45: Intermittent Wire ACK Fault During Programming/Debugging and Flash Erase Failure 你好，希望你一切都好。   首先，请您确认一下您定制主板的一些硬件细节： BOOT_CFG (PTA4) 网络是否有下拉电阻连接到 GND？VDD_SYS 和 VDD_CORE 去耦电容是否已安装？因为这些是提供反馈通路并维持内部稳压器输出电压稳定性所必需的。   要尝试恢复设备，请尝试以下步骤： 您能否通过 ISP 模式访问您的设备？为此，在 RESET 期间将 BOOT_CONFIG (PTA4) 拉高，以强制设备进入 ISP 模式（在 KW47-EVK 上，这是 SW4）。 进入ISP模式后，打开命令提示符并运行以下命令： # Confirms ROM bootloader communication is working, a successful response confirms the device is reachable via ISP blhost.exe -p COMX get-property 1 # Reveals whether the device is in OEM_OPEN or a secured lifecycle state blhost.exe -p COMX get-property 07 # Perform a mass erase of the CM33 and NBU Program Flash blhost.exe -p COMX flash-erase-all blhost.exe -p COMX flash-erase-all 2 之后，您可以尝试运行 hello_world 或 BLE 示例，以确保电路板正常工作。 另外，请确认一下，您之前运行的是哪个应用程序？你有没有用低功耗的例子进行测试？设备也可能进入了低功耗状态，在低功耗运行期间禁用了SWD调试接口，这将导致LinkServer或J-Link无法正常连接。 此致， 索菲亚。 Re: KW45: Intermittent Wire ACK Fault During Programming/Debugging and Flash Erase Failure 您好，女士。 感谢您的详细回复。 关于硬件细节： BOOT_CFG (PTA4) 下拉：是的，我们定制的板上的 BOOT_CFG (PTA4) 网络有一个下拉电阻连接到 GND。 VDD_SYS 和 VDD_CORE 去耦电容：是的，所需的去耦电容已安装在板上。我已附上相关的原理图部分/图像，显示了VDD_SYS 和 VDD_CORE 的连接以及去耦电容。 同时，我将按照您建议的步骤，通过ISP 模式访问设备，并尝试使用 blhost 命令检查设备状态并执行批量擦除。 关于之前运行的应用程序： 该应用程序基于FreeRTOS ，并集成了以下外设/模块： FreeRTOS LPSPI0 带 DMA 通用IO LPSPI1 带 FIFO WDOG 关于低功耗问题，我在应用中并没有特意使用任何具体的低功耗示例。 我将执行 ISP 恢复程序，并告知您结果，特别是以下方面： 获取属性 1 获取属性 07 全部擦除 全部擦除 2 如果您建议在进行这些测试时进行任何其他硬件检查或测量，请告诉我。 Prashanth1_0-1789454497591.png普拉山斯1_0-1789454497591.png Prashanth1_1-1789454501864.pngPrashanth1_1-1789454501864.png 再次感谢您的支持。 此致， 普拉桑特

Does NXP official have a code routine for configuring external boot for S32K344 chip? Does NXP official have a code routine and tutorial for configuring external boot for S32K344 chip? We would like to configure the chip to boot from the SD card？ Re: Does NXP official have a code routine for configuring external boot for S32K344 chip? In a nonsecure boot configuration - does the first bootloader run from ROM (is it immutable)? Can this first bootloader be configured to boot the subsequent bootloaders/application images from an external source/flash? Re: Does NXP official have a code routine for configuring external boot for S32K344 chip? This device does not offer an option to boot from external memory. Device supports secure and nonsecure boot modes but in both cases it is internal flash boot.

S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on specific Device: S32K312 Toolchain: Green Hills ELXR (compiler) HSE Firmware: s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin Debugger: Lauterbach TRACE32 Software: AUTOSAR RTD-based Bootloader (FBL) + Application (APP), two-image structure ISSUE SUMMARY On a subset of production units, the CPU hangs immediately after a Functional (software) reset. The same units always boot correctly after a Destructive (power-on) reset. The hang does not reproduce on our reference/known-good units. EVIDENCE THAT AN NMI OCCURS BEFORE ANY APPLICATION CODE EXECUTES 1) CPU context captured at the hang point (auto-stacked exception frame): - R0-R3 = 0x00000000, R12 = 0x00000000 - LR = 0xFFFFFFFF (reset default -> no BL has executed yet) - PC = 0x00416904 (the very first instruction address of our Reset_Handler) - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - VECTACTIVE[8:0] = 2 -> NMI is the currently active exception - RETTOBASE = 1 This confirms the CPU is currently executing inside the NMI handler. 3) Our vector table entry for the NMI offset correctly points to our own default exception handler, so this is a genuine NMI event, not vector table corruption. REGISTERS CHECKED AT THE SAME HANG STATE (all read as clean / inactive) - MC_RGM_DES = 0x00000000 (not a destructive reset) - MC_RGM_FES = 0x20000000 (bit 29 only) (only "software functional reset" flag set, no other functional reset source flagged) - FCCU: STAT, N2AF_STATUS, A2FF_STATUS, N2FF_STATUS, NCF_S0, IRQ_STAT all = 0x00000000 - CMU_FC instances 0, 3, 4: SR = 0x00000000 (no frequency high/low fault) - PMC LVSC = 0x00000000 (no LVD/HVD flag, latched or live) - ERM (0x4025C000): could not be read on either good or failing units (likely clock-gated in our configuration), so ERM status is unverified. QUESTIONS 1. Are there any NMI sources -- other than FCCU / CMU_FC / PMC / MC_RGM -- that could fire before the application's Reset_Handler executes its first instruction? 2. Since the HSE subsystem runs independently of the application core, is it possible for an application-core Functional reset (which does not reset HSE) to create a state mismatch that triggers an NMI on the application core? 3. Is there a known errata for S32K312 matching this symptom (NMI only on functional/software reset, never on power-on reset)? Any guidance on additional registers to check, or documentation covering NMI sources outside FCCU / ERM / CMU_FC / PMC, would be greatly appreciated. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Could you please read registers MU_0.MUB CSSR0 and MU_1.MUB CSSR0 at the hang state, and confirm whether bit 0 (NMIC) is set in either of them? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to MU_0.MUB / MU_1.MUB CSSR0. CSSR0 (bit 0, NMIC) on both MU_0.MUB and MU_1.MUB reads 0x00000000 on the failing unit at the hang state, so the MU->NMI request path (CCR0[NMI] / CSSR0[NMIC]) does not appear to be pending. However, while comparing MU registers between a known-good unit and a failing unit (both captured at the identical hang-state address range), we found a consistent difference:                                Good unit Failing unit MU_0.MUB VER 0x0300000F 0x0300000F (identical) MU_0.MUB PAR 0x20200404 0x20200404 (identical) MU_0.MUB CR 0x00000000 0x00000000 (identical) MU_0.MUB SR 0x00000000 0x00000002 <- MURIP set MU_1.MUB VER/PAR/CR: identical between good and failing units MU_1.MUB SR 0x00000000 0x00000002 <- MURIP set So on BOTH MU instances, SR bit 1 (MURIP) is set only on the failing unit, consistently. Per the reference manual, MURIP indicates that "processor A" has issued an MU reset, and can only be cleared by a system reset (not by an MU reset). Since the CPU is frozen inside the NMI handler before executing any application code, it could not have cleared this flag itself, so it must have been set prior to (or as part of) this boot sequence. We'd appreciate your input on the following: 1. For MU_0.MUB and MU_1.MUB, which processor is "processor A" (i.e. who sets MURIP)? Our header only exposes the "MUB" register block at the application-core-accessible address -- does this imply the application core is always "processor B" and HSE is "processor A" for these instances? 2. Does "system reset" (required to clear MURIP) include a Functional/SW reset of the application core, or only a Destructive/POR reset? If MURIP is not cleared by our functional reset, that would explain why it stays set across SW reset while it is clear after power-on. 3. Independent of the NMI question: is a set/stuck MURIP flag itself expected or considered anomalous during normal operation? 4. Since CSSR0[NMIC] currently reads 0, is it possible for hardware to auto-clear NMIC upon NMI exception entry, or does it only clear via an explicit software write (in which case NMIC=0 would mean the MU->NMI channel was never asserted in the first place)? Thanks again for your help so far. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, I'm sorry for the delay. I was out of office for two days. 1. Yes, the HSE_B core controls the MUA interfaces of MU_0 and MU_1. 2. Any system reset should reset MURIP. 3. I would consider this an anomaly, as I do not have much information about it. 4. It requires an explicit write, as it is a W1C register. Can you make sure that HSE_B is inactive at the time the functional reset is triggered? Also, what is the state of HSE_B while the application is stuck in the NMI handler? Can you read the standard HSE GPR (0x4039_C028), FSR, and GSR registers on the MU_0 B side? Do you use the NMI pin in the application? Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi Daniel, Please find three combined register-dump screenshots attached, followed by our findings organized by your questions. -------------------------------------------------------- ATTACHMENTS -------------------------------------------------------- Attachment 1: GOOD unit (Secure Debug enabled, running normally) Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png Attachment 2: FAILING unit, immediately BEFORE the functional reset is triggered (normal operation) Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png Attachment 3: FAILING unit, AFTER the functional reset, stuck in the NMI handler (hang state) Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- FINDINGS 1) HSE_B activity at the time the functional reset is triggered, and 2) state of HSE_B while stuck in the NMI handler: Comparing Attachment 2 (before reset) and Attachment 3 (after reset, hang state) on the failing unit, every register we checked reads IDENTICALLY before and after the reset: - MU_0.MUB / MU_1.MUB TSR = 0x0000000F, RSR = 0x00000000 (no pending messages on transmit/receive channels, unchanged by the reset) - MU_0.MUB GSR = 0x00000000 (unchanged) - MU_0.MUB FSR = 0x03600000 (unchanged) - HSE GPR (0x4039C028) = 0x000001C1 (unchanged) - MU_0.MUB / MU_1.MUB SR bit 1 (MURIP) = 0x00000002 -- already set BEFORE the reset is triggered, and remains set, unchanged, after the reset So MURIP was already set prior to this reset cycle, and the functional reset itself does not change any of these HSE-related registers. For reference, on a good unit with the same Secure Debug configuration (Attachment 1), MURIP reads 0x00000000 on both MU_0.MUB and MU_1.MUB, while HSE GPR and WKPU NCR read the same values as the failing unit. 3) Regarding whether a set/stuck MURIP is anomalous: Understood, thank you for confirming. 4) NMI pin usage: We do not use the WKPU-routed NMI path (WKPU_IP_USED is not enabled; no WKPU driver code is compiled into either our bootloader or application image). WKPU NCR (0x402B4008) = 0x60000000 identically across all three attachments. NSR = 0x00000000 in all cases. Since this is unchanged across all units and conditions, we don't believe an external/WKPU-routed NMI source is involved. SUMMARY OF FINDINGS SO FAR MURIP (MU_0.MUB and MU_1.MUB SR bit 1) is already set on the failing unit BEFORE the functional reset is even triggered, and remains unchanged throughout the hang. It reads 0 on a good unit with the same Secure Debug configuration. This is the only consistent, reproducible difference we have found across every register we've compared (FCCU, CMU_FC, PMC, WKPU, and MU CSSR0/GSR/TSR/RSR/GPR/FSR). Since MURIP is set by "processor A" (HSE_B) and should be cleared by "any system reset" per your answer, and since it is already set before our functional reset is triggered (and the reset itself does not appear to change it), this suggests HSE_B issued an MU reset at some earlier point that was never cleared by a "system reset" recognized by HSE_B. QUESTIONS 1. Is there a way to determine, from the HSE side, what would cause HSE_B (processor A) to issue an MU reset in the first place? We'd like to understand why MURIP gets set at all. 2. Is there a recommended way for us to trigger a reset that HSE_B recognizes as a "system reset" (to clear MURIP) from application software, short of a full power cycle? 3. Could a stuck MURIP flag on the application-core side be related to the NMI we are observing, or are these more likely two independent symptoms of the same earlier event? Thanks again for your continued help with this. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thank you for the detailed register dumps. I have escalated the questions around MURIP behavior and the potential NMI path between HSE_B and CM7_0 to our internal HSE team, as this seems to be not documented. I will get back to you once I have their input. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek,  Thank you for the update, and for escalating the MURIP / NMI path question to your internal HSE team. We appreciate it, and we'll wait for their input. In the meantime, we found an additional data point that may be relevant, so we wanted to share it now rather than wait. While comparing OTP fields in the UTEST Flash area between a good unit and a failing unit, we found a difference in the Lifecycle slots. CUST_DEL (0x1B000220-22F) and OEM_PROD (0x1B000230-23F) are identically programmed (0x55AA50AF across all words) on both the good unit and the failing unit. The difference is in the IN_FIELD slot (0x1B000240-24F): - Good unit: begins being programmed Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - Failing unit: reads as unprogrammed (0xFFFFFFFF) Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png We are still double-checking the exact byte pattern within the IN_FIELD slot on our side, but the good/failing difference at this slot appears consistent. Could you clarify: 1. Does this suggest that the failing unit's configuration became corrupted or incomplete partway through the transition into IN_FIELD? 2. Could an incomplete or missing lifecycle advancement to IN_FIELD explain the NMI/hang behavior we have been investigating in this thread? 3. Is there a safe way to check or complete this lifecycle advancement on the failing units, without a full production re-flow? Thanks again for your help. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Based on the memory view, OEM_PROD = Inactive, IN_FIELD = Erased. Can you please first read the DCM registers: RM, rev.12, Section 39.3.1 DCM memory map. And Section 38.2.3 Read-Only GPR On Destructive Reset 3 (DCMROD3)? You can also use the HSE_FW APIs to get the LC attribute? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to the DCM memory map and DCMROD3. We captured DCMSTAT (0h), DCMLCS (8h), DCMLCS_2 (80h), and DCMROD3 (208h) on both units, and decoded them against RM rev.9. ---------------------------------------------------- CAPTURED VALUES ---------------------------------------------------- Good unit: Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 Failing unit: Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - DCMSTAT (0h) = 0x00000E03 - DCMLCS (8h) = 0x06184104 - DCMLCS_2 (80h) = 0x00000006 - DCMROD3 (208h) = 0x00400000 ---------------------------------------------------- DECODED FIELDS (FAILING UNIT ONLY, since good unit reads all-zero) ---------------------------------------------------- DCMSTAT: - bit1 DCMERR = 1 (DCM completed with error) -- good unit has this bit = 0 - bit4 DCMLCST = 0 (LC scanning status not "completed successfully") -- good unit has this bit = 1 DCMLCS: - bits 21-19 DCMLCC4 (IN_FIELD Marking) = 011b = "Region is erased/virgin" - bits 15-13 DCMLCC3 (OEM_PROD Marking) = 010b = "Marked as inactive" - bits 27-25 DCMLCC5 (Pre-FA Marking) = 011b = "erased/virgin" - All associated *_ECE/*_CFE/*_CSS bits = 0. DCMLCS_2: - bits 3-1 DCMLCC6 (FA Marking) = 011b = "erased/virgin" DCMROD3: - bit22 LC_ERR = 1 ("Error In Life Cycle Scanning") This is consistent with the UTEST OTP dump we shared earlier: the IN_FIELD slot on the failing unit reads as erased/virgin. ---------------------------------------------------- HSE_FW API RESULT (HseReadLifecycle) ON THE FAILING UNIT ---------------------------------------------------- HseReadLifecycle() returns 0x10 = HSE_LC_IN_FIELD. So from the HSE firmware's point of view, the current lifecycle is already IN_FIELD. This appears to conflict with the DCM/OTP data above: DCM's DCMLCC4 field reads IN_FIELD marking as "erased/virgin," and the UTEST OTP IN_FIELD slot (0x1B000240h onward) reads as unprogrammed (0xFFFFFFFF), yet the HSE API reports the lifecycle as confirmed IN_FIELD. We wanted to share this as-is rather than draw a conclusion, since we don't know whether HSE tracks lifecycle through a separate/secure store independent of the DCM flash marking, or whether this indicates the marking itself is the problem. Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thanks for the data. Since the IN_FIELD slot is still in the erased state, could you try setting the attribute again to advance it? As I mentioned, the case is currently under internal discussion. I will update this thread as soon as I have any new information. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Probably the HSE service responsible for advancing the Life Cycle (LC) was interrupted, leaving the LC in this state. The LC and LC Control (DCMLCC) register reports 0x77 (IN_FIELD) as the HSE_FW does, but the UTEST area is not programmed correctly. In theory, you could program the UTEST IN_FIELD slot using a debugger, which should clear the DCM error.  Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek  We tried setting the IN_FIELD attribute again on the failing unit, as suggested. Result: HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek  Thank you for the suggestion to program the UTEST IN_FIELD slot using a debugger. We checked our internal OTP field reference table, and the IN_FIELD lifecycle slot (1B00_0240-024F) is listed as write-protected for any master except HSE once LC > MCU_PROD (OEM_PROD). Since HseReadLifecycle() on this unit already reports IN_FIELD, this LC condition appears to already be met. Could you clarify how a debugger write to this slot would be expected to succeed under this protection rule? Is there a specific procedure, mode, or authentication step required for the debugger to be treated as an allowed master in this case? Separately, do you have any findings yet on why the LC advancement to IN_FIELD was left in this partial state in the first place? We'd like to understand the root cause, not just the recovery step, if that analysis is available. Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Thank you for the information. It seems there is no option to recover the MCU at this point. One possibility is that the HSE set attribute service request to advance the LC was interrupted by a system reset (I understand the LC was not advanced using the LCW within the IVT).: Do you read the HSE response of the service request? Do you log whether there was an error? Before triggering the service, do you verify that HSE_STATUS_INIT_OK is set? How many boards/MCUs are affected by this issue? Is it limited to a few units, or have you observed it across a larger number of devices? Thank you, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Do you have any update? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Apologies for the delayed response, and thank you for the questions. Here are our answers: 1. For the LC advance sequence, we read the HSE service responses (from the DebugAuth, AdvanceLifecycle, and ReadLifecycle calls) and use them to determine an overall success/fail status. We don't log which specific call failed or the individual error code -- only the overall OK/FAIL result exists, and it is not persisted anywhere. So we have no record of what happened during the original LC advancement on these units. 2. Neither our LC-update function nor its caller explicitly checks HSE_STATUS_INIT_OK before triggering the AdvanceLifecycle service. We check HSE_STATUS_INIT_OK once at the beginning of our download flow, by reading the MU_0.MUB FSR register (0x4038C104) and deriving hseStatus_t from it (mask/shift on FSR bits 16-31, as done in Hse_Ip_GetHseStatus). This check is not repeated before the lifecycle advancement step later in the flow. For additional context, our production equipment log for the failing units shows the following sequence: FSR check completed (OK) -> App download -> Secure Debug Enable -> FAIL Note that "Secure Debug Enable" in our equipment log refers to the entire procedure that includes the LC advancement (DebugAuth, AdvanceLifecycle, and ReadLifecycle together) -- it's logged as a single pass/fail step, so we cannot tell from this log which of the sub-steps actually failed. Our debug equipment (TRACE32) has checked HSE_STATUS_INIT_OK as part of our existing debug flow, but our download/programming equipment (production line) may not have consistently checked this at the point in the sequence where the LC advancement is triggered. Regarding the number of affected units: we currently have 2 boards/MCUs showing this issue. We also have two follow-up questions: - Is reading the FSR register and deriving hseStatus_t from it this way a valid/recommended way to check HSE_STATUS_INIT_OK? - We currently check HSE_STATUS_INIT_OK once at the beginning of our download flow, via this register read. Should it also be checked specifically before triggering the lifecycle advancement? Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , I hope you're doing well. I wanted to check in and see if there have been any updates on this thread. We'd appreciate any guidance you can share when you get a chance. Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Apologies for the delay — I have been waiting for feedback from the HSE team, but have not received a clear explanation for the NMI. The LC_ERR flag in DCMROD3: it can trigger an NMI only if FCCU NCF 3 is configured to generate one. To your questions: Yes, that is correct. The HSE_STATUS_INIT_OK flag should be checked after any system reset. The application must wait for this flag before changing system clocks or using any HSE service. Once set, it remains set. The application can additionally poll the WFI flag of the HSE_B core (PRTN0_CORE2_STAT[WFI]) to determine whether the HSE_B is busy or idle. On the topic of the interrupted LC advancement — there is one more possible root cause worth investigating. Changing the lifecycle modifies the contents of the UTEST flash, and the UTEST flash resides in the same RWW (Read-While-Write) partition as Code Flash Block 0. If any code is executing from Block 0 during the UTEST write, an RWW error will occur and can prevent the lifecycle change from completing successfully. To avoid this, the application must ensure there is no concurrent access to Block 0 while the LC advancement service is in progress. Note that the cache may mask this issue in most cases, but in certain corner cases, particularly when the application uses a non-synchronized event, it can result in a cache miss, making the problem visible. Regards, Daniel

GUI Guider 1.10.1 では、背景の不透明度が 0 の場合、背景スタイルのプロパティが省略されます。 環境 GUI Guider: 1.10.1 LVGL: 8.3 ウィジェット: ボタン スタイルパーツ: LV_PART_MAIN スタイル状態: LV_STATE_DEFAULT 問題の説明 GUI Guider 1.10.1 で再現可能なコード生成の問題を発見しました。 ボタンに背景色が設定されているにもかかわらず、背景の不透明度が0に設定されている場合、GUI Guiderは対応する背景色プロパティを生成しません。 実行時に背景の透明度を動的に変更すると、予期しない動作が発生します。 再生 ボタンを作成して設定します。 背景色：#F08300 背景の不透明度: 0 次に、LVGL 8.3コードを生成します。 GUI Guider が生成するもの: lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 0、 LV_PART_MAIN | LV_STATE_DEFAULT); しかし、設定した背景色は生成されません。 lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); テスト：背景の不透明度のみを0から1に変更する 背景色の#F08300はそのままに、背景の不透明度だけを0から1に変更しました。 コードを再生成した後、GUI Guiderは以下を生成します。 lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 1、 LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_grad_dir(ui->screen_password_btn_15, LV_GRAD_DIR_NONE、 LV_PART_MAIN | LV_STATE_DEFAULT); したがって、生成されるコードは、背景の不透明度が正確に0であるかどうかによって異なります。 背景の不透明度 = 0: bg_opaが生成されます bg_color は生成されません 背景の不透明度 = 1: bg_opaが生成されます bg_color が生成されます その他の背景プロパティも生成されます 実行時への影響 私のアプリケーションは背景の不透明度を使って現在選択されているパスワード番号を示します。 背景色はGUI Guiderで #F08300 として設定され、アプリケーションは背景の不透明度のみを動的に変更します。 例： lv_obj_set_style_bg_opa(btn, LV_OPA_COVER、 LV_PART_MAIN | LV_STATE_DEFAULT); 初期の背景不透明度が0のボタンの場合、生成されるコードには設定された背景色が含まれません。 アプリケーションが不透明度を0からLV_OPA_COVERに変更すると、ボタンはGUI Guiderで設定された #F08300 色の代わりにLVGLテーマまたはデフォルトの背景色を表示します。 その動作は以下のとおりです。 GUI Guiderの設定： 背景色 = #F08300 背景の不透明度 = 0 生成されたコード: bg_opa = 0 bg_color は生成されません ランタイム： bg_opa が LV_OPA_COVER に変更されました 結果： #F08300の代わりに、デフォルトまたはテーマの背景色が表示されます。 応急措置 アプリケーションコード内で背景色を明示的に設定すると、以下の問題が解決します。 lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300) LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER、 LV_PART_MAIN | LV_STATE_DEFAULT); 別の回避策としては、GUI Guiderで背景の不透明度を1に設定する方法があります。これにより、GUI Guiderは設定された背景色を生成するようになります。 しかし、これは初期のUI状態を変更してしまうため、理想的とは言えません。 期待される動作 背景色と背景の不透明度は、それぞれ独立したLVGLスタイルプロパティです。 ユーザーが明示的に以下を設定する場合: 背景色 = #F08300 背景の不透明度 = 0 GUI Guiderは、生成されたコードにおいて両方のプロパティを保持するはずです。 lv_obj_set_style_bg_opa(btn, 0、 LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300)、 LV_PART_MAIN |LV_STATE_DEFAULT); bg_color bg_opa が0のときは目に見える影響はありませんが、アプリケーションが実行時に動的にbg_opaが変化すると重要になります。 現在のコード生成動作では、GUI Guiderで設定された背景色情報が失われます。 実際の行動 GUI Guider 1.10.1 では、背景の不透明度が 0 の場合、背景スタイルのプロパティが省略されるようです。 不透明度を0から1に変更するだけで、背景色やその他の背景プロパティが再生成されます。 再現手順 GUI Guider 1.10.1 でボタンを作成する。 背景色を#F08300に設定してください。 背景の不透明度を0に設定してください。 LVGL 8.3コードを生成します。 値0のlv_obj_set_style_bg_opaが生成されていることを確認してください。 #F08300 を指定した lv_obj_set_style_bg_color は生成されないことに注意してください。 背景の不透明度のみを0から1に変更してください。 コードを再度生成してください。 #F08300 を指定した lv_obj_set_style_bg_color が生成されていることを確認してください。 実行時に、元のボタンの不透明度をLV_OPA_COVERに変更します。 設定された背景色は、アプリケーションが明示的に設定しない限り表示bg_colorないことに注意してください。 質問 これはGUI Guider 1.10.1における意図的なコードサイズ最適化なのでしょうか、それともコード生成の問題なのでしょうか？ もしこの最適化が意図的であれば、GUI Guiderはバックグラウンド不透明度が0のときにバックグラウンドプロパティを保持するオプションを提供してくれますか? ランタイムアプリケーションはLVGLスタイルのプロパティを動的に変更することが多いため、初期の不透明性だけでbg_colorを省略すると、UI設定とは異なる実行時の挙動が生じる可能性があります。 Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 こんにちは、 @zzjgood さん、 投稿ありがとうございます。 あなたが説明した行動を再現できます。これはコード生成の問題だと思います。ユーザーが背景色を明示的に設定する場合、GUI Guiderは初期の背景不透明度が0でも対応するbg_colorコードを保持するか、透明オブジェクトの背景スタイルプロパティを保持するオプションを提供するべきです。この件はGUI-Guiderチームに報告し、修正を依頼します。さらに、当社の内部エスカレーションプロセスに基づき、以下の情報を提供していただけるとありがたいです。 - どのNXP製品を使っていますか? - 最終的なアプリケーションは? 現在の実用的な回避策は、アプリケーションコード内で背景色と不透明度の両方を明示的に設定することです。 コピー lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); お役に立てば幸いです。 BR セレステ Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 はい、ご返信ありがとうございます。 Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 こんにちは、 @zzjgood さん、 お元気でお過ごしでしょうか。 この件に関して最新情報が入りました。バージョン1.10.1では、不透明度が0に設定されている場合に背景スタイルのコード生成をスキップする動作は、不要な生成コードを削減するために意図的に設計されたものです。同じ論理は境界線のスタイルにも当てはまります。 お客様のユースケースでは、残りのスタイルコードを生成することが依然として有益であることは理解しています。しかし、v1.xブランチは既に更新されていません。対照的に、v2.xは値に関係なくユーザー設定のスタイルプロパティをすべて生成し、あなたのシナリオを完全にサポートします。 したがって、Gui-guider v2.xへの移行をお勧めします。 現代的な組み込みGUIファストを作成 | NXP Semiconductors よろしくお願いいたします。 セレステ

连续两次测量中接收灵敏度相差 10dB 我发现我们一款使用 QN9083 BLE SoC 的产品出现了异常行为。当我测量设备接收器灵敏度时，我发现连续两次测量之间有高达 10dB 的差异。我正在使用 CMW100 的广播模式进行测量，该设备放置在屏蔽的射频盒中。在不打开盒子和/或改变设备位置的情况下，连续进行 RxS 测量，设备的响应差异高达 10dB（即 -91dBm 和 -81dBm），这是意料之外的，以前从未发生过。这种行为是随机的。我正在寻找硬件和软件方面可能的原因。 Re: Rx sensitivity differs by 10dB between consecutive measurements 你好， 连续两次灵敏度测量结果之间出现高达 10 dB 的变化，这通常是我们意想不到的。 能否告知您当前使用的软件/SDK 版本？ 另外，您能否澄清一下： 这种情况是发生在单个设备上还是多个产品上？ 您是否在不同的单元中观察到过同样的情况？ 使用相同的测量设置，能否在 NXP 开发板上重现该问题？ 这些信息将有助于确定问题是硬件、软件还是测试环境特有的。 顺祝商祺！ 里卡多 Re: Rx sensitivity differs by 10dB between consecutive measurements 您好，感谢您的回复。我的回答如下： 能否告知您当前使用的软件/SDK 版本？ 5.0 版本基于156414（控制器子系统）和 156821（主机子系统） 这种情况是发生在单个设备上还是多个产品上？ 同一款产品。使用其他产品从未遇到过问题。 您是否在不同的单元中观察到过同样的情况？ 是的，但并非始终如此。 使用相同的测量设置，能否在 NXP 开发板上重现该问题？ 我需要一块搭载 QN9083 芯片的开发板，以及一个能将芯片设置为广播模式的固件。 谢谢！       Re: Rx sensitivity differs by 10dB between consecutive measurements 关于BLE版本的其他信息： SDK 2.2.3 BLE 1.5.6，支持 BLE Core 5.0。 Re: Rx sensitivity differs by 10dB between consecutive measurements @Ricardo_Zamora 我使用 QN9080-DK 进行了测量。虽然我没有看到 10dB 的差异，但仍然存在 5dB 的波动（见下方数据）。可能是什么原因造成的？ furbani_0-1784214895282.pngfurbani_0-1784214895282.pngfurbani_0-1784214895282.png Re: Rx sensitivity differs by 10dB between consecutive measurements 嗨@Ricardo_Zamora，您有时间查看我发布的数据/答案吗？ 谢谢。 Re: Rx sensitivity differs by 10dB between consecutive measurements 我测量了 W236 FRDM 板，看看辐射 RSSI 的变化有多大。变化幅度可达 4dB。 RomanPBudek_0-1789049903611.pngRomanPBudek_0-1789049903611.png RomanPBudek_1-1789049923585.pngRomanPBudek_1-1789049923585.png Re: Rx sensitivity differs by 10dB between consecutive measurements @RomanPBudek谢谢你的更新。你使用什么仪器进行测量的？如果您也能测量一下我们这款设备的尺寸，我想寄送一台给您。 谢谢

安装S32 Design Studio for ARM 2.2无法激活 安装S32 Design Studio for ARM 2.2： 1.在激活时选择online则报图一错误，使用https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/Troubleshooting-Activation-fails-with-error-message-FNP-ERROR-0/ta-p/1123259后报图二错误，但是我的电脑服务中FlexNet Licensing Service时启动状态 2.使用offline激活，完全参照官网步骤后，报图三错误，我该如何正确激活并安装此版本软件？ Re: 安装S32 Design Studio for ARM 2.2无法激活 我已经完全按照步骤做了，依旧不行 Re: 安装S32 Design Studio for ARM 2.2无法激活 嗨@aether FNP 错误 20 通常与组件未正确安装或当前用户无法访问有关。请尝试以下步骤： 完全卸载 S32DS for ARM v2.2，并删除 C:\NXP\S32DS_ARM_v2.2 中所有剩余的文件。 备份并清除隐藏文件夹 C:\ProgramData\FLEXnet\ 的内容。 重新下载并安装适用于 ARM 的基本 S32DS v2.2 软件包（不包含 Update 2）。 以管理员权限运行安装程序，并确保防病毒软件或安全软件没有阻止安装程序运行。 BR，VaneB Re: 安装S32 Design Studio for ARM 2.2无法激活 嗨@aether 能否请您提供一下安装日志文件（.log）？它应该位于： C:\NXP\S32DS_ARM_v2.2\_S32 Design Studio for ARM Version 2.2_installation\Logs

ARINC615A 数据加载，使用 JTAG 访问密码保护 当未安装 HSE 固件时，可以使用CUST_DB_PSWD_A字段和设备生命周期配置来限制 S32K3 上的 SWD/JTAG 访问。假设更新是由应用程序或引导加载程序软件处理，而不是通过调试接口处理，启用此密码保护是否会对向处理器执行 ARINC 615A 软件数据加载产生任何影响？ Re: ARINC615A Data loading with JTAG Access password protected CUST_DB_PSWD_A 仅限制 SWD/JTAG 调试访问。我不熟悉您的 ARINC 615A 实现的细节，但如果软件加载完全由您的应用程序或引导加载程序处理，我认为调试密码本身不会产生任何影响。 最终，这是特定应用，取决于 ARINC 615A 在您的系统中是如何实现的。如果更新机制不使用调试接口，则调试访问限制通常应独立于软件加载过程。任何其他限制都将取决于您的生命周期配置和应用程序网络安全设计。

GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 Environment GUI Guider: 1.10.1 LVGL: 8.3 Widget: Button Style Part: LV_PART_MAIN Style State: LV_STATE_DEFAULT Problem Description I found a reproducible code-generation issue in GUI Guider 1.10.1. When a button has a configured background color but its Background Opacity is set to 0, GUI Guider does not generate the corresponding background color property. This causes unexpected behavior when the background opacity is changed dynamically at runtime. Reproduction Create a Button and configure: Background Color: #F08300 Background Opacity: 0 Then generate the LVGL 8.3 code. GUI Guider generates: lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 0, LV_PART_MAIN | LV_STATE_DEFAULT); However, the configured background color is not generated: lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); Test: Change only Background Opacity from 0 to 1 I changed only the Background Opacity from 0 to 1, while keeping the same Background Color #F08300. After regenerating the code, GUI Guider generates: lv_obj_set_style_bg_opa(ui->screen_password_btn_15, 1, LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(ui->screen_password_btn_15, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_grad_dir(ui->screen_password_btn_15, LV_GRAD_DIR_NONE, LV_PART_MAIN | LV_STATE_DEFAULT); Therefore, the generated code differs depending on whether Background Opacity is exactly 0. Background Opacity = 0: bg_opa is generated bg_color is not generated Background Opacity = 1: bg_opa is generated bg_color is generated other background properties are also generated Runtime Impact My application uses the background opacity to indicate the currently selected password digit. The background color is configured in GUI Guider as #F08300, while the application dynamically changes only the background opacity. For example: lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); For a button whose initial Background Opacity is 0, the generated code does not contain the configured background color. When the application changes the opacity from 0 to LV_OPA_COVER, the button displays the LVGL theme or default background color instead of the #F08300 color configured in GUI Guider. The behavior is: GUI Guider configuration: Background Color = #F08300 Background Opacity = 0 Generated code: bg_opa = 0 bg_color is not generated Runtime: bg_opa is changed to LV_OPA_COVER Result: The default or theme background color is displayed instead of #F08300. Workaround Explicitly setting the background color in application code resolves the issue: lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); Another possible workaround is setting Background Opacity to 1 in GUI Guider, because this causes GUI Guider to generate the configured background color. However, this changes the initial UI state and is therefore not ideal. Expected Behavior Background Color and Background Opacity are separate LVGL style properties. If the user explicitly configures: Background Color = #F08300 Background Opacity = 0 I would expect GUI Guider to preserve both properties in the generated code: lv_obj_set_style_bg_opa(btn, 0, LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); Although bg_color has no visible effect while bg_opa is 0, it becomes relevant when the application dynamically changes bg_opa at runtime. The current code-generation behavior loses the background color information configured in GUI Guider. Actual Behavior GUI Guider 1.10.1 appears to omit background style properties when Background Opacity is 0. Changing only the opacity from 0 to 1 causes the background color and other background properties to be generated again. Steps to Reproduce Create a Button in GUI Guider 1.10.1. Set Background Color to #F08300. Set Background Opacity to 0. Generate LVGL 8.3 code. Observe that lv_obj_set_style_bg_opa with value 0 is generated. Observe that lv_obj_set_style_bg_color with #F08300 is not generated. Change only Background Opacity from 0 to 1. Generate the code again. Observe that lv_obj_set_style_bg_color with #F08300 is now generated. At runtime, change the opacity of the original button to LV_OPA_COVER. Observe that the configured background color is not displayed unless bg_color is explicitly set by the application. Question Is this an intentional code-size optimization in GUI Guider 1.10.1, or is it a code-generation issue? If this optimization is intentional, could GUI Guider provide an option to preserve background properties when Background Opacity is 0? Runtime applications commonly change LVGL style properties dynamically, so omitting bg_color based only on its initial opacity can result in runtime behavior that differs from the UI configuration. Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 Hello @zzjgood , Thanks for your post.  I can reproduce the behavior you described. I think this is a code-generation issue. If the user explicitly configures a Background Color, GUI Guider should preserve the corresponding bg_color code even when the initial Background Opacity is 0, or provide an option to preserve background style properties for transparent objects. I will report this to the GUI-Guider team for further fix. In addition, according to our internal escalation process, we would appreciate it if you could provide the following information: - Which NXP product are you using? - What is your end application? The current practical workaround is to explicitly set both the background color and opacity in the application code: Copy lv_obj_set_style_bg_color(btn, lv_color_hex(0xF08300), LV_PART_MAIN | LV_STATE_DEFAULT); lv_obj_set_style_bg_opa(btn, LV_OPA_COVER, LV_PART_MAIN | LV_STATE_DEFAULT); Hop it helps. BR Celeste Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 Hello @zzjgood , Hope you are doing great. We got update about this issue. In v1.10.1, the behavior of skipping background style code generation when the opacity is set to 0 was intentionally designed to reduce unnecessary generated code. The same logic also applies to border styles. We understand that, in your use case, generating the remaining style code may still be beneficial. However, the v1.x branch is no longer being updated. In contrast, v2.x generates all user-configured style properties regardless of their values, which fully supports your scenario. Therefore, we recommend that migrating to Gui-guider v2.x.  Create Modern Embedded GUIs Fasts | NXP Semiconductors Regards, Celeste Re: GUI Guider 1.10.1 omits background style properties when Background Opacity is 0 Alright, thank you for your reply.

在 S32 Design Studio for Power Architecture v2.1 中，PEmicro GDB 启动失败 您好， 我正在测试的电路板是 MTRCKTSPS5744P（带有 MPC5744P MCU 的三相 PMSM 电机控制开发套件）。 不知何故，下载过程不太顺利。 点击调试按钮后，下载失败，此时会弹出此窗口。 eunwoo_lee_0-1789496057004.png 弹出一个窗口，显示此错误信息。 服务启动序列错误 PEmicro GDB 启动失败：GDB 服务器无法与目标处理器建立连接。请检查您的连接和电源。请确认调试配置中的启动设置是否准确。 控制台面板显示此消息。 来自“127.0.0.1”的连接，通过 127.0.0.1。从端口“53438”到7224的连接 PE错误：警告。部件运行时无法读取寄存器。 PE错误：警告。部件运行时无法读取内存。@0（4 字节） PE错误：警告。部件运行时无法读取内存。@0（4 字节） PE错误：警告。部件运行时无法读取寄存器。 PE错误：警告。部件运行时无法读取内存。@0（4 字节） PE错误：警告。部件运行时无法读取内存。@0（4 字节） PE错误：警告。部件运行时无法写入二进制文件。40001000 - 长度：0 - 值：二进制数据 PE错误：警告。部件运行时无法写入二进制文件。40001000 - 长度：460 - 值：二进制数据 PE错误：警告。部件运行时无法写入二进制文件。40001460 - 长度：460 - 值：二进制数据 PE错误：警告。部件运行时无法写入二进制文件。400018c0 - 长度：460 - 值：二进制数据 PE错误：警告。部件运行时无法写入二进制文件。40001d20 - 长度：2e0 - 值：二进制数据 PE错误：GDB客户端处理：发生异常：程序异常！ 异常类：EIDCONNCLOSEDGRACEFULLY 消息：连接已正常关闭。 地址 0X0046EA89 通过 127.0.0.1 与“127.0.0.1”断开连接。通过端口“53438”与7224断开连接 目标设备已断开连接。 你知道有什么办法解决这个问题吗？ 谢谢。 Re: PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 你好， 你知道有什么办法解决这个问题吗？ 正如消息中所述，您无法在运行时写入/读取寄存器。首先在调试器中停止代码执行，然后才能修改寄存器、内存等…… MPC5744P 正在运行用户代码，P&E 探针无法停止设备，因此所有内存/寄存器访问均失败，下载操作中止。 这看起来不像是一个闪存编程问题，而更像是调试器在下载之前未能停止 MPC5744P 的运行。 例如，微控制器中是否存在启用了 SWT0 的软件？ 或者这是一个没有运行任何软件的全新样本？ 顺祝商祺！ Peter

S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_2025 不支持 HB200x AUTOSAR R21-11 版本 0.8.0 您好，NXP， 我尝试将 HB200x AUTOSAR 规范 SDK 集成到 S32 Design Studio 中，但收到以下错误消息： 问题：在工具链/IDE 项目中找不到 Mc33hb。该项目无法编译！ 级别：错误 类型：验证 工具：工具链/IDE 项目 来源：外围设备 目标：工具链/IDE 项目：M7_0 资源：platform.driver.mc33hb 甚至包括 CDD_Mb33Hb.c 文件在 S32 Design Studio 应用程序 (v3.6.4) 中安装 SDK 时，尚未添加 CDD_Mb33Hb.h 等文件。 Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ 你好， 您似乎使用了错误的RTD版本。根据 HB200x AUTOSAR R21-11 0.8.0 发行说明，该软件可以基于 SW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip 使用（该软件需要安装在 S32 Design Studio IDE v3.5 中）。 PetrS_0-1789471295419.pngPetrS_0-1789471295419.png BR，彼得

PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 Hi, The board I am testing is MTRCKTSPS5744P (3-Phase PMSM Motor Control Development Kit with MPC5744P MCU). For some reason, the download process doesn't go well. This window pops up after failure in downloading when I click debug button. eunwoo_lee_0-1789496057004.png An window pops up showing this error message. Error in services launch sequence PEmicro GDB Launch Failure : The GDB Server was not able to establish a connection to the target processor. Please check your connections and power. Verify that the launch settings in the Debug Configuration are accurate. Console panel displays this message. Connection from "127.0.0.1" via 127.0.0.1. Connection from port "53438" to 7224 PE-ERROR: Warning. Can't read registers while part is running. PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read registers while part is running. PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't Write Binary while part is running. 40001000 - Length of: 0 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001000 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001460 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 400018c0 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001d20 - Length of: 2e0 - Value of: Binary Data PE-ERROR: GDB Client Processing : Exception Occured : PROGRAM EXCEPTION! EXCEPTION CLASS: EIDCONNCLOSEDGRACEFULLY MESSAGE: CONNECTION CLOSED GRACEFULLY. ADDRESS 0X0046EA89 Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "53438" from 7224 Target Disconnected. Is there any solution you know for this problem? Thanks. Re: PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 Hello, Is there any solution you know for this problem? As the message explains you cannot write/read registers on the fly. First stop the execution of the code in debugger and then you can modify the registers, memory, etc... The MPC5744P is running user code and the P&E probe is unable to halt the device, therefore all memory/register accesses fail and the download operation aborts. This looks less like a flash programming problem and more like a debugger failing to halt the MPC5744P before download. Is there for example SW with SWT0 enabled in the microcontroller? Or is it a fresh sample with no SW running? Best regards, Peter

ARINC615A Data loading with JTAG Access password protected When HSE firmware is not installed, SWD/JTAG access on the S32K3 can be restricted using the CUST_DB_PSWD_A field and device lifecycle configuration. Would enabling this password protection have any impact on performing an ARINC 615A software data load to the processor, assuming the update is handled by application or bootloader software rather than through the debug interface? Re: ARINC615A Data loading with JTAG Access password protected CUST_DB_PSWD_A only restricts SWD/JTAG debug access. I am not familiar with the details of your ARINC 615A implementation, but if the software load is handled entirely by your application or bootloader, I would not expect the debug password itself to have any impact. Ultimately, this is application-specific and depends on how ARINC 615A has been implemented in your system. If the update mechanism does not use the debug interface, debug access restrictions should generally be independent of the software loading process. Any additional limitations would depend on your lifecycle configuration and application security design.

KW45：プログラミング/デバッグ中の断続的なワイヤACK障害およびフラッシュ消去失敗 チームの皆さん、こんにちは。 現在、KW45ベースのカスタムボードを使用しているのですが、ファームウェアのプログラミングとデバッグ中に断続的な問題が発生しています。 SEGGER J-LinkとNXP MCU-Linkのデバッグプローブの両方で基板をテストしましたが、問題は両方のプローブで発生しました。 このカスタムボードはKW45 EVKと同じブート構成を採用しており、JTAG/SWD接続も確認済みで、問題ないようです。 しかし、以下のような挙動が見られます。 動作が確認されているアプリケーションをダンプしたりプログラムしたりしようとすると: 時にはアプリケーションが成功裏にプログラムされますが、プログラムやデバッグセッション開始後、デバイスは最終的にフォールトアドレスにジャンプします。 デバッガーはその場所で停止します。 プログラミングやダンプ処理中に、ワイヤACKフォルトが発生することがあります。 MCUXpressoは、別の時には次のように報告している。 MIコマンドの実行中にエラーが発生しました。 MCUXpressoからフラッシュメモリを消去しようと試みましたが、フラッシュメモリの消去操作自体が正常に完了しませんでした。 既に実施済みのチェック JTAG/SWD接続を確認したところ、問題ないようです。 この問題はSEGGER J-LinkとNXP MCU-Linkデバッグプローブの両方でテストされました。 ブート構成はKW45 EVKと比較された。 テストには動作が確認されているアプリケーションを使っています。 この問題は断続的に発生します。プログラミングが成功することもありますが、ワイヤACKエラーやMIコマンドエラーが発生することもあります。 フラッシュメモリの消去も試みましたが、正常に完了しませんでした。 私の質問 KW45がコードのダンプやプログラミング中に断続的にWire ACKの故障を報告する原因は何でしょうか? MIコマンドの実行中にエラーを報告しますか？ プログラミング後に、予期しないまたは無効なメモリ アドレスにジャンプまたは停止する？ フラッシュメモリの完全消去を試みても失敗する？ 問題には断続的なWire ACKの故障やフラッシュ消去時の故障が含まれているため、これはデバッグインターフェース、SWD/JTAGの信号整合性、電源の安定性、リセットシーケンス、フラッシュコントローラの状態、デバイスのセキュリティ/設定、起動設定、あるいは他のハードウェアレベルの問題に関連しているのではないかと疑っています。 以下のような推奨される手順を教えていただけますか: KW45デバイスを復元または消去します。 デバッグインターフェースが正しく動作しているか確認してください。 デバイスがセキュリティ保護されているか、または通常のプログラミングを妨げる状態になっていないかを確認してください。 ワイヤACK障害が、ターゲットハードウェア、デバッグプローブ、電源/リセット動作、またはSWD/JTAG信号の完全性のいずれかに起因するものかどうかを判断します。 必要に応じて以下の情報を提供できます。 MCUXpresso IDE バージョン:25.6.1 テストしたデバッグプローブ:SEGGER J-LinkおよびNXP MCU-Linkです ワイヤACK障害の詳細を含む完全なエラーログ デバッグコンソール出力 JTAG/SWDおよびブート接続の概略図 SWD/JTAGクロック周波数 電源およびリセット設定 障害状態からのメモリ/レジスタ情報 推奨されるトラブルシューティング手順についてご教示いただければ大変ありがたいです。 よろしくお願いいたします。 Re: KW45: Intermittent Wire ACK Fault During Programming/Debugging and Flash Erase Failure こんにちは、奥様。 詳細なご回答をありがとうございました。 ハードウェアの詳細について： BOOT_CFG (PTA4) プルダウン:はい、当社のカスタムボードでは、BOOT_CFG (PTA4) ネットにGNDへのプルダウン抵抗が接続されています。 VDD_SYSおよびVDD_COREデカップリングコンデンサ：はい、必要なデカップリングコンデンサは基板上に実装されています。VDD_SYSとVDD_COREの接続およびデカップリングコンデンサを示す関連する回路図の断面図／画像を添付しました。 その間に、ISP モードで デバイスにアクセスするための手順を進め、blhostコマンドでデバイスの状態を確認し、大量消去を実行してみます。 以前に実行されていたアプリケーションについて: このアプリケーションは FreeRTOS をベースにしており、以下のペリフェラル/モジュールを統合しています: FreeRTOS DMA対応LPSPI0 汎用I/O (GPIO) LPSPI1（FIFO付き） WDOG 低消費電力の質問については、アプリケーションで特定の低消費電力の例を意図的に使ったわけではありません。 ISP復旧手順を実行し、結果をお知らせします。特に以下の点についてお知らせします。 get-property 1 get-property 07 フラッシュ消去 フラッシュ消去2 これらのテストを実施する際に、他に推奨するハードウェアのチェックや測定があればお知らせください。 Prashanth1_0-1789454497591.pngPrashanth1_0-1789454497591.pngプラシャンス1_0-1789454497591.png Prashanth1_1-1789454501864.pngPrashanth1_1-1789454501864.pngプラシャンス1_1-1789454501864.png 改めてサポートありがとうございます。 よろしくお願いします、 プラシャント Re: KW45: Intermittent Wire ACK Fault During Programming/Debugging and Flash Erase Failure こんにちは、お元気でお過ごしでしょうか。   まず最初に、カスタムボードのハードウェア詳細を確認していただけますか: BOOT_CFG（PTA4）ネットにはGNDへのプルダウン抵抗が接続されていますか？VDD_SYSおよびVDD_COREのデカップリングコンデンサは実装されていますか？これらは、フィードバック経路を提供し、内部レギュレータ出力の電圧安定性を維持するために必要となる。   デバイスの復旧を試みるには、以下の手順をお試しください。 ISPモードでデバイスにアクセスできますか?そのためには、リセット中にBOOT_CONFIG（PTA4）をハイレベルにプルアップして、デバイスをISPモードに強制的に切り替えます（KW47-EVKの場合はSW4です）。 ISPモードに入ったら、コマンドプロンプトを開き、以下のコマンドを実行します。 # Confirms ROM bootloader communication is working, a successful response confirms the device is reachable via ISP blhost.exe -p COMX get-property 1 # Reveals whether the device is in OEM_OPEN or a secured lifecycle state blhost.exe -p COMX get-property 07 # Perform a mass erase of the CM33 and NBU Program Flash blhost.exe -p COMX flash-erase-all blhost.exe -p COMX flash-erase-all 2 その後、hello_worldやBLEの例を試して、基板が正常に動作しているか確認してみてください。 念のため確認ですが、以前どのアプリケーションを実行しましたか?低消費電力のサンプルでもテストしましたか？また、デバイスが低消費電力状態に入り、低消費電力運転中にSWDデバッグインターフェースが無効化され、LinkServerやJ-Linkが正常に接続できなくなる可能性もあります よろしくお願いします、 ソフィア。

HB200x AUTOSAR R21-11 バージョン 0.8.0 S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_2025 がサポートしていません こんにちは、NXPさん。 HB200x AUTOSAR仕様SDKをS32 Design Studioに統合しようとしましたが、以下のエラーメッセージが表示されます。 問題点:Mc33hbはツールチェーン/IDEプロジェクトに存在しません。プロジェクトはコンパイルできません！ レベル: エラー タイプ：検証 ツール:ツールチェーン/IDEプロジェクト 起源:ペリフェラル ターゲット:ツールチェーン/IDEプロジェクト:M7_0 リソース:platform.driver.mc33hb CDD_Mb33Hb.c ファイルでさえCDD_Mb33Hb.hなどは、SDKがS32 Design Studioアプリケーション(v3.6.4)にインストールされた際には追加されていませんでした。 Re: HB200x AUTOSAR R21-11 Version 0.8.0 not supported by S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_ こんにちは、 どうやら間違ったRTDバージョンを使用しているようです。HB200x AUTOSAR R21-11 0.8.0リリースノートに基づき、このソフトウェアはSW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip(S32 Design Studio IDE v3.5にインストールする必要があります)上で使用可能です。 PetrS_0-1789471295419.pngPetrS_0-1789471295419.png BR、ペトル

安装 S32K312 的 RTD 我正在尝试在 S32 Design Studio v 3.6.6上为 S32K312 设置开发环境，具体步骤如下： 1. 下载了 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip 2. 在 S32 Design Studio 3.6.6 中打开了“S32Extensions and Updates”。在 Windows 11 系统上运行，并已安装 S32K3 实时驱动程序，如下所示： durga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.pngdurga_choudhury_0-1788877584959.png 3. 按照提示重启了IDE（我也尝试过重启电脑）。 由此看来，我无法看到对 K3 系列的支持。“新建项目”对话框中没有显示此选项： durga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.pngdurga_choudhury_1-1788877756997.png 如果我尝试安装如下所示的“S32K3XX”驱动程序： durga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.pngdurga_choudhury_2-1788877862245.png 我收到如下所示的错误信息： durga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.pngdurga_choudhury_3-1788877910412.png 现在在 S32DS v 3.6.2 上重复整个过程略有改善：现在“新建项目”对话框中列出了 K312 选项，但没有列出其 SDK： durga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.pngdurga_choudhury_4-1788878190320.png 我做错了什么？ Re: Installing RTD for S32K312 嗨@VaneB 很遗憾，我在S32DS 3.6.6上没有对应的版本。我已经尝试将 RTD 版本从 7.0.1 降级到 6.0.0。 是否有适用于 3.6.6 的特定版本？ Re: Installing RTD for S32K312 你好@durga_choudhury 截图来自我的 S32DS 3.6.10 系统。安装过程；但是，您应该会在 IDE 中看到类似的设置。 VaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.pngVaneB_0-1788893776567.png 另外，根据你分享的截图，我可以看到你已经成功安装了 RTD 7.0.1。由于 RTD 7.0.1 依赖于 S32K3 开发包，因此该软件包很可能已经安装。 Re: Installing RTD for S32K312 嗨@VaneB 请详细说明一下您的评论。 我看到我安装了 S32K1xx 的“开发包”（这也是我使用的 MCU 系列）： durga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.pngdurga_choudhury_0-1788891225434.png 但我发现K3并没有类似的功能。 那么我该如何安装呢？重申一下，我目前为止所做的工作是： 1. 下载了 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip 2. 已将其添加为 S32 DS v 3.6.6的更新站点 3. 安装了以下软件： durga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.pngdurga_choudhury_1-1788891394005.png Re: Installing RTD for S32K312 你好@durga_choudhury 来自您的 S32DS 3.6.6安装过程中，似乎没有安装 S32K3 开发包。 关于 S32DS 3.6.2，请注意，RTD 7.0.1 是使用 S32DS 3.6.4 开发和验证的。因此，我们建议使用 S32DS 3.6.4 版本。或者使用更新的版本以确保兼容性并避免潜在问题。 此外，还需要验证工具链。创建项目时，请确保已安装 NXP GCC 10.2.0 并选择其作为项目工具链。 BR，VaneB Re: Installing RTD for S32K312 你好@durga_choudhury 我的配置是RTD 7.0.0。随 S32DS 3.6.6 一起安装。但是，如前所述，RTD 7.0.1 应该可以正常工作，因为这些版本的设置非常相似。 能否分享一下您的安装详情？ Re: Installing RTD for S32K312 你好@durga_choudhury 请注意，提供的链接并非常规网址。它对应于 S32DS 使用的更新站点，用于访问可用的软件包和更新。 要查看完整的更新站点列表，请打开 S32DS 扩展和更新窗口，然后选择“管理站点”。您可以在这里找到 IDE 识别的所有更新站点。 Re: Installing RTD for S32K312 你好@durga_choudhury 请您尝试以下操作？在 S32DS 中，转到“帮助”→“安装新软件”……这将打开安装窗口。在“使用以下方式操作：”字段中，输入以下更新站点： https://www.nxp.com/lgfiles/updates/Eclipse/S32DS_3.6 应该会显示一个可用更新列表，类似于下面显示的内容。请检查列表中是否能找到 S32 Design Studio S32K3xx 开发包，并尝试安装。 VaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.pngVaneB_0-1789057150680.png 如果代码包，软件包未出现或安装失败，我建议更新到最新的 S32DS 版本。当前安装可能缺少某些元器件，或者在安装/更新过程中某些文件损坏。 Re: Installing RTD for S32K312 嗨@VaneB 很遗憾，它对我不起作用： durga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.pngdurga_choudhury_0-1789083559046.png Re: Installing RTD for S32K312 嗨@VaneB 以下是我尝试过的两个文件（都存在同样的问题）： durga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.pngdurga_choudhury_0-1789048352154.png 以下是关于S32DS的信息： durga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.pngdurga_choudhury_1-1789048467186.png 以下是一些安装细节，尽可能全部显示在一张屏幕截图中。您还需要其他信息吗？ durga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.pngdurga_choudhury_2-1789048687291.png Re: Installing RTD for S32K312 嗨@VaneB 感谢您的支持。请您再次确认一下网址好吗？如果我尝试从这里更新，S32 DS 会报错，如下所示： durga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.pngdurga_choudhury_0-1789063889394.png 如果我尝试通过 REST 类型的应用程序访问它，例如：使用 wget 下载时，出现 HTTP 错误 404（未找到）。 会不会是恩智浦内部的问题（例如，（不在面向公众的服务器上）？ Re: Installing RTD for S32K312 你好@durga_choudhury 请您在另一台机器上测试一下好吗？ 此外，最好与您的 IT 团队确认是否存在防火墙、代理或网络安全策略阻止访问更新站点。 Re: Installing RTD for S32K312 这似乎确实是我们的代理服务器出了问题。它可以在公司网络之外的计算机上运行。 非常感谢您的支持。