LPSPI3 registers inaccessible from Linux (Bus error on devmem read) — external SPI device on P11 EXP Summary I'm trying to bring up two external MCP2515 CAN controllers (Waveshare 2‑CH CAN HAT, confirmed working on a genuine Raspberry Pi) on the FRDM‑IMX93 board's P11 EXPI header, using LPSPI3 on GPIO_IO08‑11 (the pins that match the Raspberry‑Pi‑compatible header positions per UM12181 Table 21). After fixing every device‑tree‑level issue I could find (power, pinmux, chip‑select, pinctrl‑assert‑gpios), the SPI clock (SCK) never toggles on the physical header pin, and a direct register read of the LPSPI3 block causes a Bus error. A different, known‑working peripheral (LPUART1) reads back fine from the same address space. This points to a resource/bus access restriction (RDC or similar) rather than anything fixable from the Linux device tree. Board / software Board: FRDM‑IMX93 (NXP), SoC: MIMX9352CVVXMAB BSP: NXP i.MX Release Distro, kernel 6.18.2-1.0.0-gf49f45233f7b Target peripheral: lpspi3 (spi@42550000, aliased spi2 in /aliases, real dts label confirmed via /proc/device-tree/__symbols__ to be lpspi3) External device under test: 2× MCP2515 (Waveshare 2‑CH CAN HAT) on CS0/CS1 What's already confirmed working (ruled out) Power to the header. reg_vexp_3v3 / reg_vexp_5v are regulator-fixed nodes that default to disabled (regulator_summary showed use=0). Added regulator-always-on + regulator-boot-on via overlay fragments targeting &reg_vexp_3v3 / &reg_vexp_5v (confirmed real labels via __symbols__). Verified 3.3 V / 5 V physically present on P11 afterwards. Pinmux. GPIO_IO08‑11 correctly muxed to LPSPI3_PCS0/SIN/SOUT/SCK using the official macros from imx93-pinfunc.h. input_reg/input_val are 0x0000/0x0 for these three functions, so no DAISY‑chain select is required (ruled out via macro inspection, no separate register needed). Chip‑select. cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; (bit‑banged GPIO CS, matching NXP's own upstream board‑support pattern for this node). Confirmed via cat /sys/kernel/debug/gpio and multimeter/logic‑analyzer: CS0 toggles correctly and physically reaches the header pin. pinctrl-assert-gpios. NXP's own upstream &lpspi3 reference for this board includes pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; (this line does not appear in most public guides, only in the board's own dts patch). Added it; confirmed via /proc/device-tree/__symbols__ that pcal6408 resolves, and via cat /sys/kernel/debug/gpio that the GPIO is asserted (out hi) once lpspi3's default pinctrl state is requested. Overlay applies cleanly. No FDT_ERR_NOTFOUND from U‑Boot's fdt apply; /sys/bus/spi/devices/ shows spi2.0 and spi2.1 registered by the SPI core. ERR051608 (LPSPI TCR[PRESCALE] errata). Checked spi-fsl-lpspi.c history — the fix (prescale_max = 1 for fsl,imx93-spi) landed in mainline Aug 2024 / stable 6.6.51 & 6.10.10 Sept 2024, well before this kernel version (6.18.2), and the compatible string (fsl,imx93-spi) is already present in the base board dts, so the driver should auto‑apply this limit. Not ruled out with certainty (no direct register confirmation of the actual PRESCALE field written), but timeline strongly suggests it's already handled. The actual symptom With CS0/CS1, MISO, MOSI, SCK probed on the physical P11 pins (multimeter, then a logic analyzer at 10–20 MSa/s triggered on CS0 falling edge) while continuously retrying a transfer (spidev_test in a loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind): CS0 toggles. Confirmed on both multimeter and logic analyzer. SCK never toggles. Flat, no activity, regardless of continuous transfer attempts. MOSI never toggles. Both MCP2515s fail identically: mcp251x spi2.0/spi2.1: MCP251x didn't enter in conf mode after reset / Probe failed, err=110 (ETIMEDOUT) — i.e. the driver's own SPI‑level reset+read‑CANSTAT sequence gets no response, consistent with SCK never leaving the SoC. Root cause narrowed to clock / bus access, not device tree   # clk_enable_count AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ 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 $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 lpspi3's functional (per) clock shows clk_enable_count=0 and clk_prepare_count=0 even while 42550000.spi (the real, bound consumer) is actively attempting transfers in a loop (spidev_test loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind). clk_prepare() is the step before clk_enable() — the fact that it's never even called suggests the driver's transfer path (or a pm_runtime_get() in front of it) never reaches its own clock‑management code for this device, rather than the clock being requested and then failing to gate on. I don't have kernel build tooling to add tracepoints, so I can't yet tell whether this is a pm_runtime resume that silently no‑ops, a missing dependency (e.g. a power-domains reference this board's lpspi3 node needs but doesn't have), or something else in spi-fsl-lpspi.c for this specific kernel build. The decisive register‑level test — direct devmem read:   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) A completely unrelated, working peripheral (LPUART1, used for the debug console) reads back fine from the same CPU/bus context; LPSPI3's base address faults on a plain 32‑bit read. I initially suspected a Resource Domain Controller (RDC) style access restriction specific to this board, but several NXP Community threads (i.MX25/i.MX6ULL "devmem return bus error", i.MX8MP I2C‑from‑DSP thread) point to the same symptom being the normal, expected result of touching an AIPS‑bus peripheral whose clock is gated off — not necessarily a security/domain restriction. That's consistent with clk_enable_count=0 above and makes me now think this is a clock‑enablement bug in the driver/PM path for this device, not (necessarily) an RDC block — though I can't fully rule out RDC without lower‑level tooling. This isn't a general i.MX93 LPSPI3 limitation For context: a separate NXP Community thread ([iMX93AUTO EVK] SPI Configuration for QCA7006AQ, community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847) shows someone successfully driving an external SPI device over LPSPI3 on the same GPIO_IO08‑11 pins on the i.MX93‑11x11‑EVK (same SoC), using:   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; I tried this exact variant (native LPSPI3_PCS0/LPSPI3_PCS1 instead of plain GPIO2_IO08/GPIO2_IO07, plus the explicit compatible override) on the FRDM board — no change, devmem 0x42550000 32 still faults, clk_enable_count/clk_prepare_count still 0. This rules out pinmux/compatible‑string choice as the cause on this board, and — combined with the EVK success — makes me suspect something FRDM‑board‑specific (either in imx93-11x11-frdm.dts's handling of lpspi3, or in this board's U‑Boot/ATF‑level RDC/power‑domain setup) rather than a general i.MX93 SoC or mainline‑driver limitation. Questions for NXP Given clk_prepare_count/clk_enable_count stay at 0 for lpspi3 even while the SPI core is actively driving transfers to a bound spi2.0/spi2.1 device, and a plain register read of 0x42550000 bus‑faults — what's missing from the FRDM‑IMX93's lpspi3 device‑tree node (or from board‑level RDC/power‑domain setup) that the working EVK config doesn't need? Is LPSPI3 on the FRDM‑IMX93 intentionally reserved for another domain (e.g. Cortex‑M33 / secure world, or the on‑board MAYA‑W2 tri‑radio module path) at the board's default RDC/ATF configuration, unlike the EVK? Is there a reference imx93-11x11-frdm-lpspi.dts (analogous to imx93-11x11-evk-lpspi.dts) for using LPSPI3 externally via P11 on this specific board? How to reproduce Base board dtb: stock imx93-11x11-frdm.dtb shipped with the i.MX Release Distro image (unmodified NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v nodes — all confirmed present via __symbols__). Apply the overlay described above (regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3; tried both plain‑GPIO and native‑PCS0/PCS1 pinmux variants, same result both times). Bind spidev (built‑in, CONFIG_SPI_SPIDEV=y) manually to 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 — "succeeds" (no I/O error) but RX data is not a loopback of TX even with MOSI/MISO physically shorted; SCK never toggles on a logic analyzer regardless. cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0. devmem 0x42550000 32 → Bus error. devmem 0x44380000 32 (LPUART1) → succeeds normally. Happy to provide the full overlay source, dmesg, and clk_summary/gpio dumps if useful.

FRDM-IMX93: LPSPI3 registers inaccessible from Linux (Bus error on devmem read) — external SPI devic Summary I'm trying to bring up two external MCP2515 CAN controllers (Waveshare 2‑CH CAN HAT, confirmed working on a genuine Raspberry Pi) on the FRDM‑IMX93 board's P11 EXPI header, using LPSPI3 on GPIO_IO08‑11 (the pins that match the Raspberry‑Pi‑compatible header positions per UM12181 Table 21). After fixing every device‑tree‑level issue I could find (power, pinmux, chip‑select, pinctrl‑assert‑gpios), the SPI clock (SCK) never toggles on the physical header pin, and a direct register read of the LPSPI3 block causes a Bus error. A different, known‑working peripheral (LPUART1) reads back fine from the same address space. This points to a resource/bus access restriction (RDC or similar) rather than anything fixable from the Linux device tree. Board / software Board: FRDM‑IMX93 (NXP), SoC: MIMX9352CVVXMAB BSP: NXP i.MX Release Distro, kernel 6.18.2-1.0.0-gf49f45233f7b Target peripheral: lpspi3 (spi@42550000, aliased spi2 in /aliases, real dts label confirmed via /proc/device-tree/__symbols__ to be lpspi3) External device under test: 2× MCP2515 (Waveshare 2‑CH CAN HAT) on CS0/CS1 What's already confirmed working (ruled out) Power to the header. reg_vexp_3v3 / reg_vexp_5v are regulator-fixed nodes that default to disabled (regulator_summary showed use=0). Added regulator-always-on + regulator-boot-on via overlay fragments targeting &reg_vexp_3v3 / &reg_vexp_5v (confirmed real labels via __symbols__). Verified 3.3 V / 5 V physically present on P11 afterwards. Pinmux. GPIO_IO08‑11 correctly muxed to LPSPI3_PCS0/SIN/SOUT/SCK using the official macros from imx93-pinfunc.h. input_reg/input_val are 0x0000/0x0 for these three functions, so no DAISY‑chain select is required (ruled out via macro inspection, no separate register needed). Chip‑select. cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; (bit‑banged GPIO CS, matching NXP's own upstream board‑support pattern for this node). Confirmed via cat /sys/kernel/debug/gpio and multimeter/logic‑analyzer: CS0 toggles correctly and physically reaches the header pin. pinctrl-assert-gpios. NXP's own upstream &lpspi3 reference for this board includes pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; (this line does not appear in most public guides, only in the board's own dts patch). Added it; confirmed via /proc/device-tree/__symbols__ that pcal6408 resolves, and via cat /sys/kernel/debug/gpio that the GPIO is asserted (out hi) once lpspi3's default pinctrl state is requested. Overlay applies cleanly. No FDT_ERR_NOTFOUND from U‑Boot's fdt apply; /sys/bus/spi/devices/ shows spi2.0 and spi2.1 registered by the SPI core. ERR051608 (LPSPI TCR[PRESCALE] errata). Checked spi-fsl-lpspi.c history — the fix (prescale_max = 1 for fsl,imx93-spi) landed in mainline Aug 2024 / stable 6.6.51 & 6.10.10 Sept 2024, well before this kernel version (6.18.2), and the compatible string (fsl,imx93-spi) is already present in the base board dts, so the driver should auto‑apply this limit. Not ruled out with certainty (no direct register confirmation of the actual PRESCALE field written), but timeline strongly suggests it's already handled. The actual symptom With CS0/CS1, MISO, MOSI, SCK probed on the physical P11 pins (multimeter, then a logic analyzer at 10–20 MSa/s triggered on CS0 falling edge) while continuously retrying a transfer (spidev_test in a loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind): CS0 toggles. Confirmed on both multimeter and logic analyzer. SCK never toggles. Flat, no activity, regardless of continuous transfer attempts. MOSI never toggles. Both MCP2515s fail identically: mcp251x spi2.0/spi2.1: MCP251x didn't enter in conf mode after reset / Probe failed, err=110 (ETIMEDOUT) — i.e. the driver's own SPI‑level reset+read‑CANSTAT sequence gets no response, consistent with SCK never leaving the SoC. Root cause narrowed to clock / bus access, not device tree   # 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's functional (per) clock shows enable_count=0 even while 42550000.spi (the real, bound consumer) is actively attempting transfers in a loop — it isn't simply "unused" (compare to lpspi1/2/4, which are deviceless and also show 0, so that alone isn't conclusive). The decisive test — direct register read via devmem:   $ devmem 0x44380000 32 # LPUART1 base — known-good peripheral 0x04040007 $ devmem 0x42550000 32 # LPSPI3 base (VERID register) Bus error (core dumped) A completely unrelated, working peripheral (LPUART1, used for the debug console) reads back fine from the same CPU/bus context. LPSPI3's base address faults on a plain 32‑bit read, before any clock‑gating or pinmux consideration even matters. This looks like a Resource Domain Controller (RDC) — or similar access‑control mechanism — blocking the Cortex‑A55 (Linux) domain from this peripheral's address range at the hardware level, independent of anything configurable from the Linux device tree. Questions for NXP Is LPSPI3 on the FRDM‑IMX93 intentionally reserved for another domain (e.g. Cortex‑M33 / secure world) in the board's default RDC configuration, making it unusable from Linux without additional SPL/ATF/TF‑A level reconfiguration? If so, is there a documented way to reassign LPSPI3 bus access to the Cortex‑A55 non‑secure domain (RDC config in U‑Boot SPL, or an OP‑TEE/TF‑A change), or is this simply not supported as an external SPI on this board's P11 header despite GPIO_IO08‑11 being broken out there? Is this specific to my board/kernel build, or a known characteristic of the default FRDM‑IMX93 BSP? A reference imx93-11x11-frdm-lpspi.dts (analogous to imx93-11x11-evk-lpspi.dts for the EVK) would be very helpful if one exists. How to reproduce Base board dtb: stock imx93-11x11-frdm.dtb shipped with the i.MX Release Distro image (unmodified NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v nodes — all confirmed present via __symbols__). Apply the overlay described above (regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3). Bind spidev (built‑in, CONFIG_SPI_SPIDEV=y) manually to 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 — transfer "succeeds" (no I/O error) but RX data is not a loopback of TX even with MOSI/MISO physically shorted. devmem 0x42550000 32 → Bus error. Happy to provide the full overlay source, dmesg, and clk_summary/gpio dumps if useful.

LPSPI3レジスタがLinuxからアクセス不能(devmem読み取り時のバスエラー)— P11 EXP上の外部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 AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ 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 $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 LPSPI3の機能クロック(per)はclk_enable_count=0 、 clk_prepare_count=0を示します。これは425550000.SPI(実際のバインドされた消費者)がループ(spidev_testループ、そしてEcho SPI2.>0を経て/sys/bus/spi/ドライバ/mcp251x/bindを繰り返し強制してMCP251Xを再プローブを繰り返し試みている間でもです)。clk_prepare()はclk_enable() の前の ステップです。呼び出されないことから、ドライバーの転送経路(またはその前のpm_runtime_get())がこのデバイスの独自のクロック管理コードに到達しないことを示唆しており、クロックを要求してゲートオンに失敗したわけではありません。 トレースポイントを追加するカーネルビルドツールは持っていないので、これがサイレントノーオプスの繰り返しpm_runtimeなのか、依存関係が欠落しているのか(例:power-domainsがこのボードのlpspi3ノードが必要とするが持っていない)、あるいはこの特定のカーネルビルドに対するspi-fsl-lpspi.cの別の何かなのか、まだ判断がつきません。 決定的なレジスタレベルのテスト ― 直接的な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)スタイルのアクセス制限かと疑いましたが、いくつかのNXPコミュニティスレッド(i.MX25/i.MX6ULL「devmem return bus error」やi.MX8MP I2C-from-DSPスレッド)は、 クロックが制限されているAIPSバス周辺機器に触れた場合の正常で予想される症状 であり、必ずしもセキュリティやドメイン制限ではないと指摘しています。これは上記のclk_enable_count=0と一致しており、これはこの デバイスのドライバー/PMパスのクロック有効化バグであり、必ずしもRDCブロックではないと考えています。ただし、低レベルのツールがなければRDCを完全に除外することはできません。 これは一般的な i.MX93 LPSPI3 の制限ではありません 参考までに:別のNXPコミュニティThread([iMX93AUTO EVK] SPI Configuration for QCA7006AQ, community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847)i.MX93-11x11-EVK （同じSoC）の同じGPIO_IO08-11ピン上で、LPSPI3を介して外部SPIデバイスを正常に駆動する様子が示されています。   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; FRDM ボードでこのまったく同じバリアント (通常の GPIO2_IO08/GPIO2_IO07 の代わりにネイティブ LPSPI3_PCS0/LPSPI3_PCS1、さらに明示的な互換性オーバーライド) を試しましたが、変化はありませんでした。devmem 0x42550000 32 は依然としてフォルトを起こし、clk_enable_count/clk_prepare_count は依然として 0 です。これにより、このボードではピンmux/compatible-stringの選択が原因ではないことがわかり、EVKの成功と合わせて、 FRDMボード固有の何か（imx93-11x11-frdm.dtsのlpspi3 の処理、またはこのボードの U-Boot/ATF レベルの RDC/電源ドメイン設定）によるものであり、一般的な i.MX93 SoC またはメインラインドライバの制限ではありません。 NXPへの質問 SPIコアがバインドされたspi2.0/spi2.1デバイスへの転送をアクティブに実行している間も、lpspi3のclk_prepare_count/clk_enable_countが0のままであり、0x42550000の単純なレジスタ読み取りでバスフォルトが発生する場合、FRDM-IMX93のlpspi3デバイスツリーノード（またはボードレベルのRDC/電源ドメイン設定）には、正常に動作するEVK構成に不要なものが欠けているのでしょうか？ FRDM-IMX93 の LPSPI3 は、別のドメイン (例:Cortex-M33 / セキュアワールド、またはオンボードの MAYA-W2 トライラジオモジュールパス）は、EVK とは異なり、ボードのデフォルトの RDC/ATF 構成で動作しますか？ この特定のボードでP11経由でLPSPI3を外部から使用するための参照ファイルimx93-11x11-frdm-lpspi.dts（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 を使用。plain-GPIO と native-PCS0/PCS1 pinmux の両方のバリアントを試しましたが、どちらの場合も同じ結果でした）。 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 のループバックではない。ロジック アナライザで SCK がトグルすることはない。 cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0. devmem 0x42550000 32 → バスエラー。devmem 0x44380000 32 (LPUART1) → 正常に成功しました。 必要であれば、オーバーレイのソースコード、dmesgログ、clk_summary/gpioダンプなど、すべての情報を提供いたします。

imx95 AHAB SGK 支持 你好， 我正在研究 i.MX95 上的 AHAB 安全启动支持，并想确认支持的签名密钥层次结构。 我了解到，某些 i.MX9 变体（例如 i.MX93）目前不支持 AHAB 容器签名的从属签名密钥 (SGK)，而仅支持基于 SRK 的签名，如这里所讨论的： https://community.nxp.com/t5/i-MX-Processors/imx93-AHAB-SGK-support/td-p/2181212 请问 i.MX95 是否支持使用带有 CA 标志的 SRK 证书对 AHAB 启动容器进行从属密钥 (SGK) 签名，还是当前发布的 ELE 固件仅支持直接基于 SRK 的签名？ 如果支持 SGK，能否也说明一下，支持是否取决于 i.MX95 芯片版本、ELE 固件版本、AHAB 容器格式或 BSP 版本？ Re: imx95 AHAB SGK support 请问有人能帮帮我吗？ Re: imx95 AHAB SGK support 你好， 对于未能及时回复您，我深表歉意。如果该功能仍然有用，经与团队确认，A 或 B 芯片版本均不支持该功能。 此致敬礼/Saludos， 阿尔多。 Re: imx95 AHAB SGK support 感谢@AldoG的澄清。

S32 Design Studio プラットフォーム + SW32G2 + RTD バージョン選択 私はS32G-VNP-RDB2 ソフトウェア イネーブルメント ガイドを参照しており、推奨されているソフトウェアバージョンはSW32G2_S32DS_3.4.0_D2012.zip+R S32DS.3.4_b201217_win32.x86_64.exe+リアルタイム・ドライバ S32_RTD_4.4_1.0.0_HF01_D2102_DS_Updatesite.zipでした。 しかし、実際にダウンロードしたのは S32DS.3.4_b201217_win32.x86_64.exe +SW32G2_S32DS_3.4.1_D2104.zip +SW32G_RTD_4.4_3.0.2_HF01_DS_updatesite_D2204.zip です。 RGBLEDを点灯してペリフェラルを起動しようとすると、「ペリフェラル:[SDK] コード更新に失敗 - コード生成に失敗」と表示されます。ソフトウェアのバージョンが違うからこそエラーが原因なのかは分かりません。 Re: S32 Design Studio Platform + SW32G2 + RTD version selection こんにちは、 guang1994 社内で返信させていただきます。 BR ジョーイ

Linux 无法访问 LPSPI3 寄存器（读取设备内存时出现总线错误）——P11 EXP 上的外部 SPI 设备 摘要 我正在尝试在 FRDM-IMX93 板的P11 EXPI 接头上使用LPSPI3在 GPIO_IO08-11 上启动两个外部 MCP2515 CAN 控制器（Waveshare 2-CH CAN HAT，已确认在真正的 Raspberry Pi 上工作）（引脚与 UM12181 表 21 中 Raspberry Pi 兼容接头的位置相匹配）。 在修复了我能找到的所有设备树级问题（电源、引脚复用、片选、引脚控制断言-GPIO）之后，SPI 时钟 (SCK)始终无法在物理接头引脚上切换，并且直接读取 LPSPI3 块的寄存器会导致总线错误。另一个已知工作正常的外部设备（LPUART1）可以从相同的地址空间正常读取数据。这表明存在资源/总线访问限制（RDC 或类似限制），而不是 Linux 设备树中可以修复的问题。 板/软件 开发板：FRDM-IMX93（恩智浦），SoC：MIMX9352CVVXMAB BSP：NXP i.MX 发布发行版，内核版本 6.18.2-1.0.0-gf49f45233f7b 目标外设：lpspi3（spi@42550000，别名在 /aliases 中为 spi2，通过 /proc/device-tree/__symbols__ 确认实际 dts 标签为 lpspi3） 被测外部设备：CS0/CS1 上的 2 个 MCP2515（Waveshare 2 通道 CAN HAT） 已确认有效（已排除） 给排气歧管供电。reg_vexp_3v3 / reg_vexp_5v 是默认禁用的调节器固定节点（regulator_summary 显示 use=0）。通过覆盖片段添加了 regulator-always-on + regulator-boot-on，目标为 &reg_vexp_3v3 / &reg_vexp_5v（通过 __symbols__ 确认了真实标签）。事后验证 P11 上实际存在 3.3 V / 5 V 电压。 Pinmux。使用 imx93-pinfunc.h 中的官方宏，GPIO_IO08‑11 已正确复用到 LPSPI3_PCS0/SIN/SOUT/SCK。对于这三个函数，input_reg/input_val 均为 0x0000/0x0，因此不需要 DAISY 链选择（通过宏检查排除，不需要单独的寄存器）。 芯片选择。cs-gpios = , （位操作 GPIO CS，与 NXP 针对此节点的上游板级支持模式相匹配）。通过 cat /sys/kernel/debug/gpio 和万用表/逻辑分析仪确认： CS0 切换正常，并且物理上连接到了接头引脚。 pinctrl-assert-gpios。NXP自己的上游 &lpspi3 参考中包含 pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>;（此行并未出现在大多数公开指南中，仅出现在板自己的 dts 补丁中）。已添加；通过 /proc/device-tree/__symbols__ 确认 pcal6408 已解析，并通过 cat /sys/kernel/debug/gpio 确认，一旦请求 lpspi3 的默认 pinctrl 状态，GPIO 就会被钳位（输出 hi）。 覆盖层涂抹顺畅。U-Boot 的 fdt apply 没有出现 FDT_ERR_NOTFOUND；/sys/bus/spi/devices/ 显示 SPI 内核已注册 spi2.0 和 spi2.1。 ERR051608（LPSPI TCR[PRESCALE] 勘误）。已检查 spi-fsl-lpspi.c历史记录——该修复（fsl、imx93-spi 的 prescale_max = 1）已于 2024 年 8 月合并到主线版本 / 稳定版 6.6.51。& 6.10.10 2024 年 9 月，远早于此内核版本 (6.18.2)，并且兼容字符串 (fsl,imx93-spi) 已存在于主板 dts 中，因此驱动程序应该自动应用此限制。虽然不能完全排除这种可能性（没有直接的注册确认实际写入了 PRESCALE 字段），但时间线强烈表明此事已经处理完毕。 实际症状 使用万用表探测物理 P11 引脚上的 CS0/CS1、MISO、MOSI、SCK，然后使用逻辑分析仪以 10–20 MSa/s 的采样率在 CS0 下降沿触发，同时不断重试传输（在循环中使用 spidev_test，以及通过 echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind 反复强制 mcp251x 重新探测）： CS0切换。经万用表和逻辑分析仪验证。 SCK 从不切换。平坦，无任何活动，无论持续尝试转移。 MOSI 从不切换。 两个 MCP2515 的故障情况完全相同：mcp251x spi2.0/spi2.1：MCP251x 在复位后未进入配置模式 / 探测失败，错误代码为 110 (ETIMEDOUT) — 即驱动程序自身的 SPI 级复位 + 读取 CANSTAT 序列未得到响应，这与 SCK 从未离开 SoC 的情况一致。 根本原因已缩小到时钟/总线访问，而非设备树。   # clk_enable_count AND clk_prepare_count are both 0, despite the controller # actively being used in a continuous retry loop $ 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 $ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count 0 即使 42550000.spi（真正的绑定消费者）正在循环中积极尝试传输（spidev_test 循环，以及通过 echo spi2.0 > /sys/总线/spi/drivers/mcp251x/bind 反复强制 mcp251x 重新探测），lpspi3 的功能（每个）时钟显示 clk_enable_count=0 和 clk_prepare_count=0。clk_prepare() 是 clk_enable()之前的步骤——它甚至从未被调用，这表明驱动程序的传输路径（或其前面的 pm_runtime_get()）从未到达该设备的时钟管理代码，而不是请求时钟然后无法开启。 我没有内核构建工具来添加跟踪点，所以我还无法判断这是 pm_runtime 恢复时静默执行空操作，还是缺少依赖项（例如，此板的 lpspi3 节点需要但没有的功率域引用），或者是此特定内核构建的 spi-fsl-lpspi.c 中的其他问题。 决定性的寄存器级测试——直接读取 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) 式访问限制，但 NXP 社区的几个帖子（i.MX25/i.MX6ULL“devmem 返回总线错误”，i.MX8MP I2C 来自 DSP 的帖子）指出，同样的症状是触摸时钟被关闭的 AIPS 总线外设的正常预期结果，而不一定是安全/域限制。这与上面的 clk_enable_count=0 一致，现在让我觉得这是该设备的驱动程序/PM 路径中的时钟使能错误，而不是（不一定）RDC 块——尽管在没有底层工具的情况下，我无法完全排除 RDC 的可能性。 这并非 i.MX93 LPSPI3 的普遍限制 上下文：NXP 社区的另一个帖子（[iMX93AUTO EVK] QCA7006AQ 的 SPI 配置，community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847）展示了如何使用 LPSPI3 在i.MX93-11x11-EVK （同一 SoC）的相同 GPIO_IO08-11 引脚上成功驱动外部 SPI 设备：   c &lpspi3 { compatible = "fsl,imx93-spi", "fsl,lpspi"; cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>; status = "okay"; ... }; &iomuxc { pinctrl_lpspi3_qca: lpspi3grp { fsl,pins = < MX93_PAD_GPIO_IO11__LPSPI3_SCK 0x3fe MX93_PAD_GPIO_IO10__LPSPI3_SOUT 0x3fe MX93_PAD_GPIO_IO09__LPSPI3_SIN 0x3fe MX93_PAD_GPIO_IO08__LPSPI3_PCS0 0x3fe /* native PCS0, not plain GPIO */ >; }; }; 我在 FRDM 板上尝试了完全相同的变体（使用原生 LPSPI3_PCS0/LPSPI3_PCS1 而不是普通的 GPIO2_IO08/GPIO2_IO07，加上显式兼容覆盖）——没有变化，devmem 0x42550000 32 仍然出错，clk_enable_count/clk_prepare_count 仍然为 0。这排除了引脚复用/兼容字符串选择是此板卡上的原因，并且——结合 EVK 的成功——让我怀疑是FRDM 板卡特有的问题（要么在 imx93-11x11-frdm.dts 中）。处理 lpspi3（或该板的 U-Boot/ATF 级 RDC/电源域设置）而不是一般的 i.MX93 SoC 或主线驱动程序的限制。 向恩智浦提出的问题 即使 SPI 内核正在积极地向绑定的 spi2.0/spi2.1 设备进行传输，lpspi3 的 clk_prepare_count/clk_enable_count 仍然保持为 0，并且普通的寄存器读取 0x42550000 会导致总线故障——FRDM-IMX93 的 lpspi3 设备树节点（或板级 RDC/电源域设置）缺少什么，而正常工作的 EVK 配置不需要这些？ FRDM-IMX93 上的 LPSPI3 是否故意保留给另一个功能域（例如，Cortex-M33 / 安全世界，或板载 MAYA-W2 三射频模块路径）在板的默认 RDC/ATF 配置下，与 EVK 不同？ 是否有类似 imx93-11x11-frdm-lpspi.dts 的参考文件，用于在该特定电路板上通过 P11 外部使用 LPSPI3？ 如何重现 底板 dtb：随 i.MX 版本 发行版镜像一起提供的标准 imx93-11x11-frdm.dtb（未修改的 NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v 节点 — 全部通过 __symbols__ 确认存在）。 应用上述覆盖（稳压器始终开启，pinctrl + cs-gpios + pinctrl-assert-gpios on &lpspi3; 尝试了 plain-GPIO 和 native-PCS0/PCS1 pinmux 变体，两次结果相同）。 手动将 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 的环回；无论如何，逻辑分析仪上的 SCK 都不会切换。 cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0。 devmem 0x42550000 32 → 总线错误。devmem 0x44380000 32 (LPUART1) → 正常成功。 如果需要，我很乐意提供完整的 overlay 源代码、dmesg 和 clk_summary/gpio 转储。

问题：修复 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