ねむいさんのぶろぐ

OpenOCDの新MPSSEドライバを試す

20130403追追:
こちらのページにてOpenOCDとInsightを用いた効率的なデバッグ方法を
紹介しております。合わせてご参考願います。

20130403追:
私のおきぱで公開しているOpenOCDバイナリはWinUSB/LibUSB両対応と
なっております。
Zadigでインストールする際にLibUSBKを選択するとドライバの入れ変え無しに
どちらの方法からでもアクセス可能でさらに便利になっております。




MLを追いかけてる人ならご存知と思いますが少し前のOpenOCDのコミットで
新MPSSEプロトコルによるJTAGkey2をはじめとしたFTDI系デバイスでアクセス速度が
さらに向上するサポートが追加されました。
Windows環境下ではLPC17xx系でフラッシュ書き込みの速度不足を感じていたので私も
すぐに飛びつきました。

さて従来のものとどう違うかなのですが、新MPSSEは使用するドライバが
LibUSB(libftdi)やFTD2XX(libftd2xx)ではなくMicrosoftの汎用USBドライバで
あるWinUSBを使用する(実際はlibusb-1.0 async API のバックエンド)ようになります。


ねむいさん今までWindows環境上ではかたくなにFTDI純正ドライバ使用して
きましたが速度的に大幅に優勢になったのとlibusbがWin7系でも十分安定した
ので今回の変更を機にFTD2XXを捨てて乗り換えることにしました。


以下いくつかのMCUで実際に書き込みの比較を行います。
FT2232系デバイスとしてJTAGKey2を使用しています。

●RCLKを効かせたLPC2388の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg  -c "mt_flash	main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

RCLK - adaptive

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : RCLK (adaptive clock speed)

Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

Info : Embedded ICE version 7

Error: EmbeddedICE v7 handling might be broken

Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units

fast memory access is enabled

dcc downloads are enabled

target state: halted

target halted in Thumb state due to debug-request, current mode: User

cpsr: 0x00000070 pc: 0x0002b5ae

auto erase enabled

wrote 491520 bytes from file main.elf in 7.796974s (61.562 KiB/s)

verified 465140 bytes in 0.515632s (880.935 KiB/s)

requesting target halt and executing a soft reset

target state: halted

target halted in ARM state due to breakpoint, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:09

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc2388_rclk_flash.cfg  -c "mt_flash	main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain

RCLK - adaptive

Info : RCLK (adaptive clock speed)

Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)

Info : Embedded ICE version 7

Error: EmbeddedICE v7 handling might be broken

Info : lpc2388.cpu: hardware has 2 breakpoint/watchpoint units

fast memory access is enabled

dcc downloads are enabled

target state: halted

target halted in Thumb state due to debug-request, current mode: User

cpsr: 0x00000070 pc: 0x0002b5a8

auto erase enabled

wrote 491520 bytes from file main.elf in 4.859437s (98.777 KiB/s)

verified 465140 bytes in 0.437505s (1038.247 KiB/s)

requesting target halt and executing a soft reset

target state: halted

target halted in ARM state due to breakpoint, current mode: Supervisor

cpsr: 0x000000d3 pc: 0x00000000

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:06

もう全然威力が違うのがわかりますね♥

●STM32F4の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x080451a0 msp: 0x10010000

15000 kHz

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

stm32x mass erase complete

wrote 550968 bytes from file main.elf in 4.093803s (131.432 KiB/s)

verified 550968 bytes in 0.781260s (688.701 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:20

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x08045c28 msp: 0x10010000

21000 kHz

Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE

Info : device id = 0x10006413

Info : flash size = 1024kbytes

stm32x mass erase complete

wrote 550968 bytes from file main.elf in 3.937550s (136.647 KiB/s)

verified 550968 bytes in 0.546882s (983.859 KiB/s)

Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:21

残念ながらSTM32系はフラッシュの消去が遅いので(autoeraseだとさらに遅くなるので
"stm32f2x mass_erase 0"の使用を推奨)そっちに足が引っ張られます。実際のテンポは
あまりよろしくないです。それでも100kiB/Sec越え(どっちも越えてますがー！）
また同じスクリプトファイルでも新MPSSE版はJTAGのクロックが細かく設定できるよう
になり若干JTAGのクロックも早くなります♥
20130507追:
…と思いきや実際にオシロで波形を測定してみると15MHzのままでしたorz
FT2232Hの仕様上MPSSEの最高が30MHzでその一つ下は15MHzとづづきますからLibftdiの
時はOpenOCDの周波数の表示が計算上の値を正直に出してるだけで実際にFT2232Hに
設定されるTCKの周波数とは全く違うということですねorzorz


ちなみにSTM32F1系はもっと悲惨でフラッシュの書き込み速度も遅いため
35~7kiB/Secで一律頭打ちになってしまいます。
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0802bb00 msp: 0x20010000

7500 kHz

Info : device id = 0x10016414

Info : flash size = 512kbytes

stm32x mass erase complete

wrote 434240 bytes from file main.elf in 11.765700s (36.042 KiB/s)

verified 434240 bytes in 1.015631s (417.536 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/stm32f107.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

1000 kHz

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 1000 kHz

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x0802bbe0 msp: 0x20010000

9000 kHz

Info : device id = 0x10016414

Info : flash size = 512kbytes

stm32x mass erase complete

wrote 434240 bytes from file main.elf in 11.640700s (36.429 KiB/s)

verified 434240 bytes in 0.765629s (553.875 KiB/s)

Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:13

●FM3の場合
*FTD2XX

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/ftdiOCD/tcl -f interface//jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00624-gaf9918d-dirty (2012-07-17-22:29)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : device: 6 "2232H"

Info : deviceID: 67358712

Info : SerialNumber: 22222222A

Info : Description: Amontec JTAGkey-2 A

Info : max TCK change to: 30000 kHz

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000

Rize up to Internal PLLed Clock!

15000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 524288 bytes from file main.elf in 9.312559s (54.980 KiB/s)

verified 505904 bytes in 0.578129s (854.562 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:12

*WinUSB

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.6.0-dev-00626-g10fd274-dirty (2012-07-23-11:26)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'

adapter_nsrst_delay: 100

jtag_ntrst_delay: 100

trst_only separate trst_push_pull

500 kHz

cortex_m3 reset_config sysresetreq

verify Capture-IR is disabled

Info : clock speed 500 kHz

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

Info : mb9bfxx8.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

target state: halted

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x00000114 msp: 0x20010000

Rize up to Internal PLLed Clock!

18000 kHz

auto erase enabled

Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 5)

Info : Fujitsu MB9B500: FLASH Write ...

wrote 524288 bytes from file main.elf in 6.984419s (73.306 KiB/s)

verified 505904 bytes in 0.343753s (1437.215 KiB/s)

Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:09

FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388
並みに速くなっています！
(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、
さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)

上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトで
あらかじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。



ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルド・デバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥　こっこれで"ねむいさんという
人のページみたけどやり方がさっぱり"って後ろ指挿されることなくなったんじゃ！！






中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が｢初めて触った人が陥り易く、かつ致命的になる｣と感じた問題たちについての
回避策やtipsをご紹介したいと思います。


●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバの
　インストール方法が面倒そうででわかりません＞＜;
->zadigれ


●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
　一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
　てこさえた基板言い値で全部買い取れ。
　->ｶｴﾚや!!1!
->STM32ではWFI命令を含むプログラムを実行した後ペリフェラルのクロックが停止し
　　ますが同時にコアにあるデバッグユニットに供給されるクロックも仲良く停止し
　　てしまい、JTAG/SWD等で一切アクセスできなくなってしまいます。

　　回避策はWFIが実行される前に速攻HALTをかけてフラッシュを全消去して電源再投
　　入してやれば再びアクセスできるようになります。しかしこの方法はタイミングが
　　シビアすぎるのでお勧めできません。
　　
　　確実な方法は、システムメモリからブートするモードにしておき、リセットかけ
　　ても常にブートローダーに飛ぶようにしておくとJTAG/SWDでアクセスできるよう
　　になってとにかくフラッシュを消去できるようになります。ブートローダーから
　　そのままFlashLoader等のツールでUART経由で消去しても構いません。

　　ここ最近で"元に戻せなくなった"と↑の質問をいただくケースが激増してます。
　　戻す方法はちゃんとあるのであきらめないでください。

●LPCXpresso基板のLPCLinkの部分を分離してJTAGkey+OpenOCDをデバッガにして
　開発を始めてみました。でも何故かmbedやLPCXpresso(ねむいさん注：IDEの方)
　で動いていたLチカのプログラムが全く動きません＞＜;
->NxPの内蔵フラッシュ付きのARMマイコンは伝統的にCheckSumValidationを持って
　　います。これはリセット直後にフラッシュのとある番地にあるリセットベクタの
　　チェックサムの値を確認し正しくなければISPに飛んでいく機構です
　　(ユーザーマニュアル参照)。
　
　　mbedやLPCLinkのライタは書き込む際にリセットベクタのチェックサムを計算し、
　　その番地の値だけ計算済みの値に改変して書き込むのでCheckSumValidation
　　を通過しユーザープログラムを実行することができます。もちろんOpenOCDでも
　　同じことが可能ですが、ベリファイの際は改変前のバイナリと比較してしまう
　　ため、必ずエラーになってしまいます(=ゆえにベリファイだけできない)。

　　ベリファイまで通したい場合は、あらかじめ計算した値をリセットベクタの指定
　　のアドレスに書き込んでおくことで可能となります。私が公開しているLPC系の
　　マイコンのプロジェクトは、すべて計算済みの値を記してあるので参考にしてく
　　ださい(スタートアップのアセンブラファイルに直値を記述)。


●フリーのEclipseを使った開発をしているのですが(ry
->(全身から血をふきだして死んだ)
　　※しかしねむいさんは有償のEclipseベースの開発環境では死にません。
　　　死ぬのはあくまでも設定が死ぬほど面倒な素のEclipseで攻撃された時です。
　　　あといないさんのおぱんつ画像でも一発で死にますので絶対に見せたりしな
　　　いでください絶対ですよ絶対！！１！１



●ねむいさんの手順の通りにしているけどOpenOCDがビルドできません＞＜;
->ビルド済のバイナリを用意したのでこれからはおきぱのOpenOCDのバイナリを使っ
　　てください。FTD2XXのライブラリは使用していないのでGPLに引っかからずバイ
　　ナリを自由に利用できるようにしました!…あとご忠告ですが、最初のうちは変
　　な自分流のアレンジをしたりせずにあくまでも手順に沿ってやりましょうね…。


●mt_flashとかいうのがよくわかりません&見つかりません＞＜;
->大昔はtelnetでOpenOCDとコマンドのやり取りをし、マイコン内蔵のフラッシュに
　　プログラムを書き込む方法しかありませんでした。現在はその方法はスマート
　　では無く、ARMコアなルーターのフラッシュ書き換えの際の動作確認程度にしか
　　利用されていません。
　　デバッグでカットアンドトライをしてる時はとても効率が悪いです。

　　しかしながら上記のような"現在は不適切なor廃止された"とされる数年以上も
　　前のOpenOCDに関する情報が｢最新のOpenOCDを〜｣という見出しで検索の
　　トップを占めているのが現状で、何も知らない人がこれらの情報をもとに"最新"
　　のOpenOCDを使おうとしても当然うまくいくはずもなく、"使えない"、
　　"敷居が高い"という印象を持って離れてしまっています。

　　2012年7月現在"最新"の0.6.0ではWindowsはバッチファイルで、Linux系なら
　　シェルスクリプトでJim-Tclのスクリプトをコマンドの引数として一括で呼び出す
　　ことにより簡単に書き込み動作ができるようになります。mt_flashってのはその
　　スクリプトの名前のことで、それが記述されているスクリプトもしくはコンフィグ
　　ファイルがないと当然使用できません。私が公開しているOpenOCDのバイナリ
　　にはそれらが仕込まれたコンフィグファイルがありますので安心してお使い
　　ください。

　　ちなみにmakeと組み合わせることによりさらに効率よく開発が可能です。
　　長々と書きましたがここ見てくれれば間違いないのですがそうだね宣伝だね。


●"Remote 'g' packet reply is too long"というエラーが(ry
->去年の年末に｢次それ聞いたら頭にJTAGKeyぶっ挿して一ビットずつ対策方法焼き
　　こんでくから｣…って私言いましたよね！？

• 2012.07.28 Saturday
• 18:18
• ネムイ・トリノミアス
• MISC
• comments(0)
• -

STM32F4シリーズを使ってみる6 -giflibを実装する-

前回はlibpngを実装してTFT-LCDに表示を行いましたが、今回は同じく現在でも
多用されているgif形式の画像がデコードできるgiflibをSTM32F4に実装し、さらに
アニメーションgifのTFT-LCD上においての再生も成功しました。


●あらまし
giflibはlibungifを前身に持ち、LZWというアルゴリズムでエンコード・デコードを
行います。ご存知の方は多いと思いますがそのパテントを持っていたUnisys社により
一時はgifフォーマットがあまり使われていなくなっていた時期がありました
(代わりのフォーマットとしてpngが出てきました)。
2012年現在はそのパテントの期限も切れて自由にLZWが利用できるに至っています。

gifフォーマットはpngと比べて256色までしか表現できませんが、アニメーションgif
として今でも現役で使用されています。ことさら私たち虹裏メイドに関しては、
ファイルのアップロードに500kByteの制限がある虹裏の板の仕様上pngと並んで
アニメーションを表現するのに非常に重要な形式であり、これをSTM32F4に代表される
大規模マイコンに移植し表示せしめることは最早宿命とも言えます！

STM32F4への実装と動作の理解の助けとして、yoya氏のwikiを参考にさせて
いただきました。ありがとうございます！


●必要なもの
giflib
今回は出来たてホヤホヤのgiflib-5.0.0を使用します。

●ファイルI/O
libjpegやlibpngと同じようにFatFsのAPIを差し替えりゃ簡単…とはまったく言えず、
PC向けにファイルI/Oが特化されたgiflibをChaNさんのFatFsの流儀に嵌めるまでは
かなり試行錯誤を強いられました。最終的にDGifOpenFileHandle()内はFatFs完全特
化する形で書き変えてしまいました。

●makefileに追加するCソースファイル
デコードするためには最低限下記ファイル群が必要です。
dgif_lib.c
gif_err.c
gif_font.c
gif_hash.c
gifalloc.c
quantize.c

dgif_lib.cに関しては一部内容の書き換えが生じます(後述)
dgif_lib_fatfs.cとリネームしておいてください。

●ARMマイコン上で動作させるための少しの変更
FatFsのAPIに当てはめるため、幾つかの変更を強いられます。
dgif_lib_fatfs.c
　->"/* Nemui Changed */"の変更・削除した部分を参照してください。
gif_lib.h
　->ff.hをインクルードしてください。
　->178行目のプロトタイプ宣言は以下に変更してください
　　　GifFileType *DGifOpenFileHandle(FIL* fp, int *Error);
gif_lib.h
->ff.hをインクルードしてください。

●gif(アニメーション)を表示する
多くのアニメーションgifではインターレースがどれかのフレームで使用されて
いたため、インターレースの表示ルーチンも実装しました。giflibにあったexampleを
見れば特に困ることはありません。
もちろん表示スピードは落ちますが透過表現も実装してます。

また、実際の表示に関してはRAMの少ないマイコン上の話なので一列ずつ表示
することになります。この時に消費されるRAMはベースで28672Byte(デバッガの
追跡により算出)と一列ごとのピクセル数*3です。
だいたいlibpngより少し少ない量になりますね。

しかしながら、320x240サイズのちょっと大きめでフレーム数が多いgifアニメー
ションは再生中にもメモリ要求量が増大していき、総量で70kByte近く消費しました。
libpngも大きい画像サイズの奴をデコードしようとすると65kbyte程使うように
なりますがそれより多いのです。
というわけで専ら大容量の内蔵SRAMが使用できるFM3・STM32F2&F4ですね〜。

デコードされたRGBデータは8+8+8の24ビットの形式となっているため、565の
16bitにしてTFT-LCDにデータを書き込みます。
グローバルカラーマップとローカルカラーマップの判別もこの段階で行います。



そして動かしたところです…
(gifファイルはとしあき&｢｣作の物を使わせてもらいました！)


↑写真が静止画なので分からないと思いますがgifアニメーションが動いてます。
　アンドリューW.K.さん(キャラクターが)いいよね…


↑gifアニメーションの最終フレームまで来たら停止します(ループはしません)。
　ちなみにgifの仕様上ディレイ時間は10mSec区切りとなるので実装時は適切な
　時間のディレイを生成する必要があります。
　また、私の表示プログラムでは最終フレームまで行かなくても途中で各入力を
　行うことによりファイラに強制的に戻ることができます。



↑STM32F2でも動く！当たり前ですが…
　…STM32F1はRAM容量的に流石にきつかったので抜きで。

↑FM3マイコンでももちろん動きます！


ということで今回の成果はおきぱのSTM32F4,F2,FM3のFatFs移植例に
すでに反映しています。前回も少し触れましたが、私が使わせてもらている各
ライブラリ・プログラム・フォントのライセンス表記についてもきちんと明記する
ようにしていくようこころがけています。

おまけ

またまた買ってしまった(写真奥)…これからは解像度320x480で小型なTFT-LCDの
時代です！手前のaitendoさんで売ってるのより一回り小さいやつで、コントローラICは
HX8357Aです。今回のいつものの更新ではこちらの液晶にももちろん対応させています。

大きさも3インチと一回り小さいので出来あいLCD基板にちょうど乗ります♥

• 2012.07.13 Friday
• 01:25
• ネムイ・トリノミアス
• ARM/STM32
• -
• -

XMEGAを使ってみる5 -FatFsのDMA化-

AVRマイコンの進化形であるXMEGA。ねむいさんの偏見ですがこれを触った
人たちの殆どが以下の運命を辿ってる気がしなくもなくもなくもないです…。

1.XMEGAが手に入りました(^^)DMAやDACが使えるので楽しみです。
↓
2.ChaNさんのFatFsが動きました(>▽<)次はDMA化してみます(^^)
↓
3.XMEGAではSPIはスレーブしかDMAをサポートしてないみたいですね〜
　UARTのMSPIモードでしかマスタでDMAができないようです(＠o＠)
　いやはやデータシートはしっかり見なくては(^^；
　(↑流し読みしないで初めからちゃんと見ろ！)
↓
4.(XMEGA関連の更新が途絶え、関係ない記事ばっかりになる)
↓
5.(息してない)
↓
6.おや？スライムたちが集まって…？
↓
7.
　
　↑こちらのサイトでこの文字を作らせていただきました！


…なんでねむいさんのほうを見る！？



といつもの戯言はこの辺にして以前挫折して放り投げていたXMEGAにおける
FatFsのDMA化、ねむいさんもついに成功しましたのでご報告します。

ain氏のXMEGAのDMA転送に関する記事が大きなヒントになったわけですが、
SPIは送信と受信が対になっていて｢(SPIマスタで)データを得たければ先ずは送信せよ｣
というのが頭で固まってしまっていてずっとTxからDMAの初段をキックしていました。

まさかRxからキックを開始しなければ転送が成立しないなんて思いもしなかったので
目からうろこでした…。ホントにあとちょっとのところだったのに投げ出して
しまったのか私orz
…と後からいくらでもなんとでも言えるのでまぁ無事動いたから良しとしましょう！


ファイルの読み出し速度の比較を行ってみました。

↑DMAを使用しないベタな転送の時

↑DMA転送時
実験に使用したSDカードはSTM32の時に使っている物と同一です。

STM32F1でSPIのクロックが18MHz時のDMA転送では2100kByte/Sec程出ていました
が、XMEGAにおいて許容されるSPIクロックは16MHzまでとなります。そこから単純に
逆算すると、1800kByte/Sec近く出ることになります。DMA転送前の前処理等での
時間ロスを考慮すれば1500kByte/Secという値はある納得できるものだと思います。

これ以上転送速度を上げようと思ったらオーバークロックをするか、ダブルバッファ
リングで効率化を図る等が必要になるでしょう。同氏の記事にはそれらに加えて
ペリフェラルも合わせてDMAで動かすときの考察もされており非常に参考になります。



というわけで私のおきぱにあるXMEGAのプロジェクトも今回のDMA転送のサポートを
加えて更新しておきました。なんとうかずっと残っていた胸の突っかかりが取れたような
気分でほっとしております♥

また、トップにもたびたび告知していますが、今回の更新から私が使用させてもらって
いる他の方のライブラリやソフトのライセンスの表記について、ソースが入っている
Zipファイルに各コピーライト、ライセンスを記したテキストファイルを同梱し明確化
していくようにしました(ホント今更ですが…)。

もちろん私のSTM32等のプロジェクトも同様の整備を広げていくしていく方針です。

• 2012.07.07 Saturday
• 23:42
• ネムイ・トリノミアス
• AVR
• comments(0)
• -