フォーラムへの返信
-
投稿
-
御回答ありがとうございます。
UCSCTL7レジスタによってオシレータ障害の発生と解消を確認してからFLL再起動を行おうと考えていますが、FLL再起動にDCO安定化処理を加えると、オシレータ障害解消を確認後に再度オシレータ障害が発生した場合にDCO安定化処理での待ち時間が長くなることで製品機能に不具合が発生します。
そのため、FLL再起動ではDCO安定化処理を実行しないことを検討しています。
FLL再起動時にDCOが安定していなかった（OFIFG＝1）としても、フェールセーフ機能によってクロックソースが32ｋHzの内蔵オシレータに切替わり通常通り処理が行われると考えていますが、このような動作になるのでしょうか？御回答ありがとうございました。
サンプルコードではDCO安定待ちのために「while (SFRIFG1&OFIFG)」のループ処理がありますが、FLL初期化ではこのループ処理は実施しなくても良いでしょうか？
確認が遅くなり、申し訳ありませんでした。
ご紹介頂いたサンプルコードを参考にしてFLLの再起動（MCLK、SMCLK、ACLKの再設定）を行ったところ、消費電流が戻ることを確認しました。FLLの再起動のためクロックシステム制御レジスタ「UCSCTL*」の再設定を行いましたが、ご紹介頂いたサンプルコードのどの範囲がFLL再起動に必要な処理なのでしょうか？
サンプルコードを添付いたします。-
この返信は5 年、 3 ヶ月前に
kkk さんが編集しました。
Resource Explorerが起動できなかったため遅くなりましたが、ご紹介いただいたサンプルコードを確認しました。
下記サンプルコードではSCG0によってFLLを再起動していますがDISMODをセットしていないため、DCOモジュレータを再起動していないと思います。// Initialize DCO to 12MHz
__bis_SR_register(SCG0); // Disable the FLL control loop
UCSCTL0 = 0x0000; // Set lowest possible DCOx, MODx
UCSCTL1 = DCORSEL_5; // Select DCO range 24MHz operation
UCSCTL2 = FLLD_1 + 374; // Set DCO Multiplier for 12MHz
// (N + 1) * FLLRef = Fdco
// (374 + 1) * 32768 = 12MHz
// Set FLL Div = fDCOCLK/2
__bic_SR_register(SCG0); // Enable the FLL control loopオシレータ障害発生後に消費電流が増加したソフトの動作モードはアクティブモードとLPM3モードを交互に繰り返すことで、FLLをイネーブル/ディスエーブルに切り替えて再起動（DCOはイネーブルのまま）しましたが、消費電流がオシレータ障害発生前の数値に戻ることはありませんでした。
DCOモジュレータの再起動によって消費電流がオシレータ障害発生前の数値に戻ることは確認できましたので、DCOモジュレータがオシレータ障害発生後の消費電流増加の原因と考えていますが、そのようなことは無いのでしょうか？御連絡ありがとうございました。
iPhoneやWifiルーターが無くネットワーク環境の変更は難しいです。
自宅のパソコンとネットワーク環境ではResource Explorerが正常に動作したため、そちらでサンプルコードを確認します。御回答ありがとうございます。
御連絡いただいたURLのことです。
IE11で御連絡いただいた方法 1.ブラウザのキャッシュをクリアして再度アクセス、2.PCを再起動して再度アクセス、の両方を試しましたが、アクセスすることができませんでした。
アクセスできなかった時の画面を添付します。Attachments:
御回答ありがとうございます。
御連絡いただいたとおり、FLL基準クロックソースはXT1CLKから供給(SELREF=0)されています。
FLL(DCO)の再起動はどのような手順で行えば良いでのしょうか？御社担当者様より御連絡いただきました。
弊社で、書き込み可能な2台目のパソコンのMSP Flasherフォルダを丸ごと1台目のパソコンにコピーしたところ、1台目のパソコンでもhexファイルの書き込みが可能になりました。
書き込みができなかった直接的な原因は不明のままですが、1台目のパソコンでも書き込みが可能になったので、ここで確認は終了したいと思います。
色々な助言をいただき、ありがとうざございました。御質問について回答します。
オシレータ障害発生前の、UCSCTL4.SELA、SELS、SELMの設定値は下記になります。
UCSCTL4.SELA：000（初期値）
UCSCTL4.SELS：011
UCSCTL4.SELM：011消費電流計測時の動作モード(Active Mode/LPMx)については、62.5ms毎にActive modeになり、メイン処理を実行後にLPM3になる動作を繰り返しています。
メイン処理で同じ処理を実行させることで、Active modeになる期間とLPM3になる期間の変化によって消費電流が変化しないようにしています。御回答ありがとうございます。
hexファイルの書き込みができた２台目のパソコンのMSP430.dllを１台目のものにコピーしても、１台目ではhexファイルの書き込みができませんでした。
また、新規プロジェクト作成時に「Project templates and examples」→「Basic Examples」→「Blink the LED」を選択して作成したサンプルプログラムでIntel-hexフォーマットを生成して書き込もうとしましたが、書き込みできませんでした。
生成したサンプルプログラムhexファイルを添付できませんが、どのように送付すれば良いでしょうか？
サンプルプログラム書き込み時のエラー画面は記録していなかったので、後日送付します。申し訳ありませんでした。
DISMODの値が間違っていました。御確認内容に記載されている通り、「オシレータ障害発生前のDCOモジュールはEnable(DISMOD=0)であり、オシレータ障害から復帰後に一度DCOモジュールをDisable(DISMOD=1)にしてから、再度Enable(DISMOD=0)にした場合、消費電流がオシレータ障害発生前の数値に戻る」ということです。
御回答ありがとうございます。
MSP430.dllの更新日時で新旧を確認しました。
hexファイルの書き込みができない1台目のパソコンは2019/3/4、hexファイルの書き込みができる2台目のパソコンは2018/4/13となり、後者の方が古いバージョンであることを確認しました。また、ご紹介頂いた場所からダウンロードしたフォルダのMSP430.dllを1台目のパソコンのものに変更しましたが、hexファイルの書き込みはできないままでした。
御質問について回答します。
１．マイコン単体での複数台の消費電力をご計測頂けますでしょうか。
※前段でご提供頂いた測定結果では、マイコン単体ではサンプル数１台で、増加した電流値は0.5μAとの認識です。
⇒マイコン単体の消費電流を測定するためには、パターンを切り基板を破壊することになるので、改造にかかる時間と残りの基板台数から実行することは難しいです。
また、増加した電流値はご指摘の通り0.5μAになります。２．オシレータ障害発生前後で実行されるソフト処理が変わりますでしょうか。
⇒基板での動作を確認したところ、液晶表示や通信など基本的な機能（ソフト処理）は変わりなく実行できました。
また、液晶表示や通信を実行後も消費電流は0.5μA程度増加したままでした。３．オシレータ障害が発生し、エラーフラグをクリア後に再度クロック周りのレジスタの初期化処理を実行した場合、電流値に違いは見られますでしょうか。
⇒オシレータ障害フラグをクリアし、基板の消費電流が0.5μA程度増加した状態でDCOモジュレータをディスエーブル後に再度イネーブルする（DISMODを 1→0→1 の順にセットする）と、消費電流が最初の状態に戻る（0.5μAの増分が無くなる）ことを基板2台で確認しました。御質問について回答します。
１．ご計測された消費電流値は、MSP430チップ単体の消費電流量でしょうか。
また、オシレータ障害が発生する前の消費電流量は平均でどの程度でしょうか。
⇒基本的に基板全体の消費電流を測定していますが、1台でMSP430チップ単体の消費電流も測定しています。
オシレータ障害が発生する前の消費電流量は基板によりますが14μA程度です。
消費電流の測定結果を添付いたします。２．複数のボードでも１μAの上昇する現象が同様に見られますでしょうか。
⇒添付ファイルには1μA上昇する現象を1台のみ記載していますが、1μA上昇する現象を2台で確認しています。３．UCSモジュールのレジスタ(UCSCTL0～UCSCTL9)は、オシレータ障害の発生前/復帰後で差分はありますでしょうか。
⇒他のUCSモジュールのレジスタ(UCSCTL0～UCSCTL9)では差分はありませんでした。御回答ありがとうございます。
両者のパソコンともにMSP Flasherのバージョンが1.3.18であり、バージョンが同じであることは事前に確認しておりました。
2台目のパソコンではバージョン1.3.18でhexファイルが書き込めることを確認しています。 -
この返信は5 年、 3 ヶ月前に
