2014年01月24日

STLink/v1/v2ドライバとOpenOCD/STLink Utilityの使い方まとめ

STLink/v1/v2ドライバとOpenOCD/STLink Utilityの使い方まとめ
いつか書こうと思っていた。。。
STM32 Discoveryボード群を使う時の、
OpenOCD用のドライバとSTMicro純正ドライバの「切り換え方法」と「確認方法」のまとめです。

STM32でSTLink/v1/v2を使う時に、よくハマってしまって、
もう我慢できません。(爆(爆

* 前提条件
 (1)Windows7(32bit)環境。
 (2) ARMマイコン用のCコンパイラはLaunchpadのarm-none-eabi-gcc。
        https://launchpad.net/gcc-arm-embedded
 (3) STM32 Discoveryボード搭載のSTLink/v1/v2をそのままボード上のマイコンに対して使う場合です。
 (4) OpenOCDバイナリは、ねむいさん(http://nemuisan.blog.bai.ne.jp)のバージョンv08を 
    使用させていただいております。(注1)

* STLink/v1 : STM32VL-Discovery
(1) STM32VL-Discoveryボードで STLink Utilityを使いたい
    ** ST original driver : USBSTOPR (v6.1.7601.17577)(zadigで見た時)
         確認方法:
             (a) ボードをUSB接続ケーブルにつないだ時に、
                 Windowsの「リームーバル・ディスク」として見えていればOK。
                (USB接続時にドライブ認識のメッセージが出る)
             (b) zadigで確認すると「USBSTOPR」ドライバと出るはず。
         状態:
             STLink Utility OK
             OpenOCD NG:
         補足:    
            STM32VL-Discoveryボードを購入してSTMico純正ドライバのみをインストール
            した直後なら、この状態(USBSTOPRドライバ(zadigで確認すると))になっている。
            OpenOCDは使えません。
        
(2) STM32VL-Discoveryボードで OpenOCDデバッグしたい 
    ** OpenOCD driver : WinUSB (v6.1.7600.16385)
         設定方法:
             (a) STM32ーDiscoveryボードをPCにUSB接続しておく。
             (b) 「zadig」を起動して、
               「Options」-「List All Devices」して、リストから「STM32 STLink」を選択。
               「Replace Driver」ボタンを押す。
         確認方法:
             「デバイスマネージャ」−「Universal Serial Bus devices」で、
            「STM32 STLink」と表示さていればOK。
         状態:
             STLink Utility NG
             OpenOCD OK
         補足:
             OpenOCDデバッグ/書込み専用状態です。
             STLink Utilityを使いたい時は、下記(3)を実施する必要があります。
            
(3) STM32VL-Discoveryボードで OpenOCDデバッグしてたけど、STMicro純正ドライバに戻したい
             (a) 「デバイスマネージャ」−「Universal Serial Bus devices」で、
                 「STM32 STLink」を右クリック−「削除」で
                  「このデバイスのドライバーソフトウエアを削除する」にチェックしてOK。
             (b) USBケーブルを挿し直す。
                 上記(1)の状態が確認できればOK。
                 STLink Utilityが使える様になります。

* STLink/v2 : STM32F0/F3/F4-Discovery の場合
  これらのボードは、
  STMicro純正のWinUSBドライバでOpenOCD/STLink Utility双方の利用が可能です。
  STLink Utilityをインストールする時に、専用ドライバがインストールされるので、それ以外
  なにもしなくてよいです。
  特に、STLink Utilityを使いたい時は、zadigは、いじっちゃいけません。:D
  ** STMicro Original driver : WinUSB
     確認方法:
            (a) ボードをPCにつないでおく。
            (b)「デバイスマネージャ」
                −「ユニバーサル・シリアルバスコントローラ」で、
                「STMicroelectronics STLink dongle」と表示されていばOK。
     状態:
         STLink Utility OK
         OpenOCD OK
      
 (1) zadigで「WinUSB(vXXX.XXX)」をインストールしちゃったみたい
    まず、zadigでインストールする「WinUSB(vXXX.XXX)」というドライバは、STMicro純正の
    「WinUSB」(バージョンなし)ドライバとは別物の様です。
     表記が微妙なので混乱しますが、そういう事の様です。
     この場合、OpenOCDは使えますがSTLink Utilityが使えなくなります。
     確認方法(1):
             (a) STM32ーDiscoveryボードをPCにUSB接続しておく。
             (b) 「zadig」を起動して、
               「Options」-「List All Devices」して、リストから「STM32 STLink」を選択。
               「Driver」が「WinUSB(vXXX.XXX)」になっているならSTLink Utilityは使えません。
     確認方法(2):
             「デバイスマネージャ」−「Universal Serial Bus devices」で、
            「STM32 STLink」と表示さているならSTLink Utilityは使えません。
     状態:
         STLink Utility NG
         OpenOCD OK

(2) なんか、おかしくなっちゃったっ!!(爆(爆
    STLink/v2使用時にzadigをいじる必要はないものの、
    思わず別のドライバに変更してしまった可能性があります。 orz orz (TT) (爆
    例えば上で書いた、
    「WinUSB(vXXX.XXX)」や「LibUsb-win32」等々。
    修復方法:    
            (a) ボードをPCにつないでおく。
            (b)「デバイスマネージャ」で、
                「Universal Serial Bus devices」の
                「STM32 STLink」を右クリック、
                「ドライバソフトウェアの更新」、
                「コンピュータを参照して。。。」、
                「コンピュータ上のデバイスドライバーの一覧から選択」、
                「STMicroelectronics STLink dongle」を選択すると
               直ります。
     修復後のzadig上の表示:
     Driver:
     「WinUSB」->「WinUSB(vXXX.XXX)」
     修復後の状態:
         STLink Utility OK
         OpenOCD OK
    補足:
       zadigで他の正しくないドライバをインストールしてしまった場合でも、
       「デバイスマネージャ」中で「STM32 STLink」というUSBドライバを捜しだして
        上記の方法で修復することができます。

(3) まとめ
   STM32F0/F3/F4-Discoveryボード上のSTLink/v2を使って、OpenOCDデバッグのみをするなら、
   「WinUSB(vXXX.XXX)」ドライバになっていたとしても大丈夫ですが、
   STLink Utilityを使う時は、上記(2)を実施してドライバを入れ替えます。

* STLink Utilityを使う理由
   (1)GUIソフトでサクッとHEXファイルが書き込める。
   (2)コマンドライン書込み用のソフトも使える。
   (3)マイコンとデバッガ部分の最低限の生存確認ができる。
   (4)ボード上のSTLink用マイコンのファームアップデートができる。
   等々。
   特に(3)は精神衛生上できた方が良いかな。



(注1)成り行き上、ボード用のCFGスクリプトは付属の「stm32f0discovery.cfg」、「stm32vldiscovery.cfg」。。。(以下同じ、)
       をocd起動時に指定して使っていますが、ねむいさんの「xxxx_flash.cfg」系を使った方が
	   良いと思います。:D
      



posted by Copyright (C) avrin All Rights Reserved. at 00:00| Comment(0) | TrackBack(0) | OpenOCD | このブログの読者になる | 更新情報をチェックする

2010年08月15日

OpenOCD: Eclipseを256倍...orz

OpenOCD: Eclipseを256倍 ... orz
* はじめに
以下は無料で使える「素のEclipse」の話。
今なら、Eclipse galileo + CDTのことだ。


* コンパイル時に自動で未保存ファイルを保存する

この程度のことがデフォで設定されていないなんて

もうEclipseを使いたくない。

と思った。
血眼(ちまなこ)になって探した結果発見した。
が、
もう疲れた。orz

Eclipseのトップメニューから
「ウインドウ」-「設定」-「一般」-「ワークスペース」で、

1,「ビルド前に自動に保管」にチェックを入れる。

2,ついでに
	「自動的にリフレッシュ」にチェックも
	
	力強く推奨します。

  ファイルを追加した時に自動でコンパイル対象になるので
  かなり便利になります。
  じゃなくて。
  ようやくこれで普通の使い勝ってになります。

	つか、なんでこれがOFFなわけ?
	
  orz



*CPUレジスタ値を16進数で表示する。

これのやり方がずっと不明でレジスタ群がデフォで
「10進表示」とかなりイヤな状態だった。

もうEclipseを使いたくない。

と思っていた矢先、解決した。 orz

orz なのか?

LPCXpressoのナレッジベースに書いてあった。
(ログインすると見られる)


Eclipseのトップメニューから
「ウインドウ」-「設定」-「C/C++」-「デバッグ」で設定出来る。 orz

orz なのか? 



* ARM GCC(Codesourcery etc)ツールチェーン対応プラグイン
無料のEclipse(今ならGalileo+CDT)に
ARM GCCツールチェーン対応プラグイン
を入れます。

Codesourcery、やYAGARTO、DevkitProに対応していて結構便利。
マップファイルやリストファイル、コンパイル結果サイズなどを
デフォで出力可能になっています。

コンパイルオプション設定画面(ほとんど設定済み)も
独自に持っていて便利。

このプラグインを入れた後、プロジェクトの新規作成画面で
Codesourcery、やYAGARTO、DevkitProなどが選べる。
arm-gcc-cdt-plugin.gif
あとはソースコードとリンカースクリプトを登録して
コンパイルオプションを必要に応じて少し修正すれば
即コンパイル可能になります。(注1)

以下がCodesourcery用のコンパイラ設定画面
CPUタイプもリストから選べる。
 arm-gcc-cdt-plugin-setup.gif

注意点:
アセンブラファイルの拡張子が小文字、例えば
「startup.s」だとアセンブラが認識してくれないので大文字に
変える。「startup.S」のように。 orz

(注1)スタートアップコードとリンカスクリプト、
CMSIS等は自前で用意、登録する必要がある。















posted by Copyright (C) avrin All Rights Reserved. at 23:19| Comment(0) | OpenOCD | このブログの読者になる | 更新情報をチェックする

2010年07月31日

OpenOCD:CMSIS: lpc1768/STM32 I/Oビュー画面の研究(Peripheral view magic)

OpenOCD:CMSIS: lpc1768/STM32 I/Oビュー画面の研究(Peripheral view magic)


ocd-pv-magic-logo2.gif
I/Oビュー画面が何かは以下で述べた。 OpenOCD vs LPCXpresso (IOビュー画面) I/Oビュー画面を持たない無料系のデバッガで「簡単にI/Oビュー画面」機能を 持たせる試みです。 io_vew_lpc17xx.gif io_vew_lpc17xx-expand.gif 上はOpenOCD+EclipseでI/O View表示してみた。 insight-io-view.gif Insightでも表示してみた。 良いよい。 raid7-io-view.gif STM32を持っていないので上はRaid7のシミュレータで「io view」を表示してみた。 大丈夫そうだ。(Raid7では「未使用変数」を消去しないような設定が必要) *原理 やりかたは何種類かあるけど、例えば
#include "LPC17xx.h"

LPC_SC_TypeDef * const IO_SC_ = LPC_SC;

と定義してやると上の方に掲載した画像のように「IO_SC_」が 「変数ウインドウ」に表示可能になります。 同様に、 IO_GPIO0_,IO_ADC_とか47個ほど(LPC1768)あるので全部宣言すれば終了です。 宣言1個あたり「4バイト」(ポインタなので)消費します。 47個あるので190バイトくらい必要です。 SRAMに割り当ててもたいした量じゃないけど、 「このポインタ自身は絶対変更されないので、変数である必要はない」。 従って、「const」を付けてFlashに割り付けたのがミソかな。 SRAMの消費量はゼロです。 (別な思考としては、 I/Oマップ用のセクションを作成、そのセクションに変数として割り当てる というようなやり方。これはリンカスクリプトの変更が必要そうなので 今回は不採用。(未検証)(SRAMもFLASHも消費しない?)) *効能 かなり便利です。 I/Oビュー機能のない「Eclipse」や「Insight」、「TrueSTUDIO Lite」でも 簡単に表示できます。 1,定義さえすれば、LPC1768,STM32でも同様。 2,非常に簡単に組み込める。(プロジェクトにファイルを1つ追加するだけ) 3,CMSISの「LPC17xx.h」が必須だけど「LPC17xx.h」だけもってくれば   他のCMSISファイルと関係なくI/Oビューが利用できる。   (STM32も同様)   と。思ったが、   「LPC17xx.h」の中からインクルードしているファイルがあるので   CMSIS環境が良い。 *注意点 1,分解能がレジスタ単位。一部は8ビット単位。   ビット単位のビューは出来ない。(手動で作る例を後述) 2,定義ファイルの最適化を「OFF」にする。   (「Unused」で抹消されるのを防ぐため。) *状況 LPC2388とLPC17xxはレジスタ構成に共通部分が多いので 共通部分のLPC2388用「IO VIEW」を作るのは比較的アレかも。 *使い方 LPC17xx用:io-view-lpc1768-v01-201008.zip STM32f10x用:io-view-stm32f10x-v01-201008.zip 以下LPC1768で説明。 1,解凍して出来た「LPC17xx_io_view.c」を自分の任意のプロジェクトに追加します。 2,このファイルのコンパイル時の「最適化をなし」に設定します。   gccなら「-O0」(オーゼロ) 3,プロジェクトを普通にビルド、デバッグ開始。   すると、グローバル変数登録画面に現れるので登録する。   手動で登録する場合は「IO_ADC」等と入力する。(Insightなど)   (「LPC17xx_io_view.c」の中身参照。 *ビット構造の表示 ビット構造表示用の定義はないので自前で作る必要がある。 LPC17xxの「etc」フォルダにある「LPC17xx_io_view_bits.c」が具体例だ。 よく参照するレジスタだけ定義して使うと良いだろう。 io-view-bits.gif 上はステップ実行で変化したビットが黄色で表示された図。 (2010/08) *ねむいさんのLPC1343/LPC11xx対応版 ねむいさんが LPC1343/LPC11xx対応版を作成されました。 ここの kickstartプロジェクトに含まれています。 さらに便利になったと思います。
posted by Copyright (C) avrin All Rights Reserved. at 21:46| Comment(4) | OpenOCD | このブログの読者になる | 更新情報をチェックする

2010年07月26日

OpenOCD: lpc1768 + JTAG + Eclipse + GDB Debug 設定

OpenOCD: lpc1768 + JTAG + Eclipse + GDB Debug 設定

*Synopsis(概要)
*lpc1768/Eclipse側 設定
*lpc1768/OpenOCD側 設定
* lpc1768/ reset-initイベントハンドラ
*その他の設定(lpc1768)
*「soft_reset_halt」がキモだった(lpc1768)
*ベクタ・チェックサムについて(lpc1768)
*soft_reset_haltの位置(lpc1768)
*soft_reset_haltの位置(lpc1768) (2)

*Synopsis(概要)
やりたいことは
lpc1768ボードにJTAGアダプタつないでEclipseで
デバッグ(ステップ実行、etc)したい。

具体的には、
Eclipseで「デバッグ・ボタン」押したら、
実行ファイル(ELFファイル)をlpc1768にロードしたあと
「main()関数の先頭」にbreakで
停止するところまでやってほしいのだ。

ここに書いてない設定は他の人のページを参考にした。

諸条件:
Eclipse galileo 
OpenOcd v0.4.0
lpc1768ボードは汎用品(以前のブログに書いたもの)。
JTAGアダプタ(oocdlink-s互換品)。

で、
「キモ」の設定。

*lpc1768/Eclipse側 設定

赤丸の部分。
lpc1768-eclipse-gdb.gif
最初の1行目はみんな同じなので、
残り「たったの4行」を設定するのに

どどどどっと、大変だった。

何故なら、そもそも「lpc1768用」の設定例がWebで見つけられなかった。
のと。「他のをまねしてみても」ダメだったのだ。 orz
でも、
動いてみればlpc1768固有の設定項目はない風に見える (^^;

実は上の赤丸部分の「書き方」が多数存在し混乱気味なので、
なるべく上のように「CPUボードやCPUに依存しない書き方」が
望ましいといえる。

もし固有の設定があるなら「reset-initハンドラ内」或いは関数一つに内包する
ような記述にしたほうが良いだろう。
(まぁ、ケースバイケースかもしれないが)

と、いいますのも、
Eclipse(gdb)側の設定を複雑にしてしまうと
「難易度がさらに」上がってしまうと思うのです。

(爆

*lpc1768/OpenOCD側 設定

実のところ、こっちもWeb上に
「OpenOCD+lpc1768 + Eclipse + gdb」でデバッグ出来た設定例はなかった。

「JTAGのTAP情報が読み出せた」までの例は見つかるが
「デバッグ出来た設定例」はなかった。

別にWebに書く義務はないわけだけど (^^; (^^;
書いてあると助かるなぁ〜〜って思うわけです (オイ

考えられるのは
1,すごく簡単な設定で誰でもわかるので「書くまでもない」か、
2,トライする人が非常に少ないか、
3,設定できなくて挫折したか、
4,特に興味がないか、 (オイ
5,そんなのは某月刊誌や書籍に載ってる。
の、どれかかなぁ。(爆

一番気になるのが「2,」だ。
まえから気になっていたが「mbed」のおかげで
せっかくlpc1768使用者が増えたのに、JTAGがつながらないので

OpenOCD+JTAG+lpc1768使用者が世界的に増えていないのだ。

と予想する。(当然、趣味の世界の話だけど)

* lpc1768/ reset-initイベントハンドラ
「*.cfg」ファイルにある「reset-initイベントハンドラ」がキモなのだ。
このreset-initハンドラは「いつ呼ばれるか」。

1,Eclipse上で「デバッグ開始ボタン」を押す。
2,上の「gdb」設定の「monitor reset init」コマンドが実行される。
3,ハードウエアリセット等(JTAG関連も)が発生。
4,リセット系のイベントハンドラ群が呼ばれる。
5,最後から2番目に「reset-start」ハンドラが呼ばれる。
6,最後に「reset-init」ハンドラが呼ばれる。

で、多分「5.」の直前あたりで「CPUはHALT状態」になっている。
少なくとも「reset-init」ハンドラが呼ばれる前に「CPUはHALT状態」になっている。

「6,」の後、
上の赤丸部分で言うと「load」の直前でCPUはHALTで停止していることになります。

以下が「キモ」になる「reset-init イベントハンドラ」設定。
(soft_reset_haltをあとから追加しました。後述。)
$_TARGETNAME configure -event reset-init {
    echo "--- reset-init" 
    global _r

    # The VTOR indicates the offset of the vector table base address from 
    # memory address.
    # 0: Specify code region.
    mwb $_r(VTOR)    0x00

    # 1: User mode. The on-chip Flash memory is mapped to address 0.
    mwb $_r(MEMMAP)  0x01   

    soft_reset_halt     
}
(注: "_r"やレジスタ名は独自に定義したもの) コメント等々を省けば以下のようになる。
$_TARGETNAME configure -event reset-init {
    mwb $_r(VTOR)     0x00
    mwb $_r(MEMMAP)   0x01
    soft_reset_halt        
}
さらにレジスタ名定義をやめれば、
$_TARGETNAME configure -event reset-init {
    mwb 0xE000ED08    0x00  ; # VTOR
    mwb 0xE01FC040    0x01  ; # MEMMAP 
    soft_reset_halt    
}
と簡単に書ける。 2番目の「MEMMAP設定」が必要な理由は以下の文書にある。 lpc2300系からlpc1768への移行時のノート AN10878 Migrating to the LPC1700 series http://ics.nxp.com/support/documents/microcontrollers/pdf/an10878.pdf 以下抜粋、
8.1.6   Boot ROM re-mapping 
...
 However, if execution is halted immediately after reset by a 
debugger, the debugger should correct the mapping for the user by using the MEMMAP 
register which allows portion of the Boot ROM to be mapped to address 0 or flash 
memory is mapped to address 0. This is normally transparent to the user and important 
for tool vendors to be aware of. 
最初の「VTOR設定」が必要な理由は謎だが、 「VTOR設定」をすることで動いたというWeb上の情報を採用した。 *その他の設定(lpc1768) 以下については上側のデフォルトでいいような気がするが 下側の設定に変えてある。理由はせっかく回路は個別にあるのに 分離しないともったいない。(オイ lpc1768.cfg:
# LPC2000 & LPC1700 -> SRST causes TRST
#reset_config srst_pulls_trst
reset_config trst_and_srst separate
上はデフォルトに戻すかも。 lpc1768.cfg:
flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME \
	lpc1700 $_CCLK calc_checksum
上のようにチェックサムのチェックは無視しています。 現在は有効にしてあります。(調査中) そうすると以下のようにデバッグできたのだった。 eclipse-lpc1768-debug.gif (2010/08) *「soft_reset_halt」がキモだった(lpc1768) 上の設定には追加済みだけど、 「soft_reset_halt」コマンドを入れないと「sprintf/printf系」の 浮動小数表示がうまくいかないことが発覚した。 ねむいさんや、irukaさんに試してもらったら大丈夫とのこと。 実験してもらって感謝です。m(__)m 「soft_reset_halt」コマンドを当初から無視していたのが良くなかった ようだ。 無視した理由は「reset init」コマンドを実行してあるのに 「さらに何で?」と単純な疑問。 なるべく「おまじない的」な記述は避けたかったが、 無視したコマンドが「最大のキモ」だった。 orz reset initはリセット後にCPUをHALTさせるだけで 内部的なブートシーケンスの残骸が残ったままのようだ。 それをsoft_reset_haltで修正する感じでしょうか。 詳細は不明だが以下わかったこと、 1,「soft_reset_halt」コマンドを実行しない場合、スタックポインタ(SP)の   初期値が正しく設定されない。   (それでもスタック領域は約8kバイト確保されている) 2,「soft_reset_halt」コマンドを実行しない場合にsprintfの浮動小数変換を   実行しても、「8kバイトのスタックがあふれる訳ではない」が、   sprintfは正しく動作しない。   (malloc()系のsbrk()で約3k弱のヒープメモリを消費するがスタック破壊まで   5kバイト以上余裕があった。) *「soft_reset_halt」コマンドを実行する位置 Eclipse側のgdb設定なら「monitor reset init」の直後に入れればOKだった。 さらに「load」コマンドの直後でも大丈夫だった。 最終的には上記の様にOpenOCD設定ファイルの「reset-initイベントハンドラ」の 最後に追加した。 理由はInsightでデバッグする時の初期設定に複数のコマンドを書くと エラーになるのでOpenOCD側で済ませることにした。 *ベクタ・チェックサムについて(lpc1768) NXPはどうしてこんな機能を付けたのか。 理由が書いてないので不明だが何かの虫よけになるのかなぁ。 それより、「プログラムがブートしない!」って悲鳴が 世界的に増えるだけのような気がする。 (^^; これミスると痛い目に合う。十分注意したほうが良い。 で、 「OpenOCDはflashコマンドにcalc_checksum」を付けるとflash書込み時に 自動でベクタ・チェックサムを計算して書き込んでくれる。 だからソースコード内のチェックサム記述を気にしなくて良い。 が、しかし、 このcalc_checksumが動作するのは「flashコマンド」を使った時だけで gdb のloadコマンドの時には効果がないことが分かった。 デバッグは普通にできるけどJTAGを切り離してリセットかけると 「ギャッ!!」 orz やっぱり悲鳴だった。 従って ソースコードにちゃんとベクタ・チェックサムを記述することにした。 (OpenOCD v0.4.0) そこでチェックサムを簡単表示するEasy Checksum"を作った。 あと、Flashコマンドで書き込んだ後、gdbにシンボル情報だけロードする手も あるような気がする。(2010/11) * ブートシーケンスとの関係 実はリセット直後の内部ブートシーケンスの中に「ベクタ・チェックサム」の チェックも入っていて、 1,チェックサムが合わないときISPモードに移行する。 2,チェックサムが合えばユーザコードを実行。 という部分がある。 デバッガが介入すると「1.」の場合でも無理矢理「ユーザコード」を 実行するのだ。(ISPモードの残骸処理が必要) ここまでの状況から 「soft_reset_halt」が必須なのは「1.」の状態を無視して デバッグする場合だけの予感もするが もーめんどくさいので確認は省略。(オイ (2010/10) *soft_reset_haltの位置(lpc1768) ふと思った。 soft_reset_haltの位置はもっと前の方が良いかもしれない。 と、考えが変わるのは「soft_reset_halt」が実際何をどこまでやっているのか 不明なので想像になってしまうのだ。(そのうち調べよう) 現状では以下のように
$_TARGETNAME configure -event reset-init {
    soft_reset_halt
    mwb $_r(VTOR)     0x00
    mwb $_r(MEMMAP)   0x01
}
「VTOR」、「MEMMAP」設定の前の方が良い気がする。
(2010/11) *soft_reset_haltの位置(lpc1768) (2) 上の様にsoft_reset_haltを「reset-initハンドラ」の最初に持って来るのは 全然ダメなことが発覚しました。 気づくまでにかなりの時間がかかりました。orz ということで現状は以下、
$_TARGETNAME configure -event reset-init {

    mwb $_r(VTOR)     0x00
    mwb $_r(MEMMAP)   0x01
    soft_reset_halt
    
    jtag_clock_up_khz 1500
}
「jtag_clock_up_khz」はPLLを100MHzにアップした後JTAGクロックを 1.5MHzにアップする自作ルーチン。 LPC1768のPLLのクロックアップ方法についてはgitで取得した最新版の ソースコードの openocd\tcl\board\mcb1700.cfg というファイルがそのものズバリになります。
posted by Copyright (C) avrin All Rights Reserved. at 23:15| Comment(2) | OpenOCD | このブログの読者になる | 更新情報をチェックする

2010年07月18日

OpenOCD:雑多なメモ

OpenOCD:雑多なメモ
はじめに-1
はじめに0
はじめに1

OpenOCDのコンパイル編
  *cygwinをインストール
  *OpenOCDの開発版(最新版)(非正式版)ソースを取得
  *OpenOCDのリリース版(正式版)ソースに変更
  *FTDIのDLLを入手する
  *OpenOCDのコンパイル

コンフィグファイル編
  *はじめに
  *コンフィグファイルはTcl言語
  *PDFマニュアルを生成する

*I/Oビュー画面の代替?


はじめに-1
(マイナス1?
自分がOpenOCDを使ってみようとした理由は付録LPC2388基板で
ハードウェア・デバッグができるからだ。

基本的にgdb+Eclipse環境で使うことを前提にしている。
グローバル/ローカル変数の参照、
C言語/アセンブラソースでブレーク、ステップ実行。
レジスタ/メモリ参照などが容易に可能になる。

(注OpenOCDは多くのCPUに対応している
(注I/Oビュー(Peripheral View)機能はないが後述)

はじめに0
2010年7月現在、FT2232のFTDIドライバを使うと
OpenOCDは自分でコンパイルすることになる。
詳しくは以前のブログに書いた。

有名な解説ページがFTDIドライバを採用したしため
LibUSB-Win32のVista問題が偶然回避されてきたと想像する。

たぶん、半年〜1年以内にこの状況は改善されるだろう。
LibUSB-Win32のドライバがようやく改善されたようなのでコンパイル済みの
インストーラがWindows Vista以降で使える可能性が出てきた。
そうなれば自分でコンパイルする必要もなくなるし、

ワンクリック・インストーラ一発でお気楽極楽インストールが出来るだろう。

(今でもWindowsXPならできるが成功した情報を見つけられない)
(そうなるとSeggerJ-LINKのクローン品も視野に入ってくる)
(注2010年7月現在公(おおやけ)の場所から入手できるインストーラは
Vista問題ありのやつです。(たぶん))

まぁ、結局は出てみないとアレだけど。(オイ

今はちょうど過渡期と言っていいだろう。

そうこうしているうちにLPCXpressoが
簡単でかなりいい感じなのでそっちが大盛況になると思います。
LPCXpressoは「インストーラ、一発で設定終了」ですから、
その次はもうプロジェクト作ってコンパイル&デバッグ・ゴーなので。

特にLPCxpresso/LPC1768版が2800円で秋月から発売されたら
思わず買っていいと思います。(爆爆

はじめに1
メモメモ。

基本的に以下の2人の方(かた)のページを参考、
及び「ほぼそのまま(^^;」だったり、
独自の調査に基づく内容だったりいろいろになっています。

OpenOCDビルド方法(win32版)

ねむいさんのぶろぐ


OpenOCDのコンパイル編
*cygwinをインストール
今回、別の理由で最初からCygwinを再インストールしたので
その時の記憶。

cygwinをあまり好きじゃないと言いつつ使うのは、
某IF誌が提供する各種コンパイラ記事がCygwin用だったり、
MinGW/MsysがCygwinほど追加インストールが楽じゃなかったり。
使いにくいとはいえCygwinは、
「ワンクリック・インストーラ」が使えたりパッケージ・マネージャが
あったりするのだ。

cygwinに追加インストールしたもの
libtool
make
gcc3
git

など。

*OpenOCDの開発版(最新版)(非正式版)ソースを取得
cygwinのユーザフォルダを「/home/mi」とする。
以下はCygwinコンソール上で実行する。

$ pwd
/home/mi

$ mkdir ocd
$ cd ocd

$ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
これで /home/mi/ocd/openocd に開発版(今ならVer0.5-dev)のソースが取得される。 *OpenOCDのリリース版(正式版)ソースに変更 上で取得したのは最新版だけど、開発中の物(非正式版)なので正式版(v0.4.0)に変更する。 「開発版」というのは「途中のバージョン」なので、動作があやしい可能性もある。 さらに、「自分が取得した時点の最新版」なので 正確なバージョンの特定が難しいといえる。(まぁ、特定する方法はあると思うが) 最新版は、最新版なりに意味がある場合もあって微妙とも言える。(オイ 自分の場合は最初、最新版を使用して、後から正式版(v0.4.0)に戻した。 理由は、結構大変だったというのもある。(結果は変わらずだったが) 正式版(v0.4.0)と開発版(今ならVer0.5-dev)には、 「*.cfgファイル」に互換がないようなので注意が必要。 マニュアルもバージョンに合った物を読むこと。
$ cd openocd
以降の「git コマンド」は「openocdフォルダ」で実行する。 「branch」コマンドで
$ git branch
*master
上のようにマスターブランチ(印付き)(最新版)にいることを確認。
$ git tag
v0.1.0
v0.2.0
v0.3.0
v0.3.0-rc0
v0.3.1
v0.4.0
v0.4.0-rc1
v0.4.0-rc2
上でバージョンタグを確認する。 次に「checkout」コマンドでソースコードをごっそり 正式版(v0.4.0)に変更する。
$ git checkout v0.4.0
ブランチコマンドで確認
$ git branch
* (no branch)
master
上の「*印」がある方が「v0.4.0」のブランチになる. 変更はこれでOK. ソースコードを最新版(開発版)に戻したいなら
$ git checkout master
とする。 これで、「任意のバージョンにいつでも変えられる」ようになった。 このワザを十分活用してほしい。 *FTDIのDLLを入手する 取得したドライバ群を解凍して「openocd直下」のftd2xxフォルダに必要なファイルを置く。 下は解凍した物全部を置いた。
$ ls -1 ftd2xx/
CDM 2 06 00 Release Info.rtf
LogoVerificationReport.pdf
amd64
ftd2xx.h
ftdibus.cat
ftdibus.inf
ftdiport.cat
ftdiport.inf
*OpenOCDのコンパイル
$ pwd 
~/ocd/openocd
以下の順で実行する。
$ ./bootstrap
次に、
$ ./configure \
--enable-maintainer-mode \
--disable-werror \
--disable-shared \
--enable-ft2232_ftd2xx \
--with-ftd2xx-win32-zipdir=/home/mi/ocd/openocd/ftd2xx \
CC="gcc -mno-cygwin" \CFLAGS="-O0 -g -Wall"
を実行する。終わるまで待つ。 次に、
$ make
を実行。終わるまで待つ。 これで「srcフォルダ」に「openocd.exe」が出来ているので、 バージョンを確認する。
$ src/openocd.exe -v
Open On-Chip Debugger 0.4.0 (2010-07-18-xx:xx)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
と表示されればOKだ。 コンフィグファイル編 *はじめに (マタカyo *コンフィグファイルはTcl言語 OpenOCDのコンフィグファイル群(*.cfg)は、全部くまなくまるっと 「Tcl言語」のスクリプトなのだ。(サブセット+α) Tcl言語といえば化石。 じゃなくて。 超レガシーな言語だ。(爆 Tcl言語の基本文法は以下の方(かた)のページが非常に分かり易い。
Tcl文法とコマンドTcl基礎文法最速マスター
OpenOCDマニュアルにある「Tcl速習コース」は残念ながら読む意味はほとんどない。 あるとすれば、
lpc1768.cpu configure  -event  reset-init  { 
    myboard_reinit  
}
という、記述方法を知るくらい。 「コンフィグファイル」とは起動時にOpenOCDの引数に指定するファイル群のこと。 たとえば、
$ openocd.exe -f openocd.cfg -f conf2.cfg
等とする。 *PDFマニュアルを生成する 上記のようにOpenOCDのバージョンに合ったマニュアルが必須になる。 ここでは「PDFマニュアル」を生成する方法を記述する。 まず、 Cygwinに「tetex」関係のパッケージを追加する。 cygwin-tetex.gif 上が必要なtetexパッケージ 単独でマニュアルだけ生成したい時、 configureの最初のオプション「--enable-maintainer-mode」は、なにげに省略したくなりますが、 これを省略すると「PDFマニュアル」がエラーで生成できなくてハマりました。 orz 従って、OpenOCD本体のコンパイル後すぐにPDFマニュアルを生成するのが良い。 生成方法は
$ pwd 
~/ocd/openocd
docフォルダに移動して
$ cd doc
$ make pdf
で生成する。 が、しかし。 ただじゃ出来なくて (^^; RE: 'Fatal format file error; I'm stymied' 上のリンクの通りに「etex.fmt」を消去して
$ cd ~/.texmf/var/web2c
$ etex -ini -jobname=etex -progname=etex -translate-file=cp227.tcx *etex.ini
を実行した後にようやく
$ make pdf
でPDFが生成される。という、「かなりの高難度だった」。orz 多分月面。 じゃなくて。 「E難度」くらいか。 ちなみに、 Linuxでやってみたら素直にPDFが出来たので、cygwin側の設定ミスだろう。orz *I/Oビュー画面の代替? これはTOPPERSプロジェクトで代替案が導入されていて 「な〜る」って思いました。これから実験してみよっと。 OpenOCDのメーリングリストでもようやくこの件に「強くツッコミ」 を入れる人が登場しました。 この人はやり方教えてくれれば自分でやるゆーてます。 開発者サイドは、あまりやる気ない風で、「そっちより本体の方が先」みたいなぁ。 xmlファイルをいじるみたいですが難しそうなのと、こういう作業は 結構「なえ萎え」な感じ。 単純で量が多くて内容もコマくて。でも間違っちゃだめみたいなぁ。(オイ [Openocd-development] Requesting Help: How to add memory mapped I/O registers? まぁ、そういう作業をビシッとやってくれてるのがLPCXpressoなわけで。 これが「お金払ってる」。との違いでしょうか。 ちなみに、 STM32用のST−LINKアダプタを買うと無料で使えるatollic社の 「 TrueSTUDIO という開発環境」には「I/Oビュー 画面」はないです。 (有料版なら使える) こっちは逆に、 「お金払ったのに"I/Oビュー画面"はないのかよっ!」って。(注1) 「んな、こと言ったらLPCXpressoなんて128Kバイトの制限あるやろっ!」 「バキっ!」 「ボコっ!」 「...」 人生いろいろです。 (注1):TrueSTUDIOに、お金払った訳じゃないけど。 参考: Gitを使いこなすための20 のコマンド OpenOCDバイナリ Welcome on Chopin's homepage! http://www.freddiechopin.info/
posted by Copyright (C) avrin All Rights Reserved. at 19:53| Comment(0) | OpenOCD | このブログの読者になる | 更新情報をチェックする