WDTが効かない

[guest]

WDTが効かない

マイコンは、MSP430FR6972を使用しております。
開発環境は、CCS v12を使用しております。
クロックは4Mhzと32Khzを外部入力しております
WDTを1秒でタイムアウトするように設定しております。

現場のマイコンでフリーズする現象が起きており、
リセットをすると動き始めるため、WDTが効いていないように思えます。

デバッグ用にソフトウェアで無限ループとなるように動作させたところ、
正常にWDTが効くことが確認できております。
1秒と10msのタイマを使って、内部処理をしているため、
そのタイミングでWDTをクリアしております。
以下コードの抜粋になります。

 

#define WatchDog (WDTPW | WDTCNTCL | WDTSSEL__ACLK | WDTIS_4); // 1s 32kHzの時に1秒

volatile unsigned char interrupt_timer0_triggered = 0;
volatile unsigned char interrupt_timer1_triggered = 0;

int main(void)
{
WDTCTL = WatchDog;
SFRIE1 |= WDTIE; // Enable WDT interrupt
_delay_cycles(4000); // 1ms
initialize(); // 初期化処理呼び出し
g_sysrstiv = SYSRSTIV;
while (1){
if (interrupt_timer0_triggered){
// 10ミリ秒周期タイマのタイムアウト
timer0();
WDTCTL = WatchDog;
}
if (interrupt_timer1_triggered){
// 1秒周期タイマのタイムアウト
timer1();
WDTCTL = WatchDog;
}
__bis_SR_register(LPM3_bits + GIE);

}
}

 

//interrupt_timer0_triggered,interrupt_timer1_triggeredはタイマ割り込み発生時に1となります。

フリーズしているのにWDTが効かなるケースは御座いますでしょうか。

 

[umamiti従業員]

お問い合わせありがとうございます。

弊社で調査した限り、”フリーズしているのにWDTが効かなるケース”の明確な事例等は確認できませんでした。あくまで弊社の見解となりますが、考えられるケースについて以下に挙げさせていただきますので、ご参考頂ければと存じます。

• 入力している電源電圧・クロックに異常があり、推奨動作電圧範囲外にある場合、CPUがハングアップしている
  WDTでのリセットはPUC(power-up clear)リセットとなり、基本的にクロックシステムを含むハードウェアのリセットを行われず、リセットするためにはブートコードを必要とします。しかしブートコードが実行できない状態である（例えばDCOが高すぎる）場合、CPUは再びクラッシュし、WDTがトリガーするたびにまたクラッシュする可能性があります。
  また、電源電圧についてはSVSやBOR等の内部監視機能がございますが、念のため、入力している電源電圧・クロックに異常が無いかをご確認下さい。
• WDTに入力しているクロックのFail-safe機能が正しく動作していない
  入力している基準クロックに異常がある場合、自動的にLFMODOSC(約37.5kHz)に切り替わりますが、LFMODOSCにも異常がある場合、WDT正しく動作しない可能性がございます。こちらのサンプルコードをご参考にFail-safe機能のチェックが可能となります。
• WDTのレジスタが意図せず変化している
  テストコードではWDTが正常に動作している為、可能性はとしては低いと考えますが、念のため、フリーズ時のレジスタ値が想定通りかをご確認下さい。

なお、貴社のテストコードの内容から、問題となりそうな点は確認できませんが、”SFRIE1 |= WDTIE;”については、WDTをInterval timer modeの時のみ有効となります。また、意図的にWDTでのリセットをかけた場合は、”g_sysrstiv=SYSRSTIV”=WDTIFG(16h)になると認識しております。(もし認識が違う場合は、ご指摘頂ければと存じます。)

以上、よろしくお願いいたします。

 

[guest]

ご回答ありがとうございます。

テストコードでは、WDTのタイムアウトが発生した際に
”g_sysrstiv=SYSRSTIV”=WDTIFG(16h)となることを
確認できております。

WDTの割り込み関数の中でCPUのハードウェアリセット行いたいのですが、
WDT_ISRが呼び出されていないようです。

#pragma vector=WDT_VECTOR
__interrupt void WDT_ISR(void)
{
PMMCTL0 = (PMMSWBOR | PMMSWPOR);
}

リセット後は、SYSRSTIV 16Hになっていますので、
WDTが効いていると思うのですが、WDTの使い方が
間違っているのでしょうか。
また、WDT_ISR内でPMMCTL0 でリセットを掛けると、ハードウェアリセットとなるのでしょうか。

ご確認の程、よろしくお願いいたします。

[guest]

WDTのインターバルモードとウォッチドッグモードの違いを理解できておりませんでした。

インターバルモードにすると、WDTのタイマー割り込みを利用して処理を行う事が可能。
ただし、処理のどこかで無限ループによるフリーズが発生した場合はリセットされない。

ウォッチドッグモードは、WDTタイマーがタイムアウトするとPUCリセットされる。

現状、ハードウェアリセットを行っていない為、WDTによるPUCリセット後に
HWリセットまで実施したいと思います。
下記のように処理すればよろしいでしょうか。

main()
{
g_sysrstiv = SYSRSTIV;
if (g_sysrstiv == 0x0016){
　 PMMCTL0 = (PMMSWBOR | PMMSWPOR);
}
}

[umamiti従業員]

ご確認ありがとうございます。また、追加でのご連絡ありがとうございます。既にご確認済の内容もございますが、以下にまとめて回答させて頂きます。

＞リセット後は、SYSRSTIV 16Hになっていますので、
＞WDTが効いていると思うのですが、WDTの使い方が
＞間違っているのでしょうか。

WDT_ISRを使用する場合は、WDTをInterval Timer Modeに切り替える必要がございます。こちらのサンプルコードの通り、WDTCTLレジスターのWDTTMSELビットをセットする必要がございます。※ユーザーズ・ガイド「24.2.3 Interval Timer Mode」をあわせてご参照ください。

 

＞また、WDT_ISR内でPMMCTL0 でリセットを掛けると、ハードウェアリセットとなるのでしょうか。

厳密にはソフトウェアリセットとなりますが、PMMSWBOR をセットした場合はBORが発行され、PMMSWPORをセットした場合はPORが発行されます。なお、PMMCTL0へのアクセスについては、パスワード(0A5h)を一緒に書き込む必要があり、パスワードが一致していない場合はPUCが発行されます。
ユーザーズ・ガイド「2.3.1 PMMCTL0 Register」、及びこちらのサンプルコードをご参考ください。

BOR, POR, PUCの違いについては、ユーザーズ・ガイド「1.2 System Reset and Initialization」、及びこちらのURLをご参考ください。

 

＞現状、ハードウェアリセットを行っていない為、WDTによるPUCリセット後に
＞HWリセットまで実施したいと思います。
＞下記のように処理すればよろしいでしょうか。

上記にて回答させていただいた通り、PMMCTL0アクセス時にパスワードを合わせて書き込み、BORかPORのどちらかのみをセットして頂ければ、意図したリセットが発行できるかと存じます。

以上、よろしくお願いいたします。

 

[guest]

ご回答ありがとうございます。

PMMCTL0へのアクセス方法の件、承知しました。
リセット理由がPMMになっていたことがありました。
パスワードを指定していなかった事が原因でした。
パスワードとセットでリセットするように致します。

WDTのインターバルタイマモードですが、
インターバルタイマモードでは、無限ループに陥った場合は、
WDTのタイムアウトが発生しないという認識でよろしかったでしょうか。

以上、よろしくお願いいたします。

[umamiti従業員]

ご返信ありがとうございます。

＞WDTのインターバルタイマモードですが、
＞インターバルタイマモードでは、無限ループに陥った場合は、
＞WDTのタイムアウトが発生しないという認識でよろしかったでしょうか。

→”無限ループに陥った場合”の定義として、投稿いただいた時と同様にWDT以外のペリフェラルを含め、完全にシステム・CPUがハングアップしている場合では、WDTのインターバルタイマモードでの割り込みも発生しない可能性がございます。

そのため、WDTのモード切り替えでは明確な回避策にならない可能性がございます。まずは根本的な問題の特定として、現場のマイコンがフリーズする現象に対する発生条件や要因について調査いだくことを推奨いたします。

デバッグ用ソフトウェアのような無限ループの場合、インターバルタイマモードとしては、WDTIEビットとGIEビットが設定されると、タイムアウトが発生し、PUCの生成されない割り込みが発生するかと存じます。

以上、よろしくお願いいたします。

[guest]

ご回答ありがとうございます。

>デバッグ用ソフトウェアのような無限ループの場合、インターバルタイマモードとしては、
>WDTIEビットとGIEビットが設定されると、タイムアウトが発生し、PUCの生成されない
>割り込みが発生するかと存じます。

承知いたしました。

>そのため、WDTのモード切り替えでは明確な回避策にならない可能性がございます。
>まずは根本的な問題の特定として、現場のマイコン
>がフリーズする現象に対する発生条件や要因について調査いだくことを推奨いたします。

はい、おっしゃる通りです。
根本的な原因の調査を行いたいと思います。

[guest]

FRAMへSYSRSTIVのコード毎に発生回数を記録するようにして、ログを取ってみたところ、
02HのBORが発生していました。

そこで、オシロを繋いでマイコンの電圧をモニタしてみたのですが、電圧降下は発生しておりませんでした。
※電圧は2.8V以上あり。

マイコンに供給する電圧が落ちていないのに、BORが発生する事はあるのでしょうか。

ちなみに、BORが発生するタイミングは、AD変換を行っているタイミングと一致していました。
AD変換は、電源である電池の電圧測定をおこなっております。

[umamiti従業員]

電源電圧が落ちていない場合でのBORの発生としては、下記の太字で示した内容が適用されるかと存じます。

基本的にはBORの発生条件はユーザーズ・ガイド「1.2 System Reset and Initialization」に記載されている通り、下記のイベントとなります。

• デバイスへの電源投入
• LPMx.5からのウェイクアップ
• SVSHが有効な場合でしきい値を下回る
• ソフトウェアによるBOR

もしくは、データシート「5.13.1 Power Supply Sequencing」の注釈(1)に記載されている通り、電源電圧の急激な変化は、推奨電源電圧範囲内であっても、BORを引き起こす可能性があります。

電源を安定化電源等に変更することや、問題の発生していない基板上のMSP430FR6972とクロスチェックを実施することで、問題の切り分けが可能かと考えます。

以上、よろしくお願いいたします。

[投稿者]

投稿