2010年12月12日日曜日
LPCXpresso LPC1768にJTAGKey2Pを接続してOpenOCDで楽しむ
先の記事ではLPCXpresso LPC1768のデバッガとターゲットを切り離しました。
JTAGKey2Pではlibftd2xxを使用します。
http://www.ftdichip.com/Drivers/D2XX.htm
2010年12月12日現在のバージョンはlibftd2xx1.0.0.tar.gzです。
ダウンロードして展開しておきます。
次にOpenOCDのソースコードです。
ビルドにはautomakeも必要です。
予めビルド環境に入れておいてください。
ビルドできたらmake installして出来上がりです。
ここで試しにsuikanさんがポーティングされたTOPPSER/ASP for LPCのバイナリをOpenOCD経由でフラッシュに書き込んでみましょう。
まずはOpenOCDを起動します。
その前に・・・OpenOCDの設定ファイルを確認します。
openocd.cfgは以下のようにしました。
jtagkey2p.cfgはgitリポジトリに入っている物と同じです。
次にOpenOCDを起動します。
無事に起動したらtelnet localhost 4444でOpenOCDと接続します。
halt, flash probe 0, flash write_image erase (バイナリファイル名), resetでLPCXpresso LPC1768上にあるLEDがチカチカする事を確認してみましょう。
OpenOCD側の端末ではクライアントから受けたコマンドの動作が記されていると思います。
この文書ではLPCXpresso LPC1768をJTAGKey2Pで使用するための狭い範囲のドキュメントとして作成しました。
TOPPERS/ASP for LPCに関するドキュメントはsuikanさんがお書きになった以下のドキュメントも参照してください。
ターゲットを独立させたのはJTAGKey2Pを接続して使いたいためです。
ここでは実際にLPCXpresso LPC1768にJTAGKey2Pを接続してみました。
OpenOCDはgitリポジトリから2010年12月12日現在のものを取り出して使用しました。
まずはOpenOCDのビルドです。JTAGKey2Pではlibftd2xxを使用します。
http://www.ftdichip.com/Drivers/D2XX.htm
2010年12月12日現在のバージョンはlibftd2xx1.0.0.tar.gzです。
ダウンロードして展開しておきます。
tar xvfz libftd2xx1.0.0.tar.gz
次にOpenOCDのソースコードです。
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
cd openocd
./bootstrap
./configure --enable-ft2232_libftdi --with-ftd2xx-linux-tardir=/path/to/libftd2xx1.0.0
makeビルドにはautomakeも必要です。
予めビルド環境に入れておいてください。
ビルドできたらmake installして出来上がりです。
ここで試しにsuikanさんがポーティングされたTOPPSER/ASP for LPCのバイナリをOpenOCD経由でフラッシュに書き込んでみましょう。
まずはOpenOCDを起動します。
その前に・・・OpenOCDの設定ファイルを確認します。
openocd.cfgは以下のようにしました。
source [find /usr/local/share/openocd/tcl/interface/jtagkey2p.cfg]
source [find /usr/local/share/openocd/tcl/target/lpc1768.cfg]jtagkey2p.cfgはgitリポジトリに入っている物と同じです。
lpc1768.cfgについてはSWDを使う設定になっていました。
これについては以下のように修正して使用しました。
# NXP LPC1768 Cortex-M3 with 512kB Flash and 32kB+32kB Local On-Chip SRAM,
# # LPC17xx chips support both JTAG and SWD transports.
# # Adapt based on what transport is active.
# source [find target/swj-dp.tcl]
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lpc1768
}
# After reset the chip is clocked by the ~4MHz internal RC oscillator.
# When board-specific code (reset-init handler or device firmware)
# configures another oscillator and/or PLL0, set CCLK to match; if
# you don't, then flash erase and write operations may misbehave.
# (The ROM code doing those updates cares about core clock speed...)
#
# CCLK is the core clock frequency in KHz
if { [info exists CCLK ] } {
set _CCLK $CCLK
} else {
set _CCLK 4000
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x4ba00477
}
#delays on reset lines
adapter_nsrst_delay 200
jtag_ntrst_delay 200
# LPC2000 & LPC1700 -> SRST causes TRST
reset_config srst_pulls_trst
jtag newtap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
#swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m3 -chain-position $_TARGETNAME
# LPC1768 has 32kB of SRAM In the ARMv7-M "Code" area (at 0x10000000)
# and 32K more on AHB, in the ARMv7-M "SRAM" area, (at 0x2007c000).
$_TARGETNAME configure -work-area-phys 0x10000000 -work-area-size 0x8000
# LPC1768 has 512kB of flash memory, managed by ROM code (including a
# boot loader which verifies the flash exception table's checksum).
# flash bank (name) lpc2000 (base) (size) 0 0 (target#) (variant) (clock) [calc checksum]
set _FLASHNAME $_CHIPNAME.flash
# flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 $_CCLK calc_checksum
flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME lpc1700 120000
# Run with *real slow* clock by default since the
# boot rom could have been playing with the PLL, so
# we have no idea what clock the target is running at.
jtag_khz 500
$_TARGETNAME configure -event reset-init {
# Do not remap 0x0000-0x0020 to anything but the flash (i.e. select
# "User Flash Mode" where interrupt vectors are _not_ remapped,
# and reside in flash instead).
#
# See Table 612. Memory Mapping Control register (MEMMAP - 0x400F C040) bit description
# Bit Symbol Value Description Reset
# value
# 0 MAP Memory map control. 0
# 0 Boot mode. A portion of the Boot ROM is mapped to address 0.
# 1 User mode. The on-chip Flash memory is mapped to address 0.
# 31:1 - Reserved. The value read from a reserved bit is not defined. NA
#
# http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC1768&type=user
mww 0x400FC040 0x01
}
init
reset init次にOpenOCDを起動します。
shinta@greenpad:~/Projects/ledblink_lpcxpresso_1768$ sudo openocd
[sudo] password for shinta:
Open On-Chip Debugger 0.5.0-dev-00651-gc6e0705 (2010年12月11日-21:58)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
none srst_pulls_trst
500 kHz
Info : max TCK change to: 30000 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : lpc1768.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripherals無事に起動したらtelnet localhost 4444でOpenOCDと接続します。
halt, flash probe 0, flash write_image erase (バイナリファイル名), resetでLPCXpresso LPC1768上にあるLEDがチカチカする事を確認してみましょう。
shinta@greenpad:~$ telnet localhost 4444
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
> flash probe 0
flash 'lpc2000' found at 0x00000000
> flash write_image erase /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin
auto erase enabled
wrote 32768 bytes from file /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin in 5.705619s (5.609 KiB/s)
> reset
JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripheralsOpenOCD側の端末ではクライアントから受けたコマンドの動作が記されていると思います。
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1fff0080 msp: 0x10001ffc
Info : accepting 'telnet' connection from 4444
flash 'lpc2000' found at 0x00000000
auto erase enabled
wrote 32768 bytes from file /home/shinta/Projects/ledblink_lpcxpresso_1768/asp.bin in 5.705619s (5.609 KiB/s)
Info : JTAG tap: lpc1768.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Warn : Only resetting the Cortex-M3 core, use a reset-init event handler to reset any peripheralsこの文書ではLPCXpresso LPC1768をJTAGKey2Pで使用するための狭い範囲のドキュメントとして作成しました。
TOPPERS/ASP for LPCに関するドキュメントはsuikanさんがお書きになった以下のドキュメントも参照してください。
LPCXpresso LPC1768のデバッガとターゲットを切り離して使う
LPCXpressoはそれ自身でデバッガとターゲットの用が足りてしまうので、デバイスを試すという意味で言えば普通それ以上考えません。
でも、「じゃあ製品に組み込む時どうすんの?」とかそういう話になってくると「いやー、LPC-LINK使うかなぁ?(←使わないでしょ。)」とか、「本当に動くのかなー。(←そりゃ動くだろうよ。)」みたいな話になってきます。
そこで、今回はLPCXpressoのターゲットだけを切り離して、JTAGデバッガと接続するお話です。
まずは回路図を確認します。
LPCXpressoは以下のようなデザインになっています。
LPC-LINK側から+3.3[V]を給電してもらってターゲットが動作するようになっています。
「じゃあ、USBに接続しないで動作させるにはどうするの?」という話ですが、これは図にある通り、「Expansion connector」から外部電源電圧(+5.0[V])をもらい、それがそのままLPC-LINKに入って、先ほどの+3.3[V]を生成するという設計です。
ちょっと考えてみましょう。
LPC-LINKとターゲットを切り離してみてください。
そして、整理してみます。
また、図面には「Superset of mbed connector」と書かれていますが、これは大嘘。
なぜなら、mbedの40ピン目は+3.3[V]の出力です。
LPCXpressoのターゲットはLPC-LINKを接続している限り「+3.3[V]を出力」しますが、切断した途端にここから+3.3[V]を入れるという前提になっています。これでは当該ピンから+3.3[V]が供給される前提で設計されているベースボードは動作しないことになります。
これは明らかにスーパーセットではありません。
この時点で「superset of mbed pinning」は信用しないことにしました。
この設計はLPC-LINKを使わせる前提なのでしょう。
以下は図面の最後のページのピンアサインです。
初めは「self powered」の意味がわかりませんでしたが、「デバッガ+ターゲット=セルフ」ということみたいです。
そうなると「じゃあどうするの?」という現実的な問題になってきます。
私はこうしました。
LPCXpresso上の配線は以下のようになっています。
EXT_POWXから+5.0[V]をもらい、+3.3[V]に降圧してからVIO_3V3Xに給電です。
コンデンサは後で。
こうすれば(※J6-29にUSBの+5.0[V]を渡す必要もある。)電源面から見ると「mbedとほぼsuperset」と言えます。また、パソコンさえあればデバッグが開始できます。
通常、デバッガはターゲットのI/O電源電圧をリファレンスとしてもらってI/Oを駆動する形をとります。
LPC-LINKは積極的にターゲットに電源を供給する前提で設計されています。
そういう意味で「切り離して使えます」と言われてはいるものの、LPCXpresso LPC1768にかなりフォーカスしたデバッガと考えていた方が良いかもしれません。
この次にJTAGKey2Pによる動作確認です。
でも、「じゃあ製品に組み込む時どうすんの?」とかそういう話になってくると「いやー、LPC-LINK使うかなぁ?(←使わないでしょ。)」とか、「本当に動くのかなー。(←そりゃ動くだろうよ。)」みたいな話になってきます。
そこで、今回はLPCXpressoのターゲットだけを切り離して、JTAGデバッガと接続するお話です。
ユーザとしては「使い慣れた」、あるいは「既に投資してしまった」デバッガや環境を使いたいわけです。
ここでは手始めにデバッガ(LPC-LINK)とターゲットを切り離して使うことを考えます。
まずは回路図を確認します。
LPCXpressoは以下のようなデザインになっています。
LPC-LINK側から+3.3[V]を給電してもらってターゲットが動作するようになっています。
「じゃあ、USBに接続しないで動作させるにはどうするの?」という話ですが、これは図にある通り、「Expansion connector」から外部電源電圧(+5.0[V])をもらい、それがそのままLPC-LINKに入って、先ほどの+3.3[V]を生成するという設計です。
ちょっと考えてみましょう。
LPC-LINKとターゲットを切り離してみてください。
そして、整理してみます。
- LPC-LINKは+5.0[V]から+3.3[V]を生成する。
- ターゲットは+3.3[V]を給電されて動作する。
- ターゲットは+5.0[V]を給電されても、LPC-LINKにそのまま渡すだけ。(要するにターゲットと+5.0[V]は一切関係ない。)
また、図面には「Superset of mbed connector」と書かれていますが、これは大嘘。
なぜなら、mbedの40ピン目は+3.3[V]の出力です。
LPCXpressoのターゲットはLPC-LINKを接続している限り「+3.3[V]を出力」しますが、切断した途端にここから+3.3[V]を入れるという前提になっています。これでは当該ピンから+3.3[V]が供給される前提で設計されているベースボードは動作しないことになります。
これは明らかにスーパーセットではありません。
この時点で「superset of mbed pinning」は信用しないことにしました。
この設計はLPC-LINKを使わせる前提なのでしょう。
以下は図面の最後のページのピンアサインです。
初めは「self powered」の意味がわかりませんでしたが、「デバッガ+ターゲット=セルフ」ということみたいです。
そうなると「じゃあどうするの?」という現実的な問題になってきます。
- LPCXpressoのターゲットの問題は単に+3.3[V]のみ。
- 手軽に取り出せるのは、例えばUSBの+5.0[V]。
- パソコンとターゲットとデバッガI/Fだけで開発したい。
私はこうしました。
- LPCXpressoのターゲット上で+3.3[V]を+5.0[V]から生成するようにしよう。
- LPCXpressoのデバッガは+3.3[V]の出力にダイオードを突き当ててるから大丈夫。
- ターゲット用の+5.0[V]はUSBから頂こう。
LPCXpresso上の配線は以下のようになっています。
EXT_POWXから+5.0[V]をもらい、+3.3[V]に降圧してからVIO_3V3Xに給電です。
コンデンサは後で。
こうすれば(※J6-29にUSBの+5.0[V]を渡す必要もある。)電源面から見ると「mbedとほぼsuperset」と言えます。また、パソコンさえあればデバッグが開始できます。
通常、デバッガはターゲットのI/O電源電圧をリファレンスとしてもらってI/Oを駆動する形をとります。
LPC-LINKは積極的にターゲットに電源を供給する前提で設計されています。
そういう意味で「切り離して使えます」と言われてはいるものの、LPCXpresso LPC1768にかなりフォーカスしたデバッガと考えていた方が良いかもしれません。
この次にJTAGKey2Pによる動作確認です。
ラベル:
ARM,
ARM Cortex-M3,
LPCXpresso LPC1768
2010年12月1日水曜日
Time elapse image using mbed NXP LPC1768
[埋込みオブジェクト:http://www.youtube.com/v/cqOia4behOQ?fs=1&hl=ja_JP&rel=0]
The components
* mbed NXP LPC1768
* microSD card
* LinkSprite JPEG Color Camera LS-Y201
The content is UNIQLOCK.
http://www.uniqlo.jp/uniqlock/
The components
* mbed NXP LPC1768
* microSD card
* LinkSprite JPEG Color Camera LS-Y201
The content is UNIQLOCK.
http://www.uniqlo.jp/uniqlock/
ラベル:
LS-Y201,
mbed NXP LPC1768
登録:
コメント (Atom)