こんにちは、
私は RT1176 ベースのボードを (現在は古い) mcux-sdk で使用していますが、問題は mcuxsdk でも同じようです (本当に紛らわしい名前です!)。
Freertos-LPUART ドライバー (fsl_lpuart_freertos.c) は、LPUART_RTOS_Init 関数で HAL_UartInit (fsl_adapter_lpuart.c) を呼び出しません。代わりに LPUART_Init だけを呼び出しますが、これでは不十分です。
問題は、フィールド s_UartState (fsl_fsl_adapter_lpuart.c の 719 行目) が LPUART_Init に書き込まれていないため、UART からの受信割り込みが発生するとアサーションが発生することです。
アサート エラー "NULL != uartHandle ": ファイル "D:\usr\TQM\mcuxsdk\core\components\uart\fsl_adapter_lpuart.c"行「433」関数名「HAL_UartInterruptHandle」
それで、このドライバーがどのように動作するのか疑問に思います。なぜなら、割り込みドライバーのハンドルの配列 s_UartState が読み取られるからです (そして、それは NULL です)。
SO、私が何か間違ったのでしょうか、それともこのドライバに問題があるのでしょうか?LPUARTS 用のより低い API ドライバを使用するには、コードを書き直す必要があるかもしれません。
ありがとう、さようなら
オリバー
こんにちは、
最新の mcux-sdk を備えた VSCode プラグインを使用しています。私たちは TQMa117xL ベースのボードを使用していますが、残念ながら BSP はまだ mcuxsdk に対応していません。
つまり、現時点では mcuxsdk でテストすることはできませんが、将来的には変更する予定です。
言及された例は新しいものですが、mcux-sdk では見つかりませんか?調べてみます。
アサーションは Init 関数の直後に発生します。
lpuart_rtos_config_t mSerConfig;
lpuart_rtos_handle_t mRtosHandle;
_lpuart_handle mUartHandle;
mRtosHandle = {};
mUartHandle = {};
mSerConfig = {};
mSerConfig.srcclk = CLOCK_GetRootClockFreq(kCLOCK_Root_Lpuart9);
mSerConfig.base = LPUART9;
mSerConfig.baudrate = aBaudrate;
mSerConfig.parity = kLPUART_ParityDisabled;
mSerConfig.stopbits = kLPUART_OneStopBit;
mSerConfig.buffer = mReadBuf;
mSerConfig.buffer_size = sizeof(mReadBuf);
mSerConfig.enableRxRTS = true;
mSerConfig.enableTxCTS = true;
int status = LPUART_RTOS_Init(&mRtosHandle, &mUartHandle, &mSerConfig);コードは C++ クラス内にありますが、init コードを例と比較します。
さよなら、
オリバー
こんにちは@Oliver_Rさん、
次の質問について教えていただけますか?
VS Code または MCUXpresso を使用していますか?
mcuxsdk でテストすると、問題は解決しますか?
VS Code には、evkbmimxrt1170_freertos_lpuart_cm7 というサンプル プロジェクトがあります。あなたのハードウェアで動作するかどうかのテストを手伝ってもらえますか?
よろしくお願いします、
パブロ
こんにちは、
その間に、これが FreeRTOS-Uart ドライバだけでなく、基礎となる lpuart ドライバにも関連していることが分かりました。
残念ながら、SDKドキュメントやフォーラムではHAL_Uartドライバーに関する情報は見つかりませんでした。
HAL_Uartxxx-API (fsl_adapter_lpuart.c) が必要な理由は何ですか?なぜ、いつ使用すればよいのでしょうか?SDK 全体で HAL_UartInit を使用しているソースは、debug_console_lite フォルダー内の fsl_component_serial_port_uart.c と fsl_debug_console.c の 2 つだけです。
この API に関する問題は、fsl_adapter_lpuart.c が「HAL_UART_TRANSFER_MODE=1」を定義せずにコンパイルされると、すべての lpuart 割り込みがこのソースで定義され、受信 IRQ でのアサーションを回避するために HAL_UartInit を使用する必要があることです。また、IRQ はすでに定義されているため、独自の IRQ を登録する必要はなくなりました。
しかし、すべての UART の例では HAL_UART_TRANSFER_MODE=1 が設定されておらず、一部の例では独自の IRQ が定義されているため、これがどのように機能するのか疑問に思います。DEBUG_CONSOLE_TRANSFER_NON_BLOCKING を定義していますが、「utility_debug_console_lite」コンポーネントは使用していません。
ところで、「utility_debug_console」と「utility_debug_console_lite」の違いは何でしょうか?SDK ドキュメントは両方のコンポーネントで同じですか?
このドライバー コード全体を理解するのは非常に困難です。プリプロセッサ マジックが非常に多く、ドキュメントが非常に少ないためです。
SO、ソース「fsl_adapter_lpuart.c」は、lpuart IRQ を望ましくない方法で定義し、デバッグ コンソール lpuart 以外の lpuart を使用するときにアサーションを引き起こすため、コンパイルしてはならないという印象を受けます。
さよなら、
オリバー
ハイ
この問題は freertos の実装ではなく、lpuart ドライバに直接起因しているようだと述べています。
LPUART の例をベアメタルでテストすると動作しますか?
MCUXpresso を使用してこれをテストすることもできますか?
utility_debug_console と utility_debug_console_lite の詳細な説明は、SDK API リファレンス・マニュアルに記載されています。
MCUXpresso SDK APIリファレンス・マニュアル: デバッグコンソール
MCUXpresso SDK APIリファレンス・マニュアル: デバッグコンソールLite
よろしくお願いします、
パブロ
そこで、何時間もかけてドライバ コードをデバッグし、UART コードのすべてのプリプロセッサ マジックを理解しようとした結果、ようやくこの動作の理由が分かりました。そして、それは確かに FreeRTOS API とは関係ありません。
SDK の hello world の例に記載されているフラグを設定すると、問題が発生します。
「高度なデバッグ コンソール ユーティリティを使用するには、プロジェクトで DEBUG_CONSOLE_TRANSFER_NON_BLOCKING を定義するだけです。」
非ブロッキング コンソールはコードのタイミングをそれほど妨げないので、そうするのは良いアイデアだと思いました。しかし、このオプションには、どこにも言及も文書化もされていない壊滅的な副作用があります。
スタートアップ コード (startup_mimxrt1176_cm7.c) は、LPUART IRQ を次のように定義します。
WEAK void LPUART10_IRQHandler(void) { LPUART10_DriverIRQHandler(); }SO、IRQ は LPUART ドライバーにルーティングされますが、これは問題ありません。
ただし、DEBUG_CONSOLE_TRANSFER_NON_BLOCKING を定義すると、fsl_adapter_lpuart.c ですべての LPUART の IRQ (コンソール LPUART1 の IRQ だけでなく) が上書きされ、次のようになります。
void LPUART10_IRQHandler(void);
void LPUART10_IRQHandler(void)
#endif /* LP_FLEXCOMM10 */
{
HAL_UartInterruptHandle(10);
SDK_ISR_EXIT_BARRIER;
}
#endif
#endif /* LPUART10 */HAL_UartInterruptHandleには次の行があります
hal_uart_state_t *uartHandle = s_UartState[instance];HAL_UartInit を使用していない場合は、その後アサーションが発生します。
言い換えると、DEBUG_CONSOLE_TRANSFER_NON_BLOCKING を設定すると、既存の (HAL_xxx 以外の) UART コードがすべて失敗します。
ドライバ コードを確認してください。これは本当に悪い、侵入的、悪意のあるオプションであり、実際に使用する場合は、厳重な警告を出す必要があります。
私の意見では、この定義は副作用がひどいので SDK から削除する必要があります。どの SDK サンプルでもこのオプションが設定されていないのは不思議ではありません。
残念ながら、私の質問のいくつかには誰も答えてくれなかったので、もう一度ここに書きます。
1.HAL_Uartxxx-API (fsl_adapter_lpuart.c) が必要な理由は何ですか?なぜ、いつ使用すればよいのでしょうか?
2. 「utility_debug_console」と「utility_debug_console_lite」の違いは何ですか?SDK ドキュメントは両方のコンポーネントで同じですか?
したがって、SDK ドキュメントを再度示さないでください。すでに読んでいますが、「完全な説明」には違いについて何も記載されていません。
さよなら、
オリバー
こんにちは、
HAL に関しては、通常、異なる MCU プラットフォーム間での移植性が必要な場合に使用されます。
詳細については、「MCUの潜在能力を拡張するには新しい考え方が必要な理由 | NXP Semiconductors」をご覧ください。
サポートされるデバッグ コンソールのハードウェア デバイス タイプはそれぞれ異なり、UART (lite) のみをサポートするものもあれば、UART、USB、および SWO をサポートするものもあります。
ドキュメントの Web ページに記載されている内容としては、たとえば、API を使用するために必要なパラメーターであるシリアル インターフェースがサポートされていること、たとえば、Advance の場合はインターフェースに応じて情報がどのように印刷されるかを示す完全な表があり、Lite では同数のインターフェースがサポートされていないため、表示される情報は限られていることなどが挙げられます。
他にご質問がございましたらお知らせください
よろしくお願いします、
パブロ