Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
#S32K312 IO 输入配置 我想使用LPUART0 RX,需要配置IMCR[699],但规范中只列出了IMCR[473],那我该怎么办? Re: #S32K312 IO input config 嗨@joshua9264 S32K3xx 参考手册第 12 版第 10.1.2 节指出: “附件 IOMUX 文件中定义的 IMCR 相对于 SIUL2 内存映射部分中定义的 IMCR 编号有 512 的偏移量。” 为了帮助阐明如何应用偏移量,RM 第 4.4.3 节还提供了一个示例。 BR,VaneB Re: #S32K312 IO input config 是的,我找到了。谢谢
記事全体を表示
关于MIMXRT1170和MIMXRT1180中外部存储器接口的ECC支持需要进一步说明 您好,NXP团队, 我们正在评估MIMXRT1170和MIMXRT1180在内存完整性是关键要求的关键应用中的性能。因此,了解这些设备上的确切 ECC 覆盖范围对于我们的架构和设备选择过程非常重要。 在查阅了现有文档后,我们未能找到关于哪些外部存储器接口提供 ECC 保护以及如何实现 ECC 的清晰总结。 1. 外部接口 ECC 覆盖范围 对于 MIMXRT1170 和 MIMXRT1180,下列哪些接口支持 ECC? FlexSPI NOR闪存 FlexSPI HyperFlash FlexSPI 超级内存 SEMC 同步动态随机存取存储器(SDRAM) SEMC SRAM/PSRAM eMMC SD卡接口 其他外部存储器接口(如有) 2. ECC实施 对于每个支持的接口: 硬件控制器是否原生支持ECC? ECC功能在硬件中是自动激活的,还是需要软件配置? 3. XECC 的使用 (RT1170) 参考手册讨论了 XECC 模块;但是,它与外部存储器的关系并不完全清楚。 请问您能否解释一下: 哪些存储器/接口可以通过 XECC 进行保护? XECC 是否仅适用于内部存储器,还是也可以保护存储在外部 同步动态随机存取存储器(SDRAM)、SRAM、HyperRAM、闪存等中的数据? 是否有任何使用示例或应用笔记来展示 XECC 对外部存储器接口的保护? 问候, Pooja Re: Clarification Required on ECC Support for External Memory Interfaces in MIMXRT1170 and MIMXRT118 i.MX RT1170 ECC 应用您可以参考 AN13204 了解 ECC 启用方法。 ECC主要用于内部存储器,对于外部存储器,ECC主要用于并行和串行的与非设备。您可以访问UM网站查看详细信息。你想使用哪种类型的内存进行ECC纠错? Re: Clarification Required on ECC Support for External Memory Interfaces in MIMXRT1170 and MIMXRT118 你好@Pooja_04 , 谢谢你的提问! 1. 外部接口 ECC 覆盖范围 MIMXRT1170 FlexSPI 和 SEMC 控制器 本身并不为外部存储器数据路径提供通用的原生 ECC。然而,RT1170集成了 三个独立的外部ECC控制器(XECC)实例,分别与 FlexSPI1、FlexSPI2 和 SEMC。eMMC 和 SD 卡(通过 uSDHC) 没有MCU端ECC。 MIMXRT1180 目前的产品文档明确规定了 SEMC Raw NAND 接口的硬件 ECC。确实如此。 RT1180 文档并未指定 SEMC SDRAM/SRAM、FlexSPI NOR/HyperFlash/HyperRAM 或 SD/eMMC 的通用控制器端 ECC。 无法识别 RT1170 型 XECC_FLEXSPI / XECC_SEMC 模块。eMMC/SD 设备可能实现内部介质 ECC,SD/eMMC 协议使用 CRC 进行传输错误检测,但这些机制不应被视为 MCU 端到端 ECC 保护。 2. ECC实施 MIMXRT1170 — XECC(外部存储器): ECC是 FlexSPI/SEMC 控制器本身不提供此功能;此功能由专用的 XECC 模块提供。 ECC不会自动启用。软件(或适用的 ROM/熔丝流程,通过熔丝)必须配置 ECC 地址区域并启用读/写 ECC 处理。 每个 XECC 实例支持 它具有四个可配置的受保护地址窗口,并且每个 32 位数据字都带有 32 位 ECC。 必须先初始化(预加载)整个区域,然后才能读取;否则读取操作将引发 ECC 错误。 MIMXRT1180 — SEMC 与非硬件 ECC: Provided natively by the SEMC controller hardware for the RAW NAND interface (8/16-bit). 3. XECC 的使用 (RT1170) XECC 旨在用于 外部存储器。这是 不适用于内部存储器——内部 TCM/Cache/OCRAM 使用独立的 ECC 机制(内核内置 ECC 和 FlexRAM/MECC 控制器)。 XECC 可以保护外部 同步动态随机存取存储器(SDRAM)、SRAM/PSRAM(SEMC 后面)和 NOR Flash / HyperFlash / HyperRAM(FlexSPI1/FlexSPI2 后面)中的数据。 使用示例/文档: AN13204 — “i.MX RT1170 ECC 应用” (涵盖外部存储器的 XECC、熔丝/软件配置、ROM 预加载、错误注入): https://www.nxp.com/docs/en/application-note/AN13204.pdf (配套代码:AN13204SW) MCUXpresso SDK XECC 示例 (仅限RT1170/RT1160) i.MX RT1170 参考手册 (IMXRT1170RM) — 专用的 XECC 分会。 因此,如果ECC保护 外部 SDRAM/SRAM 或 FlexSPI Flash/HyperRAM 这是您的关键应用程序的硬性要求。 RT1170(通过 XECC) 符合这一点,而 RT1180 没有提供等效的外部 ECC 控制器——在 RT1180 上,控制器侧的外部 ECC 仅限于 SEMC RAW NAND 接口。 此致, 加文
記事全体を表示
登録:S32K eMIOSエンコーダーのCW/CCWカウンタの静的ローター位置での挙動 チームの皆さん、こんにちは。 私はS32K322マイクロコントローラを使っており、位置センサーからローター角度を得るためのエンコーダーインターフェースを実装しています。 申請ノートに基づいて、TRGMUX、LCU、eMIOSを含む必要なMCALモジュールを構成しました。エンコーダーの機能は正常に動作していますが、CWカウンターとCCWカウンターで予期しない動作が見られました。 私の質問は以下のとおりです。 ローターが動いていない静的なローター位置では、CWおよびCCWカウンターがフリーランニングカウンターとして振る舞うことが期待されますか? 私の場合、CWとCCWカウンターは増加し続けますが、絶対ポジション値はゼロのままです。これは想定される動作ですか? もしこれが予想されるなら、ローターが静止しているのにCWやCCWカウンターが増加する理由は何ですか? もし予想外の情報があれば、以下の方法を提案していただけませんか: MCALの設定(TRGMUX、LCU、またはeMIOS)において、必要な構成変更はありますか? ローターが静止しているときにCW/CCWカウンターが増加しないように、追加のソフトウェア機構やフィルタリングを実装すべきでしょうか? 参考のために動画を添付しました。 AWSライブラリS32K3 よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 LCnからのCWおよびCCW出力は、それ自体で位置カウンターではありません。インクリメンタルエンコーダの実装によれば、使用されるLCnは、検出された直交シーケンスに応じて、A/B信号の各エッジでCWまたはCCW出力にパルスストリームを生成します。eMIOSはこれらのパルスをカウントして位置を蓄積します。これは、PHA/PHBがLCUで処理され、eMIOSが位置蓄積のカウンターとして機能するS32K3の直交方式と一致しています。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 ローターが本当に静的でエンコーダのA/B入力が安定している場合、新しいCW/CCWパルスを連続的に生成すべきではありません。したがって、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 こんにちは、 I could not find any register corresponding to the UIN status in the S32K322 リファレンス・マニュアル. Could you please check and guide me on how to verify this for further analysis? I debugged the registers that update the CW and CCW counters. According to the 参考マニュアル, eMIOS チャンネル 5 MCU CNT corresponds to the CW counter, and eMIOS チャンネル 6 MCU CNT corresponds to the CCW counter. しかし、MCU CNTのレジスタは、ローターが静的状態でも0から65535(フリーランニング)まで連続的に増加し続けるのを観察しました。この行動が予想されるものなのか、あるいは何が原因なのか教えていただけますか? 参考までに、関連するレジスタ値のスクリーンショットを添付しました。 さらに、MCALの設定も確認しましたが、共有されたアプリケーションノート通りに正しく設定されています。 早くもサポート よろしくお願いいたします。 ティル
記事全体を表示
利用管道进行日志记录 大家好, 我正在尝试集成 freemaster pipes 进行日志记录(以后可能会用到它的更多功能)。 由于我使用的是 Linux 系统,所以我尝试了 freemaster light + python 的方案。 我可以正常连接,但是当尝试打开管道并打印管道日志消息时,我没有通过 rpc 服务器收到任何数据。 为了验证目标实现,我还通过 Windows GUI 进行了检查,发现它可以正确读取管道,因此问题似乎出在 PC 端。 请参见附件中的示例 Python 脚本。任何提示都欢迎。 顺祝商祺! Re: Utilize pipe for logging 没关系,看来我需要在接收端显式调用 PipeFlush 函数。没想到会这样。附件为可运行示例,供您参考。 Re: Utilize pipe for logging 你好, 太好了,你终于搞定了。我确认需要调用 PipeFlush 函数,因为它会导致管道数据在两个方向上交换。实际上,这是唯一一个会导致物理数据传输的管道调用。PC 端和目标端的所有其他操作都只是将数据缓冲到管道缓冲区。 使用 FreeMASTER 协议时,PC 是唯一的通信启动器。目标板无法自行启动。PipeFlush 是 PC 给目标用户一个机会来报告(然后发送)任何新的管道数据的地方。 问候, 米哈尔
記事全体を表示
LS1088AのDDRvツールに問題があります こんにちは、LS1088A SoCベースのカスタムボード上で新しいタイプのDDR4 SO-DIMMを検証しようとしているのですが、DDRvで問題が発生しています。過去にいくつかのDDR4モデルを検証しましたが、問題は発生しませんでした。 私が検証しようとしている新しいDDRモデルは、メンフィスのB075I IMM2G72D4SOD8AGです。その速度制限は2,666ですが、2,100MT/sで運行したいと考えています。QorQの新しい構成プロジェクトを作成し、SPD経由でDDR構成を正常に読み込むことができました。しかし、最初のステップ(クロックのセンタリング)は「自動検索と書き込みレベリング開始値の検出」部分で0.04%で一貫して失敗します。 テスト結果の概要を見ると、テストが失敗し、理由は「DDRインターフェースがWRLVL_START値以外の原因で故障しています。ボードのハードウェア問題を調査してください。" ログセクションには、以下の情報が表示されます。 ################## ## Result for: wrlvl_searcher ## ## ## Run  1 ## ####################################   テスト結果: [ ============================================================ 更新: WRLVL_CNTL = 0x86550605、WRLVL_CNTL_2 = 0x00000000、WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09060C0F、WRLVL_CNTL_3 = 0x0E110B0E、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09050C0F、WRLVL_CNTL_3 = 0x1611130E、SDRAM_CLK_CNTL = 0x02800000     DDRインターフェースがWRLVL_START値以外の原因で故障しているので、基板のハードウェア問題を調査してください。 <> {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     エラーキャプチャレジスタ: 0xE20、0x00000000 0xE24、0x00000000 0xE28、0x00000000 0xE40、0x00000080 0xE44、0x00000000 0xE48、0x0000001D 0xE4C、0x00000000 0xE50、0x00000000 0xE54、0x00000000 0xE58、0x00010000     ごみ: 0xF00、0x00000000 0xF04、0x00001002 0xF08、0x0000000A 0xF0C、0x14000C20 0xF10、0x00000000 0xF14、0x00000000 0xF18、0x00000000 0xF1C、0x00000000 0xF20、0x00000000 0xF24、0x2F003500 0xF28、0x2A003600 0xF2C、0x3E004A00 0xF30、0x44004600 0xF34、0x3A007000 0xF38、0x00000000 0xF3C、0x00000000 0xF40、0x00000000 0xF44、0x00000000 0xF48、0x00000001 0xF4C、0x94000000 0xF50、0x0F001300 0xF54、0x0C001800 0xF58、0x1F002C00 0xF5C、0x22002700 0xF60、0x1C000000 0xF64、0x00009000 0xF68、0x00000020 0xF6C、0x00000000 0xF70、0x0060007B 0xF74、0x00000000 0xF78、0x00000000 0xF7C、0x00000000 0xF80、0x00000000 0xF84、0x00000000 0xF88、0x00000000 0xF8C、0x00000000 0xF90、0x00000000 0xF94、0x80000000 0xF98、0x00000000 0xF9C、0x29002B00 0xFA0、0x2B002B00 0xFA4、0x27002D00 0xFA8、0x28002E00 0xFAC、0x27000000 0xFB0、0x10000003 0xFB4、0x42344241 0xFB8、0x40334332 0xFBC、0x43404150 0xFC0、0x00004133 0xFC4、0x44424444 0xFC8、0x44415134 0xFCC、0x51414251 0xFD0、0x42414241 0xFD4、0x50434252 0xFD8、0x50444342 0xFDC、0x42413444 0xFE0、0x43514340 0xFE4、0x44424444 0xFE8、0x42514441 0xFEC、0x40423443 0xFF0、0x43424342 0xFF4、0x43415042 0xFF8、0x51415341 0xFFC、0x54000D0D       データ: 0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000   ]   検証手順が失敗した際の詳細なCCSログも添付しました。   これが何を意味するのか、また問題のデバッグ方法を説明していただけますか? QorIQ LS1デバイス Re: Problem with DDRv tool on LS1088A 新しいタイプのDDR4 SO-DIMMと比べて、以前使われていたSODIMMはどのようなものでしたか?新旧間の変更点 Re: Problem with DDRv tool on LS1088A こんにちは、 あなたの具体的なダンプに関して最も有効な解釈は、コントローラがトレーニング中に自動キャリブレーションエラー( ACE )を発生させ、DDRvの書き込みレベリング検索が調整しても有効な動作領域を見つけられなかった WRLVL_START です。これはまずリセット/クロック/構成/DQマップ/SIチェックを指し示しており、DDRリセットと DQn_MAP は、NXPのデバッグ履歴においてこのDDRv障害クラスに繰り返し関連付けられているため、優先順位が高い。ですので、チューニングマージンを決める前にDDRクロック/RCW、DDRリセットタイミング、SPD由来のランク/ジオメトリ、DQマッピング、パワー/SIを確認してください。 よろしくお願いします。
記事全体を表示
S32K3のeTPUクランク、カム、インジェクション、イグニッション こんにちは、 クランクとカムの信号に合わせてインジェクションと点火を作動させるドライバを実装する必要があります。 このドライバを実装するための最適なソリューションを理解する必要があります。 私の疑問は次のとおりです: 1) AN4907SW.zip で提供される API は、S32K3xx に存在する eTPU と互換性がありますか? 2)いいえの場合、この API を S32K3xx に適合させるのは良い解決策ですか、それとも ConfigTool を使用するのが最善の解決策でしょうか? このアプリケーションについて S32K3xx の例はありますか? よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@francescovico ビッグ エンディアンからリトルエンディアンにデータを変換するには、データ型のサイズに応じてビット シフトとマスクを調整してバイト順序を逆にする必要があります。 GCC は、このプロセスを簡素化する組み込み関数を提供します。例: uint32_t __builtin_bswap32 (uint32_t x)。詳細については、GCC ドキュメントの7.2.3 バイトスワッピング組み込みを参照してください。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@VaneB 、 私が正しく理解していれば、オートモーティブ機能 (CRANK、SPARK...) はビッグエンディアンマイクロコントローラ用に作られています。 S32K364 (リトルエンディアン) 上のオートモーティブ機能で eTPU を使用するには、次を選択して関数セットをダウンロードする必要があります。 そして関数を変更します: uint32_t *fs_memcpy32(uint32_t *dest、uint32_t *source、uint32_t size); void fs_memset32(uint32_t *開始、uint32_t 値、int32_t サイズ); 各 32 ビット値を交換して、リトルエンディアン コードとパラメータを読み書きするというのは本当ですか? よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@francescovico 電動化アプリケーション向け S32K39/37/36 マイクロコントローラにはeTPU が含まれています。ただし、現在、これらのデバイス向けに利用できる MPC5634 の AN4907 に類似した専用のドキュメントやデモはありません。 ただし、AN4907 ドキュメント、デモ、マイクロコードは S32K39/37/36 ファミリに適していますが、これらのデバイスはリトルエンディアン アーキテクチャを使用していることに注意してください。したがって、メモリ アクセス API を変更する必要があります。 リトルエンディアン に更新された CodeWarrior eTPU 関数セレクタ でモータ制御関連のモジュールを参照できます。 BR、ヴェインB Re: eTPU crank, cam, injections and Ignitions on S32K3 指摘していただきありがとうございます! エンディアン変換の問題が発生しました。その結果、欠落した歯のマスクが正しく構成されず、1 回転あたり 350 度、または 1 サイクルあたり 700 度とカウントされました。 現在、元の投稿のデモ アプリは修正されています。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@MilanBrejlさん、 現在、Fuel Cyl 1 etpu ドライバを使用しようとしています。 ドライバは s24AngleNormalEnd を「開始角度」として使用し、s24AngleStop で噴射を停止するようです。 u24InjectionTime の持続時間は決して尊重されません。 それは可能ですか? .rarが添付されていますインジェクターパラメータが以下の「燃料シリンダー 1」のピコスコープ取得を含むファイル: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24角度法線終了= DEG2TCR2(-180)、 .s24アングルストップ= DEG2TCR2(-360)、 .s24角度オフセット再計算= DEG2TCR2(-30)、 .u24注入時間= USEC2TCR1(1200)、 .u24補償時間= USEC2TCR1(0)、 .u24注入時間最小値= USEC2TCR1(0)、 .u24オフタイム最小値= USEC2TCR1(0)、 .eGenerationDisable= ETPU_FUEL_GENERATION_ALLOWED }; ピコスコープ取得では、正確に 180° で注入が開始され、360° で注入が停止し、注入持続時間が 30 ms (1.2 ms であるべき) であることが確認できます。 よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@MilanBrejlさん、 現在、Fuel Cyl 1 etpu ドライバを使用しようとしています。 ドライバはs24AngleNormalEnd を「開始角度」として使用し、s24AngleStop ですべての噴射を停止するようです。 u24InjectionTime の持続時間は決して尊重されません。 それは可能ですか? .rarが添付されていますインジェクターパラメータが以下の「燃料シリンダー 1」のピコスコープ取得を含むファイル: Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24角度法線終了= DEG2TCR2(-180)、 .s24アングルストップ= DEG2TCR2(-360)、 .s24角度オフセット再計算= DEG2TCR2(-30)、 .u24注入時間= USEC2TCR1(1200)、 .u24補償時間= USEC2TCR1(0)、 .u24注入時間最小値= USEC2TCR1(0)、 .u24オフタイム最小値= USEC2TCR1(0)、 .eGenerationDisable= ETPU_FUEL_GENERATION_ALLOWED }; ピコスコープ取得では、正確に 180° で注入が開始され、360° で注入が停止し、注入持続時間が 30 ms (1.2 ms であるべき) であることが確認できます。 よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@MilanBrejlさん、 おっしゃる通り、 s24AngleOffsetRecalc は正の数である必要がありますが、次のように記述します。 s24角度オフセット再計算 = DEG2TCR2(30) 結果は同じです(。 私は 16 チャネルの 2 つの ETPU (A と B) を備えた S32K364 を使用しています。 ETPUA で燃料ドライバーを使用するとドライバーは正常に動作しますが、ETPUB チャネル 0 を使用する必要があります。 私の必要性は、STAC レジスタを使用して、ETPUA から ETPUB に TCR1 と TCR2 を共有することです。 STAC レジスタが正しく初期化されていない可能性があります。 よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@francescovicoさん、 これは、eTPU1 から eTPU2 に TCR1 と TCR2 を共有するように STAC_ENG1 および STAC_ENG2 レジスタを設定する方法です。 役に立つかどうか教えてください。 よろしくお願いいたします。 ミラノ Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@MilanBrejlさん、 私のレジスターはあなたの提案と全く同じです: しかし、問題はまだ存在しています。 添付のピコスコープ取得では、ETPU A で生成されたスパークが青色で、ETPU B で生成されたスパークが赤色で確認できます。 両方のスパークの終了角度は 180 度、滞在時間は 8000 マイクロ秒です。 よろしく、フランチェスコ。   Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@francescovicoさん、 私のサイトでもあなたの問題を再現し、根本的な原因を見つけました。両方の eTPU エンジン間で TCR1/TCR2 時間/角度バスを共有するだけでは不十分です。スパークおよび燃料機能は、実際のエンジン速度に基づいて時間を角度に変換します。TRR(ティック レート レジスタ)を使用します。このレジスタは、Angle Clock ロジックの一部であり、eTPU A で実行される Crank eTPU 機能によって管理されます。したがって、TRR の正しい値は eTPU A でのみ保持されます。次に、eTPU B TRR を使用した eTPU B の時間から角度への変換で間違った結果が返されます。 これはかなり基本的な問題で、おそらく両方の eTPU エンジンでエンジン制御を実行している人に会ったことがないので、これは解決されていません。特に、新しい S32K3 デバイスは 16+16 チャネルに制限されているため、これは重要になります。このユースケースを提起していただき、またお待ちいただきありがとうございます。 添付のデモ アプリケーションは、(このスレッド内の) 以前のものに基づいており、次の変更が追加されています。 Spark 2 チャネルは eTPU エンジン A から eTPU エンジン B に移動されます。 チャネルマスクはそれに応じて更新されます チャネルリンクは両方のエンジンの使用をサポートする必要があります(マクロ ETPU_IP_CHANNEL_TO_LINK を使用) ピン構成が更新され、割り込み構成が更新されました Crank eTPU FW の新機能: eTPU FW イメージが更新されました。Crank 関数は両方のエンジンで実行でき、他の eTPU エンジンの TRR 値も更新できます。 この新機能では、クランク構成に1つの新しいパラメータを設定する必要があります。 どこ これが役に立つことを願います。 よろしくお願いいたします。 ミラノ Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは@MilanBrejlさん、 今では完璧に動作しています。 サポートしていただき本当にありがとうございます! よろしく、フランチェスコ。 Re: eTPU crank, cam, injections and Ignitions on S32K3 こんにちは。私もK396基板について調べており、クランクシャフト、カムシャフト、オイルインジェクターにETPUを使用したいと考えています。この件についてもう少し詳しくお話しいただけますでしょうか?
記事全体を表示
MCXN547:SWD DP ID 可读,但 AP0/AP2 访问返回 WIRE ACK FAULT 错误。 您好,NXP技术支持, 我们使用定制板上的 MCXN547VKLT,并带有外部 MCU-Link 探针。 启动调试会话时,SWD 连接失败: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. 可以正确检测到SWD-DP: DPID = 0x6BA02477 但是,访问 CPU0 AHB-AP (AP0) 失败,并显示以下错误信息: WIRE ACK FAULT 调试邮箱请求也失败了。LinkServer报告: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 我们已核实的内容: SWD频率测试范围从1 MHz到10 kHz 在示波器上,SWDIO 和 SWCLK 波形看起来正常。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC 和 I/O 电源 = 3.3 V RESET_B 工作正常 MCU-Link固件:CMSIS-DAP V3.172 LinkServer 版本:26.5.59 同一个 MCU-Link 可以与 MCXN947 开发板配合使用。 MCXN547芯片已更换为新芯片,但问题仍然存在。 USB ISP 与 VID/PID 1FC9:014F 配合使用正常。使用 blhost,我们可以: 擦除内部闪存 对内部闪存进行编程和读取 应用程序运行成功 枚举应用程序 USB 复合设备 ROM报告: Security State = UNSECURE 我们还通过 USB ISP 读取 PFR: CMPA 已完全擦除 (0xFF) 除了ROM生成的CMAC之外,CFPA已被擦除。 不存在客户 SOCU 或调试身份验证配置 请问您能否提供以下建议: AP0 和 AP2 可访问需要满足哪些条件? DM-AP 状态 0x60F93638 是否与已知的电源、RESET 或硬件配置问题相关? 是否存在与 SWD 或调试邮箱访问相关的已知 MCXN547 勘误表? 我们应该检查哪些电源和 RESET 信号才能发现此症状? MCX N
記事全体を表示
Utilize pipe for logging Hi community, I am trying to integrate freemaster pipes for logging (and maybe use more of its functionality later on). As I am running linux I tried to go the freemaster light + python path. I can properly connect but when trying to open the pipeline and print my piped log messages I am not receiving any data via the rpc server. To verify the target implementation I also checked via the Windows GUI which could read the pipe properly, so the issue seems to be on the PC side. See attached example python script. Any hints welcome. best regards Re: Utilize pipe for logging Never mind, seems I have to explicitly call PipeFlush on the receiver side. Did not expect that. Attached the working example as reference. Re: Utilize pipe for logging Hello,  it is great you got it finally working. I confirm the PipeFlush needs to be called as it causes the pipe data to be exchanged in both directions. This is actually the only pipe call which causes a physical data transfer. All other operations at both PC and target sides are just buffering the data to pipe buffers. When using FreeMASTER protocol, the PC is the only initiator of communication. The target board cannot start it by itself. The PipeFlush is the place where PC gives the target a chance to report (and then send) any new pipe data. Regards, Michal
記事全体を表示
マイクロコントローラ の選び方は?位置制御のためにエンコーダー付きのモーターを3つ制御する必要があります。 ステッピングやBLDCモーター(+モータ・ドライバまたはESC)で、xyz軸方向の負荷(例えば約3kg)の位置を制御したいと考えています。フィードバックループ用のエンコーダーやセンサも追加したいと思っています。 そのため、適切なマイクロコントローラを選ぶのに苦労しました。ブランドについては、STM32かESP32のどちらかにしようと考えています。3つのモーターがあるため、3つのPWM出力信号が必要ですが、クロック周波数や外部部品の必要性など、その他の要件が満たされているかどうかをどのように判断すればよいでしょうか? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. こんにちは、 @pekomsさん MCXを選択する場合は、このプロジェクトではMCX A34x / A344~A346から始めてください。180 MHzのCortex-M33、2つのFlexPWM/eFlexPWMブロック、多数のPWM出力、ADC、タイマー、そしてエンコーダフィードバック用のハードウェア直交デコーダブロック2つを備えているため、3軸モーター制御に最も強力なMCX適合です。 カタログを精査した結果、この種のタスクに適したハイエンドMCXの主要候補として、MCX N94xとMCX A34xが浮上した。 BR ハリー
記事全体を表示
How to choose a microcontroller? Need to control 3 motors with encoders for position control. Im looking to control the position of a load (lets say around 3 kg) in xyz axis with either steppers or BLDC motors (+Drivers or ESC). I want to add encoders as well or some sensors for feedback loop. Based on that, I struggled to pick an appropriate microcontroller. I was thinking either STM32 or ESP32 for the brand. It requires 3 PWM output signals (since 3 motors), but how do I know if everything else is enough like the frequency of the clock, do I need external components, etc? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. Hi @pekoms  For an MCX choice, start with MCX A34x / A344–A346 for this project. It is the strongest MCX fit for 3-axis motor control because it has a 180 MHz Cortex‑M33, two FlexPWM/eFlexPWM blocks, many PWM outputs, ADCs, timers, and two hardware quadrature decoder blocks for encoder feedback. A catalog pass also surfaced MCX N94x and MCX A34x as the main higher-end MCX candidates for this class of task. BR Harry
記事全体を表示
ログ記録にパイプを利用する こんにちは、コミュニティの皆さん、 ログ記録のためにfreemasterパイプを統合しようとしています(そして、将来的にはその他の機能も利用したいと思っています)。 Linuxを使っているので、FreeMaster Light + Pythonの道を試しました。 正常に接続はできますが、パイプラインを開いてパイプログメッセージを印刷しようとすると、rpcサーバー経由でデータが一切届きません。 ターゲット実装を確認するために、Windows GUIでパイプを正しく読み取れるか確認したので、問題はPC側にあるようです。 添付のPythonスクリプトの例を参照してください。どんなヒントでも歓迎です。 よろしくお願いいたします Re: Utilize pipe for logging まあいいや、レシーバでPipeFlushを明示的に呼ぶ必要があるようだ。それは予想外だった。参考として、動作例を添付しました。 Re: Utilize pipe for logging こんにちは、 ようやく動作するようになってよかったですね。PipeFlushを呼び出す必要があることを確認しました。なぜなら、この関数はパイプデータの双方向交換を引き起こすからです。これは、物理的なデータ転送を引き起こす唯一のパイプ呼び出しです。PC側とターゲット側の両方におけるその他の操作はすべて、データをパイプバッファにバッファリングするだけです。 FreeMASTERプロトコルを使用する場合、通信の開始者はPCのみとなります。ターゲットボードは自動で起動できません。PipeFlushは、PCがターゲットに対して新しいパイプデータを報告(そして送信)する機会を与える場所です。 よろしくお願いいたします。 ミハル
記事全体を表示
MCXN547:SWD DP IDは読み取れるが、AP0/AP2アクセスはWIRE ACKフォルトを返す こんにちは、NXPサポートの皆さん、 カスタムボード上のMCXN547VKLTと外部のMCU-Linkプローブを使用しています。 デバッグセッションを開始する際にSWD接続が失敗する: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. SWD-DPは正しく検出できます: DPID = 0x6BA02477 しかし、CPU0 AHB-AP(AP0)へのアクセスは以下の場合に失敗します: WIRE ACK FAULT デバッグ用メールボックスのリクエストも失敗します。LinkServer のレポート: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 確認した内容: SWD周波数は1MHzから10kHzまでテスト済み。 SWDIOとSWCLKの波形はオシロスコープ上で良好に見える。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDCおよびI/O電源 = 3.3V RESET_Bは正しく動作します MCU-Linkファームウェア:CMSIS-DAP V3.172 LinkServer バージョン: 26.5.59 同じMCU-LinkはMCXN947開発ボードで動作します MCXN547は新しいチップに交換されたが、問題は解決していない。 USB ISPはVID/PID 1FC9:014Fで正しく動作します。blhostを使えば、以下ができます: 内部フラッシュを消す 内部フラッシュのプログラムと読み取り アプリケーションを正常に実行してください アプリケーションのUSBコンポジットデバイスを列挙します ROMの報告によると、 Security State = UNSECURE USB ISP経由でPFRも読み取りました。 CMPAは完全に消去されました(0xFF) CFPAはROMで生成されたCMACを除いて消去されます。 お客様向けのSOCUやデバッグ認証の設定は存在しません 何かアドバイスをいただけますか: AP0とAP2が利用可能になるには、どのような条件が必要ですか? DM-APステータス0x60F93638は、既知の電源、リセット、またはハードウェア構成の問題に関連していますか? SWDやDebug Mailboxへのアクセスに関する既知のMCXN547エラタはありますか? この症状を確認するには、どの電源信号とリセット信号をチェックすればよいでしょうか? MCX N
記事全体を表示
如何选择微控制器?需要使用编码器控制3个电机进行位置控制。 我希望使用步进电机或无刷直流电机(+驱动器或电调)来控制负载(假设约为 3 公斤)在 xyz 轴上的位置。我还想添加编码器或一些传感器用于反馈回路。 基于此,我很难选择合适的微控制器。我当时考虑的是STM32或者ESP32作为品牌。它需要 3 个 PWM 输出信号(因为有 3 个电机),但我如何知道其他方面是否足够,例如时钟频率、是否需要外部元器件等等? Re: How to choose a microcontroller? Need to control 3 motors with encoders for position control. 嗨@pekoms 对于 MCX 选择,本项目建议首先选择 MCX A34x / A344–A346。它是最适合三轴电机控制的 MCX,因为它具有 180 MHz Cortex-M33、两个 FlexPWM/eFlexPWM 模块、多个 PWM 输出、ADC、定时器和两个用于编码器反馈的硬件正交解码器模块。 目录浏览还发现 MCX N94x 和 MCX A34x 是此类任务的主要高端 MCX 候选产品。 BR 哈里
記事全体を表示
Gui_Guider may freeze when generating C code. After importing the font file, the generated C code keeps getting stuck. Even after I reduced the page to a single size and removed the icons to create a simple interface, it still gets stuck in the "Generating C code" state. Re: Gui_Guider在生成C code时会出现卡死的情况 I found the problem is that when I directly import a new font into Gui_Guider, the Generating C code freezes. How can I solve this problem? 回复: Gui_Guider在生成C code时会出现卡死的情况 Hi @vettle  May I ask what font you imported? Will this problem occur if you change the font? BR Harry
記事全体を表示
Gui_Guider在生成C code时会出现卡死的情况 在导入字体文件后生成C代码会出现一直生成的情况,我将页面缩减成一个,去除图标生成一个简单的界面也会一直卡在Generating C code的情况。 Re: Gui_Guider在生成C code时会出现卡死的情况 我发现原因就是我直接在Gui_Guider里导入一个新的字体然后Generating C code就会出现卡死,我如何解决这个问题? 回复: Gui_Guider在生成C code时会出现卡死的情况 嗨@vettle 请问您导入的是什么字体? 如果更改字体,还会出现这个问题吗? BR 哈里
記事全体を表示
Toolbox workflow 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. Figure 5. Embedded Coder. Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.
記事全体を表示
Battery Management System - Overview 1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion 2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.   3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller. The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior. 4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads 5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator 6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT) 7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.
記事全体を表示
IMX8MPセカンダリイメージブート IMG_CNTN_SET1_OFFSETセカンダリイメージブート(RM 6.1.6.2)は、i.MX8MP上のECSPI("SPI") NORブートで動作しますか、それともFlexSPI NOR(およびSD/eMMC)のみで動作しますか?表6-28では、「SPI」と「FlexSPI NOR」が別々のブートデバイスとして記載されており、セカンダリオフセットの有効値は「FlexSPI NORブートの場合」にのみ記載されています。 Re: IMX8MP secondary image boot こんにちは、 あなたの理解は間違っています。IMG_CNTN_SET1_OFFSETセカンダリイメージブートはSPIデバイスでも動作しますが、オフセットが異なります。 FlexSPI の有効な値は、0、1、2、3、4、5、6、および 7 です。 SPI の場合、ヒューズ値が 10 より大きい場合、セカンダリ ブートは無効になります。n = ヒューズ値が より大きい場合 10. • n == 0: オフセット = 4MB • n == 2: オフセット = 1MB • その他 & n <= 10 : オフセット = 1MB*2^n Re: IMX8MP secondary image boot ありがとうございます。これでオフセットマッピングの問題が解決しました。i.MX8MPボード上で再現するために2つのフォローアップです(ECSPI2でNOR起動、OPEN/非HAB設定、ヒューズ読み取り2 1 = 0 → n=0 → 4MB): ROMがSPI NORのセカンダリイメージに切り替わるトリガーは何ですか?これは無効なプライマリブートヘッダーやイメージ解析失敗、それとも特定のHAB認証失敗なのでしょうか?つまり、セカンダリイメージブートはオープン(非セキュア)構成でも機能するのか、それともデバイスがHABで閉じられている場合にのみ機能するのか? 同じリセット手順にフォールバックするのか、それとも電源のオンオフ/2回目のリセット(永続起動方式)が必要になるのか? 4MBオフセットにあるセカンダリイメージは、別途構築されたブート可能なイメージ(そのオフセット用の独自のIVT/ブートデータ)である必要がありますか、それともプライマリイメージとバイト単位で同一のコピーで十分ですか? Re: IMX8MP secondary image boot i.MX8MPがOPEN(SEC_CONFIG=open、非HAB)構成でECSPI(SPI)NORからブートする場合、IMG_CNTN_SET1_OFFSETセカンダリイメージブートの正確なトリガー条件は何ですか?ROMは無効または消去されたプライマリコンテナヘッダーのセカンダリイメージに切り替わるのか、それともHAB認証失敗時のみ(すなわち(閉鎖/セキュリティ保護された構成の場合のみ)?有効なセカンダリコピーが4MB(fuse n=0)にあり、プライマリヘッダーが消去され、ROMはオープン構成にフォールバックしません。
記事全体を表示
FRDM i.MX93 上的 AP1302 MIPI CSI 流问题 你好, 我使用的是FRDM i.MX93开发板和X-RPI-CAM-MIPI A1摄像头模块。 我遇到的问题是,我无法从此设置中捕获 MIPI CSI 流。 我已将固件二进制文件ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin放置在以下位置:“/lib/firmware” 启动过程中,我看到 AP1302 被成功检测到,但是当我尝试启动视频流时, VIDIOC_STREAMON出现“管道破裂”错误。 以下是相关日志。 内核日志: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected 流媒体测试: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) 请问您能否帮我理解一下为什么VIDIOC_STREAMON会出现“管道破裂”错误? 在成功开始流媒体传输之前,AP1302 固件、设备树、媒体管道或传感器初始化是否需要任何额外的配置? 此外,我目前使用的是“LF_v6.18.2-1.0.0_images_IMX93EVK”预构建镜像。 如果您需要任何其他日志或信息,请告诉我。 感谢您的支持。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 与AE团队讨论。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 你好@yipingwang 感谢您的反馈, 我的回答如下,供您参考。 1. 固件位置 我尝试了推荐的固件安装位置,也尝试了每个位置的单独安装。仅当使用ap1302_ar0144_single_fw.bin时,相机探测才会成功。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw 启动过程中成功检测到 AP1302。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected 但是,我在内核日志中没有看到任何与 AP1302 相关的固件加载消息。 2. 软件环境 我使用的是为FRDM i.MX93板提供的预构建镜像。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302 检测成功,CSI/ISI 设备也存在。我已附上完整的日志供您参考。 3. 媒体管道 媒体管道似乎已正确创建。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctl 的输出显示 AP1302、CSI 和 ISI 实体已启用。完整的 media-ctl 输出结果已附上,供您参考。 4. 补充信息 请参考附件fourth_point.txt文件以获取所需信息。 5. 流媒体播放失败 当流媒体命令失败时,我没有看到任何其他内核消息。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 故障发生后,dmesg 输出仍然为空,因此没有额外的内核日志可以帮助确定根本原因。 由于 AP1302 已被成功检测到,媒体图也已正确创建,并且在 VIDIOC_STREAMON 期间没有报告任何内核错误,请问我应该执行哪些额外的检查或调试步骤来确定为什么流媒体播放失败并出现“管道破裂”错误? 感谢您的支持。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] 此致, 米拉夫 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302 探测成功并不能保证整个摄像机管道已配置完毕并开始传输。在 i.MX93 上,VIDIOC_STREAMON 返回 -1(管道破裂)通常意味着媒体管道元器件之一(AP1302 → MIPI CSI-2 接收器 → ISI 捕获路径)未能启动或协商有效流。您的日志仅确认检测到了 AP1302 I²C 设备: ap1302 2-003c:检测到 AP1302 版本 0.2.6 但这并不能证实这一点: 固件加载成功。 使用了正确的DTB。 媒体关系图已创建完成。 CSI接收器锁定到传入的MIPI数据, AP1302 已配置为匹配的输出格式。 首先我会检查:固件位置/名称 关于 FRDM-i.MX93 AP1302 支持,NXP 文档指出: 下载 ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin 将其重命名为ap1302.fw 放入: /lib/firmware/imx/camera/ap1302.fw 不仅仅是 /lib/firmware。 请核实: ls -l /lib/firmware/imx/camera/ap1302.fw 并检查启动日志: dmesg | grep -i 固件 dmesg | grep -i ap1302 查找类似这样的消息: 请求固件 固件已加载 固件加载失败 第二步:你使用的是正确的DTB吗? 版本说明表明 AP1302 支持与 i.MX93 EVK 设备树支持相关。 检查: cat /proc/device-tree/model cat /proc/cmdline 并确定实际加载的 DTB。 另请查看: dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 第三项检查:验证介质拓扑结构 在尝试使用 v4l2-ctl 之前,请先验证媒体图是否存在: shell media-ctl -p 显示更多行 您应该会看到类似以下的实体: ap1302 CSI 伊西 videoX 如果 /dev/media0 不存在,则相机管道创建不正确。一个非常相似的FRDM-i.MX93 AP1302案例显示: media-ctl -p 枚举 /dev/media0 失败 这表明媒体管道尚未实例化。 请检查: ls -l /dev/media* 第四项检查:检查协商好的格式 运行: v4l2-ctl --list-devices 以及 v4l2-ctl -d /dev/video0 --all 另外: media-ctl -p AP1302 固件通常输出处理后的 YUV 格式,而不是 RAW Bayer 格式。另一个常见的故障是: AP1302 输出格式 A ISI 配置为 B 格式 导致流媒体启动失败。格式不匹配通常表现为 STREAMON 故障或 CSI 管道错误。 第五项检查:在 STREAMON 期间检查 CSI 错误 打开另一个终端并进行监测: dmesg -w 然后运行: v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 查找类似这样的消息: CSI超时 帧开始超时 未收到任何数据 先进先出溢出 MIPI错误 链接未启用 这些信息通常会揭示管道破裂的真正原因。
記事全体を表示
割り込みを有効にせずにDMAでLPI2Cペリフェラルを使うにはどうすればいいですか? こんにちは、 私は NXP S32K396 MCU を扱っており、 割り込みを有効にせずにeDMAを使ってLPI2Cマスタートランザクションを実行したいと考えています。私のプロジェクトでは LPI2C1ペリフェラルを使っています。 以下の割り込みが有効であれば、DMAを使ってLPI2Cの読み書きトランザクションを正常に実行できます: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn しかし、RTD LPI2C DMAの実装はこれらの割り込みに依存しているようです。 Lpi2c_Ip_MasterSendData()では、LPI2Cマスター割り込みは常にドライバによって有効化されます: さらに、Lpi2c_Ip_MasterTxDmaConfig() および Lpi2c_Ip_MasterRxDmaConfig() によって TX および RX 用に構成された DMA TCD は、常に DMA メジャーループ完了割り込みを有効にします。 Lpi2c_DmaTransferList[9u]. Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT ; Lpi2c_DmaTransferList[9u]。値= 1U; また、別の関数であるLpi2c_Ip_MasterSendDataBlocking()では、LPI2C転送用のDMA TCDが設定されていないようです。 DMAを使ってLPI2Cの送受信トランザクション全体を行い、DMAを無効にし、eDMAチャネル割り込みを無効にLPI2C1_IRQnしたいと考えています。   可能であれば、NXPが LPI2CとDMAの両方の割り込みを無効にした状態でDMAを使用するLPI2CマスターTX/RXの例を提供していただけますか?   MCU:NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   どんなご支援でも大変ありがたく思います。どうぞよろしくお願いいたします! 必要なら、プロジェクトを添付できます。 Re: How to use LPI2C peripheral with DMA without enabling any interrupts? こんにちは@rkhw 現在のドライバ実装では、「Lpi2c_Ip_MasterSendData()」は転送完了と状態処理のためにLPI2Cマスター割り込みとDMAメジャーループ完了割り込みの両方に依存しています。 したがって、割り込みを有効にしなければDMAを有効にすることはできません。RTDドライバーはこの使用をサポートしていません。
記事全体を表示