Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32G3 LLCE LIN マスターが「フレームタイムアウトを無効にする」がチェックアウトされているときにRx応答が欠けています NXPのエキスパートの皆様、こんにちは。 現在、S32G3(LINマスターとして動作)でLLCEコンポーネントを使ったLIN実装に取り組んでいます。私たちはS32G_LLCE_1_0_10を使用しています。 LLCE LINファームウェアのフレームタイムアウト構成に関して奇妙な挙動に遭遇しており、ファームウェアのブラックボックスロジックについて内部の詳細や説明を求めたいと思います。 問題の説明: LINチャネルを「Disable Frame Timeout」がUNCHECK(タイムアウト検出が有効)に設定し、Response Timeout値を14に設定した場合: LLCE LINマスターはヘッダー(ブレーク+同期+PID)をバスに正常に送信します。 スレーブノードはヘッダーを受信し、正しいデータとチェックサムを即座に返信します。 しかし、LLCEのLINマスターはランダムまたは継続的にデータの取得・受信に失敗します。データがLLCEファームウェアによって失われたり、破棄されたりしたかのように動作します。 回避策が見つかりました: 他のすべてのハードウェアおよび物理バス環境をまったく同じに保ったまま、設定ツールで「フレームタイムアウトを無効にする」(ファームウェアの内部タイムアウトロジックを無効にする)にチェックを入れるだけで次のようになります。 マスターはデータを一切ドロップせず、スレーブからのすべての応答を正常に受信します。 私たちの質問: LLCE_firmware_user_guide.pdfには内部ステートマシンに関する情報が非常に限られているため、この動作に困惑しています。 LLCEファームウェア内部では、タイムアウト値「14」はどのように正確に計算されるのですか?値14は、特定のGPT/タイマークロックソースに関連する絶対マイクロ秒、ビット時間、またはサイクルを表しますか? 奴隷が即座に返答したにもかかわらず、なぜ主人はその反応を捉えられないのか?タイムアウトカウンターが早すぎる(例えばヘッダーの送信が終わる前)に始まっている可能性はありますか?それとも「14」という閾値が内部ハードウェアやファームウェアのレイテンシのために小さすぎるのでしょうか? 有効な応答を破棄することなくフレームタイムアウト保護を有効にしたままにしたい場合、このタイムアウト値を適切に計算して設定するための推奨される方法はありますか? LLCE LINファームウェアの内部タイミングロジックに関するドキュメントやアプリケーションノート、洞察があれば大変ありがたいです。 よろしくお願いいたします! よろしくお願いします、 cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご説明ありがとうございます。 1.DisableFrameTimeoutボックスにチェックを入れると、Linドライバーは最大フレーム長より長いフレームを受け入れます。 2. 「LinResponseTimeout」の場合、リセット値は0Eh = 14で、これはT_Response_Maximum = 1.4 x T_Response_Nominalに対応します。これは1バイトの応答タイムアウト時間(ビット時間)です。 BR チェイン   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん 迅速なご対応ありがとうございます。ご質問への回答と、ファームウェアのバージョンに関する訂正事項を以下にご説明いたします。 ハードウェア:弊社では、NXPの公式リファレンスボードではなく、S32G3をベースにしたカスタムボードを使用しています。 実装:公式のサンプルを直接実行しているわけではありません。これは当社独自の実装ですが、NXPの公式サンプルコードを参考に開発されています。 ファームウェアバージョンの訂正:最初の投稿でバージョンに関して間違いがあったことに気づきました。実際にはS32G_LLCE_1_0_10ではなく、S32G_LLCE_1_0_09を使用しています。 バージョン1.0.09のLIN応答タイムアウトに関連する既知のバグや、この特定のファームウェアバージョンでタイムアウト値「14」がどう解釈されるか確認を手伝ってもらえますか? よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq 投稿ありがとうございます。 1. NXPのS32G3ベースのカスタムボード、またはリファレンスボードのどちらをお使いでしょうか? 2. この問題は、お客様独自の実装で発生したものですか、それともNXPが提供するサンプルで発生したものですか? BR チェイン Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん ご説明いただきありがとうございます。アプリケーションでDisableFrameTimeoutをチェックし続けることに決めたため、特定のタイムアウト計算は問題になりません。 ただし、DisableFrameTimeoutが有効になっている場合のファームウェアの状態マシンに関する特定の動作について確認しておきたいと思います。 LINマスターがヘッダーを送信し、スレーブが応答しない場合、Lin_GetStatus()を呼び出すとチャネルがLIN_TX_BUSY状態に永久に 固定 されます。 この構成において、LIN_TX_BUSY状態が永続的に続くのは、LLCEファームウェアの想定される正常な動作なのでしょうか? フレームタイムアウトロジックが完全に無効になっているため、内部ステートマシンは応答データを無期限に待ち続け、ビジー状態から自動的に移行することはないだろうと私は推測します。自分の理解が公式設計と一致しているか確認したいだけです。 よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご返信ありがとうございます。 フレームタイムアウトが無効でスレーブ応答がない場合、状態機械LLCE_LIN応答完了イベントもタイムアウトイベントも受け取らないため、問題が生じます。したがって、応答なし検出が必要な場合はフレームタイムアウトを有効にするか、LINチャネルを中止・再初期化するアプリケーションレベルのタイムアウトを実装してください。 BR チェイン
View full article
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 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 你好,路易斯, 现在我们已经能够使用 SPSDK 调试邮箱工具建立 SWD 调试连接。 我们采用的步骤如下: 1. 通过调试邮箱重置MCU: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ 工具 RESET -f mcxn547 2. 通过调试邮箱启动调试会话: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. 调试会话打开后,我们通过 SWD 使用 LinkServer 连接到 Cortex-M33 内核。 我们没有使用任何身份验证密钥、密码、调试凭据或批量擦除命令。“start-debug-session”命令似乎通过始终可访问的 AP2 调试邮箱暂时启用 AP0。 在打开调试会话后,我们还使用了 NXP LS_preconnect_MCXN5XX.scp 脚本中的 GDET 寄存器序列。该序列禁用 aGDET 和 dGDET 复位路由,并在调试期间禁用 SPC 毛刺检测。 关于电源方面: - VDD_VBAT 直接连接到 VDD,两者均为 3.3 V。 - VDD_P4 直接连接到 VDD,两者均为 3.3 V。 - VDD_ANA 通过铁氧体磁珠连接到 VDD。 - VDD 为 3.3 V。 但是,我们现在又遇到了另一个调试问题。 当电路板正常上电且未进行 SWD 调试复位时,固件运行正常。但是,当我们使用上面描述的调试邮箱重置程序进入调试会话时,固件无法正确启动。 单步执行以下 SDK 函数时,调试连接丢失: static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base, spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(电压等级); } 更具体地说,当写入 ACTIVE_CFG 以更改运行模式 DCDC 电压等级时,连接会丢失。 因此,以下两种情况下的行为有所不同: 1. 冷启动: 固件启动并正常运行。 2. 重置调试邮箱,然后启动调试会话并建立 SWD 连接: 固件到达 SPC DCDC 配置,但写入 ACTIVE_CFG 时调试器丢失目标,应用程序无法正常启动。 与完全上电RESET相比,调试邮箱RESET是否会使 SPC、DCDC、GDET 或 RESET状态处于不同的状态? 启动调试邮箱调试会话后,修改 SPC ACTIVE_CFG 是否有必要的步骤?例如: - 等待 SPC_SC[BUSY] 清除; - 清除 SPC 或 GDET 状态标志; - 解锁或禁用故障检测; - 使用特定的重置类型; - 避免在启动调试会话后进行软复位; 或者应用完整的 LS_preconnect_MCXN5XX.scp 序列? 在调试过程中写入 DCDC 电压等级是否会触发 GDET 事件、DCDC 保护事件、欠压 RESET 或其他系统 RESET? 另外,请告知在写入 ACTIVE_CFG 之前应该立即捕获哪些寄存器。我们可以为 SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS 和调试邮箱 CSW 等寄存器提供值。 顺祝商祺! Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 这可真是个难题!调试连接问题可能非常令人沮丧,尤其是在使用定制电路板时。“线路确认故障”肯定表明通信出现故障。您尝试过不同的SWD时钟速度,或者在调试过程中检查MCU的电源,有没有取得什么进展?有时,电力供应不足会导致这类间歇性故障。这让我想起了在《雪地骑士 3D》中追求完美滑行的感觉——一个小小的失误就可能让一切功亏一篑!希望你尽快查明真相!
View full article
IMXRT LPUART non-blocking transfer API makes error handling difficult Hi, I've been looking at the "transfer" API for LPUART, for interrupt-based non-blocking transfers.  It seems to do a decent job of wrapping all the "happy case" handling of LPUART interrupts, etc, and providing a good high level API for just receiving data when it's ready (i.e. handling IDLE, RX ready, TX complete, etc).  However, it makes handling UART errors very difficult.  There is no error handling inside the LPUART_TransferHandleIRQ function, and just after that function in fsl_lpuart.c is a bogus empty LPUART_TransferHandleErrorIRQ containing a comment "To be implemented by the user".  This looks completely half-baked. The only way to actually handle UART errors seems to be to override the default LPUARTx_IRQHandler functions so that instead of calling LPUARTx_RX_DriverIRQHandler (or TX), you'd have to call your own function that handles errors and passes on "happy case" interrupts to the original LPUARTx_RX/TX_DriverIRQHandler so it can call into LPUART_TransferHandleErrorIRQ. In addition you'd have to enable those error interrupts yourself outside the transfer API by calling LPUART_EnableInterrupts, and in your error handling also call LPUART_DisableInterrupts and deal with clearing them, etc. This seems like a lot of extra hassle to handle errors.  Why is this not baked into the transfer API itself? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, Thank you for the detailed feedback. I understand that the SDK could be a little ambiguous since these are intended to provide a common use cases for each peripheral functionality. We are constantly working to improve our APIs thanks also of recommendations like this. Thank you for the recommendations, and we hope that LPUART's error handling will be implemented in future releases. On the other hand, could you please let me know which specific error conditions you are interested in handling and which device you are using? With that information, I can suggest documentation related to those error conditions that may help with your implementation. BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, I understand that this may require additional development time, sorry for that, we continuing working to improve our SDKs. As a reference, you may review the following structure of the SDK (version 26.6) function called "LPUART_TransferHandleIRQ" and implement a similar recovery flow as your application requires. BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult All possible errors.  This applies to pretty much all peripherals (SPI, I2C, etc) that have a transfer API but no error handling.  LPUART on IMXRT1172 specifically has framing, parity, and noise errors that aren't handled.  Unfortunately right now all these peripherals require some hacking to handle errors when using the transfer API.  I had to override the actual default IRQ handlers to check for errors before calling the SDK handler. Thanks, -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, Please let me know if you have any further questions. BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Yes, I've already implemented something similar.  Thanks for sending that.
View full article
IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 考えられるすべてのエラー。これは、転送APIはあるがエラー処理がないほぼすべてのペリフェラル(SPI、I2Cなど)に当てはまります。IMXRT1172のLPUARTには、特にフレーミングエラー、パリティエラー、ノイズエラーがあり、これらは適切に処理されていません。残念ながら現状、これらのペリフェラルは転送API使用時のエラー処理にハッキングが必要です。SDKハンドラーを呼び出す前に、エラーを確認するために実際のデフォルトのIRQハンドラをオーバーライドしなければなりませんでした。 ありがとうございます -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 追加の開発期間が必要になる可能性があることは理解していますが、SDKsの改善に引き続き取り組んでいます。参考として、SDK(バージョン26.6)の関数「LPUART_TransferHandleIRQ」の構造を確認し、アプリケーションが必要とする類似の回復フローを実装できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult はい、既に似たようなものを実装しています。送っていただきありがとうございます。
View full article
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 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT こんにちは、ルイスさん。 SPSDKデバッグメールボックスツールを使用して、SWDデバッグ接続を確立することができました。 私たちが用いた手順は以下のとおりです。 1. デバッグメールボックスを通じてMCUをリセットする: NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ ツールリセット -f mcxn547 2. デバッグメールボックスからデバッグセッションを開始します。 NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ cmd -f mcxn547 start-debug-session 3. デバッグセッションが開かれた後、SWD経由でLinkServerを使ってCortex-M33コアに接続します。 認証キー、パスワード、デバッグ認証情報、一括消去コマンドは一切使用しませんでした。「start-debug-session」コマンドは、常時アクセス可能なAP2デバッグメールボックスを介して、一時的にAP0を有効にするようです。 デバッグセッションを開いた後、NXP LS_preconnect_MCXN5XX.scpスクリプトからGDETレジスタシーケンスも使用しました。このシーケンスは、デバッグ中にaGDETおよびdGDETのリセットルーティングを無効にし、SPCグリッチ検出を無効にします。 電源装置に関して: - VDD_VBATはVDDに直接接続されており、どちらも3.3Vです。 - VDD_P4はVDDに直接接続されており、どちらも3.3Vです。 - VDD_ANAはフェライトビーズを介してVDDに接続されています。 - VDDは3.3Vです。 しかし、今度は別のデバッグ問題が発生しました。 SWDデバッグリセットを行わずにボードを通常通り電源投入した場合、ファームウェアは正しく動作します。しかし、上記のデバッグメールボックスリセット手順を使用してデバッグセッションに入ると、ファームウェアが正しく起動しません。 以下のSDK関数をシングルステップで実行するとデバッグ接続が失われます。 static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_タイプ *ベース、 spc_dcdc_voltage_level_t voltageLevel) ヤージュ base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } より具体的に言うと、アクティブモードのDCDC電圧レベルを変更するためにACTIVE_CFGが書き込まれると、接続が失われます。 したがって、以下の2つの場合で挙動が異なります。 1. 電源投入時の冷間状態: ファームウェアは正常に起動し、正常に動作します。 2. デバッグ:メールボックスリセット、続いて開始・デバッグセッションおよびSWD接続: ファームウェアはSPC DCDC構成に到達しますが、ACTIVE_CFGが書き込まれるとデバッガはターゲットを失い、アプリケーションは通常起動できません。 デバッグメールボックスのリセットが、完全な電源オンリセットと異なる状態にしてしまいますか? デバッグメールボックスのデバッグセッションを開始した後、SPC ACTIVE_CFGを変更する前に、必要な手順はありますか?例えば: - SPC_SC[BUSY]がクリアされるのを待っています。 - SPCまたはGDETステータスフラグをクリアする。 - グリッチ検出のロック解除または無効化。 - 特定のリセットタイプを使用する。 - デバッグセッション開始後のソフトリセットを回避する。 または、LS_preconnect_MCXN5XX.scp シーケンス全体を適用する? デバッグ中にDCDC電圧レベルを書き込むと、GDETイベント、DCDC保護イベント、ブラウンアウトリセット、または別のシステムリセットがトリガーされる可能性はありますか? ACTIVE_CFG書き込みの直前に取得すべきレジスタについてもご教示ください。SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS、そしてデバッグメールボックスCSWなどのレジスタの値を提供できます。 よろしくお願いいたします。 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT これは難しい問題だ!接続問題のデバッグは特にカスタムボードの場合非常にフラストレーションが溜まります。その「WIRE ACK FAULT」は、間違いなく通信障害を示しています。異なるSWDクロック速度を試したり、デバッグセッション中にMCUの電源を確認したりしてみましたか?時には限界的な電力供給がこのような断続的な故障を引き起こすことがあります。これは Snow Rider 3D で完璧なランを狙うような感覚を少し思い出させます。ほんの小さなミスで全てが狂ってしまうこともあります!早く真相が解明されることを願っています!
View full article
当“禁用帧超时”未选中时,S32G3 LLCE LIN 主站缺少接收响应 各位NXP专家,大家好! 我目前正在使用 S32G3 上的 LLCE 元器件(作为 LIN 主控运行)进行 LIN 实现。我们正在使用 S32G_LLCE_1_0_10。 我们在 LLCE LIN 固件的帧超时配置方面遇到了奇怪的问题,我想了解一些关于固件黑盒逻辑的内部细节或说明。 问题描述: 配置 LIN 通道时,如果“禁用帧超时”未选中(即启用超时检测),并将响应超时值设置为 14: LLCE LIN 主站成功将报头(中断 + 同步 + PID)发送到总线。 从节点接收到头部信息后,立即返回正确的数据和校验和。 但是,LLCE LIN 主站会随机或持续地无法捕获/接收数据。表现得好像数据被 LLCE 固件丢失或丢弃了一样。 找到解决方法: 如果我们在配置工具中仅勾选“禁用帧超时”(禁用固件的内部超时逻辑),同时保持所有其他硬件和物理总线环境完全相同: 主设备从不丢失任何数据,并成功接收从设备的每一个响应。 我们的问题: 由于 LLCE_firmware_user_guide.pdf 提供的关于内部状态机的信息非常有限,我们对这种行为感到困惑: LLCE固件内部是如何精确计算超时值“14”的?值 14 代表的是绝对微秒、比特时间,还是与特定 GPT/定时器时钟源相关的周期? 为什么即使从设备立即回复,主设备也无法获取响应?超时计数器是否有可能启动过早(例如,在报头传输完成之前),或者由于某些内部硬件/固件执行延迟,“14”作为阈值是否太小? 如果我们想在不丢弃有效响应的情况下保持帧超时保护处于活动状态,那么正确计算和设置此超时值的推荐方法是什么? 任何有关 LLCE LIN 固件内部时序逻辑的文档、应用笔记或见解都将不胜感激。 提前感谢! 此致, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好, @cjq 谢谢你的解释。 1.如果选中“禁用帧超时”框,则 Lin 驱动程序将接受长度超过最大帧长度的帧。 2. 对于“LinResponseTimeout”,重置值为 0Eh = 14,对应于 T_Response_Maximum = 1.4 x T_Response_Nominal。这是 1 字节的响应超时持续时间(以比特时间为单位)。 BR 陈银   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 陈银你好, 感谢您的快速回复。以下是对您问题的解答,以及关于固件版本的更正: 硬件:我们使用的是基于 S32G3 的定制电路板,而不是 NXP 的官方参考电路板。 实现方式:我们没有直接运行官方示例。这是我们自行开发的,但它与 NXP 官方示例代码密切相关,并在此基础上进行了开发。 固件版本更正:我意识到我在最初的帖子中关于版本信息有误。我们实际使用的是S32G_LLCE_1_0_09 ,而不是S32G_LLCE_1_0_10。 请问您能否帮忙检查一下 1.0.09 版本中是否存在与 LIN 响应超时相关的已知错误,或者该特定固件版本是如何解释超时值“14”的? 此致敬礼,cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好, @cjq 感谢分享。 1. 请问您使用的是基于 S32G3 的定制板还是 NXP 的参考板? 2. 该问题是在您的自定义实现中发现的,还是在 NXP 配置的任何示例中发现的? BR 陈银 Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好, @cjq 感谢您的回复。 如果帧超时被禁用且没有从设备响应,由于 LLCE_LIN 状态机既没有收到响应完成事件也没有收到超时事件,因此会出现问题。所以,如果需要检测无响应,请保持帧超时启用,或者实现一个应用程序级别的超时,以中止/重新初始化 LIN 通道。 BR 陈银 Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 陈银你好, 谢谢你的解释。由于我们决定在应用程序中保持 DisableFrameTimeout 选中状态,因此具体的超时计算对我们来说不再是问题。 但是,我想确认启用 DisableFrameTimeout 时固件状态机的一个具体行为: 当 LIN 主设备发送报头而从设备未回复时,调用 Lin_GetStatus() 显示通道永久卡在 LIN_TX_BUSY状态。 在这种配置下,LLCE 固件的这种永久性 LIN_TX_BUSY 状态是否是预期和正常的运行状态? 我推测,由于帧超时逻辑完全被禁用,内部状态机将无限期地等待响应数据,并且永远不会自动退出忙碌状态。我只是想确认一下我的理解是否与官方设计一致。 此致敬礼,cjq
View full article
S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi NXP Experts, I am currently working on the LIN implementation using the LLCE component on S32G3 (running as a LIN Master). We are using S32G_LLCE_1_0_10. We have encountered a strange behavior regarding the Frame Timeout configuration in the LLCE LIN firmware, and I would like to seek some internal details or clarifications about the firmware's black-box logic. Problem Description: When configuring the LIN channel with "Disable Frame Timeout" UNCHECKED (meaning timeout detection is enabled) and setting the Response Timeout value to 14: The LLCE LIN Master successfully transmits the Header (Break + Sync + PID) to the bus. The Slave node receives the Header and responds with the correct Data + Checksum immediately. However, the LLCE LIN Master randomly or constantly fails to capture/receive the data. It behaves as if the data is lost or dropped by the LLCE firmware. Workaround Found: If we simply CHECK "Disable Frame Timeout" (disabling the firmware's internal timeout logic) in the configuration tool while keeping all other hardware and physical bus environments exactly the same: The Master never drops any data and successfully receives every single response from the Slave. Our Questions: Since the LLCE_firmware_user_guide.pdf provides very limited information about the internal state machine, we are confused by this behavior: How is the timeout value "14" precisely calculated inside the LLCE firmware? Does a value of 14 represent absolute microseconds, bit times, or cycles related to a specific GPT/timer clock source? Why does the Master fail to grab the response even when the Slave replies immediately? Is it possible that the timeout counter starts too early (e.g., before the Header finishes transmitting), or is "14" too small a threshold due to some internal hardware/firmware execution latency? What is the recommended way to properly calculate and set this timeout value if we do want to keep the Frame Timeout protection active without dropping valid responses? Any documentation, application notes, or insights into the LLCE LIN firmware's internal timing logic would be highly appreciated. Thanks in advance! Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for your clarification. 1. If DisableFrameTimeout box is checked, then Lin driver will accept the frame that is longer than Maximal Frame Length. 2. For "LinResponseTimeout", the reset value is 0Eh = 14, corresponding to T_Response_Maximum = 1.4 x T_Response_Nominal. This is the response timeout duration (in bit time) for 1 byte. BR Chenyin   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi Chenyin, Thank you for your quick response. Here are the clarifications to your questions, along with a correction regarding the firmware version: Hardware: We are using a custom board based on S32G3, not the official NXP reference board. Implementation: We are not running the official example directly. It is our custom implementation, but it is closely referenced and developed based on the official NXP sample code. Correction on Firmware Version: I realized I made a mistake regarding the version in my initial post. We are actually using S32G_LLCE_1_0_09, not S32G_LLCE_1_0_10. Could you please help check if there are any known bugs related to the LIN response timeout in version 1.0.09, or how the timeout value "14" is interpreted by this specific firmware version? Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for the post. 1. May I know if you are working with a S32G3 based custom board or reference board from NXP? 2. Is the issue found in your custom implementation or from any samples provisioned by NXP? BR Chenyin Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi Chenyin, Thank you for the clarification. Since we have decided to keep DisableFrameTimeout checked for our application, the specific timeout calculation is no longer an issue for us. However, I would like to confirm one specific behavior regarding the firmware's state machine when DisableFrameTimeout is enabled: When the LIN Master transmits a Header and the Slave fails to reply, calling Lin_GetStatus() shows that the channel remains permanently stuck in the LIN_TX_BUSY state. Is this permanent LIN_TX_BUSY state the expected and normal behavior of the LLCE firmware under this configuration? I assume that because the frame timeout logic is entirely disabled, the internal state machine will wait indefinitely for the response data and will never automatically transition out of the busy state. I just want to verify if my understanding aligns with the official design. Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for your reply. With frame timeout disabled and no slave response, since LLCE_LIN state machine receives neither a response-complete event nor a timeout event, there would be issues, so If no-response detection is required, keep frame timeout enabled or implement an application-level timeout that aborts/reinitializes the LIN channel. BR Chenyin
View full article
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.
View full article
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错误 链接未启用 这些信息通常会揭示管道破裂的真正原因。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 在进行捕获之前,需要使用以下命令设置管道。 $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1] $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none] "
View full article
割り込みを有効にせずに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ドライバーはこの使用をサポートしていません。
View full article
フラッシュ消去時にRAM内でピット割り込みが実行されます フラッシュを消している間にタイマー割り込みに入れないことがわかりました。私の要件を満たすために、タイマー割り込みをRAM上で実行する予定です。linker_flash_s32k388.ld ファイルを修正して IntCtrl_Ip.o と Pit_Ip.o を RAM に配置するようにしましたが、フラッシュを消去すると、タイマー割り込みの発生により依然としてエラーが発生します。私が見落としている点があれば教えてください。#s32k388 Re: Pit interrupt runs in ram wen flash erase こんにちは、 IntCtrl_Ip.oとPit_Ip.oを配置するだけでRAMに書き込むだけでは通常は不十分です。PFLASH消去操作中は、CPUは影響を受けたフラッシュアレイへのアクセスを避けなければなりません。 割り込みベクタテーブル、PIT ISR、ISRによって呼び出されるすべての関数、およびISRで使用されるすべてのデータ/定数がSRAMに配置されていることを確認してください。さらに、VTORレジスタがRAMベースのベクタテーブルを指していることを確認してください。リンカーマップファイルは通常、残りのフラッシュアクセスを特定する最良の方法です。 S32K3リファレンスマニュアルには、フラッシュ操作が継続実行を必要とする場合はコード実行をSRAMに移す必要があると記載されています。 よろしくお願いいたします。 ピーター Re: Pit interrupt runs in ram wen flash erase 私のISRとISRが呼び出す関数はRAMに配置されており、VTORのアドレスも0x2...0x4ではなく...RTDの設定時にフラッシュドライバーがRAMで動作するのを選びました。PITが閉じている間は正常に動作しますが、PITを有効にするとフリーズします。ただ、デバッグしても問題の原因を特定できません Re: Pit interrupt runs in ram wen flash erase こんにちは、 説明文だけでは判断しにくい。 見落とされがちなこと: 割り込みベクタテーブルはまだフラッシュメモリに保存されています CPUはまずベクタテーブルからISRアドレスを取得する。 ベクターテーブルがP-Flashに残る場合、割り込みは消去中にFlashにアクセスし続けます。 ベクトルテーブルはRAMにコピーされ、それに応じてVTORが更新される必要がある。 PIT ISR関数自体はRAMに存在しなければならない。 PITドライバ( Pit_Ip.o )だけでなく、アプリケーションのコールバックやISRも含まれます。 ISRから呼び出されるものはすべてRAMに存在しなければならない。 アプリケーション機能 OSサービス スケジューラフック ログ記録/デバッグ機能 ISRによって呼び出されるヘルパー関数 Flashに常駐する定数はありません たとえコードがRAMから実行されていても、以下へのアクセスがあります: const 表 補正データ 文字列リテラル 構成構造は依然としてフラッシュ読み取りを生じさせることがあります。 スタックトレース/デバッグインフラストラクチャによるフラッシュアクセスはありません デバッグビルドでは、予期しないFlash参照が混入することがよくあります。 よろしくお願いいたします。 ピーター
View full article
执行 fls_Erase() 操作期间断电后,数据闪存损坏和 ECC 错误 我们发现,当由于断电/RESET情况导致Fls_Erase()操作中断时,数据闪存会发生损坏。系统重启后,受影响的数据闪存区域似乎已损坏。 在随后尝试使用Fls_Erase()恢复扇区时,当 Flash 驱动程序在执行擦除操作之前尝试访问受影响的地址范围时,会生成 ECC 错误。因此,擦除操作无法成功进行。 我们希望了解闪存控制器在此场景下的预期行为,并请求就以下几点提供指导: 如果在Fls_Erase()操作进行期间断电,数据闪存是否会损坏? 在发生此类中断后,访问部分擦除/损坏的闪存扇区时,是否预期会出现 ECC 错误? 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查,以便擦除和恢复损坏的 Flash 扇区? 断电后,对于包含无法纠正的ECC错误的闪存扇区,推荐的恢复程序是什么? 目标设备: [MPC5746C] 软件栈: [AUTOSAR / 裸机] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation 你好, 如果在Fls_Erase()操作进行期间断电,数据闪存是否会损坏? 是的,这是正确的做法。由于编程/擦除过程中断电,闪存中的数据将与 ECC 纠错码不匹配。 在发生此类中断后,访问部分擦除/损坏的闪存扇区时,是否预期会出现 ECC 错误? 是的。 是否有任何机制或寄存器可以暂时禁用 Flash ECC 检查,以便擦除和恢复损坏的 Flash 扇区? 不,这是硬件的永久性功能。 断电后,对于包含无法纠正的ECC错误的闪存扇区,推荐的恢复程序是什么? 在这种情况下,您需要初始化(擦除)损坏的闪存块。一旦完成 ECC 纠错,闪存中的数据将与 ECC 纠错匹配,访问不会触发 ECC 错误。 有关闪存擦除步骤,请参阅参考手册: 顺祝商祺! Peter
View full article
S32K396的ETPU的例子 您好,我需要一个S32K396的RTD5.0.0用于S32DS3.5中生成的ETPU的demo,然后我想将它用于喷油功能,可以给我一个软件包和代码例子吗 Re: S32K396的ETPU的例子 嗨@大概, 实时驱动程序 (RTD)中已有 ETPU 和 S32K396 的示例: 此外,您可以在S32K3 - eTPU软件包中找到各种示例。它独立于RTD,这意味着可以使用任何版本,但是,eTPU软件仅使用特定的RTD 7.0.0版本进行了验证。版本,且无法保证与其他版本的兼容性。 此致, 朱利安
View full article
S32 Design Studio for ARM v2.2许可延期 あなたは好,S32 Design Studio for ARM v2.2提示許可馬上到期,Activation Code:FAF2-FCC2-8A8E-87AC,麻烦延期,谢谢!
View full article
i.MX 8M Plus LPDDR4 EVK - eMMC boot0/boot1 の有効化 ボード:i.MX 8M Plus LPDDR4 EVK(MIMX8ML8DVNLZAA年)、IMX8MPEVKHUG rev 0 HAB:融合オープン(SRKは意図的に燃焼せず、まだ評価中) 私はRAUCベースのA/B更新システム向けにブートローダーと更新の冗長性を実装しており、eMMCのハードウェアboot0/boot1パーティション(BOOT_PARTITION_ENABLE)を多くのi.MX8M設計のように使いたいと考えています。つまり、新しいブートローダーを非アクティブなブートパーティションに書き込み、どちらがアクティブかを反転させ、新たにアクティブなブートローダーが故障した場合はROMがもう一方にフォールバックする形です。私は特に、このためにBOOT_CFG/efuseを焼却することを避けたいのです。 EVK上で、poky/oe-core mmc-utilsレシピからビルドしたmmc-utilsを使用して観察した結果は以下のとおりです。 - mmc extcsd read /dev/mmcblk2 は PARTITION_CONFIG を報告し、BOOT_PARTITION_ENABLE は既に boot0 (値 0x08) に設定されています。 - boot0 (/dev/mmcblk2boot0) には有効なイメージ (オフセット 0 に正しい IVT タグ) が含まれていますが、現在デプロイされているブートローダーと一致しません。 - boot1 (/dev/mmcblk2boot1) は完全に空です (すべてゼロ)。 - バイト単位の正確な比較により、ボードは実際には標準の32 KiBオフセットで生のeMMCユーザーエリアから起動していることが確認できます(コンテンツは現在デプロイしているimx-bootと完全に一致します)。boot0から起動しているわけではありません。boot0が有効であることを示すPARTITION_CONFIGもあります。 このボードでは、EXT_CSDのBOOT_PARTITION_ENABLEはROMの実際のブートソースに影響を与えていないようです。IMX8MPEVKHUG 2.2節によると、EVKのSW4スイッチは粗いブートデバイスクラス(eMMC、SD、QSPI、NAND、ヒューズ、USBシリアルダウンロード)のみを選択し、eMMCブートパーティションサブモードのスイッチ位置は存在しません。 質問: 1. LPDDR4 EVK上で「eMMC boot0/boot1ハードウェアパーティションからのROMブート」を特に選択する方法は、BT_FUSE_SEL=1設定やBOOT_CFGエフューズの焼却なしに選択できるサポート方法はありますか?例えば、ジャンパー、抵抗オプション、またはrev 0に記載されていない代替のSW4/SW1101の組み合わせなどIMX8MPEVKHUG?それとも、このボードのPCBにハードストラップされていて、状態に関係なく常にeMMCユーザーエリアから起動するようにEXT_CSD? 2. BOOT_CFG efuseがeMMCブートパーティションモードを有効にする唯一の方法である場合、これを制御するBOOT_CFGヒューズバンクは、HABに使用されるSRKハッシュヒューズとは独立していますか?ヒューズを介してeMMCブートパーティションの冗長性を有効にすると、同時にHAB(SRK書き込み)を終了する必要が生じるのか、それともこれらは別々の決定事項なのかを理解したい。 3. i.MX 8M PlusとeMMCを使ったカスタムボード設計(EVKではありません)の場合、eMMCのboot0/boot1冗長性を最初の起動時から利用可能にする推奨方法は何でしょうか?つまり、BOOT_CFG GPIOのストラップやPCB設計において、後でヒューズのコミットメントを必要としないよう、初日の選択肢として何が真であるべきか? また、eMMCブートパーティション選択のBOOT_CFGビット定義(IMX8MPEVKHUGで既に扱われているSW4デバイスクラスビット以外)を扱ったリファレンスマニュアルのセクションへの指し印も教えていただけると助かります。 ご回答をお待ちしています。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 i.Mx8 UMに関する参考までに、第5章の第5.8.2.2.1章「高レベルeMMCブートフロー」 SCU ROMは4つのeMMCブートシナリオをサポートします: 1.このシナリオでは、「eMMC高速ブート」ヒューズが切れています。一次および二次 イメージコンテナセットは両方ともブートパーティション内にあり、BOOT_PARTITION_ENABLE = 1 または 2 です。 2. このシナリオでは、「eMMC 高速ブート」ヒューズが切れています。小学校と中学校 イメージコンテナセットはどちらもユーザーエリアにあり、BOOT_PARTITION_ENABLE=7です。 3.このシナリオでは、「eMMC高速ブート」ヒューズは切れません。起動モードはノーマルです Bootとプライマリおよびセカンダリイメージコンテナセットはどちらもユーザーエリアにあります。 4. この場合、「eMMCファストブート」ヒューズは 切れていません。起動モードは通常です ブート、プライマリおよびセカンダリイメージコンテナセットは両方ともブート内にあります パーティション、および BOOT_PARTITION_ENABLE = 1 または 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 アドバイスありがとうございます。ただ、第5.8.2.2.1章で別のチップファミリが説明されていると思います。「SCU ROM」eMMCブートフローは、専用のシステムコントローラユニット(Cortex-M4ブートサブシステム)を持つi.MX8QuadMax/QuadXPlus/DualXPlus専用です。i.MX8M PlusにはSCUがなく、起動ROMはCortex-A53上で直接動作するため、その章の BOOT_PARTITION_ENABLE=1/2/7 シナリオはここでは当てはまりません。 i.MX8M Plusの場合、冗長性はi.MX8M Plusリファレンスマニュアル(図6-1)のプライマリ/セカンダリイメージ機構で処理されているようです。ROMはBT_FUSE_SEL/BOOT_CFGで選択したデバイスから起動し、故障時には同じブートデバイス上でIMG_CNTN_SET1_OFFSETヒューズオフセットのセカンダリイメージにフォールバックします。 別々のboot0/boot1パーティションではありません。これはLPDDR4 EVKで見ているものと一致します。BOOT_PARTITION_ENABLE=1はEXT_CSDに設定されていますが、ROMはそれを無視し、生のユーザーエリアのオフセットから起動します。 そこで、私の質問はi.MX8M Plusに限定されました: 1. LPDDR4のEVK(ジャンパー、抵抗、または非公式のSW1101/SW4位置)でeMMC boot0/boot1をブートソースとして選択する方法はありますか?それとも純粋にストラップやBT_FUSE_SELの判断BOOT_CFGに過ぎませんか? 2. BOOT_CFGヒューズバンクはHABのSRKハッシュヒューズとは独立しているのか、それともBOOT_CFGヒューズ経由のコミットもHABのクロージングを強制するのか? 3.カスタムボード設計の場合、レイアウト時にハードウェアのブートパーティション冗長性を後でヒューズに縛り付けずに維持するために、どのようなBOOT_CFGものが必要ですか? もし私が第5.8.2.2.1章のどの部分に適用されるのかを誤解しているようでしたら、ご指摘いただければ幸いです。
View full article
Example of an ETPU based on S32K396 Hello, I need a demo of RTD 5.0.0 for S32K396 used in an ETPU generated by S32DS3.5. I want to use it for fuel injection functionality. Could you provide a software package and code examples? Re: S32K396的ETPU的例子 Hi @大概, There is an existing example for ETPU & S32K396 inside the Real-Time Drivers (RTD): Additionally, you can find various examples inside the S32K3 - eTPU SW package. It is independent from RTDs, meaning any version can be used, however, the eTPU SW has been validated only with the specific RTD 7.0.0 version, and compatibility with other versions cannot be guaranteed. Best regards, Julián
View full article
Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation We are observing Data Flash corruption when a Fls_Erase() operation is interrupted due to a power abort/reset condition. After the system restarts, the affected Data Flash region appears corrupted. During a subsequent attempt to recover the sector using Fls_Erase(), ECC errors are generated when the Flash driver tries to access the affected address range before performing the erase operation. As a result, the erase operation cannot proceed successfully. We would like to understand the expected behavior of the Flash controller in this scenario and request guidance on the following points: Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? Target Device: [MPC5746C] Software Stack: [AUTOSAR / Bare Metal] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation Hello, Is Data Flash corruption expected if power is lost during an ongoing Fls_Erase() operation? Yes, that is correct behavior. As data in flash will not match ECC syndromes in flash due to power loss during programming / erase process. Are ECC errors expected when accessing a partially erased/corrupted Flash sector after such an interruption? Yes. Is there any mechanism or register available to temporarily disable Flash ECC checking so that the corrupted Flash sector can be erased and recovered? No. It is permanent HW feature. What is the recommended recovery procedure for handling Data Flash sectors that contain uncorrectable ECC errors following a power interruption? You need to initialize (erase) the corrupted flash block in such case. Once done ECC syndrome will match the data in flash and access wont trigger ECC faults. For flash erase procedure please refer to reference manual: Best regards, Peter
View full article
i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Board: i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB: fused OPEN (SRK not burned, deliberately, still evaluating) I am implementing bootloader-update redundancy for a RAUC-based A/B update system and want to use the eMMC's hardware boot0/boot1 partitions (BOOT_PARTITION_ENABLE) the way many i.MX8M designs do — write the new bootloader to the inactive boot partition, flip which one is active, and rely on the ROM to fall back to the other if the newly-active one fails. I specifically want to avoid burning any BOOT_CFG/efuses for this. What I have observed on the EVK, using mmc-utils built from the poky/oe-core mmc-utils recipe: - mmc extcsd read /dev/mmcblk2 reports PARTITION_CONFIG with BOOT_PARTITION_ENABLE already set to boot0 (value 0x08). - boot0 (/dev/mmcblk2boot0) contains a valid-looking image (correct IVT tag at offset 0), but it does not match my currently deployed bootloader. - boot1 (/dev/mmcblk2boot1) is completely empty (all zero). - A byte-exact comparison confirms the board is actually booting from the raw eMMC user area at the standard 32 KiB offset (content matches my currently deployed imx-boot exactly) — not from boot0, despite PARTITION_CONFIG indicating boot0 is enabled. So on this board, EXT_CSD's BOOT_PARTITION_ENABLE appears to have no effect on the ROM's actual boot source. Per IMX8MPEVKHUG section 2.2, the EVK's SW4 switch only selects the coarse boot device class (eMMC vs SD vs QSPI vs NAND vs fuses vs USB serial download) — there is no switch position for the eMMC boot-partition sub-mode. Questions: 1. Is there a supported way to select "ROM boots from eMMC boot0/boot1 hardware partition" on the LPDDR4 EVK specifically, without setting BT_FUSE_SEL=1 / burning BOOT_CFG efuses — e.g. a jumper, resistor option, or alternate SW4/SW1101 combination not documented in IMX8MPEVKHUG rev 0? Or is this hard-strapped on this board's PCB to always boot from the eMMC user area regardless of EXT_CSD state? 2. If BOOT_CFG efuses are the only way to enable eMMC boot-partition mode: are the BOOT_CFG fuse banks that control this independent of the SRK-hash fuses used for HAB? I want to understand whether enabling eMMC boot-partition redundancy via fuses would force me to also commit to closing HAB (SRK burn) at the same time, or whether these are separable decisions. 3. For a custom board design (not the EVK) using the i.MX 8M Plus with eMMC, what is the recommended way to make eMMC boot0/boot1 redundancy available from first bring-up — i.e., what needs to be true in the BOOT_CFG GPIO strapping / PCB design so this is a day-one option rather than something that requires a later fuse commitment? Any pointers to the specific Reference Manual section covering the BOOT_CFG bit definitions for eMMC boot-partition selection (beyond the SW4 device-class bits already covered in IMX8MPEVKHUG) would also be appreciated. Thank you! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 FYI for i.Mx8 UM at chapter 5.8.2.2.1 High Level eMMC Boot Flow The SCU ROM supports 4 eMMC boot scenarios: 1. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. 2. In this scenario, the "eMMC fast boot" fuse is blown. The primary and secondary image container set are both in the User Area, and BOOT_PARTITION_ENABLE =7. 3. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the User Area. 4. In this scenario, the "eMMC fast boot" fuse is not blown. The boot mode is Normal Boot, and the primary and secondary image container set are both in the boot partitions, and BOOT_PARTITION_ENABLE = 1 or 2. Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 Thanks for the pointer — though I believe chapter 5.8.2.2.1 describes a different chip family. The "SCU ROM" eMMC boot flow is specific to the i.MX8QuadMax/QuadXPlus/DualXPlus, which have a dedicated System Controller Unit (separate Cortex-M4 boot subsystem). The i.MX8M Plus has no SCU — its boot ROM runs directly on a Cortex-A53 — so the BOOT_PARTITION_ENABLE=1/2/7 scenarios in that chapter don't apply here. For i.MX8M Plus, redundancy appears to be handled via the Primary/Secondary Image mechanism in the i.MX8M Plus Reference Manual (Figure 6-1): the ROM boots from the device selected by BT_FUSE_SEL/BOOT_CFG, and on failure falls back to a Secondary Image at the IMG_CNTN_SET1_OFFSET fuse offset — on the same boot device, not a separate boot0/boot1 partition. This matches what I'm seeing on the LPDDR4 EVK: BOOT_PARTITION_ENABLE=1 is set in EXT_CSD, but the ROM ignores it and boots from the raw user-area offset regardless. So my questions remain, scoped to i.MX8M Plus: 1. Is there any non-efuse way on the LPDDR4 EVK (jumper, resistor, or undocumented SW1101/SW4 position) to select eMMC boot0/boot1 as the boot source, or is that purely a BOOT_CFG strap/BT_FUSE_SEL decision? 2. Are the BOOT_CFG fuse banks independent of the SRK-hash fuses for HAB, or does committing to BOOT_CFG-via-fuse also force HAB closure? 3. For a custom board design, what BOOT_CFG strapping is needed at layout time to keep hardware boot-partition redundancy available without a later fuse commitment? Happy to be corrected if I'm misreading which part chapter 5.8.2.2.1 actually applies to.
View full article
Fls_Erase() 操作中の電源中断後のデータフラッシュ破損および ECC エラー 電源の中断/リセットによってFls_Erase()操作が中断された場合、データフラッシュの破損が発生することを確認しています。システムを再起動すると、影響を受けたデータフラッシュ領域が破損しているように見える。 その後、セクターを Fls_Erase()で復旧しようとする際、フラッシュドライバが消去操作を行う前に影響を受けたアドレス範囲にアクセスしようとした際にECCエラーが発生します。その結果、消去作業は成功裏に進められません。 このシナリオにおけるフラッシュコントローラの期待される挙動を理解し、以下の点についての指針をお願いしたいと思います。 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか? このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか? ターゲット装置: [MPC5746C] ソフトウェアスタック: [AUTOSAR / ベアメタル] Re: Data Flash Corruption and ECC Errors After Power Abort During Fls_Erase() Operation こんにちは、 Fls_Erase()操作の実行中に電源が切断された場合、データフラッシュの破損が発生する可能性はありますか? はい、それは正しい行動です。フラッシュメモリ内のデータは、プログラミング/消去処理中の電源喪失により、フラッシュメモリ内のECC症候群と一致しなくなります。 このような中断後に部分的に消去・破損したフラッシュセクターにアクセスする際にECCエラーが起こることは予想されますか? はい。 破損したフラッシュセクターを消去・復元するために 、フラッシュECCチェックを一時的に無効 化する仕組みやレジスタはありますか? いいえ。これは恒久的なハードウェア機能です。 電源遮断後に訂正不可能なECCエラーを含むデータフラッシュセクターを処理するための推奨される復旧手順は何ですか? その場合は破損したフラッシュブロックを初期化(消去)する必要があります。一度実行すると、ECC症候群はフラッシュのデータと一致し、アクセスによってECCの故障が起きません。 フラッシュ消去の手順については、リファレンス・マニュアルをご参照ください: よろしくお願いいたします。 ピーター
View full article
i.MX 8M Plus LPDDR4 EVK - 启用 eMMC boot0/boot1 主板:i.MX 8M Plus LPDDR4 EVK (MIMX8ML8DVNLZAA), IMX8MPEVKHUG rev 0 HAB:熔断 OPEN(SRK 未烧毁,故意,仍在评估中) 我正在为基于 RAUC 的 A/B 更新系统实现启动加载程序更新冗余,并希望像许多 i.MX8M 设计那样使用 eMMC 的硬件 启动0/启动1 分区(BOOT_PARTITION_ENABLE)——将新的启动加载程序写入非活动启动分区,切换哪个分区处于活动状态,并依靠 ROM 在新激活的分区发生故障时回退到另一个分区。我特别想避免为此烧毁任何 BOOT_CFG/efuse。 我在 EVK 上使用基于 poky/oe-core mmc-utils 配方构建的 mmc-utils 时观察到以下情况: - mmc extcsd 读取 /dev/mmcblk2 报告 PARTITION_CONFIG 中 BOOT_PARTITION_ENABLE 已设置为 boot0(值为 0x08)。 - boot0 (/dev/mmcblk2boot0) 包含一个看起来有效的映像(偏移量 0 处有正确的 IVT 标签),但它与我当前部署的引导加载程序不匹配。 - boot1 (/dev/mmcblk2boot1) 完全为空(全部为零)。 - 逐字节比较证实,该板实际上是从标准的 32 KiB 偏移处的原始 eMMC 用户区启动(内容与我当前部署的 imx-boot 完全匹配)——而不是从 boot0 启动,尽管 PARTITION_CONFIG 指示 boot0 已启用。 因此,在这个板上,EXT_CSD 的 BOOT_PARTITION_ENABLE 似乎对 ROM 的实际启动源没有影响。根据 IMX8MPEVKHUG 第 2.2 节,EVK 的 SW4 开关仅用于选择粗略的启动设备类别(eMMC vs SD vs QSPI vs NAND vs 熔丝 vs USB 串行下载)——没有用于 eMMC 启动分区子模式的开关位置。 问题: 1. 在LPDDR4 EVK上,是否有支持的方法可以选择“ROM从eMMC boot0/boot1硬件分区启动”,而无需设置BT_FUSE_SEL=1或烧录BOOT_CFG熔丝?例如,是否可以通过跳线、电阻或IMX8MPEVKHUG rev 0中未记录的SW4/SW1101组合来实现?或者,该板的PCB是否已硬性规定始终从eMMC用户区启动,而不管EXT_CSD状态如何? 2. 如果 BOOT_CFG 熔丝是启用 eMMC 启动分区模式的唯一方法:控制此模式的 BOOT_CFG 熔丝组是否独立于用于 HAB 的 SRK 哈希熔丝?我想了解通过熔丝启用 eMMC 启动分区冗余是否会迫使我同时关闭 HAB(SRK 烧录),或者这些是否是可分离的决定。 3. 对于使用 i.MX 8M Plus 和 eMMC 的定制板设计(非 EVK),推荐的方法是如何在首次启动时就使 eMMC boot0/boot1 冗余可用?也就是说,BOOT_CFG GPIO 跳线/PCB 设计中需要满足哪些条件,才能使其成为第一天就能使用的功能,而不是需要稍后进行熔丝位绑定? 如果能提供一些关于 eMMC 启动分区选择的 BOOT_CFG 位定义的具体参考手册章节的链接(除了 IMX8MPEVKHUG 中已经涵盖的 SW4 设备类位之外),我们将不胜感激。 谢谢! Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 供参考,请参阅 i.Mx8 UM 第 5.8.2.2.1 节“高级 eMMC 启动流程”。 SCU ROM 支持 4 种 eMMC 启动方案: 1.在这种情况下,“eMMC 快速启动”熔丝被烧断。小学和中学 镜像容器集均位于启动分区中,且 BOOT_PARTITION_ENABLE = 1 或 2。 2. 在这种情况下,“eMMC 快速启动”熔丝烧断了。小学和中学 镜像容器集均位于用户区域,且 BOOT_PARTITION_ENABLE =7。 3.在这种情况下,“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动、主镜像容器集和辅助镜像容器集都在用户区域。 4. 在这种情况下,“eMMC 快速启动”熔丝没有熔断。启动模式为正常模式 启动时,主镜像容器集和辅助镜像容器集都在启动过程中。 分区,并且 BOOT_PARTITION_ENABLE = 1 或 2。 Re: i.MX 8M Plus LPDDR4 EVK - enabling eMMC boot0/boot1 谢谢你的指点——不过我认为第 5.8.2.2.1 章描述的是不同的芯片系列。“SCU ROM” eMMC 启动流程是 i.MX8QuadMax/QuadXPlus/DualXPlus 特有的,它们具有专用的系统控制器单元(独立的 Cortex-M4 启动子系统)。i.MX8M Plus 没有 SCU – 其启动 ROM 直接在 Cortex-A53 上运行 – 因此该章节中的 BOOT_PARTITION_ENABLE=1/2/7 场景不适用于这里。 对于 i.MX8M Plus,冗余似乎是通过 i.MX8M Plus 参考手册中的主/辅助映像机制来处理的(图 6-1):ROM 从 BT_FUSE_SEL/BOOT_CFG 选择的设备启动,如果失败,则回退到 IMG_CNTN_SET1_OFFSET 熔丝偏移处的辅助映像——在同一引导设备上,而不是单独的 boot0/boot1 分区。这与我在 LPDDR4 EVK 上看到的情况一致:EXT_CSD 中设置了 BOOT_PARTITION_ENABLE=1,但 ROM 忽略了它,仍然从原始用户区偏移量启动。 所以我的问题仍然是,仅限于 i.MX8M Plus: 1. 在 LPDDR4 EVK 上,是否有任何非熔丝方法(跳线、电阻或未记录的 SW1101/SW4 位置)来选择 eMMC boot0/boot1 作为启动源,还是这完全取决于 BOOT_CFG 跳线/BT_FUSE_SEL 的决定? 2. BOOT_CFG 熔丝组是否独立于 HAB 的 SRK 哈希熔丝,或者通过熔丝提交 BOOT_CFG 是否也会强制关闭 HAB? 3.对于定制板设计,在布局时需要进行哪些 BOOT_CFG 绑定才能在不进行后续熔丝分配的情况下保持硬件启动分区冗余? 如果我误解了第 5.8.2.2.1 章实际适用的部分,请指正。
View full article