フォーラムへの返信
-
投稿
-
解決されたとのご連絡ありがとうございます。
また何か、ご不明な点がありましたら、お気軽にお問い合わせください。
UniflashはJTAGによる書き込みのみサポートしており、SCIブートによるフラッシュメモリの書き込みには対応しておりません。
SCIブードは、シリアル通信で受信したプログラムをSRAMに書き込み、そのプログラムを実行するモードとなっており、フラッシュメモリへの書き込みには対応していません。SRAMに書き込むプログラムとしてフラッシュ書き込みファームウェアを用意いただき、そのファームウェアを使用してシリアル通信とフラッシュメモリへの書き込みを実施して頂く必要があります。
C2000wareにはSCIブートを使用したフラッシュメモリ書き込みのPCツールが用意されております。このツールには、SCIブートにてSRAMへ書き込むファームウェアバイナリが用意されておりますので、ご確認いただけたらと思います。
SCIブート用のプログラムは、C2000wareをインストールしていただくと、以下のフォルダに格納されております。
<C2000ware Install folder>\utilities\flash_programmers\serial_flash_programmer書き込み完了後、ブートモードをBoot from flashの設定に変更して電源を入れ直すことで、フラッシュメモリに書き込まれたプログラムが実行されます。
エミュレートモードにつきましては、ご認識のとおりとなります。そのため、通常時にJTAGがアクティブにならないように、データシートでは、TMS端子に2.2kΩでプルアップしていただくことを推奨しております。
TMS320F28004Xでも、ブートモードの切り替えについては、GPIOで行います。
ブートモードピンとして使用される端子は、GPIO24とGPIO32となっており、これらの端子が両方1で、Boot from Flashとなります。F28004Xコントロールカードでは、右上にあるS1で設定できます。S1のスイッチを上側（スイッチOFF）でフラッシュメモリからのブートになります。
ご購入いただいた状態でBoot from Flashの設定となっていますので、書き込み後に書き込みツール（CCSまたはUniflash）を切断状態にして、電源を入れ直して頂ければ、USBケーブルをつないだままでもフラッシュメモリからプログラムが実行されます。コントロールカードのスイッチの詳細につきましては、Piccolo F280049C controlCARD Information Guideに記載されておりますので、こちらの資料も合わせてご確認ください。
過去のC2000デバイスでも、ブートモードの切り替えはGPIOにて行われており、TRST端子はエミュレータ（XDS）接続の判定に使用されるものとなります。
JTAGの規格（IEEE Standard 1149.1-1990）では、TRST端子はオプションとなっており、TRST端子に代わる信号として、TMSとTCKを用いた制御が行われます。cJTAGは接続信号を削減することが目的となっており、コントロールカードをご利用の際には特に必要ないものと考えております。ご設計される基板でcJTAGを使用される場合に、cJTAGの評価・動作確認を行う際にご利用頂ければと思います。
ご確認いただいた推奨回路の上にあるNoteによりますと、最新のXDSコントローラが以前の製品より信号の立ち上がり時間/立ち下がり時間が早い信号ドライバを使用するため、反射の影響を抑えるためとあります。
Note: The following diagram deviates from previous TI documentation in that TI now suggests utilization of series termination resistors on the JTAG clock signals and TDO. The reason for this change is the latest XDS controllers utilize signal drivers with faster rise and fall times than previous generations, thus increasing the chances of reflections on these critical signals.
実装がない場合は、通信エラーが起こり、JTAG接続が切断される可能性があります。
モジュールのパタンアンテナですと、素人目にはダイポールかモノポールアンテナ風の指向特性でしょうか….。
パターンアンテナの指向性につきましては、形状によりさまざまですので、使用されているモジュールメーカー
に確認いただくほうが良いかと思います。棒状のアンテナを外部アンテナとすると、円状に変わり指向特性一様化が期待できる…とかでよいでしょうか。
こちらも、同じような棒状でも内部の構造により指向性がある場合がありますので、アンテナメーカーにご確認
いただくことをお薦めいたします。
先程の返信にも記載しましたが、外部アンテナにすることで、設置位置を自由にすることができ、アンテナ周辺の環境に依存しにくくなることもメリットになるかと思います。これにより、「到達距離や安定性に寄与」、しかもわずかな差異とは限らない、良いでしょうか。
はい、その様にお考え頂ければと思います。
ところで、アンテナ利得が、+3dBiということから、送信出力が増加する/しない？
dBiは理想点アンテナとの比でしかなく、指向特性が変わるだけ、あるいは送信出力アップが起こり得る、ということが判りません。指向性と利得の関連につきましては次のサイト資料が参考になるかと思います。
http://www.rf-world.jp/bn/RFW04/samples/p126-127.pdfまた、WiFiのアンテナでは、くねくねと自由に曲がることができるものを見かけますが、WiFiは指向性が高いので有効と想像します。
922MHzでは、縦置き/横置き位しか影響ないとの理解…..たいして曲げても効果期待できないとの理解で良いでしょうか？申し訳ありませんが、アンテナの内部構造にも依存することですので、効果についてはわかりかねます。
アンテナの特性につきましては、アンテナメーカーさんのサイトに詳しく記載されておりますので、
そちらをご参照いただけますでしょうか。一般論として、あくまで参考にしていただけたらと思います。
アンテナの利得に関しては、電波法として+3dBi未満ですので、外部アンテナにすることで無線到達距離や無線通信の安定性などに大きな差が得られる可能性はあります。
基板搭載のアンテナですと、基板形状や周辺構造、アンテナ特性により、指向性が生じます。これらの影響を抑えるためには、外部アンテナが必要となってきます。またダイバーシティを実装したい場合には、外部にアンテナスイッチ＋アンテナの構成が必要になるかもしれません。
基本的には、モジュール搭載のアンテナで、システム的に問題がある場合に、外部アンテナにより問題点を解決していくという考え方で良いのではないかと思います。
F280049M検証用キットの回路図、Gerberデータにつきましては、C2000Wareに収録されております。
http://www.tij.co.jp/tool/jp/c2000ware
このサイトの注文にある”ソフトウェア”ボタンからC2000wareインストーラをダウンロードの上、インストールしてください。
インストールいただきますと、以下のフォルダにF280049M検証用キットのハードウェア情報がありますので、ご確認ください。<C2000Wareインストールフォルダ>\boards\controlCARDs\TMDSCNCD280049M\A
よろしくお願いいします。
ご確認ありがとうございます。
XDS100をご利用の場合に問題がなく、XDS110に置き換えたときに発生する場合は、以下のことが考えられます。
XDS110はXDS100と比べてドライブ能力が弱く、TRSTやTDOなどJTAG信号を基板側で
プルアップ・プルダウンがTI社のリファレンス・要求と異なる場合に、XDS110の出力が、規定電圧に
ならない場合がございます。エミュレータヘッダからの回路に関して、以下の推奨回路とご確認いただけますでしょうか。
回路図上問題がない場合、一度JTAG信号（TRST, TDI, TDO, TMS, TCLK）の信号波形を取得いただけますでしょうか。
XDS100（正常接続）とXDS110（接続失敗）で、どのような信号レベルに差があるのか確認いただくと、
解決に結びつくことがあります。
大変申し訳ありませんが、画像のメッセージのみでは、エラーの詳細がわかりません。
何点か確認をさせてください。
1）エラー発生時のConsoleに表示される内容を全文テキストでコピー&ペーストしていただけないでしょうか。
2) Code Composer Studioからの書き込みは正常に行えておりますでしょうか。
3) Uniflashのバージョンはいくつでしょうか。
なお、エラーメッセージ画像の中に、error -1135が見えますが、こちらのエラーについては、
以下のサイトが参考なるかと思います。ご一読いただけないでしょうか。○Debugging JTAG Connectivity Problems – C28x the debug probe reported an error
よろしくお願いいたします。
新しいBLE Stack v2.2.2が、TI-RTOS 2.21.01.08に対応しております。
Project ZeroにこちらのBLE Stackへの対応を行っていただけないでしょうか。
以下にProject Zeroに対してBLE StackおよびTI-RTOSの変更方法を記載させていただきます。
すでに実施されているとは思いますが、参考にしていただけたらと思います。- TI-RTOSバージョン変更
アプリケーションプロジェクト（project_zero_app_cc2650launchxl）のプロジェクトプロパティより、General -> Productsタブ にある「TI-RTOS for CC13xx and CC26xx」のバージョンを”2.21.1.08”に変更します。 - 環境変数（パス設定）の変更
アプリケーションプロジェクト（project_zero_app_cc2650launchxl）とスタックプロジェクト（project_zero_stack_cc2650）双方のプロジェクトで参照する環境変数（パス設定変数）を変更します。
プロジェクトプロパティより、Resource – Linked Resource画面にて、以下の環境変数を修正します。● CC26XXWARE
変更前）${EXT_TI_PRODUCTS_DIR}\tirtos_cc13xx_cc26xx_2_20_01_08\products\cc26xxware_2_24_02_17393
変更後）${EXT_TI_PRODUCTS_DIR}\tirtos_cc13xx_cc26xx_2_21_01_08\products\cc26xxware_2_24_03_17272●TI_RTOS_DRIVERS_BASE
変更前）${EXT_TI_PRODUCTS_DIR}\tirtos_cc13xx_cc26xx_2_20_01_08\products\tidrivers_cc13xx_cc26xx_2_20_01_10\packages
変更後）${EXT_TI_PRODUCTS_DIR}\tirtos_cc13xx_cc26xx_2_21_01_08\products\tidrivers_cc13xx_cc26xx_2_21_01_01\packages●TI_BLE_SDK_BASE
変更前）${EXT_TI_PRODUCTS_DIR}\simplelink\ble_sdk_2_02_01_18
変更後）${EXT_TI_PRODUCTS_DIR}\simplelink\ble_sdk_2_02_02_25 - ボード定義ファイルの変更
アプリケーションプロジェクトのBoardフォルダにある次の2ファイルを、BLE Stack 2.2.2に用意されているファイルに置き換えます。
ファイル名： CC2650_LAUNCHXL.c / CC2650_LAUNCHXL.h
BLE Stack 2.2.2： C:\ti\simplelink\ble_sdk_2_02_02_25\src\boards\CC2650_LAUNCHXL
以上の修正により、BLE StackおよびTI-RTOSのバージョンを変更し、Project Zeroが正常に動作していることを確認しています。
お手数ですが、BLE Stackのバージョンを変更のうえ、UART動作をご確認ください。よろしくお願いします。
BLE-STACKは、TI-RTOS バージョン2.20.01.08をベースに作成されており、他のバージョンでは正常に動作いたしません。
特定の機能のみ、バージョンを変更することはおすすめしておりません。
TI-RTOS バージョン2.20.01.08のUART Echoサンプルプロジェクトでも、文字化けは発生するのでしょうか。
ご確認のほど、よろしくお願いします。
USBのサンプルプロジェクトでは、ウォッチドッグ機能をディセーブルする処理および、ウォッチドッグタイマのクリア処理が実装されておりません。そのため、ウォッチドッグによるリセットが発生しているものと考えます。
デバッガをランチすると、ランチ時にウォッチドッグ機能はディセーブルされますので、デバッグ時は正常に動作しますが、デバッガを終了し、再起動すると、ウォッチドッグ機能はデフォルトの有効状態で起動します。
最終的には、ウォッチドッグ・タイマをクリアする処理を追加していただくのですが、デバッグや評価におきましては、以下の様にmain関数にてRAMFUNCセクションのコピー前に、ウォッチドッグ禁止処理（DisableDog()）を追加してご確認いただけますでしょうか。
int
main(void)
{
int iStatus;
DisableDog();
#ifdef _FLASH
// Copy time critical code and Flash setup code to RAM
// This includes the following functions: InitFlash();
// The RamfuncsLoadStart, RamfuncsLoadSize, and RamfuncsRunStart
// symbols are created by the linker. Refer to the device .cmd file.
memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
#endifご確認のほど、よろしくお願いします。
-
この返信は6 年、 4 ヶ月前に Yojiro さんが編集しました。
サンプルプログラムには、レジスタアクセスを行う方法として、構造体・ビットフィールドによるレジスタアクセスのサンプルと、ドライバAPIタイプのサンプルの2種類用意されております。
構造体・ビットフィールドタイプでは、DEBUGと定義され、ドライバAPIタイプのサンプルでは_DEBUGと定義されていますので、ご利用方法に合わせて、定義して頂ければと思います。これらの定義により有効となる処理につきましては、必須の処理とは限りませんが、すべてのデバッグ機能を組み込まれる場合は、両方の定義を追加頂ければと存じます。
以上、よろしくお願いします。
リンクエラーにつきましては、DSP2802x_headers_BIOS.cmdをExcludeされる際に、同じフォルダにある”F2802x_Headers_nonBIOS.cmd”もExcludeされていませんでしょうか。エラーメッセージに出力される内容につきましては、F2802x_Headers_nonBIOS.cmdをビルド対象としていただくことで解消いたします。
FLASH初期化関数につきましては、InitFlash()がcommon\source\f2802x_sysctrl.cに定義されており、資料に記載されている通りのファイル構成で問題ありません。
FLASH_setupはdriverLibを使用したFLASH ROMの初期化ですので、driverLibをご利用になる際には、別途flash.cをExclude対象から除外いただければと存じます。ifdefスイッチで参照している定数DEBUGおよび_DEBUGにつきまして、pie.cの_DEBUGにて有効となる関数（PIE_setDebugIntVectorTable）はデバッグ時にも基本的には使用することはありません。この関数は、お客様で未定義の割り込みハンドラについても、デフォルトのハンドラを使用せずにお客様で作成されたハンドラを使用する場合にご利用いただく関数になります。
従いまして、デバッグ時は、”DEBUG”のみの定義で問題ございません。以上、よろしくお願いします。
- TI-RTOSバージョン変更