Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
了解 RD772BJBCANFDEVB、RD-K358BMU 和 RD33774CNC3EVB 之间的通信流程 您好,NXP团队: 我们正在评估以下NXP 电池管理系统评估板: RD772BJBCANFDEVB (BJB) RD-K358BMU(BMU) RD33774CNC3EVB(卡内基梅隆大学) 在审查现有示例软件时,我们无法理解 BJB、BMU 和 CMU 之间的完整通信流程。 我们希望您能就以下问题作出澄清: 三个董事会之间的整体沟通流程。 它们之间交换 CAN 消息。 信号从一个电路板流向另一个电路板。 哪些软件模块/文件实现了这种通信? 是否有通信流程图或架构文档? 任何解释软件通信流程的文档或应用笔记都将不胜感激。 谢谢。 RD33774CNC3EVB 、 RD-K358BMU 、 RD772BJBCANFDEVB
記事全体を表示
imx95はRAMへのサスペンド時にvdd_socをオフにする こんにちは、 アイドル状態になった後、VDD_SOCをオフにしようとしています。 例えば、m33コンソールでは次のようになります。 lm サスペンド lm M7 サスペンション アイドル 次に、vdd socをオフにします(pf09のスタンバイモードをvdd socオフに設定することによって)。 次にスタンバイピンを放します。 m33 の VDD_SOC は最初からやり直しますが、RAM は保存されたままです。 bl31でウォームブートパスを実行するようにsplのコードを変更し、カーネルへの起動に成功しました。 しかしその後、カーネルが詰まってしまい、以下の通りの「最新のログ」が確認できます。 2つのCASEで何が違うのか気になります。 - CASEノーマルサスペンド:(保持vdd_soc) - Case Abnormal(vdd_soc オフ) この場合、M33の起動時に何か再初期化するために別のことをすべきでしょうか? [2026-07-06 10:39:55.070]通知: BL31: ウォームレジュームNSコンテキストが復元されました [2026-07-06 10:39:55.074][ 1018.529356][T3251] its_restore_enable+0x0/0x1ac を呼び出しています [2026-07-06 10:39:55.080][ 1018.529356][T3251] cpu_pm_resume+0x0/0x5c を呼び出しています [2026-07-06 10:39:55.084][ 1018.529356][T3251] kvm_resume+0x0/0x68 を呼び出しています [2026-07-06 10:39:55.089][ 1018.529356][T3251] irq_gc_resume+0x0/0x110 を呼び出しています [2026-07-06 10:39:55.094][ 1018.529356][T3251] irq_pm_syscore_resume+0x0/0x24 を呼び出しています [2026-07-06 10:39:55.100][ 1018.529356][T3251] timekeeping_resume+0x0/0x188 を呼び出しています [2026-07-06 10:39:55.105][ 1018.529356][T3251] sched_clock_resume+0x0/0xd0 を呼び出しています [2026-07-06 10:39:55.110][ 1018.529619][T3251] ブート以外のCPUを有効にする... [2026-07-06 10:39:55.142][ 1018.559214][T0] CPU1でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.146][ 1018.559246][T0] GICv3: CPU1: 再分配器100の領域0:0x0000000048080000が見つかりました [2026-07-06 10:39:55.154][ 1018.559293][T0] CPU1: 起動済みのセカンダリプロセッサ0x0000000100 [0x412fd050] [2026-07-06 10:39:55.161][ 1018.560868][T3251] CPU1が起動しました [2026-07-06 10:39:55.191][ 1018.608610][T0] CPU2でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.196][ 1018.608642][T0] GICv3: CPU2: 再分配器200の領域0:0x00000000480a0000が見つかりました [2026-07-06 10:39:55.203][ 1018.608686][T0] CPU2:起動されたセカンダリプロセッサ0x0000000200 [0x412fd050] [2026-07-06 10:39:55.210][ 1018.610091][T3251] CPU2が起動しました [2026-07-06 10:39:55.240][ 1018.657836][T0] CPU3でVIPT命令キャッシュを検出しました [2026-07-06 10:39:55.245][ 1018.657870][T0] GICv3: CPU3: 再分配器300領域0:0x00000000480c0000が見つかりました [2026-07-06 10:39:55.253][ 1018.657917][T0] CPU3: 起動された二次プロセッサ0x0000000300 [0x412fd050] [2026-07-06 10:39:55.260][ 1018.659332][T3251] CPU3が起動しました [2026-07-06 10:39:55.289][ 1018.707065][T0] CPU4でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.294][ 1018.707101][T0] GICv3: CPU4: 再分配器400領域0:0x00000000480e0000が見つかりました [2026-07-06 10:39:55.302][ 1018.707151][T0] CPU4:セカンダリプロセッサ0x0000000400起動 [0x412fd050] [2026-07-06 10:39:55.309][ 1018.708560][T3251] CPU4が起動しました [2026-07-06 10:39:55.339][ 1018.756298][T0] CPU5でVIPT Iキャッシュを検出しました [2026-07-06 10:39:55.344][ 1018.756332][T0] GICv3: CPU5: 再分配器500領域0:0x0000000048100000が見つかりました [2026-07-06 10:39:55.351][ 1018.756379][T0] CPU5:起動したセカンダリプロセッサ0x0000000500 [0x412fd050] [2026-07-06 10:39:55.359][ 1018.758206][T3251] CPU5が起動しました [2026-07-06 10:39:55.362][ 1018.781314][T3251] rpmsg-ライフサイクル rpmsg-lifecycle: PM: 呼び出し rpmsg_lifecycle_resume_noirq @ 3251、親: プラットフォーム [2026-07-06 10:39:55.373][ 1018.792078][T3251] rpmsg-lifecycle rpmsg-lifecycle: PM: rpmsg_lifecycle_resume_noirq が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.383][ 1018.802181][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] @ 3251 を呼び出し中、親プロセス: 49000000.bus [2026-07-06 10:39:55.394][ 1018.812966][T3251] arm-smmu-v3 490d0000.iommu:PM: arm_smmu_resume [arm_smmu_v3] が 60 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.403][ 1018.822745][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.414][ 1018.833538][T3251] imx_mu 445b0000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 3 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.424][ 1018.843279][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.434][ 1018.853283][T3251] imx_mu 47300000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.444][ 1018.863029][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.454][ 1018.873031][T3251] imx_mu 47320000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.464][ 1018.882772][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.474][ 1018.892773][T3251] imx_mu 47330000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.483][ 1018.902513][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.493][ 1018.912516][T3251] imx_mu 47340000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.503][ 1018.922256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.513][ 1018.932256][T3251] imx_mu 47350000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.523][ 1018.941998][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.533][ 1018.952002][T3251] imx_mu 47550000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.542][ 1018.961770][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.553][ 1018.972548][T3251] imx_mu 42430000.mailbox:PM: imx_mu_resume_noirq [imx_mailbox] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.563][ 1018.982411][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 42000000.bus [2026-07-06 10:39:55.574][ 1018.993375][T3251] fsl-lpuart 42590000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 2 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.584][ 1019.003326][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] @ 3251 を呼び出し中、親プロセス: 44000000.bus [2026-07-06 10:39:55.595][ 1019.014289][T3251] fsl-lpuart 44380000.serial:PM: lpuart_resume_noirq [fsl_lpuart] が 4 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.605][ 1019.024225][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.616][ 1019.035009][T3251] imx-lpi2c 42530000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 1 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.626][ 1019.044756][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.636][ 1019.055531][T3251] imx-lpi2c 42540000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.646][ 1019.065272][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.657][ 1019.076047][T3251] imx-lpi2c 426b0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.667][ 1019.085794][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.677][ 1019.096567][T3251] imx-lpi2c 426c0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.687][ 1019.106304][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 42000000.bus [2026-07-06 10:39:55.698][ 1019.117086][T3251] imx-lpi2c 426d0000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.708][ 1019.126830][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] @ 3251 を呼び出し中、親: 44000000.bus [2026-07-06 10:39:55.718][ 1019.137605][T3251] imx-lpi2c 44350000.i2c:PM: lpi2c_resume_noirq [i2c_imx_lpi2c] が 0 マイクロ秒後に 0 を返しました [2026-07-06 10:39:55.728][ 1019.147353][T3251] imx-irqsteer 4b0b0000.interrupt-controller:PM: genpd_resume_noirq @ 3251 を呼び出し中、親: soc [2026-07-06 10:39:55.738][ 1019.157693][T3251] PM: GENPD_RESUME_NOIRQ dev=4b0b0000.interrupt-controllerドメイン=display タスク=kworker/4:5 pid=3251 [2026-07-06 10:39:55.749][ 1019.168295][T3251] SCMI_PD ディスプレイ ドメイン=13 状態=オン タスク=kworker/4:5 pid=3251 Linux PMIC Re: imx95 turn off vdd_soc when suspend to ram ログにはエラーは記録されていませんが、a55はそこで停止してしまいます。 通常の場合(vddsoCを切らさずに)、そのまま動作を続けます スリープモードでの消費電力を減らそうとしているので、この方法でvddsocをオフにしつつRAMは残しています。 Re: imx95 turn off vdd_soc when suspend to ram ログにはエラー情報がないようです。電圧を遮断するかどうかによって、消費電流に差が生じる可能性があります。消費電力に違いを感じますか?また、VDDSOCをオフにしたい理由は何ですか? Re: imx95 turn off vdd_soc when suspend to ram こんにちは@thinkembedsw VDD_SOC(および関連するデジタル電源)電圧は、「サスペンドモード」電圧まで低下します。直接電源を切ることはサポートしていません BR
記事全体を表示
imx6 jtag random Invalid ACK (7) in DAP response Hi everyone, I'm still picking at the mazda cmu and I've already been able to connect to jtag, but there's a problem. After initializing the memory, the chip stops responding to jtag commands after a while, and openocd resets the connection accordingly. If I do everything quickly and try to download the compiled project from eclipse, I get a bunch of: Error: timeout waiting for DSCR bit change Error: Error waiting for InstrCompl=1 Error: Error waiting for cortex_a_exec_opcode and the subsequent loss of communication. I tried initializing the APB-AP registers with the command imx6d.dap apcsw 1 0 and disabling wdog, but it didn't help. I have attached archive with my configs and log. i.MX6Dual Re: imx6 jtag random Invalid ACK (7) in DAP response Hello, I suggest you check directly with manufacturer. If you are not able to debug the device, may have secure JTAG debug enabled. Best regards. Re: imx6 jtag random Invalid ACK (7) in DAP response Hello. Visteon is not particularly willing to share information, but Mazda is... It does not introduce reverse engineering of its devices at all, as explicitly stated in the license agreement. secure jtag is most likely not enabled because I can initialize the memory and perform operations with it. it seems to me that the problem is in openocd or in the second core, which is not affected by the halt state.
記事全体を表示
S32K358 MBDT参照モデルビルド失敗 こんにちは、 私はMATLAB R2024bとNXP MBDT for S32K358を使用しています。 私はハードウェア(10Hz CAN Tx/Rx)上で正しくビルド、フラッシュ、動作するスタンドアロンのNXP CAN通信モデルを持っています。 また、参照モデル、ステートマシン、推定器、故障マネジメントロジックを含む別のBMSアルゴリズムモデル(Offline_Test)も持っています。 BMSアルゴリズムを動作中のNXPモデルに統合してビルドすると、MBDTは参照モデル(BMS_Out_Config)用の別の設定フォルダを生成し、以下で失敗します: 致命的なエラー: Mcl.h:そのようなファイル、又はディレクトリはありません #include エラーの原因は次のとおりです。 コントローラー/BMS_Out_Config/src/mbdt_board_init.c Mcl.h は、以下の環境では生成されません。 コントローラ/BMS_Out_Config/RTD/インクルーブ 私の質問は次のとおりです。 アルゴリズムのみ参照されたモデルには、独自のハードウェア構成やRTD生成が必要でしょうか? それとも最上位のハードウェアモデル構成を引き継ぐべきでしょうか? 既存のS32K3ハードウェアプロジェクトに大規模なアルゴリズム参照モデルを統合するための推奨ワークフローはありますか? 動作中のNXPモデル、BMSアルゴリズムモデル、ビルドエラーのスクリーンショットを添付します。 ありがとうございます。
記事全体を表示
yolov11n、yolov8n、yolov5nuモデルでi.MX95 NPUを使用しても出力が出ません   [i.MX95 NPU]YOLOv5n/v8n/v11n Neutron変換モデルは動作しますが検出なし(出力ゼロ) 問題の説明 私はNeutronコンバーターを使ってi.MX95 NPU上のYOLO物体検出モデルを評価しています。 INT8量子化されたTFLiteモデルはCortex-A55 CPU上で正常に動作しオブジェクトを検出しますが、コンパイルされたneutron.tflite版は、推論をクラッシュせずに実行しても、NPUにオフロードしても検出ゼロ(空/出力なし)ができません。 環境およびハードウェアのセットアップ   ハードウェア: i.MX95 19x19 LPDDR5 EVK(A1リビジョン) OS/カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXPツールチェーン: MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 テストされたモデル: YOLOv5nu、YOLOv8n、YOLOv11n(ウルトラリティクス) ワークフローの手順と使用されるコマンド 1. 量子化(Ultralyticsエクスポート) モデルはINT8のフル整数量子化で320x320解像度でエクスポートされました。 yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状態: CPU上で完全に動作します。yolovXn_full_integer_quant.tflite は、A55 コア上でオブジェクトを正しく検出します。 2. Neutron 編纂 TFLiteモデルは、Neutronコンバータを用いてi.MX95 NPU向けにMCU_SDK_25.09.00+Linux_6.12.34_2.1.0でコンパイルされました: ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状態: NPU上のオブジェクトを検出できませんでした。コンパイルされたモデルは構文や実行エラーを投げることなく推論を読み込み実行しますが、出力テンソルはまったく同じテスト画像に対して検出をゼロ返します。 観察された症状と疑われる根本原因   オペレーターの代替手段: コンバーターは特定のYOLOレイヤー(カスタムアンカー、SiLU/Swinのアクティベーション、Non-Max Suppressionなど)でCPUにフォールバックしましたか? 量子化のスケーリング/非対称性: Ultralytics経由でエクスポートされるYOLOモデルは、しばしば非対称量子化を用いたり、特定の出力テンソルスケーリングを用いており、Neutron NPUドライバーが誤解することがあります。 出力テンソルのフォーマット:推論は実行されるため、入力パイプラインは問題ないと思われますが、出力バウンディングボックス/スコアが空白であるか、完全にゴミ値になっています。 NXPのエキスパートへの質問   Ultralytics YOLOアーキテクチャ特有のNeutron変換器には既知の制限や必須の最適化フラグはありますか? TFLiteモデルをNeutronコンバーターに渡す前に、NMS(Non-Max Suppression)レイヤーを取り除くべきでしょうか? i.MX95 Neutron SDKは、出力層を正しく解析するために対称量子化(per_channel=TrueまたはFalse)を必要としますか? i.MX95 NPU向けのガイダンス、リファレンススクリプト、またはYOLOの導入に関する作業手順書などがあれば、大変ありがたいです。   Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 ご回答ありがとうございます。 私のハードウェアプラットフォームについて誤解があるのではないかと思います。私の問題はi.MX91とは関係ありません。 私は以下のプラットフォームを使っています: 基板:i.MX95 19x19 LPDDR5 EVK(IMX95LPD5EVK-19CM、A1リビジョン) ボードクイックスタートガイド: https://www.nxp.com/docs/en/quick-reference-guide/IMX95LPD5EVK-19CM.pdf Neutron SDK: MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 カーネル: Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) あなたが共有したガイドはi.MX91向けのようですが、私の質問はi.MX95 Neutron NPUでのYOLO展開についてです。 オリジナルのINT8 TFLiteモデル(YOLOv5nu、YOLOv8n、YOLOv11n)はCortex-A55 CPU上で正しく動作し、有効な検出結果を生み出します。しかし、同じモデルをMCU_SDK_25.09.00+Linux_6.12.34_2.1.0に含まれるNeutron コンバータでまとめた後、推論はNPU上で実行時エラーなく正常に実行されるが、出力テンソルには有効な検出結果が含まれない。 調査を容易にするために、すでに元の投稿に以下のファイルを添付しています: * オリジナルのINT8量子化されたTFLiteモデル。 * YOLOv8nおよびYOLOv11n向けの中性子変換TFLiteモデル。 * 問題を再現するために使えるPython推論スクリプト。 これらは元の事前学習済みUltralyticsモデルをTFLiteに変換したものなので、標準のCOCOクラス名を提供されたスクリプトで直接使用できます。追加の修正なしでi.MX95プラットフォーム上で同じ動作を再現できるはずです。 添付ファイルを使って問題を再現していただけるとありがたいです。また、これがi.MX95の現行Neutron SDKの既知の制限か、あるいは問題なのか教えていただけると助かります。 ありがとう。 Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは@vijayranaACL。 NXPサポートまでご連絡いただきありがとうございます。 このガイドを参照してください。 お客様が使用されているのはi.MX91 A1シリコンリビジョンであるため、A1は主に評価および開発目的を意図した初期のシリコンリビジョンであり、一部の機能が正しく動作しない可能性があります。 そのため、テストおよび検証作業には、i.MX91 B0シリコンリビジョンを使用することをお勧めします。このガイドはB0シリコン版を用いて作成・検証されたため、文書化された挙動と結果はその改訂版に基づいています。 可能であれば、どのシリコンリビジョンを使っているか、そして比較のためにB0デバイスにアクセスできるかを確認してください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 すみません、私の入力ミスでした。 私が言及していたのはi.MX95のことです。i.MX91にはNPUが搭載されていないからです。 モデル変換には以下のコマンドを試してみることをおすすめします: .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt Neutron SDKのドキュメントによると、コンバータはi.MX95のようなNeutron-Sターゲットに対してデターミニスティックではないことに注意が必要です。変換プロセスはマルチスレッド制約付きプログラミングソルバーに依存しているため、同じモデル上でコンバータを実行する場合、特にTCMメモリ割り当てや生成されたマイクロコードに関してわずかに異なる結果が生じることがあります。 複数の最適解が存在する可能性があるため、異なるソルバースレッドが各変換時に異なる有効な解に収束することがあります。これらの解は内部的に異なる場合がありますが、すべてコンバーターによって正しく最適化されています。ほとんどの場合、これらの違いは機能性や性能に大きな影響を与えることはありません。 挙動、性能、精度にばらつきが見られた場合は、モデルを複数回変換して結果を比較することをお勧めします。デターミニスティックな振る舞いを強制する方法は存在しますが、通常は変換時間が大幅に長くなり、厳密に必要でない限り推奨されません。 検査結果をお知らせください。 よろしくお願いします、 アレハンドロ・ガルシア Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 i.MX 95(i.MX 91ではない)に関する説明と、使用に関する推奨事項をありがとうございます。 --最適化レベル OOpt。 現在のセットアップであなたの提案されたコマンドに従おうとしましたが、Neutron-コンバーターとボードBSPを組み合わせたところ --optimization-level は利用できません 利用できません 。 現在の環境 コンポーネントバージョン ボード IMX95LPD5EVK-19 BSP LF6.12.34_2.1.0 (Linux 6.12.34-lts-next) Neutron 代表乗船中 v1.0.0-be8bf399 ホストコンバータ eIQツールキット 1.17 → Neutron-converter 2.1.3+0Xaf140cf5 コンバーターBSPタグ MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 このコンバーターでは、 中性子コンバーター――help does not list ―最適化レベル。 実際に実行するコマンド Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 デバッグには、以下のツールも使用します。 Neutron-converter \ --input yolov8n_full_integer_quant.tflite \ --output yolov8n_neutron.tflite \ --ターゲットimx95 \ --詳細表示 当社のコンバーター(2.1.3)で利用可能なフラグ 主なオプション  - ヘルプ: - 入力、  - 出力、  - ターゲット --合一Neutronグラフ --入力値をuint8からint8に変換、 --出力をuint8からint8に変換 --ダンプ統計、 --ダンプグラフ、 --詳細表示 --入力テンソル間のインクルード、 --入力テンソル間の除外 --ターゲットを表示、 --カーネルの種類を表示 --最適化レベル 存在しません このビルドでは。 これまでの検査結果 モデルNPUの挙動 YOLOv8n Neutron (我々の変換) 呼び出しOKですが 検出数:0 YOLOv8n ヘッドレスバックボーン NPU出力 定数(約1.13) ヘッドレスCPUバックボーン+CPUヘッド 検出は正常です — パイプラインのロジックは正しい 質問 最適化レベルのOOpt は 2.1.3 よりも新しいNeutronコンバーターでしかサポートされていないのでしょうか? 推奨される変換コマンドは何ですか? LF6.12.34 / imx95 いつ OOpt 利用できませんか? Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、 @vijayranaACL さん。 B0シリコンを搭載したi.MX95 EVKであなたのコードをテストしましたが、こちら側では問題なく正常に動作しているようです。 person_detect.pyアプリケーションを使うと、モデルは正常に読み込まれ、Neutronデリゲートは正しく初期化され、アプリケーションは予想通りの推論を実行します。テスト中、安定した物体検出と、約13~14 FPSの持続的なパフォーマンスを確認しました。ログはまた、Neutron delegateがアクティブであり、モデルがNPU加速で正しく動作していることも確認しています。 これらの結果に基づき、B0シリコンリビジョンへの移行を推奨します。A0およびA1シリコン版は主に評価およびベータテスト目的でリリースされており、B0ほどのソフトウェアサポートや検証レベルが整っていません。初期の改訂版以降、いくつかの機能追加や修正が行われており、それがお客様が経験されている動作の原因となっている可能性があります。 私のテストログの関連部分を以下に示します。 root@imx95evk:~# python3 person_detect.py Opening camera /dev/video52 ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Loading model and NPU delegate ... Loaded Neutron delegate: /usr/lib/libneutron_delegate.so /usr/lib/python3.13/site-packages/tflite_runtime/interpreter.py:457: UserWarning: Warning: tf.lite.Interpreter is deprecated and is scheduled for deletion in TF 2.20. Please use the LiteRT interpreter from the ai_edge_litert package. See the [migration guide](https://ai.google.dev/edge/litert/migration) for details. warnings.warn(_INTERPRETER_DELETION_WARNING) INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-d98743a7, zerocp enabled. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Model input: shape=[ 1 640 640 3] dtype= quant=(0.003921568859368563, -128) Model output[0]: shape=[ 1 84 8400] dtype= quant=(0.003906319383531809, -128) Using model input size: 640x640 Re-opening camera after model load ... Trying camera backend: V4L2 /dev/video52 Camera opened via V4L2 /dev/video52 Person detection running. Press Ctrl+C to stop. First frame: 640x480 Output tensor shape: (1, 84, 8400) frame=22 person conf=0.61 box=[143,8,496,476] fps=10.7 --- fps=11.5 detections=0 --- frame=39 person conf=0.58 box=[138,16,496,473] fps=12.1 frame=50 person conf=0.50 box=[138,12,496,472] fps=12.5 frame=60 person conf=0.58 box=[138,13,496,476] fps=12.8 --- fps=12.8 detections=1 --- frame=84 person conf=0.61 box=[143,10,496,475] fps=13.3 frame=85 person conf=0.54 box=[138,10,496,475] fps=13.3 frame=86 person conf=0.61 box=[138,13,496,476] fps=13.3 frame=88 person conf=0.54 box=[138,12,496,472] fps=13.3 --- fps=13.3 detections=0 --- --- fps=13.6 detections=0 --- frame=136 person conf=0.65 box=[138,13,496,476] fps=13.7 frame=139 person conf=0.58 box=[138,12,496,472] fps=13.7 frame=140 person conf=0.61 box=[136,10,498,475] fps=13.8 frame=141 person conf=0.61 box=[138,13,496,476] fps=13.8 frame=145 person conf=0.50 box=[138,13,496,476] fps=13.8 frame=146 person conf=0.65 box=[138,13,496,476] fps=13.8 frame=148 person conf=0.54 box=[138,16,496,473] fps=13.8 frame=150 person conf=0.50 box=[131,12,498,472] fps=13.8 --- fps=13.8 detections=1 --- frame=155 person conf=0.50 box=[152,32,497,472] fps=13.8 frame=156 person conf=0.71 box=[180,37,495,422] fps=13.8 frame=157 person conf=0.54 box=[182,38,497,411] fps=13.8 frame=158 person conf=0.65 box=[156,37,493,472] fps=13.8 frame=159 person conf=0.68 box=[158,42,496,472] fps=13.8 frame=160 person conf=0.61 box=[155,46,495,468] fps=13.8 frame=162 person conf=0.54 box=[156,46,493,463] fps=13.8 frame=163 person conf=0.71 box=[171,43,493,466] fps=13.8 frame=164 person conf=0.54 box=[186,41,363,353] fps=13.8 frame=165 person conf=0.61 box=[187,42,492,452] fps=13.8 frame=166 person conf=0.58 box=[190,41,495,393] fps=13.8 frame=167 person conf=0.61 box=[190,42,495,432] fps=13.8 frame=168 person conf=0.61 box=[195,38,495,426] fps=13.8 frame=169 person conf=0.50 box=[190,36,495,423] fps=13.8 frame=170 person conf=0.58 box=[198,37,496,397] fps=13.8 --- fps=13.9 detections=0 --- frame=202 person conf=0.50 box=[145,28,495,456] fps=13.9 --- fps=14.0 detections=0 --- ^CStopped. root@imx95evk:~# 同じアプリケーションとモデルがB0シリコン上で正常に動作するため、問題はアプリケーション自体ではなくシリコンリビジョンに関連している可能性があるため、さらなるデバッグを続ける前にB0デバイスでテストを繰り返し行うことをお勧めします。 よろしくお願いします、 チャビラ Re: yolov11n,yolov8n,yolov5nu model not getting any output after running on i.MX95 NPU こんにちは、アレハンドロさん。 私たちが話したコードとモデルが FRDM-IMX95 15x15 プラットフォームと互換性があるか確認していただけますか? bsp 6.12.49_2.2.0 を使用
記事全体を表示
aft05ms004nt1 困ったことがあるんです、皆さん助けてください 私はAFT05MS004NT1というICを持っていますが、30~45MHzの周波数で送信したいと思っています。 どなたかZloadとZsourceの価値について助けていただけますか? 添付ファイルの表をご覧ください。 Re: aft05ms004nt1 こんにちは、arkazainsの皆さん。 良い一日! このトランジスタの動作範囲を大きく超えています。残念ながら、このPNトランジスタの代わりは電圧レベルの問題でありませんが、設計にレベルトランスレーターを組み込むことを検討すれば、例えば以下の通りの他のPNトランジスタが見つかるかもしれません。 MRFE6VP61K25H もう一つの選択肢は AFT05MS003N;すでに生産終了と表示されていますが、販売代理店にまだ在庫があるか確認すると良いでしょう。 プロジェクトの成功を心からお祈りしています。 良い一日をお過ごしください。幸運を祈ります。
記事全体を表示
Why results from NPU tflite model and tflite model are different? I have quantized classification model. I convert to NPU tflite model with command  ./neutron-converter \ --input QAT.tflite \ --output QAT_NPU.tflite \ --target imxrt700 \ --dump-header-file-output \ --dump-header-file-input \ --use-sequencer After that, I use 2 generated model header files for NPU and CPU. I use the sample tflm_cifar10_cm33_core0, modified for our models. I use the sample image_data.h (resized image to model input size). But the final results of 2 models (on CPU and NPU modes) are different: - In almost cases, the predicted class is same with similar probability (not exactlty match by values) - In some cases, the predicted classes in 2 modes are different ==> Do you have any comment for this problem? Sorry I can not share my model. Re: Why results from NPU tflite model and tflite model are different? I tried to verify this problem with the sample tflm_cifar10_cm33_core0. But in this sample, there is only NPU tflite model, I did not see the other one (CPU tflite model). I want to compare predicted results with different images to see whether this problem is happened with model pretrained by NXP. If you have CPU tflite model (correspond NPU tflite model tflm_cifar10_cm33_core0), please share with me. I am curious about whether conversion from tflite model to NPU tflite model results in difference of inference's results. Thank you. Re: Why results from NPU tflite model and tflite model are different? @mayliu1 Hi could you help me about this problem? Sorry, I feel that the number of NXP's supporters in i.MX RT is small and questions are sometimes missed. Before, I worked with MIMXRT1060 and N947, I got response very quickly. Re: Why results from NPU tflite model and tflite model are different? Hi @nnxxpp, It is expected that after the model conversion process, you see slight differences on the output values, due to the fact that the Neutron Converter restructures the model into NeutronGraph nodes for NPU execution, rather than executing the original graph on an operator basis like it would be done on a CPU-based TFLM. That said, if the outputs are too different, resulting in miss predicted classes on too many occasions, it would be important to check things like: The neutron convertor version and neutron libraries version used on runtime to ensure matching SW, memory configuration used for the NPU, as well as inspecting the converted nodes to ensure the whole model was correctly converted rather than only partially. BR, Edwin. Re: Why results from NPU tflite model and tflite model are different? Hi @nnxxpp , Thank you for sharing your feedback. Your case is currently being followed by my colleague, Edwin, who is actively working on it. We would appreciate your patience while the investigation continues. Edwin will continue to follow up on this matter and keep you informed of any progress. Thank you for your understanding. Best regards, May Re: Why results from NPU tflite model and tflite model are different? @mayliu1  Oh, I am very happy to hear that from you. Thank you so much for supporting. I will wait good news from you. Re: Why results from NPU tflite model and tflite model are different? @EdwinHz  Thank you so much for supporting. Yes. I understood that it is expected, so in this case I need to evaluate NPU tflite on board (not tflite model) to see exact performance. Thank you.
記事全体を表示
S32K3の低電力ウェイクアップ問題 最近、S32K314の低消費電力ウェイクアップ機能をデバッグしていたところ、外部ウェイクアップ方法を使用してもスリープモードから復帰できないことがわかりました。 通常の状況下では、DIは外部刺激に反応するが、休眠状態に入ると全く反応しなくなる。 添付ファイルにコードが含まれています。この問題の原因は何でしょうか?また、どのように解決すればよいでしょうか? Re: S32K3 低功耗唤醒问题 こんにちは、ジュリアン あなたの提案に従ってみたところ、目が覚めるようになりました。これは、私が本当にスタンバイモードに入ったということでしょうか? もう一つ質問したいのですが、スタンバイモードに入った後、I/Oポートの状態は以前と同じままなのでしょうか? もう一つの疑問は、回路設計において、MCUから定期的にデータ供給を受ける必要があるハードウェアウォッチドッグが存在することです。これを低消費電力でどのように実現できるでしょうか? ありがとう、 Joker_Y Re: S32K3 低功耗唤醒问题 こんにちは、 @Joker_Y さん。 あなたが共有してくれたプロジェクトはかなり大規模なようですね。すべてを確認したわけではありませんが、あなたが対応するウェイクアップソースを有効にしていないのはわかります。以下の行がコメントアウトされています。 Wkpu_Ip_EnableInterrupt(0,Wkpu_Ip_ChannelConfig_PB[0].hwChannel); また、スタンバイモードに入る前に、Clock_Ip_Init() APIを使用してメインクロックをFIRCに変更してください。 低出力の例を参照できます;クロック設定の変更方法やWKPUチャネルの有効化方法が示されています。 S32K3の低消費電力管理ANとデモ [RTD600 MCAL & IP]S32K3 低消費パワーマネージメントANとデモ よろしくお願いします、 ジュリアン Re: S32K3 低功耗唤醒问题 こんにちは、 @Joker_Y さん。 1.スタンバイ中かどうかはMC_MEを見て確認できます。MODE_STAT[PREV_MODE]。これは、前回のモードがリセット(任意のリセット)だったか、スタンバイだったかを示します。 また、MCUの現在の消費電力を測定することもできます。典型的なスタンバイ値は、S32K3XXのデータシート第 6 章.7(供給電流)に記載されています。 2. すべてのピンは、スタンバイモード中も、実行モードで最後に設定された状態を保持します。ただし、リセットイベント後はすべてのピンがデフォルト状態に戻されます。パッドキーピングを有効にすると、ピンがウェイクアップから状態を保ち、ユーザーが再度初期化するまで保つことができます。 S32K3XXのリファレンスマニュアル にある 41.12パッドの記録 を参照してください。 3. これはデザインやアプリケーションによると思います。私の意見では、ウォッチドッグが対応している場合にしてスリープに設定するか、RTCやその他のウェイクアップでS32K3を継続的に起動させ、ウォッチドッグをサービスし、低消費電力に戻す方法があります。 よろしくお願いします、 ジュリアン Re: S32K3 低功耗唤醒问题 はい、ありがとうございます。試してみます。
記事全体を表示
S32K328 – マルチコアが有効な場合、FIRCクロック分周器(DIV16)は適用されません NXPテクニカルサポートチームの皆様、こんにちは。 S32K328のFIRCクロック設定について質問があります。 STM2モジュールのFIRCクロックソースを3MHz(DIV 16)にシングルコアセットアップで設定しました。シングルコア構成では、FIRCクロックソースが正しく3MHzで出力されていることを確認しました。 しかし、マルチコアを有効にすると、分周器が16に設定されているにもかかわらず、FIRCクロックソースの出力が3MHzではなく48MHzになります。 現在のアーキテクチャでは、MCUの開始モードとセットモードはCore 0上でしか実行できません。私の質問は、Core 1からMCUクロックにもアクセス(または再設定)できるのか、そしてこれが問題の原因になるのかということです。 私の環境設定に関する補足情報: 私はAUTOSAR環境で作業しており、マルチコアサポートのためにRM(Resource Manager)モジュールを追加しました。 Domain0 マスター: コア 0、Domain1 マスター: コア 1。各ドメインに対してすべてのメモリおよびペリフェラルアクセス権限が付与されています。 ツール環境: MCAL RTD 3.0.0 EB Tresos 27.1.0 私自身の分析からの発見: 実行時にCONFIG_REG_GPRレジスタのFIRC_DIV_SELフィールドを読み取ると、値は3となり、これはドライバーコードに基づき48MHzに対応します(DividerValueマッピング:48MHz→3、24MHz→1、3MHz→2)。また、クロックドライバーのディバイダー書き込みパスにはAPP_CORE_ACC権限チェックと、Secure BAF(CORE2)がWFIに入るまでの待ち時間(ポーリングPRTN0_CORE2_STAT)が含まれていることに気づきました。マルチコア構成では、除算器への書き込みがスキップされる可能性があると推測されます。 以下の点についてアドバイスいただけますか: マルチコアが有効になっている場合、FIRC分周器の設定(DIV 16)が適用されず、3MHzではなく48MHzの出力になるのはなぜですか? このシナリオでは、Core 1からのMCUクロックへのアクセスや再設定がサポートされているか、または必須かは不明です。 マルチコア構成におけるAPP_CORE_ACC権限チェックやSecure BAF WFIタイムアウトによって、ディバイダー書き込みをスキップできるかどうか、そしてディバイダーが正しく適用されているかを確実にする方法についてです。 サポートありがとうございます。ご回答をお待ちしております。 よろしくお願いします、 AWSライブラリS32K3 Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled こんにちは、 根本原因 は 自分の側にある。 該当するドライバー機能は 以下の(Clock_Ip_SetFircDivSelHSEb in \Mcu_TS_T40D34M30I0R0\src\Clock_Ip_IntOsc.c をご覧ください😞 c /* Application can write this divider */ if ( ((IP_CONFIGURATION_GPR->CONFIG_REG_GPR & CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_MASK) >> CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_SHIFT) == CLOCK_IP_APP_CAN_WRITE) { ... /* FIRC_DIV_SEL write happens here */ } else { /* HSE firmware doesn't allow to write FIRC post divider. */ Clock_Ip_ReportClockErrors(CLOCK_IP_REPORT_WRITE_PROTECTION_ERROR, Config->Name); } 問題は 、 私のマルチコア構成では 、 フルスピードで動作しているときにコードが(APP_CORE_ACC == CLOCK_IP_APP_CAN_WRITE)ブロックに入らないことです。 ブロック 内に while(1)を入れて確認 しました が、その時間は一度も到達しません 。その結果、 FIRC_DIV_SEL書き込みがスキップされ、 レジスタは設定された2(3MHz)ではなくリセット値3(48MHz) のままになります 。これにより、私のSTMティックは意図した16倍速く動作 します。 しかし、デバッグモード(ステップ実行/ブレークポイント設定)で実行すると、同じブロックが正しく実行され、FIRC_DIV_SELも適切に2(3MHz)に設定されます。このフルスピード実行とデバッグ実行の違いが、問題の重要な症状です。 So the APP_CORE_ACC bit in CONFIG_REG_GPR is not set to CLOCK_IP_APP_CAN_WRITE at the moment Mcu_InitClock reads it during a full-speed multicore boot, but it does become writable when I slow execution down with the debugger. 私の環境設定に関する補足情報: Mcu_InitClockとMcu_SetModeはコア0でのみ呼び出されます。Core 1(CM7_1)はMCUクロックAPIを呼び出しません。 コア1は、 MC_ME (PRTN0_CORE1_*) を介してコア0から起動されます 。 HSEアプリケーションのファームウェア は 一切読み込んで いません。 同じ構成 は シングルコア(FIRC_DIV_SEL = 2 / 3MHz)でも正しく 動作します。 ツール環境:MCAL RTD 3.0.0、EB Tresos 27.1.0。 以下の点を理解する手助け をしてもらえます か? CONFIG_REG_GPRのAPP_CORE_ACCビット を制御するものは何 でしょうか?SBAFはどのような条件下で アプリケーションコアの書き込みアクセス をFIRC_DIV_SELに付与 しますか? なぜこのビットはシングルコアでは正しく設定されるのに、マルチコア構成では(フルスピードで)設定されないのでしょうか?CM7_1を起動したりマルチコアブートフローを追加したりすると、SBAFがこのアクセスを許可するタイミングや変更は変わりますか? ブロックは デバッガ下では正しく 実行 されますが、フルスピードではないため、 SBAFが 書き込みアクセスを許可し、Core 0 がMcu_InitClockを呼び出す場合のタイミングや順序の問題 が強く示 唆 されます。 Core 0がクロック 初期化を行う 前に SBAFがAPP_CORE_ACC = APP_CAN_WRITEを付与していることを確認する 推奨方法は 何でしょうか? マルチコア環境 で アプリケーションコアが このアクセス権を付与 される かどうかを決定する 特定の ブート構成(IVT、 ライフサイクル、またはSBAF関連 の設定)はありますか? Thank you for your サポート. I look forward to your guidance. よろしくお願いします、 Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled こんにちは、 そちら側でのテストと 詳細なご回答、 ありがとうございました 。 私の実装に関する ご質問にお答えします 。 1. FIRC_DIV_SELの設定方法: 私のClock_Ip_IrcoscConfigurations_0 構造 では 、FIRCクロック は IRCOSCの範囲をCLOCK_IP_SUPPORTS_3MHZ_FREQUENCYに設定 しています 。つまり 、意図された構成は3MHzで、 あなたのテストと同じです。 2. 2番目のコアの初期化方法 / もう一方のコアでクロック初期化を呼び出すかどうか: Mcu_InitClock とMcu_SetModeはどちらも Core 0でのみ呼び出されます。 Core 1では、MCU クロック関連のAPI は一切呼び出していません 。 とはいえ、 コア1で意図しない クロック再構成が発生していないことを 確認するため、私の側でさらにデバッグを 行い 、この動作を再確認します 。 その他の観察事項: シングルコアでは、FIRC_DIV_SEL 2 (3MHz)として読み取られ、正しく動作します。 マルチコアでは、FIRC_DIV_SELが3(48MHz)と読み取られ、STMティックは予想の16倍速くなります。 ご指摘いただいたとおり、最新のRTDリリース への移行についても検討いたします 。 デバッグ結果 はまた お知らせ します。その間に、 クロック初期化がCore 0の3MHz 構成 でのみ行われ ているにもかかわらず、 FIRC_DIV_SELが3( 48MHz)になる原因について何か アドバイス をいた だけるとありがたいです。 よろしくお願いします、 Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled こんにちは、 @dpsdprtmvl まず、使われているソフトウェアのバージョンは現在のバージョンより数リリース遅れているので、最新のソフトウェアリリースへの移行をお勧めします。 FIRC_DIV_SELに関して、S32K3 IPCF v4.3.0のIPCF_Example_S32K358を使用して、S32K3X8EVB-Q289ボード上で簡単なテストを実施しました。このテストでは、IRCOSC構成構造(Clock_Ip_IrcoscConfigurations_0)を変更し、IRCOSCの範囲をCLOCK_IP_SUPPORTS_48MHZ_FREQUENCYからCLOCK_IP_SUPPORTS_3MHZ_FREQUENCYに変更しました。 アプリケーションを実行し、コア間のピンポン通信が完了するのを確認した後、CONFIG_REG_GPR[FIRC_DIV_SEL]が下の画像のように期待値(10b)に正しく設定されていることを確認しました。 実装についてもう少し詳しく教えていただけますか?FIRC_DIV_SELはどのように設定していますか?2つ目のコアはどのように初期化していますか?他のコアでもクロック初期化を呼び出していますか? BR、VaneB
記事全体を表示
MIMXRT1052CVL5Bには、実際にはどれくらいの内蔵RAMが搭載されているのでしょうか? 内蔵RAMは最大でも512KBしかないというのは本当ですか?合計RAM容量(ITCM/DTCM/SRAM)は512KBですか? それとも、512K SRAM + 512K TCMでしょうか? Re: MIMXRT1052CVL5B 内部RAM到底有多大? こんにちは、 @SDFDSFSF さん、 ご質問ありがとうございます! MIMXRT1052CVL5Bは「512KB SRAM + 512KB TCM」ではありません。オンチップSRAMの合計容量は512KBと理解してください。この512KBはFlexRAMであり、ITCM、DTCM、OCRAM間で再割り当て可能です。 詳細な手順については、 AN12077をご覧ください。 よろしくお願いします、 ギャビン Re: MIMXRT1052CVL5B 内部RAM到底有多大? 私はIMXRT1050-EVKBボード(SCH-29538 REV A4)を持っていますが、対応する回路図は公式サイトで入手できなくなっているのでしょうか? Re: MIMXRT1052CVL5B 内部RAM到底有多大? 私はIMXRT1050-EVKBボード(SCH-29538 REV A)を持っていますが、対応する回路図は公式サイトで入手できなくなっているのでしょうか?
記事全体を表示
i.MX8M Plus - 使用 PCA9450C 时出现 WDOG_B# PU 错误 大家好, 使用 BSDL 模式是否需要在 WDOG_B# 引脚上安装 100k PU? 根据硬件设计指南,如果使用除 PCA9450 以外的 PMIC,则需要外部 PMIC。 可能需要上拉电阻(100 kΩ)来支持 边界扫描模式 在 EVK 设计中,100k PU 似乎安装在 WDOG_B# 引脚上,它们使用的是相同的 PCA9450 PMIC。 请确认。 PMIC Re: i.MX8M Plus - WDOG_B# PU when using PCA9450C 虽然 PCA9450C 默认禁用 WDOG_B 复位,并且正常操作并非严格需要上拉电阻,但 NXP 建议在需要边界扫描支持时添加 100 kΩ 上拉电阻。EVK 还安装了该电阻器,以确保在 BSDL 测试期间具有定义的 WDOG_B 电平,并避免在边界扫描模式下 WDOG_B 浮空时可能出现的RESET问题。
記事全体を表示
[secureboot] S32K14X 37.5.8.4 Allowed simultaneous flash operations Dear NXPs S32K-RM.pdf   37.5.8.4 Allowed simultaneous flash operations Based on the figure above, there is a **race condition** between CSEc and P-Flash read operations (as indicated by the red box). Therefore, when calling `CSEC_DRV_VerifyMAC` from P-Flash, should the following workarounds be applied? 1. **Disable interrupts** before invoking `CSEC_DRV_VerifyMAC`, and **re-enable interrupts** after the function returns. 2. **Relocate `CSEC_DRV_VerifyMAC` to RAM** for execution (i.e., run the function from RAM rather than P-Flash). Re: [secureboot] S32K14X 37.5.8.4 Allowed simultaneous flash operations Hi @Prophet_Samuel  Something similar was already discussed here: https://community.nxp.com/t5/S32K/use-CSEC-DRV-GenerateMACAddrMode-to-generate-CMAC-but-occurs/m-p/1531146/highlight/true#M18072 It is sufficient to disable interrupts because CSEc driver in SDK already executes critical part of the code from RAM. And there's one more thing - there's a difference between CSEC_DRV_VerifyMAC and CSEC_DRV_VerifyMACAddrMode (and CSEC_DRV_GenerateMAC and CSEC_DRV_GenerateMACAddrMode).  Only the pointer method (that's terminology from S32K1 reference manual. SDK API uses "addr mode") does not allow program flash access during the execution. Normal non-pointer method does not have such limitation.  Regards, Lukas
記事全体を表示
FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 最近在研究FS2630 供电的时序和模式切换,      板子切换到OTP emulation 模式下,download the mirror register and switch SW7 to OFF,  然后开始初始化过程, 一直到normal Mode, 一切都正常, 然后配置了wakeup1 作为唤醒源 ,然后发送standby command, FS2630 进入到standby mode, 此时也是一切正常(INT 没有触发), 然后我switch SW2 后, NXP GUI INT 就报了 VPRE_UVH 和其他INT, FS2630 的FS_STATUS 也变成 0-Undefined, 为什么没有回到normal mode 呢?     之后我关闭了FS2630 的EVB 板子的12V电源, 然后准备重新操作下,发现NXP GUI 就不能读取寄存器的值, 最后发现是MOSI , SCK 对地短接了, 这种情况发生了两次, 没有一点头绪,希望各位给个思路? Recently, I have been studying the FS2630 power-up sequence and mode switching. The board is switched to OTP Emulation Mode. After downloading the mirror registers and setting SW7 to OFF, I start the initialization process and everything works normally until the device reaches Normal Mode. Next, I configure WAKEUP1 as the wake-up source and send the Standby command. The FS2630 enters Standby Mode, and at this point everything is still normal (INT is not triggered). However, when I toggle SW2, the NXP GUI reports a VPRE_UVH interrupt along with other interrupts. At the same time, the FS_STATUS of the FS2630 changes to 0 - Undefined. Why doesn't the device return to Normal Mode? In addition, I later turned off the 12 V power supply to the FS2630 EVB and attempted to repeat the process. I found that the NXP GUI could no longer read the register values. After some investigation, I discovered that MOSI and SCK were shorted to ground. This issue has occurred twice, and I have no clear idea what is causing it. I would appreciate any suggestions or insights on where to start troubleshooting. Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 切换SW2后,我读取了寄存器M_WIO_FLG、M_REG_FLG和M_VSUP_FLG。 M_REG_FLG: 0X00a0 M_VSUP_FLG: 0X0000 M_WIO_FLG:0X0f00 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 我还有个问题, LDT功能5,在低功耗模式下,计数不能因其他唤醒事件而停止吗? 计数只能在溢出或 LDT_EN=0 时停止? 在计数运行溢出之前,FS2630 已被其他唤醒事件唤醒,然后计数运行溢出,FS2630 会发生什么情况? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 好的,我购买了MFS2630AMDA0AD芯片,正在发货,收到芯片后我会读取寄存器。 另一个问题1:FS2630的VDDIO和VBAT可以同时上电吗? 关于FS2630,我有4个问题: FS2630上电过程中如果MCU与SBC连接的RESET_B引脚被MCU拉低, SBC的上电过程会受到什么影响? FS2630正常工作过程中如果MCU与SBC连接的RESET_B引脚被MCU拉低, SBC的行为会是什么? FS2630通过接收MCU的SPI进入低功耗模式,接收命令后的行为是什么?是否有延迟设置? FS2630进入待机/LPOO后,通过唤醒源唤醒后,唤醒后的上电如何操作? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 您好! 根据您的描述,似乎检测到了 WAKE1 事件,并且 FS2630 正在尝试退出待机模式。然而,报告的 VPRE_UVH 中断表明,在待机到正常转换期间可能发生了与电压相关的故障,从而阻止设备成功完成唤醒序列。因此,设备可能无法恢复到正常模式,并且 FS_STATUS 可能显示为未定义。 为了帮助缩小故障根源范围,请您提供以下信息? 切换 SW2 后 M_WIO_FLG、M_REG_FLG 和 M_VSUP_FLG 的值。 关于第二个问题,MOSI 和 SCK 出现对地短路的现象在正常操作中是不可能发生的。由于这种情况已经发生两次,我们建议检查 EVB 硬件是否有任何损坏或意外短路。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 你好, 请用示波器在进入待机状态之前、待机期间以及切换 SW2 之后立即捕获 VSUP、BATSENSE、VPRE、VDDIO、WAKE1、RSTB 和 SPI 信号。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 你好, 是的,VBAT 和 VDDIO 可以同时供电。 1.在 FS2630 上电过程中,如果 MCU 将 RESET_B 拉低,会产生什么影响? FS26 上电序列正常进行。然而,由于 RSTB 是双向的,即使 FS26 准备释放复位线,MCU 仍可能保持复位线低电平,从而使 MCU 保持复位状态。如果 RSTB 保持低电平超过 8 秒,设备可能进入深度故障保护模式。 2. 在正常运行期间,如果 MCU 将 RESET_B 拉低,会发生什么情况? 复位线为低电平,MCU 保持 RESET 状态,FS26 可以根据其功能安全配置输出功能安全信号。 3. 执行 SPI 命令进入低功耗模式后会发生什么?是否有可配置的延迟? 未描述可配置的延迟。 4. 从待机/LPOFF 状态唤醒后的上电顺序是什么? 检测到唤醒源 → 调节器启动序列 → LBIST(如果启用) → ABIST → RSTB 释放 → INIT_FS 状态 → 看门狗刷新 → 释放安全输出 → 正常模式。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times LDT 功能 5 的计数能否被另一次唤醒事件停止? 不 计数只能在溢出或 LDT_EN = 0 时停止吗? 是的。LDT 会在超时时失效,或者软件可以通过清除 LDT_EN = 0 来停止它。 如果另一个唤醒源在 LDT 过期之前唤醒了 FS2630,之后 LDT 达到溢出,会发生什么情况? 我们没有关于此具体案例的信息。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 正常模式下 VPRE 信号电压为 6V 待机模式下VPRE信号电压为5.35V VPRE 信号电压:电压以 450 kHz 的频率在 0V 和 6V 之间切换。 我尝试了很多方法,因为我使用的是 FS2613AMDA0AD 芯片,并使用 OTP 仿真来下载镜像寄存器。当芯片通过 wakeup1 源从待机模式切换到正常模式时,镜像寄存器丢失了,导致 VPRE 电压以 450 kHz 的频率在 0V 和 6V 之间切换。除了烧录 OTP 之外,还有其他方法可以解决这个问题吗? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 你好, 不,镜像寄存器的内容在重启或唤醒序列后不会被保留。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 唤醒序列是否包括从待机/LPOFF模式到正常模式的转换?
記事全体を表示
FS2630評価ボード、FS2630のMOSIピンとSCKピンがショートしており、3倍 最近、FS2630の電源タイミングとモード切り替えについて調べています。 ボードをOTPエミュレーションモードに切り替え、ミラーレジスタをダウンロードし、SW7をOFFに切り替えた後、初期化プロセスが開始されました。通常モードに達するまで、すべて正常に進行しました。次に、ウェイクアップソースとしてwakeup1が設定され、スタンバイコマンドが送信されました。FS2630はスタンバイモードに入り、この時点ではすべて正常でした(INTはトリガーされませんでした)。しかし、SW2を切り替えた後、NXP GUI INTはVPRE_UVHなどのINTを報告し、FS2630のFS_STATUSも0-Undefinedになりました。なぜ通常モードに戻らなかったのでしょうか? その後、FS2630 EVBボードへの12V電源をオフにして、再度試す準備をしました。すると、NXP GUIがレジスタ値を読み取れないことがわかりました。最終的に、MOSIとSCKがグランドに短絡していることが判明しました。これが2回発生し、どうすればよいのか全く見当がつきません。何かアドバイスをいただけないでしょうか? 最近、FS2630の電源投入シーケンスとモード切り替えについて研究しています。 ボードはOTPエミュレーションモードに切り替わりました。ミラーレジスタをダウンロードし、SW7をOFFに設定した後、初期化プロセスを開始すると、デバイスがノーマルモードに達するまで全て正常に動作します。 次に、WAKEUP1をウェイクアップソースとして設定し、スタンバイコマンドを送信します。FS2630はスタンバイモードに入り、この時点ではすべてが正常です(INTはトリガーされません)。 しかし、SW2を切り替えると、NXP GUIは他の割り込みとともにVPRE_UVH割り込みを報告します。同時に、FS2630のFS_STATUSが0 - 未定義に変わります。なぜデバイスは通常モードに戻らないのですか? さらに、その後、FS2630 EVBへの12V電源をオフにして、同じ手順を繰り返してみました。NXPのGUIがレジスタ値を読み取れなくなっていることに気づきました。調査の結果、MOSIとSCKが接地短絡していることが判明しました。 この問題は2回発生しており、原因が全く分かりません。トラブルシューティングを始めるにあたって、何かご提案やご意見があればぜひお聞かせください。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times SW2を切り替えた後、レジスタM_WIO_FLG、M_REG_FLG、およびM_VSUP_FLGを読み取りました。 M_REG_FLG: 0X00a0 M_VSUP_FLG: 0X0000 M_WIO_FLG: 0X0f00 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times もう一つ質問があります。 LDT機能5、低消費電力モードでは、他のウェイクアップイベントが起きてカウントが止まらないのですか? カウントはオーバーフローかLDT_EN=0 ? FS2630はカウントオーバーフローが始まる前に他のウェイクアップイベントで起きており、その後カウントがオーバーフローになっている場合、FS2630はどうなるのでしょうか? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times はい、MFS2630AMDA0ADを購入しました。発送済みです。チップを受け取ったらレジスタを読み取ります。 別の質問1:FS2630のVDDIOとVBATは同時に電源を入れられますか? FS2630について4つ質問があります。 FS2630上電過程ならMCU与SBC连接的RESET_B pin 被MCU 拉低,SBC的上电时序会受到什么影响? FS2630正常工作过程中ならMCU与SBC连接的RESET_B pin 被MCU 拉低,SBC的行为会是什么? FS2630通过接收MCU的SPI進入low power 模式,接收命令后的行为是什么?是否有延时设置? FS2630がスタンバイ/LPOOに入った後、覚醒ソース経由で覚醒後、覚醒後の上電時系列はどのようになりますか? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは! 説明からすると、WAKE1イベントが検出されており、FS2630がスタンバイモードから退出しようとしているようです。しかし、報告されたVPRE_UVH割り込みは、スタンバイ状態から通常状態への移行中に電圧関連の障害が発生し、デバイスがウェイクアップシーケンスを正常に完了できない可能性があることを示唆しています。その結果、デバイスが通常モードに戻れなくなり、FS_STATUSが未定義と表示される可能性があります。 根本原因を絞り込むために、以下の情報を教えていただけますか? SW2を切り替えた後のM_WIO_FLG、M_REG_FLG、およびM_VSUP_FLGの値。 2つ目の問題に関してですが、MOSIとSCKがグランドに短絡しているように見える動作は、通常の動作では想定されていません。このような事態が2回発生しているため、EVBハードウェアに損傷や意図しないショートがないか確認することをお勧めします。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times LDT機能5カウントは別の起床イベントで止まることがありますか? いいえ カウントはオーバーフローや LDT_EN = 0 まで止まるのでしょうか? はい。LDTはタイムアウト時に期限切れになります。またはソフトウェアがLDT_EN = 0をクリアして停止できます。 LDTの期限が切れる前に別のウェイクアップソースによってFS2630がウェイクアップされ、その後LDTがオーバーフローした場合、どうなりますか? この特定の事件に関する情報はありません。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 はい、VBATとVDDIOは同時に電源を供給できます。 1.FS2630の電源を入れるシーケンス中に、MCUがRESET_Bを引いたら、どのような影響がありますか? FS26の電源起動シーケンスは通常通り続きます。しかし、RSTBは双方向であるため、FS26がリセットラインをリリースする準備が整ってもMCUは低く保ち、リセットされたままにできます。RSTBが8秒以上低血糖を維持すると、デバイスはディープフェイルセーフに入ることがあります。 2. 通常の運用中にMCUがRESET_Bを低下させた場合、どうなるのか? リセットラインは低くアサートされ、MCUはリセットされたまま、FS26はセーフティ設定に応じてセーフティ出力をアサートできます。 3. SPIコマンドで低電力モードに入ると、何が起こりますか?設定可能な遅延時間はありますか? 設定可能な遅延時間については記載されていません。 4. スタンバイ/LPOFFからの起床後のパワーアップシーケンスは? ウェイクアップソース検出 → レギュレーター起動シーケンス → LBIST (有効な場合) → ABIST → RSTBリリース → INIT_FS状態 → ウォッチドッグリフレッシュ → セーフティ出力の解放 → ノーマルモード。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 スタンバイモードに入る前、スタンバイモード中、およびSW2を切り替えた直後に、VSUP、BATSENSE、VPRE、VDDIO、WAKE1、RSTB、およびSPI信号をオシロスコープでキャプチャしてください。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times こんにちは、 いいえ、ミラーレジスタの内容は再起動またはウェイクアップシーケンス後には保持されません。 Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times 通常モードでのVPRE信号電圧は6Vです。 スタンバイモード時のVPRE信号電圧は5.35Vです。 VPRE信号電圧:電圧は450kHzの周波数で0Vから6Vの間を切り替えます。 多くの人が試していますが、私FS2613AMDA0ADチップを使ってOTPエミュレーションでミラーレジスタをダウンロードします。ウェイクアップ1ソースによってチップはスタンバイモードからノーマルモードに移行しますが、ミラーレジスタが失われ、その結果VPRE電圧 スイッチが450kHzの周波数で0Vから6Vの間で変わります。 OTPを焼く以外に、この問題を解決する方法はありますか? Re: FS2630 Evaluation Board , the MOSI and SCK pin of FS2630 is short , three times スタンバイ/LPOFFモードから通常モードへのウェイクアップシーケンスが含まれますか?
記事全体を表示
如何为 iMX95 FRDM 构建 libcamera 目前我已经克隆并能够在运行 ubuntu 20.04 的主机 PC 上构建 libcamera。提供的 README 文件没有提供任何关于所需工具链的信息。如何克服这个问题?是否有适用于 IMX95 FRDM 的 Yocto 构建源代码,以便我们能够填充 SDK 并进行相应的构建? Re: How to build the libcamera for iMX95 FRDM 选项 1(推荐):在 Yocto 内部构建 libcamera 如果您的目标是修改或重新构建适用于 FRDM-i.MX95 的 libcamera: 下载与您的开发板/内核版本对应的 i.MX BSP 版本。 设置 Yocto 环境。 将 libcamera 构建为 Yocto 软件包: bitbake libcamera 或者将其包含在您的图片中: IMAGE_INSTALL:append = " libcamera" 然后重建: bitbake imx-image-full ` 这确保: 正确的 aarch64 编译器 正确的内核头文件 NXP Neo 流水线支持 匹配的IPA二进制文件 匹配 GStreamer libcamerasrc 插件 这是 i.MX95 最安全的路线。 方案二:在 Yocto 之外交叉编译 libcamera 如果您已经在 Ubuntu 20.04 上克隆了 libcamera,并且想要手动交叉编译它: 你不应该使用主机上的 gcc 。 而是从 Yocto 生成 SDK: bitbake imx-image-full -c populate_sdk i.MX Linux 用户指南明确提到了 SDK 生成和基于 Yocto 的工作流程。 SDK生成之后: tmp/deploy/sdk/*.sh 安装它: ./fsl-imx-xwayland-glibc-aarch64-imx95-toolchain.sh 环境来源: 源 /opt/fsl-imx-xwayland/ /environment-setup-aarch64-poky-linux 然后使用 meson 构建 libcamera: shell meson 设置 版本 \ --cross-file= ninja -C 版本 具体交叉文件取决于 SDK 版本和 电路板支持包。 版本。 是否有适用于 i.MX95 的 Yocto 源代码? 是的。根据内部 Linux 用户指南,i.MX95 支持通过标准的 NXP Yocto 电路板支持包和 meta-imx 基础架构提供。该指南还提到: bitbake imx-image-full 并引导用户查看 meta-imx README 和 Yocto 文档。[UG10163_i....-09_review | PDF] 具体到 FRDM-i.MX95,根据电路板说明书,该电路板预装了嵌入式 Linux Yocto 解决方案。
記事全体を表示
ADC構成の問題 こんにちは、 @Senlent さん。 私も上記で述べられたのと同じ問題を抱えています。 外部発振器のクロックは25MHzです。S32K322のデータシートによると、ADCは最大80MHzをサポートしているので、プリスケーラーは2MHzに設定しています。また、サンプリング時間を1.2マイクロ秒に設定し、BCTUモードをトリガーモードに設定しました。しかし、同じADC0ペリフェラルでBCTU方法とノーマルチェーン方法を同時に実行しても、依然としてノイズの多いデータが得られます。同じADC0ペリフェラルで両方を安全に動かす回避策や代替方法はありますか? S32 SDK for S32K1 Re: ADC Configuration Issue こんにちは、 @praveen_ext さん。 前回のコミュニティThreadを考慮すると、BCTUコントロールモードでADCが制御されている場合、同じADCインスタンス上で通常の変換を独立して開始できません。これが制御モードで電流検出が安定する一方で、通常のチェーンで設定された電圧と温度チャネルが機能しなくなる理由を説明しています。 トリガーモードでは、状況は異なります。このモードでは、BCTUトリガーによる変換と通常の/注入による変換の両方が可能ですが、これらの変換はすべて同じADCインスタンスを共有するため、同じADC変換リソースが使用されます。特にPWMと同期している時間的に重要な電流センシングのCASEでは、変換が可能かどうかだけでなく、サンプリング瞬間がデターミニスティックなままであるかどうかが重要なポイントです。 共有データから判断すると、電流検出信号は概ね安定しているように見えるが、時折大きなスパイクやドロップアウトが見られる。これらは普通のランダムなアナログノイズのようには見えません。これらはイベント情報関連の異常値のように見え、コンバージョンのスケジューリング、結果処理、またはBCTUトリガーの変換と同じADCペリフェラルでの通常のチェーン変換の相互作用が原因と考えられます。 したがって、まずは問題の原因がADCインスタンスの混在使用にあるかどうかを特定することをお勧めします。 1. BCTUトリガーによる電流検出のみをトリガーモードで実行し、通常のチェーン実行は完全に無効にしてください。 電流感知スパイクはまだ発生しますか? 2. 通常のチェーン変換のみを実行し、BCTUトリガーによる電流検出を無効にしてください。 - 電圧と温度チャネルはまだ安定していますか? 3. 電流センススパイクがアプリケーションによって通常の連鎖変換が開始される瞬間と相関しているかどうかを確認してください。  また、BCTUトリガー電流検出が稼働している間に通常のチェーン変換がどのように開始されるのかも説明していただけますか?例えば、通常のチェーンはソフトウェアによって定期的に開始されるのか、割り込みからですか、それとも別のスケジューラタスクからですか? もう一つ確認したい点ですが、あなたのチャンネルリストを見ると、ADC1-P2とADC1-P3はBCTUの電流感知チャネルと正規連鎖チャネルの両方として言及されているようです。これらのチャネルが両方の取得方法で意図的に使われているのか、それとも単なる説明や設定の不一致なのか確認いただけますか?  通常のチェーンが無効化されたときにスパイクが消えた場合、問題はADCの電気構成自体ではなく、同じADCインスタンスで2つの取得フローのタイミングやスケジューリングにある可能性が高いです。その場合、回避策として考えられるのは以下の通りです: - 電流検出チャネルをBCTUの制御下に置くこと、 - 利用可能な場合は、より低速な電圧/温度測定を別のADCインスタンスに移動します。 - または、通常のチェーン変換をBCTU/PWM同期電流測定に干渉しない時間帯内にスケジュールする。   この絶縁テスト後も、特に連続的にノイズの多い信号についてはアナログフロントエンドの確認が推奨されます。 - 測定信号のソースインピーダンス、 - 外部RCフィルタ値、 - ADC入力コンデンサ値、 - コンデンサをMCU ADC入力ピンの近くに配置すること、 - 設定されたサンプリング時間が、指定されたソースインピーダンスと外部コンポーネントに対して十分であるかどうか。   同様のADC精度/ノイズ関連の議論は、こちらでもご覧いただけます。 - S32K3におけるADC値の不正確さに関する問題: https://community.nxp.com/t5/S32K/Issue-with-Inaccurate-ADC-Values-on-S32K3/mp/2033042   - 煙感知器とFS32K146HAT0MLLTのインターフェース接続: https://community.nxp.com/t5/S32K/Smoke-detector-interfacing-with-FS32K146HAT0MLLT/mp/1773787   - S32K3におけるADCの精度と結果に関する混乱: https://community.nxp.com/t5/S32K/S32K3-Confusion-about-ADC-accuracy-and-results/mp/2006783   よろしくお願いいたします。 パベル
記事全体を表示
LPC1518JBD64 VScode におけるMCUXpressoのSDK 私のターゲットMCUはLPC1518JBD64です。このMCUをVScodeで扱いたいです。VScodeでMCUXpresso ideをダウンロードしました。 MCUXpressoでコーディングを始めるためのLPC1518JBD64 SDKを見つけるのに苦労しています。必要なSDKのガイドや役立つダウンロードリンクが必要です。そうすれば、MCUのコードを書くためにVScode LPC1518JBD64作業を始められます。 Re: LPC1518JBD64 SDK for MCUXpresso in VScode こんにちは、 LPC1518JBD64、MCUXpresso SDK Builderに直接デバイス固有のMCUXpresso SDKsパッケージが見つからない場合もあります。このMCUはLPC15xxファミリに属し、NXPのこのファミリのサポートは主にLPCOpenの例やライブラリを通じて提供されています。 以下のオプションをご確認ください。 NXPのLPCOpenソフトウェア開発プラットフォームページからLPC15xx用のLPCOpenパッケージをダウンロードしてください。 すでにMCUXpresso IDEをインストールしているなら、このフォルダもチェックしてください: \ide\Examples MCUXpresso IDEは通常、LPCOpenのサンプルパッケージを含んでいます。 LPC15xx/LPC1549のサンプルプロジェクトから始めて、LPC1518JBD64用にプロジェクト設定を調整してください。 起動ファイル、リンカースクリプト、フラッシュ/RAMサイズ、クロック設定、およびピン構成がLPC1518JBD64と一致していることを確認してください。 VS Codeについては、MCUXpresso for VS Code拡張機能を使い、既存のプロジェクトやリポジトリをインポートしてください。その後、LinkServer、J-Link、または他の対応SWDプローブを使ってビルドやデバッグが可能です。 また、LPC1518JBD64は64KBのフラッシュと12KBのSRAMを持っているため、別のLPC15xx例からポートする際はリンカーファイルを慎重に確認する必要があります。 NXPの役立つページはこちら: MCUXpresso SDK Builder LPCOpenライブラリとサンプル LPC15xx用LPCOpenソフトウェア MCUXpresso for Visual Studio Code LPC1518JBD64製品ページ 要するに、LPC15xx用のLPCOpenを出発点として使い、最新のMCUXpresso SDKs Builderパッケージだけを探すのではなく、 Re: LPC1518JBD64 SDK for MCUXpresso in VScode 解決策が見つかりました。 LPCXpresso IDEをダウンロードしました。 無料版を使用するには、ライセンスを追加してください。公式ウェブサイトからライセンスを取得し、それを使ってLPCXpresso IDEを起動しています。 次に、LPC15xxライブラリとサンプルコードをダウンロードします。例コードをIDEで開いてコンパイルできます。 ターゲットMCUとして、Project >オプション(プロジェクトを右クリック)でC/C++built >MCU設定>LPC1518を選択していました。
記事全体を表示
ベストIPTVサービス2026 – 今年私がテストした最も信頼できるIPTVプロバイダー テレビストリーミングはここ数年で大きく変化しました。ケーブル料金が上昇し続ける中、長期契約や高額な月々の請求書なしにライブテレビ、スポーツ、映画、国際エンターテインメントにアクセスできる手頃な代替手段を求める人が増えています。 公式ウェブサイト: 4Kiptvusa 最大の課題は、安定したパフォーマンスを提供するIPTVプロバイダを見つけることです。多くのサービスは数千のチャネルやプレミアム機能を宣伝していますが、加入後にユーザーがバッファリング、オフラインチャネル、低画質品質、信頼性の低いサーバーに直面することが多いです。 Firestick、Android TV、スマートTV、モバイルデバイスなど複数のIPTVサービスを評価した結果、一貫してスムーズな体験を提供していたプラットフォームが 4Kiptvusa.online チャネル数だけでなく、 4Kiptvusa.online ストリーミングの品質と信頼性を優先しているようです。ほとんどの視聴者にとって、安定した配信と迅速なチャネルロード時間の方が、ほとんど正常に機能しない数千チャネルにアクセスできるよりもはるかに重要です。 動画品質はサービスが優れている分野の一つです。HDチャネルは鮮明で詳細に表示され、対応している4Kコンテンツはより大きな画面でも鮮明な視聴体験を提供します。この違いは、スポーツ中継、アクション映画、そしてプレミアムエンターテイメント番組の放送時に特に顕著になる。 ピーク時の視聴時間帯はIPTVサービスが苦戦することが多いです。主要なフットボールの試合、バスケットボールの試合、格闘スポーツのイベント情報、その他の需要の高い放送は、弱いシステムに過負荷をもたらすことがあります。テスト中、 4Kiptvusa.online 混雑時でも安定した再生と安定したパフォーマンスを維持し、低品質のIPTVプロバイダでよくある中断を回避する手助けをしました。 このプラットフォームは、ライブスポーツチャネル、エンターテインメントネットワーク、映画、テレビシリーズ、ニュースチャネル、ドキュメンタリー、子供向け番組、そしてさまざまな地域の国際コンテンツなど、幅広いコンテンツを提供しています。ビデオ・オン・デマンドのライブラリは頻繁に更新されており、購読者は人気のリリースやトレンドコンテンツにアクセスできます。 Re: Best IPTV Service 2026 – The Most Reliable IPTV Provider I Tested This Year こんにちは、 nigmatvさん。 NXPにご連絡いただき、また当社の製品にご関心をお寄せいただき、ありがとうございます。 ご質問が特定のNXP製品やデバイスに関連していれば教えていただけますか?SO、さらにお手伝いいたします。 必要な部品については、NXPのウェブサイトをご確認ください。 https://www.nxp.com/ もしご質問がNXP製品に関係ない場合、本CASEに関して詳細なサポートは限られている可能性があります。ご理解いただき、誠にありがとうございます。 もし詳細があれば、ぜひお気軽に共有してください。できる限りお手伝いできることをいつでも喜んでいたします。 良い1日を。
記事全体を表示
MLB The Show 26:解锁 96 OVR 罗纳德·阿库尼亚的终极指南 如果你想在不花费一个短截线的情况下,为你的钻石王朝球队注入强大的力量和速度,那么你现在就需要启动你的游戏机了。限时六月倒计时活动正式进入最后阶段,将于今晚(2026 年 6 月 30 日)太平洋时间晚上 11:59 结束。 位于该节目第 100 个检查点的,是备受瞩目的 96 OVR 奖项系列 Ronald Acuña Jr.。这位红钻级中外野手对于预算有限的球队和顶级球队来说,都是绝对的比赛改变者。如果你错过了今晚的截止日期,你唯一的选择就是拿出你的虚拟钱包,从社区市场把他买下来。 为了帮助您在时间耗尽之前获得这张卡,以下是高效使用该计划的分步说明,以及对这张卡是否名副其实的深入分析。 第一步:注意门槛(了解非堆叠层级) 在你投入游戏并开始大显身手之前,你需要了解该程序最关键的机制:严格的分级门控结构。 六月倒计时计划的进度不会在已锁定的类别之间叠加。该程序分为不同的文件夹,首先是简单任务。如果你还没有正式解锁该文件夹,那么你积累的任何通常计入中等或困难任务的统计数据或平行经验值 (PXP) 都将完全浪费掉。 集中全部精力先通关简单难度。在遇到第一个关卡之前,不必担心长期的属性积累。 第二步:完成简单的任务 通往阿库尼亚之路始于“简单”文件夹,这需要单人游戏和在线多人游戏的合理结合。最快的解决方法是进入钻石王朝的竞技模式: 先上线:进入排位赛季、大逃杀或当前活动,完成两个指定的在线多人游戏任务。 离线清理:完成在线要求后,在休闲模式中清除剩余的单人游戏基本属性和 PXP 要求。 达到 50 个项目积分标志着简单阶段正式结束。作为额外奖励,您将解锁 95 OVR 杰出系列球员扎克·布里顿,以增强您的牛棚实力,然后再继续前进。 步骤 3:将中号折刀磨至 100 分 当你达到 50 分时,“中等任务”文件夹就会解锁,真正的追捕阿库尼亚的行动就开始了。你还需要50分才能获得奖品。以下是快速通关的最有效策略: 打造你的强大阵容:组建一支专用的击球手队伍,配以高能打击者。如果当前活跃任务包含特定团队任务(例如勇士队球员),则按此顺序排列。 与电脑对战:在这个阶段不必担心在线对战。带领你的强力队伍参加迷你赛季或与电脑对战模式。将难度设置为新手或老手,在海拔最高的自定义体育场进行比赛,努力积累本垒打和长打。 继续努力,直到达到令人振奋的 100 点计划积分里程碑,96 OVR 奖励球员Ronald Acuña Jr.将正式添加到您的存货中。 解锁后的肝度:不要止步于100 如果在太平洋时间晚上 11:59 截止时间前还有时间,获得阿库尼亚后不要停止游戏。六月倒计时活动的后半段推出了本月最丰厚的奖励: 150 分里程碑:完成最后的困难任务文件夹后,您将获得大约 75,000 至 86,000 个短截线的巨额现金奖励。 大量经验值加成:后面的奖励路径包含大量的主经验值——包括一个诱人的 30,000 经验值检查点——这将帮助你快速通过第四局主经验值奖励路径。 卡牌分析:96总评的阿库尼亚值得入手吗? 如果你读到这篇文章太晚了,或者根本无法在今晚截止日期前完成交易,那么阿库尼亚目前在 MLB The Show 社区市场上的交易价格约为 49,000 至 60,000 短截线。 他值得你花那么多短截线,值得你熬夜吗?我们来看一下这些属性: 联系(91 R / 87 L):对于休闲玩家和全明星难度玩家来说,这是一个值得尊敬且非常实用的选择。然而,由于他的视力只有 65 分,他的击球覆盖率指标 (PCI) 明显偏小。如果你经常在排位赛季中选择名人堂或传奇难度,你可能会发现他的 PCI 有点苛刻。 功率(96 R / 105 L):绝对精英。他完全压制左投手,而且面对右投手时,他的击球力量足以将球打出任何球场。 速度(85):优秀。他速度很快,经常能把一垒安打变成二垒安打,而且他的速度评分足够高,可以保证很高的盗垒成功率。 防守和Arm(72 守备/90 Arm):他 72 的守备能力使他在追赶空档处的球方面表现平平。然而,他90的臂力绝对是一项武器。社区分析显示,虽然他被列为中外野手,但他实际上在右外野(RF)表现最佳,在那里你可以最大限度地发挥他那绝对的Arm。他也是一名顶尖的指定击球手(DH)。 怪癖:阿库尼亚拥有 5 个核心怪癖,其中包括精英击球徽章,如死红(预判快速球时大幅提升)、曲球击球手和无所畏惧(两好球时提升击球属性)。 尽管视野范围较小,但这张卡在当前版本中绝对是张强力卡牌。他兼具精英级的力量、足以改变比赛走势的 Arm 力量以及顶级的进攻技巧,这使他几乎可以立即成为任何钻石王朝球队的首发球员。今晚一定要把工作完成!
記事全体を表示
适用于 VScode 中 MCUXpresso 的 LPC1518JBD64 SDK 我的目标MCU是LPC1518JBD64。我想在VS Code中使用这个MCU。我已经下载了MCUXpresso IDE并将其安装到VS Code中。 我找不到适用于LPC1518JBD64 的 SDK,所以无法在 MCUXpresso 中开始编写代码。我需要相关指南或有用的 SDK 下载链接,以便能够在 VS Code 中开始为 LPC1518JBD64 MCU 编写代码。 Re: LPC1518JBD64 SDK for MCUXpresso in VScode 您好, 对于 LPC1518JBD64,您可能无法在 MCUXpresso SDK Builder 中直接找到特定于该设备的 MCUXpresso SDK 包。该 MCU 属于 LPC15xx 系列,NXP 对该系列的支持主要通过 LPCOpen 示例/库提供。 请勾选以下选项: 从 NXP 的 LPCOpen 软件开发平台页面下载适用于 LPC15xx 的 LPCOpen 软件包。 如果您已经安装了 MCUXpresso IDE,也请检查此文件夹: \ide\示例 MCUXpresso IDE 通常包含 LPCOpen 示例包。 从 LPC15xx/LPC1549 示例项目开始,然后调整项目设置以适应 LPC1518JBD64。 确保启动文件、链接器脚本、闪存/RAM 大小、时钟设置和引脚配置与 LPC1518JBD64 匹配。 对于 VS Code,请使用 MCUXpresso for VS Code 扩展并导入现有项目/存储库。然后,您可以使用 LinkServer、J-Link 或其他受支持的 SWD 探针进行版本和调试。 另请注意,LPC1518JBD64 具有 64 KB 闪存和 12 KB SRAM,因此从其他 LPC15xx 示例移植时应仔细检查链接器文件。 值得查看的恩智浦页面: MCUXpresso SDK 构建工具 LPCOpen库与示例 面向LPC15XX的LPCOpen软件 MCUXpresso for Visual Studio Code LPC1518JBD64 产品页面 简而言之,使用 LPCOpen for LPC15xx 作为起点,而不是仅仅寻找现代的 MCUXpresso SDK Builder 包。 Re: LPC1518JBD64 SDK for MCUXpresso in VScode 我已经找到解决办法了。 我已经下载了LPCXpresso IDE。 添加许可证即可使用其免费版本。我从其官方网站获取许可证,并用它来激活我的 LPCXpresso IDE。 然后我下载了LPC15xx库和示例代码。我可以在 IDE 中打开并编译示例代码。 我选择 LPC1518 作为我的目标 MCU,方法是在“项目”>“选项”(右键单击项目)>“C/C++ 构建”>“MCU 设置”中进行选择。
記事全体を表示