フォーラムへの返信
-
投稿
-
ご確認ありがとうございます。クロック変更により接続が成功したとのこと、承知いたしました。
こちらのClockを低くすることによるデメリットはありますでしょうか。
JTAGの通信クロックが変わるため、デバッグ時のCCSとのデータ通信や、デバイスへのプログラムのロード時間が長くなる等のデメリットがあるかと存じます。
また、従来は5.5MHzでも接続可能だったのですが、
基板やケーブルの劣化などハードウェア的な問題でこちらの
前述のエラーが発生しやすくなることがあるのでしょうか。前述のエラーについては、ご紹介させていただいたURLで説明されているエラー要因の他にも、JTAG信号自体のノイズ等によって発生する可能性が有ると考えます。
従いまして、基板やケーブルの劣化などハードウェア的な問題が要因となり、問題が多発する可能性はあるかと存じます。以上、よろしくお願いいたします。
ご確認ありがとうございます。
タイトルの通りデバッグの概要についてが書かれており
書き込み手順の記載は無いようですが、リンク先に間違いないでしょうか。CCSは書き込み及びデバッグを目的としたツールとなり、ご紹介させていただいたページでは、書き込み以外にも必要な様々な設定情報を含めた内容としてご紹介させていただきました。
プログラムの書き込み手順については、「7.3. Launching a debug session」、「5.6. Building and Running Your Project」を合わせてご参照ください。以上、よろしくお願いいたします。
ご投稿ありがとうございます。
頂いたエラー内容はこちらの「Debugging JTAG – Path measure」の情報に類似していると考えます。
お手数ですが、以下の点についてご確認頂けますでしょうか。- データシート「7.9.5 Emulation/JTA」を参考に、すべての物理的なJTAG接続を確認し、電気的に信号や接続に問題がないことを確認する。
- こちらの動画をご参考にXDS110のTCLKを下げ、書き込み動作が安定するかを確認する。
以上、よろしくお願いたします。
ご投稿ありがとうございます。
・ビルドオプションのDebugとReleaseの違いについて
CCSで新しいプロジェクトを作成すると、デフォルトでDebugとReleaseの2つのビルドコンフィギュレーションが作成されます。
Debugビルドコンフィギュレーションでは、通常、最適化は行われず、フルシンボリックデバッグが有効になっており、デバッグが容易に行えるようになっています。
Releaseビルドコンフィギュレーションでは、最適化を有効にし、シンボリックデバッグを無効にして、ソースレベルデバッグの必要なく、できるだけ小さなコードや高速なコードを作成します。
CCS では、Debugの設定がデフォルトで表示されるため（新規プロジェクトの作成時およびプロジェクトのインポート時）、ユーザーは通常、コンパイラおよびリンカのオプションの変更を行う場合、Debugの設定を直接調整し始めます。コードを最適化を変更する場合、 Releaseコンフィギュレーションに切り替えることが推奨されます。
詳細につきましては、こちらの「6.1.3.11. Build Configurations」を合わせて以下の資料をご参照ください。・リリース版のプログラムは.out形式で管理して連続書き込みする予定なので、CCS上でのその手順について
CCSで書き込みを行う場合、1台単位での書き込みとなり、手順についてはこちらの「7.1. Debug Overview」をご参照ください。
なお、連続での書き込みを行う場合、下記の書き込み専用ソフトウェアツールも用意されておりますので、合わせてご参照ください。- UNIFLASH：最大1台への書き込みが可能で、ハードウェアはXDS110, XDS200が利用可能です。
- C2000-GANG-SW：同時に最大8台への書き込みが可能で、ハードウェアはC2000-GANGが利用可能です。
・CCSの比較的新しい日本語マニュアルがあるか
大変申し訳ございませんが、直近で新しい日本語マニュアルは提供されておりません。
こちらの「Code Composer Studio User’s Guide」をご参考頂けますと幸いです。以上、よろしくお願いいたします。
電源電圧が落ちていない場合でのBORの発生としては、下記の太字で示した内容が適用されるかと存じます。
基本的にはBORの発生条件はユーザーズ・ガイド「1.2 System Reset and Initialization」に記載されている通り、下記のイベントとなります。
- デバイスへの電源投入
- LPMx.5からのウェイクアップ
- SVSHが有効な場合でしきい値を下回る
- ソフトウェアによるBOR
もしくは、データシート「5.13.1 Power Supply Sequencing」の注釈(1)に記載されている通り、電源電圧の急激な変化は、推奨電源電圧範囲内であっても、BORを引き起こす可能性があります。
電源を安定化電源等に変更することや、問題の発生していない基板上のMSP430FR6972とクロスチェックを実施することで、問題の切り分けが可能かと考えます。
以上、よろしくお願いいたします。
ご投稿ありがとうございます。
また、ご返信が遅くなり大変申し訳ございません。以下に回答させていただきます。①について
下記リンクに記載の通り、現在サポートされている最新の32-bit版CCSはv8.3までとなります。
○8.1.1. Does CCS still support 32-bit Windows systems?32-bit版のサポート終了に関する情報は確認出来ませんでしたが、弊社としては64-bit版や最新版のCCSをご利用いただくことを推奨いたします。
※コンパイラのバージョン及び設定、使用しているリンカーコマンドやソースファイル内容が一致している場合、基本的に同じ.txt実行ファイルを生成できるかと存じます。②について
下記リンクに記載の通り、シミュレーションデバッグに対応しているCCSはv5.5までとなります。
○8.1.3. Are simulators no longer included with CCS?以上、よろしくお願いいたします。
ご返信ありがとうございます。
＞WDTのインターバルタイマモードですが、
＞インターバルタイマモードでは、無限ループに陥った場合は、
＞WDTのタイムアウトが発生しないという認識でよろしかったでしょうか。→”無限ループに陥った場合”の定義として、投稿いただいた時と同様にWDT以外のペリフェラルを含め、完全にシステム・CPUがハングアップしている場合では、WDTのインターバルタイマモードでの割り込みも発生しない可能性がございます。
そのため、WDTのモード切り替えでは明確な回避策にならない可能性がございます。まずは根本的な問題の特定として、現場のマイコンがフリーズする現象に対する発生条件や要因について調査いだくことを推奨いたします。
デバッグ用ソフトウェアのような無限ループの場合、インターバルタイマモードとしては、WDTIEビットとGIEビットが設定されると、タイムアウトが発生し、PUCの生成されない割り込みが発生するかと存じます。
以上、よろしくお願いいたします。
ご確認ありがとうございます。また、追加でのご連絡ありがとうございます。既にご確認済の内容もございますが、以下にまとめて回答させて頂きます。
＞リセット後は、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のどちらかのみをセットして頂ければ、意図したリセットが発行できるかと存じます。
以上、よろしくお願いいたします。
お問い合わせありがとうございます。
弊社で調査した限り、”フリーズしているのに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)になると認識しております。(もし認識が違う場合は、ご指摘頂ければと存じます。)
以上、よろしくお願いいたします。
お問い合わせありがとうございます。
大変申し訳ございませんが、PKG内の配線長情報については基本的にメーカーより公開されておりません。設計等につきましては、製品ページ上の関連するドキュメントの規定に準拠いただけますようお願い致します。
※型番は異なりますが、下記URL情報の通りとなり、本製品も同様に公開された情報は無いと想定されます。
・Am5728: Package internal bond wire length
・66AK2H12 internal pattern length into the K2H package以上、よろしくお願いいたします。
ご投稿ありがとうございます。
大変申し訳ございませんが、お問い合わせいただいた製品につきましては、NRNDとなっているためご回答出来かねます。※現在Webページより、製品ページや各種ドキュメント、ソフトウェア情報が確認出来ない状態となっております。そのため、添付頂いた画像のResource Explorerでの情報もアクセス出来ない状態かと存じます。
新規ご設計で検討いただいている場合は、以下のURLより代替品等をご検討頂けますようお願い申し上げます。
以上、何卒よろしくお願いいたします。
ご投稿ありがとうございます。
頂いたご質問につきましては、現在メーカーに確認させていただいておりますので、大変恐縮ですが、少々お時間頂けますと幸いです。
なお、本フォーラム上では共有が出来ないファイル内容の場合は、個別にメールでご連絡させていただければと存じます。
以上、よろしくお願いいたします。
ご質問ありがとうございます。
（組込み技術ラボ フォーラム システム上のトラブルにより、対応が遅れましたこと、お詫び申し上げます。誠に申し訳ございません。)大変恐縮ですが、上記を実現するための専用サンプルコードは用意されていないため、以下のURL情報等をご参照頂き、貴社にてソフトウェアを作成した上で、十分に実動作をご確認いただけますようお願い申し上げます。
頂いた内容については、①側の受信データをFRAMに転送する際、もしくは②側の送信データをFRAMから転送する際に、DMAと組み合わせて使用することで、ある程度の並列処理が可能かと存じます。
①センサ→マイコン内部レジスタ→DMA→FRAM
or
②FRAM→DMA→マイコン内部レジスタ→Flashご留意点としては、MSP430のデータバスの構造上、DMAによるデータ転送の間(数サイクル)はCPUがバスアクセス出来ません。
また、センサからのデータをFRAMへ保存するタイミングが、Flashへ保存するタイミングに間に合わない場合、Flashに保存するデータが正しく反映されない可能性がございますので、ユーザー側でタイミングを調停する必要がございます。参考URL情報
■MSP430FR58xx, MSP430FR59xx, and MSP430FR6xx Family User’s Guide (Rev. P)
・Chapter 11 DMA Controller■各ペリフェラルのサンプルコード
・msp430fr599x_dma_01.c以上、よろしくお願いいたします。
-
この返信は2 年、 1 ヶ月前に umamiti さんが編集しました。理由: リンク未挿入のため
お問い合わせいただきありがとうございます。
F28065のTMUの評価を行っているのですが、平方根演算を行うと、演算結果＝入力値となってしまいます。
どのような原因が考えられるかアドバイスをいただけたらと思います。F28065にはTMUは内蔵されておりませんので、以下のURLよりダウンロード可能な「C2000WARE」内のサンプルコードをご参考に動作をご確認頂けますでしょうか。
URL：https://www.ti.com/tool/ja-jp/C2000WARE
PCへインストール後、下記のパスにCCSへインポート可能なプロジェクトが確認できるかと存じます。
C:\ti\c2000\C2000Ware_4_01_00_00\libraries\math\FPUfastRTS\c28\examples\isqrt_f32
C:\ti\c2000\C2000Ware_4_01_00_00\libraries\dsp\FPU\c28\examples\math\fastsqrt_f32
C:\ti\c2000\C2000Ware_4_01_00_00\device_support\f2806x\examples\cla\sqrtまた、古いバージョンのCCSを使用しているのですが、関係ありますか？
CCSバージョン：6.2.0.00050
Compilerバージョン:TI v15.12.3.LTSバージョンによる関係性については現在の情報のみではコメント出来かねますが、弊社としましても可能であれば比較的新しいバージョンをご利用いただくことを推奨いたします。
例）
CCS：v10.4.0：https://software-dl.ti.com/ccs/esd/documents/ccs_downloads.html#code-composer-studio-version-10-downloads
Compiler：上記CCSに付属のバージョン以上、よろしくお願いいたします。
ご連絡が遅くなり、大変申し訳ございません。メーカーより回答を頂きましたので、以下に回答させていただきます。
＝＝＝以下、メーカー回答＝＝＝＝＝＝＝＝＝＝＝＝＝
VDDIO/VDDの動作中の降下や外部LDOの故障が懸念される場合、現在のシステムでは電源からのオンチップXRSnゲートでは十分でない可能性があります。リスクは、リセット・ロジックが前述したスレッショルドに従ってXRSnをロー・ドライブする前に、デバイスがVmin制限の範囲外で動作することです。
申し訳ございませんが、弊社が提示できる定格外(1.01～1.14Vの推奨電圧範囲外かつPORにかからない領域)での動作時間の規定はありません。定格外で動作した場合、データシートに見合った性能を保証することができなくなります。 そのため、いかなるタイミングでもデバイスが正しく動作しないリスクがあり、その故障がどのようなものかは不明となります。
VDDIO/VDDの動作中の降下や外部LDOの故障が懸念される場合に関しては、公称電圧でこれを考慮できるLDO/電源ICを選択することを推奨いたします。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝