MAXQマイクロコントローラのJTAGインタフェース端子の多重化

概要

多くの場合、組込みアプリケーションでは、マイクロコントローラのすべてのポート端子がアプリケーション用に必要であり、余分な端子はありません。ただし、開発者には、この問題に対処する選択肢が用意されています。(フラッシュメモリやEEPROMなどの)再書込み可能な内部プログラムメモリ内蔵の大部分のMAXQマイクロコントローラは、標準JTAG/TAPインタフェース(別名、デバッグポート)をサポートしています。外部ホストはこのインタフェースを使って、インサーキットデバッグまたはインサーキットプログラミング(ブートローダ)機能にアクセスします。このインタフェース用の端子は通常、標準GPIOポート端子と共用化されているため、開発段階が終了すると、アプリケーションが端子を利用することができます。このアプリケーションノートでは、汎用アプリケーション用にこれらのインタフェース端子を再利用する方法について説明します。また、このアプリケーションノートでは、こうした端子を共用化する際に考慮すべき状況を示します。

アプリケーションの開発段階

開発段階中に、JTAG対応のデバッグポートは、いくつもの便利な機能を提供します。まず、デバッグポートによって、(MAX-IDE、Rowley CrossWorks、またはIAR Embedded Workbench®などの開発環境を利用する)外部ホストの制御のもとでアプリケーションをロードすることができます。すなわち、アプリケーションを次のテストサイクル用に再び素早くテストし、修正し、ロードすることができます。第二に、デバッグポートによって、MAXQアーキテクチャから提供されるインサーキットデバッグ機能にアクセスすることができます。これらのデバッグ機能は、レジスタの読取り/書込みを行い、プログラムコードを１ステップずつ実行し、プログラム、データ、およびスタックメモリを参照する機能を備えています。最後に、ブートローダとインサーキットデバッガを使用しても、アプリケーションが利用可能なメモリリソースにはほとんど影響を及ぼしません。これは、インサーキットデバッグ機能は、MAXQハードウェアとユーティリティROM内にすべて実装されているためです。

アプリケーションが終了し、テストされると、インサーキットデバッグ機能はもはや不要です。さらに、再プログラム可能なMAXQデバイスをマスクROMバージョンに置き換えるような大規模生産では、インサーキットプログラミング(ブートローダ)機能も不要であるため、デバッグポートはもはやいかなる目的にも適合せず、無視するかまたはもっと有意義に使用することができます。MAXQデバイスのGPIOポート端子の数が限られ、アプリケーションにとって不十分である場合、JTAG対応デバッグポート専用のポート端子を汎用アプリケーション用に利用することは特に有益かもしれません。

デバイスポート端子の再利用

以下の4個の端子を使って、JTAG対応のデバッグポートインタフェースを実装することができます。

• TCK：テストクロック—MAXQへの入力
• TMS：テストモードの選択—MAXQへの入力
• TDO：テストデータアウト—MAXQからの出力
• TDI：テストデータイン—MAXQへの入力

これらの4個の端子は通常、4個のGPIOポート端子と共用されています。この目的のために使用されるまさにその端子はMAXQデバイスから次のデバイスまで異なります。デフォルトでは、リセットまたはパワーオンリセット(POR)状態の後に、デバッグ端子がイネーブルされます。これは、ポート端子が汎用アプリケーション用に利用不可であることを意味します。デバッグポート機能をディセーブルし、汎用目的のためにポート端子をイネーブルするには、システム制御(System Control)レジスタのTAPビット(SC.7)をゼロにクリアする必要があります。その後、ポート端子は、PD、PO、およびPIレジスタによって通常方式で制御されます。

ハードウェアに関して

同じハードウェアがアプリケーション開発/配備段階中に使用される場合は、デバッグインタフェースのポート端子がGPIOモードまたはJTAG/TAPモードで使用されるときに、ハードウェアが適切に動作することに注意する必要があります。たとえば、端子がJTAG/TAPモードで使用される場合は、これらの端子に接続される外付けデバイスは端子をトライステートモードにする必要があります。こうしてホストとMAXQはこれらのライン上の信号を駆動することができます。さらに、これらのラインに接続されるデバイスは、インサーキットデバッグまたはブートローダ動作中にホストやMAXQで駆動されるライン上で受信される信号を無視する必要があります。このことは、信号への応答がデバイスに損傷を与えるおそれがある場合に特に該当します。

たとえば、ポート端子のいずれか1つがTCK信号用(JTAG/TAPモードでの使用時)とリレー制御用(GPIOモード時)の両方に使用されたと仮定します。デバイスがJTAGインタフェースを通じてデバッグされると、TCK信号は素早く切り替わります。その結果、リレーがオンおよびオフになり、リレーに接続された外付け機器に損傷を与えるおそれがあります。これを防止するには、JTAG/TAPインタフェースから端子に接続された外付けデバイスを、デバイスがブートローダまたはインサーキットデバッグモードで動作するときは常に、ディセーブルする必要があります。外付けデバイスは、ジャンパまたは別の端子をイネーブル信号として使って、ディセーブルすることができます。

ソフトウェアに関して

JTAGインタフェースポートのディセーブルは容易です。TAP (SC.7)ビットは、随時ゼロにクリアすることができます。これを実行すると、アプリケーションがポート端子を直ちに利用することができます。アプリケーション開発者の自然な志向は、場合によっては、アプリケーション用の適切な動作モードを設定するためにアプリケーションコードの最初でこのビットをクリアすることです。ただし、これほど早くTAPビットをクリアすると、アプリケーション開発中に問題が発生する場合もあります。

アプリケーションがマスクROM MAXQデバイス(再プログラム不可)で動作している場合は、アプリケーションの最初でTAPをゼロにクリアしない理由がありません。この場合は、コードはプログラム済みで、変更不可であるため、ブートローダおよびインサーキットデバッグ機能は使用されません。

ただし、再プログラム可能なMAXQデバイスで開発されたアプリケーションの場合は、TAPビットをクリアし、JTAGインタフェースをディセーブルする前に、アプリケーションソフトウェアが必ず数秒の遅延を与える必要があります。TAPビットがリセット直後にクリアされる場合は、アプリケーションのリロードやデバッグを行おうとすると、以下のイベントシーケンスが発生することがあります。

1. ホストがアクティブローRESETをローに駆動し、MAXQがリセットに移行
2. ホストがアクティブローRESETをリリース
3. MAXQがリセットから抜け、コード実行を開始するため、すぐにJTAGインタフェースをシャットオフ
4. ホストがJTAGインタフェースを通じてデバイスと通信を試みるが、通信不可

このシーケンスは、リセット後にすぐに停止モードまたは別の超低電力モードに移行するアプリケーションによって発生する問題と類似しています。この問題は、アクティブローRESET端子もディセーブル可能なデバイスではさらに悪化する場合があります。こうした状態での実際のリセット動作は、ホストがトリガするイベントシーケンスと、デバイスがアクティブローRESET端子またはパワーオン/オフによってリセットされるかどうかに依存しています。

上記のソフトウェア問題を回避するには、デバッグTAPポートまたはアクティブローRESET端子をシャットオフするアプリケーションが、起動時にデバッグエンジンをシャットダウンする前に数秒遅延する必要があります。この遅延によって、外部ホストが、このインタフェースがオフになる前に、JTAGインタフェースを通じてMAXQを制御することができます。また、アプリケーションは(ジャンパやプッシュボタンで制御される)別のポート端子の入力レベルをチェックし、JTAGポートをイネーブルまたはディセーブルすべきかどうかを決定することができます。

結論

MAXQマイクロコントローラのTAP (SC.7)ビットで提供されるJTAGインタフェースの共用化によって、インタフェースの4個の端子をデバッグ/ブートローダ用または汎用I/O用に使用することができます。いくつかのハードウェアおよびソフトウェアの注意事項に従う限り、これらの端子を端子が限られたシステム用に追加リソースとして再利用し、MAXQデバイスによるアプリケーションの開発時の柔軟性を向上することができます。