いろいろ試す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カードが急に書き込み禁止になったんですけぉ！！１！！
物がよくつぶれる(人も)ようになりました。ねむいさんが使ってる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