i.MX95: A55は電源投入も電源切断も完了せず、2つの異なるボードで同じように停止する。 概要 i.MX95のカスタムシステムマネージャ設定では、A55論理マシン(LM1)の起動は共有ドライバ関数 SRC_MixSoftPowerUp() (devices/MIMX9/drivers/fsl_src.c) for srcMixIdx = PWR_MIX_SLICE_IDX_A55P (index 11)でフリーズします。 SRC_MixPowerUpCompleted() 決して真を返さない、 FUNC_STAT 混合状態または不整合な状態でフリーズし、最終的にSM自身のWDOG2がFCCUリセットを実行します。 重要なのは、シーケンスが完全な電源オフ・オンサイクルを強制されるとき 電源停止要求も完了しない ハードウェアはこのミックスのソフトウェア電源制御に い ずれ 方向にも応答しないことです。 同じファームウェアは物理的に異なる2つのボード(FRDM-IMX95 15x/LPDDR4xおよびFRDM-IMX95-PRO 19x19/LPDDR5)で同じように停止しますが 、両ボードの工場出荷時のeMMCイメージは完全なLinuxユーザースペースで起動するため、シリコンや基板自体は実証的に対応可能です。 具体的な証拠（下記参照）に基づいて、多くの候補原因を除外することができました。残りの原因についてご助言いただければ幸いです。 環境 商品の価値 SoC i.MX95 (B0) ボード FRDM-IMX95 (15x15、LPDDR4x) そして FRDM-IMX95-PRO (19x19、LPDDR5) システムマネージャー nxp-imx/imx-sm で lf-6.18.20-2.0.0-5-g3198944 SM設定 カスタム（SMCT/.mex生成）、 ない mx95evk M33/SMステータス 完全に動作します M7ステータス 完全に動作 — SCMI、TRDCパーティショニング、STOP/SUSPEND/ディープアイドル、I2C、イーサネットMDIOはすべて機能しています A55 (LM1) 説明どおりに失敗する テストされたブートメディア SD そして eMMC（同一の結果） 兆候 A55はM7からオンデマンドでブートされます SCMI_LmmBoot() （手動でも再現可能） LM1ブート （SMデバッグモニターより）。 SCMI呼び出し自体は成功しました。 ステータス = 0 LM1はその後報告する SCMI_LMM_STATE_SUSPEND （状態＝2） 執行が停滞 SRC_MixSoftPowerUp() 待機中 SRC_MixPowerUpCompleted(PWR_MIX_SLICE_IDX_A55P) FUNC_STAT 400万回以上の投票反復の間、凍結されたままです。 制限が解除されると、SMのWDOG2監視ウォッチドッグがFCCUリセット（errId = 18）を実行し、M7を含むシステム全体がダウンします。 証拠を登録する SRC_XSPR_CORTEXMIX_PLATFORM （ミックスインデックス11） FUNC_STAT 凍結 0x00001010 または 0x00001011 入国時の状態によって異なります。 7 つのステータス フィールドを解読 PWR_MIX_FUNC_STAT_PUP/PDN: 観測されたフィールド状態 PSW_STAT 「アップ」パターン SSAR_STAT 「アップ」パターン A55_HDSK_STAT 「アップ」パターン SYSMAN_STAT 「アップ」パターン RST_STAT 「電源オフ」パターン ISO_STAT 「電源オフ」パターン MEM_STAT 「電源オフ」パターン これは、完全に電源が入った状態でも、完全に電源が切れた状態でも一致しない、矛盾した状態であり、進行しません。 ハードウェア測定 スコープが取り付けられました VDD_ARM (出力キャップC211–C215、インダクタL7の後、DCDCの離散PPF5301下流に設置され、このボードには専用ARMレールが搭載されています。その間 LM1ブート 試み： 鉄道はすでに稼働しています 約0.92V 試み それ 目に見えて低下する 試み つまり、これは単なる権限やタイミング、ソフトウェアのアーティファクトではなく、物理的に観察可能な不完全な電力移行です。 最も有益な単一データポイント A55Pミックスに対して電源オフと電源オンのサイクル全体を無条件に強制する（ MEM_STAT == 0 ゲート — つまり SLICE_SW_CTRL |= PDN_SOFT、待機 電源オフ完了、 SLICE_SW_CTRL &= ~PDN_SOFT、待機 PowerUpCompleted) は、 明示的な電源オフ要求さえも完了しない。 FUNC_STAT 待機中ずっと変化しない。 これは、問題がSRCレジスタインターフェースの下にあることを示唆しており、例えばGPCハンドシェイクの前提条件、SRCブロック自体へのクロックの欠如、ボードやPMICの応答問題などがあり、 SRC_MixSoftPowerUp()自身のシーケンスロジックで修正可能な問題ではないことを示唆しています。 既に調査済みで、証拠に基づき除外済み PERF_A55 口論 (3 → 0、ODV → PRK 電圧レベル) — どちらの値でもバイトが同一で障害が発生します。DVS/電圧レベルの不一致は除外されます。 config_bctrl.h (SM_BCTRL_A_CONFIG) / SM_BCTRL_W_CONFIG) — 私の設定では空でした。 mx95evkの値は何も変更されませんでした。それから私はライブレジスターを読みました 稼働中の工場システム SMモニター経由（BLK_CTRL_NS_AONMIX） 0x44210008–0x44210024、 BLK_CTRL_WAKEUPMIX 0x42420030–0x42420064) — すべての言葉が一致しました mx95evk 正確に参照してください。 SM_A55P_CONFIG、 config_user.h、TRDC SRC/GPC/ANATOP の許可、WDOG2 タイムアウト — 全て同一であることが確認されました mx95evk は、ブロッカーではないことが確認されています。(SM自身のDOM2 TRDCアクセスはこれらのレジスタに実際に動作しており、レジスタ値の変更を読み書きできます。)注記 SM_A55P_CONFIG そして SM_DDR_CONFIG 空です mx95evk 自身の設定ファイルも。 SRC_MixIsPwrReady() guard — 正しい論理ですが、ここでは正当にfalse(混合ビット状態)を返すため、動作は変わりません。 無条件 SRC_MixSetA55HdskMode(..., ACK_WAIT) — 効果なし。 A55_HDSK_STAT 最初から最後まで正しい「上向き」のパターンだった。 より新しいSMファームウェア — ピン留めされた SRCREV を walnascar → whinlatter スパンにわたって差分化しました: 変更なし に デバイス/MIMX9/ （含む fsl_src.c、 dev_sm_cpu.c、 dev_sm_power.c) uboot-imx 違い — リリースごとに実際の違いは存在するが、どれも PD_A55P/SRC_XSPR/A55 の電源投入。これは構造的にも真実です。U-Boot SPL は A55号線で、つまりこのパワーアップが既に成功した後にのみ有効です。 ERR053228アナログ(MTR_ACK_CTRL) — i.MX95には、ミックスごとの MTR_ACK_CTRL/MTR_ACK_STAT ハンドセイク(オフセット0x90/0x94)があり、そのリセットデフォルト(CNT_MODE = 0)はハードウェアMTRのアクセントを無期限に待ち、これはスティック MEM_STATに十分にマッチしているように見えました。私が書いた CNT_MODE = 3 （タイムアウトモード）最大 MTR_CNT_CFG 電源投入遷移前に書き込みが有効になることをリードバックで確認しました（いいえ LOCK_CFG 干渉）。 変更なし。 実際の工場APバイナリ — 抽出済み bl31.bin / tee.bin / u-boot* このボードの既知の正常な工場eMMCイメージからそれらを構築し、 flash.bin 変更なし （U-Bootの最初の命令の前に停止が発生するため、これは想定内の動作である。） ヒューズ/OTP — 除外: ヒューズはダイごとに一度焼却され、工場出荷時のイメージと私のイメージは 同じ物理的な基板。 ブーツミディアム SDカードとeMMCの両方をテストした結果、同一であった。 ファクトリーSMバイナリの由来 これは特に強調しておきたい点です。なぜなら、「NXPは別のSMビルドを出荷している可能性がある」という可能性を排除できるからです。工場出荷時の eMMC の M33 イメージ (ROM コンテナ 3、イメージ 3、 CORE_CM33、コンテナ相対オフセット 0x79000、サイズ 0x2C800) を使用 mkimage_imx8 -soc IMX9 -parse を実行し、抽出を検証しました。 コンテナ自身の記録されたハッシュとの完全なSHA384一致。その建築バナーにはこう書かれている。   SMからのメッセージです（ビルド819、コミットc450f539、2026年3月9日 03:24:50）   c450f539 は (git merge-base --is-ancestor) であることが確認されています。 私のビルドの直接の祖先であり、唯一の介入コミットは fsl_src.c/dev_sm_cpu.c/dev_sm_power.c これは、機能的な変更を一切伴わない、純粋なテスト用足場のクリーンアップです。 A55を正常に起動させる工場出荷時イメージは、私の場合失敗したSMソースと同じ機能的に動作しています。 質問 工場出荷時イメージが機能的に同一のSMソースでA55を起動するのを踏まえると、 outside imx-sm sourceとBCTRLレジスタ構成の違いは何でしょうか?A55Pミックスの電源アップを妨げる可能性があるのです。具体的には、AHAB/ELEコンテナ署名やプロビジョニングのメタデータがA55プラットフォームの電源供給に影響するのでしょうか? 観測された FUNC_STAT パターン (PSW/SSAR/A55_HDSK/SYSMAN) 上、 RST/ISO/MEM （前進ではなく下降）既知の署名？その状態から次にどのような変化が起こると予想されるのか、そしてその変化を促す要因は何なのか？ なぜ明示的な電源オフ リクエストも完了しないのですか？ それが最も有力な手がかりのようだ。 SRC_XSPR 応答する SLICE_SW_CTRL.PDN_SOFT このミックスには全く関係ない？ ERR053228以外に、A55Pミックス電源シーケンスに影響を与える既知のi.MX95 B0のエラーはありますか？ A55プラットフォームのミックスに対して、reference mx95evk flowには存在しつつ、生成された config_*.hでは表現 されていない初期化が必要ですか  ファイル ― つまり、カスタム SMCT ベースの設定では暗黙のうちに省略されるもの？ 備考 PROボードにはJTAGが搭載されていない（ヘッダーがない）ため、15x15ボード上の脆弱な0.5mmテストパッドは使用しないことにしました。 上記の診断はすべてSM独自のデバッグモニター（lm info、 えーっと、 btime、 MD）、直接レジスタ読み取り、およびスコープ測定。 私はコンテインメント修正を導入しています(元の無制限の待機が有界待ちを置き換えます その間(!SRC_MixPowerUpCompleted()) {;} ループ)を導入し、障害がスムーズに LM1 = 停止 に劣化するようにしています。ウォッチドッグのようにシステム全体をリセットするのではなく。もしお役に立つようでしたら、別途お教えいたします。 Re: i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards 上記の投稿は無視して、チケットを閉じてください。先ほどwrynoseを使って新規ビルドをしてみましたが、うまくいきました！以前のビルドではwhinlatterを使用していましたが（FRDM-IMX95に同梱されていたため選択しました）、うまくいきませんでした。

i.MX93 parallel diaply interface Hi, I am designing a board with i.MX93 (MIMX9332CVVXMAC) that has to drive a RGB display with parallel interface. From config tool the data bit are lebelled data0-23 without reference to R,G,B channel. I have also looked at evb FRDM and TM050RDH03-41, unfortunately on FRDM the data are as in config tool and the schematic of TM050RDH03-41 is not provided. Is it possible to have such schematic for confirmig the pinout? Or can you confirm me that the 24 bits can be muxed between channels R G and B freely? Thank you, Enrico Re: i.MX93 parallel diaply interface Hi, Thank you for your interest in NXP Semiconductor products, Please see the TM050RDH03-41 display connector schematic, if you are interested in the full schematic, please create a technical case. JosephAtNXP_0-1789574219944.pngJosephAtNXP_0-1789574219944.png Regards

有人用TapLinx吗？ 有人使用 NXP 的 TapLinx SDK 与 MIFARE 卡进行交互吗？ 我对一些最简单的控制台应用程序示例很感兴趣。这个示例应用程序有点难用，因为它是一个带有大量功能的图形用户界面应用程序。 我想找一些功能最简化的控制台应用程序，它们只需要对卡进行读写操作、身份验证等。 如果是 Kotlin 示例就更好了，但 Java 示例也可以。 入门指南 Re: Anyone using TapLinx? 你好@reid88 TapLinx SDK 支持 MIFARE DESFire、Plus、Classic、Ultralight、NTAG 等。您可以通过以下方式查看设计资源： TapLinx SDK for MIFARE, NTAG, ICODE and UCODE | NXP 半导体

i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards Summary On a custom System Manager configuration for i.MX95, booting the A55 logical machine (LM1) hangs inside the shared driver function SRC_MixSoftPowerUp() (devices/MIMX9/drivers/fsl_src.c) for srcMixIdx = PWR_MIX_SLICE_IDX_A55P (index 11). SRC_MixPowerUpCompleted() never returns true, FUNC_STAT freezes in a mixed/inconsistent state, and SM's own WDOG2 eventually fires an FCCU reset. Critically, when the sequence is forced to do a full power-down-then-up cycle, the power-down request never completes either — the hardware does not respond to software power control for this mix in either direction. The same firmware stalls identically on two physically different boards (FRDM-IMX95 15x15/LPDDR4x and FRDM-IMX95-PRO 19x19/LPDDR5), while both boards' factory-shipped eMMC images boot to a full Linux userspace, so the silicon and boards themselves are demonstrably capable. I have been able to rule out a large number of candidate causes with concrete evidence (listed below) and would appreciate guidance on what remains. Environment Item Value SoC i.MX95 (B0) Boards FRDM-IMX95 (15x15, LPDDR4x) and FRDM-IMX95-PRO (19x19, LPDDR5) System Manager nxp-imx/imx-sm at lf-6.18.20-2.0.0-5-g3198944 SM config Custom (SMCT/.mex-generated), not mx95evk M33/SM status Fully working M7 status Fully working — SCMI, TRDC partitioning, STOP/SUSPEND/deep-idle, I2C, Ethernet MDIO all functional A55 (LM1) Fails as described Boot media tested SD and eMMC (identical results) Symptom A55 is booted on demand from M7 via SCMI_LmmBoot() (also reproducible manually with lm LM1 boot from the SM debug monitor). The SCMI call itself succeeds: status = 0 LM1 then reports SCMI_LMM_STATE_SUSPEND (state = 2) Execution stalls in SRC_MixSoftPowerUp() waiting on SRC_MixPowerUpCompleted(PWR_MIX_SLICE_IDX_A55P) FUNC_STAT remains frozen for 4,000,000+ poll iterations Left unbounded, SM's WDOG2 supervisory watchdog fires an FCCU reset (errId = 18), taking down the whole system including M7 Register evidence SRC_XSPR_CORTEXMIX_PLATFORM (mix index 11) FUNC_STAT freezes at 0x00001010 or 0x00001011 depending on entry state. Decoding the seven status fields in PWR_MIX_FUNC_STAT_PUP/PDN: Field Observed state PSW_STAT "up" pattern SSAR_STAT "up" pattern A55_HDSK_STAT "up" pattern SYSMAN_STAT "up" pattern RST_STAT "powered-down" pattern ISO_STAT "powered-down" pattern MEM_STAT "powered-down" pattern This is an inconsistent state that matches neither a fully-powered-up nor a fully-powered-down condition, and it does not advance. Hardware measurement A scope was placed on VDD_ARM (output caps C211–C215, after inductor L7, downstream of the discrete PPF5301 DCDC — this board has a genuine dedicated ARM rail). During an lm LM1 boot attempt: The rail is already live at ~0.92 V before the attempt It visibly drops during the attempt So this is a real, physically observable incomplete power transition, not purely a permissions/timing/software artifact. Most informative single data point Forcing the entire power-down-then-up cycle unconditionally for the A55P mix (bypassing the MEM_STAT == 0 gate — i.e. SLICE_SW_CTRL |= PDN_SOFT, wait PowerDownCompleted, SLICE_SW_CTRL &= ~PDN_SOFT, wait PowerUpCompleted) shows that even the explicit power-down request never completes. FUNC_STAT is unchanged for the entire wait. This suggests the problem sits below the SRC register interface — e.g. a GPC handshake precondition, a missing clock to the SRC block itself, or a board/PMIC response issue — rather than anything correctable in SRC_MixSoftPowerUp()'s own sequencing logic. Already investigated and ruled out (with evidence) PERF_A55 argument (3 → 0, ODV → PRK voltage level) — byte-identical failure at either value. Rules out a DVS/voltage-level mismatch. config_bctrl.h (SM_BCTRL_A_CONFIG / SM_BCTRL_W_CONFIG) — was empty in my config; populating it with mx95evk's values changed nothing. I then read the live registers on the working factory system via the SM monitor (BLK_CTRL_NS_AONMIX 0x44210008–0x44210024, BLK_CTRL_WAKEUPMIX 0x42420030–0x42420064) — every word matched the mx95evk reference exactly. SM_A55P_CONFIG, config_user.h, TRDC SRC/GPC/ANATOP grants, WDOG2 timeout — all confirmed identical to mx95evk, or confirmed not to be the blocker. (SM's own DOM2 TRDC access to these registers demonstrably works — I can read and write changing register values.) Note SM_A55P_CONFIG and SM_DDR_CONFIG are empty in mx95evk's own config too. SRC_MixIsPwrReady() guard — correct logic, but it legitimately returns false here (mixed bit state), so it never changes behaviour. Unconditional SRC_MixSetA55HdskMode(..., ACK_WAIT) — zero effect; A55_HDSK_STAT was already in the correct "up" pattern throughout. Newer SM firmware — diffed the pinned SRCREVs across the walnascar → whinlatter span: zero changes to devices/MIMX9/ (including fsl_src.c, dev_sm_cpu.c, dev_sm_power.c). uboot-imx differences — real differences exist across releases, but none touch PD_A55P/SRC_XSPR/A55 power-up. This is also true by construction: U-Boot SPL runs on A55, i.e. only after this power-up has already succeeded. ERR053228 analog (MTR_ACK_CTRL) — i.MX95 has a per-mix MTR_ACK_CTRL/MTR_ACK_STAT handshake (offset 0x90/0x94) whose reset default (CNT_MODE = 0) waits indefinitely for a hardware MTR ack, which looked like a plausible match for the stuck MEM_STAT. I wrote CNT_MODE = 3 (timeout mode) with max MTR_CNT_CFG before the power-up transition and confirmed via readback that the write takes effect (no LOCK_CFG interference). No change. Real factory AP binaries — extracted bl31.bin / tee.bin / u-boot* from this board's own known-good factory eMMC image and built them into my flash.bin. No change (expected, since the stall precedes U-Boot's first instruction). Fuses/OTP — ruled out: fuses are burned once per die, and the factory image and my image run on the same physical board. Boot medium — SD and eMMC both tested, identical. Factory SM binary provenance — this one I want to highlight, because it closes off "maybe NXP ships a different SM build". I extracted the factory eMMC's own M33 image (ROM container 3, image 3, CORE_CM33, container-relative offset 0x79000, size 0x2C800) using mkimage_imx8 -soc IMX9 -parse, and verified the extraction by exact SHA384 match against the container's own recorded hash. Its build banner reads:   Hello from SM (Build 819, Commit c450f539, Mar 09 2026 03:24:50)   c450f539 is confirmed (git merge-base --is-ancestor) to be a direct ancestor of my own build, and the only intervening commit touching fsl_src.c/dev_sm_cpu.c/dev_sm_power.c is pure test-scaffolding cleanup with no functional change. So the factory image that successfully boots A55 is running functionally the same SM source that fails for me. Questions Given that the factory image boots A55 with functionally identical SM source, what differs outside imx-sm source and the BCTRL register configuration that could gate A55P mix power-up? Specifically, is there AHAB/ELE container signing or provisioning metadata that affects whether the A55 platform mix can be powered up? Is the observed FUNC_STAT pattern (PSW/SSAR/A55_HDSK/SYSMAN up, RST/ISO/MEM down, not advancing) a known signature? What is the expected next transition from that state, and what drives it? Why would the explicit power-down request also never complete? That seems the strongest clue — what preconditions must hold for SRC_XSPR to respond to SLICE_SW_CTRL.PDN_SOFT at all for this mix? Is there a known i.MX95 B0 erratum affecting A55P mix power sequencing beyond ERR053228? Is there any required initialisation for the A55 platform mix that is present in the reference mx95evk flow but not expressed in the generated config_*.h files — i.e. something a custom SMCT-based config would silently omit? Notes JTAG is not available on the PRO board (no header), and I have chosen not to use the fragile 0.5 mm test pads on the 15x15 board. All diagnosis above was done via SM's own debug monitor (lm info, err, btime, md), direct register reads, and scope measurement. I have a containment fix in place (bounded waits replacing the original unbounded while (!SRC_MixPowerUpCompleted()) {;} loops) so that the failure now degrades gracefully to LM1 = suspended instead of watchdog-resetting the entire system. Happy to share that separately if useful. Re: i.MX95: A55 never completes power-up or power-down — stalls identically on two different boards Please disregard the post above and close the ticket... I just did a fresh build with wrynose and it works! My previous builds were with whinlatter (selected because that's what the FRDM-IMX95 shipped with), but that didn't work.

S32K3X4EVB-T172 OpenSDAを使用してプログラムできません 私は新品の S32K3X4EVB-T172 Eval ボードを持っています。S32 プロセッサは工場出荷時のデフォルトコードを実行しているようですが、USBでパソコンに接続したオンボードのデバッガでデバッグや再プログラムを試みると、S32もオンボードのデバッガもリセットされてしまいます。 S32K3X4EVB-T172クイックスタートガイドに記載されている正しい電源オン/接続手順を使っています。また、そこに記載されているソフトウェアやアドオンもインストールしています。 同僚のS32K3X4EVB-Q172で同じ手順を試したところ、問題なく動作しました。 よろしくお願いいたします。 -トビア Re: S32K3X4EVB-T172 Unable to Program using OpenSDA 1. 議論を参照してください: S32K3X4EVB-T172 での PEmicro Connection Assistant の問題。赤色LED D15 （RST_OSDA）とD3 （RESET_K3）は点灯したままですか、それとも定期的に点滅しますか？あなたのボードもこのお客様と同じ問題を抱えていますか?   2. FS26(U12)はホットですか？ 3. 「 3.2 電源を接続する」の手順、そして「3.3デバッガーケーブルを接続しますか？ 4. J40マイクロUSBケーブルを接続し、 D14 STATUS OSDA LEDを確認します。 D14のオレンジ色LEDが点灯しない場合は、USBケーブルがデータケーブルかどうか、PCがOpenSDAデバイスを列挙しているか、USBポートとドライバが正しく動作しているか確認してください。USBケーブルをUSBハブ経由でPCに接続することは推奨されません。 5. オンボードデバッガはPEMicroが提供しており、「 Multilink Debug Probes 」の 「サポート & Downloads」カテゴリから 最新の 「USB Multilink Resources Installer 」をダウンロードすることをお勧めします 。インストール後、 C:\PEMicro\Multilink_Resourcesの中からPEFirmwareConfig.exeを開き、ファームウェアのバージョンを確認してください。私のオンボードデバッガーのファームウェアバージョンは 10.98 です。あなたのボードのバージョンは何ですか?バージョンが古すぎる場合は、アップデートを推奨します。アップデートが失敗した場合は、PEMicroの技術サポートに お問い合わせ することをお勧めします。 check the version of firmware on S32K3X4EVB-T172.pngS32K3X4EVB-T172.pngのファームウェアのバージョンを確認してください。 6. マルチメーターを電圧モードで使用するか、オシロスコープを使用してP3V3_SDA（J34 ）の電圧を観察してください。 S32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.png 7. SDA_RST_TGTMCUは、オンボードデバッガK26の出力によって制御されます。SDA_RST_TGTMCUが低レベルを出力すると、赤色LED D15とD3の両方が点灯します。 オシロスコープを使用して、 SDA_RST_TGTMCU（J36）レベルを監視してください。常に低い値を示すのか、それとも定期的に低い値を示すのか？ 通常、オンボードデバッガを使用してプログラムをダウンロードしたり、S32K3をリセットしたりすると、 SDA_RST_TGTMCUに10msのローレベルが観測され、赤色LED D15とD3が短時間点灯します。 8. J12経由で接続した後、外部デバッガを使用してオンボードのS32K3チップをデバッグすることは可能ですか？ よろしくお願いいたします ロビン

Intermittent I2C read failure at boot with PCF85263A using hwclock (400kHz vs 100kHz) Hello NXP Community, Our custom board (using the PCF85263A RTC and AM6252) reads the RTC time exactly once during the initial boot sequence using the following command: hwclock -u -s We are experiencing an intermittent issue where it fails to fetch the RTC value approximately 1 out of 1,000 times. (However, if it fails and we immediately retry the read command, it successfully fetches the time without any issues.) During our troubleshooting, we lowered the I2C clock frequency from 400kHz to 100kHz (400000 -> 100000) under the exact same conditions. After this change, we conducted nearly 6,000 test iterations and the system operated perfectly without a single failure. According to the PCF85263A datasheet, it supports a maximum I2C-bus frequency of 400kHz (Fast-mode). Could you please advise: Are there any known issues, errata, or similar historical reports regarding this intermittent I2C read failure with the PCF85263A at 400kHz? Are there any specific configurations, bus capacitance/pull-up resistor considerations, or debugging steps you would recommend to resolve this while maintaining the 400kHz clock? Thank you in advance for your support. Re: Intermittent I2C read failure at boot with PCF85263A using hwclock (400kHz vs 100kHz) Hello Iseori, There are no known errata or documented hardware issues with the PCF85263A itself at 400 kHz I²C operation. The part is specified and production-tested up to 400 kHz, and the behavior you describe is a classic symptom of marginal timing compliance on the host controller or bus side rather than a defect in the PCF85263A. Recommended debugging steps: - Scope the I²C bus at 400 kHz and capture SCL/SDA waveforms. Verify that Tlow ≥ 1.3 µs, Thigh ≥ 0.6 µs, Tr ≤ 300 ns, and Tf ≤ 300 ns during the RTC read transaction. Compare against the timing requirements in Table 68 of the PCF85263A datasheet. - Check AM6252 errata for any known I²C 400 kHz SCL low-period violation. If present, reduce the I²C clock to 375–384 kHz, which typically restores full margin while remaining near 400 kHz in practice. - Review pull-up resistor values in your schematic. If they are higher than ~2.2 kΩ, replace with 1 kΩ–2.2 kΩ and re-test at 400 kHz. - Verify single-access reads: The PCF85263A requires that all time registers be read in a single I²C access to prevent roll-over corruption.  BRs, Tomas

使用硬件时钟（400kHz 对比 100kHz）的 PCF85263A 在启动时出现间歇性 I2C 读取失败 NXP社区的各位朋友，大家好！ 我们的定制板（使用 PCF85263A RTC 和 AM6252）在初始启动序列期间使用以下命令读取一次 RTC 时间： hwclock -u -s 我们遇到了一个间歇性问题，大约每 1000 次操作中会有 1 次无法获取 RTC 值。 （但是，如果读取失败，我们立即重试READ命令，则可以成功获取时间，没有任何问题。） 在故障排除过程中，我们在完全相同的条件下将 I2C 时钟频率从 400kHz 降低到 100kHz (400000 -> 100000)。经过这一改变，我们进行了近 6000 次测试迭代，系统运行完美，没有出现任何故障。 根据 PCF85263A 数据手册，它支持的最大 I2C 总线频率为 400kHz（快速模式）。 请问您能否提供以下建议： 关于 PCF85263A 在 400kHz 频率下间歇性 I2C 读取失败的问题，是否有任何已知的错误、勘误或类似的历史报告？ 在保持 400kHz 时钟频率的同时解决此问题，您有什么具体的配置、总线电容/上拉电阻方面的考虑因素或调试步骤可以推荐吗？ 感谢您提前给予的支持。 Re: Intermittent I2C read failure at boot with PCF85263A using hwclock (400kHz vs 100kHz) 你好，伊势里 PCF85263A 本身在 400 kHz I²C 操作下没有已知的错误或已记录的硬件问题。该器件的规格和生产测试均达到 400 kHz，您所描述的行为是主机控制器或总线侧时序一致性不足的典型症状，而不是 PCF85263A 的缺陷。 建议的调试步骤： - 以 400 kHz 的频率示波 I²C 总线，并捕获 SCL/SDA 波形。在 RTC 读取事务期间，验证 Tlow ≥ 1.3 µs、Thigh ≥ 0.6 µs、Tr ≤ 300 ns 和 Tf ≤ 300 ns。与 PCF85263A 数据手册表 68 中的时序要求进行比较。 - 检查 AM6252 勘误表，查看是否存在已知的 I²C 400 kHz SCL 低电平期间违例。如果存在，请将 I²C 时钟频率降低到 375–384 kHz，这样通常可以恢复全部裕量，同时在实践中保持在接近 400 kHz 的频率。 - 检查原理图中上拉电阻的值。如果阻值高于约 2.2 kΩ，则替换为 1 kΩ–2.2kΩ，并在 400 kHz 下重新测试。 - 验证单次读取：PCF85263A 要求所有时间寄存器必须在一次 I²C 访问中读取完毕，以防止数据溢出损坏。 BRs，托马斯

MRF13750H AWR MODEL Hello, I am trying to import the MRF13750H transistor model into Cadence AWR Microwave Office using the official design files provided on your website. After downloading both the design kit and the transistor model an error is generated when attempting to open the model. I have attached a screenshot of the error message. Luis_V_0-1789581238483.png I have already contacted technical support at cadence. Their team attempted to download and open the model as well, and they confirmed that they encountered the exact same issue. Could you please verify these files and let me know how to resolve this? Best, Luis V. RF Re: MRF13750H AWR MODEL Hello Luis_V Good day! The error is due to compatibility issues. The model you are trying to install is quite old and was designed for earlier versions of AWR Design Environment. Currently, there are no plans to update it for newer versions of the software. If you need to use this model, the most practical solution is to install an older version of AWR, such as one from around 2015 (for example, AWR v11 or v12), which is compatible with this model. This should allow you to work without encountering the GetIAwrUserIO DLL error. We apologize for any inconvenience this may cause. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

PCF85263Aをハードウェアクロック（400kHz vs 100kHz）で使用した場合、起動時にI2C読み取りエラーが断続的に発生する。 こんにちは、NXPコミュニティの皆さん、 当社独自のボード（PCF85263A RTCとAM6252を使用）は、初期起動シーケンス中に以下のコマンドを使用してRTC時刻を一度だけ読み取ります。 hwclock -u -s 約1,000回に1回の割合で、RTC値の取得に失敗するという断続的な問題が発生しています。 （ただし、もし失敗してすぐに読み取りコマンドを再試行した場合、問題なく時刻を取得できます。） トラブルシューティングの過程で、全く同じ条件下でI2Cクロック周波数を400kHzから100kHz（400000→100000）に下げました。この変更後、約6,000回のテストを繰り返し実施しましたが、システムは一度も故障することなく完璧に動作しました。 PCF85263Aのデータシートによると、最大I2Cバス周波数400kHz(ファストモード)をサポートしています。 何かアドバイスをいただけますか: PCF85263Aを400kHzで使用した場合に発生する、この断続的なI2C読み取りエラーに関して、既知の問題、エラー、または同様の過去の報告はありますか？ 400kHzクロックを維持しつつ解決するために、特定の構成やバスの静電容量/プルアップ抵抗の考慮点、またはデバッグの手順があれば教えてください。 あらかじめサポートに感謝いたします。 Re: Intermittent I2C read failure at boot with PCF85263A using hwclock (400kHz vs 100kHz) こんにちは、伊勢織さん。 PCF85263A自体には、400kHzのI²C動作において、既知の不具合や文書化されたハードウェアの問題はありません。この部品は400kHzまで仕様・生産テストされており、あなたが述べた挙動は、PCF85263Aの欠陥というよりも、ホストコントローラやバス側のタイミング準拠が限界的であることの典型的な症状です。 推奨されるデバッグ手順： - I²Cバスを400kHzでオシロスコープし、SCL/SDA波形をキャプチャします。RTC読み出しトランザクション中に、Tlow ≥ 1.3 µs、Thigh ≥ 0.6 µs、Tr ≤ 300 ns、および Tf ≤ 300 ns であることを確認してください。PCF85263Aのデータシートの表68に記載されているタイミング要件と比較してください。 - AM6252の正誤表を確認し、既知のI²C 400kHz SCL低周期違反がないか確認してください。I²Cクロックが存在する場合は、クロック周波数を375～384kHzに下げてください。これにより、通常は十分なマージンが回復し、実際には400kHz付近を維持できます。 回路図中のプルアップ抵抗の値を確認してください。抵抗値が約2.2 kΩより高い場合は、1 kΩ–2.2 に置き換えてください。kΩで測定し、400kHzで再測定する。 - シングルアクセス読み取りの検証:PCF85263Aはロールオーバー破損を防ぐために、すべてのタイムレジスタを単一のI²Cアクセスで読み取ることを要求しています。 BRs、トーマス

i.MX93 パラレルダイアプリインターフェース こんにちは、 私はi.MX93(MIMX9332CVVXMAC)を搭載した基板を設計しており、並列インターフェースを持つRGBディスプレイを駆動する必要があります。設定ツールからは、R,G,Bチャネルを参照せずにデータ0-23のlebelledデータビットが割り当てられています。evb FRDMとTM050RDH03-41も調べてみましたが、残念ながらFRDMのデータは設定ツールと同じで、TM050RDH03-41の回路図は提供されていませんでした。 ピン配置を確認するための回路図を入手することは可能でしょうか？ それとも、24ビットがR、G、Bのチャネル間で自由にマルチパクシングできるのか確認できますか? ありがとうございました。 エンリコ Re: i.MX93 parallel diaply interface こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 TM050RDH03-41ディスプレイコネクタの回路図をご覧ください。完全な回路図に興味がある場合は、技術CASEを作成してください。 JosephAtNXP_0-1789574219944.pngJosephAtNXP_0-1789574219944.png よろしくお願いします。

SE052 采用问题：EdDSA/X25519 可用性、非 FIPS 变体路线图、小程序限制 你好， 我们目前使用的是SE050E2 （小程序 7.2.0，在两个设计中，芯片报告为“SE051”（ATR，AppletConfig 0x3F9F），我们正在评估SE052，以用于下一个硬件版本。在做出决定之前，我们阅读了 SE052 数据表（修订版 1.5）、AN14028、AN14277、AN13904、AN12543（修订版 4.5）和 Plug & Trust MW 文档（AN13030 修订版 2.7），但有几点阻碍了我们做出决定。希望您能澄清一下。 我们的两个应用案例： 一个网状/传输节点（LoRa + 以太网），其标识为 X25519 + Ed25519 在 SE 内部生成和使用的密钥对（通过 ECDH） ECDH生成共享密钥 在 ID_ECC_MONT_DH_25519，通过以下方式签名 EdDSASign 和 ED25519PURE_SHA_512）。 使用签名设备 secp256k1 ECDSA （预先计算的摘要）和 Ed25519 针对不同的目标，使用受用户 ID 保护的会话。 问题： 变体。AN14277 指出 SE052F (OEF B501, FIPS 140-3) 是“唯一发布的变体”，其 GetInfo 显示没有 EDDSA / 没有 DH_MONT。是否有针对非 FIPS SE052 配置（相当于启用 CONFIG_EDDSA 和 CONFIG_DH_MONT 的 SE050E / SE051）的路线图？如果属实，大致时间范围和OEF是多少？ 在 SE052F 上启用 EdDSA / Montgomery DH。由于 SetAppletFeatures 需要 RESERVED_ID_FEATURE (0x7FFF0204)，而 RESERVED_ID_FEATURE 是 NXP 拥有的，那么客户是否有任何途径在 SE052F 上启用 Ed25519/X25519（例如，通过 EdgeLock 2GO 进行自定义配置），同时接受失去 FIPS 批准模式？或者说，无论小程序功能位如何，FIPS OS 版本都会阻止这些曲线？ FIPS 和 EdDSA。FIPS 186-5 批准 EdDSA。未来是否有计划推出支持 Ed25519 和 X25519 且符合 FIPS 140-3 标准的未来 SE052 小程序/操作系统版本（通过 SEMS Lite 或新的 OEF）？ APDU吞吐量限制。AN14028 §2.3.1 / AN13904 §8.4 描述了 1,000,000 APDU / 34 天的限制 (SW 66A6) 以及每 500,000 APDU 进行一次 FIPS 自检。这些是否仅与 FIPS 认证有关，在假设的非 FIPS SE052 变体中是否会缺失？通过 RST_N 重置是否足以清除计数器而不会对 NVM 产生影响？ 针对签名用例的 Applet 功能路线图。我们在 AN12543 Rev 4.5 中找不到以下任何内容。7.2.x 版本有相关计划吗？一行代码还是未来的小程序？ SE 内部强化了子密钥派生（标量加法 mod n，BIP32 风格），因此派生的私钥永远不会离开芯片。 secp256k1 上的 Schnorr 签名 (BIP340)。 确定性 ECDSA nonce（RFC 6979）和/或低 S 归一化。 预哈希 Ed25519 (Ed25519ph) 或流式 EdDSA 模式，因此长度超过 IFSC (0xFE) 的消息不依赖于 T=1 链接。 小程序 7.2.22 中的 UserID 行为。在 SE050E2 (7.2.0) 中，我们观察到，TAG_MAX_ATTEMPTS 耗尽的 UserID 对象无法再被删除（即使在 SCP03 平台上，DeleteSecureObject → 6986），并且尝试计数器属性始终显示为 0。AN14028 表 1 指出，属性现在显示最大尝试次数。2022年7月2日：（a）是否报告剩余/已用计数器？（b）SCP03 平台用户能否删除已耗尽的 UserID？ ECDH NVM 磨损（也适用于我们目前的 SE050E2）。AN12543 §4.10.3 指出，当公钥作为字节数组（TAG_2）传递时，MONT_DH_25519 上的 ECDHGenerateSharedSecret 会在每次调用时写入 NVM，但当通过瞬态ECPublicKey 对象（TAG_3）传递时则不会写入 NVM。您能否确认这同样适用于带有 applet 7.2.0 的 SE050E，并且在调用之间使用 WriteECKey 更新瞬态对象的内容本身不会写入 NVM？ 长寿。SE050E2 是否在恩智浦的产品生命周期计划范围内？是否有计划中的产品生命周期结束？这将决定我们下一次修订是否继续使用 SE050E2 版本。 提前谢谢您。 SE050 Re: SE052 adoption questions: EdDSA/X25519 availability, non-FIPS variant roadmap, applet limits 嗨@cvaldess ， 感谢您的联系！让我逐一解答。 第一季度 — 非 FIPS SE052 变体路线图 正如您正确指出的那样，SE052F (OEF B501) 目前是唯一发布的 SE052 变体，其 AppletConfig 0x26F2 不包含 EdDSA 或 DH_MONT。我们不能在公共论坛上分享具体的路线图时间表，但我建议您联系当地的 Disti/NXP FAE，在签署保密协议 (NDA) 的情况下讨论您的需求，届时可以直接讨论路线图细节。 Q2 — 在 SE052F 上启用 EdDSA / Montgomery DH SE052F 上没有客户路径可以启用这些算法。 RESERVED_ID_FEATURE (0x7FFF0204) 是 NXP 拥有的对象，客户无法修改或删除它——EdgeLock2GO 不是启用它的机制。更根本的是，SE052F FIPS 140-3 OS 版本在认证配置中排除了操作系统/硬件级别的 Twisted Edwards (Ed25519) 和 Montgomery (Curve25519) 曲线支持。即使通过 SEMS Lite 加载自定义小程序也无法重新启用操作系统层中不存在的曲线——而且这样做无论如何都会使模块不符合 FIPS 标准，正如 AN14277 明确指出的那样。 第三季度——未来 SE052 小程序/OEF 将支持 FIPS 140-3 和 EdDSA。 FIPS 186-5（2023 年 2 月）确实批准了 EdDSA，因此标准基础是存在的。但是，任何在新 FIPS 140-3 证书下支持 Ed25519/X25519 的 SE052 OEF 都需要提交完整的 CMVP 重新认证申请。我们不便在公共场合确认相关计划或时间表。请与您当地的 Disti/NXP FAE 联系，就此问题进行保密协议 (NDA) 谈判。 第四季度 — APDU 吞吐量限制（SW 66A6） 是的，1,000,000 APDU / 34 天计数器和 500,000 APDU 定期自检是 FIPS 140-3 合规性要求，专门针对 SE052F。假设存在非 FIPS SE052 变体，则该变体不受这些限制。 关于 RESET：T=1oI2C 芯片 RESET（RST_N 切换或电源循环）是官方记录的恢复路径。APDU 计数器是会话驻留在 RAM 中的值——冷 RESET 时，如果没有 NVM 写入，它将被清除。Plug & Trust MW 包含一个 apdu_throughput_limit 演示，该演示使用 phNxpEse_reset 精确地演示了这种恢复。对于您的网状/传输节点用例，持续每分钟约 340 个 APDU，此限制在实践中应该不会造成问题，但请确保您的主机驱动程序能够通过自动重置优雅地处理 SW_66A6 。 Q5 — Applet 功能路线图（BIP32、Schnorr、RFC 6979、Ed25519ph） 您列出的特性——片上 BIP32 强化子密钥派生、Schnorr/BIP340、确定性 ECDSA nonce（RFC 6979）、低 S 归一化或 Ed25519ph——均未出现在 AN12543 Rev 4.5 或任何当前的 SE05x 文档中，并且在 7.2.x 版本中也没有任何关于这些特性的公开声明。线。我建议您通过您当地的 Disti/NXP FAE 提交正式的产品改进请求，以便我们的产品团队可以跟踪这些请求。 关于 Ed25519 的 T=1 链接问题：该小程序支持 IFSC (0xFE) 之外的 APDU 数据的多块 T=1 链接，因此消息长度在传输层处理，并且不是 EdDSA 操作的功能限制。 Q6 — 小程序 7.2.22 中的 UserID 行为 （a）计数器可读性： GetAttributes 响应返回配置的 TAG_MAX_ATTEMPTS 值（最大值），而不是剩余计数。当前小程序版本中，内部递减计数器并未作为直接可读属性公开。 （b）通过 SCP03 删除已耗尽的用户 ID：您在 7.2.0 版本中观察到的删除锁定用户 ID 时出现的 6986 错误是一个已知的限制。AN13904 没有明确记录在平台 SCP03 删除的背景下，7.2.22 的此行为发生了变化。我建议直接在 SE052F 评估硬件（或运行 7.2.22 的 SE051 样品）上验证这一点。作为一种变通方法，如果锁定的用户 ID 阻止了对象管理，则通过平台 SCP03 上的 RESERVED_ID_FACTORY_RESET 进行恢复出厂设置是已确认的路径——尽管这会清除所有用户对象，因此对象布局规划在这里很重要。 Q7 — ECDH NVM 磨损（SE050E，小程序版本 7.2.0） 确认的。AN12543 明确指出， ECDHGenerateSharedSecret on ID_ECC_MONT_DH_25519 仅当公钥作为字节数组 (TAG_2) 传递时才会导致每次调用写入 NVM。当公钥通过瞬态 ECPublicKey 对象 (TAG_3) 传递时，不会发生 NVM 写入。此行为适用于带有 applet 7.2.0 的 SE050E，因为 SE050E2 使用的是相同的 7.x applet 版本（SE051 芯片和 applet 系列，正如您的 GetInfo ATR 所确认的那样）。 WriteECKey 对瞬态对象进行写入操作时，仅写入 SRAM——在调用之间更新瞬态对象的内容不会造成 NVM 损耗。建议的节点模式是：在启动时分配一个持久的瞬态 ECPublicKey，在每次 ECDH 操作之前调用 WriteECKey （仅限 SRAM），然后调用 ECDHGenerateSharedSecret 并引用该瞬态对象 TAG_3。这样就完全避免了每次通话造成的非易失性存储器损耗。 Q8 — SE050E2 产品寿命 SE050E2于2022年发布。NXP 的产品寿命计划承诺，对于已注册的产品，自上市之日起至少可供货 10 或 15 年。有关 SE050E2 的最终注册状态和使用寿命期限，请查看NXP 产品使用寿命页面（完整表格需要登录）或请您的 NXP FAE 确认。 针对您的两个用例的总体建议 鉴于您的设计依赖于 Ed25519 (EdDSASign) 和 X25519 (MONT_DH_25519 上的 ECDHGenerateSharedSecret)， SE052F 目前无法满足您的加密要求。在具有这些算法的 SE052 型号推出之前，SE050E2 / SE051 系列仍然是合适的选择。我们建议您向 NXP FAE 确认 SE050E2 的长期有效状态，并注册对非 FIPS SE052 等效产品的需求。 希望这能帮助您更好地做出决定。如果您还有其他问题，请告诉我。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

S32K3X4EVB-T172 无法使用 OpenSDA 进行编程 我有一块全新的S32K3X4EVB-T172评估板。S32处理器似乎运行的是出厂默认代码，但是当我尝试使用板载调试器（通过USB连接到我的电脑）进行调试/重新编程时，S32处理器和板载调试器都会进入复位状态。 我已按照S32K3X4EVB-T172快速入门指南中的说明，正确执行了开机/插电步骤。我也已安装了指南中提到的软件和插件。 我用同事的S32K3X4EVB-Q172 试了同样的方法，结果一切正常。 提前感谢！ 托比亚 Re: S32K3X4EVB-T172 Unable to Program using OpenSDA 1. 请参阅讨论： S32K3X4EVB-T172 上的 PEmicro 连接助手问题。红色 LED 指示灯D15 (RST_OSDA) 和D3 (RESET_K3) 是常亮还是周期性闪烁？您的主板是否也遇到了与这位客户相同的问题？   2. FS26(U12) 是否热门？ 3. 你是否按照步骤“ 3.2 连接电源”和“3.3”进行操作？连接调试器电缆“？” 4. 插入 J40 micro-USB 连接线，观察D14状态 OSDA LED 指示灯。 如果D14橙色 LED 不亮：检查 USB 电缆是否为数据电缆，验证 PC 是否枚举 OpenSDA 设备，并确保 USB 端口和驱动程序正常工作。不建议通过 USB 集线器将 USB 线缆连接到电脑。 5. 板载调试器由 PEMicro 提供，建议 从“支持与下载”类别下的“ 多链路调试探针”页面下载最新的“ USB 多链路资源安装程序” 。安装完成后，打开 位于 C:\PEMicro\Multilink_Resources 目录下的 PEFirmwareConfig.exe 文件 ，查看固件版本。我的板载调试器固件版本为 10.98 。您的板载调试器固件版本是多少？如果版本过旧，建议更新。如果更新失败，建议联系 PEMicro 技术支持。 check the version of firmware on S32K3X4EVB-T172.png检查 S32K3X4EVB-T172.png 上的固件版本 6. 请使用电压模式的万用表或示波器观察P3V3_SDA (J34 ) 的电压。 S32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.pngS32K3X4EVB-T172_PackRevB2_Schematic P3V3_SDA J34.png 7. SDA_RST_TGTMCU由板载调试器 K26 的输出控制。如果SDA_RST_TGTMCU输出低电平，则红色 LED D15和D3都会亮起。 请使用示波器观察SDA_RST_TGTMCU (J36)电平。它一直都很低，还是会周期性地降低？ 通常情况下，当通过板载调试器下载程序或 RESET S32K3 时， SDA_RST_TGTMCU中应该观察到 10ms 的低电平，导致红色 LED D15和D3短暂亮起。 8. 是否可以通过 J12 连接外部调试器来调试板载 S32K3 芯片？ 此致敬礼， Robin

S32K358 高速スタンバイ こんにちは、 S32K358で高速スタンバイ機能をテストしたいです。S32DSでIPレイヤーのデモを作成しました。このプログラムは起動後5秒で高速スタンバイ状態に入り、3秒後にRTC-APIによって起動されます。これは問題なく動作します。 そこで、このプロジェクトを参照して、MCALレイヤーのデモを作成するためにEBプロジェクトを設定しましたが、失敗しました。高速スタンバイ状態になってから3秒後、電流が増加した。これはデバイスが起動したことを示唆しているが、メイン機能には移行しなかった。PE Microで接続した後、以下のエラーメッセージが表示されます。 割り込みコマンドを受信しました。執行を停止します。 UsageFault: 無効な EPSR.T または EPSR.IT フィールドで実行された命令。 バスフォールト:不正確な(非同期)データアクセスエラーが発生しました。 ハードフォールト：障害がハードフォールトにエスカレートしました。 ウェイクアップ後のベクトルテーブルを以下に示します。 1.png1.png PCレジスタは0x0です。スタックの内容を確認すると、FastWkup_EntryAddressが入力されており、ハードフォールトはReset_Handlerにジャンプした後に発生します。 2.png2.png 3.png3.png 4.png4.png FastWkup_EntryAddress に while(1) ループを追加しても、ハードフォルトは依然として発生します。 5.png5.png スタンバイモードに入ると、単語が出てきます。 このプロジェクトでは、PMIC_PGOOD_HNDSHK_BYPが有効になっています。この基板には外部水晶発振器が搭載されていないため、コアクロックとしてFIRCが使用されています。 S32K358 RTD6.0.0 S32DS3.6.3 EB29.0 BR、 ジェイソン Re: S32K358 FAST STANDBY こんにちは、@Jason07 さん。 高速スタンバイ起動時、sBAFはVTORをカスタムベクターテーブルアドレスに設定します。 しかし、あなたのベクターテーブルには3つのエントリしか定義されていません。 初期SP、 リセットハンドラ (FastWkup_EntryAddress)、 NMIハンドラー。 つまり、ハードフォールトベクトルが抜けているのです。 何らかの故障が発生すると、CPUは定義されていないハードフォールハンドラーアドレスを取り出し、これがPC値の原因となる可能性があります。 この問題をさらにデバッグするには、ベクターテーブルに適切なハードフォルトハンドラを追加してください。それらが設定されると、ハンドラーが0x0にクラッシュする代わりに呼び出され、スタックされたPC、LR、そして元の故障の構成可能な故障状態レジスタ(CFSR/BFAR)にアクセスできます。 ありがとうございました。 BR、ダニエル

正在寻找适用于 FRDM-IMX8MPLUS 板的 Robotics Edge Image 1.0.0 大家好， 我正在寻找适用于 FRDM-IMX8MPLUS 板（不是 IMX8MP-EVK）的 Robotics Edge Image 1.0.0 的发布包。 可以找到适用于 IMX8MP-EVK 或 IMX95EVK 的预编译镜像，但没有找到适用于 FRDM-IMX8MPLUS 的镜像。该开发板受支持（ https://mcuxpresso.nxp.com/RoboticsEdgePlatform/latest/html/gsd/prebuilt-images.html ）。 从源代码（Yocto）构建它简直是噩梦，因为它需要大约 1 TB 的空间，而且在此过程中会出现很多错误。 希望能得到满意的答复。 顺祝商祺！ Re: Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board 好的，我的错，FRDM-IMX8MPLUS 文件打包在 IMX8M-EVK 压缩包里。 同一个名字，却涉及两个董事会。

TapLinxを使っている人はいますか？ 誰かNXPのTapLinx SDKを使ってMIFAREカードと連携していますか? 最小限のコンソールアプリの例に興味があります。サンプルアプリは、多数の機能を備えたGUIアプリなので、動作させるのに少し手間がかかります。 カードへのデータの読み書き、認証などを行うだけの、最小限の機能しか持たないコンソールアプリを探しています。 Kotlinの例であればなお良いですが、Javaの例でも構いません。 はじめに Re: Anyone using TapLinx? こんにちは、@reid88さん TapLinx SDKはMIFARE DESFire、Plus、Classic、Ultralight、NTAGなどに対応しています。デザインリソースは以下から確認できます: MIFARE、NTAG、ICODE、UCODE用のTapLinx SDK |NXPセミコンダクターズ

Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board Hi everybody, I'm looking for a release package for a FRDM-IMX8MPLUS board (not IMX8MP-EVK) of Robotics Edge Image 1.0.0. It's possible to find a pre-built image for IMX8MP-EVK or IMX95EVK, but nothing was found for FRDM-IMX8MPLUS. The board is supported (https://mcuxpresso.nxp.com/RoboticsEdgePlatform/latest/html/gsd/prebuilt-images.html) Building it from source (Yocto) is a pure pain, as it takes around 1 TB of space and there are plenty of errors during the process. Hope to have a successful answer. Best regards, Re: Looking for robotics Edge Image 1.0.0 for FRDM-IMX8MPLUS board Ok, my bad, FRDM-IMX8MPLUS files are packaged in the IMX8M-EVK zip file.  A single name, but two boards addressed.

S32K358 FAST STANDBY Hello, I would like to test Fast Standby on the S32K358. I created an IP-layer demo in S32DS where the program enters Fast Standby 5 seconds after startup and is woken up by RTC-API after 3 seconds. This works without any issues. Then I referred to this project and configured an EB project to create an MCAL-layer demo, but it failed. After 3 seconds in Fast Standby, the current increased, which suggests the device woke up, but it never entered the main function. After attaching with PE Micro, the error messages are as follows: Interrupt command received. Halting execution. UsageFault: An instruction executed with an invalid EPSR.T or EPSR.IT field. BusFault: An imprecise (asynchronous) data access error has occurred. HardFault: A fault has been escalated to a hard fault. The vector table after wake-up is shown below: 1.png1.png The PC register is 0x0. Checking the stack contents, I can see that FastWkup_EntryAddress was entered, and the HardFault occurs after jumping to the Reset_Handler. 2.png2.png 3.png3.png 4.png4.png If I add a while(1) loop in FastWkup_EntryAddress, the HardFault still occurs. 5.png5.png If I enter standby mode, it word. In the project, PMIC_PGOOD_HNDSHK_BYP is enabled. Since the board does not have an external crystal oscillator, FIRC is used as the core clock. S32K358 RTD6.0.0 S32DS3.6.3 EB29.0 BR, Jason Re: S32K358 FAST STANDBY Hello @Jason07, On Fast Standby wakeup, the sBAF sets VTOR to your custom vector table address. However, your vector table only defines three entries: Initial SP, Reset Handler (FastWkup_EntryAddress), NMI Handler. So the HardFault vector is missing. When any fault occurs, the CPU fetches the not defined HardFault handler address, which could explain the observed PC value. To debug this further, please add a proper HardFault handler to the vector table. Once those are in place, the handler will be invoked instead of crashing to 0x0, giving you access to the stacked PC, LR, and the Configurable Fault Status Register (CFSR/BFAR) of the original fault. Thank you, BR, Daniel

Ara2_Model_Zoo_Compilation_Deployment_Testing_Guide This document provides an end-to-end example for setting up the Ara2 compilation environment, compiling the YOLOv8L ONNX model with the Model Zoo, deploying the compiled model to an i.MX95 target, running inference and performance tests, and reviewing the key YAML fields that must be updated when adapting the flow to another model of the same type.

LPC55S28 CASPER ECC 乗算実行時間 以下のコードが計測時間内に実行されることが想定されているのか、それとも設定に何か問題があって実行が非常に遅くなっているのかを突き止めようとしています。このコードは、kCASPER_ECC_P256を使用して指定された秘密鍵から公開鍵を生成する関数の一部です。 以下のコードは、GPIOトグルを使用して実行時間を計測します。Set および Clear GPIO 呼び出しの間には 337 ミリ秒かかります。これは、この演算におけるハードウェアアクセラレーションによる計算処理としては遅いように思われる。これは想定内のことでしょうか？私のMCUのコアクロックは148MHzです。CASPERエンジンのクロックソースを選択して処理速度を向上させる方法はありますか？ /* Base Generator Point G(x, y) for secp256r1 in 32-bit Little-Endian word arrays */ static const uint32_t G_x_le[8] = { 0xD898C296, 0xF4A13945, 0x2DEB33A0, 0x77037D81, 0x63A440F2, 0xF8BCE6E5, 0xE12C4247, 0x6B17D1F2 }; static const uint32_t G_y_le[8] = { 0x37BF51F5, 0xCBB64068, 0x6B315ECE, 0x2BCE3357, 0x7C0F9E16, 0x8EE7EB4A, 0xFE1A7F9B, 0x4FE342E2 }; uint32_t scalar_le[8]; uint32_t Q_x_le[8]; uint32_t Q_y_le[8]; /* Copy Big-Endian private scalar and convert to Little-Endian for CASPER */ memcpy(scalar_le, key_buffer, 32); swap_endian_32((uint8_t *)scalar_le); /* 1. Initialize CASPER coprocessor */ CASPER_Init(CASPER); CASPER_ecc_init(kCASPER_ECC_P256); HW_DB_PinSet(); /* 2. Compute Q = d * G using CASPER hardware */ CASPER_ECC_SECP256R1_Mul( CASPER, Q_x_le, Q_y_le, G_x_le, G_y_le, scalar_le ); HW_DB_PinClear(); 回复： LPC55S28 CASPER ECC Multiply Execution Time こんにちは、 @guitardenver 同じ操作を、150MHzで動作するLPC55S28 EVK上でMCUXpresso SDK CASPER例を用いて測定しました。CASPER_ECC_SECP256R1_Mul() を 1 回呼び出すのに約 2410 万 CPU サイクルが必要で、これは約 160 ミリ秒の実行時間に相当します。 この結果に基づくと、アプリケーションで測定された337msは、特に追加のキーフォーマット、データ変換、初期化、デバッグビルドのオーバーヘッドが含まれれば、不合理とは思えません。 CASPERは、ユーザーが設定可能な別のクロックソースを提供していません。実行時間は主にCASPARアクセラレータを利用したECCソフトウェア実装によって決定されます。 BR ハリー

i.MX8M-Plus RDC Sema42 クラスター内分離 i.MX8M-PlusのRDCを使用して、A53クラスタ内のコアを分離したいと考えています。RDCセマフォを使って、A53クラスターから特定のCPUが周辺機器にアクセスするのを禁止することは可能でしょうか? Rev 3 IMX8MPRMリファレンスマニュアルには、ゲートレジスタRDC_SEMAPHOREx_GATEnにおけるGTFSMフィールドの動作について明確ではありません(セクション3.2.6.1)。ロックドメインを知らせるための2ビットと、セマフォをロックしている「プロセッサ」を知らせるための4ビットがあります。 「プロセッサ」とはクラスタ(A53、M7)ですか、それともクラスタ内のコアですか? もしA53クラスターのcore0がセマフォをUART1にロックした場合、core1...3はUART1にアクセスできるのでしょうか? Re: i.MX8M-Plus RDC Sema42 for intra-cluster isolation No. i.MX8M Plusでは、RDCセマフォ「プロセッサ」はバス・マスタ/RDCマスターであり、個別のA53コアではありません。A53クラスタはRDC目的で1つのA53プラットフォームマスター/ドメインとして表示されます。A53クアッドコアクラスタは単一のマスタードメインとして扱われ、つまり4つのA53コア（core0～core3）すべてが同じRDCドメインに属します。その結果、Sema42セマフォのGTFSMフィールドは、どのドメイン（例えば、A53クラスタ対M7コア）がロックを保持しているかを識別するのであって、クラスタ内のどの個々のコアがロックを保持しているかを識別するわけではありません。 したがって、A53 core0がUART1のセマフォをロックした場合、A53 core1–3はそのRDCセマフォによって個別にブロックされません。同じA53/RDCドメインにいる場合はUART1にもアクセスできます。 クラスタ内コア分離には、ハードウェアのRDC/Sema42ではなく、OSレベルのリソース管理やスピンロックなどのソフトウェアレベルの仕組みに依存する必要があります。