Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
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 设置”中进行选择。
記事全体を表示
SJA1110 上未移除主机到交换机的尾部 我正在通过 SJA1110 上的主机处理器 (Cortex-M7) 发送以太网帧。为了将它们路由到交换机上的特定端口,我使用了 UM11107 中 5.8.2 节描述的主机到交换机标头/尾部。 车架已运抵正确的港口,但拖车尚未拆解或仅部分拆解。为了便于参考,这里展示了同一帧在发送前存储在 txBuffer 中,以及在另一个设备接收后存储在 rxBuffer 中的数据: 01 80 c2 00 00 10 68 58 c5 00 11 02 8b 8c 88 39 88 b7 5a 46 00 01 02 06 68 58 c5 00 11 02 04 01 00 06 01 02 12 01 01 14 0e 01 02 11 00 c5 58 68 08 d8 26 c0 cb fd 18 00 00 00 00 ---- 00 04 00 00 00 ====== 01 80 C2 00 00 10 68 58 C5 00 11 02 88 B7 5A 46 00 01 02 06 68 58 C5 00 11 02 04 01 00 06 01 02 12 01 01 14 0E 01 02 11 00 C5 58 68 08 D8 26 C0 CB FD 18 00 00 00 00 ---- 00 04 00 00 00 如您所见,头部已被完全移除,但尾部(4 条虚线之后的所有内容)并未被移除(或设置为全 0,因为以太网帧至少需要 64 个字节才能有效)。 Re: host-to-switch trailer not removed on SJA1110 你好@flxwly , 从提供的数据来看,交换机似乎能够识别主机到交换机的报头,因为从传出的帧中移除了 4 字节的报头。但是,尾部字节仍然会出现在接收到的帧的末尾。 需要检查的一个重要点是主机到交换机报头中的 TRAILER_POS 字段。在您的示例中,报头字节为8b 8c 88 39。 根据主机到交换机的报头格式进行解释,得到 HEADER_TYPE = 0x8B8C,HOST_SWITCH = 1,TRAILER = 1,TRAILER_POS = 57。但是,在您转储中显示的传输帧中,5 字节的尾部似乎从 MAC DA 字段的第 59 个字节偏移量开始(从零开始)。根据相对于 SFD 的确切位置计数约定,预期值可能相差 1,但编码值 57 似乎与实际的尾部位置不匹配。 因此,请先检查 TRAILER_POS 字段的计算方式,并尝试将其设置为与尾部实际第一个字节对应的位置。 还有第二点:提供的测试帧非常短。如果去掉 5 字节的尾部,得到的以太网帧将比没有 FCS 的最小以太网帧大小短,因此需要在出口处再次添加填充。为了避免这种歧义,请您使用更长的有效载荷重复测试,例如在主机尾部之前添加 16 或 32 个虚拟字节?这将清楚地表明拖车是否真的被拆空了。 请确认第二个设备接收帧的出口端口是否配置为普通端口。根据 UM 的说法,当帧从普通端口发出时,帧头和帧尾会被剥离;而当帧从主机端口或级联端口发出时,控制信息会被保留。 最后,能否请您分享一下 5 字节尾部值 `00 04 00 00 00` 是如何生成的?验证 FRAMEID、PRIO、SWITCHID 和 DESTPORTS 的位打包是否与用户手册中显示的格式一致将很有帮助。 顺祝商祺! 帕维尔 Re: host-to-switch trailer not removed on SJA1110 你好@PavelL , 感谢你的回复。拖车位置是正确的,因为我在帖子中错误地标记了车架的“末端”。实际上它比你正确指出的位置早 2 个字节(在第 57 个字节)。 因此,预告片也发生了变化,现在更有意义,也与 UM 中的方案相符。 我还可以确认,在至少 64 字节后才出现预告片的帧中,预告片会被正确移除。所以,这只会在添加尾部之前帧长度小于 64 字节时才会出现问题(如果我没记错的话,根据 IEEE 规范,尾部不应该存在)。 顺祝商祺! 尼波穆克
記事全体を表示
i.MX8MP memory layout for Cortex M7 with DRAM 1GB We have a project where we use i.MX8MP with 1 GB DRAM. We adjusted Linker files for Cortex M7, Devicetree for RPMSG shared memory and DRAM reserved memory for Cortex M7. Starting rpmsg ping pong from U-Boot works, e.g. we are able to boot into linux, load the kernel module and see correct output. The memory map looks correct also for the m_data2 section which is in the configured space inside the 1GB DRAM Starting the same firmware (elf) from linux using remoteproc works but the demo hangs when waiting for rpmsg nameservice announce. Is there someting we miss when porting? Thank you Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB Add run prepare_mcore before booting Linux In U-Boot, before run bootcmd / run bsp_bootcmd, add: run prepare_mcore If they want this automatic, include it in the board boot command before Linux is launched. Keep unused clocks enabled during debug For bring-up, also add: setenv mmcargs "${mmcargs} clk_ignore_unused" saveenv Some downstream BSPs use a more specific workaround such as clk-imx8mp.mcore_booted=1; Toradex notes that this prevents Linux from disabling the Cortex-M7 root clock on i.MX8MP. Confirm the runtime DTB is the RPMsg-enabled DTB For EVK, NXP support responses commonly point to using imx8mp-evk-rpmsg.dtb for M7 remoteproc/RPMsg. In i.MX8MP M7 remoteproc failure – “carveout doesn't fit da request” with valid NXP RPMsg firmware, the NXP support answer says to make sure imx8mp-evk-rpmsg.dtb is used in Linux. [community.nxp.com] For a custom 1 GB board, the filenames will differ, but the important point is that the runtime DTB must include the imx8mp-cm7 remoteproc node, MU mailboxes, and all RPMsg reserved-memory nodes. Verify reserved-memory and resource table alignment For i.MX8MP, the common RPMsg layout uses regions such as: dts isn’t fully supported. Syntax highlighting is based on Plain Text. vdev0vring0: vdev0vring0@55000000 { reg = <0 0x55000000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@55008000 { reg = <0 0x55008000 0 0x8000>; no-map; }; vdevbuffer: vdevbuffer@55400000 { compatible = "shared-dma-pool"; reg = <0 0x55400000 0 0x100000>; no-map; }; rsc_table: rsc_table@550ff000 { reg = <0 0x550ff000 0 0x1000>; no-map; }; A public Linux Remoteproc on i.MX8MP discussion shows this style of DT setup, including rsc-da = <0x55000000>, mboxes = <μ 0 1 μ 1 1 μ 3 1>, and memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>, .... [community.nxp.com] For your 1 GB DRAM case, make sure none of these regions are inside Linux normal memory, CMA, GPU, OP-TEE, or another reserved range. Also verify that the M7 firmware’s rsc_table.c and linker file use the same vring/resource addresses as Linux DT. For the 1 GB DRAM port, check the ELF program headers Because Linux remoteproc loads the ELF by program headers, not just by “where U-Boot copied it,” verify: readelf -l your_m7_firmware.elf readelf -S your_m7_firmware.elf | grep -E "resource|data|bss|text" Check that every loadable segment maps to an address Linux remoteproc can translate for i.MX8MP, and that your m_data2 region is inside the actual 1 GB DRAM range and matches the reserved-memory carveout. Clear stale resource table area during debug If testing repeated boot modes, clear the RPMsg resource table area before booting M7. The i.MX Linux User’s Guide says that for i.MX8M Plus LPDDR4 EVK, the resource table area can be cleared with: mw 0x550ff000 0 4 This is specifically documented for avoiding garbage resource table values Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB As I wrote, the devicetree and linker file were adjusted. The remoteproc elf loader will load the file and start it. The ported hello world demo from MXUXSDK runs fine when started from Linux. The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work. I suspect, there is anything incompatible with the MPU initialisation code for the M7.  There are addresses above 1 GB in DRAM space for the 8MP EVK? Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB do you have an y error log to share? it seems the rpmsg may not link with DRAM setting directly Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB Discussing with the AE team. Re: i.MX8MP memory layout for Cortex M7 with DRAM 1GB The binary file and elf file are generated on the same time, by the same code and linker file, oright?  "I suspect, there is anything incompatible with the MPU initialisation code for the M7. There are addresses above 1 GB in DRAM space for the 8MP EVK?"  - If everything on uboot is OK but linux rproc is not, then it seems not the issue of MPU. I may first suspend the differences between uboot and linux rproc boot M. Please suggest customer check below two things: 1) imx_rproc.c imx_rproc_att_imx8mn has been modified according to your new DRAM size? 2) Make sure the section .resource_table is in a suitable position? Because Uboot load this table by copyResourceTable, but Linux parse the .resource_table section from .elf file. Which demo they are using? can they provide all the patch of the modification, towards Linux and M7 SDK? And what isCan they share their log shows "The RPMSG demo is loaded and starts (we have valid output on M7 debug console) but rpmsg itself does not work"?
記事全体を表示
JLinkデバッグ認証 皆さん、こんにちは。 私はMCXN947(frdm_mcxn947ボード)を基にしたプロジェクトを進めており、クライアントにテストのために送る前にデバッグ認証と署名済みファームウェア検証を設定する必要がありますが、2つの点について非常に迷っています。 デバッグ認証は「現場内」のCASEに限定されているのでしょうか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? すでにこの問題に取り組んだ方が、今後の進め方について教えていただけるとありがたいです。なぜなら、私は言及されている AN14162だけで、それ以外のドキュメントはあまり見かけません MCX N セキュリティ(EdgeLock | セキュアブート | OTP) Re: JLink Debug Authentication こんにちは、 @raimbowgeddon さん。 1. デバッグ認証は「インフィールド」ケースに限定されるのか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない ->>いいえ、デバッグ認証は「ファイル内」ケースだけのものではありません。開発中にテストCAN。CMPA側で設定してください。OTP側ではありません。 2. デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? ->>はい。デバッグ認証が有効になった後は、通常は通常、以前のように通常のJ-Linkセッションを開始することはできません。まずデバッグ認証チャレンジ-レスポンスフローを実行し、その後デバッガを接続します。 MCXN947上でデバッグ認証の設定と使用手順を示す動画があります。アクセスCANかはわかりませんが: https://www.bilibili.com/video/BV13EhAzdEzV/?spm_id_from=333.1387.homepage.video_card.click よろしくお願いします。 BR アリス Re: JLink Debug Authentication こんにちは、 @Alice_Yang さん。 返信が遅れて申し訳ありません。他の緊急の仕事に追われていました。あなたがリンクしてくれた動画の手順通りにやってみたら、うまくいったようです!ツールからデバイスのロックを解除し、その後デバッガーで接続するという手順を見落としていました。画像を別の画像で上書きしようとしましたが、CFPAリージョンが書き込まれていないという警告は出ていますが、デバッグ認証ステップを行ってもフラッシュ消去はできないようです。これは普通のことですか?これはつまり、今後は取締役会が恒久的に安全になるということでしょうか?今、ボードを工場出荷時の設定に戻す方法はないのでしょうか? ご助力本当にありがとうございます FS
記事全体を表示
セーフティ推奨コンパイラ設定違反 NXPが提供するMCAL SIPで推奨されるコンパイラ設定、アセンブラ設定、リンカー設定は、Wind Riverが推奨するセーフティコンパイラの設定に従っていません。 設定について話し合い、Wind Riverコンパイラのセーフティ推奨事項にどう合致するかを確認する必要があります。 MCAL SIPパッケージ情報: - ->SW32K3_S32M27x_RTD_R21-11_7.0.1_QLP02 ->SW32K3_RTD_R21-11_7.0.1_P05_D2604 ->SW32K3_SAF_1.0.6_D2512 ->SCST_M7_S32K3_RFP_1.0.7 Re: Safety recommended Compiler setting violation こんにちは、 アプリケーションチームに直接連絡が必要な場合は、担当のNXP担当者FAE/営業担当者に連絡してください。直接サポートチャネルを設定できます。 ご質問があれば、遠慮なくお尋ねください。 よろしくお願いします、 ピーター
記事全体を表示
S32DS 3.5 请问如何获取S32DS3.5的工具链分类报告,含 TI/TD/TCL 分析和使用约束和已知限制说明这两个报告呢? Re: S32DS 3.5 Hi,lhy 这类文档具有安全属性,需要签署NDA,请通过内部支持系统提case。 https://support.nxp.com BR Joey Re: S32DS 3.5 谢谢
記事全体を表示
MiFARE Plus APDU こんにちは、 私は「winscard」/「pcsc-lite」ライブラリとHID Global OMNIKEY 5122リーダーを使ってMIFAREカードにデータをエンコードするWindows/Linuxアプリケーションを開発しています。クラシックカードとウルトラライトカードのサポートをうまく実装でき、今度はプラスカードのサポートも追加する必要があります。 `MF1P(H)x2.pdf`より公開ドキュメント(下記リンク参照)では、このカードは「GetVersion」や「WritePerso」などのネイティブコマンドをサポートしていることを知っており、もしセクション8.2.3の内容を正しく理解していれば、これらのコマンドはAPDUでラップされている可能性があります。それは理想的です。なぜなら、他のカードの処理方法も全く同じだからです。つまり、APDUを作成して送信するのです。 私の質問は以下のとおりです。 1. MIFARE Plusのネイティブコマンドとそのパラメータを説明しているドキュメントは?これらのコマンドを正しく作成するために、この情報が必要です。 2. 私の理解では、MIFARE Plusはカードにコマンドを送信するためにAESベースの認証と暗号化が必要です。この内容を詳しく説明している文書はどれですか? 3. APDUでネイティブコマンドをラップする方法に関するドキュメントはありますか? 4. `MF1P(H)x2.pdf`には多くのリンク、またはリンクのように見えるテキストが含まれていますが、クリックできません。例えば、`CommitReaderID`、`WritePerso`、`CommitPerso`、および`Virtual Card Architecture`などです。これらの書類にはどうやってアクセスCANできますか?これらのリンクがそれぞれどの文書を参照しているかを特定する方法はありますか? NDAに署名し、NXPアカウントのセキュアセクションにあるいくつかの書類へのアクセス権を得ましたが、どれも私の質問に答えてくれません。 https://www.nxp.com/docs/en/data-sheet/MF1P(H)x2.pdf Re: MiFARE Plus APDUs こんにちは、 @Codringher あなたの調子が良いといいのですが。 MIFARE Plus EV2をサポートするリソースはNDAの下で保護されており、このページの指示に従ってSecureアクセス権を通じて申請する必要があります: Secureアクセス権 | NXP Semiconductors。また、 Secure Access Rights FAQs(セキュリティアクセス権FAQs)も確認することをお勧めします。NXP Semiconductors。 受信トレイをご確認ください。先ほどプライベートなコミュニティメッセージをお送りしました。 よろしくお願いいたします。 エドゥアルド。
記事全体を表示
eFlexPWM入力キャプチャがS32K364でキャプチャされない - フラグは設定されているがCAPTCOMPBはゼロのまま 私はS32K364マイクロコントローラのeFlexPWMモジュール(インスタンス IP_EFLEXPWM_0)を使って、入力キャプチャを通じて外部信号の周波数と周期を測定しています。私は サブモジュール2 (SM[2])を使用しています。私の構成は以下の通りです: SM2_CAPTCTRLB->EDGB0 = 0x02; (キャプチャ回路0の場合、立ち上がりエッジでキャプチャ) SM2_CAPTCTRLB->EDGB1 = 0x02; (キャプチャ回路1の立ち上がりエッジでのキャプチャ) SM2_ARMB = 1; (キャプチャー回路をArm) コードを実行した後、以下のことが確認されました。 で SM2_CAPTCTRLBのカウンタステータスビットは以下を示します。 CB0CNT = 0x4 CB1CNT = 0x4 で SM2_STS 、両方のフラグビットがセットされています。 CFB0 = 1 CFB1 = 1 しかし、取得された値( SM2_CAPTCOMPB )は 0 どちらのキャプチャ回路においても、データはラッチされません。 これは何が原因でしょうか?他に何か必要な設定(例えば、クロックの有効化、入力多重化、カウンタの設定など)で、私が見落としているものはありますか?フラグはキャプチャイベントが検出されたことを示しますが、キャプチャされた値は更新されません。どんなご意見でも大変ありがたく思います。 必要に応じて、ピン多重化設定やカウンターモードなどの詳細情報を追加してください。幸運を! Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero ハイ まず、最新のS32K3 RTD 7.0.xを確認しました。しかし、 S32設定ツール はまだ eFlexPWM E-Capture 機能をサポートしていません。 もしよければ、S32K396でテストしたいので、あなたのプロジェクトを共有してもらえますか?(残念ながら、私はS32K364を持っていません。私は S32K396-BGA-DC1 評価ボードしか持っていません。) 次に、 S32K396RM(Rev. 4、11/2024) の 「56.3.14 拡張キャプチャ(E-Capture)」の セクションを確認してください。そのセクションで言及されているレジスタ、特に図 254 のレジスタを確認してください。E-キャプチャ ロジック。eFlexPWM_0レジスターのスクリーンショットも共有しても構いません。 SM2_CAPTCTRLBの[EDGB0]、[EDGB1]、[ARMB]で言及されたビット以外に、 SM2_CAPTCTRLBの他のビットはどのように設定しましたか?   SM2_CAPTCTRLB[CB0CNT] = 0x4および[CB1CNT] = 0x4を確認されたとのことですので、対応するレジスタ値SM2_CVAL4 、 SM2_CVAL4CYC 、 SM2_CVAL5 、およびSM2_CVAL5CYCを確認されましたか?   さらに、 SM2_CAPTCOMPB[EDGCNTB]の値を読みたい場合は、まず SM2_CAPTCTRLB[EDGCNTB_EN] と SM2_CAPTCOMPB[EDGCMPB]を有効にしてください。 なぜ SM2_CAPTCOMPB[EDGCMPB] を0に設定しているのか分かりません。図254のコンパレータが使えなくなるように見える からです。E-キャプチャロジック が正しく機能しない。 よろしくお願いいたします ロビン Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero こんにちは、 @Robin_Shen さん。 MCTRLレジスタとCAPTCTRLBレジスタを適切に設定することで、外部周波数測定を正常に実装できました。しかし、テストの結果、私が達成できる最低周波数は5kHzであり、私の要求は1Hz程度の低周波数をサポートすることになっています。 プリスケーラーとプリスケーラー代替設定を調整してみましたが、改善は見られませんでした。何か提案やトラブルシューティングの方法を教えていただけますか?サポートありがとうございます。 Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero サブモジュール2の周期が短すぎるようです。「 56.3.18.3 サブモジュール0よりも低い周波数でサブモジュールを実行する」を読んで、サブモジュール2にAUX_CLKやEXT_CLKなどのより低い周波数のクロックソースを選択してみてください。
記事全体を表示
What kind of port does the T Embed have? I have the standard model T Embed, but i have no Idea what kind of port it has (the other port, not usb c), because the official site says its a grove port, the lilygo Wiki site says its a qwiic port. Can anyone help me please? Boot ROM|Booting | Flash Re: What kind of port does the T Embed have? Hello @papaku , The T‑Embed is not an NXP product, so this may be outside the scope of our support. Thank you for your understanding. BR Celeste
記事全体を表示
Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hello NXP Team, We are working on a zonal architecture using S32G399A as Zone Controllers connected to HPC Current Architecture: We are currently using the GMAC with full Time-Aware Shaper (TAS / 802.1Qbv) support along with complete TSN features. DDS runs over this GMAC path, and we have good time determinism for our service-oriented traffic. New Exploration: We have successfully brought up and tested the official NXP LLCE + PFE sample application (CAN2ETH / ETH2CAN) as described in AN13423. The goal is to offload selected high-frequency / low-latency CAN signals from ECUs directly via LLCE → PFE (IEEE1722 AVTP over UDP) to reduce CPU load and latency on the Zone Controller. From community discussions, we understand that PFE only supports 802.1AS-Rev (time synchronization) and does not support Time-Aware Shaper (802.1Qbv / TAS) or Frame Preemption, unlike GMAC. Question / Request for Guidance: Since LLCE is tightly integrated with PFE (using PFE_HIF3), what is NXP’s recommended best practice in this scenario? Can we enable TAS support on PFE by using / customizing the PFE source code provided by NXP? (I saw that NXP provides PFE source code – would this help us add or enable TAS functionality?) If TAS cannot be enabled on PFE, what is NXP’s recommended best practice to achieve strong time determinism for the LLCE + PFE CAN2ETH traffic? Should critical time-sensitive CAN signals continue to use the GMAC + TAS path, while only non-critical or high-volume signals use LLCE + PFE? Is the recommended approach to rely on an external TSN switch (such as SJA1110) downstream of the PFE port to provide full TAS scheduling for the tunneled traffic? Are there any plans or firmware updates that will add TAS support on PFE in the future? We want to decide the right split between GMAC and PFE paths without compromising determinism for safety-relevant or hard real-time signals. Any official guidance, reference designs, or configuration recommendations would be very helpful. Thank you in advance! Best regards, Arsal Imam SDV Architect @ GK Automobiltechnologie (Disrupt) GoldVIP Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi,arsalimam Thank you for your contacting and detail information. I have received your questions and will help you to check it. BR Joey Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi,arsalimam Refer to the AUTOSAR_MCAL_ETH_43_PFE_UM.pdf, PFE MCAL driver supports the Time Aware shaper, the shaper can be configured in the EB. Hope this information can help you. BR Joey Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hello Joey_z, Thank you for your prompt response and for pointing me to the AUTOSAR_MCAL_ETH_43_PFE_UM.pdf. I appreciate the clarification, we will review the PFE MCAL driver documentation and explore Time-Aware Shaper (TAS / 802.1Qbv) configuration through the EB (Elektrobit) tool. As a quick follow-up question: Does the PFE MCAL driver also support Frame Preemption (IEEE 802.1Qbu / 802.3br)? If yes, could you please share the relevant section in the User Manual or any configuration guidance for enabling it alongside TAS? We are trying to fully understand the TSN feature set available on the PFE path before finalizing the traffic split between GMAC and LLCE+PFE. Thank you again for your support. Best regards Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi,arsalimam As a quick follow-up question: Does the PFE MCAL driver also support Frame Preemption (IEEE 802.1Qbu / 802.3br)? >>>PFE does not support it. BR Joey
記事全体を表示
S32K358 + FS2633:MCU组装完成后,RSTB保持低电平;连接JTAG后,RSTB变为高电平。 我正在使用S32K358和FS2633 。当我只测试 FS2633 部分(移除 MCU)时, RSTB 被释放(高电平) ,并且3.3V 电源轨存在。 组装好 MCU 和所有元器件后, RSTB 保持低电平,MCU 无法启动。 如果我连接JTAG 调试器, RSTB 变为高电平,我可以成功地对 MCU 进行编程,应用程序也能正常运行。但是,一旦我断开 JTAG, RSTB 就会再次变为低电平,MCU 就会停止运行。 一个观察结果是, FS2633 RSTB 输出为 3.3 V 信号,而我的板上的 S32K358 RESET 线被拉高至 5 V。尽管存在这种电压差,但只要连接 JTAG 调试器,系统就能正常工作。RESET电压等级或调试器是否会影响RESET或上电顺序? 这个问题是否与上电顺序、RESET 时序、FS2633 启动配置或调试器相关行为有关?有没有人遇到过类似的问题?或者有什么调试建议吗? Re: S32K358 + FS2633: RSTB stays LOW with MCU assembled, but goes HIGH when JTAG is connected 你最好尝试将FS2633 RSTB 的电压拉高到 3.3V 进行测试,看看是否存在这个问题。
記事全体を表示
IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Hello, We are looking for an explanation for a non-working DDR4 timing set. In short, the timings generated by the DDR Tool passed calibration and stress tests, but led to sporadic Linux kernel crashes during boot, with an "undefined instruction" error. Setup (raw facts): - The SoC is an i.MX8M Mini Solo (single Cortex-A53), DDR4 (Winbond W664GG6RB-06) at 1200 MHz (DDR4-2400) in 1:2 DFI (DDR PHY Interface) frequency-ratio mode, with a single x16 4 Gb device (512 MB, no ECC). - The BSP is NXP L4.14.98_2.0.0 (Linux 4.14.98, U-Boot 2018.03); the DDR config was generated with MSCALE DDR Tool v3.31 (Windows version) and PHY training firmware v201709. The same firmware is used in Yocto to build the U-Boot image. - We are qualifying one common timing set for three interchangeable 4 Gb x16 DDR4 parts (Alliance AS4C256M16D4, ISSI IS43QR16256B, Winbond W664GG6RB-06), all operated at 1200 MHz. - To meet the slowest part's (Winbond) tRCD/tRP/tAA (~14.16 ns at the 2400 bin) we set CL=17 (17-17-17), which the Tool encodes as MR0 = 0x0864 with the matching CL-derived registers (e.g. DFITMG0 = 0x038C8207, DRAMTMG2 = 0x0609050D). - The DRAM runs static at the 2400 setpoint (DVFS/busfreq disabled in the device tree), so there is no frequency scaling by Linux at runtime. Observations: - The 17-17-17 config passes the DDR Tool stress test (~24 h) and U-Boot mtest (~1 h) with no errors. - Under Linux (on boots that reach the shell prompt) it also passes stressapptest + fio (crc32c-verified), continuously and even at Tj = 84 °C, for over an hour with zero data errors. - Nevertheless, Linux sporadically crashes during boot with "Internal error: undefined instruction" (corrupted kernel .text), ~1.1 s into the kernel, on roughly 5–7 % of cold boots (measured with an automated cold power-cycle loop). - The failure is die-independent: the CL=17 image crashes the same way on a second of these parts (ISSI), while the CL=16 image boots Linux reliably on that same ISSI part. - Both even-CL configs boot Linux reliably: 16-16-16 (our long-standing production timing) and a newly built 18-18-18 (no kernel crashes observed) — only the odd-CL 17-17-17 fails. - Only the CL-derived registers differ between the failing and working configs (MR0 CAS bits, DFITMG0 dfi_t_rddata_en, DRAMTMG2 read latency / rd2wr, DFITMG2 rdcslat, ODTCFG rd_odt_delay). Hypothesis: We suspect odd CAS latency at the 1:2 DFI ratio is the root cause: the read-data return latency is CL/2 in DFI clocks — a non-integer 8.5 for CL=17 versus integer 8.0 / 9.0 for CL=16 / 18. Since the read FIFO (written by DQS, read by the controller clock, Reference Manual §9.3.2.2.2) handles the steady state and steady stress passes, we suspect the marginality surfaces at read burst-to-burst transitions, where odd CL's half-DFI-clock offset would hit a first/last-beat edge case the RM does not document. Questions: Is odd CAS latency (e.g. CL=17) supported on the i.MX8M Mini DDR4 PHY in 1:2 DFI mode, or are there known constraints/errata for odd CL? In particular — can the DDR Tool produce an odd-CL configuration that passes its own stress test yet is marginal under real boot traffic, and is there a recommended way to constrain read burst-to-burst timing for odd CL? Attached: kernel crash console dump, the CL=17 .ds script for the DDR Tool, and the produced ddr4_timing.c. Any advice will be appreciated. Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Sorry, somehow attachments didn't attach. Here are they. Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Hello,  Please try again by modifying from CL=17 to CL=18, run ddr test and test your linux again, I recommend you to upgrade to a newer release.  Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 Please check the timing parameter for the parts below for  CAS Latency   tRCD(ns)  tRP(ns) Alliance AS4C256M16D4     DDR4-2400                                             17      14.16   14.16 ISSI IS43QR16256B                   2400Mbps                                            16-16-16 (-083R) Winbond W664GG6RB-06  DDR4-2400                                            17-17-17 The 3 parameter for IS43QR16256B is different. So you may need dedicated setting for 3 parts instead using one setting for all 3 part. It seems the issue only happened at cold boots, right?
記事全体を表示
デフォルトのワークスペース こんにちは、 MCUXpressoIDE v.24.9.25を使っています(新しいバージョンを使うことはできるのですが、何らかの理由で24.9.25を使う必要があります)。「C:\NXP\MCUXpressoIDE_24.9.25\ide\configuration\config.ini」で確認できます。osgi.instance.area.default は「@user.home/Documents/MCUXpressoIDE_24.9.25/workspace」なので正しいです。 しかし、Windowsのユーザーセッションを閉じて他のユーザーで新しいセッションを開くと、MCUXpressoIDEを実行するとデフォルトのワークスペースが最初のユーザーのワークスペースになるため、各ユーザーがそれぞれ自分のディレクトリを持っているため、2番目のワークスペースディレクトリに変更する必要があります。 どうやらosgi.instance.area.default はうまく動作していないようです。なぜなら、@user.home/Documents/MCUXpressoIDE_24.9.25/workspaceが各ユーザーのホームであるはずなのに、常に最初のログインユーザーを受け入れるからです。 どうやって再構成すればいいですか? ありがとうございます。 #mcux Re: Default workspace こんにちは、 「これをデフォルトとして使用し、再度質問しないでください」というセル機能が有効かどうか、確認の手伝ってもらえますか? 「これをデフォルトとして使用し、再度質問しない」オプションにチェックを入れると、MCUXpresso IDEは常に選択したワークスペースが開いた状態で起動します。ワークスペースを選択する際にこのチェックボックスを選ばないことをおすすめします もう一つのワークスペースをユーザー 2に追加して「最近のワークスペース」に残すと、アプリを開く前に希望のワークスペースを選択できます また、タブウィンドウ > 環境設定 > 一般 > 起動とシャットダウン > ワークスペース 起動時にワークスペースの選択を促すメッセージを表示するように設定します。 敬具、ルイス
記事全体を表示
FEE INIT into hardware Hello, I want to use FEE to store data, according to S32K344 After configuring the example, during the init process, I entered the hardware. I tried unlocking the C40 beforehand, but it still didn't work. I used SW32K3_S32M27x_RTD_R21-11_4.0.0_D2311_DS_updatesite. S32DS 3.6.3   Re: FEE INIT进hardware Hi@ LJH1 I'll take some time next week to check it out for you. 回复: FEE INIT进hardware It's not an NXP development board, it's the 8MHz board used by our hardware engineers. Re: FEE INIT进hardware The previous project was based on RTD 4.0.0, and maintenance and development primarily used this version. We will only switch to the new RTD version if we stop maintaining the old project, as the company needs a unified version. Re: FEE INIT进hardware Hi@ LJH1 I see that a total of two issues were created, both based on RTD 4.0.0. I'd like to ask why we're still developing on this version. Our RTD version has already been updated to RTD 7.0.0, and many older versions... The bug has been fixed in the new version. If possible, I recommend that you install and use the latest RTD version. If for some reason I have to use RTD 4.0.0, then I will take some time to check the program you provided. Also, I'd like to clarify what hardware you are using? I see in the project you provided that the external clock is set to 8MHz, which shouldn't be our NXP development board. Re: FEE INIT进hardware Hi@ LJH1 The pre-compilation options for the “MemAcc” component are incorrect.
記事全体を表示