4

UART を持たないアプリケーションに MSP430F2013 プロセッサを使用しています。UART が必要なので、TI のサンプル コード「msp430x20x3_ta_uart2400.c」を使用して、Timer モジュールを使用して UART をエミュレートしました。これはすべて正常に機能し (IAR Embedded Workbench でコンパイル)、PuTTY を使用して文字を開発ボードに送信し、ループバックを使用して文字を端末にエコーすることをテストしました。

これはリスクを回避するための作業であり、今ではそのコードをアプリケーションのステート マシンに移植することになりました。これを行った後、タイマー割り込みと低電力スリープ モードに関連する問題が発生しています。低電力（スリープ）モードへのエントリの周りのコードのスニペットは次のとおりです。

// Prepare the UART to receive one byte.
prepare_receiver();

// Enter low power mode 1.
__bis_SR_register(LPM1_bits + GIE);

// Check whether the full message has been received.
if(true == get_message_complete())
{
    process_event(e_euart_message_received, NULL);
}

デバッガー (C-Spy) で見ているのは、bis_SR_register()最初のエントリで行を実行してからifステートメントに移動する場合があることです。つまり、スリープ状態にするように要求したという事実を無視します。他の場合には、スリープ状態になるべきときに ISR が正しくトリガーされ、最終的にifステートメントに戻ってプログラムの実行を続行します (予想どおり)。しかし、次のステートメントに移動しようとすると、アプリケーションがその最初の行でフリーズします。つまり、先に進むことができません。

私がやっているTIの例と機能的に異なるものは何も考えられないので、私の問題は私がそれを移植した方法に関係しているに違いないと思います。たとえば、Timer ISR とここに投稿したコードは、異なるコンパイル ユニットにあります。この種の決定は何か関係がありますか? 私の質問は少し漠然としているかもしれませんが、残念ながらすべてのコードを投稿することはできません.陥ってしまったのかもしれません。

4

2 に答える 2

5

低電力モードで C-Spy を使用して割り込みをデバッグするのは難しいでしょう。Section A.3 Debugging (C-Spy) - IAR User's Guideによると:

5) C-SPY は、割り込みと低電力モードを利用するアプリケーションをデバッグできます。

しかし、頭痛の原因となっている可能性があることに注意する必要がある「落とし穴」がいくつかあります。

特に：

14) C-SPY がデバイスを制御している場合、ステータス レジスタの低電力モード ビットの設定に関係なく、CPU はオンになります (つまり、低電力モードではありません)。Step or Go の前に、すべての低電力モード状態が復元されます。したがって、C-SPY がデバイスを制御している間は、デバイスの消費電力を測定しないでください。代わりに、JTAG がリリースされた Go を使用してアプリケーションを実行します。

19) C-SPY は、デバッグ中にシステムクロックを使用してデバイスを制御します。そのため、C-SPY がデバイスを制御すると、メイン システム クロック (MCLK) によってクロックされるデバイス カウンタなどが影響を受けます。ウォッチドッグ タイマーへの影響を最小限に抑えるために、特別な予防措置が講じられています。CPU コア レジスタは保持されます。他のすべてのクロック ソース (SMCLK、ACLK) およびペリフェラルは、エミュレーション中も引き続き正常に動作します。つまり、Flash Emulation Tool は部分的に侵入型のツールです。

クロック制御 (Emulator → Advanced → Clock Control) をサポートするデバイスは、デバッグ中にクロックの停止を選択することで、これらの影響をさらに最小限に抑えることができます。

24)通常のプログラム実行中に読み取るとクリアされる周辺ビット(つまり、割り込みフラグ)は、デバッグ中に読み取るとクリアされます(つまり、メモリ ダンプ、周辺レジスタ)。

特定の MSP430 デバイス (MSP430F15x、MSP430F16x、MSP430F43x、MSP430F44x デバイスなど) を使用する場合、ビットはこのように動作しません (つまり、ビットは C-SPY 読み取り操作によってクリアされません)。

26)アクティブで有効な割り込みを使用してシングル ステップを実行している間、割り込みサービス ルーチン (ISR) のみがアクティブであるように見える場合があります(つまり、非 ISR コードは実行されていないように見え、シングル ステップ操作は常に最初の行で停止します)。 ISRの）。ただし、デバイスは非 ISR (つまり、メインライン) コードを処理する前に、アクティブで有効な割り込みを常に処理するため、この動作は正しいです。この動作の回避策は、ISR 内でスタックの GIE ビットを無効にして、ISR を終了した後に割り込みが無効になるようにすることです。これにより、ISR 以外のコードをデバッグできます (ただし、割り込みはありません)。割り込みは、[レジスタ] ウィンドウのステータス レジスタに GIE を設定することで、後で再度有効にすることができます。

クロック制御エミュレーション機能を備えたデバイスでは、シングル ステップ間でクロックを一時停止し、割り込み要求を遅らせることができる場合があります (エミュレータ → アドバンスト → クロック制御)。

試してみるべきことの 1 つは、すべての低消費電力コードをコメントアウトして、UART コードがそのように機能するかどうかを確認することです。次に戻って、低電力モードを再度有効にしてみてください。

于 2012-09-17T19:04:02.380 に答える
4

この質問に対する答えは、デバッグのセットアップにあり、より具体的には、どのタイプのブレークポイントが使用されているかにあります。プログラムのアップロードで実行されていた非常に複雑な一連のマクロがあり、テスト目的でさまざまなフックをメモリに設定しました。これらのフックはソフトウェアに依存していましたブレークポイントが作成され、アプリケーションの外部で関数が呼び出されます。通常の使用ではこれらのブレークポイントを使用しても問題はありませんが、ブレークポイントが存在すると、デバッグ セッションがリアルタイムで実行されない (つまり、デバイスがホスト PC の制御下にある) ことになります。これは、私にはまだ完全に知られていない理由で、割り込みと低電力モードをデバッグしようとしたときに問題を引き起こしました。（もう少し詳しく調べてみると、デバッグ中にクロック制御を使用する必要があることがわかると思いますが、それは別の日に取っておきます）。

したがって、この問題を解決し、より大きなアプリケーション ステート マシンに移植した割り込みおよび低電力モードの負荷の高いコードをデバッグできるようにするには、次の手順を実行する必要がありました。

  1. IAR 内のソフトウェア ブレークポイントを無効にします。
    これらは実際にはデフォルトでは有効になっていませんが、私のようにマクロを巧妙に使用していた場合は、おそらくそれらを有効にする必要があったでしょう。ほとんどの MSP430 で利用可能なハードウェア ブレークポイントが十分にないためです (たとえば、 、MSP430F2013 には 2 つしかありませんが、C-SPY はそのうちの 1 つを独り占めすることがよくあります!)。これの明らかな欠点は、デバッグが少し面倒になることですが、少なくとも信頼性は高くなります。
  2. .mac マクロ ファイルへのリンクを削除します。
    つまり、マクロを使用している場合は使用しないでください。私の場合、これは、特定のルート (以前はマクロが行っていた) を強制的に下るために、いくつかのステート マシン ロジックをハックする必要があることを意味していました。これは明らかに理想的ではありませんが、割り込み/低電力モードのコードをデバッグできます。その後、マクロを再度有効にすることができます。

結局、私のポートには問題がなかったことがわかりました。私はこのハッキーなソリューションに特に満足しているわけではありませんが、少なくとも一歩前進です. 時間があれば、ソフトウェア ブレークポイントを使用する方法を見つけて、この回答に追加できるかどうかを調査します。

于 2012-09-18T08:45:49.800 に答える