フォーラムへの返信

15件の投稿を表示中 - 16 - 30件目 (全30件中)
  • 投稿者
    投稿

  • kkk
    参加者

    御回答ありがとうございました。

    障害によって下記のフラグが全てONになるとマイコンの消費電流が4μA程度増加し、障害が無くなった後に下記フラグを全てOFFにするとマイコンの消費電流が3μA程度低下し、最終的に元の消費電流より1μA程度増加していることを確認しました。
    下記のフラグが一度でもONになるとマイコン内蔵回路が動作して消費電流が1μA程度増加する状態が続く、ということはあるのでしょうか?

    ・DCOFFG
    ・XT 1LFOFFG
    ・OFIFG

    返信先: MSP Flasherの書き込みファイルについて #5909

    kkk
    参加者

    御回答ありがとうございました。

    ソフト書き込みに使用するパソコンを変えたところ、hexファイルでの書き込みが可能でした。
    そのため、hexファイルはIntelフォーマットに則った変換ができていると考えています。

    また、hexファイルの書き込みができなかったパソコンで、バイトカウントが16のhexファイルは書き込み可能であることを確認しました。(書き込みできなかったhexファイルのバイトカウントは32)
    下記について教えていただきたいです。

    3.MSP Flasherで書き込みファイルのバイトカウント設定が必要ですか。

    4.MSP-FETのドライバVerによって、書き込み可能なバイトカウントは変わりますか。

    5.CCSでバイトカウント16のhexファイルを出力する際には、CCSをどのように設定すれば良いでしょうか。


    kkk
    参加者

    御回答ありがとうございました。

    Fail-safe機能を無効にする意図は、Fail-safe機能によってクロックソースが切り替わった後、オシレータが正常復帰しても自動的に異常前の状態に戻らないと考え、瞬間的な異常は許容して元のクロックソースを使い続ける方法を検討していたためです。

    Fail-safe機能について、続けて質問があります。
    3.ACLK が LF モードで動作する XT1 のクロック・ソースの場合、SELA ビット設定値の変更は無いようですが、ACLKのクロックソースがDCOに切り替わったことはどのように判断すれば良いのでしょうか?

    4.クリスタル・オシレータ障害ビットは自動でクリアされないのでユーザーがクリアする必要があると思いますが、オシレータ障害が解消されたことを何かのフラグなどで判断できるのでしょうか?


    kkk
    参加者

    御回答ありがとうございました。

    ウォッチドッグタイマを停止して確認しましたが、RTCレジスタはゼロクリアされていました。

    弊社で作成したソフトではリセットされてしまうようなので、CCSで確認することは諦めて、指定したアドレスのデータを返信する電文を追加し、通信によって各レジスタのデータを確認することにしました。


    kkk
    参加者

    御回答ありがとうございました。
    マイコンは「MSP430F5329」になります。

    下記のように確認しましたが、RTCレジスタがゼロクリアされていました。
    確認したレジスタは「RTCSEC、RTCMIN、RTCHOUR、RTCDAY、RTCMON、RTCYEAR」だけですが、教えて頂いた方法ではレジスタは初期化されてしまうのでしょうか?

    ・確認方法
    1.通信によって、実装基板のマイコンのRTCレジスタ(レジスタ名:RTCSEC、RTCMIN、RTCHOUR、RTCDAY、RTCMON、RTCYEAR)に日時を書き込む(正常にRTCレジスタに書き込めることは、CCSを起動した状態で通信をして確認済み)
    2.教えて頂いた方法でCCSを設定後、上記1の実装基板とPCをエミュレータで接続し、デバッガを起動する(実装基板は上記1から電源を投入したままにする)
    3.CCSでRTCレジスタの値を確認する

    返信先: RTCの割り込みタイミングについて #4894

    kkk
    参加者

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

    発生している現象は「最初の割り込みのみ31.25ms程度で発生し、以降の割り込みは設定通り62.5ms間隔となる」ということです。

    RTC設定とRTC割り込み処理を抜粋したソースコードを提示します。
    提示していませんが、メイン処理で常に動作モードをLPM3に設定し、割り込み発生時にLPM3を解除しています。

    Attachments:
    1. test_RtcCtrl.c
    返信先: RTCの割り込みタイミングについて #4888

    kkk
    参加者

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

    最初からカレンダーモードにして、プリスケールカウンタ RT0PS、RT1PS をゼロクリアしても、同様に最初だけ62.5ms割り込みが約31.25ms後に発生しました。
    確認方法は下記になります。

    1.カレンダーモードに切り替える
    2.RTCHOLDによってRT0PSおよびRT1PSを停止する
    3.RT0PSおよびRT1PSを0に設定する
    4.RTCHOLDによってRT0PSおよびRT1PSの停止を解除してテストポートをH出力する
    5.62.5ms割り込み処理でテストポートをL出力する
    6.テストポートのH時間をオシロスコープで測定する

    返信先: MSP Flasherのベリファイについて #4540

    kkk
    参加者

    御回答ありがとうございました。

    「MSP430 Programming With the JTAG Interface (Rev. AD)」の「2.3.7 Verifying the Target Memory」を確認しましたが、ベリファイでの処理内容が分かりませんでした。
    StartAddrで示されたアドレスからメモリエリアの最後まで巡回冗長検査(CRC)を実行して、書き込んだファイルでの計算結果と書き込まれたマイコンでの計算結果が一致することを確認しているのでしょうか?

    返信先: マイコンの保管期限について #3324

    kkk
    参加者

    御回答ありがとうございました。

    1について、
    べークを実施しなかった場合はどのように考えれば良いのでしょうか。
    開封した状態で2-3時間の作業後にベークをしないで再密封すると、保管期限は165-166時間と考えれば良いでしょうか。

    また、開封した状態での作業をMSL環境条件 5~30℃、40~60%RH、または10%RH以下の状態で実施すれば、保管期限は短くならないのでしょうか。

    • この返信は6 年前に  kkk さんが編集しました。
    • この返信は6 年前に  kkk さんが編集しました。
    返信先: MSP430F5329のマイコン停止不具合 #2687

    kkk
    参加者

    御回答ありがとうございます。
    ご紹介頂いたアプリケーションレポートを確認してみます。

    御回答頂いた内容について、静電気印加によりマイコンが停止した後、電源ON/OFFにより正常に復帰したため、デバイスの破損ではないと考えています。

    また、通信線の回路パターンがマイコンの裏を通っているため、回路パターンを切り、代わりにジャンパー線を接続することで通信線の回路パターンをマイコンから遠ざけたところ、静電気印加によるマイコン停止が発生しなくなりました。
    ノイズが重畳した回路パターンがマイコンの裏を通ることで、RST端子によるリセットがかからないマイコン停止が発生することはあり得るのでしょうか?

    • この返信は6 年、 1 ヶ月前に  kkk さんが編集しました。
    返信先: タイマカウントの読み出しについて #2468

    kkk
    参加者

    了解しました。
    御回答ありがとうございます。


    kkk
    参加者

    返信が遅くなり、申し訳ありませんでした。

    データ要求のためにコマンドを送信しており、その際にオーバーランエラーフラグがONになっていることを確認しました。
    しかし、上記のコマンドを送信後に3バイトデータを受信するのですが、1バイト目の受信バッファデータを読み出すとUCOEがOFFになり、次の2バイト目の受信バッファデータを読み出す直前にはUCOEがONになっていました。
    そのため、データを送信しておらず、データを受信するだけの状態でもUCOEがONになってしまう状況が発生しています。

    どのタイミングでUCOEがONになっているか確認したいのですが、デバッガ(CCS)によってUCOEがONになったタイミングを表示、またはブレークをかけることは可能なのでしょうか。


    kkk
    参加者

    1.eUSCI_A1 受信割り込み以外にSPI通信時には下記の割り込み処理を設定しています。
     Timer_B0、Timer_A0、RTC_C

    2.このときの波形ではUCOEがセットされていたか確認していません。
     このときの波形の取得後に、UCA1RXBUFのデータ読み取り直前にブレークをかけると、MSP430が
     受信後(クロック出力が8クロック出力)にブレークがかかり、レジスタの値を確認してUCOEが
     セットされていることをデバッガと波形で確認しました。
     UCOEがセットされるときの波形の取得方法についてですが、タイマによって数μs間隔で割り込み
     をかけて、UCOEを監視およびポート出力を制御する方法で良いのでしょうか。
     他に良い方法があれば教えて頂けないでしょうか。

    また、他の割り込みによる処理の遅延について、上記2.のようにUCA1RXBUFのデータ読み取り直前に
    ブレークをかけて確認した際に、MSP430が受信後にブレークがかかりUCOEがセットされていること
    を確認したため、処理の遅延が無い場合でもUCOEがセットされていると考えています。
    (他の割り込みによる処理時間はSPI通信の8ビット送信時間(128μs)の半分以下なので、割り込み
    による遅延でオーバーランエラーは発生しないだろうとも考えています)


    kkk
    参加者

    1.マイコンの型番は「MSP430FR6879」になります。
    2.リセット直後はUCOEはOFFになっています。
     どのタイミングでUCOEがONになったかは確認できていません。
    3.SPI通信の信号波形を確認したところ、MSP430が受信(クロック出力が8クロック出力)後、UCA1RXBUFのデータ読み出しの前に送信 側からデータが送られていますが、1ビットデータを読み出す直前(クロックの立ち下がり直後、設定UCCKPH=0、UCCKPL=1)に  UCA1RXBUFのデータを読み出しています。(添付ファイル参照)
     そのため、新たに8ビットデータを受信する前にUCA1RXBUFのデータを読み出しているので、UCOEはONにならないはず、と考えて
     います。

    返信先: PMM29の回避策(3)について #1938

    kkk
    参加者

    <p>投稿内容がバグっており、投稿内容の編集も削除もできないので、返信で再度投稿します。</p><p> </p><p>PMM29の回避策(3)について、『FRCTL0 = FRCTLPW』と『FRCTL0_H = 0』はレジスタの書き込み許可と書き込み禁止をしていると分かるのですが、『GCCTL0 = FRPWR』が何をしているのか分からないので処理内容を教えてください。</p><p>「FRPWRを維持したままFRLPMPWRをクリア」とコメントが付いていますが、『GCCTL0 = FRPWR』だけでFRLPMPWRもクリアされるのでしょうか?</p>

15件の投稿を表示中 - 16 - 30件目 (全30件中)