PARTNER-Jet

2018年02月15日

Depending on the PC environment, "Application hang while the debugger startup", "LoadError" or "Rebase Error" may occur. To avoid this problem, add "-rebase ADDRESS" to the start option of PARTNER in the following steps.
  1. Start PARTNER-Jet2 Configuration (JetSet)
  2. Select a target project and move to "Startup options" tab.
  3. Add "-rebase" option to the text box on the bottom right in the Startup Options tab.
[Example]
-B01000000,32 -rebase 0x40000000
The recommended value of the address to be specified for "-rebase" option is different depending on the Windows version and type of the PARTNER Application (32-bit or 64-bit). The following table shows recommended values in the different environments.
PARTNERWin7Win8/Win10
32-bit version0x40000000 0x40000000
64-bit version0x070000000000x70000000000


kmckk at 10:19

2018年02月15日

使用するPCの環境によっては、『PARTNERの起動の途中でロック』したり 『LoadError』 や 『Rebase Error』 が発生する場合があります。 この現象を回避するためには、次の手順でPARTNERの起動オプションに "-rebase アドレス" を追加します。
  1. PARTNER-Jet2 環境設定を起動します。
  2. プロジェクトを選択して、[起動オプション設定]タブを開きます。
  3. [起動オプション設定]タブ内の右下のテキストボックスに -rebase オプションを追加します。
[例]
 -B01000000,32 -rebase 0x40000000
-rebase に指定するアドレスの推奨値はPARTNERの32bit版/64bit版のEXE種別とWindowsのバージョンにより以下の様になります。
PARTNERWin7Win8/Win10
32bit版EXE0x40000000 0x40000000
64bit版EXE 0x070000000000x70000000000


kmckk at 10:11

2010年12月02日

2010年12月1から12月3日まで横浜パシフィコで開催されているET2010に出展しています。

ブース番号は A-13 です。

ブースの左端で、ノートパソコンの画面を大画面テレビに映して、Andorid対応のPARTNER-JetによるKZM-A9-Dualボードのデバッグの実演をしています。(下の写真の手前の部分。)

続きを読む

2010年11月30日

統合開発環境(IDE)はEclipseが使われることもありますが、Windowsでの開発ではMicrosoft社のVisual Studioがよく使われています。

そこで、Visual StudioとPARTNER-Jetを連携させて、PARTNER-JetにJTAGで接続した実機をVisual Studioの操作でデバッグできるようにしてみました。まだ研究開発中のものですが、参考出品としてET2010の弊社ブースで展示します。

続きを読む

2010年11月18日

KZM-A9-DualボードのLinuxのデバイスドライバのデバッグをしてます。

SDカードを読むときにエラーになってしまいます。eMMCは問題がないのになんで?

と悩んでいたらボード屋さんからSDの電源がONになっていないのでは?という情報が。

GPIOのP024をON(1)にしてみてということなので、PARTNER-JetのI/Oポートの読み書きする機能を使って試してみました。

続きを読む

2009年07月08日

PARTNER-Jet には、イベントトラッカーという機能が標準で搭載されています。

http://www.kmckk.co.jp/event_tracker/index.html

イベントというと何やら難しそうですが、ここでいうイベントとは「ターゲットプログラムの実行中に、なんらかの変化が起こった」ということを指します。例えば OS のタスク切り替えや、OS が無い場合は pc が特定のアドレスに来た場合など、任意の状態変化をイベントとしてユーザ定義することができます。

イベントトラッカーは、メモリに記録したログデータをグラフィカルに表示・解析するための汎用的なしくみを提供します。

組み込みソフトウェア開発で printf デバッグができるのは、けっこう恵まれた状況です。開発初期はシリアルコンソールすらつながっておらず、一切の I/O が使えない状況がけっこうあります。

PARTNER-Jet のような JTAG-ICE デバッガを使えば、そのような状況でも、とりあえずステップ実行をしてプログラムの動きを追うことができます。しかし、割り込み処理など、タイミングが重要なプログラムをデバッグする際には、これだけでは厳しいです。

PARTNER-Jet には、VLINK という、ターゲット上で動くプログラムから直接デバッガに printf などで出力できるという機能もあるのですが、そもそも printf 自体が比較的重い処理となるため、RTOS などのイベントハンドラの中で呼ぶことは厳しいですし、printf を呼ぶとタイミングが狂って再現しなくなってしまうバグなどもありがちです。

このような場合、イベントトラッカーが威力を発揮します。イベントトラッカーは、JTAG がつながって、メモリの読み書きができて、ログ用のバッファが確保できる状況ならば使えます。しくみが単純で処理が軽いぶん、様々な場面に使える、非常に一般的なデバッグ手法と言えます。

OS を使う場合は、Linux や各種 RTOS (T-Kernel や Toppers) など、それぞれの OS ごとに KMC が提供するパッチを当てることにより、プロセスの切り替えなどのタイミングを詳細に記録することができます。

OS が無い場合は、直接 KMC が提供するヘッダとソースコードをプロジェクトに組み込み、初期化関数を読んだ後、任意のタイミングでイベント発行関数(引数に与えられた整数がイベントとして記録されます)を呼ぶことで、イベントログを取ることができます。1 ヘッダと 1 ファイルのみなので、カスタマイズも簡単にできます。

イベントトラッカーがやっていること自体は特別なことではなく、多かれ少なかれ、どこの組み込み開発でもアドホックに行われていることだと思います。しかし、デバッガと連携した汎用のしくみが最初から提供されることにより、CPU 占有時間の計算やイベントの抽出・マスク機能など、高度な表示や統計・解析機能が簡便に使えるようになり、工数が削減できます。また、しくみが共通化されることにより、デバッグの属人性が薄まり、ノウハウの共通化が可能になるため、開発そのものだけではなく、技術教育面などにも恩恵があると考えられます。

2009年07月07日

皆さん、こんにちは。KMCの辻です。

さて、今日はPARTNER-Jet ver5.6に搭載した新しい機能「スナップショットデバッガ」についてお話します。

PARTNER-Jet ver5.6は、つい先日に僕たちがリリースした、新バージョンデバッガです。この新バージョンデバッガには、新たに「スナップショットデバッガ」という機能を追加しました。

このスナップショットデバッガを一口で説明すると、「コアダンプのCPU版」という感じでしょうか。UNIX上でのcoreファイルを使ったデバッグに似ています。PARTNER-Jetを使ってターゲットボードのソフトウェアをデバッグしている時に、デバッガ上からスナップショットを作成します。その後は、作成したスナップショットファイルを用いて、ターゲットボードなしにオフラインでデバッグを行う、という機能です。オフラインでのデバッグになるので、CPUの実行に関する事はできませんが、その他のデバッガの機能はほぼ全て利用可能です。

スナップショットファイルには、それを作成した時点でのメモリの内容とCPUの汎用レジスタや制御レジスタの情報などのほかに、PARTNER-Jetで採取していたETMやAUDなどの実行トレースの内容も保存しています。トレースデータを参照すれば、そこに至る過程も調べる事もできます。

私的な話になりますが、僕はその昔に通信機器のOSの開発をしていた事があります。電話網に使われる通信機器ですので、耐障害性など品質については厳しく”全てのバグを取り除く”という意識でのソフトウェア開発でした。しかし、難解なバグや再現性の低いバグも多く、そのようなバグ調査に実機を長時間占有させておくことも難しい事も事実でした。そのような状況でも、障害発生時に保存した実機のメモリを、ワークステーション上で解析をしてバグ対策を行っていました。また、同じ問題を一人ではなく複数人で解析したり、ファイルを転送して離れた場所の人と一緒に解析したりしていました。当時は物理メモリのファイルと、そしてシンボルデータをつき合わせて、構造体などをメモ書きしながら解析をしていました。

もちろん、このスナップショットデバッガを利用すれば、より快適にこのような作業を行うことができます(当時は本当に根性デバッグで大変でした)。

これからは、問題が発生した時には、スナップショットを保存しておくのはどうでしょうか?

記事検索
最新コメント
アクセスカウンター
  • 今日:
  • 昨日:
  • 累計:

QRコード
QRコード