いろいろ試す14

●余ったAT90USBKeyをPDI接続のXMEGAライタとして使う
AT90USBKeyは(元)主人の遺品の一つでしたが引き継いだ私がSTM32をはじめとした
32bitマイコンに完全移行した今、もう必要ないかと捨てるつもりでした。
しかしLUFAの成果物の一つにAVRISPmk2の実装があったことを今更知り、XMEGA専用の
フラッシュロムライタとして再生することにしました。

XMEGAにあるPDIインターフェースはCortex-M系のマイコンにあるSWDとよく似ていて
2線式で書き込み・デバッグを行うことができます。しかもXMEGAの場合はJTAG接続よ
りも書き込みスピードが速い(ATMEL曰く)のです!!


ATUSBKey上のAVRISPmk2の実装はPD2&PD3(PDIDATA),PD5(PDICLK)として引き出
されます。AT90USBKey上では上記図の様に配線します。またポートの出力バッファの
破損を防ぐためPDIDATA・PDICLKとも各自100〜220ohmの抵抗を直列に付けるべきです。
本当は電圧トランスレータをかます必要がありますが、私は3.3V使いしかするつもりが
ないのでこれで十分です。

PDIインターフェースはXmegaのReset信号を通信に使用します。外部リセット用の
メカニカルスイッチを実装している際にチャタリング防止のキャパシタをぶら下げてる
場合は必ず外してください。


ドライバはおなじみのLibUSBを使い、書き込みはAVRDudeから行います。メッセージは
こんな感じです↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
avrdude -p atxmega128a1 -P usb -c avrisp2 -U flash:w:main.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e974c
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (118286 bytes):

Writing | ################################################## | 100% 9.27s

avrdude: 118286 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 118286 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.77s

avrdude: verifying ...
avrdude: 118286 bytes of flash verified

avrdude done. Thank you.


> Process Exit Code: 0
> Time Taken: 00:17



ついでなのでXMEGAのFatFs+TFTLCDの実装サンプルも新しくしました。
しかしこのXMEGA、A1シリーズの384kByte版や4bit-EBIの完全版とかがATMEL本家
からことごとく無かったことにされ、素直にARM使った方が良い昨今は存在意義がほんと
にわかりません…まさに好き者物好きなあなたへ。
※もともと所持していた図体がでかいAVR-JTAGICEmk2は副業先に提供しました。

●ついでですがWinAVRからAVRToolchainに乗り換えるときの諸注意など
さすがにWinAVR使う人激減してますが、ねむいさんのようなコマンドラインビルド
主体の人がAVRToolchainに乗り換えるためのtipsを紹介します。

PROGMEMの定義
 これもう海外ではavr-gcc4.7系が出てすぐにFAQと化した事柄ですがたまに質問
 もらいますので日本でも既に他の方々が言及してますが私もお伝えします。
 
 prog_****系の(prog_char)等の宣言が4.7系で廃止になったのでテーブル等の定数
 をフラッシュメモリ置くときは以下のように定義し直せばOKです。

 旧 :const prog_char unk[] ="inachang!";
 新 :const char unk PROGMEM[] = "inachang!";

 私が公開してるXMEGAのサンプルはすでに修正入れています。

utilsが無い!
 AVRToolchainはAVRStudio6で使用するのが大前提なのでunixライクツールがあった
 utilsフォルダが存在しません。ですがAVR-GCCのバイナリがあるフォルダに同等の物が
 一緒にほぼ全部ぶち込まれてるので大抵は困りません。(sh.exeだけは無いです)
 シェル(sh.exe)に依存するmakeの書き方をしてるとエラーで止まるのでご注意ください。
 …LUFAっていまだWinAVR20101110が前提なんですよね…めどい…。
 因みに私が公開してるXMEGAのサンプルはもちろんこのビルド手順準拠です。
 ARM-GCCの代わりにAVRToolchainをGCCコンパイラとして指定するだけです♥

●デジカメ買い換えました

2010年の8月に購入後数日で比叡山の登山道の石の上におっとこして以来だましだまし
使用していたねむいさんのIXYDIGITAL220Fちゃんが湯の山温泉のバトルで力尽きとうとう
縦向きでしか撮影できなくなりE32エラーも連発するようになったので最新のIXY3に
買い換える運びとなりました…

2年たつと全然性能が違いますね…まぢて…マクロ撮影が1cmまでできるのでTFT-LCDの
COGの解析に役立つかもしれません!



●今まで普通に使えてたSDカードが急に書き込み禁止になったんですけぉ!!1!!
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってるPCも上記の症状が
出るようになってしまいました…。SDカードは認識するがライトプロテクトが解除
出来ず書き込み禁止になるパターンはいくつかの原因が考えられます。

SDカード本体のライトプロテクトキーがLOCKになっている
 ->SDカードについているLOCKキーは物理的なものでSDカード内部と
  電気的なつながりはありません。もしこれがLOCKの位置になってたら
  ずらすと直ります。しかし大抵は…い紡海

SDカードリーダ・ライタのドライバ側がライトプロテクト設定にしてある
 ->ちょっとインテリジェンスなカードリーダ・ライタはたまにソフトウエアで
  プロテクト設定可能な機能があります。違うカードリーダ・ライタだと普通に
  読み書きができる手合いの奴ですね。マニュアルを見て解除してください。

Windowsを使ってる場合限定でレジストリの設定でライトプロテクトにしている
->google先生に聞いてください…

SDカードリーダ・ライトのソケットに問題があり、常にLOCK状態になっている
 ->使い込んだリーダライタやノートPC付属の奴ではよくありがちです。
  ではなんでこんなことになるのかを説明します。


SDカードの挿入検知(INS)とライトプロテクト(WP)検知はメカニカルスイッチで行われ、
カードリーダ側でその電圧レベルを読み取って状態を判断します。INSとWPのポートは
大抵は3.3Vでプルアップされています。


カード未挿入状態ではINSは解放されているので3.3Vになり、なおかつWPも上写真
ように解放されているので3.3Vとなり、ロジックレベルではどちらもHIになります。


このときSDカードのLOCKスイッチをLOCKにしないで挿入するとINSはSDカードリーダ
側のソケットと電気的に接触し信号レベルがGNDに落ちます。

同じくWPも挿入するとSDカード側のLOCKスイッチに物理的に押されてGNDに落ちます。
この状態ではカードリーダ側は読み書き可能と判断します。


一方SDカードのLOCKスイッチをLOCKの位置にスライドして挿入した場合、同じくWPの
接点とソケットのGNDが一時的に押されるわけですが深くまで挿すと位置的に再び解放
されてロジックレベルがHIに戻ります。
この状態ではカードリーダ側は書き込みのみ可能と判断します。

まとめると3つの状態があることがわかります。

・カード未挿入
 INS :HI(3.3V)
 WP  :HI(3.3v)
・カード挿入(LOCKの位置ではない)
 INS :LOW(0V)
 WP  :LOW(0v)
・カード挿入(LOCKの位置)
 INS :LOW(0V)
 WP  :HI(3.3v)


そしてWPの接点はINSよりも構造が脆弱で長期間使用で接点の弾性の劣化・酸化による
接触不良を非常に起こしやすく、ある日突然常にHIレベル(WP有効)と認識されるように
なってしまいライトプロテクト状態となってしまうわけです。

これについての対処方法ですが、つまりは接点を復活させればいいわけですが、USBの
カードリーダ使ってて起こった人は買い換えた方が手間暇も喰わず安上がりです。
しかしノートPC等で基板にソケットが備え付けられてるタイプの奴は一苦労です。大抵
修理保証期間を過ぎたころに上記の接触不良が発生するので上記の箇所の修理でも多額
のお金がかかるケースもあります。
ねむいさんの場合、購入後5年以上経過していたのとPCの裏蓋を外すとカードリーダー
のソケットが手の届く位置にあったので、WPの端子を導電性布テープで詰めて固定しGND
に強制的に落としてLOCKスイッチの位置にかかわらず常にWP解除状態としました。

接触不良の初期段階の書き込み禁止になったりならなかったりの時は接点復活王なども
有効かもしれません。いずれにしてもソケットが手が届く位置にある場合限定です。


●STM32F4DiscoveryでMP3プレーヤーを構築する

ククク…(by鍵最高)もうほぼ完成状態です…♥
こちらについては月末あたりに別枠でまたお知らせしますね〜

LM4F120シリーズを使ってみる2 -Stellaris Launchpad単体でOpenOCDで書き込み・デバッグを行う-


退院したら荷物がいろいろ届いていました。
9月末に購入したSTM32F3-Discoveryもようやく来てました…長かった…!
体の方も完全に元に戻ったので東海自然歩道のほうも再開していきますので皆様方
覚悟してください!



さて本題に入りますが入院前にStellaris LaunchpadにビルドインされたTI-ICDIの
OpenOCDの対応状況について少し触れてました。あの時完成間近だったのでもうコミット
されてるよねと思ったら差し戻しでまだレビュー中になっています。
なんだかリリース時期について揉めてるようですが、私たちユーザサイドもパッチを落として
試すことができるのでどんな感じか試してみました。

以前のLuminary-ICDIと違う点はJTAGデバイスとして使うチップがFTDIのではなく、LM4F
マイコンのファームウエアとして作りこまれていてドライバもTIのプロプライエタリな
物となっています。この点はSTLink/V2がOpenOCDで使えるようになった経緯とおんなじ
ですね。こちらもTIのスタッフの助力の下TI-ICDIを叩くためのAPIを提供してもらって
OpenOCDの上位のレイヤーと下駄合わせをしています。

そしてAPIを使ってアクセスするのがSTLink/V2だけではなくなるので汎用的なレイヤで
あるstlink_swdからhla_swdへとトランスポートの名称が変わってます(OpenOCDのコン
フィグファイルの定義を少し書き換える必要が出る程度の影響ですが)。

使用するデバイスドライバはTI提供のデバイスドライバがそのまま利用可能です。
OpenOCDがサポートしているのはJTAG接続のみでSWDは未サポートなのでご注意を。



てわけで早速書き込み・デバッグしてみました。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/ek-lm4f120xl_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00089-gd6d4283-dirty (2012-11-16-14:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : ICDI Firmware version: 9270
Info : lm4f120h5qr.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000280 msp: 0x20008000
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x20000042 msp: 0x20008000
wrote 33792 bytes from file main.elf in 2.059203s (16.026 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20008000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20008000
verified 33216 bytes in 0.561601s (57.759 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:03

今回のTI-ICDIの対応を機に表示される情報が詳しい物に変わってますね。
わずかな人のみが気づいていたようですが今回の書き込みに使ったテスト用のファー
ムは実は入院直前にUARTのルーチンも追加してました。
ChaN氏のLPC2388向けUART-FiFoを移植してます。

もちろんいつものデバッグ環境も自由自在です。
尤もTIの場合はIDE環境が非常に充実してるので無理やり私の行ってる環境にしないで
メーカー謹製の開発環境のままでも良いかと思います。


ついでですが冒頭のSTM32F3Discoveryでも同じことしてみましたこちらはおなじみの
STLink/V2がビルドインされてます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32f3x_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00089-gd6d4283-dirty (2012-11-16-14:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000708 msp: 0x10002000
adapter speed: 8000 kHz
auto erase enabled
Info : device id = 0x10036422
Info : flash size = 256kbytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x10002000
wrote 6144 bytes from file main.elf in 0.624001s (9.615 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x10002000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x10002000
verified 4172 bytes in 0.171600s (23.743 KiB/s)
shutdown command invoked

> Process Exit Code: 0
> Time Taken: 00:02

こちらも詳しい表示に変更されています。

いつもの。
STM32F3-Discvoeryもまた別に時間を割いてご紹介するつもりですのでこうご期待!



今回の検証に使ったOpenOCDはテスト版なので公開していませんがWindows環境を
持ってる人で試してみたい方は連絡ください。
さらについでですがLM4F用のioviewでGPIOの出力レジスタをビット単位で表示出来る
ように更新しました。

Go to top of page