Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
[S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR Hi, Following up on S32N55 (HSE2) Secure Debug. CRS(APP) challenge-response authentication now works (final response 0x4A4A4A4A). I am now on the debug card request (HSE_DEBUG_CMD_CARD_REQUEST), and it returns: HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — "invalid debug domain map in debug card." What I send (per your earlier feedback): Packet2 Debug Domain Signal List: array style, List[22..26] = 0x01 each (CRS: Cortex-M7, PCIe, CRS NoC/CAN NoC, CANXL0-1, CANXL2-3), all other bytes 0x00. Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 as advised (bits 22-26). AuthScheme: macAlgo = HSE_MAC_ALGO_CMAC = 0x11. AuthTag: AES256-CMAC over the card info, authLen = 16. What I have tried for enabledDebugDomainMap (uint64_t, 8 bytes on the wire): Little-endian: 00 00 C0 07 00 00 00 00 → 0x20 Big-endian: 00 00 00 00 07 C0 00 00 → 0x20 bit27 (0x08000000, matching AUTH target 0x1B) → 0x20 All return the same 0x20. Questions: 1. For CRS, what is the exact enabledDebugDomainMap (uint64_t) value HSE expects, and in what wire byte order? 2. Must enabledDebugDomainMap (Packet3 bitmask) be consistent with the Debug Domain Signal List (Packet2, array List[22..26])? What is the exact relationship? 3. The RM example states "domain 1,3 enabled → 0x00..A0." Could you clarify the domain-to-bit mapping so I can compute the CRS value? 4. Does HSE validate the domain map before verifying the AuthTag? I want to confirm whether 0x20 indicates only the domain map is wrong, or whether other fields (e.g. the AuthTag / signed data range) could also be causing HSE to stop at this point. I also want to confirm the signed data range for the card AuthTag: I currently compute AES256-CMAC over the card info fields (authKeyRef + reserved0 + ownerId + authScheme + signal list + domain map + UID list). Is this the correct data to sign? Best regards, Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR Hello, @EddiePark  Thanks for your post. 1. It is pleased to hear that the phase1 has been passed without issues.2.  For your phase2 queries, I am still checking with it for a more clear description, and would reply you later if there are any valuable updates To make it aligned, would you mind sharing with me the latest logs and corresponding scripts used again, which could be shared via message as usual. BR Chenyin  
記事全体を表示
[S32N55 / HSE2] デバッグカード要求 — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR こんにちは、 S32N55 (HSE2) セキュアデバッグに関する続報です。CRS(APP)チャレンジレスポンス認証が機能しました(ファイナルレスポンス0x4A4A4A4A)。現在、デバッグカード要求(HSE_DEBUG_CMD_CARD_REQUEST)を実行中ですが、以下の結果が返されます。 HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — 「デバッグカード内のデバッグドメインマップが無効です。」 (以前のフィードバックに基づいて)私が送信するもの: Packet2 デバッグドメイン信号リスト:配列スタイル、List[22..26] = 0x01 各(CRS:Cortex-M7、PCIe、CRS NoC/CAN NoC、CANXL0-1、CANXL2-3)、その他のバイトは0x00。 Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 (ビット 22-26) が推奨どおりに動作しました。 AuthScheme: macAlgo = HSE_MAC_ALGO_CMAC = 0x11。 AuthTag: カード情報に対するAES256-CMAC、authLen = 16。 enabledDebugDomainMap(uint64_t、8バイト)に対して私が試したこと: リトルエンディアン: 00 00 C0 07 00 00 00 00 → 0x20 ビッグエンディアン: 00 00 00 00 07 C0 00 00 → 0x20 bit27 (0x08000000、AUTHターゲット0x1Bに一致) → 0x20 すべて同じ0x20を返します。 質問: 1.CRSの場合、HSEが期待するenabledDebugDomainMap(uint64_t)の正確な値は何か、また、ワイヤバイトの順序はどうなっているのか? 2. enabledDebugDomainMap(Packet3ビットマスク)は、デバッグドメインシグナルリスト(Packet2、配列List[22..26])と一致している必要がありますか?正確な関係性はどのようなものですか? 3. RMの例では「ドメイン1、3が有効になりました → 0x00..A0」と記載されています。ドメインからビットへのマッピングについて、CRS値を計算するために説明してもらえますか? 4. HSEはAuthTagを検証する前にドメインマップを検証しますか?0x20がドメインマップだけが間違っていることを示すのか、それともAuthTagや署名済みデータ範囲などの他のフィールドもHSEがこの時点で停止している可能性があるのかを確認したいです。 また、カードのAuthTagの署名付きデータ範囲を確認したいです。現在、カード情報フィールド(authKeyRef + reserved0 + ownerId + authScheme + signal list + domain map + UID list)に対してAES256-CMACを計算しています。これは署名するデータとして正しいですか? よろしくお願いいたします。 Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR こんにちは、 @EddiePark 投稿ありがとうございます。 1.フェーズ1が問題なく通過したと聞いて嬉しく思います。2.フェーズ2に関するご質問につきましては、より明確な説明を得るために現在確認中です。何か有益な情報が得られ次第、後ほどご連絡いたします。 整合性を合わせるために、最新のログと対応するスクリプトを再度共有してもらえますか?通常通りメッセージで共有できます。 BR チェイン
記事全体を表示
NFCアンテナツール - スキン効果 こんにちは!NFCアンテナツールに関して質問があります。このツールは、アンテナパラメータを計算する際に表皮効果を考慮していますか? Re: NFC Antenna Tool - Skin effect こんにちは、@lucas_uy_13さん はい、そうです。
記事全体を表示
ソフトウェアライセンス延長の期限切れ申請   サポートチームの皆様、 添付画像に示すように、S32DSのライセンスの有効期限が近づいていることを通知するメールを受け取りました。 現在進行中の作業では、引き続きS32DSを使用する必要があります。ソフトウェアを使い続けられるようにライセンスを延長してもらえますか? ご協力ありがとうございます。 よろしくお願いいたします。 Re: Request for Software License Extension Due to Expiration こんにちは、 あなたのアカウントを確認したところ、ライセンスは2028年まで有効です。
記事全体を表示
S32 デザインスタジオライセンス更新 フルフィルメントID:128143961 有効期限:2026年6月22日 製品:ARM v2018 R1用S32 Design Studio。 起動コード:3E1F-50E5-6F93-F06F Re: S32 Design Studio License Renewal こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター
記事全体を表示
S32KはMPUを無効にした場合のSRAMのデフォルト属性です。 こんにちは、NXPテクニカルチームの皆様。 S32KチップのMPUが有効になっていない場合、SRAMのデフォルト属性はどうなるのでしょうか?具体的に、SRAMのデフォルト設定における「share」と「cache」の属性は何ですか? ARMv7-mアーキテクチャのリファレンスマニュアルを参照したところ、SRAMのデバイスタイプは「device」とされており、SRAM全体がシェア可能でキャッシュできないことを意味しているようです。次の画像をご覧ください。 私のプロジェクトに戻りますが、MWCT2016s を使用するプロジェクト (つまりS32K312) は、MPU が有効になっていない場合に HSE 機能が異常になるため、SRAM 領域を共有可能かつキャッシュ不可に設定するように MPU を構成する必要があります。しかし、S32K322を使用するプロジェクトでは、MPUが有効になっていない場合でもHSE機能は正常に動作します。 したがって、MPUが有効になっていない場合のS32KチップのSRAM属性、またはSRAM属性に影響を与え、それによって2つのプロジェクト間の違いが生じるような他の設定があるかどうかを知りたいです。 Re: S32K default attribute of SRAM when disable MPU こんにちは、 @Johnson97 さん。 デフォルトのメモリマップを使用します。 https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Control-Register?lang=en 「ENABLEビットが0に設定されている場合、システムはデフォルトのメモリマップを使用します。」これは、MPUが実装されていない場合と同じメモリ属性を持ちます。表2.11を参照してください。デフォルトのメモリマップは、特権ソフトウェアと非特権ソフトウェアの両方からのアクセスに適用されます。」 https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Processor/Memory-model/Behavior-of-memory-accesses?lang=en#CHDBJAJD 表2.11および表2.12に示されているように、SRAMのメモリタイプはNormal、Non-shareable、WBWAです。 よろしくお願いいたします。 ダニエル
記事全体を表示
バージョン2の問題点:Cコード生成、プレビュー こんにちは! GUI Guiderバージョン2のテストを始め、いくつかの問題(まずは空のテンプレート、Windowsシミュレータ)に気づきました。 トップレイヤーの内容を定義し、画像ボタンを入れ、ボタンを長押ししたときに状態を切り替えるイベントハンドラを作成し始めました。 生成されたコードには、次のようなエラーがあります。 gg_event_layer_top.c: 静的虚無 lv_layer_top()_event_handler(lv_event_t * e) { ... } void gg_event_init_layer_top ( gg_ui_t * ui😞 lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); (括弧は構文解析エラーの原因となります) 括弧を手動で削除すると、以下のエラーが発生します。 .../generated/events/gg_event_layer_top.c:59:38: エラー:「gg_layer_top_t」に「lv_layer_top」という名前のメンバーがいません (gg_layer_top_t の定義にはそのメンバーは含まれていません) これらの関数を正しく生成するために必要な定義が何か見落とされているのでしょうか? Re: Version 2 issues: C code generation, preview こんにちは、 @poldo さん。 この問題を再現するにはどうすればよいか教えていただけますか? BR ハリー Re: Version 2 issues: C code generation, preview こんにちは、 @Harry_Zhang さん、ご返信ありがとうございます。 私がやったことはこうです。 - layer_top にクリック可能なフラグを追加しましたが、これは必要でしょうか?ボタン用のコンテナを作成しました(クリック可能なフラグは追加していません) - コンテナ内で画像ボタンを作成しました(クリック可能なフラグが追加されました) - 「Long Pressed」というイベントをボタンに付けました 生成されたコードには上記の構文エラーが含まれています。 // In gg_event_layer_top.c static void lv_layer_top()_event_handler(lv_event_t * e) { gg_ui_t * ui = lv_event_get_user_data(e); lv_event_code_t code = lv_event_get_code(e); switch(code) { default: break; } } void gg_event_init_layer_top(gg_ui_t * ui) { lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); lv_obj_add_event_cb(ui->layer_top.Keypad_btnEnable, Keypad_btnEnable_event_handler, LV_EVENT_ALL, ui); } 括弧を削除すると、構文エラーはメンバーlv_layer_topが存在しないことに関するものです。 // In custom.h typedef struct { lv_obj_t * Keypad; lv_obj_t * Keypad_btnEnable; } gg_layer_top_t; BR ポルド Re: Version 2 issues: C code generation, preview こんにちは、 @poldo さん。 この問題を再現しようと試みました。 生成されたコードは正しいです。 私が何か見逃した点があれば教えていただけますか? BR ハリー Re: Version 2 issues: C code generation, preview こんにちは、 @Harry_Zhang さん。 問題は、最上層にオブジェクトを作成する場合です。レビューとテストのためにファイルを添付します。
記事全体を表示
FRDM-i.MX93はM33準備完了以降に起動できません。LinuxとWindowsでUUU SDPSの起動がタイムアウトします。 こんにちは、NXPサポート様 FRDM-i.MX93ボードの復旧についてご協力をお願いします。ボードは、SPLブートの初期段階で「M33 prepare ok」の直後に一貫して停止し、BL31または完全なU-Bootに進みません。UUUリカバリもSDPSの起動中にタイムアウトで失敗します。 役員の詳細: ボード: FRDM-i.MX93 シリアルログに表示されるSoC:0xa1009300 シリアルログに表示されたLC: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的なシリアル出力: U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 再構築された2025 SPLでも、同じ停止ポイントが発生します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK 使用したハードウェア構成: P1 = 外部電源、45W USB-Cウォールアダプターでテスト済み P16 = デバッグ用シリアルコンソール P13 = microSDカードスロット P2 = UUU / シリアルダウンローダーモード用のUSB-C接続 PCのUSB電源ではなく、壁のコンセント用アダプターから電源を供給するテストも行いました。行動に変化は見られなかった。 テスト対象のホストシステム: Linux Mint / Ubuntu ホスト Windowsホスト UUUのバージョンをテストしました: ううう 1.5.141 ううう 1.5.243 主な問題は、ボードがSPLに到達し、PMICとDDRを初期化して「M33 prepare ok」と出力した後、何も起こらないことです。「Normal Boot」、「Trying to boot from BOOTROM」、「NOTICE: BL31」、または完全な U-Boot に到達しません。これは、SDカードとeMMCの両方から起動した場合に発生します。 USBシリアルダウンローダーモードでは、ボードはUUUによって検出されます。 sudo ./uuu-lsusb コネクテッド Known USB Devices パスチッププロビデオPID Bcdバージョン 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 しかし、SDPSの起動中にUUUが失敗します。使用されたコマンドは次のとおりです。 sudo ./uuu-V -b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst Linuxでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 HID(W)エラー:LIBUSB_ERROR_TIMEOUT Windowsでは、以下のエラーが発生します。 開始コマンド:SDPS: boot -scanterm -f .\imx-boot-imx93frdm-sd.bin-flash_singleboot -scanlimited 0x800000 14% HID(W)エラー: LIBUSB_ERROR_TIMEOUT (-7) これはLinuxとWindowsの両方でテストされ、同じ結果が得られました。 テスト対象画像: NXP公式FRDM-i.MX93 Rev 4.0デモイメージパッケージをテストしました。 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 ブートイメージのハッシュ値は次のとおりです。 7aba6102e5ec64add632cd6667e77fa3f6886fd72c314e4c01f2964c0fc56a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 私は、同じブートイメージハッシュを使用するimx93frdm用の独自のYoctoイメージもテストしました。 SDカードからの起動選択が機能することを確認しました。SDカードが挿入されていないSDブートモードでは、シリアル出力はありません。SDカードを挿入したSDブートモードでは、SPLは起動して「M33 prepare ok」で停止します。SDカードブートスイッチは正常に動作しているようです。 また、公式のNXP .wicファイルも確認しました。イメージには、想定される32 KiB / 0x8000オフセットにブートイメージが含まれています。使用したコマンド: WIC=nxp.wic BOOT=imx-boot-imx93frdm-sd.bin-flash_singleboot xxd -l 64 -s $((32*1024)) "$WIC" xxd -l 64 -s 0 "$BOOT" cmp -n "$(stat -c%s "$BOOT")" -i $((32*1024)):0 "$WIC" "$BOOT" && echo "NXP WICには32Kにブートイメージが含まれています" || echo "NXP WICには32Kにブートイメージは含まれていません" 結果: NXP WICには32Kのブートイメージが含まれています つまり、SDカードイメージにはブートコンテナが正しく含まれているようです。 2024.04 SPLイメージだけが問題の原因ではないことを確認するため、Flexbuild/U-Bootを使用してより新しいブートイメージを作成しました。構築されたイメージ内のSPLは以下を示します。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) NXP FRDM-IMX93 私は以下の方法で、この新しい flash.bin ファイルを SD カードの 32 KiB オフセットに書き込みました。 sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync 同期 その後、ボードは新しいSPLバナーを印刷し、新しいSDブートイメージが実行されていることを確認した。 U-Boot SPL 2025.04 (2026年4月26日 16:21:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK しかし、それでも同じ箇所で停止し、BL31/完全なU-Bootまでは進みませんでした。 eMMCの状態: 当初、eMMCはLinuxログイン画面まで起動したが、ルートファイルシステムに/bin/shが存在しなかったため、rootログインができなかった。復旧試行中に、eMMCは.wicファイルを使用してSD Linuxから書き換えられた。画像。その後、eMMCブートも「M33 prepare ok」の後に停止します。しかし、同じ停止ポイントは、公式のNXPイメージを使用したSDブートと、再構築された2025 SPLを使用した場合にも発生するため、現在の問題はLinux/rootfsよりも前の段階にあるようです。 私が除外されたと考えること: シリアルポートが間違っています:シリアル接続は正常に動作し、SPL出力が表示されます。 PCの電源不良:45Wの外部ACアダプターを使用してテストしました。 SDカードブートスイッチの設定が間違っています:SDカードが入っていない状態でSDブートモードにすると、何も出力されません。 SDイメージにブートイメージがありません:公式NXP WICの0x8000 / 32 KiBにブートイメージが存在することが確認されています。 Linux/rootfsの問題:BL31/完全なU-Boot/Linuxの前に障害が発生します。 UUUのホストOSの問題:UUU SDPSの起動タイムアウトがLinuxとWindowsの両方で発生します。 古い2024 SPLだけが問題で、再構築された2025.04 SPLも「M33 prepare ok」の後に停止します。 これがFRDM-i.MX93の既知の早期起動問題かどうか、確認にご協力いただけますでしょうか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 弊社がリリースしたBSPバージョンをご利用ですか? i.MXアプリケーション・プロセッサ向け組み込みLinux | NXP Semiconductors どのバージョンのBSPを使用していますか?また、どのバージョンを選択していますか? 労働者の休暇から戻り次第、当社のボードでテストしてみます。来週の水曜日にオフィスに戻り、テストを実施してから、テスト結果をご報告します。 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私はLF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93を使用しています。画像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows オフィスに戻りましたので、ボードでテストを行い、結果をお知らせします。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 解決できましたか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 同じ問題が発生しています... 私のimx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgapビルドでは、BL31が起動を開始したのを見たことがありません。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows こんにちは、私も現在同じ問題を抱えています。解決策は見つかりましたか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題に直面しています。imx93がSDカードから起動できるようにするため、あるいはUUUが正常に動作するようにするために必要なアップデートはありますか? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 他のFRDM-IMX93ボードと比較して、このボード上のメモリチップに違いがあることに気づきました。これが問題解決の手がかりになるかもしれません。 正常に動作する基板にはミクロン製の部品が使われており、故障した基板には見覚えのないメーカーの部品が使われている。     Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 私も同じ問題を抱えています。 これは最優先事項としてマークされるべきです。なぜなら、唯一正常に動作するイメージは、工場出荷時にeMMCに搭載されているものだけだからです!もしそれを再フラッシュしたら、解決策が見つかるまでFRDM-IMX93は起動不能な状態になってしまうでしょう。これはDDRメモリのタイミングに関係しているのではないかと疑っています。 私も「M33 prepare ok」で止まってしまいます。これはDDRの設定/タイミングの問題を示しています。私のボードにも、上記の@SynchronicITさんの投稿と同じ「ノーネーム」DDR IC(メーカーロゴに「J」が付いているもの)が搭載されています。 なぜこれらのボードはeMMCで動作イメージを付けて出荷できるのに、NXPのどの画像も動作しないのでしょうか? 工場出荷時に搭載されているeMMC経由で起動した場合(これは正常に動作します)、u-bootのバージョンは以下のとおりです。 U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) 一方、NXPからの最新ダウンロード(LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip)では、「imx-boot-imx93frdm-sd.bin-flash_singleboot」ファイルはU-Bootのバージョンです。 U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) 以下は、正常に動作する工場出荷時イメージのeMMC、および動作しないSDカードに書き込まれたイメージとUUUにアップロードされたu-bootからの完全な出力です。 * 動作確認済み(工場出荷時設定のeMMC搭載) * U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DRAM 2CS_2GB DRAMが一致しました M33準備OK 通常起動 BOOTROMから起動しようとしています ブートステージ:プライマリブート 画像オフセット 0x8000、ページサイズ 0x200、IVT オフセット 0x0 ROM_APIを使用して0x57800からイメージをロードします 通知:TRDC初期化完了 お知らせ:BL31:v2.12.0(リリース):lf-6.18.2-1.0.0 お知らせ:BL31:製造日時:2026年2月10日 07:53:18 U-Boot 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) リセットステータス: POR CPU:NXP i.MX93(52) Rev1.2 A55、1700 MHz CPU:インダストリアル温度グレード(-40°Cから105°C)、24°Cで対応 モデル:NXP FRDM-IMX93 DRAM:2 GiB ボード:V1.0(ADC2:684、ADC3:271) TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x52] 無駄。CC1でのPower3.0 PDO 0:タイプ0、5000 mV、3000 mA [E] PDO 1:タイプ0、9000 mV、3000 mA [] PDO 2:タイプ0、12000 mV、3000 mA [] PDO 3:タイプ0、15000 mV、3000 mA [] PDO 4:タイプ0、20000 mV、3250 mA [] PDO 5:タイプ3、未定義 PDO 4を要請:20000 mV、750 mA ソース受理リクエスト PDソース準備完了! tcpc_pd_receive_message:ALERTレジスタのポーリング、TCPC_ALERT_RX_STATUSビット失敗、ret = -62 TCPC:ベンダーID [0x1fc9]、製品ID [0x5110]、Addr [I2C2 0x50] コア:229デバイス、32 uクラス、devicetree:別々 MMC: FSL_SDHC: 0, FSL_SDHC: 1 MMCからの読み込み環境...MMC(0)から読み上げています... *** 警告 - CRCが悪い、デフォルト環境を使用しています ビデオリンクの設定に失敗しました 掲載: シリアル 出力: シリアル エラー: シリアル ビルド情報: - ELEファームウェアバージョン2.0.5-7a34cee パーティション#0に切り替える、OK MMC0(パート0)は電流装置です UID: 4a7ff07fa81b46d8b2b59146dfa5af84 フラッシュターゲットはMMC:0です ネット:eth0: ethernet@42890000、eth1: ethernet@428a0000 [プライム] 速攻:通常 通常起動 自動起動を停止するには、任意のキーを押してください: 0 u-boot=> *動作しません* U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: オーバードライブ電圧モード DDR: 3733MTS DDR: 3733MTS M33準備OK - 下がる -
記事全体を表示
IWTL about in-vehicle network communication I'd love to learn about in-vehicle communication (CAN, LIN, FlexRay, etc) and ECUs and things. Are there any resources that can teach me this? I've looked into MIT OCW and there doesn't seem to be anything that can help there. Switch Re: IWTL about in-vehicle network communication Hello, You can start by looking at this thread: https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/m-p/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 But personally I will use AI for learning sources as it can tailor the learning according your needs. Best regards, Peter
記事全体を表示
关于车载网络通信的IWTL 我很想学习车载通信(CAN、LIN、FlexRay 等)和 ECU 等相关知识。 有什么资源可以教我这个吗?我查阅了麻省理工学院开放课程网站(MIT OCW),但似乎那里没有什么能帮到我的。 开关 Re: IWTL about in-vehicle network communication 你好, 你可以先看看这个帖子: https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/mp/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 但我个人会使用人工智能作为学习资源,因为它可以根据你的需求定制学习内容。 顺祝商祺! Peter
記事全体を表示
S32K comparator tolerance/offset we are having some test on the comparator of S32K116: we apply an input voltage(238mV) to INN (or INP), use bandgap as reference, then we increase VOSEL from 0 to 255 and monitor when the comparator output changed. Somehow, we see different tolerance/offset on MCU2 when the connection of input voltage and bandgap is swapped.  (Details shown in Test1 and Test2) 1) Is this some kind of known feature like VAIO or something else? 2) For this tolerance/offset, is it stable and can we eliminate this by calibration? (like record the trigger VOSEL at the target voltage) Test1: Input Voltage on V-, Bandgap on V+, Low Speed Mode Test2: Input Voltage on V+, Bandgap on V-, Low Speed Mode Re: S32K comparator tolerance/offset 1) Input Pin CMP0_IN is always set to channel 0. (PIN26, PTA0) Yes, input voltage still being input through the same CMP0_IN Pin26, PTA0. 2) Bandgap The feature I want to figure out is not the difference between two MCU.  It is this different tolerance/offset from the same MCU when INN and INP is swapped. I think the bandgap should not change during this swapped.  (The data of MCU1 here is just use as reference) 3) VDD/VDDA: The two MCU are using same +3.3V network (LDO within 1.25% tolerance).  I am fully understanding there will be difference between MCUs bandgap, but, again, it is the difference during swapped I am checking. 4) test method The test data above is not increasing input voltage, it is using fixed input voltage, and increasing VOSEL. (For decreasing VOSEL, i have not test yet, will check this later.) As for increasing/decreasing input voltage with fixed VOSEL, there is similar -9mV.   5) Hysteresis I do have test data for hysteresis in low-speed mode: Test data here is fixing input voltage and increase VOSEL:   6) MCU photos you can refer to attached photo "MCU1.PNG" and "MCU2.PNG" Solder mask is  FS32K11-6LFMFM-ON96V-S12YM16 Re: S32K comparator tolerance/offset Hi Sid_Zhou, Which CMP0_IN pin are you connecting the input voltage to? When swapping INN and INP, is the input voltage still being input through the same CMP0_IN pin? Also, the BandGap voltage range is between 0.97-1.03V. Have you considered temporarily ruling out issues caused by different BandGap voltages on the two MCUs? For example, could you use a different CMP0_IN pin to input a more accurate external voltage reference? Have you checked whether the VDD/VDDA voltages of the two S32K1s are the same? Were OFFSET=1 and HYSTCTR=0 confirmed during debugging? I noticed you increased the input voltage and recorded VOSEL. Have you tested decreasing the input voltage and recording VOSEL? Also, check if the Analog comparator hysteresis is affected, although I see you configured HYSTCTR=0. Take two S32K116 photos and tell me the MCU mask. Best Regards, Robin Re: S32K comparator tolerance/offset Thank you for your detailed explanation. I now understand that you are concerned about the VAIO (Analog Input Offset Voltage) parameter in the S32K1 Datasheet. Internally, I saw the AE team's explanation: The AIO offset is the offset of the comparator itself. the offset between INP and INN. The INL error includes the DNL error since it is an integral over the DNL. The error is then |V_AIO| + |INL| Based on my understanding, directly using two analog voltages from an external signal source to input INP and INN respectively to test VAIO should be more intuitive than using bandgap voltage divider.  Regarding your question:  for the same MCU, VAIO is not a random value that changes arbitrarily from moment to moment , but it can drift with operating conditions, especially temperature. The VAIO value in the datasheet should be understood as a guaranteed/worst-case limit over the full temperature range. When designing the threshold, do not treat VAIO as negligible or as a fixed calibrated-out value . Keep margin based on the full-temperature worst-case |VAIO| , plus the DAC/INL error. I also checked your previous discussion on this: S32K116 comparator tolerance. It seems that CMP's accuracy doesn't meet your needs. Have you considered the feature described in section "44.5.5 Automatic compare function" of S32K1XXRM Rev14.2? "Table 41. 12-bit ADC characteristics (2.7 V to 3 V)" in S32K1 DataSheet Rev15 shows a maximum TUE of ±8 LSB. This appears to be more accurate than CMP. Re: S32K comparator tolerance/offset Thanks for your detailed explanation. I noted that the ADC may have better accuracy in our application. But somehow, we have requirements for using CMP as safety monitor from high level architecture and i am not sure if this can be changed to ADC.
記事全体を表示
寄存器:S32K eMIOS 编码器在静态转子位置的顺时针/逆时针计数器行为 大家好, 我正在使用 S32K322 微控制器,并实现了编码器接口,以从位置传感器获取转子角度。 我已根据应用笔记配置了所需的 MCAL 模块,包括 TRGMUX、LCU 和 eMIOS。编码器功能正常;但是,我发现 CW 和 CCW 计数器出现了意外情况。 我的问题如下: 在转子静止时(即转子不移动时),顺时针和逆时针计数器是否应表现为自由运转计数器? 就我而言,顺时针和逆时针计数器都在持续递增,而绝对位置值始终为零。这是预期行为吗? 如果这是预期行为,那么即使转子静止不动,CW 和 CCW 计数器为何还会递增? 如果这不是预期行为,请您提出以下建议: MCAL 设置(TRGMUX、LCU 或 eMIOS)是否需要进行任何配置更改? 是否需要实施任何额外的软件机制或过滤措施来防止转子静止时 CW/CCW 计数器递增? 附上视频供您参考。 AWS-LIBRARIES-S32K3 此致, 蒂鲁 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好, LCn 的 CW 和 CCW 输出本身并不是位置计数器。根据增量编码器的实现方式,所用的 LCn 会在每个 A/B 信号边沿生成 CW 或 CCW 输出脉冲流,具体取决于检测到的正交序列。然后,eMIOS 对这些脉冲进行计数以累积位置信息。这与 S32K3 正交方法相符,其中 PHA/PHB 由 LCU 处理,eMIOS 充当位置累积的计数器。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 如果转子确实静止不动,并且编码器 A/B 输入稳定,则不应持续产生新的 CW/CCW 脉冲。因此,当绝对位置保持为零时,顺时针和逆时针计数器都递增,这不是预期的“理想”行为。 有几件事值得检查: 确认 eMIOS 通道确实在计数 CW/CCW 输入脉冲,而不是内部时钟源。 在调试器中检查所用 eMIOS 通道的 UIN 状态。如果 UIN 在计数器递增时保持不变,则该通道可能未使用预期的外部输入。 如果转子静止时 UIN 发生切换,请检查编码器 A/B 信号、TRGMUX 路由、LCU 输出和输入滤波。 同时在示波器上监测编码器 A/B 信号和 LCU CW/CCW 输出,以排除噪声或故障。 这应该有助于确定问题是编码器信号活动/噪声引起的,还是 eMIOS 配置问题引起的。 BR,彼得 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好, 我在S32K322参考手册中找不到与UIN状态对应的任何寄存器。请问您能否帮忙查找并指导我如何验证这一点以便进行进一步分析? 我调试了用于更新 顺时针 和 逆时针 计数器的 寄存器 。根据参考手册, eMIOS 通道 5 的 UC CNT 对应于顺时针计数器, eMIOS 通道 6 的 UC CNT 对应于逆时针计数器。 然而,我观察到即使转子处于静止状态,两个UC CNT寄存器仍然持续从0 递增到 65535 (自由运转)。请问这种现象是否正常,或者可能是什么原因造成的? 我已附上相关寄存器值的截图供您参考。 此外,我还验证了 MCAL 配置,其配置与共享的**应用笔记**中所述一致,是正确的。 尽早提供支持 此致, 蒂鲁 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 请回复此查询 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好, 我写的是 UIN,但它应该是通道 S 寄存器的 UCIN 位。 根据寄存器视图,我看到控制寄存器设置为 0x20E06D1,这表明使用了正确的模式 0x51,即对外部信号进行计数。 据我了解,LCn 在每个 A/B 信号边沿在 CW 或 CCW 输出端产生脉冲流,因此对于稳定的电机/编码器信号,不应产生脉冲,因此不应计数。 您还可以检查相应的 SIUL IMCR 寄存器,以确保已选择 TRGMUX 输出。 BR,彼得  
記事全体を表示
S32 Design Studio License Renewal Fulfillment ID: 128143961 Expiration Date: Jun 22, 2026 Product: S32 Design Studio for ARM v2018 R1 Activation Code: 3E1F-50E5-6F93-F06F Re: S32 Design Studio License Renewal Hello, It is now extended. Best regards, Peter
記事全体を表示
frdm-i.mx93 无法在 M33 之后启动准备就绪;Linux 和 Windows 上的 UUU SDPS 启动超时 您好,恩智浦技术支持、 我正在请求帮助恢复 FRDM-i.MX93 主板。在 “M33 准备就绪” 之后,板在早期的 SPL 启动期间会立即停止,并且不会继续运行 BL31 或完全 U-Boot。在 SDPS 启动期间,UUU 恢复也会因超时而失败。 董事会详情: 板:FRDM-i.MX93 SoC shown in serial log: 0xa1009300 LC shown in serial log: 0x2040010 PMIC: PCA9451A DDR: 3733MTS 典型的串行输出: U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok 重建的 2025 SPL 也出现了同样的停止点: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000) PMIC:PCA9451A PMIC:过载电压模式 DDR:3733MTS DDR:3733 MTS DDR:3733MTS M33 准备好了 使用的硬件设置: P1 = 外部电源,使用 45 W USB-C 墙式适配器进行测试 P16 = 调试串行控制台 P13 = microSD 卡插槽 P2 = 用于 UUU / 串行下载器模式的 USB-C 连接 我还测试了用墙壁适配器供电,而不是用电脑 USB 供电。行为没有改变。 测试的主机系统: Linux Mint / Ubuntu 主机 Windows 主机 已测试的 UUU 版本: uuu 1.5.141 uuu 1.5.243 主要问题是电路板达到 SPL,初始化 PMIC 和 DDR,然后打印 “M33 准备就绪”,然后什么也没发生。它永远不会达到 “正常启动”、“正在尝试从 BOOTROM 启动”、“注意:BL31” 或完整 U-Boot。从 SD 和 eMMC 启动时会发生这种情况。 在 USB 串行下载器模式下,UUU 会检测到主板: sudo ./uuu-lsusb 连接的已知 USB 设备 路径芯片 Pro Vid Pid bcdVersion 5:2 MX93 SDPS: 0x1FC9 0x014E 0x0001 但是,在 SDPS 启动期间,UUU 会失败。使用的命令是 sudo ./uuu-V-b emmc_all imx-boot-imx93frdm-sd.bin-flash_singlebootimx-image-full-imx93frdm.rootfs.wic.zst 在 Linux 系统上,故障是 启动 cmd: sdps: boot-scanterm-f imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 Fail HID(W):LIBUSB_ERROR_TIMEOUT 在 Windows 系统中,故障是 启动 cmd: sdps: 启动-scanterm-f。\ imx-boot-imx93frdm-sd.bin-flash_singleboot-scanlimited 0x800000 14% 失败 HID (W):LIBUSB_ERROR_TIMEOUT (-7) 在 Linux 和 Windows 上进行了测试,结果相同。 测试过的图像: 我测试了恩智浦官方 frdm-i.mx93 Rev 4.0 演示映像包: LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93 启动映像哈希值为: 7aba6102e5ec64add64add632cd6667e77fa3f6f6f6f6f6f6fd72c314e4c01f2964c0fc056a5f imx-boot-imx93frdm-sd.bin-flash_singleboot 我还测试了自己的 Yocto 镜像 imx93frdm,它使用相同的启动映像哈希值。 我验证了 SD 启动选择是否有效。在未插入 SD 卡的 SD 启动模式下,没有串行输出。在插入 SD 卡的 SD 启动模式下,SPL 在 “M33 准备就绪” 时开始和停止。因此,SD 启动开关似乎正在工作。 我还验证了恩智浦官方的 .wic映像包含预期偏移量为 32 KiB/0x8000 的启动映像。使用的命令 wic=nxp.wic 启动=imx -启动-imx93frdm-sd.bin-flash_singleBoot xxd -l 64 -s $((32*1024))"$WIC" xxd -l 64 -s 0"$BOOT" cmp-n " $ (stat-c%s " $BOOT ") "-i $ ((32*1024)): 0 " $WIC " " $BOOT " & & echo " " NXP WIC 包含 32K 的启动映像" 恩智浦 WIC 不包含 32K 的启动映像 " 结果: 恩智浦 WIC 包含 32K 的启动映像 因此,SD 映像似乎正确包含了启动容器。 为了排除只有 2024.04 SPL 映像是问题所在,我使用 Flexbuild/U-Boot 构建了一个更新的启动映像。内置映像中的 SPL 显示: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000)恩智浦 FRDM-IMX93 我将这个新的 flash.bin 文件写入 SD 卡,偏移量为 32 KiB: sudo dd if=flash-imx93frdm-2025.bin of=/dev/sdX bs=1K seek=32 conv=fsync sync 然后,主板打印了新的 SPL 标语,确认它正在执行新的 SD 启动映像: U-Boot SPL 2025.04(2026 年 4 月 26 日-16:21:54 +0000) PMIC:PCA9451A PMIC:过载电压模式 DDR:3733MTS DDR:3733 MTS DDR:3733MTS M33 准备好了 但是,它仍然在同一时间停止了,没有继续使用BL31/Full U-Boot。 eMMC 状态: 最初,eMMC 启动到足以登录 Linux 的程度,但由于根文件系统中缺少 /bin/sh,根登录被中断。在尝试恢复过程中,eMMC 使用 .wic 文件从 SD Linux 重写。图像之后,在 “M33 准备就绪” 之后,eMMC 启动也会停止。但是,使用恩智浦官方镜像启动SD时以及重建的2025 SPL也会出现同样的停止点,因此当前的问题似乎早于Linux/rootFS。 我所相信的已经被排除: 串行端口错误:串行端口正常工作并显示 SPL 输出。 电脑电源不良:使用外置 45 W 墙式适配器测试。 错误的 SD 启动开关:没有 SD 卡的 SD 启动模式没有输出。 SD 映像中缺少启动映像:经过验证的启动映像存在于恩智浦官方 WIC 中的 0x8000/32 KiB。 Linux/rootFS 问题:故障发生在 BL31/Full U-Boot/Linux 之前。 UUU 的主机操作系统问题:UUU SDPS 启动超时出现在 Linux 和 Windows 上。 只有旧的 2024 SPL 是坏的:重建的 2025.04 SPL 也在 "M33 准备就绪 "后停止。 你能帮忙确定这是否是已知的 frdm-i.mx93 提前启动问题吗? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你在使用我们发布的 BSP 版本吗? 适用于i.MX应用处理器的嵌入式Linux|恩智浦半导体 您正在使用并选择哪个版本的 BSP? 劳动节回来后,我会尝试在我们的电路板上进行测试,我将在下周三回到办公室然后进行测试,然后给你回复我的测试结果。 祝您有美好的一天 顺祝商祺! Rita Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我使用的是 LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93。图像 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我回到办公室将在我们的板上进行测试,然后告诉你结果。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 你想出来了吗? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows @Rita_Wang 我也遇到了同样的问题…… 我从未见过 BL31 使用我的 imx-image-full-imx93frdm.rootfs-20260705225501.wic.zst scarthgap 版本启动。 Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 您好,我目前也遇到了同样的问题。请问您找到解决方法了吗? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到同样的问题。是否有任何更新需要进行哪些操作才能使 imx93 从 SD 卡启动,或者使 UUU 正常工作? Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我们注意到该主板上的内存芯片与其他frdm-imx93主板有所不同。或许这有助于找到问题所在。 正常工作的板是微米级的,而故障板的品牌我不认识。     Re: FRDM-i.MX93 cannot boot past M33 prepare ok; UUU SDPS boot times out on Linux and Windows 我也遇到了同样的问题。 这应该标记为高优先级,因为唯一可用的映像是出厂时在 eMMC 上提供的映像!如果重新刷写固件,我的 FRDM-IMX93 就彻底报废了,直到找到解决方案为止,我怀疑这与 DDR 内存时序有关。 我的程序也卡在了“M33 prepare ok”这里,这表明DDR配置/时序存在问题,而且我的主板也和上面@SynchronicIT帖子中的一样,使用了相同的“无名”DDR IC(制造商标志带有“J”)。 为什么这些电路板可以出厂时就带有 eMMC 上的可用镜像,而 NXP 提供的所有可用镜像都无法使用? 当我通过(出厂预装的)eMMC启动时(启动正常),u-boot 版本为: U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) 而从 NXP 下载的最新版本 (LF_v6.6.36-2.1.0_images_FRDM_4.0_IMX93.zip)“imx-boot-imx93frdm-sd.bin-flash_singleboot”文件是 u-boot 版本: U-Boot SPL 2024.04+gde16f4f1722+p0(2024年9月2日 10:44:35 +0000) 下面显示的是正常工作的工厂镜像 eMMC 的完整输出,以及不正常工作的 SD 卡刷入镜像和 UUU 上传的 u-boot 的完整输出。 * 工作正常(出厂预装eMMC)* U-Boot SPL 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) PMIC:PCA9451A PMIC:过驱动电压模式 DDR:3733MTS 找到匹配的 DRAM 2CS_2GB DRAM M33 准备就绪 正常启动 尝试从 BOOTROM 启动 启动阶段:主启动 图像偏移量 0x8000,页面大小 0x200,ivt 偏移量 0x0 通过 ROM_API 从 0x57800 加载镜像 注意:TRDC 初始化完成 通知:BL31:v2.12.0(版本):lf-6.18.2-1.0.0 通知:BL31:建造时间:2026年2月10日 07:53:18 U-Boot 2025.04-g99518e6b6f20(2026年2月2日 05:52:54 +0000) 重置状态:POR CPU:NXP i.MX93(52) Rev1.2 A55,频率 1700 MHz CPU:工业级温度范围(-40℃至105℃),工作温度24℃ 型号:NXP FRDM-IMX93 动态随机存取存储器(DRAM):2 GiB 板:V1.0(ADC2:684,ADC3:271) TCPC:供应商 ID [0x1fc9],产品 ID [0x5110],地址 [I2C2 0x52] SNK.Power3.0 on CC1 PDO 0:0 型,5000 mV,3000 mA [E] PDO 1:0 型,9000 mV,3000 mA [] PDO 2:0 型,12000 mV,3000 mA [] PDO 3:0 型,15000 mV,3000 mA [] PDO 4:0 型,20000 mV,3250 mA [] PDO 5:类型 3,未定义 请求 PDO 4:20000 mV,750 mA 源接受请求 PD源已准备就绪! tcpc_pd_receive_message:轮询 ALERT 寄存器,TCPC_ALERT_RX_STATUS 位失败,返回值为 -62 TCPC:供应商 ID [0x1fc9],产品 ID [0x5110],地址 [I2C2 0x50] 核心:229 个设备,32 个微类,设备树:独立 MMC:FSL_SDHC:0,FSL_SDHC:1 从 MMC 加载环境... 从 MMC(0) 读取... *** 警告 - CRC 校验错误,使用默认环境 视频链接设置失败 输入:串行 输出:串口 错误:串行 构建信息: - ELE固件版本2.0.5-7a34cee 切换到分区 #0,确定 mmc0(第 0 部分)是当前设备 UID:4a7ff07fa81b46d8b2b59146dfa5af84 闪存目标是 MMC:0 网络:eth0:以太网@42890000,eth1:以太网@428a0000 [PRIME] Fastboot:正常 正常启动 按任意键停止自动启动:0 u-boot=> * 无法正常工作 * U-Boot SPL 2024.04+gde16f4f1722+p0(Sep 02 2024 - 10:44:35 +0000) SOC: 0xa1009300 LC: 0x2040010 PMIC: PCA9451A PMIC: Over Drive Voltage Mode DDR: 3733MTS DDR: 3733MTS M33 ready ok - 悬挂 -
記事全体を表示
Request for Dual-Core Ethernet Example on i.MX RT1176 (One Ethernet per Core) Hello NXP Team, I am currently working on the i.MX RT1176 evaluation board using MCUXpresso IDE v11.9.1 (Build 2170, 2024-04-19). I would like to know whether NXP provides any multicore example project that demonstrates the use of both Cortex-M7 and Cortex-M4 cores with independent Ethernet interfaces. My requirement is as follows: Ethernet Port 1 should be initialized and managed by the Cortex-M7 core. Ethernet Port 2 should be initialized and managed by the Cortex-M4 core. Both Ethernet interfaces should operate simultaneously and independently on their respective cores. If inter-core communication (such as RPMsg or MU) is required, I would appreciate any example or documentation explaining the recommended approach. I have searched the MCUXpresso SDK examples but have not found a project matching this use case. Could you please let me know: Is there any official NXP multicore example demonstrating one Ethernet controller on the M7 core and the other Ethernet controller on the M4 core? If such an example is available, could you please share the project or provide the corresponding SDK example name or repository link? If no such example exists, could you suggest the recommended architecture for implementing this configuration on the i.MX RT1176? Any reference projects, application notes, or documentation would be greatly appreciated. Thank you for your support. Best regards, Aravind Togaralli Re: Request for Dual-Core Ethernet Example on i.MX RT1176 (One Ethernet per Core) Dear @Aravind_Togaralli , Unfortunately, there is currently no official example that demonstrates both the Cortex-M7 and Cortex-M4 running independent Ethernet interfaces simultaneously. However, the recommended architecture is to keep the two Ethernet subsystems completely independent: Assign one Ethernet controller (e.g., ENET/ENET_QOS) to CM7 and the other to CM4. Each core should maintain its own MAC driver, PHY control, lwIP stack, netif instance, DMA descriptors, packet buffers, interrupts, and network configuration. Use RPMsg-Lite, MU, or shared memory only for inter-core control and status communication when needed. Consider using RDC/XRDC2 to isolate Ethernet peripherals and memory resources between the two cores during development. For Ethernet DMA buffers, ensure the selected memory region is accessible by both the corresponding CPU and Ethernet DMA master. A suggested implementation approach is: Start from a working RT1170 multicore example. Bring up Ethernet on CM7 using a standard lwIP example. Bring up Ethernet on CM4 using the second Ethernet controller. Verify both Ethernet interfaces operate simultaneously without IPC. Add RDC/XRDC2 isolation if required. Introduce RPMsg-Lite or MU/shared-memory communication only if the application requires inter-core interaction. You may also find application note AN13264 helpful, as it provides guidance and recommendations for RT1170 multicore application development. Best Regards, Shelly Zhang
記事全体を表示
NFC Antenna Tool - Skin effect Hello! I have a question regarding the NFC Antenna Tool. Does the tool account for the skin effect when calculating the antenna parameters? Re: NFC Antenna Tool - Skin effect Hello @lucas_uy_13  Yes, it does.
記事全体を表示
S32K default attribute of SRAM when disable MPU Hi nxp technical team, I would like to know the default attributes of SRAM when the MPU of the S32K chip is not enabled? Specifically, what are the attributes of "share" and "cache" in the SRAM default settings? I have consulted the ARMv7-m architecture reference manual, which indicates that the device type of SRAM is "device", seemingly meaning that the entire SRAM is sharable and non-cacheable. See the following picture. Returning to my project, the project using MWCT2016s (i.e. S32K312) has abnormal HSE function when the MPU is not enabled, and it is necessary to configure MPU to set the SRAM area as sharable and non-cacheable. However, in the project using S32K322, the HSE function is normal when the MPU is not enabled.  Therefore, I would like to know the SRAM attributes of the S32K chip when the MPU is not enabled, or if there are any other settings that affect the SRAM attributes and thereby cause the differences between the two projects? Re: S32K default attribute of SRAM when disable MPU Hi @Johnson97, It uses the default memory map: https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Control-Register?lang=en "When the ENABLE bit is set to 0, the system uses the default memory map. This has the same memory attributes as if the MPU is not implemented, see Table 2.11. The default memory map applies to accesses from both privileged and unprivileged software." https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Processor/Memory-model/Behavior-of-memory-accesses?lang=en#CHDBJAJD As you can see in Table 2.11 and Table 2.12, the memory type for SRAM is Normal, Non-shareable, WBWA. Regards, Daniel
記事全体を表示
車載ネットワーク通信についてのIWTL 車内通信(CAN、LIN、FlexRayなど)やECUなどについて学びたいです。 これを教えてくれるリソースはありますか?MITのOCWを調べましたが、役立つものは特に見当たりません。 スイッチ Re: IWTL about in-vehicle network communication こんにちは、 まずはこのThreadをご覧ください: https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/mp/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 でも個人的には、学習にはAIを使うつもりです。AIはあなたのニーズに合わせて学習を調整できるからです。 よろしくお願いいたします。 ピーター
記事全体を表示
GC7000 GPU ハング galcore タイムアウト 問題の概要 NavAppの実行中に、画面表示が完全にフリーズします。カーネルログの調査によると 、これは アプリケーションのクラッシュではなく 、 Vivante GC7000 GPU(Galcore)の ハム です。 観察結果: カーネルは30秒後に GPUタイムアウト を報告します(gpuTimeout = 30000)。 Galcoreは GPU状態ダンプを生成し、以下を呼び出します: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() 運転手は次のように報告します。 [ガルコア]:運転手を停止させて現場を維持しろ。 GPUの状態ダンプは複数のGPUブロックが詰まっていることを示しています: FEはアイドル状態ではない SHはアイドル状態ではありません TXはアイドル状態ではありません MCはアイドル状態ではありません DMAが停止しているようです ドライバ構成 現在のGalcore構成は以下のとおりです。 リカバリ = 0、GPUタイムアウト = 30000   GPUリカバリーが無効になっている(リカバリー=0)ため、ハングを検出するとドライバーは停止し、最後にレンダリングされたフレームだけが表示されるため、画面がフリーズする現象が確認されます。 GPUメモリの状態: GPUのメモリ統計はメモリの使い尽きを示し ません 。 総GPUメモリ:256MB 使用量:約155MB 無料:約113MB したがって、この問題はGPUのメモリ不足によるものではないようです。 GPUクライアント: GPUデータベースによると、ハング時点で NavAppだけがアクティブなGPUクライアント です。 GPUの状態ダンプは、以下の以下の人から提出された複数のコマンドバッファを参照しています: NavApp これは、NavAppが提出したレンダリングコマンドを実行している間にGPUのハングが発生したことを示しています。   応募スケジュール: アプリケーションログから、GPUがハングする直前に以下のシーケンスが観察されています。 連続的な地図のズームイン/ズームアウト操作 オフラインの地図/タイルアクセス 経路計算 ルート情報表示 GPUのタイムアウトと状態ダンプ GPUのハングは集中的なレンダリング作業の直後に発生します。 結論: 収集された証拠に基づくと: カー ネルパニック 、 OOM、 アプリケーション クラッシュ はありません。 この故障は、Galcoreのウォッチドッグによって検出された GPUコマンドプロセッシングのハング です。 ハングが発生した際はNavAppがレンダリングクライアントですが、GPUドライバー内で障害が観察されます。 GPUのメモリ使用量は制限内であり、リソースの枯渇を示しているわけではありません。 TVSチームへの調査依頼: Vivante GC7000 / Galcore GPUドライバーがレンダリング中にフリーズします。 この問題が既知のGPUドライバーかファームウェアの制限かは不明です。 GPUリカバリー(recovery=1)がこのプラットフォームでサポートされ推奨されているかどうか。 GPU状態ダンプの分析により、どのGPUコマンドまたはハードウェアブロックがタイムアウトを引き起こしたかを特定します。 BSPやGPUドライバー、ファームウェアのリリースなどが更新されていても、同様のGPUタイムアウト問題に対応しています。 Re: GC7000 GPU hang galcore timeout こんにちは@Zhiming_Liu SOC - iMX8qxpComek BSPバージョン - Scarthgap L6.6.5 ネタバレ (ハイライトして読む) ネタバレ (ハイライトして読む)     Re: GC7000 GPU hang galcore timeout こんにちは、 @Ram2さん SOCの部品番号、BSPのバージョン、および再現手順をお知らせください。 よろしくお願いします、 志明 Re: GC7000 GPU hang galcore timeout こんにちは、 @Ram2さん EVK上でこの問題を再現するための手順を教えてください。 よろしくお願いします、 志明 Re: GC7000 GPU hang galcore timeout こんにちは@Zhiming_Liu 再現手順: 画面がフリーズする問題は、ランダムかつ断続的に発生するため、決まった再現手順はありません。しかし、利用可能なシステムメモリが非常に少なくなった場合(通常は60MiB未満)に発生する可能性が高いことが観察されています。 問題の再現性を高めるため、以下の活動を継続的に行いました。 長距離ルートを2~3本作成した。 ナビゲーションを開始し、約1分以内に終了しました。 ホーム、オフィス、ホテルのクイックアクションボタンを使って繰り返しルートを作成しました。 パン操作や頻繁なズームイン/ズームアウト操作を行い、地図上のさまざまな領域を探索した。 これらの作業中に、利用可能なメモリ容量が低レベルまで低下した際に、画面がフリーズする現象が確認された。例えば: メモリ容量:合計1709.5 MiB、空き容量55.8 MiB、使用容量1298.1 MiB、バッファ/キャッシュ容量567.2 MiB MiB スワップ: 合計 0.0、空き 0.0、使用済み 0.0、利用可能メモリ 411.4 これは、空きメモリがほぼ枯渇した状態で継続的に使用した場合に、この問題が発生する可能性が高くなることを示唆している。 Re: GC7000 GPU hang galcore timeout こんにちは@Ram2  NXPがリリースしたLinux BSPにはナビゲーションアプリは含まれていません。テスト用アプリとテスト手順書をご提供ください。 よろしくお願いします、 志明
記事全体を表示
Version 2 issues: C code generation, preview Hi! I started testing GUI Guider version 2, and I found a couple of issues (starting with an empty template, Windows simulator). I started defining the content of the top layer putting an image button, creating an event handler to switch state when the button is long pressed. The generated the code has some errors, like: gg_event_layer_top.c:   static void lv_layer_top()_event_handler(lv_event_t * e) {     ...   } void gg_event_init_layer_top(gg_ui_t * ui😞   lv_obj_add_event_cb(ui->layer_top.lv_layer_top(),  lv_layer_top()_event_handler, LV_EVENT_ALL, ui); (parenthesis create a parsing error) Manually removing the parenthesis, the error below is generated: .../generated/events/gg_event_layer_top.c:59:38: error: 'gg_layer_top_t' has no member named 'lv_layer_top' (gg_layer_top_t definition doesn't include that member) Am I missing some definition to make a correct generation of those functions? Re: Version 2 issues: C code generation, preview Hi @poldo  May i ask how can i reproduce this issue? BR Harry Re: Version 2 issues: C code generation, preview Hi @Harry_Zhang , thank you for your reply. This is what I did: - On layer_top (clickable flag added, is this necessary?) I created a container for my buttons (no clickable flag added)  - Inside the container I created an image button (clickable flag added)  - I attached the event "Long Pressed" to the button Generated code contains the syntax errors above. // In gg_event_layer_top.c static void lv_layer_top()_event_handler(lv_event_t * e) { gg_ui_t * ui = lv_event_get_user_data(e); lv_event_code_t code = lv_event_get_code(e); switch(code) { default: break; } } void gg_event_init_layer_top(gg_ui_t * ui) { lv_obj_add_event_cb(ui->layer_top.lv_layer_top(), lv_layer_top()_event_handler, LV_EVENT_ALL, ui); lv_obj_add_event_cb(ui->layer_top.Keypad_btnEnable, Keypad_btnEnable_event_handler, LV_EVENT_ALL, ui); } Removing the parenthesis the syntax error is about the member lv_layer_top not existing: // In custom.h typedef struct { lv_obj_t * Keypad; lv_obj_t * Keypad_btnEnable; } gg_layer_top_t; BR Poldo Re: Version 2 issues: C code generation, preview Hi @poldo  I tried to reproduce this issue. The generated code is correct. May I ask what I missed? BR Harry Re: Version 2 issues: C code generation, preview Hi @Harry_Zhang . The issue is when you create objects on the top layr. I'm attaching my file for your review and test.
記事全体を表示