S.M.A.R.T.が採れて安価なTranscendの民生向けSDカードを試す！
あけましておめでとうございます(もう1月末ですが)
今年は節目となるイベントがたくさんありますのでよろしくお願い
いたします…！！
さて、新年一発目はTranscend製でS.M.A.R.T.(以下SMART)が取れる
SDカード、それもいつもの産業用じゃなくて民生用で安価なものを
紹介させていただきます…！！
TranscendのHPに記載があってびっくりしたのですが民生品で
SMARTに対応しているのを明記してるのが出てきておりました。
Ultra Performanceと呼ばれるUSD340S/SDC340Sシリーズです！
このシリーズはSD SMART Toolboxなるもので上記カードから
SMARTの情報を読み取り使用量を把握できるものとなっているそうです。
ねむいさんもさっそく購入して試してみました！
大阪日本橋のPCOne'sで購入したのは128GB容量のTS128GUSD340Sです。
しかし…
ﾁｰﾝ
使用USBカードリーダーがTranscendのTS-RDF5でしかも2019年以降
製造のロットじゃないとダメだったようです…
てわけでRDF5の2020年以降製造と思われるカードリーダーを
購入してまいりました…！！！
ﾁｰﾝ
…
なんでだYO！！１！！
念のためねむいさんのFatFs実装例(STM32H5版)でCMD56放ってみましたが
全部0が返ってくる状態でSMART情報は得られませんでしたorz
もしかしてカードの方もほんとに最新のやつじゃないとSMARTに対応して
いないのでは…2022年製造の奴は古いってことですか…
念のためSDカードの情報を引っ張っておきました。
FatFs module test terminal for STM32H563ZIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jan 17 2025
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 17869 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 32717
Sectors/FAT = 16384
Number of clusters = 923424
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is 128GUSD340S
Volume S/N is 0977-190A
...
1 files, 132949600 bytes.
0 folders.
118198272 KiB total disk space.
118067456 KiB available.
>ds 0
rc=0
Drive size: 236462080 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 DB 79 00 03 86 07 7F 80 0A 40 00 BD @..2.y.......@..
CID:
00000000 74 4A 60 55 53 44 55 31 20 28 0A 09 9B A1 69 7B tJ`USDU1 (....i{
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x280A099B
DateCode.Month :9
DateCode.Year :2022
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E ..............9.
00000010 00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 05 84 87 00 00 00 00 ........
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :2
SD Security :0
SD Bus Width :5
SD_Spec V6.xx!
Detected as Not SD Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class2, A2 Card.
A2 CommandQueue Depth 32 Supported
A2 Cache Supported.なんかすごい気になったのはSD Securityの値が"0"になってて
CPRMサポートしていないようなんですよね…。
SD Securityビットの値でSDSC/SDHC/SDXCの判別してたのでちょっと
困ったことになりました…
ちなみにSDUCではCPRMサポートは完全除外されSD Securityビットも
0となるでしょうから別の方法でカード種別の判別するしかないですね。
気を取り直して店変えて買いなおしました…
今度はAMAZONでTranscend直売のTS64GUSD340S買ってみました…
これならたぶん古くとも2023年くらいでしょー…(願望)
そして…
！！
やったぁ！SMARTが取れた！
2024年10月製造のモデルでした！
ちなみに5年前、TranscendEmbedded様より超ご厚意でいただいた
"SD SMART Tool"でも無事にSMART情報を得ることができました。
やっぱこっちのほうが詳細が分かってよいですね〜
そしてこちらは2019年以前のRDF5でも普通に使えます。
なんで製造年数縛りでソフト作ったのでしょうか…???
ていうわけでこっちのカードもSDの情報抜き出しときます。
FatFs module test terminal for STM32H563ZIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jan 31 2025
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 20381 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 28621
Sectors/FAT = 16384
Number of clusters = 471032
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is 64GUSD340S
Volume S/N is FBDE-D5FB
...
1 files, 132949600 bytes.
0 folders.
60292096 KiB total disk space.
60161664 KiB available.
>ds 0
rc=0
Drive size: 120649728 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 DB 79 00 01 CC 3D 7F 80 0A 40 00 47 @..2.y...=...@.G
CID:
00000000 74 4A 60 55 53 44 55 31 20 76 0B 46 98 A1 8A 27 tJ`USDU1 v.F...'
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x760B4698
DateCode.Month :10
DateCode.Year :2024
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E ..............9.
00000010 00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 87 00 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :2
SD Security :4
SD Bus Width :5
SD_Spec V6.xx!
Detected as SDXC Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class2, A2 Card.
A2 CommandQueue Depth 32 Supported
A2 Cache Supported.ん？こっちはちゃんとSD Securityのところが4(SDXC)になってる…?
う〜〜むSDカードは水物でほんとによくわからん
そんでもってCMD56で抜き出したSMARTのデータも置いておきますので
ご参考に…512バイトのSMARTのデータのフォーマットはかつての
産業用SD/microSDと同じでした。だから同じツールが使えたのですね。
そんなわけで2025年になってようやく民生品レベルにもSMARTを搭載した
SD/microSDカードが浸透し始めた段階です。
まさに民生向けSDカードのSMART元年とでも言いましょうか…
願わくばSDの規格にSMARTが正式に搭載されることを祈り続け今後の
発展を見守ることにしましょう…
今回のまとめ
・Transcendの340Sシリーズは安価な民生品だがSMARTを搭載している。
・SMARTを見るためには以下の条件が必要。
��2024年以降製造のカード必須。それ以前のものはSMARTが無いかも。
��TS-RDF5が必要。しかも2019年以降製造のモデル必須。
※マイコンとかで直接CMD56を放つ場合はTS-RDF5不要。
・CMD56の引数やSMARTのデータフォーマットはTransendの
2021年以降新規発表・販売モデルの産業用SD/microSDと同一。
・SMARTの詳細は過去記事も参照のこと。
中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
今年の初頭にねむいさんはついに石川県を超えて富山県にも到達しました。
今回は富山と石川県の境を通って富山県は城端に行き着くことを
画策して実行してみました！いざ勝負！
●2024.11.16 中部北陸自然歩道(倶利伽羅〜医王山(〜城端))
二次裏メイドの朝は早い。
夜行高速バスで金沢駅に降り立ちます…。
金沢駅からはIRいしかわ鉄道で倶利伽羅駅へと向かいます…
倶利伽羅駅から65kmの長きにわたるバトルの開始です…！！
いきなりの登坂がお出迎えでいきなり歩いてしまう…
そして今回は全ルートでツキノワグマの恐怖にもおびえないといけない…
津端方面からくる旧北陸道と合流します。
倶利伽羅峠頂点部にある不動寺で道中祈願を行いました。
倶利伽羅剣がある場所が石川県と富山県の県境となります。
倶利伽羅峠周辺は源平合戦の地となっており、それにちなんだ
地名が紹介されています。そこにいざなう古道へと歩を進めていきます…！
道は下り基調になり高度を下げていきます。
合戦の舞台の開設やルート案内もここかしこにあります。
…しかし、ねむいさんは道間違えたのか変なところに入り込んでしまう…
強引に突っ切って降りた先は霧に包まれていた…
マヌーサ…
電子コンパスを頼りにとりあえず北に進んでチェックポイントの
松尾神社に行きつけました…年初の地震の影響で倒れた鳥居は
撤去されていました。
今回の自然歩道は3ルート分ありますがとりあえず1ルートはクリアです。
次のエントリポイントへと霧の中を進みます。
加越能バス藪波バス停です。
ここから2ルート目スタートです…！
ちょっと道に迷って時間食ったので巻き返します。
サイクルターミナルなる場所で道標に従って進んだつもりでしたが…！？
また間違って時間ロスしちゃった！
あーもうめちゃくちゃだよ！
チェックポイントの戸久神社です…
ここから道を南下…南下…して山の中に左折…
あれれ？？
峠超えて県道の分岐に出ちゃった！？
ここでまた正規ルートを探して迷う…
だいぶ戻って写真の民家の手前の薮超えた先に山道らしきものを発見…
こんなのわかりませんよう！
更なる激藪がねむいさんを襲う…
ようやく安全地帯らしきところに出た…
あとは下るだけ！
延々と下っていくとさっき間違えた県道と落ち合いました。
迷ったらこっちの道行ったほうが確実ですね…
さらに降りると安居寺です。
安居寺から離れたら別の県道に押し込まれます。
ちょうど自販機があったので補給を兼ねて小休止…
これはありがたい。
今度は県道をひたすら南下していきます。
遥かむこうに今回のターゲットの医王山が見えてきました…！
ひたすら舗装路を走って南下していきます…
ひたすら…ひたすら…
国道304号とクロスしてさらに進みます。
チェックポイントの光徳寺に到達しました…
壺がたくさん配置された変わったお寺です。
ここで中部北陸自然歩道の巨大案内板が出てきましたので
またまた小休止しました…。今ねむいさんが走ってきた安居寺〜光徳寺の
区間は車移動区間だったそうです･･･###
さて、ここから今回の本番の医王山への道が始まります…！
時刻は11:30、今のところ予定時刻通りに進んでいますが間に合うのか！？
医王山トンネルを抜けてぬく森の里の分岐から
県境をひたすらなぞる"百万石道路"の始まりです…
ここでも熊の脅しがありますね…
百万石は車でも登れるように舗装路となっていますが
疲労が蓄積した足にこれはきつい…
別の登山道や近年発掘された殿様道路とも合流して
道はづづいていきます…！
ひたすら続く道、道、道…！
足が上がらずほとんど歩いちゃってます…
でも急がないと…！
だいぶ高度が上がってきたと感じたところで国見ヒュッテに到達しました。
今年の営業はもう終了しているようですね。
医王権現社で残りの道中祈願をしました。
無事に城端に戻れますように…！
鳶岩、白兀山への分岐がある辻堂を超えていきます。
山道は延々と続く…
疲れがたまっているところに上り下り入れられるとマジきつい…！
進んでいくとイオックスアローザスキー場が見えてきました…！！
夕霧峠まであと少しＤＡ！
巨大休憩所がある夕霧峠に到着です…！！
夕霧峠は菱広峠とも呼ばれています。
さて夕霧峠に到達した時点で13:50、時間も余裕ができたので
追加ちゃれんぢの奥医王山山頂にアタックを行いました！
がぁあああああ…50�匐瓩�走ってきてこの階段攻めは効く…
見返り杉と龍神池です。
?
ッッようやく奥医王山に到着です…！
あとはひたすら駆け下りて城端に帰るだけとなります…！
さすがに下りは早い。
夕霧峠がどんどん離れていきます…！
イオックスアローザスキー場の中の道を駆け下りていきます…！
途中で湧き水の金銘水がありました。
これはありがたい…！
紅葉とススキのコラボを見ながら駆け下りていきます。
中部北陸自然歩道の今回のルートの起点に到達しました…！
ですがねむいさんのゴールは城端なのです！！
アローザ村の中を駆け下り、スキー場の敷地とも別れを告げます…！
さらに東に進んで長沢バス停に到達です。
公式の案内ではこのバス停がルートの終点ですがバスの便は
一切期待できないのでJR城端駅までさらに進んでいきます！
最後の最後まで上り坂でねむいさんを苦しめる…がぁああああ！！
ぁあ…やっと道路標識も城端の文字が…！
城端大橋を通過して城端の市街にとりつきました。
城端は小京都と呼ばれていてちょっとした観光地になっております。
(最後のローソンで物資買ってから)ラストスパートで17:00丁度で城端駅に
無事ゴールとなりました…！予定時間より20分早く到着です☆
ですがこの先も気が抜けません…ここから京都に帰らないといけません。
まずは城端線に揺られて新高岡へ…
そんでもってタイトなスケジュールで新高岡駅で敦賀行の
北陸新幹線に乗り換えます…！
そんで新幹線に乗っても気が抜けず敦賀に到着したら乗り換えレースが
はぢまります…エスカレーターで詰まったときちょっと焦りました…！
何とか乗り換え時間以内に在来線特急のサンダーバードに乗ることが
できてようやく一安心です…！！
ほんとに最後まで気が抜けない戦いの一日でした…！
というわけで積雪期になる前に富山のこのルートを攻略してまいりました。
んでもってようやく敦賀延伸後の北陸新幹線乗ったりして新しい北陸への
アクセスに体験してまいりましたが徐々に慣れていこうと思います。
これからも北陸方面には手を広げていこうと思いますので今後ともヨロシク…！
●2024.11.16 中部北陸自然歩道(倶利伽羅〜医王山(〜城端)) GNSSログ
にしても今回はひたすら長かった…
ほとんど舗装路だったのもあるでしょうね〜
いろいろ試す62
●Picoscope7のソフトがバージョンアップ！今度こそ安定…か？
すぐフリーズしたり落ちたりでなかなか安定しないPicoscope7のソフトですが
Stable版が7.1.29にバージョンアップしておりました。
今度こそ本当にStableなんでしょうね…！？(どきどき
※会社で現役でバリバリ使用中のPicoscope3206Aで試してます
☝2画面で動かして放置すると固まったorz
…
ファ〇ッッック！！！！！
基本的な操作はだいぶ安定してきましたがちょっと複雑な操作はまだ
安定していないようですね…
というわけで安定して使用できるまでPicoscope6使っていきましょ…。
●arm-gccが久々の更新
Arm GNU-GCCが久々の更新です。
といってもGCC14ではなくまだGCC13のままです…。
13.2->13.3のマイナーチェンジですね。
また、今回はセキュリティ対策のアップデートしております。
同じプログラムをビルドしてバイナリサイズの比較です。
13.2Rel1(前のやつ)
arm-none-eabi-gcc (Arm GNU Toolchain 13.2.rel1 (Build arm-13.7)) 13.2.1 20231009
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 479156 0 479156 74fb4 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
477416 1740 39668 518824 7eaa8 main.elf
main.elf :
section size addr
.text 0x747fc 0x8000000
.ctors 0x0 0x80747fc
.dtors 0x0 0x80747fc
.eh_frame 0x54 0x80747fc
.ARM.exidx 0x98 0x8074850
.data 0x6cc 0x20000000
.bss 0x18a8 0x200006d0
.heap 0x0 0x20001f78
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x44 0x0
.debug_frame 0x1e88 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x80b9e13.3Rel1(新しいほう)
arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478396 0 478396 74cbc main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476624 1772 39668 518064 7e7b0 main.elf
main.elf :
section size addr
.text 0x744e4 0x8000000
.ctors 0x0 0x80744e4
.dtors 0x0 0x80744e4
.eh_frame 0x54 0x80744e4
.ARM.exidx 0x98 0x8074538
.data 0x6ec 0x20000000
.bss 0x18a8 0x200006f0
.heap 0x0 0x20001f98
.ram2 0x0 0x20040000
.stack 0x0 0x20040000
.ram3 0x824c 0x20050000
.bkpram 0x0 0x40036400
.qspirom 0x0 0x90000000
.comment 0x45 0x0
.debug_frame 0x1d98 0x0
.ARM.attributes 0x38 0x0
.debug_line_str 0x1f2 0x0
Total 0x807b7Flash使用量は減りましたが…、
ううむ若干SRAM使用量増えてますね…。
mapファイルを比較してましたがnewlibでSRAMの使用量が32byteほど増えて
おりました。…まぁこの程度なら許容の範疇でしょう…。
一応STM32H5でlibpngのDecode速度のパフォーマンスを比較してみました。
13.2Rel1
13.3Rel1
あ…ありり…
ちょっとかなり遅くなってる…(脂汗
…
GCC14に期待しましょう〜！！
13.3Rel1のGDBはCortex-M33コアでbreakpointが効かなくてデバッグが
できないことが判明しました…(多分バグです)
ひとつ前の13.2Rel1のやつ使いましょう…
20240828追:
13.3Rel1のGDB(GDB14)はちょっと規模が大きいプロクラムになると
breakpointが効かなくなってデバッグが全くできなくなることが
判明しました…orzおそらくGDBのバグっぽい挙動ですがまだ情報が
出そろっていないので今は13.2Rel1のarm-gccを使ったほうが無難です…
どうしてこんなことにorzorz
●組み込み向けのLTO考察
リンク時最適化(LinkTimeOptimization)。ねむいさんは10年位前に使った際に
バグが多くて封印してそれっきりでした。ここ最近はどうなっているのか色々
調べてみましたが、あのころと比べてかなり様変わりしてるのがわかりました。
まずは公式のLTOの解説をしっかりと読みとおすこと。
そのうえでLTOのビルドを成功させるためには幾つかの障壁がありました。
*FONTX2のファイルを直接取り込むincbinと相性が悪い
LTOなしだとビルドできるのにLTOつけるとアセンブラでエラー吐いてこける。
LTOの場合はmakefileがあるところからのフルパスを指定しないといけない。
makefileが存在するディレクトリからの相対パスを指定しなおすことで
苦しみ紛れに屁をこいたような対策ですが何とか対処できました。
*引数も重要
ビルド時に与える引数も"-flto"だけじゃダメになっていて、試行錯誤した結果
以下のオプションを全部追加することでLTOビルドを達成できました。
-flto
-ffat-lto-objects
-fuse-linker-plugin
-flto-partition=noneSTM32H5のビルドサイズ比較をしてみましょう
LTOなし
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 478260 0 478260 74c34 main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
476488 1772 39668 517928 7e728 main.elfLTOあり
Built Object Informations:
=== Total Binary Size ===
text data bss dec hex filename
0 473372 0 473372 7391c main.hex
=== Verbose ELF Size ===
text data bss dec hex filename
471608 1764 39672 513044 7d414 main.elf5kByte弱削減できました。SRAM消費量も微量ながら減ってますね。
もちろんLTOありでもちゃんとプログラムは機能します。
大規模プロジェクトなので効果は感じづらいですがSTM32C0とかの
小規模なプログラムなら削減効果をかなり実感できると思います。
あとリンク段階で変なワーニング出るんですけど対象方法知ってる人いたら
教えてくだち。
●mbedサ終
ついに来てしまいましたね…
ねむいさんもほとんど使用しないままここまで来てしまいましたが
時代の仇花として人々の記憶に残るでしょう…(2026年完全終了)。
ねむいさん的にはオンラインコンパイラは圧倒的に相性悪くてやっぱり
PCで普通にコンパイルするのが身の丈に合っていると感じました。
●STLinkV3はST製以外のマイコンを排斥する！実質STM32専用ｯ！
まぢですか…、OpenOCDからも使えないとは…！
秋月で売ってるやつ買わないでよかった…！
実質STM32以外の他社製のCortex-Mのマイコンのフラッシュ書き込みは
おろかコアにconnectすらできないようです…。
一方で手持ちのSTLink/V2系は大丈夫なのかどうか実際に確認してみました。
使用したのはおそロシアの力でSWIMに無理やり対応させたSTM32F0Discovery
付属のSTLink/V2です…相手は今は亡きLPC810です！
まずはHLAとして接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -c "transport select hla_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : clock speed 1000 kHz
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.905861
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.093837s (2.743 KiB/s)
Info : verified 3072 bytes in 0.055933s (53.636 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01お次はDAPDirectで接続
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/lpc81x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00682-gefe902219 (2024-08-12-08:52)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : STLINK V2J45S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 2.882555
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0bc11477
Info : [lpc81x.cpu] Cortex-M0+ r0p0 processor detected
Info : [lpc81x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [lpc81x.cpu] Examination succeed
Info : [lpc81x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[lpc81x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
Info : wrote 3072 bytes from file main.elf in 1.219387s (2.460 KiB/s)
Info : verified 3072 bytes in 0.063133s (47.519 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
ファームのVerは20240821最新のV2J45S7を使用しておりますが、
STLink/V2のハードウエアなら他社製Cortex-Mマイコンでも大丈夫なようですね…
●そしてぱちもんSTLinkV2にもパチモン対策が
まぁこんなこったろうと思っていましたが、粗製乱造で広まっている中華製偽物
STLink/V2を検知したらシリアル番号を"C"にしてしまうファームウエアが発動
しているようです。
STM32CubeProgrammerではこのシリアルをもつぱちもんSTLink/V2が
使用できなくなります。
OpenOCDからはまだ大丈夫っぽいですがこちらも穴がふさがれそうですね。
ちなみにねむいさんがSTM8マイコンの読み書きするためにおそロシアの力を
使って改造したSTLink/V2はシリアル番号は"C"ではなかったのでセーフでした。
恐らく正規のSTM32マイコンを使用しているか否かで判別しているようですね。
STM32U0はぢめました
買ってから3か月以上たってしまいましたがまだ私が国内一番乗りかな！？
STM32L0の省電力性をさらに高めてなおかつパフォーマンスも妥協しない
新シリーズとしてSTM32U0が登場しました。
MCUの拡大写真です。
パッケージに二次元バーコードがついていて時代の流れを感じさせますね。
STM32U0シリーズは現在STM32U031x,STM32U73x,STM32U83xの3種がライン
ナップされておりますがねむいさんはフラッシュ容量最大のSTM32U083RCT6を
搭載したNUCLEO-U083RCを購入しました。
STLink部分はSTLinkV2-1相当ですがコネクタがUSB-TypeCとなってますね。
また、STLinkを電気的に切り離し外部からデバッガ接続できる構造になって
いますが2mmピッチの独自14ピンコネクタなのはちょっと扱いづらいです…
これは完全にSTLinkV3-MINIEを接続することを意識したものでしょうか？
まぁNUCLEO基板搭載のSTLinkV2で十分事足りるので外部デバッガの登場は
ないと思います。
●ところで肝心のOpenOCDの対応状況は？
御多忙にもれず未だ誰も触れてない理由としてはOpenOCDがまだSTM32U0
のフラッシュ書き込みに正式対応してないことにあると思います。
ちなみにgerritにパッチは上がっておりますが現在パッチ自身に不備が
あって普通にあてただけだとビルドエラーになります…F**K!!!!
そしてそのままずっと放置されております…おいおい
というわけでねむいさんサイドでちょっと手直ししてU0シリーズにも
対応させてみました。ドライバの分類としてはSTM32G0,STM32C0と同じく
STM32L4のグループに属するようですね。
STM32U0対応のOpenOCDダウンロードはこちらからどうぞ！
上記OpenOCDのバイナリには収録しておりますが、フラッシュ書き込みや
デバッグの基底となるstm32u0.cfgも存在してなかったので今回作って
収録しております。
# SPDX-License-Identifier: GPL-2.0-or-later
# script for stm32u0x family
#
# stm32u0 devices support SWD transports only.
#
source [find target/swj-dp.tcl]
source [find mem_helper.tcl]
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME stm32u0x
}
set _ENDIAN little
# Work-area is a space in RAM used for flash programming
# By default use 6kB
if { [info exists WORKAREASIZE] } {
set _WORKAREASIZE $WORKAREASIZE
} else {
set _WORKAREASIZE 0x1800
}
#jtag scan chain
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
# SWD IDCODE (single drop, arm)
set _CPUTAPID 0x0bc11477
}
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap
$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
flash bank $_CHIPNAME.flash stm32l4x 0x08000000 0 0 0 $_TARGETNAME
flash bank $_CHIPNAME.otp stm32l4x 0x1fff6800 0 0 0 $_TARGETNAME
# reasonable default
adapter speed 2000
adapter srst delay 100
if {[using_jtag]} {
jtag_ntrst_delay 100
}
reset_config srst_nogate
if {![using_hla]} {
# if srst is not fitted use SYSRESETREQ to
# perform a soft reset
cortex_m reset_config sysresetreq
}
$_TARGETNAME configure -event examine-end {
# Enable DBGMCU clock
# RCC_DBGCFGR |= DBGEN
mmw 0x40021050 0x00000001 0
# Enable debug during low power modes (uses more power)
# DBGMCU_CR |= DBG_STANDBY | DBG_STOP
mmw 0x40015804 0x0000000C 0
# Stop watchdog counters during halt
# DBGMCU_APB1_FZR |= DBG_IWDG_STOP | DBG_WWDG_STOP
mmw 0x40015808 0x00001800 0
}
へルパーcfgのstm32u0_swd_flash.cfgはこんな感じです。
# script for stm32u0x with flash programming
# Nemuisan's Special
source [find target/stm32u0x.cfg]
$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
proc mt_flash {IMGFILE} {
flash write_image erase $IMGFILE
verify_image $IMGFILE
reset run
shutdown
}
proc mt_flash_bin {IMGFILE OFFSET} {
flash write_image erase $IMGFILE $OFFSET bin
verify_image $IMGFILE $OFFSET
reset run
shutdown
}
proc mt_flash_hex {IMGFILE} {
flash write_image erase $IMGFILE 0 ihex
verify_image $IMGFILE 0
reset run
shutdown
}
proc eraser {} {
stm32g0x mass_erase 0
flash erase_check 0
shutdown
}
#debug_level 3
#reset_config srst_only srst_nogate connect_assert_srst
reset_config none
adapter speed 500
gdb_target_description enable
init
reset init
それらを使って書き込んでみたところのログはこんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00658-g6554d176e (2024-07-21-10:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
dapdirect_swd
DEPRECATED! use 'gdb target_description', not 'gdb_target_description'
Info : STLINK V2J45M30 (API v2) VID:PID 0483:3752
Info : Target voltage: 3.236554
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : [stm32u0x.cpu] Examination succeed
Info : [stm32u0x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections
[stm32u0x.cpu] halted due to breakpoint, current mode: Thread
xPSR: 0xf1000000 pc: 0x08002b30 msp: 0x2000a000
Info : device idcode = 0x10006489 (STM32U07/U08xx - Rev A : 0x1000)
Info : RDP level 0 (0xAA)
Info : flash size = 256 KiB
Info : flash mode : single-bank
Info : Padding image section 1 at 0x08008004 with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x08008008 .. 0x080087ff
Info : wrote 32776 bytes from file main.elf in 1.595168s (20.065 KiB/s)
Info : verified 32772 bytes in 0.780823s (40.987 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03
もちろんデバッグも自由自在です。U0シリーズの要であるスリープ時
等からの接続デバッグにも対応したつもりですが人柱お願いします…
●実際に動くものを作ってみよう
使い勝手としましてはSTM32G0,STM32C0とほぼ同じなので移植もあっさり
できちゃいました。
NUCLEO基板で定番となったI2Cを使用したセンサとOLEDの表示ルーチンを
サクッとこしらえてみました。なお、STM32U0は最大動作周波数56MHzで
動作しますが48MHz動作のほうが潰しがきくのでお勧めです。
私の作例では48MHz動作としております。
●ちょっとした注意
STM32U0は徹底した低電力性を唱えておりますので初期状態でほとんどの
モジュールにクロックが供給されておりません。
ねむいさんもうっかり嵌ってしまいましたがU0ではDBGMCUのクロックが
初期状態で供給されておりませんのでMCUのリビジョンをやIDを取りたい
場合は下記の要領でクロックを有効にしてやりましょう。
#if defined(USE_STM32U083RC_NUCLEO)
/* STM32U0 DeviceID & Revision Detection */
char mcurev;
__HAL_RCC_DBGMCU_CLK_ENABLE(); // <- これ
uint16_t revid = HAL_GetREVID();
uint16_t devid = 0x0FFF & HAL_GetDEVID();
if (revid == 0x1001) mcurev = 'Z';
else /* 0x1000 */ mcurev = 'A';
printf("STM32U0xx DevID 0x%04x Rev.%c¥n",devid,mcurev);
printf("STM32U0xx UID 0x%08lx%08lx%08lx¥n",HAL_GetUIDw2(),HAL_GetUIDw1(),HAL_GetUIDw0());
printf("¥n");
#endifOpenOCDでは上でも述べましたがcfgファイル内で接続した瞬間にDBGMCUの
クロックを有効にするように仕込んでますので安心です(人柱求む)。
というわけでSTM32U0という新しいラインナップが加わったわけですが、
U0はL0シリーズの後継という位置づけのようなので市場もL0からU0へと
次第に置き換わっていくこととなるでしょう。
STM32も世代を重ねて着実に進化していくので楽しみです。
中部北陸自然歩道を往く -再走！小松から金沢まで-
今年6月早々に敦賀〜金沢まで走破達成した…つもりでしたがあとから
調べたら小松〜金沢間で"整備中・廃道"となっているルートが存在している
ことが判明し、この年末にその失われたルートに赴いて真の走破達成を
目指しました！！！はてさてどうなることやら…
●2023.12.28 中部北陸自然歩道(小松〜金沢)
なぜ私は再走を…
再び小松の地に立つ私…
新幹線ムードがいやがおうにも高まる小松駅からスタートです…！
小松は歌舞伎推しですね
菟橋神社で47�匱紊離丱肇襪良�勝祈願をしました！
安宅橋近くに来ました。
6月に訪れた安宅灯台も見えますね。
"自然歩道"のルートと合流します。安宅バス停付近です。
石川県内のルートは現在正式には3ルートしか存在しませんが
実は"自然百景の道"なる大量の中部北陸自然歩道構想が存在して
おりました。こんなにあったのになぜ今3ルートしかないかというと
予算とかの都合で整備放棄->廃道となったり永遠の未整備となって
いるようです。
そして！これが！整備放棄され廃道化した"弁慶・義経なみだのみち"です…
今回はこの自然歩道たちに忠実に進んで金沢へ向かいます！！！
ちょっとグラウンドを周回した後すぐに日本海に出ます…がいきなりの
冬季通行止め看板が！
今回のルートは小松加賀自転車道と道をほとんど同じくしておりますが…
まぁこの天気だと問題なく全部通れそうですけどね〜(死亡フラグ
ちゃんと側道もあるのでこちらを通りました。
と思ったらすぐに住宅街方面に押し出される…
翠が丘運動公園から北陸自動車道を超えていきます。
住宅街ルート中にも神社仏閣がちらほら見られ、
飽きさせません。
源平合戦で有名らしい根上松です。
高坂公園です。
ほんと神社仏閣が多いですね…
サンダーバードが北陸の大地を駆け抜けるのもあと少し…
能美根上駅で小休止しました。
能美根上駅から再び日本海に向かいます。
と思ったらまた住宅街に戻される…
JR小舞子駅です。
ここで弁慶・義経なみだのみちはおしまいです。
次は加賀海岸しおかぜのみちらしいですが…
国道に沿って取手川を越えていきます。
さぁ今度こそ日本海を走る！
と思ったらまたまた戻されていく…
取手公園平賀園地に沿って進みます。
今度こそほんとのホントに日本海沿いをひたすら走るルートに！！！
あ、こんなところに
いつもお世話になっております(意味深
豪快な日本海とどこまでも続く自転車道、そして…
12月とは思えないくらい日差しが強い太陽…！
天候的には抜群のコンディションですね…
日本海の荒波に常にされされているせいかここかしこに補修を続けて
いる場面が見られます…こういうのもあって自然歩道から外れちゃったの
でしょうねぇ…
徳光PAに到着です…！
売店でマス寿司を買って大休憩で後半戦に備えます。
？？？
さぁ後半もお気楽自転車どu…う”！？
道が砂で埋まってる！？
砂に足を取られて先に進めない…靴の中にもどんどん砂が
たまってくる…天候はベストなのが唯一の救いです…
と思ったら今度は川かＹＯ！
これ自転車道ですよね…？
体力をごりっと削られてやっと砂地獄から解放された…
ていうか冬季に限らず自転車で通れるわけないでしょ！！！
県民海浜公園で砂落としがてら休憩です。
ここから先は川沿いのサイクリングロードを走ります。
ねこ。
犀川サイクリングロードに沿って駆け抜けていきます…
あと少し…あと少し…
北陸新幹線の延伸ももうすぐですね…
金沢市街に突入しました。
最後の神社にお参りして香林坊に向かいます。
自然歩道の終点(と思われる場所)、芭蕉の辻に到着です。
香林坊まであとほんのちょっと！！！
ッッ到着…！！
北陸道の交差路香林坊に到着です！！！！
そして昨年10月から足掛け1年2か月…敦賀から金沢まで自然歩道を
たどってこんどこそ真の走破を達成しました！！
金沢駅に来たらゴーゴーカレーも忘れない！！
いただきます！！！
さておなかを満たした後は…(道に迷ってる)
やっと見つけた！
サウナもある瓢箪湯で足の疲れをいやしました…♨
お土産もたくさん買い込んで京都に帰還です…
次に金沢に来るときは北陸新幹線になるのかな〜
…と思いながら帰路につきました。
ていうわけで年末ぎりぎりに突っ込んでみましたが後半の砂地獄以外は
懸念していた雪もなく天候に恵まれ楽しく？走り抜けることができました！
●2023.12.28 中部北陸自然歩道(小松〜金沢)GPSログ
さぁ次は今度こそ富山県境にアタックDA!
STM32H5はぢめました
20240516追:
秋月さんよりNUCLEO-H563ZI販売開始です！！
20240516追:
↑STM32H56x/57xエラッタシートより
ぇえぇ…エラッタで1000回しかフラッシュ書き換えできないとか
どこのルネ〇サスのマイコンだYO…
被弾するのはrev.AとZね…ふむふむ
…
おいいいいいいいいいいいいいい！！！！！！！！１１！！１１
というわけでいきなり地雷を踏んで幸先の良いスタートを切った私のSTM32H5
ですが、現時点ではSTマイクロがリリースするCortex-M33コアを持つ最新の
マイコンとなっております。
動作周波数は250MHzにまで引き上げられ、インストラクションキャッシュや
データキャッシュ(FMCとQSPIのみ)も増強され、STM32F7に勝るとも劣らない
実力を備えながらも電力は控えめと環境にも優しいものとなっております。
過去にリリースされた同じCortex-M33のマイコン、STM32L5のパフォーマンス
強化型の進化の位置づけとなりなおかつベストセラーだったSTM32F4の後継と
なるでしょう。ちなみに低消費電力特化型はSTM32U5となりこちらも順当に
進化し続けております。
ねむいさんは7月上旬早々に144Pin版H5NUCLEOを購入しておりましたが先に
塩漬けになっていたSTM32L5の攻略に時間がかかっておりましたので10月に
入ってようやく手を付けた次第でございます…。
NUCLEO基板なのでデバッガもコミコミで搭載されております。
当たり前のようにSTM32F723がのっかっている…これはSTlinkV3相当ですね〜
USBの端子はすべてType-Cに統一されております。
STM32H5がUSB-PDに対応してるからですね〜STM32H5Cube見た限りでは
USB関連はかなりの魔境になっているので当分手出しできそうにないですが…
また、イーサネットも出ております。こちらも魔境なのでかなり先の課題と
なるでしょう…！
144Pin版NUCLEOなのでSTM32L5の時に拵えたゲタ基板ももちろん引き続き
流用可能となっております！
おっと
一点注意ですがQSPI-ROMも使いたい場合はSB70にジャンパをしてください。
PE2(OCTO-SPI IO2)がデフォルトでは電気的に接続されておりませんので
SB70をジャンパして有効にするのを忘れぬようご注意ください。
いずれ紹介するQSPI-ROM使用時の記事に再度アナウンスします。
そんなわけで今回は単に基板の紹介に終わってしまいましたが、実は
すでにねむいさんのいつもの(UART,SDMMC経由FatFs,OCTO-SPI,SPI液晶)
は実装済みとなっております。今回は各モジュール、特にSPIとDMAがL5と
全く違ったものとなっているため一つ一つじっっくりと時間をかけて解説
させていただきます。H5の記事作成これからもがんばるぞい！
とりあえずSTM32H5のFatFs実装例を見たいんだーい!!って人はもうすでに
おきぱに配置しておりますので予習をお願いいたします。
ねむいさんの真似をしてゲタ基板を作られた方ならすぐに再現可能と
なっておりますので是非ご利用ください！
また、私が提供するOpenOCDバイナリはSTM32H5の書き込み&デバッグを
サポートしておりますのでNUCLEOをお持ちの方はこちらもご利用ください！！
STM32C0を使ってみる2 - OpenOCD正式対応記念 -
20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:
気づいたら私ってば今月3件も記事更新してますね…北陸侵攻は資金がすぐ
尽きるので気軽に山行けないのとGWの過密期間ずらしの相乗効果でひまが
出来てしまっておかげでしょうか…？それはさておき
さて、去る5月も末になりついにOpenOCDがSTM32C0のフラッシュ書き込みに
正式に対応と相成りました！
ねむいさんもgerritでアシストした甲斐があったものです。
おきぱにあるOpenOCDバイナリは既に対応済みで、もちろんSTM32C0用の
書き込みスクリプトの公開をしております☆
そんでもってSTM32C031-NUCLEO向けの基本プロジェクトも機能を大拡張
して公開しておりますので今のところ誰もC0使ってないようですが、
これからどんどん使ってほしいとおもいます…！
もはや実家のような景色のOpenOCDで書き込んでいるところです。
まぁ10数年やってる同じことだからもう慣れたもんですね〜
…ぇ？お前Codelite使ったデバッグ手順の公開はいつだって！？
すみませんそれだけはもうちょっとだけ待ってください・・・・！
その代わりといってはナニですが私のプロジェクトの詳細をちょっと
解説しておきましょう。色んなセンサに対応するために#defineの嵐に
なっておりますがその分細かく各機能の確認が可能です。
私の公開しているSTM32のNUCLEOボード系プロジェクトは簡単質素を
掲げており、他の方が再現しやすいようにペリフェラルも下記機能に
限定して使っております(144Pin系のNUCLEO除く)。
・汎用タイマ(を使ったuSecウエイト)
・UART(割り込み・リングバッファつき)
・I2C(センサ・表示デバイスのドライバ付き)
・1-Wire(GPIO制御による)
まずはI2Cデバイスが何もなくてもLEDとUARTが確認できるものです。
STM32C0-NUCLEO基板を買ってきてすぐに試すことができます。
UARTはSTLinkがVCPの役割もしているので別途USBシリアル変換を
用意する必要もありません☆
お次はI2Cの機能ですが、前回も言いましたがI2Cデバイス用の+3.3V
電源はAVCCからとっているため、SB25ジャンパは必ずしておいて
ください！！！買ったときはジャンパされておらずAVCCがつながって
おりません！STM32C0-NUCLEOの罠です！
NUCLEO系の基板はこんな感じに都合よくI2Cの機能を試すのに丁度よい
ピン配置で線が出ているのでやっけつハーネスを使って外部のI2C
テスト基板に接続しています。
さらにそこからSTN-LCD/OLED用の線をこんな感じで引き出します。
私はブレッドボードは意地でも使わないウーマンなのでこういった
変換基板や、ハーネス製作で汎用性を持たせプロトタイピング性を
高めております。
ちなみにI2Cのバスライン全体のプルアップ抵抗値についてですが
"つぶし"が効くように2.7~4.7kohmを保つように気を付けております。
さらにSCLのクロックはむやみやたらに上げず100kHzをベースとして動作
挿せております。最適化はまず確実に動かしてからするものです。
あとオシロスコープの波形確認用にこのようなブリッジ接続用治具を
作っておくと波形解析に極めて便利です。
秋月さんで売っているこちらのリードアダプタと組み合わせると
安定確実に波形測定が可能となります！
それとI2C程度の速度の波形確認なら今では格安で10万円以下で
USBの2chオシロが手に入るので必ず持っておきましょう。
安物でもあるのとないのとでは開発のスピードが全く違います。
遊びでも投資はケチらずしっかりと行いましょう！
話を戻して5月の更新からデフォルトのドットマトリクス表示デバイスを
I2C-STNから秋月さんで購入可能な入手しやすいI2C-OLEDに替えております。
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
STNの方はねむいさんのお気に入りで今みたいにOLEDが自由に使える環境は
まだなかったので時代を感じますね…この辺長くなるのでまた次回にでも。
でもねむいさんこの2.5元I2C-STN液晶いまだ大好きなんですけどね…(一番手前の)
センサは秋月さんで購入できるAosoungのAHT21Bを使用することにします。
実際はAHT2x系ならAHT25やDHT22、AHT20も後述の設定で動作可能です。
main.cのdefineの定義はこのようにしておいてください。
ドットマトリクス表示デバイスはSSD1309を、defineはAHT2X系のテスト
ルーチンとします。
makefileの定義はSSD1309ですがスクロールなどの特殊コマンドは
使用しておらず、基本コマンドだけで動かしているのでSSD1306でも。
SH1107でも問題なく動作すると思います(動作は遅いですが)
20240129追:
この時公開していたSSD1309用のドライバでは秋月OLEDを動かせませんでした！！
ごめんなさい！！！
20240129現在は秋月OLED用のSSD1306に対応しております！！！！
20240129追:
それとソース読んでて気づいているかと思いますがI2Cの各センサ
モジュールとI2CのOLED/STNでSTM32の同じI2Cポートを二重に初期化
しております。
これはドットマトリクス表示ライブラリ(xMSTN)の開発はSPI接続の
ものから行っていた経緯がありI2Cインターフェースのものは後から
追加されたことに由来しております。
はたから見れば二重に初期化してて未意味な無駄コード構成になって
いるように見えますがオシロで波形を確認し、実害はないことを確認
しているので将来の拡張を考えあえてこのようにしております。
決して手抜きではない！
AHT21BをOLEDを変えつつ動かしているところです。
湿度がだいぶ高くなってますがこの記事を書いてる時点で京都も
梅雨入りしたそうです。
以前は対応しておりませんでしたがCRCチェックに対応済みです。
こちらも次回の"いろいろ試す"時に詳細をお伝えします。
DS18B20やAM230x系の1-wire系デバイスももちろん動作します。
プルアップ抵抗は4.7kohmにしておいてください。
BME280をお持ちの方はこちらもしっかり動作します。実はBME280も
シリアルナンバを取得できるのですがこれも次回に詳細をお伝え
しましょう…
そんなわけでまだユーザーがほとんどいないSTM32C0ですが、秋月さんが
STM32G0の後釜でNUCLEOや単体SO8パッケのチップとか販売してくれたら
爆発的に広まると思います！
だから秋月さん頼みますよぅ〜！
20240223追:
秋月にSTM32C0参上！！
いろいろ試す56
ぁーGWですね〜…
出張疲れでなんもやることないので今まで貯めてきたUSBシリアル
変換で嵌ったチョイネタを公開します。
●USB-シリアル変換のRTSとかの制御タイミングは結構適当？
いいえ、ねむいさんの脳みそが適当(仕様)
ねむいさん副業(本業は二次裏メイド)でHalf-DuplexなRS485の
ちょっとした基板を製作しておりました。
MAX485データシートから抜粋と追加。
_REとDEを一つにまとめ、HIで送信、LOで受信に切り替えます。
そのような仕組みなので何らかの方法で入力と出力を切り換えないと
いけないのでRS232-Cの規格に存在するRTS信号出力を手動で切り
変えて送受信を制御してやろうと思ったのですが…
…うまく動かない…
なんか送信がぶつかってるような…
最初FTDIのやつ使ってたのですが通信できたりできなかったり
そんでProlificのやつ使ったら全く通信できにゃい！！！
ぬがああああああ！１１１！！！１！！
というところでようやくオシロスコープを引っ張り出して波形を
確認することにしました。ねむいさんいつも他人にはオシロで
ちゃんと波形確認しろと言っておきながら自分もめんどくさくて
やってない。
まぁそれは置いといて実際測定してみるとなんでか分かった。
まず検証に使ったソースコードですがVC++で適当にプロジェクト
作ってCreatefileでCOMポート開いてその際にDCB構造体のfRtsControl
に"RTS_CONTROL_TOGGLE"を設定しておきます。
これでWrite関数を実行、具体的には送信したい文字列を…
今回はDAAAAAAAAA¥r¥nというゼEROみたいな文字列を1秒ごとに
吐き続けるやつで検証してみました。
イケてるとき。
信号レベルはTTLレベルなので反転前なので注意してください。
ここで見るべきは文字列送信終了後にRTSが変化していることです。
でも1.5mSecもかかって信号レベルが遷移している・・？
イケてないとき。
なんと試行して数回目で発生した！！
送信し終わってないのにRTSが戻ってる！！！！
こりゃだめだ…。
RTSの信号をEscapeCommFunction関数で手動で変えてみたりしましたが
文字列送信中にRTSが受信方向に変化しやがったり逆に何mSecも戻
らなかったりもうぜんっぜんだめ…
もう疲れたのでFTDIの奴は置いといて今度はProlificのチップ
使ったUGREEN製のUSBシリアル変換ケーブルで試してみました。
注:信号レベルはRS232なので注意。それと時間レンジに注目！
おいいいいいいいいいいいいいいいいい！！１！！１！！！！
Open関数を実行したとたんRTSが立ちっぱなしになってもとに
戻らなくなってしまいました(COMポート閉じるまでこのまま)
お前なんなんだYO!
これはいけない。
ということでネットの海にダイブしていろいろ調査していると
ねむいさんと全く同じ状況に陥っている方がいました。
西村備山様の"滴了庵日録"の下記ブログ記事にはねむいさんと同じように
文字列を送り終わる前にRTSが変化しているのがわかります。
・FTDIのUSBシリアルの不具合？
また、さらに調査されていてHalf-DuplexでRS485をやりたい人は
TXDEN信号を使えばいいとのことです。
・PCのCOMポートをRS485に接続する
なぜRTSが適切なタイミングで変化してくれないのか、USBの規格や
仕様を考えたらすぐ分かる話なのですが物理COMポートはuSec単位で
反応できる一方、USBでは最速でも1mSec(USBフルスピードで)の
"フレーム単位"ごとにしか状態を変えられないことにあります。
20240829追:
HuMANDATA様がFTDIのRTSの制御線の遅延を検証されております！
必見です！！！！
20240829追:
また、西村様の上記記事の最後にFTDIのドライバでRTSがうまく
変化してくれないと言及されておりますが我らがProlificに
至ってはおそらくOpenFile(COMポート開いた)のタイミングで
RTSがいきなりビンッビンにおっ立ってしまい、もう治まり
そうにありません！！1！！もう許ちて！！！！
…すみません下ネタに近いこと言ってしまいましたが西村様のブログ記事に
倣い、FTDI系では方向制御にTXDENを使用することにしました。
うーむ完璧！USBシリアル変換でRS485でHalf-Duplexな通信
したい人はFTDIならTXDENを使えば良いですね。なんだかんだ
言ってFTDIが一番安定して使いやすいですし。
ちなみに秋月で販売しているCH340Eシリアル変換もTXDENに相当する
制御用ポートがあります。
秋月電子のデータシートより抜粋。
CH340EにはTNOWという端子がありこれがTXDENに相当します。
こいつを引っ張り出してあげましょう。モジュール上にはちょうどR4が
TNOWに付いてて半田もしやすいですね。
うーむこれも完璧☆
今を時めくUSBType-Cコネクタで何より安いのでこれは使い勝手良いかも！？
え、肝心のProlificはどこ行ったって？
ありゃだめですよぅ…(もはや測定する気力がない)。
20231103追：
HumanData様のサイトにRTCをトグルした際の遅延を測定した
データがあります。非常に参考になりました。
やはり2~3mSecの遅延があるようですね…
https://www.hdl.co.jp/USB/jkn016/
https://www.hdl.co.jp/USB-001/usb001-t4.html
●CP2102のぱちもん
前々回DS18B20のぱちもんを紹介しましたが中華製ぱちもん半導体の
勢いはとどまることを知らない。過去にFTDIの偽物が出回ってそれ
つぶすドライバが配布されて大混乱になりましたが、駆け込み寺で
使用されたSiliconLabs製のCP2102にもぱちもんが蔓延していた
ようです。
2017年にアメリカのMAKER系イベントで配布された名札代わりの
ボードの中に使用されていたUSBシリアル変換IC(CP2102)に偽物が
混ざっており動作せず人海戦術で対応に当たったという事象が
ありました。
なおこのぱちもんCP2102はUSB-TTL(3.3V出力付き)Breakoutボード
としてAmazonやebay,Aliexpressでも蔓延しており、見分け方が
提示されておりました。
さらに調べるとロットNo.と思われる部分に"DCL00X"と刻印されてる
奴はぱちもんのようですね。
さらにその基板はReset端子がVbus(+5V)直結になっているため、
Reset端子から電流が流れ込み+3.3Vラインが+4Vとかになってると
思われます。一応全端子5Vトレラントのようですがデータシートの
説明にはVDD(内部3.3Vレギュレータ)に4.7kohmでプルアップせよ
と明記されてますね。
抵抗じゃなくてヒューズがついてるのはOKとかそうではなくこの
パチモンCP2102使ったぱちもんモジュールを使うのを避けたほうが
いいですね…
ところで私の持ってるCP2102は大丈夫なのか！？調べてみました。
DOIT-AM製のESP32-DevKit-Cです。
DCL00Xじゃなくてとりあえず安心…
ESPRESSIF製のESP32-DevKit-C-VE
CP2102Nでした。多分大丈夫でしょう。
ESP32-DevKit-C-VE
ESP32-S3-DevkitC-1
こちらもCP2102Nでした。
今現在CP2102が実装された基板はESP32系だけでした。DOIT-AM製の
2016年末くらいの奴は怪しいかなと思ってたのですが回路図見たら
ちゃんとデータシートの言いつけを守っておりました…ｻｽｶﾞﾀﾞｧ…
因みにDOIT-AM製初期のDEVKIT-Cと秋月で購入したESP32-WROVER-E
を使用したESP32-DevKit-C-VEにはADP3338に交換済みです…！！
一方最新のESP32-S3-DevkitC-1に使用されているLDO、SGM2212は
ADP3338には及びませんがVdrop最悪値が0.6Vなのでまぁ使える
レベルにあると思います。
●UGREEN製のUSBシリアル変換を改造してみた
最初のRTSの件で使用したUGREEN製のですがRS485変換には使い物に
ならなかったのでとりあえず分解してみました
結構な化粧箱に入っておりました。921600bps対応とか抜かして
ますがもちろんそんなボーレートで通信できませんでした。
とりあえず殻むきして中身を出してみます。
よくあるDsub9Pinのコネクタを利用した基板直付けタイプですが…
なんかずれてて隣のパタンとショートしそうになってました！！
Dsub9pinコネクタを外してみました。金メッキとか抜かしてました
が外から見える部分だけ金メッキでした…びんぼっちゃまくんかな？
Prorific製ICはPL2303TAが使用されていますがこのチップ、すでに
ぱちもん対策で廃版になっておりPL2303Gが最新です。
ねむいさんPL2303Gが使用されてると抜かしてたので買ったのですが
まぁチャイナリスクってやつです(12年ぶり2回目)
信号レベル変換ICはZT213LEEAなるものが使用されています。
MAX212系のRS232Cレベル信号変換のICの中華版でしょうか。
データシートを見るとMAX250kbps...
ねむいさん921600bps対応って抜かしてたので買っ(ry
とりあえず先ずは使い勝手を良くしちゃいましょう。
これからシリアル番号をつけて同じPCのどこのUSBポートに
挿してもCOMポートが固定されるように改造します。
PL2303TAのデータシートは外付けEEPROMは24C02を要求してますので
これをつけてやります。
ついでに空いていたD1に青色LEDつけちゃいます。
さらにどっかから拾ってきたEEPROMWriterでシリアル番号の書き換えに
成功です！やったぜ。
基板を覆っていたモールドは取り出し時に破壊しちゃいましたので
コネクタを追加して元のケーブルも活用することにしました。
ていうかケーブルだけは作りが無駄にしっかりしてますね…
まぁ仕事で使うのって9600bpsが関の山だから921600bps出なくても
良いっていえば良いんですけどね…ぶつぶつぶつ・・・・
そんなわけでUSBシリアル変換のことばかりだらだら紹介してしまい
ましたがUSBシリアルについてはこれだけは言わせてもらいたいです！
１．FTDI製はやっぱり鉄板
->何だかんだで一番安定してます。
迷ったら真っ先にこれを使いましょう!もちろん本物をですよ！
２．中華製ぱちもんには気をつけろ！
->AmazonやAliexpress,ebayでは偽物に気を付けてください。
安物買いの銭失いとならないようにしましょう。
３．あえて中華製使いたいのならお覚悟を
->Prolificとかはぱちもん対策でばんばんモデルチェンジ
してますが正規品でもちょっと道から外れた使い方したら
思ったように動かないとかざらだったりCH340系もかなり
癖があるので心してかかるように、また他の方の使用記を
しっかり読み込んだ上で挑みましょう！
STM32 Primer2を14年間使い続けた結果
結論から言いますと現役バリッバリで大活躍中です！！
私のSTM32プロジェクトの中で唯一かつ最も成功している作例です！
STM32 Primer2は2009年くらいに発売されたSTM32F103VET6の評価
ボードでした。NUCLEOやDiscoveryがなかった当時は画期的なプロト
タイピングボードだったわけです。
ただ電源の設計に致命的な問題があり、ねむいさんは14年前に
電源の強化を行っております。その後14年経過しましたがねむいさん
改造版電源回路には一切問題はなく-10度〜+40度の温度環境下かつ
すさまじい衝撃が常にかかり続けるトレランでも超ド安定動作で
稼働し続けております。
さらに、生セルだったリチウム電池も市販の1000mAhの保護IC付
リポバッテリーにしてさらにハーネスもつけて脱着容易なように
改造しております。
現在は拙作のSTM32Primer2 GNSS Tr@cker専用ハードウエア構成と
なっており、現在はCDTOPとなったGTOP製のGms-G9を使用し、GNSS
ロガーとして機能させております。
●令和のファームウエア大改修
2023年に入って上記GNSSTrackerのファームウエア大改修を行い
ました。細かいバグとか致命的なバグとかいろいろです。
まずC++の予約語扱いになっている__(ダブルアンダースコア)の
インクルードガードの全廃とかウオッチドッグタイマの計算が
オーバーフローしてたとか何よりSTM32F103VETなのになんでか
512Kbyteじゃなくて1MByteでリンカスクリプト組んでたとか
肝心のUSB-MSCとかUSB-CDCのゼロパケットの処理なかったり(!!!)
USB-MSCの時にUSBポートに刺した瞬間に突然デッドロックして
なんでそうなるかわからなくてロジアナで調べてみるとUSBの
コンフィギュレーションの時にEP-INでおだんまりになっている
ことが分かったけど対処がわからずms単位のディレイ突っ込んだら
安定してデッドロックしなくなったけどなんでそうなったか
分らず助けてtsuneoさん！！！！１
…はぁはぁ…STM32F1でこれ以上なにかいじる気力ないので
もう無理ッス・・・・
20230505追加：
ちなみにUSB-MSCの転送速度は以下のようになります。
Read :0.56MByte/Sec(MAX値)
Write :0.20MByte/Sec(MAX値)
なんとWrite(EP-IN)をタブルバッファ化してるのにこの体たらく…
まぁNMEAログはトレラン60kmコース13時間しばきでも7MBもないので
読み出しは直線で0.55MByte/Secあるから許せる範囲内でしょう…
いつも思いますが10数時間フル稼働してもファイルシステムが壊れない
Cha'N師のFatFsのロバスト性の高さにはいつも助けられてます…！
ｻｽｶﾞﾀﾞｧ…
20230505追加終わり：
●今回のエントリここからが本番だ
正直前途の技術的(?)解説とかもうどうでもいいんです！！！！
話は変わりますがねむいさんは現在中部北陸自然歩道と呼ばれる
北陸地域の自然歩道を集中的に攻略しております!
なぜかと言うと北陸新幹線が来春に金沢-敦賀まで開通しその区間
の北陸本線ははぴラインふくいなる頭ハッピーセットみたいな名前の
3セクになってしまいその区間のサンダーバードがなくなってしまう
からです。
サンダーバードが敦賀どまりになる前に敦賀駅から30年前家族旅行で
訪れた金沢駅(正確に言うと兼六園)まで己の足で進み、そこから
どや顔でサンダーバードのグリーン車で京都に帰還するという所業を
達成するのが当面の目的となっております！！！
ちなみに30年前の旅行では特急雷鳥だった記憶なのでサンダーバード
の時点で手遅れだろという意見もありますが在来線特急なのは同じ
なのでノーカンで…
というわけでここから先はSTM32Primer2を使たGNSSロガーと一緒に
北陸攻略をしていった記録をだいぢぇすとでご紹介します…
2022.10.22 敦賀〜今庄
すべての出発点の敦賀駅。
ねむいさんは北陸新幹線開通までに金沢に間に合うのか！？
いきなりの洗礼。無意味な廃墟区間400mの上り返しと総延長40km越えの
きつすぎる行程…
しかし一本義っていう良酒に巡り合えた！
2022.10.29 今庄〜武生
この時はめっちゃ体調悪く、まだ秋の1デイパスで鈍行オンリーのつもり
でしたがいきなりサンダーバードをショートカットしてしまいました
やっぱ特急はらくちん☆
そして体調不良なのでこういうところほんとつらい。
武生駅はさすがに開けていてお土産もたくさん買って帰還。
2022.12.03 王子保〜漆の里河田
もうこのあたりからサンダーバードの移動が当たり前に…資金が…
ちなみに今庄〜武生の途中の王子保からなぜかルートが分岐し、
きつい山岳ルートときつい海沿いルートに分かれやがります…☠
今回は山岳ルートの最初の部分となりますが…
日野山っていうきつい山越えその…もう雪積もってやがる…マジか
山から下りて10kmくらい走るとまた山に登らされる…もう桜とか
いいから…
訳が分かりませんがルートの途中で大幅に南に寄り道して600m近くの
山に登らされます…日没ぎりっぎりですよぅ！！
鯖江に帰ったころにはもう真っ暗…なんかコンサートがあったらしくて
場にそぐわないメスガキが大量にいました…なおねむいさんも
ぴちぴちのめすがきなんですけぉ！
2023.01.14 漆の里河田〜一乗谷
そろそろ雪の季節…と思ったら雨…雨装備なかったのでぬれねずみに
ところでなんでこのメガネのメスガキは発情してるんですかね…(困惑)
泥だらけになって雲海を見る。
そしてまた無駄に寄り道をする！！こんなんばっかり！！
そして30�卅�ったところでまた山登り…
雪が阻み始めて辛い…
今回でついに福井駅に到着…当面の前線基地になります
2023.02.04 一乗谷〜永平寺口
最強寒波の名に恥じぬ積雪量・・
そもそも電車が雪で走ってなかったのでだいぶ足止めを食らいました
…なんだこの雪の量…400m進むのに1時間かかる
なぜか峠越えは雪がなくてよかった♥
永平寺に寄りました。
観光客もだいぶ戻ってますね…そして拝観中にどんどん下がる体温…
ぶるぶる震えてすっかり危ないやつに
今回もボロボロの私…北陸舐めてました…
2023.02.25 武生〜梅浦(越前海岸のちょっと手前)
永平寺口から北は最強最悪の浄法寺山がとうせんぼしており、
雪解けまで全く出だしできないので海沿いを攻略攻略しました。
うぉ・・海沿いも標高500m超えると結構積雪が…
日陰は林道もたっぷり積雪が…ぐは…
ラッセル地獄
陶芸の里で道に迷って20分くらいロスorz
織田信長ゆかりの神社だそうです。
ここでかき揚げを買って食べましたが寒さで指がうまく動かない。
海まであと200mくらいでバスが来てしまったので今回はここまで！
2023.03.04 梅浦〜波の華温泉
JR西日本はWESTERなるポイントアプリを推しています。
うぉ〜！海沿いだ〜
久しぶりに雪がないルートだ〜！
日本海は豪快ですね〜
越前海岸は水仙の里でも有名です
今回はお気楽に温泉も楽しめました♨
そして福井の名物ヨーロッパ件総本山でソースかつ丼定食を
堪能しました☆
2023.03.11 波の花温泉〜大味
今回も海沿いからスタートですが…
なんと山の中で分岐を道を間違え4時間もロスする羽目にorz
正規のルートも地獄…！！！
ああああああああもう雪やだぁああああ１１１１！！！！！
心が折れたところで花折峠です
越知山がある越知神社です
大味バス停ってところで終了です…
北陸ルートの中で一番やばかった…
ちなみに"おおあじ"ではなくて"おおみ"だそうです
2023.03.18 大味〜三国湊
ｵｲｵｲｵｲまた雨かよぅ…
でも段々晴れてきた…
走っているといつかは超えないといけない最難関、浄法寺山が
三国港駅までやってきました
ゆあぽーと三国で久々にゆったり♨
2023.04.15 永平寺口〜芦原温泉(地獄)
逃れられぬ戦いが始まってしまった…
そしてまた雨…
このルートは２年まえから"通行止め"として管理放棄されています…
雨で滑って風がたたきつけてヤバイ岩場！
浄法寺山最後の難関！！腰までの残雪！！！
浄法寺山は拍子抜けするくらい雪がなかった…
丈競山で強風で転倒するということを味わった
あゝ春の嵐
残り懲役30��
しかし残り7kmですさまじい暴風雨に遭遇する。
最後まで気が抜けない。
何とか芦原温泉郷にたどり着けました…
温泉も堪能♨
2023.04.22 芦原温泉〜大聖寺
芦原温泉郷からスタートです。
三国港から東尋坊に向かいます
東尋坊です。
最高の景色！！風も強い！！
風力発電所のもとを走る。
北潟湖を周回します。
福井県と石川県の県境に！！
ついに福井県を脱出！！
大聖寺までたどり着いてゴール
ようやく石川県に食い込めました。
というわけで駆け足で紹介しましたがねむいさんの北陸攻略は
まだまだ続きます…でもすぐに軍資金が枯渇するので資金繰りを
しっかりしつつ兼六園を目指していこうと思います…
…？お前STM32はどこ行ったって！？
細かいことは気にすんな！です！YO！
STM32C0はぢめました
20240430追:
秋月さんでNUCLEO-STM32C031C6が販売されました！！！
20240430追:
個人ぶろぐでは一番のりかな！？
てわけでリリースしたばかりのSTM32C0シリーズに手を出しました。
立ち位置的にはSTM32G0から機能をシュリンクし、コストを下げて
8/16bitの価格帯に32bitを持ち込む戦略のようです。
評価基板もDiscovery/Nucleo系がすでにリリースされており、
ねむいさんはSTM32C031C6-NUCLEO基板を入手しました。
ところで2021年以降のNucleoはコネクタがUSB-MicroBに変わっているので
ご注意ください…！
そんでもってAVCCが3.3Vに接続されてませんのでご注意ください…
これで30分はまった…orz
基本的な使い方はSTM32G0と全く変わりません。つまりG0からC0への
移植も全く苦ではありませんでした。
ちなみにSTM32CubeC0ライブラリもGithubに登場しております。
STMicro公式からもダウンロードできますが更新が遅く落とすために
登録があって面倒なのでGithubから落としたほうが楽です。
ちなみにuSecディレイに使っている一般タイマですが、HALが微妙に
バージョンアップしていて構造体変数が１個追加されてやがりました。
実はSTM32G0から追加されていたようですが普通に動作してたのでずっと
気づかず、STM32C0では最初うまく動作しなかったところで初めて
気づき30分ほど足止めを喰らいましたorzマニュアルはちゃんと読もう。
というわけでいつものI2Cデバイスをぶら下げて動作させてみます。
こんな感じで何事もなく動作しました☆
AVCCがジャンパされてなかったり変数設定の漏れがあったり
何事もあった気がしたけど気のせいです。
おっとその前に、順番が入れ違いましたがOpenOCDはまだ公式には
STM32C0シリーズのフラッシュ書き込みに対応していませんがgerritに
パッチが上がっています。こいつを適用したOpenOCDをビルドして
さらにSTM32C0用書き込みスクリプトも準備して書き込んでみます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32c0x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.12.0+dev-00075-g79caea874 (2023-02-23-23:36)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
dapdirect_swd
Info : STLINK V2J38M27 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.227154
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x0bc11477
Info : [stm32c0x.cpu] Cortex-M0+ r0p1 processor detected
Info : [stm32c0x.cpu] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32c0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[stm32c0x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08001918 msp: 0x20003000
Info : device idcode = 0x10006453 (STM32C03xx - Rev A : 0x1000)
Info : RDP level 0 (0xAA)
Info : flash size = 32 KiB
Info : flash mode : single-bank
Warn : Adding extra erase range, 0x08006070 .. 0x080067ff
Info : wrote 24688 bytes from file main.elf in 1.217141s (19.808 KiB/s)
Info : verified 24688 bytes in 0.269830s (89.350 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02
なおOpenOCDでは内部的にはG0と同じくフラッシュ書き込みルーチンが
L4シリーズと同じ扱いになっています。
そんなわけでSTM32C0にも対応したOpenOCDのWindowsバイナリは
すでにおきぱにて公開しております！STM32C0を手に入れた人は
バンバン使っていただけるとありがたいです！
ついでにNUCLEO向けのテストプログラムも公開しております。
新規プロジェクトの取っ掛かりにご利用ください！！
いろいろ試す55
もう1か月過ぎそうですがあけましておめでとうございました！！
1月2月は毎年死ぬほど忙しいのでいつも月末ギリギリの投稿です・・・
●OpenOCD 0.12.0ついにリリース！
あれ・・？0.13じゃなかったの…まぁいいや
いちおうRCが取れて正式にOpenOCD0.12.0となりました…
ナイトリービルドが当たり前になっちゃって正式リリースとか関係なしに
動いている今最新のが安定版…みたいな哲学的な状態となってますが今回は
ちょっと注意点があります
libusbのほうの最新のコミットでdeprecatedになった関数があり、
libusbに依存しているライブラリの中でdeprecatedなのを使っている奴が
ビルドエラーになってしまってます。
OpenOCDで引っかかっているのはJ-Link用ライブラリlibjaylinkで今の
ままではビルドが通らないのでおきぱのOpenOCDのバイナリでバインドして
いるのは古いv1.0.26のままとなっております。
libjayの方に更新かかってv1.0.27対応になったらまるっと差し替えます。
OpenOCDのwindowsバイナリはこちらです！
●avrdudeもついにv7.1に！
avrdudeのほうも長らく7.0だったのがようやく7.1となりました…！
相変わらず日付が間際らしいですがバージョン上がった日付のまま
いくらコミット進んでもここの日付は変えないみたいですね…
先月述べた通り表示関連が大幅変更になっていますが見た目は変わって
ないのでいつもと同じ感覚で使用できると思います。
また、libusbはOpenOCDと同じくv1.0.26としております。特に動作に
支障はないので当分1.0.26で行きましょう…
avrdudeのwindowsバイナリはこちらとなります！
●FatFsディレクトリ破壊問題に進展
MMCに書き込んだらFATディレクトリ構造が破壊される問題は
下記の段階まで絞り込めてきました。
・アロケーションユニットサイズが512バイト(1セクタ)以外
のものは書き込んだらディレクトリ構造ごと破壊
もうこれ以外の違いは判りませんがSDフォーマッタでくだんのMMCを
フォーマットするとFAT16で32セクタ(アロケーションユニットサイズが
16kバイト)になってしまうので512バイト以上のファイルをコピー(f_writeを
実行)したら確実に破壊されることがわかりました。
これを回避するためにはFAT32もしくはexFATでアロケーションユニット
サイズを512バイトでフォーマットしてやればどのサイズのファイルを
コピーしても破壊されることはありませんでした。
現行最新のFatFs0.15でも同現象を確認してさらに上記対処法で回避
可能なのですがどうしてそうなるのかというメカニズムは今後も解析を
続け、わかりしだい追ってお伝えします…！
MMCとか今頃使ってる人はいないでしょうけどもし同じ現象にぶち
当たった人はアロケーションユニットサイズを512バイトに固定して
FAT32かexFATでフォーマットしたら回避はできますのでお勧めします？
ついでですが今回の検証でSTM32F4のSPIモード時のMMCv3のクロックの
処理が誤っていたので(MMCv3は最大20MHz以下)修正しておきました。
●↑のついでにFatFs移植例の整備
STM32F4のソースに久々に手を付けたついでにSTM32F7とSTM32H7のFatFs
移植例も整備を行いました。makefileも見直しており、デバッグ時の
スイッチ新設とアセンブラファイルのビルド時のファイル名の小文字化
とかももう少しマトモな表現に直しました。
旧
# Exchange Uppercase into Lowercase
#MPU_MODEL_LOWER = $(shell echo $(MPU_MODEL) | tr A-Z a-z)
lc_jimae = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1))))))))))))))))))))))))))
MPU_MODEL_LOWER = $(call lc_jimae,$(MPU_MODEL))新
# Exchange Uppercase into Lowercase
MPU_MODEL_LOWER = $(shell echo $(strip $(shell echo $(MPU_MODEL) | tr A-Z a-z)))なんで私はこんな苦しみ紛れに屁をこいたようなものを数年も放置して
しまっていたのか…時間を見てほかのSTM32シリーズにも展開しておきます。
現状は下記3つのプロジェクトに対して最新のものを反映しております。
ついでにHALライブラリもgithubの新しいものを反映するようにしました。
・STM32F4
・STM32F7
・STM32H7
●半導体品切れがいくつか復活するも
秋月ですごい高くなってる…特にLDOとかSTM32とか
私の記憶ではLT1963Aは450円くらいで買えたはずですが…円安とインフレ
めっ…ちなみにdigikeyでは20230131現在950円となりやがっておりおいそれと
使うことができない高根の花となってしまいました…
そしてADP3338も
LDOを求めて難民になってしまいましたがいろいろ探して値段性能的に妥協
できそうなやつを見つけてみました(注:SOT-223-3パッケージ、Vin=5V限定)。
まずはSOT223パッケージで真ん中の足がGNDのLT1963A系のやつはMicroChip社の
MIC37100-3.3WSなんかが妥協できそうですね。MLCC使用OKです。
ドロップアウト電圧は0.5V/1AMAXで十分な性能があると思います。
そして値段も300円以下(20230131現在)なので価格的にも優しいです。
お次にSOT223パッケージで1PinがGNDの"LT1117系"のLDOですが、こちらは
DIODESのAP2114HA-3.3TRG1とかですね。こちらもドロップアウト0.75/1AMAX
でドロップアウト0.8V切りは一応クリアでESP32でも持ちこたえられると思います。
もちろんこちらもMLCC使用可です。
まだデータシート上で選定しただけですが特にLT1117系LDOの置き換えを狙う
AP2114HAについては実際に入手してESP32の基板で試してみたいところです！
いろいろ試す54 -2022年反省会-
すみませんやっと時間取れましたが今年残りあと0.2時間くらい…
●OpenOCD-0.12.0-RC3更新
OpenOCDももうすぐ0.13.0になろうとしておりますがRC2->RC3の私的に
注目する更新は、RTOSの自動検知でRTOSがサポートしてないもしくはRTOS
未使用の際にステップ実行したとたんに落ちていたのが修正された…
…のはよいのですが今度はねむいさん特製cfgファイルのほうと衝突
しちゃってTARGETNAME設定の際にとりあえず出つけていた"rtos auto"の
オプションはcfgファイルから削除するようにしました。
ねむいさんRTOSほとんど使ってませんし唯一(仕事で)使ってるMbedOSは
OpenOCDのスレッド検知非対応でrtos autoの設定は実質無意味になっちゃい
ましたからはずしてしまいました。
またつぶしが効くような修正や逆に私がRTOSサポートに本腰入れるように
なったらこの辺りもう一度見直そうと思います…
というわけで今年最後の更新かつ2022年末最新のOpenOCDバイナリはこちらと
なりますのでどしどしつかいたおしてくださいっ！
さりげなくSTM32G4とSTM32L4のフラッシュ書き込みに対応しております！
●AVRDUDEが相わからず更新しまくり
なんでこんな恐ろしいスピードで更新しまくっているのか…！？
息を吹き返していま最もホットなavrdudeもビシバシ充てられるコミット
にしがみついて追従しております。
![](https://dl.dropboxusercontent.com/s/j2mvf4xfhnk33qe/20221231_002.png"")
ところでいつまでバージョン表記はv7.0-20220508のままなんですかね…
中身めちゃくちゃ変わってるんですけぉ…
まぁそれは置いといてこちらは31日付でビルドしなおしております。
こちらもびしばしつかいたおしてくださいっ！
●Android狂騒曲
20230123追：内容が酷過ぎたので少しまともに修正
もう作業進める時間が欲しくてこのブログ書いてる暇が全くないのですが
仕事で必要になりAndroidのタブレットを自分でも購入したことからすべては
はぢまってしまいました。Android上でPythonを走らせてさらにGUIを動かす
という作戦を現在敢行しております。
ガチドザのねむいさんにははぢめてのこと過ぎてあまりにもハードルが
高すぎましたが下記の手順でPythonでGUIを動かすところまで行けてます。
1.Termuxインストール
2.Termuxのエミュレータ端末からPython3インストール
3.同じくpython-tkinterインストール
4.pipでPyserialインストール
5.pipでPySimpleGUIインストール
6.PySimpleGUIのためのx-window導入
7.VNCViewerインストール
上記の長い手順を踏んだうえでser2net化したラズパイZeroとUSB-OTGで
STM32G431K-Nucleoを接続し(STLinkはUSBシリアル変換として動作する)、
さらにwifi経由でラズパイZeroとAndroid間であたかも通常のシリアル
通信のようにデータをやり取りできるところまでできました！！！
今回の例はDHT系の温湿度モジュールAM2322Bの温湿度データを取得して
Termux上のPythonGUI上に温湿度データを取得表示しているところです。
XFCEのデスクトップ画面は殺風景すぎるのでﾃﾞb東條希さんが横たわってる
壁紙で多少の癒し効果を与えております。
ところでこんな回りくどいことやらずに素直にkotlinで直接TCPで通信する
Androidアプリ作れやだって！？
あのね！ねむいさんがそんな正攻法するわけないでしょ！
この狂騒曲はまだ続いておりますが落ち着いたら改めてやったことの
整理ついでに詳細を紹介する予定です。
●Transcend製の3D-TLCの産業用microSDカードTS256GUSD460Tを買った
というわけでTranscendの産業用microsd460Tが市場に出回ってしまったので
年末のくそ忙しい今買って試しました！
まずはWin10でベンチ。直線もチマチマも十分の実力ですね〜
例のあれでSMARTを取得してみました。しっかり読み取れますね！
お次はいつもので読んで見ます。
FatFs module test terminal for STM32H747XIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Dec 5 2022
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 21495 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 262144
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 32768
Number of clusters = 954112
Volume start (lba) = 65536
FAT start (lba) = 98304
DIR start (lba,clustor) = 4
Data start (lba) = 131072
Volume name is TS256G460T
Volume S/N is 9C33-6BBD
...
1 files, 132949600 bytes.
244252672 folders.
244120832 KiB total disk space.
4 KiB available.
>ds 0
rc=0
Drive size: 488636416 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 DB 79 00 07 47 FF 7F 80 0A 40 00 73 @..2.y..G....@.s
CID:
00000000 74 4A 60 55 53 44 55 31 20 80 36 D4 80 01 6A 73 tJ`USDU1 .6...js
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x8036D480
DateCode.Month :10
DateCode.Year :2022
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E ..............9.
00000010 00 08 00 00 00 02 FC 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 87 00 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :2
SD Security :4
SD Bus Width :5
SD_Spec V6.xx!
Detected as SDXC Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class2, A2 Card.
A2 CommandQueue Depth 32 Supported
A2 Cache Supported.
>
A2クラスはもはや当たり前となりましたね〜
最もA2に対応したSDホストでないと真価は出ませんが…
そして産業用microSDもだいぶそろってきましたのでここらでラズパイ
向けの価格性能比が最も優れたもの比較でもやりましょう…！
と言いたいところですがもう時間がないので来年に…
●毎年恒例ねむいさんQ&A
Q:ねむいさん…Codelite使ったARMデバッグ手順のﾎｳﾊ…
A:あああああああああああああああああ１！１！！１１！
今最新のGCC12でもLPC2388(ARM7TDMI)のデバッグできまくるの確かめた
ところまできやがってます！！！！！もうちょっとまって！１！！！
☝GCC12でひりだしたelfはinsightで読めないので苦しみ紛れに屁こいた
みたいな釈明でその場をしのがせていただきます…
Q:時間ない割には山にはいくんだ？
A:それは別腹です
Q:それとDropBOXの過去の消えた画像は？毎年言ってますが…
A:…
…
来年から本気出す！！
それではよいお年を〜
いろいろ試す53
副業(本業は二次裏メイド)が激務になったのと秋の登山ラリーが始まったので
まったく時間が取れてませんが何とか進めていきたいと思います…
●ようやくSWDマルチドロップも使い物に･･･！
-OpenOCD-0.12.0-RC2更新-
長かった…ラズパイピコが登場してから長い戦いだったがようやく本家にも
安定した状態で取り込まれたようですね…感無量です。
↓以下RaspiPicoに書き込んだところのログ
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash_bin main.bin 0x10000000"
Open On-Chip Debugger 0.12.0-rc2+dev-00001-g12ce17094 (2022-10-30-22:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Warn : Transport "swd" was already selected
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Info : starting gdb server for rp2040.core1 on 3334
Info : Listening on port 3334 for gdb connections
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
Info : Padding image section 0 at 0x1001fe80 with 128 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x1001ff00 .. 0x1001ffff
Info : wrote 130816 bytes from file main.bin in 4.495757s (28.416 KiB/s)
Info : verified 130688 bytes in 0.206712s (617.405 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05コアがちゃんと2つ見えているのがわかりますね〜
また、注目すべき点はコアの数だけgdbサーバのポートも増加している点です
デバッグ時はgdbも一個ずつ起動してつなげていきます
openocdも0.12.0になってARM以外のかなりのCPUコアもサポートしています。
STM8はすでに書き込みデバッグに成功していますが新規にサポートされた
RISCVのGD32V系、また本家にサポートが取り込まれたESP32などはまだ全くの
手付かずなのでこれから挑戦していきたいと思います！
というところでねむいさん特製ビルドのOpenOCDはこちらになりますので
どしどしお使いください…！
●で、CodeLiteとGDBを使ったデバッグはどうなったの？
…正直まだ検証が進んでません…
10年同じ事やってたのでtarget extended-remoteってなんだよってとこから
再開ですしSTM32の検証がやっと終わってほかのcortex-M、あとARM7TDMIも
見ていこうと思ってますがすべてのCPUで安定して動かせられるパタンが中々
見つからず苦戦しています。
・今できてること
→ステップ実行(ステップイン/ステップアウト)
→ブレークポイント
→変数読み取り
・InsightではできたがCodeLiteでできなくなったこと
→IOViewでペリフェラルを直感的にたたけなくなった
(gdbのprintコマンドでせこせこ変えるしかない)
→main関数内の最上位でステップアウトをうっかりやらかすと死ぬ
→ブレークポイントを設定しないでrunさせたら死ぬ
→調子おかしくなったと感じてstopしてもgdbにコマンドがなぜか通らず死ぬ
→とにかく機嫌損ねたら死ぬ
死んだらこちらも能動的に殺しにかかってtaskkillコマンドでOpenOCDごと
強制終了してつなぎなおしてます。Insight時代からやってましたがよく
わからなくなったら全部終了で再開するのが最適だと感じてます。
画像はNuvotonのnano130のデバッグ終了時の画面です…いささか強引ですが
これが一番楽…とこんな感じでLPC系のマイコンとかも確認を進めていきます。
●avrdudeがものすごく中身変わっていた
avrdudeがすさまじい勢いで修正がかかりまくりどんどん進化してます
当然途中で大変更が発生することもあり、これで深刻な影響を受けるのは
たいていビルドする人間です…orzビルドが通らなくなったorz
今回readline周りが大幅変更でまともにビルド通らず動かずで難儀しましたが
何とか安定して動かすことができました…細かいことは省きますがreadlineが
dllとして追加になりました。もちろん自前ビルドです。
以下avr128da48に書き込んだ時のログ
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi -U flash:w:main.bin
avrdude: Version 7.0-20220508
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is C:¥Devz¥AVR¥avrdude¥avrdude.conf
avrdude: input file main.bin auto detected as raw binary
Using Port : usb
Using Programmer : pkobn_updi
avrdude: found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : AVR128DA48
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : Curiosity nano (nEDBG) in UPDI mode
ICE HW version : 0
ICE FW version : 1.21 (rel. 37)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude: partial Family_ID returned: " "
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9708 (probably avr128da48)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
To disable this feature, specify the -D option.
erasing chip
avrdude: reading input file main.bin for flash
with 3392 bytes in 1 section within [0, 0xd3f]
using 7 pages and 192 pad bytes
avrdude: writing 3392 bytes flash ...
Writing | ################################################## | 100% 1.09s
avrdude: 3392 bytes of flash written
avrdude: verifying flash memory against main.bin
Reading | ################################################## | 100% 0.60s
avrdude: 3392 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:02
正直大変更前と見た目は全く変わらないので見栄えがしませんがいろんな人の努力で
どんどん機能がパワーアップしていくわけですね…
avrdudeの10月末最新のバイナリもアップロードしました。
こちらもどんどん使ってくださいませ〜！
XMEGAを使ってみる6 -どうしても外付けSRAMつけたかったので-
●XMEGAよ、やはりお前を救いたい
今から約10年前、ねむいさんはXMEGAをいじっておりましたがFatFsを実装し、
SPIのDMA化で力尽きました。ほんとは256kByteくらいのSRAMを外付けしたり
してやりたかったのですが残念ながら当時購入したATXMEGA128A1ではチップ
単体ではEBIを4PORTSRAMモードで動作させてもアドレスバスに当たる一部の
ピンが外部に出ておらず、SRAMを動作せしめることができませんでした。
(アドレスが1つだけでよいTFT-LCDとかならなんの問題もない)
その後USB機能付きのATXMEGA128A1Uが登場し、アドレスバスを別のポートに
割り当てできるようになっているとのことで入手せんと試み失敗したのが前回です。
この半導体不足で何とか手に入れられないものかと思案した結果、部品が
だめなら製品を買えばよい！
と至って久々にAliexpressでお買い物をしました。
MCUZONE製のATXMEGA128A1Uボード。
USBブートローダはちゃんと動いたので本物でした!
慎重にチップをはがして載せ替えてみました。
ちなみにATXMEGA128A1のドアップ写真を。
オリジナルATXMEGA128A1
謎の縦じまがあるぱちもん。
ATXMEGA128A1UではなくATXMEGA128A1をリマークしたもの。
本物のATXMEGA128A1U！
●外付けSRAM
今回使用する外付けのSRAMは8bitバス,2Mbit(256kByte)の
CY7C1010DV33-10ZSXIです。
10年以上前にデジキでかって塩漬けにして以来の活躍です。製造メーカの
CypressはすでにInfineonに食べられてしまっていますね。
SRAMも付けたXMEGA基板の表裏はこんな感じです…
二度とバスの配線とかやりませんよもう！
●回路とコード
すみません回路図めんどくさくて10年前から書いてませんが割り振り表はあるので
まねされる方はそれを参考にしてください。
TFT-LCD駆動用にCS0をつかってしまっているのでSRAMはCS1とします。
外付けSRAM用4Port-EBIの設定です。実行する関数はmain関数より早く実行した
ほうが良いので".init5"セクションに配置します。
EBIの設定のほかにheap領域は外部RAMで行えるようにheapの初期設定も行います。
__malloc_heap_start__malloc_heap_endにheap領域を示すアドレスを代入します。
__malloc_heap_endってなんで固定値0xFFFFなのかについては最後に解説します
また、上記のコードで書いてあった変数"__extram_end"はリンカスクリプト内で
定義します。コード内で値の設定を行うときは&を忘れずに。
以上で外付けSRAMを使う準備ができました。
●動いた！…しかし
載せ替えたXEGAにプログラムを書き込みFatfsの動作を確認です。
チップリビジョンはATXMEGAA1Uを示す'L'になってますね。
mallocで領域確保したりちゃんとできてますね★
特筆する点はFatFsの転送スピードです！
内蔵RAMは8kByteしかないので転送用のバッファも少ししか取れずDMAの
恩恵に預かれなかったのですが、外付けで32kByteとってやると断然違います！
これだけでもわざわざATXMEGA128A1Uを手に入れた甲斐がありました！
しかし…
●立ちはだかる16bitの壁
さて、上でさらっと述べましたが何も考えないで内蔵RAMのように気軽に使用
できるのはメモリのアドレスが0xFFFFまでです。つまり最大でも64kByteまで
しかだめです。今回の作例ではメモリアドレス0x005000から開始しているので
0xFFFF-0x5000=0xAFFFで、10進数に治すと45055Byte分しか楽に使えません。
そこから先の世界に踏み出そうとすると10年以上前に頭を抱えた24bitアドレス問題に
直面することとなります。私の作例では一応24bitアドレスアクセスルーチンも
テストの一部として入れております。DMAに関しては最初っから24bit分レジスタが
用意されているので心配はありません。
というわけでがんむばって256kByteのSRAMくっつけてたのがつけてから64KByte分
くらいしか得しないことを気づいてしまいましたが10年来心に抱え続けていたものに
決着をつけることができました。
世間はUPDIなAVR-DBシリーズに移行している中で盛大な寄り道をして
しまいましたが今回頭を唸らせた経験はきっと役に立つでしょう〜♨
(やばい思想にはまっている目で)。
今回の成果を反映したものをおきぱにおいておきます。
忘れたころにXMEGA触る人に少しくらい役に立つと期待しております。
いろいろ試す51
今回は8bitマイコン中心のネタになります。
●AVRDUDEの整備
新世代のupdiに対応したavrdudeはgithubに戦場を移してかつてとは比べ物に
ならない速度でビシバシ修正が入りまくっております。
私もそれに対応すべくなるべく最新のコミットを常にpullしてビルドしたバイナリを
OpenOCDと同じく皆様に提供しております。
前回の記事の通り、USBシリアル変換でUPDIがお手軽にできてしまったので
avrdudeの需要がかなり増加しておりavrdude目当てでぶろぐに来られる方も
増えておりうれしい限りでございます。
宣伝ですがSTM32系のCortex-M系マイコンのねむいさん特製書き込み
スクリプト付きのOpenOCDバイナリも公開しておりますのでこちらもご利用ください☆
●ATXMEGA128A1"U"を使ってみるつもりだったが…
今年の春、思うことあってXMEGAを再び使う気持ちになり、ATXMEGA128A1の
進化系であるATXMEGA128A1"U"を入手して使用してみました…
ATXMEGA128A1"U"はU無しの物にUSB機能やその他修正を加えたものです。
多分USB付きだからUなのでしょうね…
デバイスIDはなんとATXMEGA128A1と同一です…間際らしい…
A1UのリビジョンはHか〜…A1と全く同じじゃん(←まだ気づいてない
しかし、その後いろいろいじって気づいたがねむいさんが本当に使いたかった
4-PortEBIのSRAMが使用できなかった…。
具体的に言うとA1UはEBIがPORTFに割り振られておりA8~A15のアドレスバスが
使用できるはずなのですができない！！！！！
唸ること1週間、AVRFREAKSの記事にATXMEGA128A1Uのチップリビジョンは
'L'であるというコメントが…
そしてもう一回入手したA1UのリビジョンIDを見直すと…
↑A1UはRev:LのはずなのにRev:H
あああAAあああああ！！！これA1UではなくてA1なのでは！？
もう一度チップ表面を見てみる
あれ…私がaliexpressで買ったA1UはA1の奴と見比べるとよく見ると真ん中
あたり削ってるような形跡…
…
リマーク品でしたー！クソァ１！！！１！！！
まぁこんな半導体不足のご時世でデジキもMOUSERもA1Uの在庫0なのにAliexpress
からすんなり買えるはずはないと思ったのですよぅ…
このネタは次回のA1U入手作戦に続きます…
●arm-gccがアップデート
今年の春先にarm-gccがgccバージョン11.2になってアップデートしています
今回からファイルサイズがメタクソにでかくなってるのでダウンロードの際は
十分ご注意下さい。スタティクライブラリを各コアごとにすべて用意して
いるのが原因のようです。ちなみにCortex-M系だけではなくLPC2388等の
ARM7TDMI等もビルド可能です。
●avr-gccもアップデート
avr-gccも12.1.0にアップデートしております。
こちらについては次回予定のATXMEGA128A1Uの記事で合わせて紹介
させてたいだきます。
●STM8Lはぢめてます
ATXMEGA128A1U購入のついでに8pinSTM8LシリーズのSTM8L050J3M3
も試用してます。
こちらもうまいこと使いこなせるようになったら紹介したいと思います。
ATTINY202(とその他)を使ってみる3 -UPDI難民問題解決の件-
●私の中でUPDI難民問題に終止符が！！
新しい世代のAVRシリーズは従来からのISP,JTAG,PDI,TPI,dWireとは
全く別のプログラミング・デバッグインターフェース(UPDI)となって
いるのはご存じの通りかと思います。
ねむいさんもPDI,TPIまでは手持ちのデバッガ・ライタハードウエアで
で何とかしのげていたのですがUPDIに関しては市販の評価基板から線を引き出して
それに対応した特別なavrdudeを使用して茶を濁しておりました。
そしてその後にpyUPDIというCOMポートの通信だけでUPDIの
プログラミングをお手軽にできる代物が世に広まっていき、
嗚呼…これがavrdudeにも実装されたらなぁ…
…とずっと願っておりましたが今年に入ってついに！ついに!
それが実現しました！！
●ハードウエアを用意する
avrdudeはsvnからgitに移行した時から鬼のような勢いでfixが入りまくり
日々成長を広げております。ねむいさんもgitからクローンしたやつから
ビルドして試してみました。なお今回紹介するお手軽COMポートUPDIは
avrdude内ではserialupdiと呼ばれているので以下それに倣います。
使用するCOMポートについてはUSBシリアル変換チップが勿論使用できます。
安物中華チップでもそれなりに動きますが5Vトレラントや高いボーレートが
保証されてるFTDI系のものがやはり安心です。
(注：後述しますがFTDIに関してはデバイスドライバの設定必須)
ねむいさんは☝写真の秋月製のFT23xモジュールを愛用しています。
そしてUPDI実現のための追加ハードウエアはたったこれだけ！
AVR側の電源は別口からとることを想定しております。また、FT234xなら
+5V信号を受けられるので、3.3~5Vの範囲ならば電圧レベル変換などの
考慮も不要です。
こんな感じでユニバーサル基板のきれっぱを使用してコネクタと部品を
実装して脱着可能アダプター形式にしてみました。
●実際に使ってみよう
まずは私も使っているATTINY202を使用しましょう。ちなみに昨年夏位に
pyUPDIが公表されてからUPDIのハードルが一気に下がったせいか秋月で一瞬で
売り切れてしましたが半導体不足の波も超え今では安定して入手可能となって
いますがたくさん買いすぎるなよ！
avrdudeはねむいさん特製ビルドのものを使用してください。最新のコミットのほかに
avrftdiのバグの修正やLUFAのAVRISP2エミュの不具合修正パッチもあてています。
avrdudeに与えるハードウエア名は"serialupdi"、使用するポートは
上記のように"COM"+"ポート番号"とボーレートを指定してください。
とその前に！
FTDI系のチップを使用する際はドライバの設定(デバイスマネージャから
COMポートのプロパティ->詳細設定)でBMオプションの待ち時間を1mSecに
しないと本来のスピードが出ません。
これ何かというとFTDI系は送信バッファがそれぞれのデバイスの上限に
達したらUSB転送開始もしくは上記待ち時間(latency_timerという)の時間が
過ぎたらとりあえずUSB転送する仕様となっており、最小の1mSecにすれば
USBフルスピードの1フレーム間隔(1mSec)でとにかく隙間なく転送される
ことになりCPUパワーは食いますが少量のバイト数の転送の場合に効率が
良くなります。
jtag2updiのサイトに深い記述があるのでこちらも熟読してください。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p attiny202 -P com3 -b230400 -c serialupdi -U flash:w:main.hex
avrdude: Version 6.99-20211218
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is "C:/Devz/AVR/avrdude/avrdude.conf"
Using Port : com3
Using Programmer : serialupdi
Overriding Baud Rate : 230400
avrdude: serial_baud_lookup(): Using non-standard baud rate: 230400 AVR Part : ATtiny202
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 61 61 0 0 0 0x00 0x00
sernum 0 0 0 0 no 10 1 0 0 0 0x00 0x00
osccal16 0 0 0 0 no 2 1 0 0 0 0x00 0x00
osccal20 0 0 0 0 no 2 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
osc16err 0 0 0 0 no 2 1 0 0 0 0x00 0x00
osc20err 0 0 0 0 no 2 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 10 0 0 0 0x00 0x00
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 append 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootend 0 0 0 0 no 1 1 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 1 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
flash 0 0 0 0 no 2048 64 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 64 32 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: UPDI link initialization OK
avrdude: NVM type 0: 16-bit, page oriented write
avrdude: Entering NVM programming mode
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% -0.00s
avrdude: Device signature = 0x1e9123 (probably t202)
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 (1592 bytes):
Writing | ################################################## | 100% 0.36s
avrdude: 1592 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: input file main.hex auto detected as Intel Hex
Reading | ################################################## | 100% 0.14s
avrdude: 1592 bytes of flash verified
avrdude: Leaving NVM programming mode
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:02脱線しましたが書き込みはこんな感じです。
ATTINY202はROM容量が少ないので早いのか遅いのかよくわかりませんが…
ではAVR128DB28で12kByteくらいのバイナリを書き込んで確かめてみた
curiocity nanoのmDBG
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128db28 -P usb -c pkobn_updi -U flash:w:main.hex
avrdude: Version 6.99-20211218
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is "C:/Devz/AVR/avrdude/avrdude.conf"
Using Port : usb
Using Programmer : pkobn_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : AVR128DB28
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : Curiosity nano (nEDBG) in UPDI mode
ICE HW version : 0
ICE FW version : 1.21 (rel. 37)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
PDI/UPDI clock Xmega/megaAVR : 100 kHz
avrdude: Partial Family_ID returned: "AVR "
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% -0.00s
avrdude: Device signature = 0x1e970e (probably avr128db28)
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 (12076 bytes):
Writing | ################################################## | 100% 3.75s
avrdude: 12076 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: input file main.hex auto detected as Intel Hex
Reading | ################################################## | 100% 2.06s
avrdude: 12076 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:07serialupdi
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128db28 -P com3 -b230400 -c serialupdi -U flash:w:main.hex
avrdude: Version 6.99-20211218
Copyright (c) Brian Dean, http://www.bdmicro.com/
Copyright (c) Joerg Wunsch
System wide configuration file is "C:/Devz/AVR/avrdude/avrdude.conf"
Using Port : com3
Using Programmer : serialupdi
Overriding Baud Rate : 230400
avrdude: serial_baud_lookup(): Using non-standard baud rate: 230400 AVR Part : AVR128DB28
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
Programmer Type : serialupdi
Description : SerialUPDI
avrdude: serial_baud_lookup(): Using non-standard baud rate: 230400avrdude: UPDI link initialization OK
avrdude: NVM type 2: 24-bit, word oriented write
avrdude: Entering NVM programming mode
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% -0.00s
avrdude: Device signature = 0x1e970e (probably avr128db28)
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 (12076 bytes):
Writing | ################################################## | 100% 0.85s
avrdude: 12076 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: input file main.hex auto detected as Intel Hex
Reading | ################################################## | 100% 0.78s
avrdude: 12076 bytes of flash verified
avrdude: Leaving NVM programming mode
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:05>curiocity nanoのmDBG
計7秒
>serialupdi
計5秒
あれ…イケてるじゃないですか…☆
しかも純粋な書き込み時間だけ見たら3.75sec対0.85Secで圧勝ですね！
というわけで実践でも結構使えるUSBシリアルとavrdudeを使った
お手軽UPDIはこれから爆発的に流行ってくるとおもいます！
ねむいさんが記事にしたせいでATTINY202の在庫がまた切れて
しまうかもしれないので何度も言いますが一人で買い占めちゃダメだゾ！
☆serialupdi対応のavrdude-windows32bitバイナリはこちら☆
在庫復活記念！！ATTINY202を限界まで使い倒す！
●ATTINY202復ｯ活ｯ！
プーチンが突然けぉって顔真っ赤にしてウクライナに侵攻してから
半導体の納期がさらに悪化する兆しを見せやがっておりますが、その中で
ATTINY202の在庫が秋月電子通商さんに復活しました！！
なんか20円値上がりしてる気がしますがたぶん気のせいでしょう…
そんなこと気にするより在庫が復活するのが超重要事項なのです！！！！
扱いが非常に簡単かつ非常に安価に使いまわせるので様々な
シーンで活躍していくことでしょう！！
●ていうわけでねむいさんも本腰入れて使ってみました
昨年になってATTINY202のポテンシャルに気付いた方々が爆買いに走り
気づいた時にはすっからかんとなっておりました。ねむいさんもちょっと
動かして満足してほっぽっていましたが他の方の使用例に刺激されて
ATTINY202のROM容量限界まで使ってみました！！！
なお,ATTINY202はメモリリソースが非常に少ないです…。
ROM:2048Byte
RAM:128Byte
ねむいさんいつもSTM32H7等の大容量メモリを扱ってたのでパワーゲームに
慣れきってしまったせいか逆に少ないリソースのマイコンは新鮮に感じます。
私のモットーとしては
１．スタックを考慮してRAMはなるべく使用しない。
２．ROMもメモリ容量圧縮しつつギッチギチに使う
で攻めてみます！
●作例1：1-Wire温湿度計
過去にSTM32G0を使用したときのAosong製AM2322Bを今回も採用して
出力をUARTから吐くようなプログラムを作ってみました！
ROM容量は2037Byte....2048バイトまで10バイト弱…これはｷﾞﾘｷﾞﾘ
-fno-split-wide-typesをコメントアウトしてみました…
2バイト削減…もはや数バイトの戦い！
関数突入時のプロローグ/エピローグルーチンをあらかじめ作ってROM容量を
削減する効果がある-mcall-prologuesをあえてコメントアウト！
使用する関数がごく少ない場合は逆にコメントアウトしたほうがROM容量が
減ってお得です☆これで2027バイト…まぁこれでよいでしょう…！
なお、XMEGAとかでこのオプションちゃんと付けてないと確実に容量が
膨れ上がって爆死します☠
動いたところはこんな感じです。
内蔵クロックが20MHzもあるので230400bpsでも余裕です☆
●作例2:2-Wireで定番LCD(IC:HD44780)を動かす
すでにI2Cでキャラクタ液晶動かすネタはほかの人がやってしまっているので
ひねくれ者のねむいさんは11年前の無理やりすぎるやつをやってみました！
SUNLIKE製の安く購入できるものに代表される2行16文字で内臓コントローラ
ICがHD44780互換なキャラクタ液晶モジュールを受動部品を追加してたったの
2線で動かしちゃう実用性皆無の超力技です！中国だもんなア…
↑のリンク先で牛という単語が散見しますが中国では牛を肯定的な意味で使用
されることがあるとのことです。この力業は文字通り強い牛を見るようだ。
ソースコードは上リンクの中国の人のATMega16のものをベースに汎用で幅広く
使えるように一般公開向けに現在整備中です！
間に合わなかったわけじゃないよ！
しかし…
そこに立ちふさがるROM容量の壁！orz
ああっつ!｢作例1：1-Wire温湿度計の計測｣結果をUART出力の代わりに
かっこよく表示して今回の記事を〆たかったのに容量ぜんぜん足らない…！
あと500Byteあれば…
･･･
15分ほど頑張りましたが挫けてしまい文字列表示ルーチンだけ走らせて
敗戦の弁を述べさせていただきます…orz
というわけでSTM32に慣れ切った私の体には負担が強すぎたのはわかりましたが
ATTINY202の(ROM容量の)イッパイ使用できて非常に満足しております…！
今回の記事で紹介した作例のソースコードはまだ公開用に整備中なので
もうしばらくお待ちいただければ幸いです。
20231201追:
ATTINY202の無理やりすぎるプロジェクトを上げました。
ついてこれる人だけついてきてください…！！！
20231201追:
ところでねむいさん今回はUPDIプログラマ使ってなくてなんかUSBシリアル
変換だけで開発してない？ですって！？
それの詳細は次回以降でみっっっちりと解説させていただきますよぅ♥
ATTIY202売り切れしたのってこれ絡みが原因だったかもれませんがこうご期待！
AVR128DAとかDBをもうちょっと使ってみる
●XMEGAの後継！機能満載でエラッタも満載
品種的にはXMEGAの後継となるAVR-Dxシリーズ。数々の新機能がありますが
それは同時に数々のエラッタを仕込むこととなりエラッタシートとチップリビジョンに
注意しておかないとドハマリして目の下にクマつけてダブルピースして
しまいます。
現在、AVR128DAに代表されるAVR-DAシリーズとAVR-DBシリーズが
流通しております。
DAとDBの違いはアナログ入出力がさらに強化されているのと異なる電圧の
I/OそしてDAに存在したエラッタが修正されていることです。
マイクロチップは過去のシリーズで出たエラッタは新しい奴で修正するよという
スタンスなのでしょうか…???これから買う人はDBシリーズ以降にしておけば変な
地雷踏まずに済むと思います。ただし使用前にエラッターシートは必ず目を
通しておいてください。
20240229追:
秋月さんよりAVR128DB28が販売されました！！！！！！
20240229追:
●製造開始直後のAVR32DAに存在した致命的エラッタ
さてAVRはアトメル時代からまず大きめの容量のチップ作ってそのあとシュリンク
していく量産体制の流れになっていますがAVR128DAが世に出て少し経った頃に
製造されたAVR32DAというチップに致命的エなエラッタが存在していました！！！
エラッタの内容は本来は4バイト必要な割り込みベクタが2バイト刻みになっている
というものです。AVR32DAのフラッシュ領域すべてにアクセスするためには割り込み
ベクタで4バイトのjmp命令を使う必要があります。が、ハード的に発生する割り込み
要因は2バイトずつで詰め詰めになってるのでjmp命令ではとんだ先がめちゃくちゃ
になってrjmp命令を使用しなければならず、8kB分しかアクセスできません。
↓以下AVRのジャンプ命令の参考資料
RJMPは16bitオペコードなので2バイト
(フラッシュ8kB以下のデバイスはこちら)
JMPは32bitオぺコードなので4バイト
(フラッシュ8kB以上のでデバイスはこちら)
avr-gccに関しては4バイト区切りの割り込みベクタアドレスを前提に
スタートアップコードがビルドインされておりうんこつきのAVR32DAでは
どう頑張ってもまともに割り込みが使えません！
↑データシートよりAVR32DAの割り込みベクタの解説。
アドレスは2ワード(=4バイト)区切りなのがわかります。
AVRって最初に出た当初は"すっきり16bitオペコード"を売りにしてて伝統的に
ワード(16bit)でプログラムアドレスを表現してきたからシュリンク設計した人が
バイトアドレスと間違っちゃったんじゃないかな…
というわけでこの製造初期に出てしまったAVR32DAは回収され、現在流通している
物については正しい割り込みアドレス間隔になっているそうです。わたしは怖くて
使う気もないですけど！
ちなみに致命的すぎるエラッタゆえにエラッターシートには記載されておらず、
AvrFreaksで指摘があって初めて広く知られるようになったそうです。
●AVR128DAにもやっぱりあかんエラッタ
そして私が持っているAVR128DAもフラシュメモリがらみのエラッタがありますが、
それは下記の条件がすべて重なった時に起こります。
�．侫薀奪轡緡琉茲鬟如璽仁琉茲�0x8000から32kB分をマッピングして読み書きする
��FUSE領域のBOOTCODEに0以外の数値が入っている(=APPCODE領域を有効にする)
��NVMCTRL.CTRLBのBOOTRPをたててブート領域のプロテクションを行う
上記すべてが重なると32kB区切りのどの領域をマッピングしても最初のBOOTCODEの
領域が頭のほうにかぶさってきやがります！！
↑超わかりづらい公式のエラッタシートの解説DA!。
ブート領域を設定しなかったりLPMでフラッシュ領域のデータの読み取りするなら
全く気にする必要はありませんがせっかくデータ領域にフラッシュ領域のデータを
マッピングできるのですからせめて活用はしたいですよね…！
●AVR-Dxを救いたい
というわけでせめて32kB分だけでもPROGMEMしないでSTM32とかと同じように
constな値を置いてみたかったので上記エラッタを踏まないように配慮したうえで
リンカスクリプトをいじりフラッシュ領域のマッピング機能を最大限に活用する
作戦を取りました！
１．通常版の場合
マッピングを使用せず素直にPROGMEMした場合のプランです。
128kByte自由に使えますが64kB以上のPROGMEMの読み出しはfarポインタを
使用する必要があります。
なお、私は使おうとするAVRのフラッシュ容量を見てfar使うか使わないかを使い分け
られるようにしてます。しかしなんでもかんでもfarにするとべらぼうにリソースを
食ってしまいますのでChaN師に倣いfarはなるべく使用しない方が吉です。
２．マッピングあり&フラッシュ容量32kBのマイコンとして使う
妥協案その1。AVR128DAを32kB分しか使わず残り96kBは見なかったことにしたら
32kByte全域にPROGMEMしないでもconstだけでアクセスできるわ♥ﾔｯﾀｰ!
ってあほか！
３．マッピングあり&rodataだけ最終セクタに押し込む。
妥協案その2.リンカスクリプトをいじくり倒してrodataだけ96kB以降に押し込んで
この領域をマッピングする！
これが一番妥協できて無難ではないでしょうか？FONTX2みたいな馬鹿でかい
ファイルおかない限りはリード専用領域32kBは十分すぎると思いますよぅ。
リンカスクリプトのいじる際のミソは__RODATA_PM_OFFSET__にデータ領域へ
マッピングされたアドレス0x8000を指定することとtextの次にrodataが
来るようにすること(重要)
順番間違えたらビルドが通らないです。
こんなわけでAVR−Dxシリーズの売りの一つだったフラッシュ領域のデータ領域への
マッピングも一応使いものになってきましたので少しは救いになったかと思います！
今回のソースコードは↓になります。回路はAVR128DA48-CuriosityNANOに準拠した
つくりとなっておりますが設定を変えてビルドしたらDBシリーズでも使用可能です。
AVR-DAとかDBとか買ったはいいものの持て余してる方はお試しください。
AVR128DA48 CuriosityNANO TestProgram.
●AVR-XMEGA、お前は救えない
上でちょっと触れたfar使う使わないの判定ですがXMEGAにも横展開しました。
対象はChaN氏のAVR版xprintfと私のavr版fontx2ドライバです。
FONTX2ドライバとかサイズでかいからさいっしょっからfar必須でしょ
とお思いかもしれませんがankコードだけなら10kbyteもないものが
あるので少しでもリソース減らすために追加してみました。
なんというか4年ぶりのxmegaの更新をしましたがここまでプログラムの規模が
でかくなるとやはりSTM32とかの32bitマイコンのほうが使いやすいなと感じます。
一方AVR使うならフラッシュ容量32kB以下のものを使っていくのが適材適所かなと
感じてます。進化の袋小路に入りこんだXMEGA。そこから生まれたAVR-Dxは
どこまで正当な進化を続けられるのか？
これからの活躍を見届けたいと思います！
おまけ
超久しぶりにXMEGA触ったからAとAUの違いって何だろうと調べたらUSB機能追加の
ほかにPORTLが存在しなくて不可能だった4Port-EBIが完全に使用できるのが判明！
今さら遅いんだYO!
AVR128DA/DBシリーズとかATMega4809とか使ってみる
●買ったはいいものの肥やしになりそうなのでやるなら今しかねぇ…
昨年末に正統進化系のAVR128DAシリーズを入手しましたがようやくいじる
機会が出来たので紹介します。
AVR128DA48 Curiosity Nanoというキットで購入しました。
値段は2000円ちょっとです。
AVR DA/DBファミリーに位置付けられるこの品種はなんと動作電圧1.8V~5.5Vの
範囲で24MHz駆動を保証しておりUARTとかも待望のボーレート生成用分数割り算器
なんかも装備しておりなにより過去の品種と比べてもはるかに安価であるという
超進化を遂げております。
が、フラッシュメモリアクセス(後述します)とI/Oのトレラントは従来のまま
なのでもうちょっとがむばってほしいですね。
なお今回のブログ記事作成に当たり下記先達のサイトを参考にさせていただきました。
みなぎ様
なんでも独り言様
KemushiComputer様
●最初に立ちはだかるUPDI難民問題
そしてフラッシュの書き込み方式はAVR-0/1系と同じくUPDIというプロトコルに
従って書き込みを行います。これ実態は半二重のUARTなのですがLUFAとか
簡単に対応ができるんじゃないのと思っていたのですがXMEGAのPDIとも勝手が
違うらしく、従来の自作系ライタとは相性が悪くて実装例はあまりなくて
普及が進まない状態となっていると感じております。
でその中でとれる方法は大きく分けて4つ
�ヾ冉阿靴�ATMELICE/PICKITを買ってMicrochipの開発環境から読み書きする
��安価な評価ボード(XPlained/Curiosity)のファームを書き換えてUPDI専用にする
��jtag2updiで専用のavrdudeで書き込む
�ぜ詑屬枠焼鷭�UARTなので仮想COMでせこせこ自作する(pyUPDIとかも一例)
ねむいさんは値段対費用効果が高いと思われる�△諒�法をとりました。ATTINY202の
時にATTINY104XplainedをUPDIプログラマ化してAvrdudeで書き込んでいます。
�い硫樵�COM使う方法でavrdudeが対応するのが最良なのですが
首を長くして待ってます。
みなぎ氏のサイトではそれに近いことにちゃれんぢされているようで
すごく期待してます☆
ぁ、なんかいつの間にか薄い本同人のネタにしますって書き換わってる・・・・
20230927追:
avrdudeがserialUPDIに対応しました！！
avrdudeは現状はAVR128DA/DBなどの128kbフラッシュを持つ品種に対応して
おらず、パッチを充てる必要があります。ちなみにCuriosityNanoにも
対応してくれてすごく助かります♥
avrdudeを使って書いてみたところはこんな感じになります
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128da48 -P usb -c pkobn_updi -U flash:w:main.hex
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"
Using Port : usb
Using Programmer : pkobn_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : AVR128DA48
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : PKOB nano (nEDBG) in UPDI mode
ICE hardware version: 0
ICE firmware version: 1.17 (rel. 514)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
JTAG clock megaAVR/program: 0 kHz
JTAG clock megaAVR/debug: 0 kHz
JTAG clock Xmega: 0 kHz
PDI clock Xmega : 100 kHz
avrdude: Partial Family_ID returned: " "
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9708 (probably avr128da48)
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 (2462 bytes):
Writing | ################################################## | 100% 0.79s
avrdude: 2462 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 2462 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.44s
avrdude: verifying ...
avrdude: 2462 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:02CuriosityNanoに搭載されているnEDBGはpkobn_updiと指定するようですね。
また、Xplainedの時みたいに無理やりファーム書き換えなくてもupdiがそのまま
使用可能なのもうれしいです。これで2000円ちょっとならよい買い物かも！？
●今度はAVR128DB28だ！
さて今度はキット上ではなく別の品種にも書けるか確かめてみました。
AVR128DB28です！！これもかつてのmega8系の上位互換となっていくでしょう。
と思いきやはじめはXplainedから改造したupdiプログラマから書き込み失敗して
焦りました。どうやらCuriosityNanoのファームではないとAVR128DA/DB
シリーズのフラッシュ書き込みに対応していないと考えられます。
CuriosityNanoで書いたところです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p avr128db28 -P usb -c pkobn_updi -U flash:w:main.hex
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"
Using Port : usb
Using Programmer : pkobn_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : AVR128DB28
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : PKOB nano (nEDBG) in UPDI mode
ICE hardware version: 0
ICE firmware version: 1.17 (rel. 514)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
JTAG clock megaAVR/program: 0 kHz
JTAG clock megaAVR/debug: 0 kHz
JTAG clock Xmega: 0 kHz
PDI clock Xmega : 100 kHz
avrdude: Partial Family_ID returned: "AVR "
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e970e (probably avr128db28)
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 (2398 bytes):
Writing | ################################################## | 100% 0.79s
avrdude: 2398 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 2398 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.43s
avrdude: verifying ...
avrdude: 2398 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:02●最後にATMega4809を試す
こちらは3月くらいに秋月さんから販売されだしたmegaAVR-0シリーズの
品種になります。AVRDA/DBと比べると1世代前の品種になります。
こちらもフラッシュ書き込みはUPDIとなっています。
とりあえずCuriosityNanoで書いてみる
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p atmega4809 -P usb -c pkobn_updi -U flash:w:main.hex
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"
Using Port : usb
Using Programmer : pkobn_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : ATmega4809
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 61 61 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 10 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
usersig 0 0 0 0 no 64 64 0 0 0 0x00 0x00
flash 0 0 0 0 no 49152 128 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 256 64 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : PKOB nano (nEDBG) in UPDI mode
ICE hardware version: 0
ICE firmware version: 1.17 (rel. 514)
Serial number : MCHP3280031800001375
Vtarget : 3.31 V
JTAG clock megaAVR/program: 0 kHz
JTAG clock megaAVR/debug: 0 kHz
JTAG clock Xmega: 0 kHz
PDI clock Xmega : 100 kHz
avrdude: Partial Family_ID returned: "mega"
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.07s
avrdude: Device signature = 0x1e9651 (probably m4809)
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 (5344 bytes):
Writing | ################################################## | 100% 2.07s
avrdude: 5344 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 5344 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.02s
avrdude: verifying ...
avrdude: 5344 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:03
最後にファーム入れ替えたXplainedから。えらいにぎやかになりました。
ATmga4809はXplainedでも書けます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
C:/Devz/AVR/avrdude/avrdude -v -p atmega4809 -P usb -c xplainedmini_updi -U flash:w:main.hex
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:¥Devz¥AVR¥avrdude¥avrdude.conf"
Using Port : usb
Using Programmer : xplainedmini_updi
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : ATmega4809
Chip Erase delay : 0 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 0
StabDelay : 0
CmdexeDelay : 0
SyncLoops : 0
ByteDelay : 0
PollIndex : 0
PollValue : 0x00
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 61 61 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 10 0 0 0 0x00 0x00
fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse6 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse7 0 0 0 0 no 1 0 0 0 0 0x00 0x00
fuse8 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00
data 0 0 0 0 no 0 0 0 0 0 0x00 0x00
usersig 0 0 0 0 no 64 64 0 0 0 0x00 0x00
flash 0 0 0 0 no 49152 128 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 256 64 0 0 0 0x00 0x00
Programmer Type : JTAGICE3_UPDI
Description : Atmel AVR XplainedMini in UPDI mode
ICE hardware version: 0
ICE firmware version: 1.13 (rel. 43)
Serial number : ATML2678020200007560
Vtarget : 5.00 V
JTAG clock megaAVR/program: 0 kHz
JTAG clock megaAVR/debug: 0 kHz
JTAG clock Xmega: 0 kHz
PDI clock Xmega : 0 kHz
avrdude: Partial Family_ID returned: "mega"
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.09s
avrdude: Device signature = 0x1e9651 (probably m4809)
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 (5344 bytes):
Writing | ################################################## | 100% 1.72s
avrdude: 5344 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 5344 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.38s
avrdude: verifying ...
avrdude: 5344 bytes of flash verified
avrdude done. Thank you.
> Process Exit Code: 0
> Time Taken: 00:04こんな感じで市販のライタをそのまま流用もしくはファームだけ入れ替え
というアマチュアリズムに反する行為になってしまいましたが2000円
ちょっと出して電圧変換機能付きのUPDIプログラマ買えるのならもうこれで
いいかなと思いまし、た！
●残る問題、フラッシュ領域のアクセスはどうなった？
そういえばMicrochip体制のtinyAVRからフラッシュ領域のアドレスが
データ領域のアドレスに変換され割り振られ、PROGMEMを使わなくても
一般的なC言語のconstのように定義したら自動的にコンパイラが割り当てて
くれるようになってくれるはずですが実際にアセンブルリストと照らし
合わせてみてみましょう。
まずATMega1284p
main.cのグローバルにconst charの文字列リテラルをPROGMEMとか使わず
定義した場合、フラッシュではなくデータ領域のアドレス(0x800000以降)
として配置されます。この状態だとコンパイラがmain関数開始前に
フラッシュメモリからデータ領域のSRAMの該当アドレスに配置するルーチンを
実行しSRAMを大幅に浪費してしまいます。
続いてATMega4809の場合もデータ領域のアドレスに配置されるようになりますが、
このアドレスはLPMなどのフラッシュアドレスアクセス用の命令は必要がなく
普通のSRAMのように読み出しができるため、main関数開始前にフラッシュから
SRAMに読み出すようなルーチンは実行されません。
AVR128DA/DBは御覧の通り従来のAVRと同じになってしまいます。実は
ATmega4809と違って制約があり、データ領域は64KB以内のアドレスしか
参照できないためさらにI/Oの分も差っ引かれて実際には最大
参照できないことからくると考えられます。
まぁこれAVRのアーキテクチャーの宿命なので仕方がないのですけど128kByte分
フルに参照せしめるためには10年前にねむいさんが行っためんどい手法をもってして
やらないといけません！。
※みなぎ氏の調査によるとAVR32DAxxとか32kByteのROM容量の品種では
4809と同じくPROGMEMの考慮が必要なくなるそうです。
2023927追:
AVR-Dxシリーズでいろいろ試してみました！！
20240229追:
秋月さんよりAVR128DB28が販売されました！！！！！！
PCベースUSBオシロスコープ PicoScope 5444D MSOを使う
●誰が豚に真珠や
今からさかのぼること10年前、超円高時代に有利な価格で売られていた
Picotech製のUSBオシロPicoscope3206Aを秋月さんより購入し、自作環境の
測定器として使ってきました。
そして2021年、満を持して機能を強化した上位モデルの購入に踏み切りました！！
そして我が家にやってきたPicoscope5444D MSO!
アナログ帯域は個人では十分な200MHzで4CH使えてサンプリングもMAX1GS/Sec、
且つMSO(ミックスドシグナルオシロ)と呼ばれるちょっとしたロジック
アナライザポートも備えています！１！１１１！！
さらに下位モデル3000シリーズの差別化として5000シリーズではFlexResと
言ってハードウエアでサンプリングビット数を最大16bitまで可変が可能です！！
2011年のころは4CHオシロとか200MHzで1GS/Secとか100万越えの奴しか
まともなのなかったはずですが現在では選択肢も増えて価格も
大幅に下がりねむいさんの資金力でも十分に手が届く価格となって
きたので購入に至った経緯があります。
最初は送料込みの総額が一番安いAmazonで買おうかと思ってたのですが
納期が未定になってしまったためヤマト科学という計器卸売の商社さんから
購入しました。
お値段は送料無料の税込み331100円でした。アマゾンも＋2000円ちょっとしか
変わりませんけどねなんというか消費税だけで3万近くもするってめっちゃ
やばいですねああそうだ10年前はまだ消費税5%時代だったからていうかもう
かれこれ10年もたってるじゃんかぁ
あああああああaAあああァああああぁああああ！！１１！！！１１！
…
ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼しました。なお、Picoscopeは英国製のため、ポンド/米ドルと
米ドル/円の為替レートにより日本円で買える値段が大幅に変わりますので
ご注意ください。
20220416追:
今悪性の円安が加速しまくってて37万円以上になってる！１１！！１！！１！！！！！
黒ちゃんはやく円安何とかしてくだち！！！１１１！！１１！！！
20231112追:
今悪性の円安が加速しまくってて45万円以上になってる！１１！！１！！１！！！！！
植田ちゃんはやく円安何とかしてくだち！！！１１１！！１１！！！
RSコンポーネンツでは55万円以上になってます☠
●とりあえず使ってみようぜ
とはいえ以前の3206Aと操作感覚は変わりません。オシロを操作するための
PCソフトは数万の格安モデルから100万越えの最高性能モデルに至るまで
同一のものが使用できます。
4CH全部使用したところです。
3206Aと比べてCHが4つに増えた以外は違いはありませんね★
なお、ねむいさんが買った4CHモデルは外部電源を接続しないと2CHまでしか
使えません。(MSOポートもMAX2CH分扱いで、計6CH分となる)
●Picoscopeの真骨頂プロトコルアナライザ機能を使う
まぁこれも3206Aで紹介してますが改めて。
Picoscopeのソフトは2012年あたりにロジアナのお株を奪うシリアル信号の
プロトコルアナライザの機能が搭載されています。
まずはI2Cバスでやってみましょう。
画像のシリアルデコードの項目を選びます。
オシロのA(CH1)とB(CH2)をSDA,SCLに割り当てました。
I2C信号のやり取りは拙作のSTM32F030-NucleoのI2C液晶とSTTS751の
温度表示プログラムを実行したところです。
CSVファイルに出力して後から解析も可能です。
STTS751の温度データを取得しているところがよく分かると思います。
このプロトコル解析はロジアナポート(MSOポート)でも当然のように使用可能です。
ていうかこのMSOポートはこういう用途に積極的に使うべきですね。
MSOでトリガかけるときは設定方法にちょっとコツがいります。
いちいち設定するのは忘れがちで骨が折れます。
一度こういう特的目的の信号の測定を設定したらファイル->保存で設定ファイルを
保存しそのファイルをダブルクリックで起動すると再び同じ設定で測定が可能です。
このプロトコルアナライザの機能、実はかなり使えます。最初はUARTとI2C
くらいしかなかったのですが、現在はFlexRayやUSB1.1(FULLSPEEDまで)、
SPIも解析可能となり非常に強力なツールとなりました。ちょっとしたシリアル
信号の解析ならロジアナを引っ張り出す必要もなくなりました。
そんなわけでねむいさんが学生時分の頃はまさに"高値"の花で全く手が
出なかったオシロスコープは現在では実務にもバリバリ使えるレベルで個人
でも手が届くような値段で手に入るようになりました。
据え置き型との対比としては"PCがないと使えない"という最大の弱点が
ありますがもはやPCは一家に数台な時代ですしテクトロの1000万クラスの
据え置きオシロも中身はWindowsOSで動いてるまさに一体型のパソコンオシロ
みたいなもんですので個々の環境や測定対象に合わせて使いやすいものを
選択してくのがよいでしょう！
大緊急事案！！！１！Raspberry Pi Picoはぢめました！！１！！１
●なにっ
超小型linuxPCの代名詞となったRaspberryPiですがNanoに加えてPicoなるものも
ラインナップに加わりました！！
秋月電子通商さんで550円ですでに販売されており、すでに手に入れられた方も
いるかと思います。ねむいさんも早速購入していぢって見ることにしました！！！
基板としてはRaspiNanoよりも一回り小さいサイズとなっております。
MPUはARMのCortex-M0plusのデュアルコア構成、Raspberry財団のロゴが
レーザーマーキングされた特製のものとなっております！
しかもM0+のコアながら100MHz越えの高速クロックで動く代物です！！
※細かいスペックは次回以降に紹介します。
●とりあえず動かしてみる
USB-microコネクタから給電するとフラッシュに何も書いてないときもしくは
BOOLSELボタンを押しながら給電するとマスストレージとして見えます。
binファイルではなくuf2(USB Flashing Format Data)をドラッグアンド
ドロップすることにより内蔵フラッシュに書き込まれるようです。
RaspiPicoの公式ページにはGettingStartとしてこのD&Dで始める方法が紹介
されており動作確認用のuf2ファイルも落とせます。
これでLチカを確認できます。
●プログラムのビルド方法は？
同じくGettingStartedに方法が書いてあります。OS間で共通する項目は
SDKを使いCMAKEとPythonでmakefileを生成してビルドするということです…
…CMAKEってねむいさん嫌いなんですよね…記述がちょっとでも抜けてたら
思った通りに動作しなくて…Raspiなので基本的にLinux系OS下のビルドを前提と
しています。
幸いにもWindows環境下のビルド指南もしております。
もちろんCMakeとPythonとVisualStudioCodeが必要です。が、ねむいさんは
中途半端にMSYSのOpenOCDビルド環境を持っているのでそちらと折半して
ビルドしてみました。
…
(格闘すること2時間後)
あああもうめちゃくちゃだよ
make一発で出来るようにシンプルなライブラリの構成にしてほしかった…！
しかも一度に全部のプロジェクトをビルドしやがるのでものすごく時間がかかります。
※ねむいさん式RaspiPicoビルド環境は次回以降に(またかいな
●ビルドしたやつをどう書き込むのか？
ビルドしたプログラムを書き込むだけなら上記のUF2ファイルをマスストレージ
モードでD&Dで書き込む方法がありますがねむいさんがそんなので済ませるわけは
ありません！！！
Cortex-M0+コアなのでOpenOCDが使えるはずです…がデュアルコアかつSWDオンリー
なので無理か…と思いきやRaspberryPi公式でOpenOCDをRP2040用にFork
しており、こちらはなんとマルチドロップSWDとRP2040のフラッシュ
書き込みドライバの対応済です！！
画像の上部に写ってるｲﾗｽﾂは気にしてはいけない。
RP2040用の書き込みcfgも作成してRaspiPico専用OpenOCD+JTAGKey2を使って
RaspiPicoにelfファイルを書き込みせしめることに成功しました！！！！
ログはこんな感じになります。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd-pi -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2_swd.cfg -f target/rp2040_swd_flash.cfg -c "mt_flash blink.elf"
Open On-Chip Debugger 0.10.0+dev-gf8e14ec97 (2021-02-07-14:35)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
Info : Writing 16384 bytes starting at 0x0
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
そんなわけでとりあえずほんとに基本だけ紹介してみましたが次回以降は
RP2040のMPUスペックやメモリ構成などの深い部分に突っ込んでいこうと思います！
それに先立ってRaspiPico(RP2040)用のOpenOCDバイナリを公開いたします。
ねむいさんのいつものOpenOCDバイナリに書き込み用cfgとともに同梱しておりまので
どしどしご利用ください！！！！
↑RaspiPico専用OpenOCD:openocd-pi.exe
同じく専用cfg:target/rp2040_swd_flash.cfg
今更STM32G0はぢめました
皆様あけましておめでとうございました！！
今年は初詣期間が２か月くらいあるそうなので全然遅くはないですね(手遅れ
さて、先月さらっと紹介したSTM32G0、秋月さんのところで9月に発売されていたのを
12月にようやく手に入れ、そして今ようやく記事にしてみた次第です。
STM32もついに8pinの世界に足を踏み入れてしまいましたがコアのほうもCorte-M0
じゃなくてM0+にパワーアップしています。しかしながらメモリ容量32kb、SRAMも
8kbもあるという小さなボディに大きな力を秘めているわけです！！
メモリ構造も慣れ親しんだSTM32の伝統のアドレス配置で移植も苦ではありません！
このマイコン用のプロジェクトの作成に当たってはSTM32G0-DISCOを参考にさせて
もらっております。
しかしピン数さすがに少なすぎできついですねこれ…どうしたらいいものか…
7,8ピンはSWDで潰れる…そして6ピンはLEDに使用済み…
この小規模なマイコンでもきることはやはり一つ…！I2C！！
PA9がリマップ済みになってるようなので用検討ですね…
ひとまずLチカできるレベルのプロジェクトをF0のプロジェクトをベースに拵えて
見ました…確認用の基板もやっけつ仕事で昔のLPC810基板に乗っけました。
デバッガの接続は定番のSWDです。8PinがSWCLK,7PinがSWDIOあとは電源の配線を
すればつながります。また、購入直後のSTM32G0の接続ではnReset(4Pin)の接続は
特に不要です！(重要)将来的にnResetをGPIO化して使う際には逆に邪魔になって
しまいますので…
OpenOCDはすでにG0シリーズの多くに対応しております。ねむいさんもG0用の
フラッシュ書き込み用のcfgを作成しました。
すでにOpenOCDのバイナリに収録済みです！
まずはVersaloonで書き込みしたところです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32g0x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : VSLLink SWD mode enabled
swd
Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)
Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info : clock speed 500 kHz
Info : SWD DPIDR 0x0bc11477
Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32g0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000
Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)
Info : flash size = 32kbytes
Info : flash mode : single-bank
Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff
Info : wrote 3760 bytes from file main.elf in 0.188402s (19.490 KiB/s)
Info : verified 3756 bytes in 0.029309s (125.148 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01
Win10ではレジスタウインドウ使えませんがInsightのデバッグもすいすい
できちゃいます。
お次はSTLink(STM32-NucleoのSTLink/V2-1)でHLAデバイスとして
書き込んでみます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32g0x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.11.0-rc1+dev-00032-gbd1adcffe (2021-01-23-19:37)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 500 kHz
Info : STLINK V2J33M25 (API v2) VID:PID 0483:3752
Info : Target voltage: 3.272439
Info : stm32g0x.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for stm32g0x.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x08000c9c msp: 0x20002000
Info : device idcode = 0x10016466 (STM32G03/G04xx - Rev Z : 0x1001)
Info : flash size = 32kbytes
Info : flash mode : single-bank
Info : Padding image section 1 at 0x08000eac with 4 bytes (bank write end alignment)
Warn : Adding extra erase range, 0x08000eb0 .. 0x08000fff
Info : wrote 3760 bytes from file main.elf in 0.156605s (23.447 KiB/s)
Info : verified 3756 bytes in 0.031977s (114.706 KiB/s)
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01こんな感じでサクッと書くこむことができます。
ということでSTM32も8bitマイコンの牙城に続々と乗り込んできたおかげで
小粒マイコンも立派にSTM32として使えるような局面が出てくると思います。
今回はLEDの点滅だけですが豊富なメモリ資源とCPUスピードを利用してI2C
デバイスの制御にちゃれんぢしてみようと思います！
注：プロジェクトはまだ作成中のためもうしばらくお待ちください。
AVR再びはぢめました(ATTINY104とATTINY202を使ってみる)
●AVRは生きていた！
ねむいさんが東海自然歩道とか熊野古道とかを進軍しているうちに時代は
変わり、同じく8bitマイコンの世界も大きく変わっておりました…
今から三年前、ねむいさんはMicrochipに吸収されたATMELが擁していた
AVRに別れを告げて32bitマイコンの世界にどっぷりつかりこんだつもりでしたが…
AVRはMicrochipの庇護下で命脈を保ち、さらに現代風にリニューアルして
復活をしていた！！
秋月電気通商さんでAVR-0世代のATTINY202が発売されたのを機にねむいさんも
かつて背を向けたAVRに再び向き合うことにしました…！
そのまえに
●まずは旧世代のATTINY104
ATMEL時代の最後の嫡子ATTINY10xシリーズもついでに触ってみることにしました。
同じく秋月さんからATTINY104版のAtmelXplainedの在庫があったので
ATTINY202を買うついでにゲッツしました。
Xplained系は1000円台で純正デバッガmEDBGがついているのでお得です☆
ATTINY10xシリーズは旧世代のAVRシリーズであり、私が過去使用していた
XMEGA以前のAVRシリーズと同様のアーキテクチャーとなっています。
Lチカ程度なら余裕ですｎ…
なんとAVR-GCCがATTINY104に対応していなかった！！！orz
ATMEL STUDIOみたいな出来合いのツール使うのならば全く問題がないのですが
ねむいさんはコマンドラインビルド教なのでこれはきつい。
結局ﾏｶｰの人がやった手順をなぞってavr-gccをATTINY10xに対応させて
ビルドしました。
書き込みはAVRDUDEを使ってXplainedに内蔵されたmEDBG(tpi接続)経由で
かきこみをおこな…i…
tpiで書き込めねぇ！！！！orz
Xplained系のATMEL評価ボード内蔵のmEDBGはAvrdudeではjtag3という
デバイス扱いで繋ぎに行くのですがなんとソースコードレベルで
jtag3のtpiモードに対応してなかったorzもう6年以上たってるのになんで…
ATMELSTUDIOからならちゃんと読み書きできるんですけどね…
atmega1284pなのは気にしないでください。大昔の1284pのプロジェクトから
転用してATTINY104のプロジェクトこしらえたもので…
さて、ねむいさんはAvrdudeでどうしても書き込みしたかった。
Avrdudeのソースコード追ってくと手持ちのライタで書き込みができそう
だったのはLUFAとFTDI系でした。
まずはLUFAのAVRISPmk2化したATUSBKEYでtpi書き込み成功!!
(↑最初リセット繋げてなくて焦った)
お次はftdi、ねむいさんはJTAGKey2を作っているのでそれを使用しました。
TPIの結線はこちらのJTAGKey2紹介記事のリンク先回路図、
SWD接続の部分を参照の事。結線は以下の通り読み替えてください。
TPICLK = SWCLK
TPIDATA = SWDIO
RESET = TMS
リセットはRESETじゃなくてTMSなんですよねAVRだと。
そしてJTAGKey2でも危なげなく書き込み成功。
GUIツールはこれを使わせてもらいました。
なお、Avrdudeにもパッチ当てないとATTINY104で読み書きできないのでご注意を。
ねむいさんのavrdudeのバイナリはもちろん対応済です☆
●お次はATTINY202だ！
ATTINY202はAVR-0と呼ばれる新しい世代のAVRマイコンです。
AVR-0/1シリーズではプログラムメモリの規模は8ビットマイコンの力を最大限に
引き出せる64KByte以下に収まりATXMEGAと同じアーキテクチャとなりました。
そして旧世代AVRの弱点だったプログラムメモリのアクセスの煩雑さはデータ領域の
アドレスに割り当てることによって完全に克服をしました！！！！！
詳しい内容は先達の方々のブログ記事に習いました。ありがとうございます。
・なんでも独り言様
・GHz2000様
avr-gccはATTINY202に当然対応しています。なぜかATTINY104はぶっち
されていますが！！そしてAVR-0シリーズはXMEGAと同じ感覚で組めるので
ATXMEGA128A1のプロジェクトを転用して作ってみました。
また、ATMEL STARTなるATMELの忘れ形見のようなサイトのツールで
周辺やクロックの初期化コードを生成することができます。
クロックを20MHzに上げてGPIOをOn/OFFにするプロジェクトをササっと作って
いよいよ書き込みを行います。新世代のAVRはuPDIというXMEGAのPDIを進化
させた1wireのデバッグ・書き込みインターフェースで書き込みを行うわけですが、
今回は最初に紹介したATTINY104XplainedのmEDBGを使います☆
Xplainedの基板の裏にATTINY202はっつけてみました。
XplainedのmEDBG(ATMEGA32U4)はPE6がuPDIの信号線となっています。
このPE6をATTINY202のRESET(uPDI)に接続します。
別のAVRでも使えるようにXplainedのNCの部分をuPDI信号とします。
そして…
…
まぁ一筋縄でいくわけがなく、ねむいさんが買ったATTINY104-Xplainedはtpi専用の
ファームとなっており、uPDIを使うためにはいったんATMEL STUDIOをインス
トールしてtpiのファームをuPDIのファームに変える必要があります。
具体的にはmedbgupdi.hex&binをmedbgtpi.hex&binにリネームし上書きします。
その状態でatfwというツールでアップデートします。
atfw -a medbg_fw.zip -t medbg -s (ここにXplainedのシリアルナンバを記述する)
ATMEL STUDIOからは見えた！勝った！
そしてAvrdudeでもちゃんと書…
…書けねぇ！orzなんか無限ループしてるorz
これもAvrdudeのバージョンアップでエンバグしてしまったらしく、変更箇所をもとに
戻したら書き込みができるようになりました。めでたしめでたし♥
そんなわけでまだ私が若くぴちぴちだった頃、はぢめてAVRを触れた頃を思い
出しながらAVR-0シリーズも弄っていこうと思います！まだわかくてぴちぴちですが。
ああ最後になりますが宣伝ですがATTINY104とXplained-updiにも対応した
AVRDUDEのバイナリはこちらになります！どしどし使ってください☆
いろいろ試す45
●ねむいさん、Facebookでちゃちなスパムに引っかかる
ッッすんませんでしたぁあああああああああああああああああああ
あああああああああああああああああああああああああ！！１１！！１
既に関係者に謝罪、パスワードも変更、乗っ取られて投げてしまった
スパムも全部削除しました…
加えて次にトイレ行くまで自分自身を腹パンし続ける刑を科しました
(↑サイバラりえぞう師匠風に)
メールやメッセージで教えてくれた人ありがとうございます。
ねむいさんもまだ見捨てられてなかったんやなぁって…(ｽﾋﾞﾋﾞ
●BSCH3V更新
かれこれ15年以上愛用している水魚堂さんのBSCHが更新しておりました。
4年ぶりですね…もう4ねんも…
ｹﾞﾌﾝｹﾞﾌﾌﾝこれからもよろしくお願いします。
●OpenOCDの更新状況について
現在もOpenOCDのx86版バイナリを当ブログで提供し続けておりますがESP32専用版も
バンドルした体制になってから時間も結構経ちました。
頻度は往時と比べてかなり落ちていますがねむいさんのバイナリ更新ポリシーとしては
以下の優先順位で更新を続けております。
1.OpenOCD本家のgitでパッチがマージされた場合
2.libusbが新しいパッチが追加され更新した場合
3.libusbに付随するライブラリ(libftdi/libjaylink)が更新した場合
4.ESP32版OpenOCDのgitにパッチがマージされたとき
ぇーっとですね…最近libusbのパッチがマージされて更新したのですがこのビルドの
"libusb.dll"を使うとなんか変に…
↑変なマイナスの数字出してエラーで止まる…
↑正常動作はこんな感じ
libusbがらみは問題の追及にすごい時間かかるんですよね…
しばしの間OpenOCDは0922版でがまんしてください…
進展があったらここのエントリを更新するつもりです。
20200930追:
libusbのcommitを追っていったら怪しいやつがありました。
さらにlibusbをデバッグビルドしてログを出すようにして追っかけてみました。
さっきのコミットが当たったところ、具体的に言うとhandle_event_trriger()で
詰まっているのが分かりました。
この修正箇所だけをひとつ前に戻したパッチを適用してビルドしたものを更新しました。
ねむいさんのところで試した限りでは問題はなかったですがうまく書き込みできない
等がありましたらご連絡お願いします。
20201105追：
直りました。
●マイコン用I2Cライブラリのレストア
先月はラズパイZeroWでI2Cデバイスを動かしてみましたがSTM32F0向けのI2C
ライブラリもS-5851AAAを追加してブラッシュアップしました。
ブラッシュアップに当たりローレベル層のSTM32のハードウエアI2Cの
コーディングが悪かった事が6年越しで判明したのでこちらも修正しましたorz
STM32のI2CってF0/F3リリース以降の品種は取り扱いが結構面倒臭くなってHAL
ライブラリ使っても思ったように動作してくれないことがあるんですよね〜
いつも自分でオシロで波形確認しろと言っておきながらめんどくさがってちゃんと
確認しないからこうなった。次からちゃんとやります。
(※室内温度)
それにしても夏すぎる暑だった…
いろいろ試す43
10万円来た！これで勝つる！！
住民税と自動車税払った！おしまいっ！
●ラズパイ4でもS.M.A.R.T.をゲッツする
すみません坪井さんの記事のぱくりです…
つぼいさんはOSイメージを書き込みmmc-utilsを改造して/dev/mmcblkから
ダイレクトにCMD56を送り込みS.M.A.R.T.(以下SMART)をゲッツされております。
ねむいさんは前回のノウハウを使ってUSBマスストレージ経由でゲッツします。
TranscendさんよりLinuxのコマンドライン版ソフトのソースコードも提供して
いただいておりましたので。
ラズパイOS｢Raspbian｣は標準でGCCコンパイラが収録されており、ねむいさんの
大好きなmake一発でsdsmarttoolをビルドできました。
ちなみにこのツールはUSBマスストレージ経由でscsiコマンドを流し込むので
OSイメージがある/dev/mmcblkは指定してもコマンドが通らずエラーになります
scsiコマンドに組み込まれたCMD56が通るRDF-5が必須となります。
というわけでラズパイからでもTranscendのSMARTを無事取得完了しました。
パース結果がめちゃくちゃですがこれは最新のUSD230Iは過去の産業用SDの物とは
SMARTのデータ構造が違うためです。ひとまずDeviceHealthだけ合わせました。
ここに至るまでwindowsのコマンドラインとの違いやpermissionに引っかかりまくり、
ガチドザのねむいさんにはそっちの方がちょっと辛い作業でした。
前回紹介した通りRDF-5は特殊なscsiコマンドを通じCMD56を特別に通すように
出来ているのでTranscend製品だけじゃなく、その他のSMART搭載の製品でも
余裕で使えます！ここもパースは放棄したやっけつです
ぇ…ところでもったいぶらないで肝心の引数教えてほしいですって…！？
ぇーっと確かちょうどSTM32H7のいつものを更新したのですがねむいさん謹製の
SDMMCドライバのヘッダファイルとか見たらイカス16進数に巡り合えるかも…
ここから先は君の眼で確かみてくれ！
●ラズパイ4のSDカード別起動時間比較
ラズパイのコマンドラインから起動時間を測定できるのでTranscendとMicronで
比較してみました。
↑Transcend
↑Micron
確かにTranscendのほうがちょっと早いですが…MicronもA1クラスでチマチマ読み
書きは十分すぎるくらい早いので劇的な差は無いみたいですね。
ていうかhciuart_serviceとかいうのがめっちゃ時間喰ってます…こいつ削ったら
もうちょっと起動早くなりそう…
●ARMマイコンビルド環境構築手順をようやくWin10に対応
読んで字の通りです…長年放置しておりましたがようやく完全対応いたしました。
・ビルド編
・デバッグ編
デバッグ編のwin10でInsightがまともに動かない問題は直接引数渡して解決です。
過去にWin7で同様の事象に出くわした方がいてねむいさんのWin7環境では発生して
無かったので正直スルーしておりましたがもうちょっと早く気づいていれば…
すみませんでした。
●京都のマルツ閉店
うあああああああああああああああああああああああああ！１１１！１１１！
副業(本業は虹裏メイド)の帰りに大阪日本橋に寄る以外ないのか
Transcendの産業用microSDカードUSD230Iシリーズを試す
20200617追:最後のほうにSMARTツールの追記あります
だいぶ前のコメントでTranscendの産業用SDとかどう？とネタをいただいたのですが
なかなか手が伸びず放置状態となっていたのが超進展しましたのでお知らせします。
2020年現在、Transcendの産業用SD/microSDカードはamazonで一般でも購入可能
です。ねむいさんも入山料を払い、登頂を開始しました！決して企業案件ではない!!!!
今回購入したTS32GUSD230IはSLCモードを搭載した高耐久性を誇る230Iシリーズに
今春新たに8~64GBの容量が追加された最新のモデルです！
さて、工業用/産業用では高い書き込み耐久性を求められますが本製品は3D-TLC
NANDのビットセルを疑似的にSLCみたいにして使う疑似SLC方式を取っております。
なんとTBWは32GB品で1400、64GB製品では5800に及び過去に紹介したマイクロンの
microSDでは容量最大の256GB品でも180TBWだったので破格の耐久性ですね。
この耐久性を実現しているSLCモードはTranscendさんの公式ﾋで解説がありますので
皆さんもよく目を通しておいてください。
んでもって230Iシリーズで使用している3D-TLCNANDも最新の製造プロセスのBiCS4が
使用されているとのことで(今春追加された8GB以上のモデルで適用されていると
思われます)、容量速度耐久性がここまで大幅に上がったと思われます。
というわけでとにもかくにもPCからベンチマークを取ってみました。
はい、御覧の通りとんでもなく早いです。特に4kの読み書き！
マイクロン産業用
サンディスク産業用
キオクシア高耐久
サンディスク超高耐久
↑と比較してもチマチマ4k読み書きがスバ抜けて早いのがわかりますね〜
シーケンシャル書き込みもピカ一です用途としてはドラレコや監視カメラにすら
もったいないくらい、まさに組み込み用PCの起動イメージにするべき逸品です！
お次はいつものでSDカード内のハードウエア情報を読み出します。
●TRANSCEND Industrial Class10 UHS-I V30 U3 A1 TS32GUSD230I
FatFs module test terminal for STM32H747XIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 22 2020
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 21046 kB/sec.
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 7534
Number of clusters = 964256
Volume start (lba) = 8192
FAT start (lba) = 9508
DIR start (lba,clustor) = 2
Data start (lba) = 24576
Volume name is USD230I_32G
Volume S/N is BDB6-0F99
...
1 files, 132949600 bytes.
30856192 folders.
30726080 KiB total disk space.
964256 KiB available.
>ds 0
rc=0
Drive size: 61736960 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 EB 81 7F 80 0A 40 00 C1 @..2[Y.......@..
CID:
00000000 74 4A 60 55 53 44 55 31 20 19 00 57 30 01 44 23 tJ`USDU1 ..W0.D#
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x19005730
DateCode.Month :4
DateCode.Year :2020
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 1E ..............9.
00000010 00 08 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 84 43 00 00 00 00 .5.C....
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :1
SD Security :3
SD Bus Width :5
SD_Spec V5.xx!
Detected as SDHC Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class1, A1 Card.しかも2020年4月の出来立てほやほやの奴です☆
Manufacturer IDの0x74はJiaElec(Transcendの製造協力会社)を示しています。
TranscendはシリアルナンバでRMAの管理をしていますがカードから読み出す上記の
シリアルナンバはそれとは別物であくまでカード表面に記載された番号でなければ
なりません。ご注意ください。
さて、こっから本番ですが230Iシリーズは当然のごとくS.M.A.R.T.(以下SMART)
が搭載されております。搭載されているから買いました！！！
そして肝心のSMART値を得るためのCMD56のアレですがなななななんと!!!!
Transcend embedded様の特別のご厚意により特別に教えていただけることに
なりました！！！！ありがとうございます！！！！
STM32H7のいつものを使ってCMD56でSMARTを読み出してみました。
肝心のCMD56の引数ですがmicronの奴に酷似しているとだけ言っておきます。
多分7月更新のいつものには反映してると思いますのでお待ちください。
何はともあれ"Transcend"のプロダクトマーカーの存在が確認され、SMARTの読み
出しが成功しているとわかります。
SMARTの目玉、カードの寿命ですがTranscendでは70バイト目に存在しています。
まだ使い始めなので100(%)ですね。
読み出したデータはこちらに。4GB以下のモデルと8GB以上のモデルでは同じ230I
シリーズでも細かいスペックやSMARTの構造体が全く違うのでご注意ください。
これからは8GB以上の奴使っていけば間違いはないでしょう。
というわけで払った対価の以上のスペックを持つこのUSD230I、大事なことなので
二回言いますがラズパイとか産業用PCなどのタフな環境で動くOSの起動イメージに
大活躍できそうですね☆
・おまけ(内容だいぶ改訂)
なんとWindowsからSMART読み出せるツールまで提供していただきました…！！
DELKINの奴みたいに特定のセクタアドレス読み出すことでSMART取得できるのか！？
と期待したのですが…
残念ながらそううまくはいかなかったorz
使用しているカードリーダーがサンワサプライの汎用のカードなのでダメなのかなと
思ってTranscendさんに聞いてみるとツールが発行するCMD56を解釈できるRDF5なら
できるとのこと。さっそく購入して試してみました。
TS-RDF5のファームウエアバージョンは"TS3A"ですが多分特定顧客向けの特殊ファーム
じゃないとダメっぽいですねorz
もしくはCMD56通ってたけどねむいさんが購入したTS32GUSD230Iが新しすぎてSMART
読み出せるツールで対応してなくて撥ねられちゃったか。
エラーログには"Write IO Control Fail, Error Message is:6"って記録されていました。
やはりSD SMART TOOLのバージョンが低いとのことで差し替えたら
ちゃんと動作しました。一番下参照。
当然この程度で諦めるねむいさんではない。
STM32F7DiscoveryのUSB-MSC使ってSMART読み出せるツールが投げるSCSI
コマンドを捕まえてみました。するとUSB-MSCではまず使用しない0xD1なる
コマンドが…このコマンドの構造体を掘るとCMD56で投げるべき引数が
ずらずら出てきました…
なるほどそういうことか…！やっぱカードリーダ側でこれが解釈できる
奴じゃないと🙅なんだ。
これってUSBカードリーダーじゃなくてバス直結のSDA標準準拠SDカード
ホストコントローラードライバ使うようなタイプのカードリーダーなら直に
scsiコマンド送れるからうまくいくのかしらと思ったり逆にCMD56こういう
方法でUSBマスストレージ経由で送れるなら専用のファームとソフトを
こしらえるだけでTranscendだろうがsandiskだろうがmicronだろうがWindows
からいけるやんけと思いましたが
マイコンで読み出せば簡単やんと安きに流れるねむいさんの情けない性格を
露呈させたところで本日の記事を〆させていただきます。
かしこ。
20200616追:
Transcend Embedded様から最新ソフトもらったので試合続行１１！！！！！１１１
ｷﾀ━━━(ﾟ∀ﾟ)━━━!!(※管理者権限で実行してください)
か…勝った…！
いくつかカードリーダー試しましたがTranscend製のTS-RDF5とTS-RDF8だけが
正しくCMD56を解釈できるのがわかりました。性能はそこそこですが価格も安く
入手もしやすくTranscend製産業用SDのSMARTも読めるのでこちらもおすすめです！
いろいろ試す42
6月になるというのに10万円まだ来ないよ
●Windows10でラズパイ4の起動SDイメージをバックアップ/レストアする
意外とネット上になかったのでねむいさん流のやり方を残しておきます。
使うアプリケーション
・バックアップ
DD for windows
R2のほうはまだベータ版で動作しないので(ねむいさんとこもダメ)旧番の
Ver.0.9.9.8を使用してください。
・レストア
balenaetcher
かつてラズパイの初期イメージ書き込み用に推奨されていたものです。
こちらはzip圧縮したイメージも展開して書き込みができるのでディスク容量の
節約になります。
・DDwinでバックアップのやり方
RaspberrypiのOSがインストールされたmicroSDをUSBカードリーダーに指して
Windows10から認識させます。ラズパイのOSイメージが仕込んであるmicroSDは
bootというラベルが付いたFAT32のパーティションと本来のラズパイのOSがある
ext4があります。Ext2fsdなどのソフトをインストールしてない限りはフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。
DDWinを管理者モードで起動します。管理者でないとドライブを認識できません。
｢ディスク選択｣でラズパイのOSのインストールされたmicroSDカード(bootのラベルの)
ドライブを指定して｢ファイル選択｣で保存先ディレクトリとファイル名を決定して
｢>>読み込み>>｣ボタンを押すとバックアップ開始です。
DDwinはlinuxのddコマンド宜しくディスク上のデータを1セクタずつ最初から
最後まで読み取ります。そんなわけでバックアップはSDカードの容量が大きければ
大きいほど悠久の時間がかかります。
時間がかかりますが確実です。こいつで読みだしたイメージは容量さえ足りれば
どんなmicroSDにも書き出すことができます！
sudo apt-updateの前は保険でバックアップしておくとよいでしょう。
さて、読みだしたデータはmicroSDのカード容量ぶん馬鹿正直に読み出すので
32GBのカードならなんと32GBのサイズになっちまいます！！！
こんなものそのまま置いておけないのでとっとこzip圧縮します！！
zipで固めるとラズパイOS｢Raspbian｣フルセットでも4GBちょっとに収まります。
・balenaetcherで書き戻す
さっきのzip圧縮したイメージをターゲットのSDに書き戻す！！！
展開しながら書き込んでくれます。
書き込みとベリファイ終わり。終わった瞬間にまたwindowsからフォーマットを
求められてしまうのでうっかりフォーマットしないようにして無視しましょう。
ラズパイ本体に描き戻したmicorSDを指して無事起動。
おしまいっ！めでたしめでたし。とっても簡単だ！
というわけで複数のツールと手間はかかりますが確実に起動可能なイメージが
保存/書き込みできますので変な設定してラズパイが起動できなくなった時の復帰
手段として覚えておいて損はありません！
●最近続々出だした高耐久SDカードの性能を見る
まずはTOSHIBA製の高耐久128GBカードEXCERIA THN-M303E1280A2(以下M303E)です。
ねむいさんがこのカードを手に入れたころにはTOSHBAメモリからKIOXIAに名前が
変わってしまいましたが(2019.10.01)、昨年の夏に世に出たようです。
SDSpeedClass10、UHS-I U3、VideoSpeedClass30,ApricationClass1(A1)の
規格や-25~+85度の動作環境温度を満足しており、さらに6,000時間の書き込み保証を
しているそうでドラレコや監視カメラに最適なカードとうたっております。
まずはWindows上からベンチを取ります。
チマチマ書きもめちゃくちゃ早いですね。ラズパイのOS用にも良いでしょう。
マイクロンの物と比べるとちょっと遅く感じますがこの数値でも十分早いです。
お次はSTM32H7からカードの情報を読み出してみました
FatFs module test terminal for STM32H747XIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 31 2020
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 22726 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 16384
Number of clusters = 944384
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is M303E_128GB
Volume S/N is 78EB-41E0
...
1 files, 132949600 bytes.
120881152 folders.
120750336 KiB total disk space.
4 KiB available.
>ds 0
rc=0
Drive size: 241827840 sectors
Erase block size: 16384 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 03 9A 7F 7F 80 0A 40 00 AF @..2[Y.......@..
CID:
00000000 02 54 4D 44 52 31 32 38 74 07 63 06 A1 01 3C 03 .TMDR128t.c...<.
Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :DR128
Product HwRev :7
Product SwRev :4
Serial Number :0x076306A1
DateCode.Month :12
DateCode.Year :2019
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 A0 00 20 07 3A 1E ............ .:.
00000010 00 08 00 00 00 01 00 00 01 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 C5 84 43 60 03 40 1A ...C`.@.
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :1
SD Security :4
SD Bus Width :5
SD_Spec V5.xx!
Detected as SDXC Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class1, A1 Card.
>単純な読み出しはSDHighSpeedの限界値まで出てますね〜
また、SdSpecはV5.xxで各種規格はスペック通りに満たしているとわかります。
お次はSANDISK製(ここはWestanDigitalになっちゃいましたが)のMAX ENDURANCEと
謳う超高耐久microSDカードSDSQQVR-064G-GN6IAです。
なんと30,000時間の書き込み(128GBはその倍)を保証し-25〜85度の動作温度保証
とSDSpeedClass10、UHS-I U3、VideoSpeedClass30の規格を満足しています。
アプリケーションクラスは無いみたいですね。こちらもドラレコや監視カメラ
の連続書き込み用でチマチマ書き込みはそれほど得意ではないのかも！？しかし…
とりあえずベンチ。
あれ…TOSHIBAのより性能高い…！？チマチマ書きもA1クラス保証の奴よりいいぞ！？
STM32H7からカードの情報を読み出すとその理由が判明！
FatFs module test terminal for STM32H747XIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 31 2020
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read at 21631 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 16384
Number of clusters = 486992
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is SQQVR-064G
Volume S/N is D6EA-C58C
...
1 files, 132949600 bytes.
62334976 folders.
62204160 KiB total disk space.
4 KiB available.
>ds 0
rc=0
Drive size: 124735488 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 DB 79 00 01 DB D3 7F 80 0A 40 40 F9 @..2.y.......@@.
CID:
00000000 03 53 44 53 48 36 34 47 80 17 A7 01 58 01 41 A1 .SDSH64G....X.A.
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SH64G
Product HwRev :8
Product SwRev :0
Serial Number :0x17A70158
DateCode.Month :1
DateCode.Year :2020
OCR:
00000000 C1 FF 80 80 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 0F 05 39 1E ..............9.
00000010 00 08 00 00 00 02 FC 00 03 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 87 00 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :2
SD Security :4
SD Bus Width :5
SD_Spec V6.xx!
Detected as SDXC Card!
Available UHS-I Mode.
Available UHS Speed Class U3.
Available SD Speed Class 10.
Available Video Speed Class 30.
Available Application Performance Class2, A2 Card.
A2 CommandQueue Depth 32 Supported
A2 Cache Supported.
>御覧の通りなんとA2カードだった！？SDSpecもV6だし間違いない！！！
というわけでMAXENDURANCEを誇るSANDISKの超高耐久カードはカタログスペック
以上の規格を備えた高性能カードでもあったことがわかりました！！！
お値段的には202005時点では同容量では性能が若干劣るTOSHIBAのほうが安いです。
購入の際は価格対効果を考慮して自分に合ったやつを使っていきましょう。
からポーティングした時のバグです(FAT0ではなくexFAT)。
6月定期更新で修正します。)
20200531修正しました
いろいろ試す41
駄目だ…コロナのせいで休業になってブログ更新の時間獲れると思ったら逆に
労働時間パワーアップしやがった…(←言い訳)
●Raspberrypiはぢめました
年末に欲張りセットを買ったきりになってましたがわずかな時間を見つけて
ねむいさんもようやく手をつけてみました！！
RaspBerrypi4 modelB 4GB
Raspberrypiの4世代となるボードだそうで主に下記のぱわふりゃーなハード
ウエアが搭載されています。
・gigabit ethernet
・USB3.0
・HDMI dual Display
・Bluetooth4.2
・wifi(速度不明)
もうなんというか普通のPCですね…
CPUはCortex-A72プロセッサの｢BREADCOM BCM2711｣だそうです。
メモリはこのモデルの最大値の4GBの奴を選びました。
Bluetoothとwifiがあるので当然国内の電波法には対応しておりしっかり
技適は獲れてますね…誰がAHOや！
また、電源は今はやりのUSBType-Cコネクタからとります。当然要求される
電流値もぱわふりゃーなヤツで5V/3A以上が最低条件です。
ねむいさんは電圧降下が考慮された5.1V/3Aのスイッチングアダプタを購入
しました！
消費される電流値から放出される熱量を考慮してヒートシンクケースも
アマゾンで購入しております。そんでもってHDMIに対応した480x800のTFT
液晶モジュールも購入してありますので準備万端です。
Raspberrypi4はボード上にeMMCとかはなく、SDカードからの起動オンリーと
なっています。
OSイメージの書き込み方は｢raspida.com｣様の手順に倣いました。
OSは"Raspbian Buster with desktop and recommended software"を選択
して"balenaEtcher"というwindowsのソフトでSDカードにイメージを書き込んで
いました(が2020年4月に公式の書き込みソフトが配布されたようです)
てなわけで電源投入！！
…
ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
キーボードはまだないですがマウスでなんとか操作できますがここまで行けました☆
そんでもってwifiからねむいさんのメインPCのモバイルホットスポット経由でVNCで
リモート接続、そしてメインPCからRaspiのブラウザを操作して…
虹裏に自分が建てたスレッドにも投稿成功！
とりあえずねむいさんがやりたかったことはできました…！
ぇ？これからのことどうするって！？それはこれから考えます！！！！！
●Win10のモバイルホットスポットをまともに動かすためのメモ
Windows10にはかつてのSoftAPに相当する機能が簡単に利用できる"モバイル
ホットスポット"なるものが存在しますがなんでかすぐにへそを曲げてしまい、
思ったような動作になりません。
Raspberrypiをwifiで接続しようとしたとき引っかかったのですがIPアドレスが
164.254.***.***というローカルリンクアドレスとかいうやつになってしまい、
このアドレスになっちゃうと外部のネットにつながりません。
で、モバイルホットスポットのメインPCで↑にならないための事前準備など
1.IPv4で接続する、IPv6は停止する(最優先)
2.こちらの方のの設定手順を実行する。SNPの設定は重要。
終わり。
これでwifi/bluetoothから安定してモバイルホットスポットが使用できるように
なります
が、もし再発してしまった場合はまずは下記の操作をしてください。
１．デバイスマネージャー起動 ->表示->非表示のデバイスを表示
２．"Microsoft Wi-Fi Direct Virtual Adapter #(数字)"を全部削除！
３．また、wifiアダプターで使用していなくて非表示になってるやつも削除！
４．PC再起動
これでほぼ何とかなります。Bluetoothでもこの現象が出ることがあり、大抵
USB接続のBluetoothドングルを別のUSBポートに繋げたらなってしまいます。
この場合は落ち着いてデバイスマネージャーから非表示になっている奴を
消すと改善します。Win10のモバイルホットスポット機能は動作の安定性は低い
ですが対処法さえしってしまえば強力な武器になると思います。
OpenOCD小ネタ26 -とうとうXPともお別れ-
とうとうこの時が来てしまいました…
ねむいさんのぶろぐ創設時より長年サポートし続けてきたWindowsXPともお別れ…！
どういうことかというとOpenOCDがリンクしているlibusbのWindowsXPのサポートが
コードからオミットされて終了してしまったのです…もうXPで動かせません。
Oh...my...ｺﾝﾌﾞ
XPのマイクロソフトのサポートが終わってもう6年、Windows7のサポートすら終わった
のでXPはこれで完全にお役御免と相成ったわけです。
まぁ実際の開発の現場じゃ昔のソフト動かすためにバリバリの現役だったりするのです
けどもそれは特殊な状況ですから今日日の普段使いのWindows系OSはすでに
使いづらいWin10に切り替わっていると思います。
というわけでOpenOCDバイナリのダウンロードページのリンク先の奴はすでに
XPサポートはオミットされた最新のlibusb1.dllが梱包されたものに変わっております。
まだXPで踏ん張ってる人はこちらの最終verをご利用ください。
同じくして他ツールも今回のlibusbがらみで更新を適用し、最新化をしました。
UrJTAG、FlashROM、そしてavrdudeが影響を受けてwindows7以降専用となって
おりますのでご注意願います。
また、64bitOS下でも32bitバイナリで不都合はないため、利便性を重視して
x86版でもx64版でもどちらのOSでも使用できるようにOpenOCDも含めてすべて
32bitバイナリのみの提供とさせていただいております。
STM32H7はぢめました・・・本当にいまさら
ｷﾀ━━━(ﾟ∀ﾟ)━━━!!
まってたぜぇ…この瞬間(とき)をよぉ…！
出る出る詐欺で一向に出る気配がなかったSTM32HのDiscoveryがついに私の
手元に入りました…！本当に長かった…！(※正式名称はSTM32H747I-DISCO)
基板の形状はSTM32F769I-Discoveryとほぼ同一ですね
メインCPUはH7シリーズ第二世代のSTM32H747XIH6です。第2世代になって何が
変わったかというとなんとCortex-M4コアがもう一つ付いたデュアルコア構成と
なっております！！！！
そんでもってビルトインされたSTLinkも最新のV3仕様で使用CPUはSTM32F723です！
なんとオンチップでUSB-Highspeedの物理層が乗っかっているすごい奴なのです！！
SDRAMはISSI製の32Bitデータバスの32MByteの奴が乗っかっています。
液晶を外して基板表面も見てみましょう。液晶モジュールはSTM32F769I-Discoveryと
全く同じMIPI-DSI接続のWVGAなTFT-LCDです(容量性タッチパネルICも同じ)
LANの物理層はおなじみMicrochipのLAN8742Aです。
そしてこの多CHフォトカプラみたいなのなに…と思ったのですがこれがQSPI-ROM
なのです！マイクロンのMT25QL512ABB8ESF-0SITが乗っています。
そして基板の反対側にもついている。STM32H747XIでは2つのQSPI-ROMを一つの大
容量クアッドSPI-ROMのように使えるDUAL-QUAD Modeが搭載されております！
I2S-CodecはおなじみのWM8994Eです。
そしてArduinoスタイルのコネクタの他にもI/Oを外部に拡張できるコネクタが
新設されました！Xbeeとかをそのままつけられそうですね〜
…
ぜんぜんピン間隔ちがってたorz
外観はこの辺にしておいてUSBMicroケーブルぶっ刺して通電です！
STMicroがイチオシするSTemWinとTouchGFXをふんだんに使用したでもアプリが
起動します。
TouchGFXはSTM32F769I-Discoveryの時のようにCPUの負荷状態とか見られる機能や
JPEGやDMA2Dみたいな各種ハードウエアアクセラレーションの効果を見ることが
できるプログラムもあり…おや…これは…
ク ソ ゲ ー 再 び
モーやってられませんわこれ(←律儀にやる人
さて、STM32H7でもいつものベアメタルでとりあえず組んでみる予定です。
現在はLチカにはぢまってねむいさんのコンテンツでは欠かせないDMA動作を絡めた
FatFsの実装まで完了しております(画像はLED点滅しているところ)。
H7に上がって機能も制約もF7とは段違いに変わってますので実装を進めながら
次回以降にみっちりと解説していけたらと思います！
3D-TLC搭載のマイクロン製産業用MicroSDを使ってみる
とある用事で大阪に降りた際に寄ったいつものPCショップでねむいさんが前から目を
付けていたMicron製のMicroSD(ややこしい)を発見し、早速入手しました！
諸般の事情で128GB‥かつてはこの容量だと10000円越えだったのに産業用でも
5000円以下となりずいぶんと安くなったものです…
正式な型番はMTSD128AHC6MS-1WTとなっております。
Micron公式では産業用向けとして紹介されており3D-TLCセルを使用した大容量・長寿命
を以てネットワーク監視カメラ用途を想定したものとなってりますが当然のことながら
ドラレコにも最適です☆
そして産業用ならでわのS.M.A.R.T.(以下SMART)も当たり前のように存在しており、
ねむいさんはもちろんそちらの方が目当てだったりしてました！
-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes
Sequential Read (Q= 32,T= 1) : 70.235 MB/s
Sequential Write (Q= 32,T= 1) : 45.021 MB/s
Random Read 4KiB (Q= 32,T= 1) : 4.693 MB/s [ 1145.8 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 4.378 MB/s [ 1068.8 IOPS]
Sequential Read (T= 1) : 71.302 MB/s
Sequential Write (T= 1) : 42.824 MB/s
Random Read 4KiB (Q= 1,T= 1) : 3.534 MB/s [ 862.8 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 3.475 MB/s [ 848.4 IOPS]
Test : 1024 MiB [H: 0.0% (0.0/116.1 GiB)] (x5) [Interval=5 sec]
Date : 2019/06/07 21:17:20
OS : Windows 7 Professional SP1 [6.1 Build 7601] (x64)
Micron Industrial MicroSDXC 3D-TLC UHS-1 MTSD128AHC6MS-1WT ADR-3ML35BK USB3.0 uPF720202 M570RUSandiskの産業用(第三世代)と比べてみますとチマチマ書き込みがかなり強い印象がありますね(理由は後述)。
FatFs module test terminal for STM32F769NIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jun 8 2019
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18452 kB/sec.
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 17931
Sectors/FAT = 16384
Number of clusters = 951296
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is MTSD128AHC
Volume S/N is DAD2-8E1E
...
1 files, 132949600 bytes.
0 folders.
121765888 KiB total disk space.
121635456 KiB available.
>ds 0
rc=0
Drive size: 243597312 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 03 A1 3F 7F 80 0A 40 00 0F @..2[Y...?...@..
CID:
00000000 09 41 50 4D 42 35 33 41 01 E1 00 6F 10 01 28 C5 .APMB53A...o..(.
Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :MB53A
Product HwRev :0
Product SwRev :1
Serial Number :0xE1006F10
DateCode.Month :8
DateCode.Year :2018
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 01 33 19 00 .............3..
00000010 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 80 43 01 00 00 00 .E.C....
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :1
SD Security :4
SD Bus Width :5
SD_Spec V5.xx!
Detected as SDXC Card!
Available UHS-I Mode.
Available UHS Speed Class U1.
Available SD Speed Class 10.
Video Speed Class NOT Supported.
Available Application Performance Class1, A1 Card.FatFs移植例も7月更新分からSDカードのサポート情報の細分化を進めており各種
スピードクラスのサポート状況が分かるようになりました。
このMicron製の奴はカード本体には記載はないのですがA1クラスサポートとなってお
ります。いちおう公式でもA1対応と言っておりますが製造時にロゴのレタリング追加
するの忘れちゃっただけなんでしょうけど。
そしてこのマイクロSD買ったメインの目的のSMART情報の取得です!
このカードではDelkinやSandiskと同じくCMD56でSMART情報の取得が可能なのですが、
なんと公式に資料を公開しており超太っ腹です！こちらの資料によるとCMD56の引数は
0x110005FBとなります。これを引数にしてCMD56を打ち込んでやると無事SMARTの
情報を取ることができました♥(もちろんSPI互換モードでも獲れます )
こちらに読みだした生データを置いておきますのでご参考に。
今回SMARTをとるにあたり上のテクニカルノート見て気づいたのですがこのMicron製の
奴はNANDメモリセルが3D-TLCなのですが一部はSLCのようなんですよね…
"Internalbuffer"としてどういう使い方するかによりますがFAT/exFATファイル
システムで使用する際に先頭にある書き換えが激しいFAT領域まではSLCの区画を
使用して比較的消去サイクルが少ないデータ領域に関しては3D-TLCの区画が
使用されている……といった感じなのでしょうか？？？
そしてSLCの区画をバッファとして使用することによってチマチマ書き込みも
強化されている感がしますね。
こういったハイブリッドなメモリセル構成にすることでコストパフォーマンスと信頼性を
同時に確保して大容量化を目指す路線が今後のSDカードで流行りそうですね〜
SDUCでの最大容量が128TBだそうですが近い将来にあっさり到達してしまいそうです。
OpenOCD小ネタ24 -ビルドするときの小ネタとかも-
もうすぐ2月ですが
あけましておめでとうございますした！
今年も皆様に役に立つ情報を提供していきますのでどうぞご贔屓に☆
なお、新しい副業先(本業は虹裏メイド)ではこのぶろぐの事は完全に隠匿している
ため｢あ、こんにちはネムイさん(ﾌﾟｰｸｽ｣とかおちょくられることはないのでねむい
さんもいないさんのぱんつがみえてるｲﾗｽﾂとか安心して公開
…とかは多分しませんので他の方が学校や職場から見ても問題ないような
記事の充実をしていこうと思います。あとdropboxの画像の復旧がむばります…。
本題に入りますが2019年最初のOpenOCDバイナリ最新版も公開しております。
皆様どしどし使ってください☆
●OpenOCDビルドするときにJIM-TCLの所でコケる対策
昨年10月くらいのアップデートからMSYS環境下でOpenOCDをビルドする際に下記の
変なメッセージを出してJIM-TCLのコードがclone出来ずOpenOCDのビルドが先に
進まないという問題にぶち当たりました。
fatal: unable to access 'https://repo.or.cz/r/jimtcl.git/': SSL certificate problem: unable to get local issuer certificateなんでや…これでOpenOCDのgerritにもパッチあげられてるのに…
仕方ないのでいろいろ調べていると回避方法が見つかりました！
git config --global http.sslVerify false"http.sslVerify false"でぐぐるとメジャーな問題だったようでねむいさんのアンテナ
の低さに自分自身で情けなくなってしまいましたorz
ねむいさんのOpenOCDぱっち詰め合わせの中にあるビルドスクリプトにも上記の対策と
ついでに64ビットOS環境下でMSYSを動かしたときに動きが鈍くなる対策も突っ込んで
降りますのでご参考に(openocd_update_s_libftdi参照)。
●libusbもアップデートしてるが…
1.0系が完全に定着したlibusbですが現在も時々刻々と機能追加や修正がくわえられて
アップデートし続けております。linux系OSでもWin系OSでもビルドできるようにgitで
ソースコートが管理しておりますがたまに特定のOS環境下でしか確認せずにエンバグ
された状態でマージしやがるやつがいます####(OpenOCDでも度々見られますが…)
これの修正は強烈でした。この修正が入った以降のコミットでビルドされたdllを使用
したら問答無用で落ちますorz
追加されたlibusb_wrap_sys_device関数のおかげでdll召喚した瞬間にお陀仏ですorz
仕方がないのでlibusb_wrap_sys_deviceのファンクションコール(Windows系OSでは
使用されていない模様)をまるまる削ったdllで事なきを得ております。
ねむいさんの公開しているOpenOCDバイナリにもこの修正がかかったlibusbのdllを
使用しておりますので安心してご使用できます☆
20190131追:
やっと直りました…F++K!
●某壺の件
LPC800系のOpenOCDのパッチは、先にねむいさんが提出したnumicroのパッチが
マージされたら提出しますのでそれまではねむいさんのOpenOCDバイナリを使用して
いただききたく思います。
でもNxPのマイコンをわざわざSTLinkで使う物好きな人とかあんまりいないので
殆どの人はこのバグに気づいていないでしょう〜
全部こいつのせいだ〜！ねむいさんはわるくないぞ〜！
●ブレークポイントで止まらねぇ！
OpenOCDのCPUコアに近い場所にパッチが当たった場合その影響がたいぶ後になって
気づくことが多々あります。
ねむいさんの提供しているSTM32F7向けのOpenOCD用cfgファイルはQSPIフラッシュが
ついてない基板でも動作できるように"gdb_memory_map disable"というオプションを
着けておりました。しかしながらそれのせいでコアにパッチがあてられたあたりから
ブレークポイントで止まらず特にmainの先頭とかで止まらずまともにデバッグが
できなくなってしまいましたorzまたですか…☠
ねむいさんの提供しているcfgは内蔵フラッシュからの起動/デバッグを想定している
ので対策は一応あります。cfg内で"gdb_memory_map disable"を記述した直後に
下記の一文を追加するとブレークポイントを貼った場所に止まることができる
ようになります。
"gdb_breakpoint_override hard"
多分RAM起動だと副作用でまくると思いますがフラッシュの書き込み耐用回数が増加
した現在ではそういう運用することはあんまりないので大丈夫とは思います。
また、正式には未だマージされていないQSPIのフラッシュ対応(XIP:直接実行)も配慮
した今回の修正なので、もし正式にQSPI対応になったら本腰入れて動作検証を重ねて
行こうと思います。
いろいろ試す36
今年は本当に波乱に満ちた年でしたね…
それでも月一ペースで何が何でも記事を更新できた私をほめてあげたい(自画自賛
●4GBのマルチメディアカードをついに入手！…しかし…
流通在庫が高すぎて敬遠していたのですがebayで新個品が放出されたタイミングを
見逃さなかった！！！！！Transcend製の4GBもあるMMC｢TS4GMMC4｣です！
同じトラ製のSDHCカードと比べてみました。
当たり前ですがねむいさんのSTM32F7のいつものでしっかり認識します。
カード情報も拾ってみました
FatFs module test terminal for STM32F769NIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Sep 30 2018
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 17609 kB/sec.
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 960
Number of clusters = 122752
Volume start (lba) = 8192
FAT start (lba) = 14464
DIR start (lba,clustor) = 2
Data start (lba) = 16384
Volume name is TS4GMMC4
Volume S/N is 9FB2-841B
...
1 files, 132949600 bytes.
0 folders.
3928064 KiB total disk space.
3797920 KiB available.
>ds 0
rc=0
Drive size: 7872512 sectors
Erase block size: 512 sectors
Default r/w block size: 2048 bytes
Card type: MMC(Byte)
CSD:
00000000 90 2F 00 2A 1F 5B 83 C0 F6 DB BF FF 96 C0 00 1D ./.*.[..........
CID:
00000000 1E FF FF 4D 4D 43 20 20 20 10 00 00 02 2E BD 73 ...MMC ......s
Parsing MMC CID Register
Manufacturer ID :0x1E
OEM/Application ID :
Product Name :MMC
Product Rev :1.0
Serial Number :0x0000022E
DateCode.Month :11
DateCode.Year :2010
Detected as MMCv4.1 Device!
OCR:
00000000 80 FF 80 00 ....
>今から8年前に造られた最後の方のロットのMMCですね〜
ebayの新古品は2000円近辺で購入できるので例のSDライセンス問題も全く心配なく
ホビーで使いまくれると思います！
…と思ったのですが！！！
なんとこのMMC、MMCv4.1なのですが今日びのSDカードですら存在する
SPI互換モードが存在しないためマイコンの工作でSPIで手軽に使用する
ことが一切できませんorz
上で認識してたのはSTM32F7のSDMMCからMMCネイティブモードで叩いたので
さくっと動いて見えたのですが…皆さんご注意ください。SPI互換モードが
存在しないのは4GB品だけで2GB以下の品種はちゃんとSPIでも動きます…。
外人さんも嘆いている
ちょうどeMMCへの過渡期だったので4GB品の製造の際に遅いSPIモードがオミット
されてしまったのでしょう…まぁ電子工作で4GBも使うって早早ないから2GBでも
十分じゃないかな〜…うっかりSDカードが動いてしまうこともありますし
というわけで古のデバイスにも癖があったというおはなしでした！
●サポート止めたプロジェクトをメンテしてみた
3年前に更新停止したLPC2388のプロジェクトとかを最新のFatFsとかにあてがって
みました。arm-gccは表向きはcortex-mのサポートとうたっていますが昔の
ARM7TDMIとかも余裕でビルドできます。
OpenOCDの書き込み・デバッグも順調です☆
あとLPC2388はUSBデバイス機能があってMSCやCDCなんかができるんですけど
たとえばCDCでは現在ではzadigを使用して汎用のCDCドライバをあてがう
ことができるので格段に使い勝手が上がってます！
まぁあえてLPC2388を使っていく意味も今となっては有りませんが余興ということで
そしてMicrochipになってしまったATMEL製のXMEGAもFatFsの最新版(0.13c(patch1))
をあてがって動作確認できました。
コード効率が悪い上に容量も128kbしかないのでexFATはおろかLFNすら乗っけられ
ませんがまぁ余興と(ry
ちなみにAVRToolchainは数年前に更新しなくなりましたが有志の方がavr-gccのツール
チェインを更新し続けているためほぼ同じ感覚でgccビルドができます。
avr-gccを使う上で注意すべき点はavr-size.exeがAVRのフォーマットが使えず、
汎用の動作しかしないのでFLASH/RAMの容量は自ら管理しなくてはいけません。
まぁここもARMマイコンいじるさいはリンカスクリプト自前で起こす必要あって
皆さん経験済みなので問題ないでしょう。
avrdudeも更新停止したと思ていたらさりげなく更新してたので久しぶりにビルド
しました。おきぱにあるのでどしどしご利用ください！
また、avr-gccにはavrdude.exeが同梱されてますがかなり古いのでavr-gccと
ねむいさんのavrdudeを組み合わせて使う際はバッティングにご注意ください。
同時にUrJTAG、flashromも微妙に更新がかかっていたのでビルドし直しました。
ビルドに当たってはOpenOCDも含めてMinGW-w64 GCC8.1.0を使用してますので
ビルド環境もアップデートしております！
●arm-gccの新しい奴が出た！
例年年末に出るやつがやっと来ました。
今回の変更点はGCCのバージョンがついに8になったところです！
さっそく導入してみました！
…
ﾅﾆｺﾚ…ihexで出力できない…
64-bit address 0x4b4fa300000000 out of range for Intel Hex file
ってなんなんだＹＯ！
arm-none-eabi-objcopyバグってる…？
調べてみると同じ症状に遭遇された方がいました。どうやらarm-gccの新しい奴にある
objcopyにバグがあり、IntelHEXフォーマットの出力ができないようですorz
対処法はどうしても新しいarm-gcc使いたい場合はarm-none-eabi-objcopy.exe
だけ一個前のverに差し替えるだけでおｋです。
こんな基本的なところでエンバグするの止めてくださいよ〜！
※バグじゃなくてオプションのつけ方悪いだけならご指摘願います
20190131追:
公式も認めました！！
●転職しました
読んで字の通りでございます。
2012年から長きにわたる派遣ジプシー生活からようやく解放されて正社員になれたん
やなぁ…って
あまり詳しいことはお伝えできませんが正社員への転職に当たっては最初は自力で
転職サイトとかに登録して活動しておりましたが有効求人倍率が1倍を上回る状況
にもかかわらず年齢的にも経験的にも箸にも棒にも引っかからず全く太刀打ちでき
ませんでした。
しかしながら存在は知っていたものの興味が無かった転職エージェントを利用した
ことで状況は大きく変わり、そこそこの待遇で内定をたくさんいただくようになり
その中で納得がいく会社に2018年内に無事就職する運びとなり、今も頑張っています。
この時利用したエージェントさんですが"め"ではじまる名前と"あ"ではじまる名前の
二社で進めていき両社とも技術系に特化した所でしたので私の適正に近い会社様を
すぐに紹介していただけました。リクルートとかエン転職とか有名どころですが
某魔法少女より｢それらは避けよ｣と事前に忠告されていたため、ちょっとマイナー
ですが"め"と"あ"ではじまるところにお世話になった次第でございます。
ちなみに両者のエージェントさｎより口をそろえてほぼ同じ内容を説教されましたが
｢あなたのブログは選考者に対して大きなマイナスの印象を与えるので紹介しては
いけませんよ」って言われてもちろんgithubもそこからブログにたどり着けちゃう
ので当然ダメでそれらの要素省いた出がらしみたいなスキルシート作るのが一番
精神的に辛かったのですがたぶん自力でやってた頃あっさりbanされまくってたのって
これが原因かなと思ってたのですがねむいさん面白い記事書けるよう務めてきたはず
ですが、いないさんのちょっとぱんつがみえてるｲﾗｽﾂとか至って健全で普通なのに何故だ(錯乱
20190407追：
ねむいさんのぶろぐがスラドに！！！
マジレスしますと私のぶろぐ記事から読み取れる私の技術的能力・文章作成能力は
｢ありものを組み合わせて動いたつもり分かったつもりの素人レベル」でこいつに
プロとしての仕事はできないと判断下され採用に至らなかったからですがorz
エージェントさんより指導入りまくった実務経歴の方はしっかりと評価していただけた
会社様が多かったので私がダメだっただけでホントに個別論ですね個別論♨
↑苦しい突っ込み入れられたら個別論で茶を濁して逃げるのいいですねねむいさんもよく使います♨
●ねむいさんFAQ
Ｑ：昔のぶろぐ記事でdropboxの見えなくなった画像早く復旧してください
Ａ：ぇっと…
今年は大事なことにたくさんエネルギー使っちゃったので
来年からがむばります！
いろいろ試す35 -ようやくWindows10環境に手を付ける-
今年もあと一か月を残すまでとなりましたが2018年はろくな年にならないのは
もはや確定事項ですがそれでも明日に向かって歩みださなければ明日喰わせる
飯も確保できないので破滅に向かい突進む運命でも新しい概念にちゃれんぢ
し続けていく覚悟で挑んでおります。
さて前置きが長くなりましたがねむいさんもやっとWindows10の環境を導入する
運びとなりぶろぐの読者様頼りだったWindows10下でのARM開発環境の動作確認を
自前で試すことができるようになってきました…がそのまえにねむいさんがWin10
でいきなり遭遇した困ったことと解決策を紹介します…
●USBメモリとかSDカードさしたら強制的にSystem Volume Informationとかいう
フォルダがつくられて消せないんですけぉ！！！！！11！！１！
はい読んで字の通りです。
このフォルダ、Win7とかではNTFSでフォーマットすると管理のために作られる奴と
認識しておりましたがWin10の1803ビルドではNTFSだろうがFATだろうがexFAT
だろうがマウントした瞬間にWin10の野郎がマウントしてきて強制的に作って
きやがるようになってやがります＃＃＃＃
これmbedとかのマスストレージで認識してD&Dで書き込みするプロトタイプボート
とかは死活問題ですが特にKinetisに関しては殺し技になってしまいますので開発
中心のPCならSystem Volume Informationフォルダ(とその中にあるWPsettings.dat)
をはなから作らせないようにする措置を取らなければなりません！！
ねむいさんが試行錯誤したところ、2018年11月現在のバージョン1803では以下に
紹介する方法でピタリと止まりました。
※必ずAdministrator権限で操作を行ってください！！！
��DisableRemovableDriveIndexingの設定
レジストリエディタを起動し、
HKEY_LOCAL_MACHINE¥SOFTWARE¥Policies¥Microsoft¥Windows¥Windows Search
キーの配下にDisableRemovableDriveIndexingというdword値を設定し1にします。
過去のバージョンではこれだけでおさまりましたが1803ではこれだけではだめです。
��WindowsSearchの停止
コンピューターの管理->サービスとアプリケーションからWindows Searchを停止させ
無効化させます。正直これを常駐させるメリットが一切何も感じられないのですが
Win7以降でファイルサーチがうんこになってしまったので別のアプリ探して使ってる
始末ですし…システムドライブにSSD使うのが当たり前の昨今では私はWin7でも
真っ先に止めてます。
��Storage Deviceの停止
コンピューターの管理->サービスとアプリケーションからStorage Deviceを停止させ
無効化させます。一体全体何の目的で起動しているのか？？？ことWin10においては
System Volume Informationフォルダを強制的に作ることしかないのではないか
と思うほどです。
以上� 銑�の操作をすべて行い再起動したらUSBメモリさしまくってもSDカード
さしまくってももう二度と憎いSystem Volume Informationフォルダは勝手に
作られません！…と言いたいところですがWin10はアップデートするとユーザーに
不利な設定に勝手に戻されるようでアップデートごとにこの操作を忘れずに
やらなければなりません。
あああめんどうくさい…
ちなみにできてしまったSystem Volume Informationフォルダを消すにはドライブ
上で右クリックし｢ポータブルデバイスとして開く｣でドライブに入ったら一撃で
中身のWPSettings.datもろとも消去することができます。お試しあれ。
20200119追:
1909以降は上記対策では不完全です！！！！
こちらもご覧ください！
20200119追:
あんまし関係ないですがTranscend製のUSB3.0カードリーダーTS-RDF5は古い
ファームウエアのままWin10環境で使用すると消去時に何故かディレクトリごと
全破壊してきやがりますので必ずアップデートしておきましょう！
…知らずにSDカード挿して折角とった基板の写真が全部消えたorz
●ARM開発環境確認中
約10年前からほとんど変わっていないねむいさんのARM開発環境ですがねむいさんの
現在の手順でほぼ問題なくプロジェクトのビルドとかはできることが分かっております。
しかしながら構築時の気になる細かい点はいくつか見つけたので年末までに手順も
ブラッシュアップして皆様に分かりやすくリニューアルする予定です。
まだ評価中ですがOpenOCD+GDB/Insightも昔とまったく変わらない操作感覚で
書き込みデバックができてます。dllの互換性も全く問題がありませんでした。
これであと20年はゆうに戦えますよ〜！
20230921追:
し か し ・・・
OpenOCD小ネタ23 -新機能続々更新-
夏が終わったと思ったらもう冬かよ…秋はどこだ…
さて、そうこうしているうちにOpenOCDも着々とバグフィクスや新機能が追加されて
おります。そろそろV0.10からV0.11になっても良いと思いますがgerritで管理され
てる全員参加型のフリーウエアにそれを求めるのはあまりにも野暮ですがそれはおい
説いて紹介させてもらいます。
●CMSIS-DAPの速度がアップ！
CMSIS-DAPはARM肝入りのフリーなデバッガアダプタで最近販売されている安価な
Cortex-Mx系の評価キットでは欠かせないものとなっております。
ねむいさんのぶろぐでも2014年にいち早く紹介させてもらっています。当初は
マイコンへの書き込み速度が非常に遅く使い物にならなかったのですがその後機能強化
されようやく実用レベルに、そして今回の修正でさらにスピードアップしました☆
もっとも2017年春にはすでにパッチが上がっていてねむいさんが提供するバイナリ
にはそのパッチが適用されておりましたので皆さん実は気づかず使用されて
いたことになります！
それではさっそく比較してみましょう。
今回CMSIS-DAPを仕込んだLPC1549Xpressoを引っ張りだしてきて32kByteの
バイナリを書き込み、ベリファイを行いそれぞれの経過時間を比較しました。
●修正適用前
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
verified 29400 bytes in 0.426025s (67.393 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:04●修正適用後
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select '.
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)
verified 29400 bytes in 0.425024s (67.551 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03 書き込み速度だけ抜き出して比較
前 :wrote 32768 bytes from file main.elf in 2.525144s (12.673 KiB/s)
後 :wrote 32768 bytes from file main.elf in 2.477142s (12.918 KiB/s)
…
あらら…140%早くなるんじゃないの‥？？
…まぁちょっと早くなったしまぁいっか！
●NuvotonのNuLinkに対応！
台湾NuvotonのCprtex-M系マイコンNumicroシリーズ、数年前にねむいさんが
フラッシュ書き込み対応させて以来即効飽きて放置してましたが…なななんと！
Nuvotonの開発チームの人が直々にNuvotonのCortex-Mx向けのデバッガNuLinkを
OpenOCDに対応してくれました！！！！１１！！！
ちなみに秋月で購入できるNuvotonのキット付属のNulinkはUSBコンポジットデバイスで
制御対象マイコンとつながるのはUSB-HIDとなっており、これだけで動作させるならば
ドライバすら不要です☆
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/nulink.cfg -c "transport select hla_swd" -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0+dev-00563-gda4b2d5-dirty (2018-10-29-08:10)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
none separate
Info : clock speed 1000 kHz
Info : NULINK is Nu-Link1
Info : NULINK firmware_version(6386), product_id(0x00012009)
Info : IDCODE: 0x0BB11477
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000035e msp: 0x20003fd0
auto erase enabled
Info : Device ID: 0x00012000
Info : Device Name: NUC120LE3AN
Info : bank base = 0x00000000, size = 0x00020000
Info : Nuvoton NuMicro: Sector Erase ... (0 to 41)
Info : Nuvoton NuMicro: Flash Write ...
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
wrote 21504 bytes from file main.elf in 6.905395s (3.041 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003fd0
verified 21288 bytes in 0.324018s (64.160 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:13
パッチを適用したOpenOCD書き込んだログはこんな感じです。
仕様上ちょっと癖があり接続しに行くと他のデバッガと違ってワンテンポ間が開く
感じで繋がります。そして立ち位置としてはTI-ICDIやSTLink系と同じHLA扱いと
なっております。ですのでAPの直叩きはできないので注意が必要です。
それとCMSIS-DAPのようには最適化されていないのかVersaloonの1/2くらいの
書き込み速度となってますね…今後の改良はNuvotonチームに期待ですね。
SW-DPの直叩き等の低レベルの操作はできないですが通常デバッグで行える操作、
レジスタ、メモリ参照などは問題なく可能です。
これでNuvotonマイコンもフリー環境で使い勝手が大幅に上昇した感じがしますね！
今回の修正を反映したOpenOCDのバイナリはすでにおきぱにありますのでどしどし
使ってください！NuLink対応はまだ公式採用ではありませんがねむいさんバイナリには
すでに適用しております！
また、今回のNuLinkの対応に当たり私がかつて統合したnuvotonドライバで
デバッグ時に一部動作がおかしくなる品種があることも突き止め、それの
修正も加味しております。これについては次回詳しく説明させていただきます！
いろいろ試す34
あああ…夏がおわる…
●GNU Arm Embedded Toolchainが新しくなった夏
忘れたころに更新されることで有名なARM提供のGCCツールチェインが
更新されていました…
日付は6/23版となっています…2018q2版になってますね
下記の修正が入っています。他は大きな違いはないと考えられます。
Important changes in 7-2018Q2 update release:
* Fixed powf/expf/exp2f/logf/log2f performance regression
https://answers.launchpad.net/gcc-arm-embedded/+question/662462
* Added support for Arm Cortex-M33 without DSP via -mcpu=cortex-m33+nodsp
* Added Armv8-R multilib mappings
* Fix build requirements for GDB tui support
* Enabled C99 IO format specifier in newlib
* Fixed cmse_nonsecure_caller Armv8-M Security Extension intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203
* Fix crash in __builtin_arm_set_fpscr GCC builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
* LTO bug https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966
was fixed in previous release. Release note updated to reflect the change.
* Fixed issue with building libgcc's cmse.c without headers
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1717502
* Fixed issue with arm_cmse.h C99 compatibility
https://bugs.launchpad.net/gcc-arm-embedded/+bug/1773934●UHS-�兇離泪ぅ�ロSDカードを動かしてみる
買ってしまった…
日本橋に寄った際に目に入ったUHS-�兇離泪ぅ�ロSDカード…
ねむいさん今省エネモードなのでお金の使い方も省エネで64GBとか買えないので
32GBのSDHCとなっています…
東芝のEXCERIAシリーズの最高峰に位置するM501とかいうモデルです！！！
UHS-�桐僂涼嫉劼�追加されていますね！
SDカードサイズへの変換アダプタもUHS-�胸斗佑箸覆辰討い泙垢諭�
早速ベンチマークをとって見ましたが…ねむいさんのUSB3.0カードリーダーは
UHS-�教�格に対応してなかったorz
ていうわけでUHS-Iの規格ですがチマチマ書き込みもまぁそこそこですし
使い物にはなると思います。
ねむいさんのいつものでカード情報を読み出してみました
FatFs module test terminal for STM32F769NIH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jul 28 2018
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20989 kB/sec.
>ds 0
rc=0
Drive size: 62529536 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 EE 87 7F 80 0A 40 00 53 @..2[Y.......@.S
CID:
00000000 02 54 4D 58 41 30 44 35 44 E2 51 8E B2 01 12 6B .TMXA0D5D.Q....k
Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :XA0D5
Product HwRev :4
Product SwRev :4
Serial Number :0xE2518EB2
DateCode.Month :2
DateCode.Year :2017
OCR:
00000000 E1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 02 90 00 20 07 3E 00 ............ .>.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 84 03 3C 03 47 82 ....<.G.
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :0
SD Security :3
SD Bus Width :5
SD_Spec V4.xx!
Detected as SDHC Card!
Available UHS-II Mode.ちゃんとUHS-�競癲璽匹�あることを認識していますね。
STM32シリーズはUHS-�競癲璽匹離ぅ鵐拭璽侫А璽垢呂泙逝減澆靴討�りませんが
UHS-�競癲璽匹�あるか否かはACMD41コマンドでわかります。
ACMD41を打って還ってくるレジスタの37番目のビットが1ならばUHS-�饗弍�を
唱っていることになります。
●OpenOCDにセキュリティホールがあるらしい
まじかー
OpenOCDも攻撃されるほど有名になっていたのですね〜
一応対応策が提示され、gerritにも上がっているようですが2018年の1月で
審議が止まっているようです
いろいろ試す32
生存確認･･･ッ！！
現在ひたすら過去記事の見えなくなった画像の修正と古くなった内容の見直しを
続けております。海外からの質問は相変わらず容赦なく来てますがそれをかいくぐ
ってわずかの時間を見つけてひたすら修正！修正！
●GNU Arm Embedded Toolchainが新しくなった
昨年秋から四半期ごとに更新が無くなってしまったARM提供のGCCツールチェイン
ですが忘れたころに更新されていました。
たしかねむいさんの記憶では2018年に入ってから更新されて様な気が･･･でもリリース
日は201712扱いですね･･･このままズルズル更新間隔が伸びていって最終的に有償に
なって実質消滅してしまったCodeSourceryみたいにならないと良いのですが･･･
主な更新は"Armv8-R and Cortex-R52 support."だそうです。
新規のCortex-R系コアのインストラクションセットが強化されていますね。
隠れてARM7TDMI系のサポートも続いているようなのでいまだにLPC2388とか
使いたい人も安心です☆
更新ついでにねむいさんのぶろぐの中でよく参照される環境構築記事を2018年度版
変更に向けて準備を始めました。私のPC環境は確定申告の関係で64ビット版
Win7のままなのでWin8以降、特に厄介なWin10は皆さんのレポート頼りなので
期待しています。
●確定申告始めました
ねむいさんも確定申告って奴を始めました。セルフメディケーション税制って
奴の恩恵にあやかるのと将来ビットコとかで大もうけしたときにあわてず
スムーズに申告できるようになるための練習です。
ねむいさんは既に電子証明書仕込んだマイナンバーカードとパソリを持って
いたためブラウザ上で拍子抜けするくらい簡単に申請が出来てしまいました。
ねむいさんの親父が毎年この時期に大量の領収書を傍らにうんうん唸ってた
のを見て育ったのでメンドクサそうだなと思っていたのですが技術の進歩って
すばらしいですね〜
ちなみに虹裏の私のスレでも主張しましたがe-taxの申請画面の最初の奴がカービィ
SDXのセーブデータ全部消えたときの画面思い出してちょっと欝です。
色の順番まで同じとか･･･ああああああ！！！
それとカービィつながりですが今シャクレルカービィとかいうコラボ企画がやってる
ようで死ぬほど笑いました。メタナイトさんしゃくれるとこソコかＹＯ！
●STM32のFatFs移植例月例更新
ねむいさんのぶろぐではどんなに忙しくても意地でも更新している項目が
いくつかありこのぶろぐ記事とあとChaN師のFatFs移植例(通称いつもの)と
OpenOCDのバイナリです。
FatFs自体は昨年10月が最新ですが今年に入って久しぶりにIJG Jpeg libraryの更新
がありそれを反映しています。STM32F7用とSTM32F4用を3月版として既に
差し替えておりますので皆様の参考にどうぞ。
OpenOCDについては必須ライブラリのLibUSBとともに結構いろんな修正が
マージされていますので3月中にでも詳しく解説します･･･。
●ぶろぐのレイアウトちょっとリニューアル中
このぶろぐ今年4月で10周年記念だそうです･･･まじかよ！
この10年でやったこと･･･FatFs移植してから先に進んでない･･･
･･･
orz
それはおいといてこのぶろぐではフリーのブログツールをお借りして見やすく努めて
いるつもりですがいつも使用しているRSSフィードのツールがアップデートしており
そちらに乗り換えました。旧バージョンは乗換えを促すため超デカイ広告が出てしま
うためねむいさんのぶろぐを知る知人が気づいて直接伝えてくれました。
というわけで乗り換えました。今回からスクロール対応です！SNSのアカウントが
必要になりましたが使い勝手やカスタマイズ性は良くなったと感じます！
STM32F7CubeがV1.9.0になった(とSTM32にかかわる話あれこれ)
皆様あけましておめでとうございます。
今月末に急にネムNEMネムって私の名を呼ばれる機会が増えましたが私の魅力に
ついに気づいてくれたのでしょうか？｢｣すら忘れかけているのにちょっぴり嬉しいでｓ
ｹﾞﾌﾝｹﾞﾌﾌﾝ今年も残すところあと１１か月になってしまいましたがわずかな時間を
見つけてがむばらせていただきます！
さて、昨年中盤から副業(本業は虹裏メイド)のほうが超ピークの稼ぎ時でなんと
基本給と歩合給あわせて今までの手取りの3倍ということでマジ超フィーバー状態で
家族のためにSALARYを稼ぐためにとても忙しくなりなかなかマイコンいじりに
割ける時間が取れなくなってしまいましたが、それでもなお沢山の方がとくに
平日日中にもかかわらず多数の方が来てくださっていますので
今後もSTM32を中心に目ぼしい情報を発信していく次第です！！！！！！！！
※ねむいさんのぶろぐは土日のアクセスは平日の1/3以下しかないです･･･
さぼるな！
●STM32F7CubeがV1.9.0にアップデート
今月末にひっそりとリリースされておりました。
今回の変更内容はCANドライバが大型変更となっており過去のHALドライバと互換性
が消滅しているようです。この容赦のない大変更はSDMMCでもありましたがまぁ今
までSTM32を使いこなしている方ならすぐにアジャストできると思います。
既におきぱのSTM32F7のFatFs移植例は最新のCMSISv5ヘッダライブラリとともに更新
しております。どしどしご利用ください！
●STM32H7ついに一般市場に
･･･今更遅ぇえーＹＯ！
すでに廉価版のNUCLEOとフル機能の高価なEVALはでていますがねむいさんはひたすら
Dicovery板待ちです･･･EVALは高すぎでNUCLEOは高速I/Fをバラックで組める自信が
ないしでやっぱし中間的な地位のDiscovery板がしっくり来ます。
しかしながらねむいさんもデータ流し読みしてて気づいたのですが、H7では
DTCM領域をDMAのデータバッファとして使用できなくなり常に内蔵SRAMとの
キャッシュの整合性を気にする必要がでてきてしまいました…。
なんというか本当にもはや"マイコン"ではなく"プロセッサ"ですねこりゃ･･･
けしかん様のブログにくわしい解説が記されております。
STM32CUBEの吐くキャッシュ設定のデフォルトがライトスルーじゃなくて
ライトバックなのハマる人続出でヤバいと思うんですがまぁこういうの触る人は
キャッシュの事熟知しているでしょうから問題ないでしょう☆
そういえばDMAで思い出しましたがアライメント制約って4バイト制約のほかに
AHBバスのバースト転送の1kバイト境界制約もあったと思うのですが誰も気に
してなくってねむいさんもずっと使い続けてて特に問題も起きてないから
なんか大丈夫っぽいですね。たぶんSTM32の中の人が上手いこと処理してくれて
いるのでしょう☆
20230920追：
そしてねむいさんはキャッシュ地獄にはまった…！！！
20230920追:
●STM32CubeProgrammer現る！
STM32の内蔵フラッシュメモリに書き込むためのSTマイクロ謹製のPCツールはいくつか
提供されていてﾃﾝでばらばらの場所にあったのですがそれをすべて統合した奴が昨年
リリースされておりました。その名もSTM32CubeProgrammer!
モノとしてはSTLinkUtility,DFUDemonstrator,FlashLoaderDemonstratorの3つの
ライタプログラムが一つのUIに統合されたものとなっており直感的な操作が
可能となっております。
ちなみにJAVAランタイム必須です･･･
ねむいさんのぶろぐを見ている剛の者ならば入れて当然入って当然の代物ですがまし
てや無いと無音でプログラムが即終了するので最初何が原因か分からず1日時間潰し
たりするような軟弱野郎はこのぶろぐの読者にいないはずですがねむいさんのように
1日時間潰してうろたえないようにJAVAランライムはインストールしておきましょう。
入れるのは32bitJAVAランタイムのほうです。
インストール時にはSTLinkとDFUとSTLinkV2-1用の仮想COMのドライバが同時に
インストールされるのでドライバを探してあっちこっちせずにすむのでとても
親切な作りとなっています。
操作画面はあっさりした構成になっています。
ひとまずSTLink/V2を接続したところです。
なんとSTLinkのファームウェアアップグレードも出来たりしちゃいます☆
書き換えた新ファームのSTM32F4Discovery付属のSTLink/V2で接続します。
もちろん困ったときの助け舟、ConnectUnderResetもありますね！
書き込みは10秒くらいで終わっちゃいます。OpenOCDより早いです。
お次はDFUモードで書き込んで見ます。
使用したボードはねむいさんの液晶表示用のF4ボード(紅牛板に無理やり
STM32F407ZGT6乗っけた奴)でブートモードにして接続すると"USB"として
認識されます。STM32F4は単体でUSBのDFUモードになれるので本当は
ライタいらずなのです。
これも書き込み速度はまずまずのスピードです。
まぁUSB接続ですもんね。
最後にシリアルブートモード接続で･･･
これさすがに遅いですね･･･128kb位なら気になりませんが･･･
や、やっとおわった･･･
まぁ普段使いの場合はSTLinkを経由して使用することがほとんどでしょうから
DFUやUARTブートモードはホントに緊急の場合に使用するくらいですね〜
そんなわけで私が思っていた以上に使い勝手があがったSTM32CubeProgrammer、
MACやLinux系OS用のパッケージも同梱されているので多くのOSで使うことができ
ますのでますます利用者が広がると思います！
あ、JAVAランタイムは忘れず入れましょう･･･
●STM32限定でAtollic TrueStudioが無料で使える！
STマイクロがAtollic社を食べたのでSTM32限定でTrueStudioが無償でフル機能が
使えるようになったそうです！！ARMマイコンのユーザを高機能な有償ツールの
無償化を餌に取り込む攻勢でしょうか、ライセンス的に企業はどこまで無償で使えるのか
どうかちょっと調べ中ですがホビイストレベルならまったく問題ないと思います。
ちなみにねむいさんのばあいは徹底したIDEの皮を被ったコマンドラインビルド環境
なのでTrueStudioとか必要ないだろと突っ込みうけそうですけどTrueStudioも結局は
GCC使っているのでデモプログラムのビルド条件の解析や他の人が公開しているプロ
ジェクトファイルがこれだった場合はやっぱり必要なので食わず嫌いせず必要な
場面で使っていく次第です。
ちなみにねむいさんは素のEclipseで殴られると全身から血を噴出して即死しますが
メーカーお仕着せのまさにTrueStudioみたいな奴ならば死にませんのでノーカンです！
いろいろ試す31(+今年の反省会)
●ねむいさんのもとに工業用SDカードが続々集まってくる！！！
12月上旬、ねむいさんの元にすこし早いクリプレが届きました･･･！
昨年紹介したS.M.A.R.T.(以後SMART)が取れる一般購入可能な貴重な工業用SDカード
のリピート購入です･･･！
そして今回はTG-4用に新手のカードも購入しました。MLCな64GBで、その名もUtility+
です！こちらも工業用の位置づけで工業用SDとしての機能は完備しておりもちろん
SMARTに対応しているそうです。
実際にTG-4に装着してUSBマスストレージから接続してDelkinDashBoardで
見たところです。以前のと同じようにしっかりとマスストレージからでも
SMART情報が取れてますね〜♥
ちなみにベンチを取るとこんな感じでした。
工業用SDカードはデータの確実性を重視しているため読み書き性能に関しては
民生品よりかなり劣るものが多いのですがUtility+はそこそこ頑張ってる感じです。
実際のTG-4で使用したときも速度的な違和感はまったく感じませんでした。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jul 17 2017
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 17484 kB/sec.
>ds 0
rc=0
Drive size: 125370368 sectors
Erase block size: 131072 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 01 DE 3F 7F 80 0A 40 00 9D @..2[Y...?...@..
CID:
00000000 58 44 44 44 44 49 4E 43 30 00 03 96 E1 01 02 FF XDDDDINC0.......
Parsing SD CID Register
Manufacturer ID :0x58
OEM/Application ID :DD
Product Name :DDINC
Product HwRev :3
Product SwRev :0
Serial Number :0x000396E1
DateCode.Month :2
DateCode.Year :2016
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 F0 02 00 AB 3F 00 ..............?.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 03 01 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Spec Version X :0
SD Security :4
SD Bus Width :5
SD_Spec V4.xx!
Detected as SDXC Card!
Available UHS-I Mode.今度はSTM32F4のいつものでSDカードの情報を読み出してみました。
2016年製ですね。
CMD56で読み出したところです。SMARTで取れるデータのフッタが昨年の
U331と同じようにCIDと同様の値が記述されてますね。
こんな感じでトレラン用のタフなデジカメにふさわしいタフな工業用SDカード
Utility+の組み合わせでこれからも厳しいフィールドを攻め込んでいきます！
●第三の刺客！SanDiskの産業用SDカード突如現る！
ねむいさんノーマークだったのですが2017年の初秋に一般のPCパーツショップで
SanDiskの産業用SDカードが安価な値段で出回っておりました。
こういったSDカードは一般に流通することはまれなので何らかの企業の大量購入品の
在庫処分でしょうか？なにはともあれありがたいことです。
容量のも8GB〜64GB品があり32/64GB品は日本の正規代理店のパッケージ販売
なのでSanDisk特有のぱちもんの心配もほぼ無いかと思います。
出遅れた感じでしたがねむいさんも16GB品を入手せしめる事ができました。
SDSDQAF-016G-Iという型番です。
速度はUHS-Iに対応していますがまぁ良くある工業用グレードの速さですね〜･･･
Utility+が早すぎるだけで工業用途にはこの速さで十分というところでしょうか。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jul 17 2017
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19279 kB/sec.
>ds 0
rc=0
Drive size: 31116288 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 76 B2 7F 80 0A 40 40 13 @..2[Y..v....@@.
CID:
00000000 03 53 44 53 4C 31 36 47 80 61 6D 11 B0 01 15 63 .SDSL16G.am....c
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SL16G
Product HwRev :8
Product SwRev :0
Serial Number :0x616D11B0
DateCode.Month :5
DateCode.Year :2017
OCR:
00000000 C1 FF 80 00 ....
SD Status:
00000000 80 00 00 00 04 00 00 00 04 00 90 00 0F 05 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 01 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!
Available UHS-I Mode.
SDカード内の情報を拾ってみました。
なんと2017年5月製ですよぅ！しかもFatFsからの読み出しに関してはUtility+より
早いです･･･！
ところでねむいさんはいかに工業用といえども無闇に買うわけではありません。
このSanDiskのカードはなんとDelkin製のやつのようにSMART情報を取れるのです！！
Delkinの奴のように細かい情報は取れないのですが皆さんも気になる｢寿命に関する
ステータス｣は取得可能なのです！！！もちろん投げるコマンドはCMD56!
(※投げる引数はDelkinのとは違い0x00000001です･･･てか統一しようよこれ)
し か し ･･･
↑CMD56投げたところでデッドロックしてるorz
流出しているSanDiskのマニュアルをよく見ると8GBと16GB品の第一世代は
SMART積んでませんと明記されていた･･･32GBと64GBから･･･だと･･･
しかも32GB/64GB品はSDSDQAF"2"-032G-Iってなってて第2世代カードっぽい･･･
SMART積んでるの第二世代以降ですね。
(注：すでに第3世代のカードが流通しています。DigikeyやMouserで購入可です)
仕方が無いので32GB品の第二世代の奴売ってる店探してゲッツしてきました！！１！１
速度は･･･UHS-Iでは無くClass10なので読み書きともMAX約20MB/Secです･･･
でも書き込みはさっきの16GBと比べてダンチだからまぁいいですか･･･
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Jul 17 2017
>fg piano
rc=0 FR_OK
>do 1ftbt.mp3
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16925 kB/sec.
>ds 0
rc=0
Drive size: 62333952 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 ED C8 7F 80 0A 40 40 C3 @..2[Y.......@@.
CID:
00000000 03 53 44 53 43 33 32 47 80 3D 76 40 13 01 13 7F .SDSC32G.=v@....
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SC32G
Product HwRev :8
Product SwRev :0
Serial Number :0x3D764013
DateCode.Month :3
DateCode.Year :2017
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 0F 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!
Available NS(or HS) Mode Only.お約束のSDカードの情報も拾っておきます。
こちらも2017年製ですね〜
お次はSTM32F7のSDMMCからCMD56を投げてDelkinみたいにSMARTが
取れるかどうか！いざ勝負！！
･･･！
帰ってきた512バイトのデータの中に｢SanDisk｣の文字が！！やった！！！！
ちなみに寿命を示すHealthStatusは9バイト目に相当します。
すでに1%使用されてるように見えますがこれはそうではなく｢0~0.99%消費された｣
ことを表すと記されています。
この値が100になったらデバイスはそれまで書き込んだデータを破壊しないように
読み取り専用になりデータ破壊から保護するそうです。
残念ながらSanDiskの奴はDelkinのようにUSBマスストレージからでもSMART取れる
仕組みはありませんがそれでも寿命推定ができるのは心強いことだと思います。
Linux系OSで物理バスにぶら下がったSDMMC持ったボードならCMD56直たたきで
見られるのでラズパイなんかでも活躍できると思います。
そんなわけで今年秋にPCショップで32GB/64GBのSanDiskの第二世代産業用マイクロ
SDカード買えた皆様、おめでとうございます！あなたのカードはSMART取れます！
逆にけちって8/16GBの第一世代の奴買っちゃったあなたはご愁傷様です･･･
まぁSMART取れないだけで物としてはバッチリ使えるのでしっかり
使い倒しまくってください！！！１１！！！
20180111追:
今度は32GB/64GBのバルク品が秋葉で販売しています！！が！！
型番から見て分かるようにこれは第一世代のSMARTが無いタイプですので、
SMART目当ての方は購入をしないよう注意してください！！
SMART積んでる奴はSDSDQAF2-***G-Iの第二世代以降の物です！
20180111追:
●ところでSPI互換モードでCMD56って効くの？
ねむいさん今まで組むのが容易なSDネイティブモードからしかCMD56の発行をして
いなかったのですがSPI互換モードからはCMD56は有効なのか？
年の瀬も迫るなかでねむいさんが公開しているFatFsの実装例、通称｢いつもの｣の
SPI互換モード用のSDカードドライバにCMD56を追加してみました。
ちなみにCMD56はSDネイティブモードではカードのイニシャライズが完了し
実際にカード内のデータの読み書きができるCMD17とかCMD24とかのコマンドが
通る状態になれば同じように使えました。SPI互換モードではステートマシンは
無いのですがとりあえずネイティブモードの挙動をまねてイニシャライズが
完了した直後にCMD56を送ってみました。
Delkin製はネイティブモードと同じく読み出しできました。
SanDisk製の奴も問題なく読み出しできました。
ねむいさんが確認した限りではCMD56はSPI互換でも問題なく通るのが確認されました。
一般的な電子工作でもSMART対応の工業用/産業用SDカードの恩恵をしっかり授かるこ
とができますね☆
ただし工業用でもSMART非実装ものや民生用の奴だとSPI互換モードでもやっぱり
フン詰まりになったり0xFFしか帰ってこないという結果になっています。
SMART取得を前提としてファームを組むならそのカード専用のドライバを作成する
ほうが無難かと思います。やはりねむいさんの希望はCMD56によるSMART情報取得が
規格化されて民生用でもSMARTが利用できるようになることです。
大事なことなので前回に引き続き2回アピールしました。
●毎年恒例反省会とねむいさんFAQ
Q:電磁波が飛ばします。受けとれっ(ﾋﾟｯ
A:ねむいさん昨年末から早々に手をつけて即効飽きてほったらかしにしたESP32で
すが電磁波を扱っているせいかqiitaとか増田さんじゃないほうのはてなで技術
風ぽゑむ書かれている方から(qiitaやはてなを利用している人たちはほとんどが
まともな方でごくごく一部の人間がそういう特殊行動やってると信じたいですが)
の抗議風自慢と思われる｢だからお前結局何が言いたいねん###｣といいたくなる
怪文書いただくことが度々ありましてねむいさん最初は｢大変申し訳ありませんで
したー！｣という内容(日本語訳で｢バーカ｣に相当する)の返事をしていたのですが
社交辞令を真に受けたのかはっきり｢バーカ｣といわないとわから無いのか知りま
せんが図に乗って私に無償で協力しろという方もいましてああもうこれかかわった
時点でねむいさんの負けだなと感じて以後はそういう奴は存在しなかったことに
しておきました。ねむいさんからはもう何も見えない。
そんな事がありましてプロフィールの免責事項もちょっとお堅い内容に変えて
おります。ついでに自分の襟も正して過去の自分の記事も読むと混乱するような
変な内容や読んだ方に悪い印象を与えるような表現は正すように常に心がけてお
ります。
Q:(粋な写真もｽｲと添えつつ)しまかぜに乗って鳥羽まで行きましたよ☆
A:よかったですね＃＃＃
ねむいさん近畿自然歩道の攻略で何度も近鉄に乗ってますが今に至るまで
一度も乗れたことありません＃＃＃＃
閑散期の平日狙えば少しはチャンスがあるのでしょうけど･･･
Q:(学生さんと思われる方から意図をぼかしつつ)｢***のソースコード書いて
ください！！！！！｣｢***の回路図を描いてください！」等々･･･
A:メールのアカウントから推定して即効あなたのﾋ垢を見つけましたが
まだ若いのに性癖全開なのは非常に期待が持てｒ･･･
ｹﾞﾌﾝｹﾞﾌﾌﾝちょっと引きますよぅ･･･
上の質問はちょっと極端ですがねむいさんより偏差値が20くらい上の子達から
ねむいさんの知能を大幅に超える難しい専門的な問い合わせもびしばしもらうので
すがねむいさん脳細胞どんどん死滅していっていないさんの今日穿いてるぱんつ
のことしか考えられなくなっていく段階なのでもうちょっと手加減してくだち。
Q:フルブリッジドライバの下段アームのFETだけ壊れるんですけど
壊れないようにしてください！！(←急遽当日になって)
A:(こいつまたかＹＯ！)ええいうるさい
ゲートに抵抗でも入れてなさい！！！！
Q:スマホから見たら画像の読み込みばっかでめっちゃ通信量食うんですけど
A:ね む い さ ん ま だ ガ ラ ケ ー Ｄ Ｅ Ａ Ｔ Ｈ ！
Q:ていうかそろそろねむいさんもスマホに換えましょうよ
A:実際どうしましょうかねぇ･･･キャンペーンがあったらガラホにでも
移ろうかと思ってます。
Q:(パッチアンテナの面を地面に向けるように実装して)Gms-g9ってたいした捕捉
性能ないっすねｗやっぱりu-bloxっしょ！(ｲｶｽ思想に取り憑かれた顔で)
A:(正気でやってるのかこれ･･･怖い･･･)
が、眼科行った後メンタルヘ！
Q:ウ ン チ ー コ ン グ って知ってるぅ?
A:ウンチーコング･･･それはﾎﾟﾒﾗﾆｱｯｸ繊細空間が展開されたときのスレッド内の
住人同士の仲が険悪になりﾚｽﾎﾟﾝﾁバトルが勃発せしめんとした際に発動して
5cmにﾎﾟﾒﾗﾆｱﾝ出来たことにより無益な戦闘によって血を流すことを避け場を
清らかに鎮めるための対繊細特化型概念である。こと虹裏においては平和的
に発動される概念だがほかのコミュニティにおいては猿系のキャラクターが
戦いにおいて敗北した際にギャラリーが連呼して敗北者にさらに精神的にダ
メージを負わせるといったまったく逆の概念で使用されていることもあるの
で留意すべし。また、冥府神がほかのキャラクターにその意味を無闇矢鱈に
問うといった意味不明の行動も見られたがこれは第0話にて彼の行動の真実が
明らかになっている。話を虹裏に戻すと猿空間においては｢座敷犬(ポメラニ
アン)のくせに獅子(ライオン)の気持ちなんてわかるわけねーだろっ！｣
というせりふとともに顔面パンチをｺﾞｯされる場面が見られ、ウンチーコングを
発動するまもなくﾎﾟﾒが処分される技術も確立されだしている。
やっぱりかませはかませだった。
Q:｢ねむいさん｣で検索するとサジェストに必ず入院とでるのですが何か大病でも
されたのですか？
A:私のこと病院送りにしたい奴らの単なるサジェスト汚染ですね〜！多分
まぁ｢ねむいさん FX 必勝法｣とかでないだけ幾分マシですが･･･
Q:画像が見えなくなってる昔の記事の画像も早く復活してほしいのですが･･･
A:(う"･･･今年秋から差し替え作業サボったままだった･･･)
ぇっとあのその来年もがむばります！！
STM32F7を使ってみる19 -CubeF7がv1.8.0になった-
9月も終わりを迎え、ようやく涼しくなってきましたね。
ねむいさんはここ数年は初夏〜晩秋にかけては登山や自然歩道攻略にリソースを
全振りしているのでこちらのぶろぐはなかなか更新するネタが無いのですが、
OpenOCDやSTM32のトピックは常にチェックしておりますのでご安心ください。
さて9月の下旬にSTM32F7Cubeが更新されV1.8.0になっております。
それに伴いCubeF7の中核をなすHALライブラリも大幅更新となっていました。
大きな変更はソースコード中にソースのバージョン表記が一切なくなったこと
です…なぜこのようなことにしたのか理解できないのですがこれあとあと面倒な
事になりそうでちょっと心配です。特に公式のフォーラム上でくだらない漫才が
繰り広げられそうで私はちょっと戦慄しております。
あとはコールバックや割り込みハンドラの細かいバグ潰しでこちらもそれほど
致命的なものではないようですね。実際にCubeF7V1.7.0のHALライブラリと直接
差し替えても特に動作に支障はなかったです。
USBライブラリのMSCのアレについては相変わらずバグったままなので注意して
ください。scsi_blk_addrのuint32_tをuint64_tにしておくのを忘れずに。
それとBSP関連が結構変わっており手を加えないといけません。
私のいつものサンプルにおいてはSTM32F769-Discoではotm8009のドライバを使用
していますがV1.7.0まではランドスケープ(800x480)だったのがポートレイトに
(480x800)なってしまっています。ひとつ前のに戻しておかないと表示も入力も
めちゃくちゃです！これに関してはotm8009.hの定義を元のV1.7.0のやつのに
戻すことで対処。
それともう一件はmp3等のサウンド再生用の関数でこれまたSTM32F769-Disco上に
搭載されたcodec、wm8994を駆動するための初期化の関数内で微妙な改変が行われ
ておりそのままではヘッドフォンから音が出力されなくなってしまったことが
判明しましたorz。(STM32F746G-Discoも同様です)
これについては私が作成してた上位関数があるmp3_support.c,aac_support.c,
そしてwav_support.cのEVAL_AUDIO_Initの第一引数をOUTPUT_DEVICE_SPEAKER
からOUTPUT_DEVICE_BOTHにすることで対処しました。ほんとはこれが正しい
記述だったのかな！？
と言うわけでCubeF7V1.8.0を適用し上記の修正を加えた今月分のいつものの更新
を行いましたので皆様どしどしご利用ください。
ちなみにARM提供のCMSISのヘッダファイルはCubeF7梱包の奴は使用せずgithubで
日々更新されているその時の出来たてﾎﾔﾎﾔの奴を適用しています☆
F7のサンプルに限らず他の品種にも時間が空いた時にこのCMSISヘッダファイル群は
まとめて適用して更新しておりますのでSTM32に限らず他のCortex-Mx系のARM
マイコンを使用されてる方にも恩恵があると思います。
ここまで書いて思い出しましたが一般信者へのリリースが待ち焦がれている
STM32H7について、CubeH7ライブラリは実は既にお披露目となっていました。
STM32H7のSDIOはなんとUHS-1対応となりましたがリファレンスマニュアルを読むと
動的にI/O電圧を内部で切り替えられる機構はなく専用のトランスレータICと組み
合わせて制御する仕組みとなっています。Discovery系のボードではさすがにトラ
ンスレータは乗ると思いますがNucleo系はちょっと予算的にも信号の精度的にも
難しそうですね。一応トランスレータ無しの3.3Vオンリーなら従来のNS(25MHz)と
HS(50MHz)はサポートしてるのでホビーならこれで十分ですけど。
この辺H7のさらなる進化でUHSモード時のI/O電圧動的切り替えがチップ内部で
出来るようになってくれると嬉しいですね〜
STM32F7を使ってみる16 -USB-MSCを使ってみる応用編-
前回はSTM32F7のSDMMCインターフェースを用いてDELKINの工業用SDカード
からSMARTの情報をCMD56コマンドを駆使し読み出す事に成功しました。
その前にUSBカードリーダーに直接DELKINのカードを接続した時はDelkinDashboard
なるWindowsアプリを用いるとSMART値を読み出す事が出来るのを確認しています。
そこで今回はUSB接続のカードリーダーに化ける奴でDashboardが使えるかどうか、
いくつか試してみました☆
1．OLYMPUS STYLUS TG-4
->SMART読み出しOK!
TG-4はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです！
２．STM32Primer2 GNSS Tracker(のUSB-MSCモード)
->SMART読み出しOK!!
いわずと知れたSTM32Primer2を用いたねむいさんのぶろぐ唯一の実用品です。
2009年から今に至るまで8年間、-10度〜+40度の過酷な環境を耐え抜き延べ3000km
以上の山道をねむいさんと共に駆け抜けてきたすごい奴です！
３．STM32F746G-Discovery(のUSB-MSC(HighSpeed))
->SMART読み出しOK!!
とりあえずSDカードが読めるUSBカードリーダー(USBマスストレージクラス)なら
何でもいけるような気がしてきましたよぅ･･･
"１．"はともかく"２．"と"３．"についてはUSB-MSCに明示的にCMD56を発行する
ようなルーチンは実装していなかったのでこれはつまりCMD56を用いなくても何か
別の方法でSMARTを読み出せられる手段があるのではないかと考えました。
そこでSTM32F746G-Discoveryを使って何が起こってるか解析してみる事にしました。
USB-MSCのSCSIコマンドを解釈するサブルーチンとSDMMCのRead/WriteにPrintfの
トラップを仕掛けどのSCSIコマンドが発行されているか、またSDカードのどの
アドレスに読み書きを行っているのかを調べます。ファームウェアを柔軟に弄る
事が出来るという市販のUSBカードリーダーでは絶対に出来ない利点がSTM32F7には
あるのです！！
STM32F746G-DiscoveryのSTLinkV2の仮想COMを開いて待機しておいた上で
Dashboardの"GO"ボタンを押すと全てが分かってしまった･･･
諸般の事情で細かい解説は省きますがある一定の順序でSDカードの特定の
ブロックアドレス群に読み書きを行う事によりCMD56による取得方法と同じ
SMART情報を得られることがわかりました･･･！
これなら特別なハードウエアを用意しなくても市販のUSBカードリーダーさえあれば
気軽にSMARTとかSDカードの寿命を確認できますね〜！
それを組み込んだこいつも更なる進化を遂げてさらに最強に強まることが出来たので
ねむいさんはこれからの近畿自然歩道の攻略に向けて燃えに燃えています！
20170308追:
このような工業用SDカードの寿命診断についてですが実際は頻繁なカードの
取り外しが困難な場所や機器に特に威力を発揮します。
性悪説的に言うとケーシングや樹脂化でSDカードを完全に隠ぺいし第三者から
"SDカードを使用している機器"と分からなくして"何らかのメモリデバイス"と
して見せることにより商売上でSDAのライセンス条件を完全に逃れている場合の
リモートメンテナンスの際にも役立ちます。
正攻法でもCMD56なりUSB-MSC経由でSMART取ればいいので品質管理の面から見て
仕事が進めやすくなるのでメリットだらけですね〜♥
20170308追:
でぢかめ向けには大容量品があるUtility+がよさそうですね。これも上記と同じくCMD56&
Windowsツール経由でSMART取れるので特にカードの寿命や動作環境を気にする
プロの人必須のアイテムだと思います。ねむいさんもお金に余裕が出来たら購入して
TG-4と併せて使った感想をレポートしてみたいと思います。
ちなみに民生品のSMART非対応のカードだと失敗しちゃいます。
TDKやApercer配布のSMART取得ツールだと非対応のカード使うと先頭1kb分のデータが
問答無用で破壊されてしまうのですがDelkinDashboardではそういうことはまったく
ありませんが興味本位で非対応のカードで試すのはやめておきましょう！！
とまぁこんなかんじで各メーカごとにSMARTの仕様がバラバラなのでSDAが早く統一
規格作るべきだと思いますよぅ。
さらにおまけですが･･･
解析途中でDELKINカードのパーティションの全容量と実容量が一致してなくてディスク
ユティリティーソフトが異常を検出してておかしいなと思っていたのですが･･･
STM32F7CubeのSDカードドライバ(v1.5.xまで)はSDHCにしか対応してなかったため
SDv1の初期化コマンドすらなかったのは周知のとおりですがUSB-MSCのサンプルも
その仕様を引きずっていたため正しい全容量を返していないのが分かりました。
20170329追:
SDv1どころかSDv2でも正しい全容量を返していないことが分かりました。
別な部分で一番最後の論理ブロックアドレスを示すよう-1している個所があり、
上記の部分で-1してしまうと余分に-1したことになるので実容量より1ブロック
分小さい値が返されてしまいます(ほとんどの場合は512Byte小さい値)。
具体的にはusbd_msc_scsi.cのSCSI_ReadFormatCapacity()で総ブロック数から１を
引いた数をホストPCに送っています。
一方SDHC/SDXC等の大容量のSDカードなら多少の容量の相違は無視できる
ほど小さいので問題はありませんでしたが、Delkinカードは1GBしかないため
ParagonHardDiskManagerではそれを見逃さず無効なパーティションと
見なしたようです。ちなみに値が微妙にずれた状態でもWin7からは普通に
読み書きできてました。
SDナビさん曰く、この値が容量偽装とかでズレが大幅になるとWindowsも
おかしいと検知してフォーマットを促すダイアログが出るようです。
20170329追:
そういえば今年になってv1.6.0が出てSDカード周りが刷新されたのですが待望のMMCが
追加されたのはｲｲのですがなんかいたるところが欠陥だらけで超やばいことになって
いたのですが話が長くなるので次回に続きます･･･
ESP-WROOM-32を使ってみる5 -ESP-WROOM-32が物故割れた！１！１！！-
ESP-WROOM-32の目次に戻る
ESP-WROOM-32はとっくに飽きてしまったの筈なのですがKimio Kosaka氏のブログ
にてとてもとても気になるエントリを見つけました。
以下引用
色々なタイミングでのプログラムの書込みをやっていたら…ESP32挙動不審な動作を
はじめ、” flash read err, 1000 “が出現しプログラムの書き込みにエラーが
発生するようになった。
引用終り
もう一つ、wakwak_koba氏のブログでも････
以下引用
WiFi.h を include するだけで、漏れなく halt してしまう ESP32 に成り果ててしまいました(涙)
やったことは、2.2〜2.8V 付近の電圧で起動と停止を繰り返しただけ。(それぞれ数秒ずつ置いて)
電源の逆接とかハード的なミスならば自業自得で諦めますが、仕様範囲内の電圧で起動しなくなるってのはどうよ。
動作中に電圧を弄ったとは言え、Δ0.1V/秒 くらいの、超ゆっくりな操作だったのに。
（ハードな試験をしていたわけでもなく、実運用中にも起きえる程度の動作条件下で壊れた）
引用終り
やっぱりねねむいさんそう思ったんですよぅ電源がドロップして動作保障電圧の2.2V
どころか3.0V以下になると何か変な動作になるんじゃないの･･･って
両氏に共通する事象はESP-WROOM-32が意図せず不可逆変化を起こした
ことに尽きます…！！
ESP-WROOM-32のメインチップESP32にはeFUSEと呼ばれるメモリ領域があり、ここに
MACアドレスやChipのID、さらにJTAGやSDIOの使用可・不可を設定できるように
なっています。AVRのヒューズビットやKinetisのFSEC領域のようなものですね。
これが何らかの原因(SPIフラッシュ書き込み時の急なドロップ・電源断)で不意に
書きかえれてしまうとヤバイ方向に転がってしまうのではないかと考えました。
何か電源の不安定な変化でeFUSEの秘孔を突いてしまうのではないか･･･ﾄ･･!ﾋﾟﾌﾟｰ
Kosaka氏はESP-IDFv2(もうv2になってるのか)にあるespsecure.pyなるpythonスクリ
プトで復帰を試みました。ねむいさんもまずは健康な状態のESP-WROOM-32のeFUSEの
値を読み出しました。eFUSEの値は下のコマンドでパースされます(COM3の場合)。
ねむいさんの解説を読んでESPTOOLのパスは通しておいてください。
また、全てUARTブートモード下の操作となります。
espefuse.py --port COM3 summary
まだ健全なモジュールなので全部ゼロになってますね〜
Flash encryption mode counter の値は0です。
さて、ここからESP-WROOM-32を潰しにかかります！！
基本のLチカのプログラムを書き込んでる最中に給電元のUSBのケーブルごと引っこ
抜いて書き込みを故意に失敗させまくります。
この時は上記のようなエラーになります。昔はPCごとお堕ちてたもんだ〜。
ちがう･･･これじゃない･･･
強化した電源ラインが仇になったのかなかなか事象が再現しません･･･
試行すること2時間と20分･･･
―――――――――！
秘孔突いた！ﾃｰﾚｯﾃｰ
(flash read err, 1000)ってメッセージで無限ループしてます。
(実際はhaltがかかってその後ウオッチドッグリセットで無限ループにみえる)
たしかにSPI-ROMの書き換えが出来ないです･･･
20170220追：
Kosaka氏と同じエラーメッセージ出てますが氏の元で発生した不具合は
ねむいさんとこと違ってSPI-ROM完全破壊状態のようです…☠
そんな故障モードもあるのか…
20170220追：
20170521追：
Facebookで私の記事に対し｢eFUSEのプロテクト外したから化けたんじゃね？｣
という指摘がありましたが私は何も触ってないまっさらの状態で試しこの
現象を確認しました。SPIROMの書き込み動作中の電源断で何故eFUSEが化けたか
は深いところまで調査を詰めてないので保障は出来ませんが中途半端に低い
電源電圧がその原因の一つにあることは間違いないです。
逆に言うと電源さえしっかりしてたらeFUSEが化ける確率をゼロに近い値まで
大幅に引き下げる事が出来るのですが････
ねむいさんが何故ADP3338選んだかを無視して｢***さん(←何故か別の人)お勧めの
ADP3338とか値段高いから中華通販で買った1117系のLDO使いました（＾＾）
高価なLDO使わなくても大丈夫だと"思います"｣とか言う人まで出る始末で
ちょっと頭痛がしてきましたがなんというかmgo-tecさんのブログで私がコメント
した通りの展開になってきてますがまぁ売り物作るわけじゃないから自己責任の
範囲で当人が満足すればそれでいいんじゃないかな〜と思います♨
尤も本当に困って私に泣き付いたときにはESP8266の時も遭遇しましたが私は
何聞かれても｢馬鹿野郎｣としか返答しませんのであしからず。
ていうかこのwifiモジュール関連はどうもいつもと違う客層であんまし素性が
よろしくない山師みたいな輩や連中ばっかりわらわら寄ってくるので以後は
一切のご意見無用といきたいところです☠
20170521追：
ここで落ち着いて復活の呪文を唱えます
espefuse.py --port COM3 burn_efuse FLASH_CRYPT_CNT
Flash encryption mode counter の値は1→3になりました。
makeの際にsdkconfigのsecure boot configurationの項目でdisable encryptionに
なってることをしっかり確認してビルドしなおします。
やった！書けた！もちろんLEDは再び点滅をするようになりました。
無事復帰しました･･･
･･･といいたいところですがこの復帰動作は何度も出来るわけではなく制限があり、
Flash encryption mode counter の値が7の状態でもう一度復活の呪文をとなえたら
秘孔が炸裂して"Bricked(ひでぶ)"してしまいます。お前はもう死んでいる
ねむいさんの英語力は中学生レベルですのでかなり怪しいですが原文を読む限りは
復活の呪文を3回となえたら4度目はないと思ったほうがよいですね。
公式のgithubやESP32のForumでも話が持ち上がっていますが結構な確率で意図せずに
この状態に入ってしまうのでしょうか？？？ねむいさんも"電ぶち"で再現させまし
たがこれ貧弱な電源使って書いた貼ったしてると秘孔突き捲ってしまうのでは･･･
とくにVCCが2V付近でうろちょろするような状態がかなりやばそうです。
･･･
でもまぁいっか！あと半年くらい待てば安定するでしょう･･･
それまでSTM32F7で遊びますよぅ！
新しい事が分かったらちゃんと追記修正していきますか怒らないで〜♥
STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-
あれ？ESP-WROOM-32が秋月から発売されて絶好のチャンスなのに
ESP-WROOM-32の記事書かないのですって？
あああれね…去年の時点で飽きました･･･今更になって弄ってるとか時代遅れ
ですよぅ！(挑発
今回はS.M.A.R.T.(以下SMARTと記載)対応のSDカードからSMART情報を読み出して
みます。別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なので
しばし御静観願います。
今回もSTM32F746G-Discoveryを使います。
工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが
存在しております。残念ながら一般に購入出来る民生向けSDカードではその
ような機能は搭載されておらず、SMART対応どころか工業用SDカードも入手が
ごく限られております。もちろん値段も民生品に比べ極めて高価です。
なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからに
つきます。皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が
無い限りはTLCタイプのNANDフラッシュメモリが使用されており、TLCという
のはSLCやMLCに比べて大容量が取れる割にデータ保持のための寿命が短い、
また書き換えできる回数も極端に短いという代物となっております。
一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており
(容量を犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが)
さらにSDカード内コントローラのファームウェアもデータ保護に特化した
特別となっております。たとえばECCチェック機能とかパワーダウン
プロテクションとかオートリフレッシュ機能とかバッドブロックマネージメント、
ダイナミック+スタティックウエアレベリング等々いろいろありますが、実は
これTLCカードを世に出すために必須の技術でそれが耐久性がもともと高い
SLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。
というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、
各社でSMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売
されております。
で、われわれホビイストが問題となるのはその工業用SDカードの入手から
始まりさらにSMART情報を取得するための"情報"を入手し利用せしめるまでに
多くの壁があることです！
まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が
日本国内からではまず困難で、さらにSMART対応と謳っていてもカタログの
隅っこに(※オプション対応)とか書いてあったりして高い金出して購入したのに
目当てのSMART機能が実は搭載されてなかったとか悲惨なことがほとんどです。
それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段や
ツールは公開されておらずメーカに直接問い合わせることになりますがほとんどの
場合対企業間の問い合わせにしか対応してなかったり(もちろん個人事業主として
問い合わせてもTHE・シカト)、SDAのライセンスに加入していないと情報を
渡すことができないよなどつっけんどんの反応しかもらえません。
ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果て
ていましたが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている
代理店が日本国内に存在しておりました。こちらは在庫があれば
一枚から対応(無ければ受注生産20枚単位)というホビイストにもうれしい
対応でしたので早速1GB品を注文し、ゲッツしました。
でかいDELKIN箱に小さいMicroSDが対照的です。
今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております！
なにルネサスより先に死んでんだよ東芝！！１１！１１！！１！！！！！！
動作温度範囲もやたらと広くて-40~+85度まで保証しております。
ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました
規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。
SMART情報をPC経由で取得するために"USBカードリーダ"を用いて
"DELKIN DashBoard"なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事に
SMART情報を読み出すことができました。やったぜ！
どういう理屈でSMART読み出してるかしらないけど(伏線)
ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは
上記のねむいさんのもってるTranscendのと全く同じチップが使用されてます。
お次はSTM32を使って動作させてみます。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Dec 6 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14338 kB/sec.
>ds 0
rc=0
Drive size: 1947648 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m
CID:
00000000 58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I
Parsing SD CID Register
Manufacturer ID :0x58
OEM/Application ID :DD
Product Name :DDINC
Product HwRev :3
Product SwRev :0
Serial Number :0x6D6DD459
DateCode.Month :12
DateCode.Year :2016
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 25 80 00 01 00 00 00 .%......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :2
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDSC Card!
Available NS(or HS) Mode Only.
>
先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製！
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。
そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります！
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を
用いてSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで
門外不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言している
ためかなりフレンドリーと感じます。
この"CMD56"は引数によってデータの受信送信を変えることができるコマンドで
CMD17等のシングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。
↓
DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが
対価を払って得た情報ゆえこのぶろぐ上で詳しく公表できません
が…
…おや？このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み
詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分の
データがCIDの情報と一致しておりました。何かのvalidationに使うので
しょうか???????(棒読み
まぁあまり重要な情報ではないでしょう(伏線
このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガーの
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモード
でもDelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深
願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。
だからSDAの中の人のPanasonicさん頼みますよ！
なぜか不自然なくらいﾊﾟﾅ推しのねむいさん。
ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ！
A:
SLCってカードにでかでかと書いてあるカード選べばＯＫです☆
STM32F7を使ってみる14 -HS ULPIでUSB-MSCを使ってみる-
みなさまあけましておめでとうございます
今年もねむいさんほか虹裏メイドたちをごひいきにm( )m
今年はねむいさんのイラストが100枚くらい増えますように
↑本音
さて新年早々ですがHALライブラリにバグを見つけたので解説しようと思います。
遡る事約一ヶ月前、ねむいさんはSTM32F7で新しい事をやろうとCubeF7に同梱されて
いるUSBライブラリとそのExamplesたちに手をつけ始めていました。
STM32F746G-DiscoveryにはULPIとかついているのでUSB-MSC(MassStorageClass)の
実装を試みました。もちろんUSBのバス速度はHighSpeed(480Mbps)です。
幸いにもSTM32F746G-Discovery向けのサンプルコードもあったのでそれを
ねむいさん謹製のいつものをベースに実装しようとしましたがUSBライブラリが
DMA使ってるくせにキャッシュの事全然考えてない作りでそれにブチ切れながら
GCC向けに移植していましたが最終的にL1キャッシュがないと足を引っ張る
SRAM1,SRAM2を使わずにノーウエイトでアクセス出来るDTCM領域だけでがんばる
ことにしました･･･orz
Ac6STM32用のプロジェクトファイルのリンカスクリプトもそうなってますし
･･･フォーラムでも奇跡の積み重ねで動いてると情けない指摘を
されています。HALライブラリみたいなバグだらけの変なものリリースしっ放し
にしてないできっちりバグつぶせYO!
☝って言ったらたくさん非難されていっぱい哀しい…
と言いつつも何とか動いて認識しました♥
もちろんeMMCとかもしっかり認識しちゃいます★
とおもったらまだ問題がありました…幾つかのカードでデータが正常に
読み込めない事がありました。
64GBのカードでも容量はしっかり見えてるんですけどね…なんか4GB以上
データを詰めてるカードで動作がへんなのです…
…
…4GB…？これって…
かつてUSB付きのARMマイコンでMSCのサンプルではカード容量を示す変数が
uint32_tで現わされていて4GB以上の容量を正しく表示できないという
4GB問題がありました。対策は単純に容量を示す変数をuint32_tから
uint64_tへ変えるだけのものなのですがUSBライブラリを見る限りでは
それはちゃんと64ビット変数になっており問題がありませんでした。
しかしブロックアドレスにブロック容量を掛け算し代入してやがる式を
見つけました。指定するブロックアドレスによってはuint32_tで扱える
範囲を超えてしまう可能性があります。このscsi_blk_addrって奴なのですが
まさか…まさか…
ﾃﾞﾃﾞｰﾝ
…
思いっきりuint32_tじゃん…
…
ば っ か じ ゃ ね ぇ の ！ ？
ねむいさんのむなしい叫び越えが夜の闇にこだまする。
ていうわけでscsi_blk_addrをuint64_t化すると4GB以上データ詰めている奴でも
正常に読み書きすることができるようになりました…なんちゅう初歩的な。
一応フォーラムにも報告しておきましたがSTM32フォーラムのguruと呼ばれている
clive師より｢ブロックアドレスをいれた変数にバイトアドレスに変換した値を放り
込むSTの昔っからのコーディング姿勢自体が愚。scsi_blk_addrの安易な64bit化は
不必要」と指摘されましたがねむいさんもごもっともだと思いました。
そんなわけで漸く正常に繋がるようになったので読み込み比較です。今回は
USBの転送用に確保していると思われるバッファの容量を増やすことで転送
スピードがどこまで変わるか見てみました。
条件STM32F746G-Diacovery,USB-HS ULPI,最適化オプションは"-s"
132MBのmp3ファイルをFastcopyを使ってPCのRAMDISKへコピーする時の平均転送速度を記録。
SDのクロックはNS(24MHz)とHS(48MHz)で比較。
ある程度分かっていたことですがやはり容量を増やしていくと転送スピードは
上がっていきましたがある程度(16kb以上)以上で転送スピードは横ばいになる
ことが分かりました。これはNSとHSもほぼ同様の傾向なので16384byte以上
パケット容量確保してもそれ以上は余り効果がないことが分かります。
まぁこれだけ速度出せたら御の字でしょう。とにかく16384byte分確保して
おけば何の問題もないですね。
ちなみに今回はお仕着せEclipse環境のAC6STM32で一旦プロジェクトをビルドして
ねむいさん環境に移植しましたが(単にリンカスクリプトをDTCMしか使わない
ようにしただけですけど)もっと性能の高いF769I-Discoveryで何で
試さなかったの？と言う話になるでしょうけど理由が…
CPUが対応してない･･･このせいでボード対応しててもビルドが通らないorz
やっぱ自分でmakefile書いてコマンドラインビルドが最強ですって☆
ESP-WROOM-32を使ってみる2 -そんな電源で本当に大丈夫か-
ESP-WROOM-32の目次に戻る
別にねむいさんががんばらなくても意識が他界系の人たちが｢IoTだウェーィｗｗｗｗ｣
とかほざきながらNAVERまとめと変わらんレベルのqiitaとかのやたら検索で引っ掛かる割には糞の役にも立たない
チュートリアルもどきをマンボウの産卵みたいにﾎﾞｺﾎﾞｺ作リ出して情報ノイズを増加させやがるのは
ESP-WROOM-02で予習済みなんですけどまぁアプリレベルの話はそれでもいいんですけど問題はそれ
以前のハードウェアよりの話でねむいさんが散々警告したにもかかわらず電圧
ドロップの問題に今更引っかかったのか納期に間に合わないせいか捨て垢のフリー
メールで日本語になってない日本語で｢これは何が悪いと思いますか！！１！！１！｣とか
あわよくばねむいさんの発言の揚げ足とってこっちに全責任押し付けてやろうというような
性根が見据えた文面のハナクソ野朗が絡んできて虹裏メイドの中でも特に温厚で
優しいねむいさんもさすがにブチ切れて｢お前みたいな奴が"ものづくり(←この単語
ねむいさん大嫌いですがあえて使います)"してんじゃねーですよぅこのハナクソ野郎
何が悪いっておまえの存在全てが悪だよﾊﾞｶﾔﾛｺﾉﾔﾛ｣と返信したいのをぐっっっっと
我慢してなるべく誠意ある対応を心がけてきましたがもうダメです限界です！もうでちゃいます１！！１１１
そういえばもう年末だね
ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ア"ーーーーーーッ！！！１１！
(CV:ストーム・ｲｸﾞｯリード)
本日の記事これにて完結！！
今回はwifiモジュールでありがちな消費電流の問題についてESP-WROOM-32の実測を
しながら検証していきたいとおもいます。
wifiモジュールは基本的に多飯喰らいで特にリセット直後の挙動は注意しなくては
いけません。wifiモジュールが使う3.3Vが大きく落ち込むとブラウンアウトリセット
が掛かり無限ループになる危険性もあります。
前回私が購入したモジュールは1117系のLDOが実装されたモジュールでしたが昨年の
私の測定結果を見れば分かりますがLDO自身のドロップアウトが1V近くあります。
このdoit.am製のボードのUSBコネクタを抜き差ししたときの電圧/電流波形を測定して
本当に安全か確認していきます。
まずはこのボードに電流プローブをつける儀式･･
ここに乗ってる3.3Vを作る1117系LDOはNCP1117かな〜
LDOを一旦はずしました。
すぐさま測定用に"立てて"付け直します。
Voutを浮かして電流プローブを付けられるようにしました。
SDIOの時と違ってプロービングやっけつですが測定対象は比較的遅い変化の電源波形
だから問題ないです。その代わりオシロのピーク検出機能は有効にしておきます。
それではようやく実測にうつります。
電源投入直後っ！
うぉぉう･･･一瞬ですが1.4Aくらいガッツリ電流喰ってますね･･･
XbeeWifi並みですよぅ…。でもこれはResetごとではなくVccの立ち上がり限定
だけのようで安心です☆
なわけないですけど。ていうかこの突入電流て相手側PCにダメージいくんじゃない
と言いたいところですが先に進めませんので見なかったことにします
もう少し時間レンジを窄めました。リセット直後の電流消費は丸で囲った部分の
２発目の大きい電流波形です。BLEブロックがこんな数百mAオーダーで電流喰うわけ
無いのでwifiのブロックがメインとなって動いてますね。
その２発目の部分を拡大です。青色で示す電流波形に注目！
なんと瞬間的に最大600mAも喰ってますよぅ！！！
もちろんこの間+3.3Vラインがおもいくそドロップしてます。
2発目の部分を少し引いた画像です。リセット後の大きな電流消費が収まった後は
電流波形も落ち着きます。しかしながら常時180mA近く消費しています･･･。
ボード上のLEDとCP2102の電流消費をさっ引いても160mA以上消費してるのは確実で
しょう。尤もCP2102は5V->3.3Vの内部レギュレータがあるのでこいつはLDOの+3.3V
には何の影響もないです。つまりESP-WROOM-32自身がめっちゃ喰ってるって訳です。
こんだけ電流喰ってるってことは･･･まさか･･･まさか･･･+5Vラインも仲良く…
おぃいいいいーーーー！！！１１！！！！！！
完全に去年と同じ展開ですね･･･しかも瞬間600mAだからドロップが悪化しますよぅ！！
…おや…どこからともなく声が聞こえる…
＞ねむいさんねむいさん、ESP-WROOM-32の最低動作電圧2.2Vを全然割ってないから
＞ひと時のおちこみくらい見逃してあげましょうよ気にしちゃだめですって！
＞おちんこでる時も気にしない、それが皆が知ってるがんばりやさんのねむいさんですよ！
ぁぁ･･･そうですね･･･入力の+5Vラインさえぱわふりゃーな電圧源使えばなんの
問題もありませんたとえドロップアウトが1V以上の1117系のLDO使ったとしても･･･
･･･
そんな↓わ↑け↓あ↑るかー！！
今のままでは余裕度が0.4Vくらいしかないじゃないですかー！
測定の際に使ったUSB-MicroBケーブルは30cm程のごくごく一般的なものです。
コネクタ部の接触抵抗やケーブルそのものの抵抗成分による電圧ドロップを加味すると
一般的なPCのUSB2.0のコネクタよりVbus電源を取るとこのような状態に簡単に陥って
しまいます！！
てわけで早速+3.3Vラインのパワーアップ大作戦です！！
1117系LDOと同じピン配置をもつADP3338を使います。こいつは負荷の高速応答、
セラミックコンデンサ可、なによりドロップアウト電圧がMAX190mVと大変優れた
逸材です！！！
覚えてらっしゃる方もいると思いますがクリスタルが発振せず電源ラインが発振
したことで有名な某C級出版製のゴミにも搭載されてしまった不名誉なLDOですが
F特の1uFを出力に乗っけるような愚を犯さなければ何の問題もありません。
今回のESP-WROOM-32板にはもともとLDOの出力に100uFのチップタンタルが
乗っていて容量としては必要十分なのでコンデンサは変えず、単純に1117と
置き換えだけ行って測定してみました☆
ADP3338を一般使いする場合は入出力とも16V/10uFくらいでX7Rもしくは
Ｂ特以上の性能の積層セラミックコンデンサ(MLCC)を選びましょう。
秋月さんだとこれとかこれとかお勧めです☆
このLDOの出力に積層セラミックコンデンサ(MLCC)を使うのは意味があります。
MLCCはESRはとても低く一度に大量の電荷を吸い込み/掃出しが可能なので
wifiデバイスのようにいきなり大電流を消費するような回路のデカップリングに
必須なのです。もちろんLDO側も急峻な負荷変動に対応できる瞬発力が要求されます。
単に出力電流容量やコンデンサの容量だけで部品を決めてはなりません。
常日頃データシートとにらめっこして適切な箇所に適切なデバイスを適用
できるように心がけましょう。
+5Vラインが落ち込んでも出力の+3.3Vには全く影響は出ていません！これで電源の心配
無しに思う存分使うことができます♥やったぜ
とはいえ上半身(+3.3V)に比べて下半身(+5V)が貧弱だと他の+5Vデバイスも一緒に
動かしているときに不都合が生じるのでデジタルテスタで遅い変化を測るだけで
終わらずオシロでしっかり波形を確認しながら製作していく癖をつけましょうね。
昨年に引き続き大事なことなので累積で4回言いました！
一応注意点ですがADP3338の入力最大電圧は1117系の半分以下の8Vとなります。
専らUSBのVusbである+5VをLDOのVinとする時の補強を狙っております。
9V以上のACアダプターを主に使う人はADP3338に変えるメリットは何もないです。
まぁこんだけ電気喰うモジュールにLDOに9V以上の入力電圧加えたらLDO自身の発熱が
どういうことになるか皆さんご存知でやはりVusbの+5V程度を入力電圧とすべきなの
は自明と思いますがねむいさん的には30USDくらいになってもいいからDCDCくらいは
組んでほしかったなぁ〜なんて思いましたっ！
ちなみにこのボードの｢Vin端子｣とVbusはショットキバリアで切られておらず何も
考えずに電圧同時印加すると当たり前にぶっ壊れるステキ設計となっております♥
尤もねむいさんのぶろぐの読者にそんなことやらかす頭がぶっ壊れた奴がいるとは
思えませんから杞憂でしょうけども(カメラ目線で
そいえばDCDCで思い出したけど以前コメントでHX1001進められたけどあれって結局
どうしたの？とお思いの方がいると思います。
実はEMSで配達指定したESP-WROOM-32の方が先に届いてしまったので評価はもう少し
先になると思います。その前にSDカードネタももう一つやりたいのでもうHX1001は
もすこしお待ちください。
20170227追：
ねむいさん+5Vや+3.3Vの事ばかり言ってますがGNDについても帰還電流の流路を
意識しなるべく広いグランドプレーンを確保するのはもはや常識と思います。
側面から出ているGNDのピンとは電気的には繋がっておりますがESP-WROOM-32の
背面のGNDパッドの接続もぜったいに省略してはいけません！このようなパタンが
設けられているのはちゃんと意味があるのです。
特にブレッドボードで工作される方はこの重要性を理解せず動作させようと
される方がものすごく多いのですが｢動いているようです｣で済ませるとこの先
必ずトラブルが起こります。
面倒くさがらずに土台はしっかりと固めておきましょう！
20170227追：
20170220追：
mgo-tec様が当ブログエントリの内容を追実験してくれました。
ねむいさんと同じADP3338を用いてよい結果を出されています。
また、電源投入時->リセット時の電流の変化もシャント抵抗を用いた測定法に
よりねむいさんと同じ測定結果を記録しております。
第三者による検証の再現性もばっちりとれているのでねむいさんのやったことは
間違ってなかったとまたひとつ確信させていただきましたっ☆
ちなみにねむいさんのdoit.amの出来合いボードのパタンが1117系でちょうど
ADP3338で楽に置き換えできたからこれを選んだわけで、ねむいさんとしましては
秋月で安価に購入できて各種保護回路も万全に備わっていてドロップアウト電圧も
1.5Aでたったの0.34Vと最強に強まっているLT1963Aを強く推させていただきます。
20171115追:
ADP3338、ついに秋月に光臨す！！！
技適マーク付きESP32モジュールESP-WROOM-32を使ってみる
20170218追：
♥併せて読みたいESP-WROOM-32の記事♥
その２(電源ラインがマジヤバイ編)
その３(IDFを使ったビルド・書き込み指南編)
その４(SPI-ROM吸出し救出編)
その５(ESP32がぶっ壊れたもしくはウンチーコング編)
20170218追:
macsbugさんの記事を見てねむいさんも速攻発注して手に入れました！！！！１！！
(12月13日に到着してたんですが忙しすぎて触れたの今日ですが･･･)
これがッ！
技適マークつきのっ！
wi-fiとBLEが使えるESP3212モジュール
ESP-WROOM-32だぁあぁああぁあっ１！！！１１
はぁはぁ･･･
ねむいさんはこちらの店から19USDで購入しましたが今見たら3ドル上がって
ました。今はクーポン効くからねむいさんのときと同じ値段で替えますけど。
実際にはこんな感じのNodeMCUを意識した出来合いボードに実装されています。
20161220現在は製造元のdoit.amのサイトにはこのボードの詳細は乗っていませんが
回路はいたって単純なのでラクに追えます。
また、このボードにはUSB-VCOMチップのCP2102と、
1117系のLDOが実装されています。
1117系ってなんかやばい予感がしますけど多分気のせいですね気のせいﾊﾊ
何はともあれ早速動かしてみました！！！
MicroBコネクタにケーブルを挿して電源投入すると
電源を示す赤LEDのほかに青LEDが点滅しました。
･･･ターミナルを開いてみたはいいのですがESP-WROOM-02と違ってATコマンドの
ファームが存在しないようで自由度が高すぎて何やってよいか分かりません＞＜
↑micropythonのスクリプト言語が走っているようです。
しかたが無いので取っ掛かりとなるUARTの文字列を吐くアプリケーションを
MSYS2でビルドしていきます。これについての詳しい解説は次回以降に行いますので
皆様首を長くしてお待ちください♥
使い方よりも先に電源を見ます。
Flash書き込みも"make flash"で一発です☆
コマンドラインビルドが出来るとこの環境でも移植しやすいので要検討ですね〜
やったぜ
小さな文字列ですが大きな一歩を歩みだしました！もはやこっちのもんです！
とりあえずビルド環境を立ち上げるのがESP-WROOM-32を使いこなす鍵となりそう
です。また、OpenOCDとかいう単語もちらちら見えるのでねむいさんにも嬉しい
32bitマイコンになってくれるかもしれません♥
というわけで今回はほんの触りですがESP-WROOM-32をご紹介しました。
公式を見る限りでは現在急ピッチで簡単に開発できる環境作りが進められている
ようです。ESP8266と違ってBLEも扱えてCPUパワーもRAMも圧倒的になりましたので
使用できる用途がさらに広がりますね！
昨年はESP-WROOM-02の到来をもって｢新しい時代が来た｣と言いましたがこの度の
ESP-WROOM-32の登場により加熱したIoTシーンはさらに過激な領域へと突入
していくと言うことができるでしょう！
いろいろ試す24
今年の暑は夏いですね････
頭が沸騰して凝固しないように少しでも文章を残す訓練をしないと･･･
●LPC11U14の悲劇
マジかよ･･･ユーザーマニュアルにはROMディバイダあるって明記してあるのに･･･
というわけで実機で調べてみました。ねむいさんの持っていたLPC11U14Expressoは
最々初期のLPC11U14が乗っています。
0x1FFF1FF8にはROMドライバのアドレスが格納されています。実アドレスは
0x1FFF1E38となっています。
LPC11UxxのROMディバイダへのポインタが格納されているアドレスはその先頭
から16バイト先にあります。つまり0x1FFF1E48に有効なアドレスが格納されて
いない場合ROMディバイダは使用不可能となります！
ア"ア"ア"ア"ア"ア"ア"ーーーーーーーッ！！！！
･･･
NxPのLPCマイコンはこう言う罠がたくさん張り巡らされていますのでユーザー
マニュアルとか鵜呑みにしないで海外のフォーラムも積極的に巡って情報を
収集してください。
そいえば2年位前ねむいさんが指摘したLPC1500のIAPのアドレスが間違ってる件も
2016年現在まだ治ってない･･･NxP(xは伏字)さんにメッセ送ったのに･･･。
●STM32Primer2を使ったGNSSロガーのリポ電池を変更
ねむいさんはトレランのトラックログ取り用にSTM32Primer2にハード的改造を施し、
それをGNSSロガーとして使用しております。電池もSparkfun製の1000mAhの
リポ電池に乗せ買え12h以上稼動できるようにしていました。
そして2010年から約6年間もの間戦い続けてきたそのリポ電池もかなりへたってきたので
交換する運びとなったわけです。
･･･がしかし！！！なんと昨今の規制強化のせいか850mAh以上の大容量のリポ電池が
軒並み販売終了となっていて購入する事が出来なくなっておりました！！！
探しに探しまくってこちらの通販会社さんから1000mAhのリポ電池を購入する事に
しました。最悪中華直販から輸入も考えたのですがチャイナボカンされたら困るので
国内から購入できる店があって助かりました♥
で、来たのはこちら。
6年前に購入したSparkFun製のものより薄く少し長くなっています。もちろん保護
回路付コネクタ付です。
元からついているコネクタは不要なのでJSTのRCYコネクタに付け直しました。
これで電池の脱着が自由に出来ます。･･･以前はテストのために直付けしたので
6年間そのままにしてましたが今回の電池交換でようやくです。
ぁーちなみにハーネスの力がかかる部分をポリイミドテープでガチガチに固定して
ますがこいつ意外と剥がれません！wifiモジュールをポリイミドでガチガチに固定してた
EnchantMOONのこと｢こんなん振動ですぐ取れるやん｣とさんざ馬鹿にしてましたが
前言撤回ですすみません！！でもよい子は真似しちゃだめだよ！
もちろん交換後も無事正常起動しました。
2016年真夏の炎天下の近畿自然歩道でバリバリ活躍しております！
たぶんねむいさんが世界でSTM32Primer2をいちばん長く使い続けてる女だと
思います･･･！もちろんあと30年は電池交換し続けて使い倒しますよぅ！
●FatFsに大量のぱっち
今年の四月にExFatに対応したChaN氏のFatFsですが、ねむいさん含めた有志からの
使用報告を受けパッチがパチパチ当たってます。現在はpatch7まで行っていますが
ねむいさんもそれに即追従してアップデートしております。
私が特に力を入れているSTM32F7をはじめSTM32F4系、STM32F1系も順次最新の
ものにアップデートしております。皆様どしどしご利用ください★
●ウィルキンソンドライコーラ
･･･
甘味抜いたタブクリアだこれ
●おそロシアふたたび
Latticeの提供しているプログラミングツールはFT2232H系のデバイスに対応して
いてJTAGKey2CompatibleでもEEPROMを書きかえるだけでLatticeのプログラマに
化けるナイスな対応をしてくれましたが、AlteraとXilinxのツールはかたくなに
FT2232系のデバイスには対応しておりませんでした。
しかしながらロシアから恐ろしい刺客がやって来たのです･･･！もちろんLatticeと
違ってかなりダーティな裏技なので詳しいやり方は伏せさせていただきます･･･。
こちらのロシア系BBSのリンク先にあるとあるファイルにAlteraのプログラミング
ツールにFTDI系デバイスを対応させるdllがあり、それに差し替えるだけでQuartus
からAlteraのCPLD/FPGAのプログラミングツールとして使えちゃいます！！！
↑実際に使ってるところ。書き込み速度はもちろん超★爆★速！
もうこれでUSBBlasterもどき作らなくてもいいんじゃ♥
そして問題のXilinx....
ねむいさんは過去に何度もXに挑戦し敗れてきましたがおそロシアのおかげでついに、
ついに攻略せしめました！！！！
注：ただし以下の条件を全て満たす必要があります。
１．FT2232Hのみ有効。FT232HやFT2232Dは不可！
２．FT2232Hにぶら下がるEEPROMは93LC56もしくは93LC66のみ有効。
93LC46はユーザー領域が足らず不可！
３．JTAGKey2 Compatible Rev.5を使用する場合、メインモジュールの
DLP-USB1232Hに搭載されたモジュールが93LC56or93LC66である事。
これは何が来るか分からないのでばくちですね･･･しかもQFNパッケなの
で引っぺがすのは普通の人にはちょっと無理でしょう。
かわりにFT2232H Minimoduleがオススメです。これ93LC56乗ってますし。
↑コツですがMProgを使ってEEPROMのデータを書きこむときにシリアルナンバを
"有効"にしておきます。この後FTDI_User_Area_Writer.exeを起動しMprog/FTProg
からは書き込めないユーザ領域にデータを書きこみます。
やったぜ。Digile○ntのJTAG-HS2として認識されました♥ちなみにISE14.7は
プラグインの調達の必要もなくIMPACTから普通に使えます。
実際にSPARTAN3をつなげてJTAGチェインを見てみます。
やったぜ！
もちろんふつうにコンフィグレーションできます♥
2010年からずっと奮闘してきた内容ですがようやくつっかえていた小骨が取れた
感じです♥EEPROMを書き換える少しの手間はありますがこれでねむいさん謹製の
JTAGKey2Compatibleが更に強力なフラッシュ書き込み/デバッグツールとして
活躍していけると思います！！
STM32F7を使ってみる12 -STM32F769I-Discoveryを動かしてみる-
超忙しい状態が続いてるせいかせっかく買ったのに半月ほど寝かせてたらその間に
円安が進んで損しましたorz
それはおいといてSTM32F769I-Discoveryを私も手に入れました★昨年販売された
STM32F746G-Discoveryを機能的に踏襲しつつ新たな機能が更に盛り込まれています。
今回の目玉はMCUのF7系最強のSTM32F769Iなわけですが、今回ついに、ついに倍精度
浮動小数点ユニットが搭載されることとなりました！！長かった･･･
ついでに細かいCortex-M7のエラッタがさりげなく直されていますがあとで紹介します。
ハードウエア的には前回は16bit分減らされて容量も半分しか使えなかったSDRAMが
32bit分全開使えて容量もアップした事とすっかりおなじみになったQSPIも64Mbyte品
に容量アップでまさに最強に強まっています！！！
では早速電源投入を･･･
･･･ぁ･･･microUSBコネクタだ･･･
microUSBケーブルを引っ張り出してきて改めて電源投入！
なんかTouchGFXというのとEmbeddedWizardとかいうのが新たにメニューに追加
されていますね。
TouchGFXのBirdtheCoinとかいうのをやってみましょ
･･･！！！
クソゲーすぎる･･･
DMA2Dのパフォーマンステスト兼ねてるみたいですね。
さてお次はEmbeddedWizardです
容量性タッチパネルコントローラの機能を最大限に生かした入力デモが利用できます。
このようなオシロ風表示もらくらくです★
お遊びはこの辺にして私のいつものをF769Iに移植してみました。
移植に関してですがF746シリーズと決定的に違う点は内蔵RAMが増量、PLL-Rが追加
されているのと倍精度浮動小数点演算ユニットの対応です。
newlibで倍精度演算ライブラリを利用できるようにするためにはGCCコンパイラに
"-mfloat-abi=hard -mfpu=fpv5-d16"を渡すべきです。
後は液晶表示のためのペリフェラルがRGBでは無くDSIを利用している点です。
DSIは速度が速すぎるため、他ポートとの兼用はしておらず完全独立しております！
DSIの叩き方等の見本はBSPが充実していますのでライセンスに乗っ取ってまるっと
利用させてもらいます。
そんでもってSDMMCのポートは二つに増えましたがこのボードではSDMMC2のみを
SDカード用のポートとして利用していますのでこちらに替えるようにします。
そしてOpenOCDでビルドしたバイナリを焼く･･･！
ねむいさんのおきぱのOpenOCDバイナリはSTM32F76x/77x系にすでに
対応しています★
いつものが無事起動しました。SDカードもしっかり見えてディレクトリを
読めています！
libjpeg,giflib,libpng等の画像デコードもいつものように無事に表示できてます♥
でも展開時の表示がなんかもたついてる感じがするんですよね･･･
解像度が800x480に上がったせいかはたまたDSIとDMA2Dの連携が上手く
いってないのかこの辺の調査は次回に繰り越します。
あと今回重要なポイントは冒頭で述べたCortex-M7コアのエラッタでデバッグ時に
ペンディングビットが立った状態だとブレークポイント張ってないのにもかかわらず
強制的にその割り込み処理の先頭でブレークしてしまうと言うちょっと厄介な
エラッタが修正されています。
画像はF746におけるUART割り込みでブレークポイント無効なのに何故かUARTの
割り込み処理の先頭でとまっちゃているのが分かると思います。
というところで駆け足で紹介しましたが今からF7に入門される人たちは上記
エラッタが修正されたSTM32F769が搭載されているSTM32F769I-Discoveryを
購入して遊ぶのが最も最適かと思います。
んでもって私のF7のサンプルはすでにSTM32F769I-Discoveryに対応している
(もちろんmakefileの設定でF746-G化も可能です)ので手前味噌でありますが
どしどしご利用ください！
いろいろ試す23
せっかく貴重なGWの休みだというのに何をやっているんだ私は･･･
でもこれを消化しないと先に進めないというBADハマリ状態なのです･･･
●FTDIのFT232Rはぱちもんを撥ねるドライバが出てFT232Rの安いぱちもん
使えなくなったから中華製のCH340G使おうぜムーブメント
みなさんはすでにご存知のこととは思いますがFT232Rはぱちもん対策が仕込んで
あってあんなことやこんなことでぱちもんを使えなくさせています。
中華製のFT232R基板はまずぱちもんなのが前提だそうでぱちもん愛好家の方には
FTDIのドライバ改変で使えなくなるのは死活問題なのは必須です。そういうわけで
中華製のUSB-シリアル変換ICであるCH340Gを使おうという動きがあるようです。
ねむいさん的には何か大前提が思いっきり間違ってる気がしますが｢自己責任
なら良いのではないでしょうか自己責任なら｣といい居たいところですが大抵は
ぱちもんに分かって手出す人はケチなくせに文句だけは百人前でそういう人に
関わると時間と金を浪費してしまいますので皆様方はそういう人種を機敏に察知し
いち早く距離を置かれることが良いと思います。
…すみません話がそれてしまいましたが残念ながらCH340Gにもぱちもんが存在している
ようです。こちらをご覧ください。真ん中あたりにくわしい解説の画像があります。
CH340Gのぱちもんの見分け方として1Pinのマーキングの丸の削りが大きく広い
物が正規品で丸が小さくクレーター状に削られてるものがぱちもんだそうです。
ねむいさんも何故かCH340Gの出来合いボード持ってました･･･そして･･･
ぱちもんでしたー！！！！
クソァ！！１！１！！１
ちなみにぱちもんCH340Gは公式のドライバ宛がっても上手く動作しないようで
やっぱし中華メーカといえどもしっかりドライバでぱちもん対策してるようです。
このへんFTDIやProlificも同じなのでたとえイタチごっことなろうとも
メーカの自衛策としてぱちもん対策を仕込むのは必然となっているようですね。
安物買いの銭失い、安全/安心は金で買うものとはよく言ったものです。
たまにその売り物の安全安心すらぱちもんのことがありますけど…ふふふ。
20160512追:
こちらの方のブログのコメントに具体的な情報を見つけました。以下引用。
Commented by 中華マニア at 2015-04-24 10:11 x
CH340G自体にも通電していると内部のボンディングワイヤが焼き切れて
すぐ使えなくなる粗悪な偽物があふれかえっているそうです。
あれ…副業先で生産が間に合わず海外の別ルートで購入したNxP(xは伏字のx)製の
FETで似たような経験したような…
●FatFsが0.12にアップデートしてついにexFATに対応！！
GW前にChaN氏のFatFsがexFATに対応してアップデートしておりました。
64GByte以上のSDXCカードが安価で販売されるようになった今、exFATへの対応は
必然であるといえるのです！
･･ぇ？FAT32で無理やりフォーマットできるですって！？それはおいといて･･･
ところでSDHCとSDXCの違いは何か、どうやって見分けるのかという素朴な疑問が
わきますが規格では64GB以上の容量を持つカードがSDXCとなっています。
一般の方が単純明快に見分けられるたった一つの方法です。
SDHCはどう頑張っても32GBどまりです。この辺はこちらの方の解説が詳しいです。
逆に言うと128GBのSDHCとかは絶対に存在しないのでぱちもんであるとわかります。
海外通販でだまされないように注意してください。
ソフトウェア的に見分ける方法はいくつかあって前回もさらっと触れましたが
SCRを読み出しSD_Securityフィールドの値を見ることでも簡単に判別できます。
SDXCはここの値が必ず4になっています。ここの値はSD_SpecのVerには関係あり
ませんのでSDSpecのVerが4でもSDHCだったり3のカードでもSDXCなのが存在する
のは前回の読み出し比較でご存知だと思います。
さて、exFATにすることでFatFsがどういう挙動になるかを実際にフォーマット別
に比較してみました。使用するカードは前回へなちょこ判定したSuperTalentの
64GBのカードです。
前回無理やりFAT32にフォーマットして使ったといいましたがWindows上ではSDXC
カードはほぼ強制的にexFATでフォーマットされてしまうのでParagonHardDiskManager
を使いFAT32にフォーマットして使いました。
exFATのフォーマットについてはもちろんおなじみのSDFormatterV4.0です。
というわけでChaN氏のFat情報を読み出すfsコマンドといつものシーケンシャル
リードの速度比較を行ってみました。STM32F7-Discoveryで行ってます。
※FAT32フォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = FAT32
Bytes/Cluster = 16384
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 30576
Number of clusters = 3913672
Volume start (lba) = 2048
FAT start (lba) = 2080
DIR start (lba,clustor) = 2
Data start (lba) = 63232
Volume name is SDXC_64GB
Volume S/N is 7022-3F80
...
19 files, 520994673 bytes.
2 folders.
62618752 KiB total disk space.
62109728 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15414 kB/sec.※exFATフォーマット
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : May 4 2016
>fs
FAT type = exFAT
Bytes/Cluster = 131072
Number of FATs = 1
Root DIR entries = 0
Sectors/FAT = 16384
Number of clusters = 489208
Volume start (lba) = 32768
FAT start (lba) = 49152
DIR start (lba,clustor) = 4
Data start (lba) = 65536
Volume name is SDXC_64GB
Volume S/N is DF51-7DE4
...
19 files, 520994673 bytes.
2 folders.
62618624 KiB total disk space.
62107904 KiB available.
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18442 kB/sec.なん･･･だと･･･！？
exFATにしたらへなちょこじゃなくなった･･･！？
exFATになってクラスタサイズがデカイのが効いているのかもしれません。
FatFsのexFATの対応はまだ始まったばかりでバグも洗い出されて洗練されて
いく真っ最中ですのでこれからの発展に期待ですね。
ついでにFatFsのexFAT対応する時の注意点をいくつか･･･
1.常にLFN対応が必須
exFATはロングファイルネームしか存在しないためです。それに伴って従来の
8.3形式ファイル表記に頼ったプログラムだと既存のものから0.12にアップ
デートする際にかなりの改修が必要です。
2.そんなわけでメモリ消費量が多くなる
これも致し方ないですね。SRAM容量32kByte以下の小規模マイコンはexFAT
対応はやめたほうが無難でしょう。尤も32GB以下のSDHCもまだまだ生産されて
流通しているのでSDXCしかカードが無い！って事態は当分の間無いといえます。
無理にexFAT対応にするべきではありません。ライセンスの問題もありますから。
･業務連絡･
もしここ見てたら"Well written implementations for STM32F/SDIO and LPC2300/MCI"
の"STM32F/SDIO and LPC2300/MCI"のところを"STM32F/SPI & SDIO and LPC4088/SDMMC"
に書き換えておいてください･･･。
↑ご協力ありがとうございました(ぺっこりん
皆様へ、
おきぱのSTM32F4とSTM32F7向けのいつものはFatFs0.12に対応してすでに公開
しております！もちろん0.12向けのパッチも適用済なのでどしどしご利用ください！
●4GBのSDカード
かつて4GB以上の容量をサポートするSDHCの規格が登場し実際に市場に出回り
はじめる過渡期に4GBの容量を持ちながらSDv1規格で動作するいわゆる"規格外"の
SDカードが存在していました。
いったいこのカードはどのような動作をするのか！？実際に現在でも流通している
カードを購入して調べてみることにしました。
ebayでドイツの販売主から購入しました。SDV1.1規格の4GBのSDカードでSDHCに対応
しないちょっと昔の機器で活躍するかも！ていう触れ込みです。
さっそくねむいさんのいつものでSDカードの情報を読み出してみました。
が････
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...
Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!･･･
なんですかこれ単なるSDHCじゃないですかーヤダー！！！
･･･ちなみにh2testwでも調べましたがカードとしてはちゃんと4GBの容量をもった
"SDHC"でした･･･ﾋﾞｷﾋﾞｷ
ぱちもんつかまされたと思って捨てるのもあれなので副業先の修理品撮影用でぢかめ
の記憶素子として利用することになりました。
が･･･
後輩から｢ねむいさんこのカード1GBしか認識しないんスけど？｣と文句を言われ
このカードのホントの力を知ることになります。
後輩が撮影した画像データを取り出そうとして使ったUSBカードリーダーは10年
以上前の骨董品で、4GBに替える前のでぢかめ用SDも時代遅れの1GBでした。
もちろんこのカードリーダはSDHCを一切認識しないため私が提供した4GBのカードが
容量が変だとはいえ認識すること事態がおかしいのです。
ねむいさん後輩からそのカードを取りかえし、デバッガで動きを追ったところ以下の
事実が分かりました。
1.イニシャライズ時に最初にCMD8(SDv2専用の初期化コマンド)を投げていると
SDHCとしてブロックアドレッシングモードで動作する。
2.ACMD41をいきなり投げると(SDv1の初期化)SDSCとしてバイトアドレ
ッシングモードで動作する
つまり新旧の初期化方法のどちらでも正しくカードを初期化できて正しく動作する
ように作られたいわば魔法のカードだったのです！！！
ねむいさんのおきぱのFatFsの移植サンプルはSDカードの初期化手順がCMD0->CMD8->
ACMD41というSDv2もSDv1も包括する流れだったので必ずSDHCとして初期化されて
しまうのでぱちもんだー！と誤認してしまいました。
以下に通常のSDv2の初期化とわざとCMD8を飛ばしてSDv1で初期化したときのカード
情報の違いの差を示します。
・SDv2
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384
No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
CSD:
00000000 40 0E 00 32 5B 59 00 00 1D B1 7F 80 0A 40 00 39 @..2[Y.......@.9
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...
Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!・SDv1
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 28 2016
>fl
----A2011/07/27 23:51 351416 0c4f42da.jpg
----A2015/03/03 15:07 307254 1c3e744f.bmp
----A2010/07/20 13:52 1993197471 91sp2_quartus_free.exe
----A2011/06/04 06:07 324588 1c3e744f.jpg
----A2010/03/24 17:47 132389 002.jpg
----A2016/01/30 10:54 244527 2d35e710.jpg
----A2013/06/20 22:49 47566 2ecd0b3e.jpg
----A2010/03/24 17:48 198903 003.jpg
----A2011/05/25 01:11 53023 3c3ba2bd.jpg
----A2010/03/24 17:48 137038 004.jpg
----A2013/05/29 21:02 22235 4b62585a.jpg
----A2012/09/19 23:32 80490 4db4ceb4-d00d-5891-b900-4f97ec745309.image.jpg
----A2010/12/02 23:28 102769 4e61b17f.jpg
----A2010/03/24 17:48 148307 005.jpg
----A2015/07/08 14:32 318848704 install_sw4stm32_win_32bits-v1.2.exe
----A2016/02/26 11:57 421760368 MDK518.EXE
----A2008/09/12 20:19 47341 2005-03-24otter02.jpg
17 File(s),2736004389 bytes total
0 Dir(s), 1239515136 bytes free
>fs
FAT type = FAT32
Bytes/Cluster = 32768
Number of FATs = 2
Root DIR entries = 0
Sectors/FAT = 948
Number of clusters = 121334
Volume start (lba) = 8192
FAT start (lba) = 14488
DIR start (lba,clustor) = 2
Data start (lba) = 16384
No volume label
Volume S/N is 3688-4D7E
...
17 files, 2736004389 bytes.
0 folders.
3882688 KiB total disk space.
1210464 KiB available.
>ds 0
rc=0
Drive size: 7784448 sectors
Erase block size: 512 sectors
Default r/w block size: 2048 bytes
Card type: SDv1
CSD:
00000000 00 0E 00 32 5B 5B 03 B6 1D B3 FF 80 0A C0 00 E9 ...2[[..........
CID:
00000000 1B 53 4D 46 46 46 46 46 10 00 00 20 46 00 FC F3 .SMFFFFF... F...
Parsing SD CID Register
Manufacturer ID :0x1B
OEM/Application ID :SM
Product Name :FFFFF
Product HwRev :1
Product SwRev :0
Serial Number :0x00002046
DateCode.Month :12
DateCode.Year :2015
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 20 04 04 90 00 08 05 00 00 ....... ........
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 25 80 00 00 00 00 00 .%......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDSC Card!もちろんどちらの初期化手順でも得られる使用可能総容量はCSDレジスタの値自体が
アジャストされ変化するためSDv2,SDv1のどちらの初期化手順でもまったく
同一の容量となり、さらにバイト/ブロックアドレッシング両方の読み書きも
すべて正しく行えております。
しかもご丁寧にSCRのSDSecurityのバージョンまでちゃんとアジャストして
SDv1で初期化したらちゃんとSDSCとして認識されるという充実ぶりです！！
ついでですがその他の"4GBのSDカード"も調べてみました。これはTOPRAM製の
カードです。結果から言うと同じく初期化手順の違いでSDSCにもSDHCにも化ける
タイプでした。
こちらは規格外カードの本家ともいえるTranscendの4GBカードです･･･がUSEDで
しか手に入らなかったのでなんか茶色いのがいっぱいこびりついててきちゃない･･･
中華からかった中古なので何がついてる分からずIPAでよごれをこすって落とし
まくって2時間後にようやく動作確認･･･
こいつこそホントに単なるSDHCでした！！！！！F**K!
20160512追:
後でさらに調べて分かりましたが"SD Compatible"とパッケージにはっきり
書かれたものでない限りはSDHCの表記が無くてもただのSDHCでSDv1の
初期化は一切通らないそうですF++K!!!
というわけで規格外な"4GBのSDカード"は規格外ながらも今日もどこかの
ちょっと古い機材で活躍しているかもしれません。
●秋月の006Pリチウム電池
テスタの電池用に秋月さんの006P型リチウム電池を購入してみました。
一般の006Pと比べるとやたら軽くちょっと大きく見えて不安になります･･･
一応無理なく収納できました★
動作も問題ありません♥
実はもう4ヶ月近く使用していますが今のところ電圧が出なくなったり爆発
したりとかはなく、至って問題なく使用できています。このリチウム電池は一
般的な006P型乾電池と比べると電流容量はかなり低いですがテスタのような
消費電力が低い機器で使用する分にはまったく問題は無いのでオススメです♥
STM32F4シリーズを使ってみる15 - FatFsとSDカード再考その4(SDカードを手当たりしだい読み出してみる) -
一年以上ぶりの企画になってしまいましたが前回の続きです。
STM32F4を使ってSDカードのカード情報を読み出したり読み取り速度の比較を
行います。
とりあえず手持ちのカードを全部！！！
MMCから始まり10年以上前のSDカードや最新のSDXCまで網羅します！！
条件は以下のとおりとします。
・各カードはあらかじめSDFormatterでFAT32でフォーマットする。
64GB以上のSDXCもHardDiskManagerで無理やりFAT32でフォーマットします。
・プログラムはSTM32F4版のいつものの3/31日版とします。
・使用するボードは180MHzで動作可能なSTM32F427IIT6が乗った
STM32F4全部乗せボードを使用します。
・SDのクロックはハイスピードモードとします。このボードでは
SDIO_CLKの最高クロック周波数は51.43MHzとなります。
また、SDIOの転送にはDMAを使用します。
・読み出し速度は132949600Byteのファイルのシーケンシャル読み出しの速度を
比較します(128MBのMMCv3を除く)。また、ねむいさん的には読み出ししか興味
ないので書き込み比較はやりません。
それでははじめましょう！
●Toshiba製eMMCv5 8GB
まずは前回のおさらい、Toshiba製のeMMC8GBです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22961 kB/sec.
>ds 0
rc=0
Drive size: 15269888 sectors
Erase block size: 1024 sectors
Default r/w block size: 512 bytes
Card type: MMC(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..
CID:
00000000 11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..
Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0>
Product Name :008GE0
Product Rev :0.0
Serial Number :0x5ADD4140
DateCode.Month :11
DateCode.Year :2015
Detected as MMCv5.0x Device!
OCR:
00000000 C0 FF 80 80 ....読み出し速度が22961kByte/SecとSDカードを抑えてダントツに早いです！
●Transcend製2GB MMCplus
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21261 kB/sec.
>ds 0
rc=0
Drive size: 3939328 sectors
Erase block size: 256 sectors
Default r/w block size: 1024 bytes
Card type: MMC(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 90 2F 00 2A 1F 5A 83 C1 B6 DB 9F FF 96 80 00 3F ./.*.Z.........?
CID:
00000000 37 FF FF 4D 4D 43 30 32 47 10 F3 02 67 50 2C F5 7..MMC02G...gP,.
Parsing MMC CID Register
Manufacturer ID :0x37
OEM/Application ID :��
Product Name :MMC02G
Product Rev :1.0
Serial Number :0xF3026750
DateCode.Month :2
DateCode.Year :2009
Detected as MMCv4.0 Device!
OCR:
00000000 80 FF 80 80 ....こちらもなかなかのお手前で。
●日本製MMCv3カード
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fl
D---- 2016/03/14 23:28 0 .
D---- 2016/03/14 23:28 0 ..
----A 2010/03/13 20:06 44679600 ftbt.mp3
1 File(s), 44679600 bytes total
2 Dir(s), 83640320 bytes free
>fr 44679600
44679600 bytes read with 1904 kB/sec.
>ds 0
rc=0
Drive size: 250880 sectors
Erase block size: 32 sectors
Default r/w block size: 512 bytes
Card type: MMC(Byte)
SpeedMode: NomalSpeedMode(17.14MHz)
DataBusWidth: 1bit
CSD:
00000000 8C 26 01 2A 0F 59 81 E9 F6 DA 81 E3 9E 40 00 7D .&.*.Y.......@.}
CID:
00000000 11 00 00 30 31 32 38 4D 32 0A 05 80 FE CB 28 7D ...0128M2.....(}
Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0><0>
Product Name :0128M2
Product Rev :0.10
Serial Number :0x0580FECB
DateCode.Month :2
DateCode.Year :2005
Detected as MMCv3.xx Card!
OCR:
00000000 80 FF 80 00 ....MMCv3は20MHz以下のクロックでなければいけないのでそれを守っています。
20MHz以上では確かに動作しませんでした。
ここから先はSDカードです。
●Transcend製x600のMicroSDHC8GB(TS8GUSDHC10U1)
昨年末に紹介したMLCアピールの奴です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20025 kB/sec.
>ds 0
rc=0
Drive size: 15759360 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 3C 1D 7F 80 0A 40 00 63 @..2[Y..<....@.c
CID:
00000000 74 4A 60 55 53 44 55 31 20 3B A1 5F AA 00 F6 25 tJ`USDU1 ;._...%
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :USDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x3BA15FAA
DateCode.Month :6
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 08 11 39 00 ..............9.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!結構読み出しが早いですね。SDカードでは20000kB/Sec以上だと
早い部類です。
●Transcend製x600のSDHC32GB(TS32GSDHC10U1)
今度はさっきの32GB版、かつ通常サイズのものです。
今年春までTG-3の撮影用記録媒体として活躍していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18130 kB/sec.
>ds 0
rc=0
Drive size: 63272960 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 F1 5D 7F 80 0A 40 00 79 @..2[Y...]...@.y
CID:
00000000 74 4A 60 53 44 55 31 20 20 46 F9 B9 1D 00 F5 67 tJ`SDU1 F.....g
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :J`
Product Name :SDU1
Product HwRev :2
Product SwRev :0
Serial Number :0x46F9B91D
DateCode.Month :5
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 00 90 00 08 11 39 00 ..............9.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!まずまずですね。
●Transcend製MicroSDHC8GB
普通の廉価版の奴です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15279 kB/sec.
>ds 0
rc=0
Drive size: 15456256 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 3A F5 7F 80 0A 40 00 43 @..2[Y..:....@.C
CID:
00000000 74 4A 45 55 53 44 55 31 02 05 B0 00 60 00 D1 E3 tJEUSDU1....`...
Parsing SD CID Register
Manufacturer ID :0x74
OEM/Application ID :JE
Product Name :USDU1
Product HwRev :0
Product SwRev :2
Serial Number :0x05B00060
DateCode.Month :1
DateCode.Year :2013
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 08 11 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 03 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!廉価版だけに速度はそれなりです。
●SuperTalent MicroSDHC 4GB
お店で同容量比で最安値に近い値段で買えたSupterTalentのSDカードです。
たしか780円でした。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 13677 kB/sec.
>ds 0
rc=0
Drive size: 7841792 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 1D E9 7F 80 0A 40 00 69 @..2[Y.......@.i
CID:
00000000 73 42 47 4E 43 61 72 64 10 19 23 6D 71 00 BB 81 sBGNCard..#mq...
Parsing SD CID Register
Manufacturer ID :0x73
OEM/Application ID :BG
Product Name :NCard
Product HwRev :1
Product SwRev :0
Serial Number :0x19236D71
DateCode.Month :11
DateCode.Year :2011
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!リードが13MB/Sec･･･ﾀﾞﾒﾀﾞﾒですね。
●SuperTalent MicroSDXC64GB(FAT32 Format)
続いては64GB版のSDXCの奴です。フォーマットは無理やりFAT32で
行ったうえで試しました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 15772 kB/sec.
>ds 0
rc=0
Drive size: 125302784 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 01 DD FD 7F 80 0A 40 00 07 @..2[Y.......@..
CID:
00000000 28 42 45 20 20 20 20 20 02 00 33 3C 22 00 FA D3 (BE ..3<"...
Parsing SD CID Register
Manufacturer ID :0x28
OEM/Application ID :BE
Product Name :
Product HwRev :0
Product SwRev :2
Serial Number :0x00333C22
DateCode.Month :10
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 90 00 08 11 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 80 03 00 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :4
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDXC Card!4GBの奴よりマシなものの15MB/Secちょっと･･やっぱしダメですね・・・
ちなみにSCRの値が示すとおりちゃんとSDXCとして認識できているので
カードとしてはれっきとしたSDXCです。
SDHCとSDXCの見分け方は容量のほかにSCRのSD Securityのバージョンから
分別することも可能です。
●KingMAX MicroSDHC32GB
こちらも廉価で替えるカードの筆頭です。
当時ちょっと値が張った32GBをFatFsの動作確認用に購入していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 13668 kB/sec.
>ds 0
rc=0
Drive size: 62683136 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 EF 1D 7F 80 0A 40 00 27 @..2[Y.......@.'
CID:
00000000 13 4B 47 53 44 33 32 47 10 C2 00 51 1A 00 C7 A3 .KGSD32G...Q....
Parsing SD CID Register
Manufacturer ID :0x13
OEM/Application ID :KG
Product Name :SD32G
Product HwRev :1
Product SwRev :0
Serial Number :0xC200511A
DateCode.Month :7
DateCode.Year :2012
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!SuperTalentと同じ13MB/Sec...ﾀﾞﾒﾀﾞｺﾘｬ
●Toshiba EXCERIA 16GB Type2国内正規版
こちらはTG-3の購入と同時に購入した国内の正規品です。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21617 kB/sec.
>ds 0
rc=0
Drive size: 30867456 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 75 BF 7F 80 0A 40 00 93 @..2[Y..u....@..
CID:
00000000 02 54 4D 53 44 31 36 47 86 DE 58 C2 6E 00 E3 23 .TMSD16G..X.n..#
Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :SD16G
Product HwRev :8
Product SwRev :6
Serial Number :0xDE58C26E
DateCode.Month :3
DateCode.Year :2014
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 04 00 00 00 04 03 90 02 00 06 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 80 03 32 02 23 82 ....2.#.
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!20MB/Sec越えです･･･やったね☆
値段張った甲斐がありました･･･
●Toshiba EXCERIA MicroSDHC32GB 並行輸入版
今度は並行輸入版の奴です。高速の信号のやり取りを意識してか
いかなる変換アダプターも使用不可と警告がありました。ねむいさんの
使用法では高々50MHzぽっちなので別に関係ありませんが。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22154 kB/sec.
>ds 0
rc=0
Drive size: 61079552 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 E8 FF 7F 80 0A 40 00 AF @..2[Y.......@..
CID:
00000000 02 54 4D 55 43 30 44 33 20 E9 C2 CF A5 00 EC 01 .TMUC0D3 .......
Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :UC0D3
Product HwRev :2
Product SwRev :0
Serial Number :0xE9C2CFA5
DateCode.Month :12
DateCode.Year :2014
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 05 00 00 00 02 02 90 02 00 06 3C 00 ..............<.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 84 03 32 02 29 02 ....2.).
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Security :3
SD Bus Width :5
SD_Spec V4.xx!
Detected as SDHC Card!おおっ！東芝のeMMCv5に匹敵するスピードですよぅ!!
こいつはオススメです☆
●Toshiba8GB MicroSDHC
廉価な東芝製のmicroSDHCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20202 kB/sec.
>ds 0
rc=0
Drive size: 15564800 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 3B 5F 7F 80 0A 40 00 75 @..2[Y..;_...@.u
CID:
00000000 02 54 4D 53 44 30 38 47 56 C0 14 C0 4F 00 B1 C5 .TMSD08GV...O...
Parsing SD CID Register
Manufacturer ID :0x2
OEM/Application ID :TM
Product Name :SD08G
Product HwRev :5
Product SwRev :6
Serial Number :0xC014C04F
DateCode.Month :1
DateCode.Year :2011
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 03 90 08 00 F2 19 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 B5 80 03 28 03 51 02 ....(.Q.
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!これもなかなかですね〜
●Panasonic 2GB MicroSD
380円でたたき売りされていたMicroSDです。
STM32Primer2用に控えで購入していました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 10776 kB/sec.
>ds 0
rc=0
Drive size: 3862528 sectors
Erase block size: 8192 sectors
Default r/w block size: 1024 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 00 7F FF 32 5F 5A 83 AE F6 DB DF FF 8E 80 00 4B ...2_Z.........K
CID:
00000000 01 50 41 53 30 32 47 46 12 43 20 E0 52 00 B6 E1 .PAS02GF.C .R...
Parsing SD CID Register
Manufacturer ID :0x1
OEM/Application ID :PA
Product Name :S02GF
Product HwRev :1
Product SwRev :2
Serial Number :0x4320E052
DateCode.Month :6
DateCode.Year :2011
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 02 02 90 00 10 05 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 25 00 00 00 F0 02 10 .%......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V2.00!
Detected as SDSC Card!まぁこんなものですね･･･
●Panasonicの512MBSLC金色カード
これは他の奴らとは一味違います！！！
Panasonic製の工業用SDカードです！！！
そしてTLCが全盛になった今希少なS・L・C!!!!
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 17939 kB/sec.
>ds 0
rc=0
Drive size: 967680 sectors
Erase block size: 4096 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 00 0E 01 32 5B 59 81 D8 7F FF FF FF 12 40 00 FD ...2[Y.......@..
CID:
00000000 01 50 41 52 46 35 31 32 23 74 EF 95 6D 00 F6 B9 .PARF512#t..m...
Parsing SD CID Register
Manufacturer ID :0x1
OEM/Application ID :PA
Product Name :RF512
Product HwRev :2
Product SwRev :3
Serial Number :0x74EF956D
DateCode.Month :6
DateCode.Year :2015
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 14 03 03 80 00 08 07 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 98 DC 90 26 76 16 08 ............&v..
00000020 01 00 93 02 41 12 22 00 00 00 00 00 00 00 00 40 ....A."........@
00000030 29 29 00 00 10 20 82 88 00 01 C6 00 00 00 17 1F ))... ..........
SCR:
00000000 02 A5 80 00 01 F0 01 01 ........
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDSC Card!あり･･･普通だ･･･ま、まぁ工業用ですからピーキーな性能よりも
安定性とかｿｯﾁのほうがすごいのでしょうね(脂汗)
●名も無き16GB MicroSDHC
1078円でたたき売りされていたMicroSDHCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 18257 kB/sec.
>ds 0
rc=0
Drive size: 31275008 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 77 4D 7F 80 0A 40 00 9D @..2[Y..wM...@..
CID:
00000000 28 42 45 48 30 33 30 39 10 00 00 19 C9 00 B1 ED (BEH0309........
Parsing SD CID Register
Manufacturer ID :0x28
OEM/Application ID :BE
Product Name :H0309
Product HwRev :1
Product SwRev :0
Serial Number :0x000019C9
DateCode.Month :1
DateCode.Year :2011
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 04 00 00 00 04 04 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!･･･たたき売りのくせにやるじゃない(ﾆﾔ
●名も無き256MBMicroSD
こちらは10年位前に6800円で購入した古の256MBのカードです。
まだまだ現役バリバリなのですよぅ
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 12321 kB/sec.
>ds 0
rc=0
Drive size: 499712 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 00 5E 00 32 57 59 83 CF ED B6 FF 87 96 40 00 D3 .^.2WY.......@..
CID:
00000000 4B 46 4D 53 44 20 20 20 10 03 00 25 63 00 69 7D KFMSD ...%c.i}
Parsing SD CID Register
Manufacturer ID :0x4B
OEM/Application ID :FM
Product Name :SD
Product HwRev :1
Product SwRev :0
Serial Number :0x03002563
DateCode.Month :9
DateCode.Year :2006
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 .......(........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 01 25 00 00 00 00 00 00 .%......
Parsing SCR
SD Spec Version :1
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V1.10!
Detected as SDSC Card!大昔のカードなのでSDのバージョンは1.10です。
このカードはBIOSの更新用ブートメモリとしてUSBカードリーダと
組み合わせて今でも使用しております。
●RiDATA 256MB MiniSD
そして更に昔の11年前にMP3プレーヤー用に購入したMiniSDのカードです！
確か9870円くらいで買ったと思いました。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 7666 kB/sec.
>ds 0
rc=0
Drive size: 492544 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: NomalSpeedMode(25.72MHz)
DataBusWidth: 4bit
CSD:
00000000 00 7F 00 32 13 59 81 E0 EE BB 3F FF 16 40 00 E9 ...2.Y....?..@..
CID:
00000000 04 00 00 53 44 00 00 2A 10 00 00 03 3A 00 48 97 ...SD..*....:.H.
Parsing SD CID Register
Manufacturer ID :0x4
OEM/Application ID :<0><0>
Product Name :SD<0><0>*
Product HwRev :1
Product SwRev :0
Serial Number :0x0000033A
DateCode.Month :8
DateCode.Year :2004
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 14 00 00 00 00 00 00 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 00 A5 00 00 00 00 00 00 ........
Parsing SCR
SD Spec Version :0
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V1.0x!
Detected as SDSC Card!なんとSDのバージョンはHighSpeedModeにすら対応していないV1.0です･･･
私が持つ最古のSDカードです。
●ATP ProMAX MiniSD 1GB x150
ねむいさんイチオシのメーカーATP製のカードです。
こちらは箱にSLCと明記されておりました。15000円くらいでヨドバシで
買った記憶があります。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19499 kB/sec.
>ds 0
rc=0
Drive size: 1999872 sectors
Erase block size: 128 sectors
Default r/w block size: 512 bytes
Card type: SDv1
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 00 5E 00 32 5F 59 83 D0 6D B7 FF 9F 96 40 00 8F .^.2_Y..m....@..
CID:
00000000 09 41 50 41 46 4D 44 50 10 45 30 00 C2 00 63 DD .APAFMDP.E0...c.
Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AFMDP
Product HwRev :1
Product SwRev :0
Serial Number :0x453000C2
DateCode.Month :3
DateCode.Year :2006
OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 38 00 00 00 00 00 00 00 00 .......8........
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 01 25 00 00 00 00 00 00 .%......
Parsing SCR
SD Spec Version :1
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :2
SD Bus Width :5
SD_Spec V1.10!
Detected as SDSC Card!やりますね〜！
●ATP MicroSDHC4GB MLC (AF4GUD-ATP023)
こちらはSTM32F4のいつもので使用しているおなじみのATPのMicroSDHCです。
一般用なのでMLCです。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 21173 kB/sec.
>ds 0
rc=0
Drive size: 7861248 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5F 59 00 00 1D FC 7F 80 0A 40 00 97 @..2_Y.......@..
CID:
00000000 09 41 50 41 46 20 55 44 10 26 3B 15 32 00 83 A5 .APAF UD.&;.2...
Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AF UD
Product HwRev :1
Product SwRev :0
Serial Number :0x263B1532
DateCode.Month :3
DateCode.Year :2008
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V2.00!
Detected as SDHC Card!速度も文句なし！
●ATP MicroSDHC4GB SLC (AF4GUDI-5ABXX)
そして同じATPの工業用のMicroSDHCです！！！！！
もちろんSLCなのですよぅ！実力やいかに！？
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 22 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16330 kB/sec.
>ds 0
rc=0
Drive size: 7892992 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 1E 1B 7F 80 0A 40 00 B1 @..2[Y.......@..
CID:
00000000 09 41 50 41 46 20 55 44 10 12 60 75 7A 00 F2 39 .APAF UD..`uz..9
Parsing SD CID Register
Manufacturer ID :0x9
OEM/Application ID :AP
Product Name :AF UD
Product HwRev :1
Product SwRev :0
Serial Number :0x1260757A
DateCode.Month :2
DateCode.Year :2015
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 03 03 90 00 08 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V2.00!
Detected as SDHC Card!ぁ･･･あれ･･･？ま、まぁ工業用ですからピーキーな
性能よりも安定性を強化しているのでしょう(脂汗)
大事な事なので二度言いました。
●Sandisk Ultra8GB MicroSDHC
トリはSanDiskのSDカードたちです！
偽者が乱舞するSandisk製ですがねむいさんいちおうちゃんとしたお店で
買っているので偽者には引っかかっておりません･･･はず･･･
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16421 kB/sec.
>ds 0
rc=0
Drive size: 15523840 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AF @..2[Y..;7...@@.
CID:
00000000 03 53 44 53 55 30 38 47 80 02 37 95 01 00 C6 87 .SDSU08G..7.....
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SU08G
Product HwRev :8
Product SwRev :0
Serial Number :0x02379501
DateCode.Month :6
DateCode.Year :2012
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 04 00 90 00 14 05 1A 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 80 01 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!ふつー･･･
●Sandisk Ultra�� 8GB SDHC
このカードはお尻にUSBの端子が付いていてUSBメモリとしても機能します。
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Apr 3 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14268 kB/sec.
>ds 0
rc=0
Drive size: 15954944 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 3C DC 7F 80 0A 40 40 C5 @..2[Y..<....@@.
CID:
00000000 03 53 44 53 44 30 38 47 80 01 9C 01 36 00 84 65 .SDSD08G....6..e
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SD08G
Product HwRev :8
Product SwRev :0
Serial Number :0x019C0136
DateCode.Month :4
DateCode.Year :2008
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 03 00 00 00 02 02 90 00 0B 05 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 35 00 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :0
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V2.00!
Detected as SDHC Card!機能盛り込みすぎてちょっと速度が遅いですがしかたは無いです。
●Sandisk ExtremePRO SDXC64GB(FAT32フォーマット)
そして！現在TG-3用の記憶媒体としてバリバリに使っていますExtremePROの
64GBのカードです！！！
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 25 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 16448 kB/sec.
>ds 0
rc=0
Drive size: 124735488 sectors
Erase block size: 32768 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 01 DB D3 7F 80 0A 40 40 DF @..2[Y.......@@.
CID:
00000000 03 53 44 53 50 36 34 47 80 F2 D6 14 07 01 01 D5 .SDSP64G........
Parsing SD CID Register
Manufacturer ID :0x3
OEM/Application ID :SD
Product Name :SP64G
Product HwRev :8
Product SwRev :0
Serial Number :0xF2D61407
DateCode.Month :1
DateCode.Year :2016
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 08 00 00 00 04 00 C0 00 0F 05 3A 00 ..............:.
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
SCR:
00000000 02 45 84 03 00 00 00 00 .E......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :1
SD Security :4
SD Bus Width :5
SD_Spec V4.xx!
Detected as SDXC Card!ありゃりゃ･･･
ま･･まぁ･･･FAT32で無理糞フォーマットしてますしそのせいでしょう(脂汗)
カードのﾓﾉとしてはSDのバージョンも4の最新のやつです。
今回の評価でSDバージョンが4の奴はこれと並行輸入版EXCERIAだけでした。
どうでもいいですけどeraseblocksizeが32768セクタもあります。
●I/ODataのClass4 SDHC4GB
ねむいさんのおとうちゃんから｢お前が山に行った時の写真分けてくれ｣と
頼まれ手渡されたどっかの家電量販店で買ってきたかのようなデータ保存用の
やっすいカードです。どうせゴミみたいな性能だろうから哂ってやるつもりで
半ば冷やかしにベンチとってみたのですが･･･
FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 25 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 19063 kB/sec.
>ds 0
rc=0
Drive size: 7878656 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Block)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit
CSD:
00000000 40 0E 00 32 5B 59 00 00 1E 0D 7F 80 0A 40 00 A5 @..2[Y.......@..
CID:
00000000 1D 41 44 53 44 20 20 20 10 A0 90 08 0A 00 02 E3 .ADSD ........
Parsing SD CID Register
Manufacturer ID :0x1D
OEM/Application ID :AD
Product Name :SD
Product HwRev :1
Product SwRev :0
Serial Number :0xA090080A
DateCode.Month :2
DateCode.Year :2000
OCR:
00000000 C0 FF 80 00 ....
SD Status:
00000000 80 00 00 00 02 00 00 00 02 02 90 00 08 11 00 00 ................
00000010 00 00 00 00 00 00 00 00 00 53 4D 49 00 00 00 00 .........SMI....
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 51 00 00 00 00 32 00 00 00 00 00 00 00 ...Q....2.......
SCR:
00000000 02 35 80 00 00 00 00 00 .5......
Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Security :3
SD Bus Width :5
SD_Spec V3.0x!
Detected as SDHC Card!>132949600 bytes read with 19063 kB/sec.
なん･･･だと･･･！？
･･･
こ、こう言うベンチマークの結果は特に気にせず皆様はそれぞれが納得し信頼できる
メーカのSDカードを選んで使用していただければよいと思いますよ(脂汗)
STM32F7を使ってみる11 -最新のeMMCを動かす-
前回までは古き世代の遺産であるマルチメディアカードをSTM32F7で再び動作せしめる
までになりましたが、今回は新しい世代へと進化したeMMCモジュールの動作に
ついに、ついに挑みます！
eMMCは最早カードの形状ではなく、ごく一般的なICの形となっていますがそれが
故に使い慣れたSDカードコネクタとかで使うには少々骨が折れます。
市販のギャングプログラマ用のSDカード変換付きソケットは100$以上するのであんまし
手を出したくはないです…
簡単かつ確実に使う良い方法ないかといろいろ探ってみるとODROIDと言うLinux系の
ARMボード向けのオプションパーツとしてeMMC実装済みのMicroSDの変換基板が販売
されているのを発見しました！
SouthKorea製なのがほんの少し心配でしたが値段も送料込みで38USD
(2016年3月下旬時点)だったので早速注文してみました！！
で、発注後4日くらいで親父の家に届きました。一週間以上かかるかと思いましたが
予想以上に早かったです。Androidを意識した質素の箱の作りで"Do it yourself"
なるコメントがあります。
一応ぷちぷちにくるまれていましたがこの色って静電対策してないやｔ
これって静電対策してないやｔ
まぁでもうごけばいいのですよぅ動けば！！
ボードとしてはｺﾃｺﾃの南朝鮮製ですが実装されているeMMCは東芝製で容量8GB,
そして規格はeMMCv5の最新版です！！！
一応コリアンボードのmicroSDへの変換パタンもやっけつではなく信号のIntegrity
を考慮した配線をしてくれているようです。
eMMCは古いタイプのカードリーダーでは認識すらしない場合があります。
ねむいさんが昨年購入したUSB3.0のTranscend製のカードリーダーでは無事に
認識できました♥
もともとこのeMMCはODROIDのオプションパーツとして販売されているので、
こんな風に最初から何らかのOSが仕込んであります。
ねむいさんはそんなもん関係なくeMMCを使用すること自体が目的なので速攻
FAT32でフォーマットして更地にてやりました！！！
前回の最後でちょろっと漏らしているように実は公開したF7のサンプルでは
既にeMMC(とMMCのブロックアドレッシング)に対応しております。
ビルド時間は結構長いので暇つぶしがてらF7からeMMCのルーチンを移植中の
STM32F4の板に差して反応見てみるかと思ったらなんと普通に認識してしまった…。
拍子抜けするくらいあっさり読めちゃって感動もへったくれもない…
ぇっ！？黒澤ダイヤちゃんのお口がｲｹﾅｲことになってるって！？何のことやらﾊﾊ
虹裏メイドねむいさんは｢ラブライブ!サンシャイン!!｣を応援します。
さてビルドが終わってF7のプログラムの書き換えも終わったのでF4板から外すか
…と思ったら…
あ…あれ…？？？
･･･
案の定HELL朝鮮製ボードに罠がありました…微妙にサイズが大きいようで刺さる
には刺さるんですけど安易に抜けません(意味深)。
無理やり引き抜くと基板で擦れてMicroSDコネクタを壊してしまいます…
てわけで削ります。
いきなりF7-Discoveryで試さなくてよかった…
ｺﾞﾘｺﾞﾘ削ってこんな感じに…
うまいこと削れたのでF7-Discoveryのコネクタにスムーズに差さります。
F7でも無事に認識して画像や動画データも自由自在に読み出しできます♥
このeMMCは8GBの容量でSDHCと同じくブロックアドレッシングになります。
私の移植例ではMMCv4以降に新設されたブートパーティション等にアクセス
するための特別なコマンド群は使用しておらず、SDHC/SDXCと同じ感覚で読み
書きします。腕に自信がある人、私のコードを参考に拡張してください･･･(懇願)
そしていつも通りカード(？)の情報を読み出してみました。
>ds 0
rc=0
Drive size: 15269888 sectors
Erase block size: 1024 sectors
Default r/w block size: 512 bytes
Card type: MMC(Block)
CSD:
00000000 D0 5E 00 32 0F 59 03 FF FF FF FF EF 92 40 00 D3 .^.2.Y.......@..
CID:
00000000 11 01 00 30 30 38 47 45 30 00 5A DD 41 40 B2 0D ...008GE0.Z.A@..
Parsing MMC CID Register
Manufacturer ID :0x11
OEM/Application ID :<0>
Product Name :008GE0
Product Rev :0.0
Serial Number :0x5ADD4140
DateCode.Month :11
DateCode.Year :1999
Detected as MMCv5.0x Device!
OCR:
00000000 C0 FF 80 80 ....MMCv4以降のバージョン判定はExtCSDREVフィールドを参照し解釈する必要
性があります。ちなみにこの東芝のeMMCはv5とのことですがですが読み出すと
ExtCSDREVは”7”となりちゃんとv5のデバイスであることが分かります。
ちなみにdatecodeが1999とあるのはCIDレジスタの年数を示すフィールドが4bit分
しかないので2012年を境に年数が一巡してしまっているからです。最新のMMCAの
データシートではExtCSDREVから2012年以降を判別せよというようになっていますので
一方、SDカードでは年数を示すフィールドは6bit分あるのであと50年くらい安泰です。
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 31 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 22000 kB/sec.
>かつ4bitモードの設定がeMMCで可能ですがご覧のとおり理論値に近い読み出し
速度が出ました。やるじゃない！
FatFs module test terminal for STM32F746NGH6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Mar 31 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 20753 kB/sec.
>と言うわけでユーザー領域のみですがeMMCでもSDHC/SDXCと同じく読み書きする
ことが出来るようになりました！今秋くらいに市場に出回るであろうSTM32F777等の
最強に強まったF7シリーズではSDMMCが二つに増えるので基板付け置きのeMMC
(とかMCP)が今後は発言力を増してくると思います！！
今回の成果はSTM32F4系やSTM32F1系、そしてLPC4088のMCIにも移植しています
のでどんどん試して下さい！ついでにバグもこっそり教えてもらえると助かります☆
OpenOCD小ネタ19 -Nuvotonドライバの統合-
今をさかのぼること2年前、いろんな行き違いによって同じNuvotonのCortex-M0
向けフラッシュ書き込みドライバが同時にマージされる事態になってしまいました。
その間もいろいろあってなかなか更新できなかったのですが今秋に両者を統合
するドライバがマージされたのでようやく報告できた次第です。
さて、この統合されnumicroと名前を変えたこのフラッシュ書き込みドライバは
少しトリッキーな動きをします。それを少し解説します。
●Undocumented Registerの存在
NuvotonのARMマイコンのフラッシュ領域はユーザプログラム用のAPROMとブート
ローダ専用のLDROMの二つがあり、書き換えをするためにはそれぞれ別のフラッシュ
ブートモードから再起動する必要があります。つまりAPROMを書き換えたい場合は
LDROMのブートモードに切り替えコアリセットを掛けるという手間がかかります。
これが公式のマニュアルに記載されている手順です。
しかし！このような煩雑な手順を踏まなくてもどのモードでもAPROM,LDROM,
CONFIGの書き換えそしてチップ全消去コマンドが実行できる方法が解析により
見つかっています。
マニュアルに記載されていないレジスタ0x5000C01Cに1を書き込むとフラッシュ
に対する全てのアクションが出来てしまうようです。Nu-Linkのツールではこれを
自動で行っていることから気づき解析されたみたいですね。
そして上記の成果はOpenOCDに反映されましたがこのときはまだmini51シリーズのみ
だったため、私の手持ちの他のシリーズ(NUC120,NUC220,M051,NANOシリーズ等)で
この技が効くかどうか確認し、OpenOCDの更新が落ち着いたタイミングを見計らって
今回の統合をおこない、無事マージされました。長かった…!
上記の修正を掛けたドライバでNANO130に書いた時のログはこんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/numicro_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.10.0-dev-00036-g48787e1-dirty (2015-10-02-09:14)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : VSLLink SWD mode enabled
swd
adapter speed: 1000 kHz
none separate
cortex_m reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Sep 16 2014)
Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000002d6 msp: 0x20003ff0
auto erase enabled
Info : Device ID: 0x00113034
Info : Device Name: NANO130SE3BN
Info : bank base = 0x00000000, size = 0x0001ec00
Info : Nuvoton NuMicro: Sector Erase ... (0 to 40)
Info : Nuvoton NuMicro: Flash Write ...
wrote 20992 bytes from file main.elf in 4.078360s (5.027 KiB/s)
verified 20800 bytes in 0.281266s (72.218 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05
一応デバッグもできますが今回の統合に至るまでにnuvotonのドライバの他にadi_v5や
cortex-mのコードにかなりの修正が掛かっており、リセット直後の状態が特殊な
nuvoton系のARMマイコンでは正攻法が通じなくなっていました。
そこで上手くデバッグできるようにcfg側も仕込んでトリッキーなことをしています。
gdbが接続した瞬間にresetとhaltを連続してかけ("reset halt"だと駄目)、さらに
プログラムカウンタを強制的に0にしておきます。
当然割り込みベクタの一番頭で停止しますがここでcontinueすると･･･
無事main関数の頭でブレークしました★
ちなみにOpenOCD側だけでは不完全でプロジェクト側も多少の修正は必要でした。
おきぱのNUC120,M0516のプロジェクトはすでに新しいOpenOCDに対応しています。
念のため他の品種も洗ってみたのですがnuvotonドライバだけではなくLPC4300系の
SPIFIの書き込みもおもいくそ影響を受けていて書き込みできてませんでしたorz
↑最後のほうでエラー出てますがコアリセットをソフト的に強制的に掛けてるので
こうなります。動作としては問題ないです。
こちらも現行のOpenOCDで正しく動作するようにcfgファイルに修正をかけておきました
ので皆さん安心して使い倒すことができると思います。
根幹に近い文字通りコアな部分をひっそり変えられると思わぬところで上手く動か
なくなるのはよくある事なので私の目の黒いうちはしっかり注視していこうと思います。
ESP-WROOM-02を使ってみる3 -そんな電源で大丈夫か-
20161231追:
ESP-WROOM-32ではさらにとんでもない自体に！！１！！！
20161231追:
2か月くらい前にESP-WROOM-02の紹介記事を2点書きました。それを多くの方が
紹介してくださったおかげで閑古鳥が鳴いていたこのぶろぐのアクセスも東海自然
歩道攻略時のころの全盛期まで盛り返し私もモチベもﾑｸﾑｸ盛り返しております♥
多くの人の目に触れるとなると当然質問も多く頂くのですが｢電源投入しても
文字列がずっと垂れ流されるだけでコマンドが全く反応しないor最初は上手く
動いてたのに急にずっと文字列(orゴミデータ)が垂れ流しになった！ESP8266が
壊れたぞ！｣という不具合についての相談を多く受けるようになりました。
●文字列がﾀﾞｰｯっと…
共通項は｢文字列(orゴミデータ)が連続して垂れ流されて制御不能になる｣です。
結論から言うとESP-WROOM-02に供給する+3.3Vの電流容量不足で起こる現象
なのですが、そのプロセスは以下のようになります。
1．電源投入or外部リセット
↓
2.ESP8266のPOR/外部リセットのイニシャライズ
(このあたりで文字列(デバッグメッセージ)が吐かれる模様)
↓
3.電気喰いのRF部起動
↓
4.電力消費過多で3.3Vがすぐドロップ
↓
5.3.3Vラインがドロップして2.0V付近になるとESP8266リセット状態になる
↓
6.少したってからLDOの保護機能等が解除で3.3V回復
↓
7."2."に戻る
デバッグメッセージがﾀﾞｰと吐かれた直後にリセット掛かってまたデバッグメッセージが…
を繰り返すので"文字列が吐かれ続けて壊れた"ように見えるわけです。
↑
ねむいさん愛用の秋月さんのXbee用のゲタ基板は150mAのLDOが乗っかっています
がESP8266の電源としてこれを使っていると上記のように2.0V近くまでおもいくそ
ドロップしてリセット->その後負荷が軽くなるので回復->また落ちるを繰り返して
しまいます。
根性があるLDOだと最初は最大定格越えても耐えられるのですが使ってるうちに
段々へばってきて上のサイクルを繰り返し、仕舞にEOSで完全に死んでしまいます。
↑
そんなわけでねむいさんは電流容量1AのぱわふりゃーなLDOを換装して多少の
電流の過渡応答にびくともしない最強に強まった電源に満足(LT1963A持ってくる
までもありません)でした。
したはずでした･･･！
勿論今回はこれだけで終わるわけではなく、皆さんの設計の参考として実際どれ
くらいの電流を消費しているのかを調べてみました。
ねむいさんのXbeeゲタ基板に+3.3Vの電圧と電流を測定できるように加工をして
電源投入直後や投入後の挙動別に各波形を見ていきます。
各種パラメータはもちろんすべてデフォルトの購入時のままです。
ESP-EROOM-02においては購入時のデフォルトはフルパワーです。
電源投入直後
↑の+3.3Vの立ち上がり時の拡大
リセット直後
RF出力時
ぱわふりゃーなLDO使ってるくせになんで3.3Vが思いきりドロップしてんだYO!
答えろYO!という突込みは後で解説することにしてRF出力時は平均280mA(ピーク値
は350mA以上)バリバリに使いまくっているのが分かると思います。
またリセット直後も40mSecもの間200mA以上(ピーク350mA強)ゴリゴリ
消費しています。
ご覧の通り+3.3Vラインに供給する電流容量の事を忘れてESP-WROOM-02を使って
いると大きな電圧ドロップによる不安定な動作に悩まされ続けることになります。
しっかりオシロスコープ使って波形測定して確認する癖付けましょうね…。
ハードウエアの設計に慣れた人ならこんなの事前にオシロで電源ラインの波形を
観測して足回りをしっかり固めておいて当然の基本の"き"なのですが…
ねむいさんの懸念はライトユーザーの方たちがこの問題に引っかかり先に進めなく
なってしまうことです。
プロトタイピング用ボードはハードウエアの差異を隠ぺいしてソフトウエア作りに
集中できるようにするために元となるハードウエアはかなりタフに作りこまれています。
ていうかそうなるべきです。全ては信頼の元に成り立っているのです。
でも残念ながらそうなってないのばっかりですのでこれを機にしっかりオシロ
スコープ使って電圧波形くらいは確認する癖をつけましょうね…。
大事な事なので2度言いました。
macsbug氏の記事では各種Arduinoと組み合わせて使用した際の考察がまとめられて
いますのでプロトタイパーな皆様は一読されることをお勧めします。
氏のブログでは+3.3Vを作るLDOにフォーカスして言及されていますが私が以下で
述べるLDOの入力系統(主に+5V)についての考慮も極めて重要です。
必ず読んでください!!!
●USBの+5Vは大丈夫か
上で行った+3.3Vの波形がドロップしちゃいけないのにドロップしてる件も調べて
みました。私の使用環境ではUSBの+5VからLDOで落として+3.3Vを作っています。
そんなわけで今度は5Vと3.3Vの波形を比較してみました。
オイー！！！！！！！！！
安物USB2.0ハブ(しかもセルフパワーなのに)元の5Vがおもいくそへばっていたorz
ねむいさんが使ってるLDOはDIODES-ZetexのZLDO1117ですが最大ドロップアウトが
1.2V(1A時)ありますので元が3.8V近くまで落ち込むくらい電流ひいてる状態だと
そりゃ駄目ですわ…。
↑DIODES-Zetex ZLDO1117データシートより引用
さっきの波形はRF送信時の約300mA近く引いてる時の電圧ドロップの波形ですが
グラフのまんまきっかり1V以上のドロップアウトですねorz
いくらぱわふりゃーなLDO積んでいても元のVinが貧弱だとこうなってしまいます。
あとコンデンサの容量を必要以上にむやみやたらに増やして茶を濁すのはねむいさんは
全くお勧めしません。今度は突入電流で素子が破損する危険性が出ますので。
てわけで大電流を引き出せられるセルフパワーなUSB3.0ハブの方に差し直して
測り直してみました。大分マシにまりましたね。
上半身に比べて下半身が貧弱だとやっぱりダメなわけですね〜足回りをしっかり
固めるのはプロトタイピングにこそ重要だと思います。
プロトタイピング用ボードだとUSBの+5Vを電源供給源としてそのまま利用する
場面が極めて多く出てくると思います。
何も考えないで使っているとこういった罠に陥って無駄な時間を費やしてしまい
ます。これを機にオシロスコープを使って電圧波形くらいはいちいち確認して
行く癖をつけておきましょう。
大事なことなので3回言いました。
20151203追：
ねむいさん的にはバッテリ駆動を見据えるならMAXで1A~800mA位の小型高効率
降昇圧DCDCを組みESP-WROOM-02専用の+3.3V電源とすることを提案します。
逆にUSBの+5V電源からだけしか使用するつもりがないならば超低ドロップアウトな
LDOであるADP3338、値が張りますが攻守共に最強のLT1963Aを提案します。
20151203追：
●おまけ
それじゃ他のWifiモジュールってESP-EROOM-02に比べてどんだけ電気喰ってるの？
というわけで手持ちのモジュールも測定してみました。
もちろん技適はばっちり取れてるのをチョイスしてます♥
その1：Xbee WiFi S6B
電源投入直後
↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジが違うので注意。
リセット直後
RF出力時
IDDの測定レンジが違うので注意。
XbeeWifi S6Bはリセット直後にガッツリ電流もってくようですね･･･負荷の過渡応答性
にすぐれたDCDC持ってこないと製品レベルに落とし込むのは無理だと思います。
ちなみにBが付かないほうのXbeeWifiはなひたふさんですらどうにもできなかった
のでねむいさんが手なずけることは不可能です････そもそもB無し持ってませんし。
その2：GS1011MIC
電源投入直後
↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジがこれだけ違うので注意。
リセット直後
RF出力時
GS1011MICは今となっては古き世代のモジュールですが瞬間最大電流は低めに
抑えられています。Adhoc等の限定した用途ならば今でも十分に活躍できるモ
ジュールといえるでしょう。
STM32F7を使ってみる2 -STM32CubeF7移植への道-
STM32F7シリーズは今年から量産開始した新しいマイコンです。つまり昔から
STM32を昔から弄ってる人にとってはおなじみだったStandard Peripheral Library
(=SPL)のF7版なぞ影も形もなく、STM32CubeF7ライブラリ通称HALライブラリ
しか存在いたしません！
ChaNさんクラスの実力がある人ならリファレンスマニュアルからレジスタ構成を
引っ張ってきて自前のペリフェラルライブラリこさえるのでしょうけどねむいさんに
そんな力があるはずもなくなすすべもなくSTマイクロのエコシステムの一部に
とりこまれてしま…ぅ･･･
まだまだだぁ！！！
幸いにもCubeF7ライブラリの中にはSW4STM32(System Workbench for STM32)
なるEclipseベースのフリーのIDEがあり、コンパイラはGCCを使用していますので
これを分析することによって私のコマンドライン&makeの環境移植へのとっかかり
を見つけることが出来ました。
ところでなんでEclipse使ってるのに全身から血を吹き出して死なないのかこの
嘘吐きめと突っ込みたいでしょうが私はメーカーお仕着せの各種設定完了済の
Eclipseのカスタム版IDEでは無傷です。あくまで死ぬのは未設定の素のEclipseで
攻撃された時だけです。あといないさんがスカートをたくし上げて下着を見せてるイラストを
見せられただけでも死ぬので絶対に見せないでください
絶対にですよぅ！！！！
それはおいといてSTM32F7-Discoveryを使ってF7版のいつものの構築に移ります。
昨年の時点でNucleo系の板はSPLからHALライブラリに引っ越ししておりました。
しかしあくまでUARTやI2Cと言った基本のライブラリを動かす程度に留まって
いたのですが今回はSDRAMやFatFsなどを動かすところまで行きます。
STM32F7になってメモリ構成がF4よりもはるかに複雑になりましたが基本は
全く変わっていません。恐れずにF4と同じようにプランを練っていきました。
TCMのうちユーザーが触ることができるDTCMはF4ではできなかったDMAができる
ようになったので細かいことは気にせずスタック/Auto変数領域に割り振る
ことができます。CubeF7のExampleではDTCMの初めからメインSRAMの終わりまで
をまるまる一本の巨大SRAMとして使っていますので細かいこと気にするなと
言うことなのでしょう。実際DTCM〜SRAM2までリニアに繋がってますし。
↑実はこれが伏線だった…
そんなわけでいつものGCCのビルド環境のひな形が出来ました
先ずは基本の"き"LED点滅とUARTから。
LEDはF7-Disacovery上ではArduinoUNOライクなコネクタピンのSCKに
相当するPI1です。
なお、昨年くらいのCubeF4のアップデートで気づいたのですがGPIOのビット
単位でセット/リセットが可能なレジスタSBRR/BRRと言うのが昔はおなじみ
だったと思いますがそれが廃止され32bitのSBRRのみとなってやがります###
ビット単位でI/Oをやり取りする際にこれは超不便且つビットアクセスのための
新しくできたHALライブラリのオーバヘッドがでかすぎるので旧来のGPIOの
構造体を作って昔と同じように16bit幅のSBRR/BRRレジスタをアクセス
できるようにしました。
UARTはSTLink/V2-1のVCP入出力が繋がるUSART1ポートのPA9(TX)、そして
GPIOB7(RX)です。RXピンはおなじみのPA10じゃないのでご注意を！
と言うわけでこの2つはF4版NUCELOを参考にF7用にあてはめるだけでOKでした。
もちろんprintf関数などのnewlibの関数群との結合も余裕です★
ここでちょっと注意ですがSTLink/V2-1でVCPを使う際に特定のUSB3.0
ホストに差すとSTLink/V2-1側から送信するUARTの信号が正常に出力
されない場合があることを発見しました。
その特定のUSBホストと言うのはFL1100なのですが上記の画像のように
めちゃくちゃな信号が出力されてSTM32F7側と正常に通信ができません。
もしUSB3.0ポートで上手くいかない場合はUSB2.0ポートに差し直して
試してみてください。
お次はSDRAMです、F7-Discoveryには128MbitのSDRAMが搭載されています。
こちらもBSPの初期化コードを参考にねむいさんの環境に嵌めて行って危なげなく
動作せしめることが出来ました。このボードにおいてはSDRAMBank1に配置されて
いて0xC0000000が開始アドレスとなっています。
STM32F7でFMCを使ってSDRAMを使用する場合、F7側はデータバスが16bit分
しかないので32bitの変数のアクセスはAHBバスで16*2bitに分割転送されます。
そんなわけでこのボード上では上位16bit分のデータバスを男らしくバッサリ
捨てており容量は128MBitありますが実質64MBit分しか使えませんorz
また、Example曰く実装されたSDRAMが安定動作するシステムクロックの
上限は200MHz、その時のSDRAMCLKの上限は100MHzになるので、
(↑根拠としてSTM32F7のデータシートに下記の記述がありました。
For 3.0 V≤ VDD≤ 3.6 V, maximum FMC_SDCLK = 100 MHz at CL=20 pF (on FMC_SDCLK).)
単純計算で100MHz*16=1600MBps
が理論値となります。なんかちょっともったいない使い方ですね…。
前回の記事でたけさんと言う方からリクエスト貰いましたのでSDRAMのR/W
性能を測定してみました。4MByte分(下述)を16bit変数単位で読み書きした値です。
D/I-Cacheは有効にしていますが妙に数値が低いのは私のコーディングが悪い
せいでしょうか･･･
最後にFatFsです。CubeF7謹製のFatFsのローレベルドライバはやたら凝っていて
USB-OTGのUSB-MSCの接続も想定したつくりになっています。FatFSで必須な
関数群はFATFS_LinkDriverなる関数で結合する仕組みとなっています。
今回からはSTのスタイルに倣ってそれを積極的に使うようにしました。
といっても私のプロジェクト向けにほんの少しの変更をしただけですが。
まだTFT-LCDのドライブまでは進めてないのでUARTからのコマンドでFatFsの
動作を確認しました。F7-DiscoveryではSDIO改めSDMMCインターフェースが
出ていてSDカードからのデータを高速にやり取りできます。
いつものごとく読み出し速度を調べてみました。CubeF7のExampleではSDMMCの
クロックは潰しの効くNomalMode(25MHz以下)に抑えられているのでF4の25MHzと
さほど変わりませんね。
CubeF7のライブラリを調べているとDMAは全く使用してないFIFOポーリングで
読み書きを行っていることが分かりましたがHALライブラリにはDMAを使用する
関数も用意されていてほんの少しの改修でDMA化できるので試してみました
が…！
なん…だと…！？
つづく！
STM32F7はぢめました
昨年秋にプレスリリースで発表されたSTM32F7ですが私がESP-ROOM-02弄りに
夢中になってる間にひっそりと市場に流通しておりました。
ﾋを見てたら国内外問わず既に入手してOpenOCDでバリバリ使い倒してる人たちもいて
STM32好きの私としてはすっかり流れに取り残された感じですがDigiKeyで大量に在庫
していたので私も一つ購入してみました。
目の前に現れたSTM32F7-Discoveryは私の知ってるDiscovery系のキットの想像を
超えた液晶もSDカードスロットも外部SDRAMもQSPI-ROMもついた夢の全部載せでした！
ちなみに液晶のタッチパネルは抵抗膜式ではなくなんと静電容量式です！
なんてゴージャスな…
Cortex-M7コアを持つSTM32F746NGH6が搭載されています。スペックについては昨年
秋も触れましたが量産開始後に最大動作周波数が200->216MHzにパワーアップして
ます。デバッガはSTLinkV2-1が搭載されています。
当然のごとくSDRAMが搭載されています。Micronの128MBitのSDRAMです。
同じくSTM32F7シリーズの目玉の一つQ(uad)SPI-ROMです。LPC4000シリーズの
SPIFIと同じくリニアなアクセスができるのが特徴です。FontX2ファイル等の
大規模データは一切合財ここにぶち込みましょう！
また、Ethernet用のPHYも搭載です。接続するピン数が少ないRMII方式で
STM32F7と接続されています。
さらにUSB-HighSpeed用のPHYまでついています！！こちらはULPIで接続されます。
後で触れますがUSBメモリを接続するのにちょうど良いですね。
さらにさらにI2S-Codecも搭載されています！！！STM32F4でも搭載されていましたが
同じように"いつもの"が出来そうです。SAIインターフェースで接続されています。
そしてこれだけそろってお値段はなななんと$50ですよ奥さん！！(DigiKeyより)
こんな時代になったのですね…2009年のころは全く考えられなかったのですが…
しみじみ
しみじみするのはその辺にして早速いじってみました。
STLink側のUSB-miniBケーブルをPCと接続するとドライバを読み込んだ後STM32F7
側にも電源が供給されてプログラムが走り出します。
すぐにナウいロゴが出てきます。
すぐにメニュー画面になり、タップでいくつかのアプリケーションが選べるように
なっています。しかもCPUの負荷率もリアルタイムで表示されます。
200MHzで動いているので結構発熱します。F4シリーズと違ってΔTは10度以上あると
思ってください。それでも他の品種の同周波数のものと比べると低いほうですが。
静電容量式タッチパネル(CTP)なので物理で押してもだめです。指で操作しましょ。
先ずは"audioplayer"です。USBメモリに仕込んだwaveファイルを読み込んで再生し
ます。デモはHS側のUSB-OTGだけしか反応しませんのでご注意ください。USB-FSや
SDカードは未実装のようです。
再生してる所です。音量調節が狭くて音量を上げようとすると指がメニューに
あたってしまって最初の画面に戻ってしまいがちです。どうでもいいですが。
infoメニューでは現在の動作周波数やファームウエアのバージョンが表示されます、
ファームウェアとやらは勿論STM32CubeF7の事です…。
どうでもいいことですがたまに異様にCPU負荷が100%になって動作が異様にもっさり
したり固まったりするのですが私の操作が早すぎるせいなのでしょうか？？？
さて、デモプログラムを触るのはこの辺にしてねむいさんのいつものの準備を、
GCCのコマンドラインビルドできる環境を固めて行こうと思います。OpenOCDはまだ
レビュー段階ですがSTM32F7フラッシュ書き込み用パッチが公開されています。
糞ややこしいのですがパッチはCortex-M7用とSTM32F7用の2種類か必要でした
http://openocd.zylin.com/#/c/2786/
http://openocd.zylin.com/#/c/2784/
http://openocd.zylin.com/#/c/2753/4
http://openocd.zylin.com/#/c/2753/5
2753は要注意です。#5のパッチだけあててもF7対応になりません！
まぁやり方さえわかればビルドはいつもどおりなのでらくちんです★
バイナリは既にSTM32F7対応に更新してあります♥
cfgファイル群も更新しましたのでどうぞ。
STLink/V2-1もファームがM11に更新されていますので事前にアップデートして
おきましょう。STLink-Utilityも3.6に更新しておいてください。
20150714追:
M11に更新しないとOpenOCDで書き込むことができませんのでご注意！！！！
まだF7向けのGCCプロジェクトはこさえていないので記事を書く2日前に1.0.1に
アップデートしたばっかリのCubeF7のF7Discovery向けのデモプログラムの
ビルド済みhexファイルをOpenOCDから焼いてみます。その前にSTLink-Utilityで
接続し、デモプログラムのhexを読み込ませてみました
このhexファイル、19MByteも有るのですがフォントと画像データがあるQSPIの領域も
含まれているようです(0x90000000以降の領域)。まだ外付けのQSPIの読み書きには
対応していないので内蔵フラッシュしか書き込むことができませんがQSPIに仕込んで
あるデータはシカトして内蔵フラッシュのだけ無理やり更新できます。
STLink-UtilityのExternalFlashLoaderにF7Discovery向けのQSPIドライバ無いんです
けぉ･･･###それはおいといてOpenOCDに話を移します！！！！
案の定QSPIの領域ではエラーが出ますが何とかフラッシュは書き込みできてます。
無事ファームウエアをV1.0.1に変更することができました。
そんなわけでSTM32F7をほんとに触りだけでしたが触れてみました。
これからいつものビルド環境に合わせたプロジェクト作りを進めて行きたいと思います。
F4の時にCubeF4向けにペリフェラルドライバの移植を試みましたが結局UARTまでしか
実装できなかったので今度こそ本気出します！！
(2年ぶり4度目)
技適マーク付きESP8266モジュール ESP-WROOM-02 を使ってみる
デ
デ
ド ン ！
ついにっ･･･！ついにきたっ･･･！
今年の2月に"ESP8266モジュール"が技適取れたとの報(ともの技術メモさん情報より)を
受けて以来、ねむいさんはず〜〜〜〜〜〜〜〜〜っと待っていました！！！
ESP8266モジュール自体は去年から活気付いてきていますがそれまではもちろん技適
なぞ取れていない真っ黒な代物で日本国内ではいつものお仕置き部屋でしか扱えなかっ
たブツでしたが･･･！ESP8266チップ製造元のEspressifさん自らがワイヤレスモジュー
ルを製造に乗り出した折に日本の技適を含む各国の認証を取得して日本でも堂々と
使うことができるようにしてくれました！
しかも従来のモジュールたちより遥かに安い単価で！！！
現在技適マークつきの"ESP-WROOM-02"モジュールを確実に購入できるのはタオバオの
本家店舗かもしくは検索で出てくるamazonの国内店舗からのようです。ねむいさんは
タオバオの本家から代行業者さん経由で購入しましたが10個で国際/国内送料コミコミ
で7000円以下でしたから単純計算で一つ当たり700円以下になり時間はかかりましたが
満足しています♥(代行業者さん使ったの数年ぶりです)
注意すべきはAliexpressやebayで"ESP-WROOM-02"として販売されているモジュール
です。こいつらは各国の認証が取れる前の開発者向けのモデルを取り扱っていて技適
マークどころかFCCマークすら存在しない超はずれのモジュールばっかりです！！！
先走って買うとまずハズレが送りつけられるので急がば回れの精神で落ち着いて
確実に技適マーク付きのやつを買える購入先をしっかり選びましょう。
ねむいさんのような哀れな子羊を増やさないように･･･掴まされたorz
腹いせに技適じゃない版のケース引っぺがしてやりました！！
SPI-ROMは貴重なので回収しましょう･･･
さて、それでは早速使っていきましょう！ESP-WROOM-02は電源立ち上がり後の
動作を決めるための外部プルアップやプルダウンすべき端子がいくつか存在しています。
配線を適当にしてると動作不良の元になるのでしっかりと！
前回と同じくピン配置を考案してみました。秋月さんのXBee変換モジュール上に乗っ
けることを想定した配置です。今回も合言葉はｂ･･･うぐぐ･･･頭が･･･
緑の網掛けの部分は外部接続必須の端子です。ブートセレクトを制御するIO15,IO2,
そしてIO0の端子の処理についてはほとんどの局面でSPI-ROMブートしか使うことは
ないと思いますがUARTブートローダモードなどに手軽に切り替えられるように10kohm
程度の抵抗でプルアップ/プルダウンすべきです。
こんなかんじで秋月さんちのRN-42用Xbee変換基板に搭載してみました。ひとまず
最低限必要なピンを配線しておきました。
ちなみにESP-WROOM-02もwi-fiモジュールなのでリセット直後はどうしても電流を
消費してしまいがちです。XBee用2.54ｍｍピッチ変換基板に元から乗っている
電流容量150mAのLDOだと到底まかなえないので私はDIODES-Zetex社のセラミック
コンデンサ使用可能なZLDO1117で3.3Vを供給しています。
さらに今は1608サイズで温度特性の良い大容量MLCCが秋月さんで購入できるので
少ないスペースの実装にフル活用しています★
まずはUARTからターミナルを用いてESP-WROOM-02と会話してみましょう。
デフォルトのUARTの設定は115200bps,N,8,1でフロー制御無しです。
また、ATコマンドの終端はCR+LFが必須となりますので
ご注意ください。
まずは基本の｢AT｣
お次はバージョンチェックコマンド｢AT+GMR｣です。技適版ESP-WROOM-02は
5月上旬に量産開始でしたからほんとに初期のものですね〜。
今はATバージョンも0.25まで進んでます。
UARTで通信できていることが確認できたらお次はwi-fiの通信を使ってみます。
通常のUARTのように使用できる透過モードでwifi2serial化してみましょう。
まずは事前にホストPCとwifi接続し、さらにNetCatを立ち上げて接続待ち状態にして
おきます。今回は1000番ポートと使用しますのでコマンドは下記のようにします
｢nc.exe -L -p 1000」
ESP-WROOM-02は購入直後はSoftAPモードになっているはずなのでたとえば
ホストPCとwifi接続した時のホストのIPアドレスが192.168.4.2ならば･･･
｢AT+CIPSTART="TCP","192.168.4.2",1000｣とします。
コマンドが成功したら上記のようにCONNECT OKが帰ってきます。
接続に成功したら｢AT+CIPMODE=1｣でコマンド透過モードに切り替えます。
このコマンドを打っただけではまだ切り替わりません。
さらに｢AT+CIPSEND｣を打つことで｢>｣がUART側ターミナルに現れてようやく
相互通信が可能になります。
Nemuisan!を送信してみました。NetCatの端末のほうに送信できています。
逆にInaisan!をNetCat側から送信してみました。
UARTのターミナルにしっかりInaisan!が現れましたね♥
透過モードではATコマンドが使用不可能になるのですが｢+++｣を打ち込むと
解除できます。その代わり｢+++｣をすばやく打ち込まないと駄目です。
一旦ATコマンドモードに戻っても｢AT+CIPSEND｣ですぐに透過モードに
復帰可能です。
という感じに取り急ぎですが購入直後から簡単にできるごく基本的な操作を
紹介しました。こんな凄まじいモジュールが技適マークつきで1000円以下で
購入できて手軽に利用できるようになるなんて(なんか前回もいったような
気がしますが)ほんとに良い時代になりましたね♥
新しい時代の幕開けです！
技適マーク付き★RN-42とRN-41を使ってみる
これがっ！
技適(このモジュールでは工事設計認証)
マークだっッ！！！！
はぁはぁ…ようやく電磁波と騒音と振動が遮断されたお仕置き部屋から出ることが
できた…♥なんだかねむいさんもきれいな体に成れたって感じです…
かつては電波法の絡みで脱着可能なコネクタを必ず持つモジュール以外では認可が
降りなかったせいで微妙に使いづらく一つ1万円以上もしやがっていたBluetoothSPP
モジュールですが…、
少し前に電波法に規制緩和があり半田付けタイプのモジュールにも技適マークを
貼ることが許されるようになり、2015年現在では秋月さんよりMicroChip社製の(元
RovingNetworks製)のRN-42を購入することで"確実に"技適マークがモジュールに
付されているBluetoothSPPモジュールを安価に入手し堂々と使用する事ができます♥
ちなみに"確実に"と強調した理由は技適(TELEC)の認証が降りていてもモジュール
本体に技適マークが貼られたり刻印されていない物が流通しているからで、特に
中華系海外通販などでは技適マークが無い品種が圧倒的に多く購入して実物を確か
めるまで分からず結局お金と時間を無駄にしてしまうことが多いです。
秋月さんちで購入できるRN-42の素の(半田付けタイプ)モジュールは1700円とかつて
のﾎﾞｯﾀ価格の連中と比べると破格です。しかもHC-05とかと違って電波法違反に
ならずいろんな場所で思う存分使いまくりできます。さらに市場に捨て値で出回って
いるHC-05とその眷属ほとんどが性能足らずのぱちもんなのを鑑みるとRN-42がいかに
非常に安価でなおかつ安心して使用できるモジュールであるかが分かります。
因みにHC-05の正規品は国際送料合わせると秋月さんとこでRN-42買う方が安くなり
なおかつ到達距離もHC-05より性能が高いので、2015年の今ではわざわざHC-05他
技適マークなしの怪しい中華モジュールをコソコソ使う理由が何一つ無いです。
ぇ？私？私はちゃんとキワモノなのを理解して電波法違反にならない様に電磁波と
振動と騒音が遮断されたお仕置き部屋で紹介してきましたのでいいんです。
私はいいんです！
ｹﾞﾌﾝｹﾞﾌﾌﾝ････せっかくきれいな体になったのにまたダーティになりかけたので
これからはこのRN-42を真面目に使っていくことにしましょう…
私が秋月さんとこで購入したのはモジュール単品に加えてXBee風に変換基板を
あつらえたものです。XBee感覚で使用できるのでお手軽です★現在はさらに安価な
秋月オリジナルのモジュールもありお求め易くなっています♥
いつもの汎用無線モジュールドックでXbeeと同じように接続!
しかし･･･
最初にホストPCで認識させたときはなんでかBuetoothHIDデバイスになってしまい
ました。どうやらデフォルトの設定では電源投入時にIO11をHiにすると強制的に
HIDキーボードになってしまうようです。もともと本家Xbee用の下駄を転用していて
XBeeのファーム更新で使うDTRが丁度RN-42モジュールのIO11につながることになる
ので私の環境では頻繁にこうなっちゃいます。
HIDキーボードモードをキャンセルしたい場合は後でも紹介しますがコマンドモード
で"SH,0000"を送信してやると常にSPPモードで使用可能になります。HIDモード不要
なら真っ先に設定しちゃったほうがいいでしょう、このほか、RN-42ではHC-05たち
とは比べ物にならないくらい幅広い柔軟な設定ができます。
(どっちも同じCSRのBC417なのに)
SPPモードで認識するとこんな感じになります。
XBee風のRN-42のピン配置をまとめてみました。電源投入時不用意にHiレベルにして
しまわないように使わないピンはNCに、その一方でハンドシェイク不要の場合はCTS
とRTSは直結にしておいた方が無難です。
オリジナルのXBeeと比べるとフロー制御用のCTSとRTSが逆のあべこべになので
XBeeアダプタを流用されるときは特に注意してください！！ファック１！！！！！
また、公式のデータシートでは一部に誤植まであってGPIO6と8の説明があべこべに
なってたり何故かGPIO7が二つ存在していやがるのでご注意ください。
ひとまずXBee風のRN-42の購入直後から簡単な設定までもう一度やってみましょうか。
ホストPCとUARTで繋がる状態にしてUARTのターミナルを下記の設定にします。
・115200bps,N,8,1
・フローコントロールあり(RTS/CTS)
このフローコントロールありが曲者です。前途のようにちゃんとした手順でホストと
RTS/CTSを繋いでおくか、もしくはXBee風のRN-42側でRTSとCTSを直結にして
おきましょう。解放は厳禁です！
こんな感じに直結用の切り替えスイッチつけておくと楽です★
電源投入後は接続待ち状態になります。この間にターミナルから"$$$"を打ち込む
ことによりコマンドモードに入ることができます。各コマンドは改行をもって受け
付けられます。改行コードはCRもしくはCRLFとしてください。
・コマンドモードに入る
$$$
・ファームウエアバージョン確認
V
・設定を工場出荷時に全て戻す
SF,1
・ボーレートを230400bps,N,8,1に変更
(リセット後に反映されます。コマンドモードも設定されたボーレートとなります。)
SU,230400
・HIDモード切り替え用キーを無効にする
SH,0000
・PINコード2613に変更する
SP,2613
・コマンドモードを抜ける
---
設定がちゃんと反映されていればモジュールをリセット後ターミナルを230400bpsで
開きなおしてコマンドモードに入り"D"コマンドで上記のように表示されます。
ちなみに"R,1"でソフトウエアリセットも可能です。
Bluetooth側の仮想COMポートとホストとの通信はもちろんバッチリです♥
ちなみにUARTからだけでなくBluetooth側の仮想COMからも同じく設定が可能です★
ところでRN-42よりさらにハイパワーなRN-41というClass1な最強に強まった
モジュールも存在しています。
以前は技適を取得できていなかったのですが最近取得されて、技適マークの入った
モジュールが出回っています。
もちろんねむいさんも入手済みです♥Mouserはこの技適マーク入りのモジュールが
"確実に"購入できます。使い方はRN-42と同じですがRN-41はClass1のハイパワーな送信
(デフォルトが最強出力設定になってる)が可能なので当然消費電流も多く、最大100mA,
RN-42の2倍以上電力を消費しますので電源周りも強化必須です！
しつこいくらいにアピール！！！！
秋月さんちで販売されているXBee風変換基板でRN-41もBee化してみました。
合言葉はbe･･･うっ･･･あ、頭がッ･･･！
さて、せっかく日本国内で堂々とお外で使いたおせるモジュールを手に入れたので
屋外で実践してみたいところですね･･･自宅からそれほど遠くなく、100m以上
障害物がない広い敷地がある場所といえば･･･
京都御苑(GYOEN)! Kyoto Imperial palace park!
ここなら思い存分実験が可能です！
そうだねお散歩ついでだね。
RN-41/42側は携帯用USB電源を使って電源供給し離れた場所に置きます。
ホストPC側はずーっと昔に買って今も使っているPLANEXのClass1の
BluetoothUSBドングルをつけて何mくらいまでデバイスが見えるか確かめてみました。
RN-42はClass2で額面はオープンサイトで飛距離10m程度のはずなのですが、
なんか10mどころか20mくらいまでデバイス安定してつかめました･･･！？
頑張ったら不安定でしたが30mまでいけたです･･･RN-41いらんやん!
お次は本チャンのRN-41です！
･･･
これ余裕で100m以上あるんじゃないかな･･･
力こそパワー！
そんなわけでよほど力を欲しない限りは無理してRN-41使わなくてもRN-42で
事足りると思います。無線モジュールはここ数年で規制の面でも値段の面でも
ハードルが低くなってほんとに良い環境になってきましたね♥
OpenOCD小ネタ18 -v0.9.0正式リリース-
なんかすっかり一年周期になっちゃってますがOpenOCDのバージョンがようやく
上がり、v0.9.0の正式リリースとなりました！
v0.9.0では使いやすさと安定性がさらに向上し、新規に追加されたARM/MIPSの
各品種のフラッシュ書き込みドライバも追加されています。さらにSTM32-Nucleo
等のデバッガ付き評価ボードのコンフィグファイルたちも充実するようになり、
益々便利となっております。
今回の正式リリースに当たり、私も数多くの貢献をしてきました。
黄色で網掛けした部分が私が手を加えた箇所です。
フラッシュドライバはNxP系の新規品種に力入れてます。
kinetisも一部手を加えておりますがFreeScale公式でも独自にパッチをあてて
FreeScale自身がリリースしているIDEに取り込んでいるようでこれからの発展
が望まれます…がFreeScaleがNxPに吸収されたのでどうなることやら…
2015年現在は完全無料のIDEな開発環境が増えてOpenOCDの出番は全く無くなり
ましたが、私はOpenOCDをARMマイコンのフラッシュ書き込み&デバッグツール
としてこれからもびしばしつかってびしばしパッチを上げていくつもりですので
ご期待ください！！！！
OpenOCDの慣例として正式バージョンが上がったらgitにあるdev版はバージョンが
一つ上がることになります。私てっきり0.9.0の次は1.0.0になるのかと思ってい
ましたがまさかの0.10.0でしたのでおそらくver1.0.0になるのは90年後くらい
かなと見てます。
おきぱのOpenOCDバイナリは既に0.10.0になったものを上げています。野良ビルドは
信用ならんから使わんと何度も指摘されてきましたので今回からようやくSHA-1
ハッシュ値を付けることにしました。私が独自に当てた有用なパッチも勿論全部
公開しております。
あとバイナリにはibusb-1.0やlibftdi1のDLLも最新のコミットを適用/修正された
最新のものを収録しております。USB3.0がらみでトラブルを抱えていた人たちからも
これなら動く！と取り上げられてて意外と国外の人たちにも好評です。
最後になりましたが、昨年も言及しましたがダブってコミットされてしまった
Nuvotonのフラッシュドライバをようやく統一出来るめどが付きましたので
バージョン上がってからの私の最初の仕事はNuvoton一色になりそうです。
JTAGKey2互換回路をもっと使ってみる3 -決着をつけてやる！-
とりあえず回路図見たい奴は此処や！
●モロ!
2010年に始まり2013年に一応の決着を見たはずのJTAGKey2互換回路製作ですが･･･
ねむいさんは未だモロにこだわっていた。尤もここでいうモロは未加工の紳士画像を
虹裏に張り付けせしめる野蛮な行為ではなく、FT2232HのLVTTLの出力を電圧レベル
トランスレーター74LVCE1G125の5V動作時のCMOS入力に直接モロに入力せしめる
乱暴な行為を指します。
JTAGKey2互換回路において、モロで何が悪いかというとターゲットの電圧が5V系で
動作してるケースです。このとき74LVCE1G125のVIHは3.5V以上となり、FT2232Hの
LVTTLの3.3Vの出力では規格を満たすことができません。
逆に74AHCT541等の高速なバッファを挟んで正規に5VCMOSレベルまで上げてみまし
たが今度はAHCTバッファの大きな伝搬遅延が影響してFT2232Hの特徴である30MHz
動作が出来なくなってしまいました。
そんなわけで私は5V系で電圧・動作温度にマージンをかなり取ってモロった時の動作に
問題が無いことを確認し、規格は満たしてないけど私の回路図と指定した部品使えば
5V系でも実力値で問題なく使えます！…とお茶を濁していました。
しかし心の奥底でルールに反した事をしているとわだかまりを残したまま、TTLレベル
入力でなおかつ1.4〜5.5Vの電圧範囲で動き、それでいて伝播遅延も少ない夢のような
デバイスの到来を期待しておりました…。
●ｱﾁｬﾓ･･･
時は流れ、半導体製造プロセスも進化したおかげか5V動作時にTTLレベルの入力電圧
範囲を持ち、それでいて速度もそこそこ早く動作電圧範囲もそこそこ広いまさに待ち望
んでいたバッファICがリリースされておりました！TIから2014年秋口にリリースされた
LV系レベルシフタSN74LV4T125です！
以前からワンゲートロジックのSN74LV1T125は既に出ていたましたがSN74LV4T125は
4回路ぶんコミコミでなおかつ出力電流と伝搬遅延特性が改善されています。
電圧範囲は1.60~5.5Vとちょっと電圧下限の保証が低いけどこれなら勝てる！！
しかし…
遅延で1ビットずつずれてやがる…orz
ちなみに正常に認識した時はこのような感じになるはずでした。
なんか包帯ぐるぐる巻きの猪狩さんに気を取られているうちに佐山聡似の不気味な飴玉
レスラーに不意打ちを受けてさらにチョビ髭ノッポなキックボクサー崩れのレスラー(？)
に追い打ち喰らって｢あちゃ〜〜もろ････｣とか言われたような気分です。
やはりTTL入力を実現するため追加されているはずの内部ゲートの遅延がかなり
足を引っ張り結局74AHCT541を経由させたのと同じになっちゃいました。
そんなわけで安きに逃げるのは止めて既存のFT2232Hを使用している+5V動作を
保障しているJTAGアダプタたちは実際にどのようにして電圧レベルの変換を行い、
かつ速度も保証しているのかじっくり調査をしてみることにしました…。
●あくまでもモロにこだわる
夜逃げしたAmontecの過去の資料を穴の開くほど調べてみるとオリジナルJTAGKey2
のサポート"電圧"は確かに1.4V〜5.5Vでした。
この"電圧"と言うのはターゲット電圧(Vtgt)そのものを指し、JTAGインターフェース
のI/Oの電圧レベルではありません。AmontecJTAGKey2の紹介文をよく読んでみると、
"5V"ではなくわざわざ"5VTTL"と明記されています。5VTTLの出力は5VCMOSの
入力を満たすことができませんのでオリジナルのJTAGKey2はVtgtが5Vであっても5V
フルスイングのCMOSレベルの出力を出せていなかった可能性があります。
ほんとにそうなのかは販売元のAmontec及びAmontecの中の人にI/Oの電圧特性に
ついて詳細を聞けばよいのですが残念ながら夜逃げして早数年経った今はそれはかない
ません。しかもいくつかMLに残された中の人の軌跡を手繰ってみると中の人はサポート
下限は1.4Vのはずなのに1.2Vとのたまっていたり5VCMOSサポート！とおもいくそ
のたまっていたり議論中に突然Amontecの製品の宣伝をしだしたり挙句の果てに"問題は
モニタとイスの間にある!(=お前もう出てけ!)"と言われたり夜逃げしてからは"あいつ
もう死んだんじゃねーの？"とか言われたりﾎﾞﾛｸｿです。最早あまりのクソコテっぷりに
Switzer版ぴるすにしか見えないんですけぉ…
ねむいさんも彼を墓から引きずり出して殴る蹴るの残虐行為はしたくはないのですが、
オリジナルのJTAGKey2の電圧/速度スペックについてはほんとに額面通りであるのか？
懐疑的にならざるを得ませんでした。
とにもかくにもI/O電圧のレベルの上限は5VCMOSではなく、5VTTLレベルであること
は明確となりましたので一歩前進です。5VTTLレベルの出力規格2.4V以上をみたし、
なおかつFT2232Hの出力(3.3V-LVTTL)と74LVCE1G125たちのVIH(0.75VDD)を満たす
ためにはVtgtから何らかの形で電圧を落とし74LVCE1G125に掛かる電圧(Vrefとします)
の上限値を4.0V付近にクランプしてやれば解決です。
また乱暴なことを…と言いたい方もいらっしゃいますかと思いますが実はこの技、5V系
なVtgtで受けつつTTLレベルの電圧をやり取りするために実際に商業向けの商品にも
使用されているれっきとしたものです。それが使われている例をご紹介します。
↑xilinx platformcable データシートより引用
xilinxのプラットフォームケーブルUSBI/IIはデータシートに入出力バッファについて
の極めて有用な解説が記載されています(ここまで細かい資料って昔あったっけ????)
↑xilinx platformcable データシートより引用
プラットフォームケーブルはJTAGの出力にはUHSBufferなるNC7SZ125が使用され、TDO等の
入力には3.3V動作の超高速コンパレータで約1V前後のスレッショルドで取り込まれています。
(※プラットフォームケーブルIIは単なるロジックで受けているようです)
↑xilinx platformcableII データシートより引用
さらにVrefを生成するための回路は至って原始的で3.9Vのツェナーダイオードと抵抗で
Vtgtを強制的に3.9V付近にクランプさせUHSBuffer等に供給するVref上限を3.9Vまで
としていました！もちろん5Vをぶち込むとそこで80mA以上消費され、ダイオードと
抵抗にかなりの発熱を伴うのは容易に分かりますがなんて男らしい実装だ…！
さらにUHSBufferたるNC7SZ125は2000年代初頭にすでに存在している高速ロジックIC
なのですが、こいつの推奨動作電圧範囲の下限は1.65Vとなります。つまりプラット
フォームケーブルが保証しているはずの1.5VLVTTL/CMOSはこのロジックICの推奨範囲
から逸脱して使用されているわけで勿論設計された当初は74LVCEシリーズなんて存在
しなかったので結構ルールから外れた(でも最大定格範囲内の動作を守っている)結構
苦しい使い方されていたのが判明しました。
オリジナルJTAGKey2でも中の人が言っていた"UHSBuffer"とやらのスペックを見ると
当時の状況からはこのNC7SZ125以外に選択肢は考えられないので"最大定格範囲を
超えない"ようにしつつ推奨動作定格を破って動かしていた可能性が極めて高いと推定
しました。おそらくVtgtも何らかの形で4.0V付近にクランプしてVrefを作っていた
はずです。さすがにツェナーダイオード+抵抗の超乱暴実装ではないはずですが…。
まさか…。
また、CMOSの特性上VDDが低下すると伝搬遅延時間も大幅に増加していきます。
↑xilinx platformcableII データシートより引用
プラットフォームケーブルのデータシートではそれについての注意事項がありますが、
オリジナルJTAGKey2にはそんな記述すらないのですがTCK=30MHzの最大スピードで
動作せしめられるようなものは3.3V系のごく限られたターゲットのみでそれ以下の
電圧や速く動くデバイスがそもそも存在しない5V系では結局は良くても最大10MHz
くらいしか出せなかったのではないかと推測します。
●私はもうﾃｨｷﾝじゃない
そんなわけでだいぶ実態が分かってきました。ねむいさんが取れる選択肢は究極
の二択になります。
一つ、冒頭のSN74LV4T125を使用して30MHz動作と1.65V以下の保証を捨てる。
->1.5VCMOS/LVTTLを使用する場面や30MHz動作できるターゲットがほとんどないので
そいつらをあきらめてSN74LV4T125で組むと自作のハードルがかなり下がります。
5VCMOSでも規格を満たします。初めてドングルを作る人向けです。
一つ、オリジナルのJTAGKey2のロジックレベル保証を忠実に守る。
->1.5VLVCMOS/LVTTLから5VTTLに至るまでの電圧範囲をサポートせしめる！！！
2015年現在存在する新しい超高速ロジックICなら低電圧領域でも速度がある程度
保証されます。その代り回路は複雑になり、使い方にも注意が必要です。
ねむいさんはもちろんオリジナルJTAGKey2の電圧範囲を忠実に守ります！！！
そんなわけでJTAGKey2Compatibleのキモにあたる部分の解説をおさらいを
兼ねて改めてしていきましょう。
TCK,TDI,TMS,SRST,TRSTはDIODES-Zetex社の74LVCE1G125です。
1.4Vから動作するので1.5V系も正式にサポートです★
TDO,RTCK,SRST_inはNexperia(旧NxP)社の74LVC2T45です。こいつは1.2Vから動作する
すごい奴です。この図だけ見るとパスコン乗せてないように見えますが
PDFにはちゃんと乗せてますのでご安心ください。
オプション扱いだった74AHCT541は廃して今回新たに4V出力のレギュレータを追加し
ました。これで5V系のシステム相手でも5VTTLの電圧レベルをサポートできます！
4V以下ではLDOの特性上内部消費電流が増加しますがこの東芝のTCR2EF40は内部
消費はmA以下のオーダーなので発熱も全くなく電圧クランプとしての役割を十分に
果たしてくれます。さらに最低動作電圧は約1V付近と一般的なLDO比べて十分低い
ので1.5V系の時の動作でも電圧が暴れず安定して使用できます♥
勿論全てのLDOがこのような使い方ができるとは限りません！しっかりとデータシート
の特性グラフとにらめっこして目的に最適なものを選んでいきましょう！
●ありがとうV戦士モロ
2年前作ったJTAGKey2CompatibleRev.4にレギュレータを追加しただけですので
見た目はまったく変わってません。74AHCT541乗っかったままですが
どこにも繋がっておらずもはやただのオブジェと化しています。
レギュレータは赤丸でかこった箇所につけました。現在は1608サイズで10uFで
しかも温度特性もそこそこのよいMLCCが売られているので早速使っています★
3.3Vの挙動については回路構成はRev.4以前とまったく同じですので5V系と1.5V系
のきわきわの動作を見ていきます。
前回と同じ条件でATMEGA1284Pをターゲットデバイスに選び検証します。今回は電圧
レベルの問題で引っかかるのはJTAGKey2内部ではなくJTAGKey2の出力バッファと
AVR間です。AVRを選んだ理由は前回と同じものを使ったから条件があわせやすいのと
VIHが通常のCMOS(0.7~0.75VDD)よりも大きい0.8VDDを要求しているからです。
VDD=5.65Vの厳しい条件で温度を振って書き込みや消去が正常にできたらねむいさんの
勝利です！！！
(注:1.5Vの時はAVRの動作補償範囲からはずれ、JTAGのTCK周波数許容値が
下がってしまうので今回は一律10MHzではなく4500kHzで検証しています。)
勝った･･･！
手抜きではないのですがATMEGA1284Pの動作保証下限1.8Vを割って1.5Vでも
問題なく動作可能です♥これで1.5VLVCMOS~5VTTLレベルの電圧レベルでは
完全に動作することが確認できてさらに5VCMOSレベルも問題なく動作する実力が
あるのもわかりました♥
ちなみにATMEGA1284Pの内部CR発振器は結構根性があって一度発振できたら1.35V
くらいまで下げても余裕で動作するのがわかりました。電池一本で動きますよ。
さすがにJTAGのTCKの周波数は大幅に下がって1MHzくらいじゃないと駄目ですが。
動作可能なI/O電圧レベルを表にするとこんな感じです。最もパフォーマンスが
出るのは3.3VLVCMOS/LVTTLの時です。5VCMOSでは上述のとおり規格を一部
満たしていませんが動作する実力が確認されたので×ではなく△印つけています。
尤も相手がCMOSならば入力電流もMAX10uA位しかないでしょうから3.8V以上は
余裕で保てるので+5VCMOSでも問題ないですね。
そんなわけで長きに渡る戦いに終止符を打たせていただきます。ですがこれから先、
技術革新が進みTTL入力コンパチでなおかつ伝播遅延が3.3Vでも3nSec以下のすごい
バッファICが出たらまたJTAGKey2Compatibleの改良に取り組みたいと思います！
JTAGKey2Compatible Revision5
↑OpenOCDでSWDしたいときの追加回路もついでに追加しています。
中華Wirelessなアレを試す4号機 -ぱちもんのぱちもんの-
新年度に入りましたので今年で6年目を迎えてしまった当ぶろぐでも
フレッシュメンの見本になるようにエンジン掛けていきますよぅ！
記事のタイトルも近いうちに紹介するブツを見越して"Bluetooth"を外して
Wireless全般にしてみました☆彡
前回の記事ではBluetooth-SPPデバイスとしては皆さんもよくご存知のアレとアレの
ぱちもんの事を書かせていただきました。はっきり言って世に広まってるのはパチもん
の方が世に広く行き渡っているのではないかと思うほどですがそこのところをもう少
し突っ込んでこのモジュールを見ていきましょう。
HC-05,HC-06はCSRの"BlueCore4-External(BC417143B)"というチップが搭載
されていておしりに付いている"External"がミソで外付けのNORフラッシュ
メモリにBluetoothの基本となるスタックやアプリケーションのバイナリが
仕込まれています。
その外付けNORフラッシュにはBC417のSPIインターフェース経由で書き換えが
可能です。
主要な情報はRobin Gross氏のHC-05ハックに関するブログ記事です。
内容は至って単純かつ容易でAVRのISP書き込みのようにCSRチップをISPモードに
して、CSR提供のツールで書き換えを行うだけです。
ですがここで思わぬ壁が立ちはだかります。書き換えに必要なハードウエアの
回路図も提供されていますがLPT接続を前提としており、残念ながら今日びの
レガシーフリーなPCにはそんな旧世代のものなぞ有りません！
そんなわけでUSB接続のフラッシュ書き換えツールを探す事になりました…。
まぁAliexpressにはCSR純正ライタのぱちもんがゴロゴロしてるのですがそれを
購入すれば終わる話ですがそれを買わないでもArduinoを使用したり
FT232RのBitbangモードを利用してCSRのツールから直接書き込み可能な
LPTアクセス乗っ取りDLLが公開されてたりします。
さらにCSRの純正ライタの自作を試みる人もいました。
ねむいさんが注目したのはだいぶ前にエラッタ持ちチップ処分セールで500円で叩き売り
されていたStellaris-Launchpadを使用したUSBプログラマのエミュレーションです！
以前はStellaris-LM4Fなんて名前でしたがTIがLuminary要素が残っていたCortex-M3を
情け容赦なくすべて捨て去ってTIVA-Cに変わったというニュースを聞いたのを最後に
ずーっと積み基板でしたがここでようやく日の目を見た感じがします。
GitHubにあるプロジェクトはGCCではありませんでしたが移植は極めて容易であっさり
ねむいさんのビルド環境にも対応(コレがベースです)できました。欲しい人はメールくだち
もちろんCSR USB<>SPI converterとして認識できます♥
相変わらずのやっけつ配線ですが…
ねむいさんが生贄として使用したのは前回紹介したCSRチップがリマーク品の怪しい
HC-05です。実はこれは中のファームウェアのバージョンも2015年現在広く
流通しているV2.0ではなくV1.0のものでした。動作がいろんな面で怪しいブツです。
無事認識されました♥
ここから外付けNORフラッシュの中身を吸い出したり書き換えたりが可能です！
V2.0のファームを書き込んでみました。
無事V2.0にアップデート完了！
でもリマーク品なので動作が怪しいのは変わりません･･･。
ちなみにHC-06のぱちもんも持っていますがこちらは2014年に騙されて購入したもので
Linvor1.8と呼ばれるHC-06向けの最新のバージョンのファームが書き込まれて
いました。HC-06もHC-05もハードウエア的違いは全くなく、ファームの違いだけ
なので若干安いHC-06を買ってHC-05化することも可能です。
こんなわけでHC-05のガワだけ真似たらあとはファームウエア書き込こんでぱちもんを
作り放題なわけで、そういういきさつがあって世にはHC-05やHC-06のぱちもんが乱舞
しているわけです。
ぱちもんはぱちもん故にいろんなところが適当でたとえばモジュールごとにチューニング
されて同じにならないはずのRF周りのパラメータとかもでたらめでオリジナルは飛距離
10m保証のはずなのに障害物なくても2m位しか電波届かないとかなんかLEDの動きが
おかしいとかそもそも全く動作しないとか当たり前のようにあります。
安物買の銭失いというよくあるチャイナ・リスクに陥りやすい代物です。
結局一番安全なのはメーカから直接正規品を購入する以外にないのですが、日本国内
の技適を取得出来ていないので外部に電磁波が出て行かない環境でしか使用でき
ませんしねむいさんも外部への電磁波と騒音が遮断されたお仕置き部屋(通称：連続稼働
試験室)内でしか実験してませんので最後の最後でいつもの建前で本日の記事を
〆させていただきます!
しまった…エンジン掛けたとたんにエンストだ！
OpenOCD小ネタ17 -CMSIS-DAPに本来の力を-
まずはこのぶろぐのアクセス数推移のグラフを見ていただきい。
東海自然歩道関連の記事の更新も一区切りが着き、OpenOCDの解説に力を
入れはじめた(中央矢印)とたんにアクセスがガタ落ちになっていますorz
"わかりやすい解説をしていただけるとありがたいです"との多数の要望を
受け始めたOpenOCD小ネタですが、ねむいさんがこちらでやったアドバイスが
効き過ぎて皆CoIDEとかに移ってしまった模様ですが、これはこれで(開発環境の
整備ごときに)無駄な時間浪費するような被害が減ってよかったのではないか、
ねむいさんは安心して近畿自然歩道とか東海自然歩道の記事更新をしまくれば
みんな幸せになれるんじゃないかなぁと思いましためでたしめでたし。
で終わってもあまりめでたくないので2015年度はちょっと毛色を変えてくどい
解説は極力排除して面白おかしく斜め45度に傾いた記事を書いていくポリシーを
取っております。
ていうわけで本題です！
●CMSIS-DAP(を制御する側)パワーアップ大作戦
現在ではCortex-Mxコアのデバッグに欠かせなくなったCMSIS-DAPですが昨年より
OpenOCDからも使用可能となっています。しかしながらOpenOCD側の実装と
CMSIS-DAPが使用しているUSBのHIDクラスの関係上フラッシュ書き込み速度が
USBハイスピード接続でもMAXで2kByte/Sec程度しか出ない、LPC11U35版の
ファームにいたっては0.8kByte/Sec以下まで書き込みスピードが落ちるという
極めて不利な弱点がありました。
昨年の秋口からこのﾁﾏﾁﾏ書き込みしか利用できないOpenOCD側の実装を何とか
しようとあの手この手のアイデアが議論され、書き込み命令をキューイング
してCMSIS-DAPに元から実装されていたが使用されていなかったブロック転送
コマンドで一気にドカンと転送する作戦が取られました。
CMSIS-DAPの元となるファームウエアは同じながらも各ベンダ間で独特の癖が
ある拡張に苦戦しましたが、今春ようやく殆どの問題が解消され正式にマージされる
運びとなりました。
説明はこれくらいにして早速威力を見てもらいましょう。
テストで使用した基板はLPC1549Xpressoです。
これにはUSBハイスピードで繋がるLPCXpressoV2ハードウエアが載っています。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 16.749893s (0.478 KiB/s)
verified 8172 bytes in 4.593720s (1.737 KiB/s)
shutdown command invoked> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 0.578121s (13.838 KiB/s)
verified 8172 bytes in 0.140624s (56.750 KiB/s)
shutdown command invoked
同じUSB2.0ホストで試しましたがご覧のとおり約10倍以上速くなってますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc1549_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x2ba01477
Info : lpc1549.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x030000b8 msp: 0x02001fe0
auto erase enabled
wrote 8192 bytes from file main.elf in 0.468747s (17.067 KiB/s)
verified 8172 bytes in 0.124999s (63.844 KiB/s)
shutdown command invokedLPC824MAXやトラ技ライタのCMSIS-DAPで使用されているLPC11U35はフル
スピードまでで、尚且つメモリリソースがかなり少ないながらもキューイングの
恩恵に多少あやかることができ、こちらもパフォーマンスの若干の向上が見られました。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00314-g90ae846-dirty (2015-03-01-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'cmsis-dap'
none separate
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : DAP_SWJ Sequence (reset: 50+ '1' followed by 0)
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : IDCODE 0x0bc11477
Info : lpc82x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 8192 bytes from file main.elf in 10.484308s (0.763 KiB/s)
verified 7948 bytes in 0.640621s (12.116 KiB/s)
shutdown command invoked> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/cmsis-dap.cfg -f target/lpc82x_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.9.0-dev-00357-g09ca5af-dirty (2015-03-31-00:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'swd'
adapter speed: 10 kHz
adapter_nsrst_delay: 200
cortex_m reset_config sysresetreq
adapter speed: 1000 kHz
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.0
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bc11477
Info : lpc8xx.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 8192 bytes from file main.elf in 4.718719s (1.695 KiB/s)
verified 7948 bytes in 0.406248s (19.106 KiB/s)
shutdown command invoked尤もLPC824でもフラッシュ容量は最大32kByte程度なので2kByte/Secでもそこまで
困らないかと思います。
トラ技で配布しているmbed版ではないほうのLPC11U35向けCMSIS-DAP
ファームウェアを使用すればマスストレージに使用していたメモリリソースが
使用できるのでさらにちょっとだけ速度が上がります。
そんなわけで弱点だったCMSIS-DAPの書き込み速度は実用レベルにまで改善したので
OpenOCDからCMSIS-DAPをびしばし使い倒すことができるようになりました。
これでXPresso系のボードの開発もスムーズに進められると思います！
STM32F4シリーズを使ってみる13 - FatFsとSDカード再考その2(SDIO基本編) -
※今回の記事の内容は時勢/判明した事実に即して逐次変更していきます。
この記事ではDMAでよくある間違いをやらかしています。
次回の記事も必ず参照してください！
STM32にはSDIOというSD/MMCカードと高速でデータをやり取りができる機能が
あります。今回は前回触れたハードウエアの接続の内容を踏まえ、ソフト的な話を
展開していきます。さらにSTM32F4に限らず他品種のSDIO相当の機能を
使用できるマイコンについても考察を重ねていきます。
●STM32のSDIOでFatFsる
SDカードとSDIOは簡易な解説がSDアソシエーションのサイトで
公開されております。この"簡易な解説"が曲者で本当に知りたい細かい部分の事柄を
知るためには会費を払って会員になる必要があります。そんなわけで
ねむいさんみたいな金も地位も技術もないホビイストにとってはMCUベンダから
提供されたSDIOモジュールアクセス用のコードさんぷるをありがたく
頂いて自分のプロジェクトに適した形に組み込んでいくことになります。
話は少しFatFsのほうに戻りますが、FatFsとMCU固有コードを結合させる
ためにはFatFs自身が必要とする下部レイヤと呼ばれる関数群をこさえて
やる必要があります。
このうちdisk_ioctl(),fat_gettime(),disk_write()はFatFsのオプション設定で
無効状態にできるのでdisk_initialize(),disk_status(),disk_read()の3つの関数は
最低限作りこんであげないといけません。
かつてSTマイクロより提供されていたSTM32F4xx_DSP_StdPeriph_Libには
FatFsと親和性が良いSDIOのSD/MMCカードW/Rサンプルライブラリがあり、
私はこれをベースにSDIOドライバを実装していきました(現在配布されている
STM32F4Cube通称"HALライブラリ"のFatFsドライバもこのサンプルライブラリと
ほぼ同じ実装です)。
私のSDIOドライバはリソース使用状況に応じてDMAとFIFOのポーリングと
両方使い分けることが可能です。以下に実際に私のSDIOドライバで使用している
要点、特に初期化時のSDIO_CK(=実際にSDカードに掛かるクロック)の設定を
重点的にかいつまんで解説していきます。
以下おきぱのSTM32F4向けのFatFs実装例内にあるsdio_stm32f4.c,sdio_stm32f4.h
を見ながら読み進んでください。
SD_Error SD_Init(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
NVIC_InitTypeDef NVIC_InitStructure;
SD_Error errorstatus = SD_OK;
/* SDIO Peripheral Low Level Init */
/* GPIOC and GPIOD Periph clock enable */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC | RCC_AHB1Periph_GPIOD | SD_DETECT_GPIO_CLK, ENABLE);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource8, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource9, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource10, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource11, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOC, GPIO_PinSource12, GPIO_AF_SDIO);
GPIO_PinAFConfig(GPIOD, GPIO_PinSource2, GPIO_AF_SDIO);
/* Configure PC.08, PC.09, PC.10, PC.11 pins: D0, D1, D2, D3 pins */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9 | GPIO_Pin_10 | GPIO_Pin_11;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
GPIO_Init(GPIOC, &GPIO_InitStructure);
/* Configure PD.02 CMD line */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
GPIO_Init(GPIOD, &GPIO_InitStructure);
/* Configure PC.12 pin: CLK pin */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_Init(GPIOC, &GPIO_InitStructure);
/*!< Configure SD_SPI_DETECT_PIN pin: SD Card detect pin */
#ifdef SDIO_INS_DETECT
GPIO_InitStructure.GPIO_Pin = SD_DETECT_PIN;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
GPIO_Init(SD_DETECT_GPIO_PORT, &GPIO_InitStructure);
#endif
/*
*NVIC_PriorityGroup_0: 0 Pre-emption priorities, 16 Sub-priorities
*NVIC_PriorityGroup_1: 2 Pre-emption priorities, 8 Sub-priorities
*NVIC_PriorityGroup_2: 4 Pre-emption priorities, 4 Sub-priorities
*NVIC_PriorityGroup_3: 8 Pre-emption priorities, 2 Sub-priorities
*NVIC_PriorityGroup_4: 16 Pre-emption priorities, 0 Sub-priorities
*/
NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);
/* Enable the SDIO Interrupt */
NVIC_InitStructure.NVIC_IRQChannel = SDIO_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
NVIC_InitStructure.NVIC_IRQChannel = SD_SDIO_DMA_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 2;
NVIC_Init(&NVIC_InitStructure);
/* Enable the SDIO APB2 Clock */
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SDIO, ENABLE);
#if defined(SD_DMA_MODE)
/* Enable the DMA Clock */
RCC_AHB1PeriphClockCmd(SD_SDIO_DMA_CLK, ENABLE);
/* Initialize SDDMA Structure */
SDDMA_InitStructure.DMA_Channel = SD_SDIO_DMA_CHANNEL;
SDDMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)SDIO_FIFO_ADDRESS;
SDDMA_InitStructure.DMA_Memory0BaseAddr = 0;
SDDMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralToMemory;
SDDMA_InitStructure.DMA_BufferSize = 0;
SDDMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable;
SDDMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable;
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Word;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_INC4;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;
#endif
/* End of LowLevel Init */
SDIO_DeInit();
errorstatus = SD_PowerON();
if (errorstatus != SD_OK)
{
/*!< CMD Response TimeOut (wait for CMDSENT flag) */
return(errorstatus);
}
errorstatus = SD_InitializeCards();
if (errorstatus != SD_OK)
{
/*!< CMD Response TimeOut (wait for CMDSENT flag) */
return(errorstatus);
}
/*!< Configure the SDIO peripheral */
/*!< SDIOCLK = HCLK, SDIO_CK = HCLK/(2 + SDIO_TRANSFER_CLK_DIV) */
/*!< on STM32F4xx devices, SDIOCLK is fixed to 48MHz */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Disable;
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_1b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);
/*----------------- Read CSD/CID MSD registers ------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_GetCardInfo(&SDCardInfo);
}
/*----------------- Select Card --------------------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_SelectDeselect((uint32_t) (SDCardInfo.RCA << 16));
}
/*----------------- Enable SDC 4BitMode --------------------------------*/
if (errorstatus == SD_OK)
{
errorstatus = SD_EnableWideBusOperation(SDIO_BusWide_4b);
}
#ifdef SD_HS_MODE
/*----------------- Enable HighSpeedMode --------------------------------*/
#warning "Enable SD High Speed mode!"
if (errorstatus == SD_OK)
{
errorstatus = SD_HighSpeed();
}
#endif
return(errorstatus);
}
最初の要となるSD_Init内の関数です。DMAを使用するモードでもFIFOポーリング
でも割り込みは使用します。CLK以外のGPIOは一応プルアップしていますが
これに頼らず必ず外付け抵抗でプルアップをしてください(前回参照)。
DMAモードの場合はここでDMA用の構造体の設定も完了させておきます。
構造体変数はグローバル化してDMAをキックする際に最低限の変数の設定に
とどめるようにして少しでもオーバーヘッドを減らすようにしております。
また、構造体変数の保持用にCCM領域を積極的に使用するようにして速度向上に
努めています。ここで注意点ですがCCM領域に置いた変数はdata領域のように
スタートアップで初期化しておくようにはしていないのでプログラム内で
明示的に初期化するようにしましょう。
その後はSTマイクロ提供のサンプルのとおりにSDカード初期化のための関数を
実行していきます。デフォルトでは先ずSDIOCLKから作られるSDIO_CKを
400kHz以下、データ幅は1-bitモードでカードの初期化を実行し、成功が
返ってきたらクロックをSDNomalModeがサポートする上限付近まで上げて
データ幅も4-bitに拡張するコマンドを発行して高速なデータのやり取りの
準備を行います。
現在流通しているSDカードはほぼすべての品種でSDNomalModeの最高値25MHzを
サポートしていますので上げる場合はその周波数近辺まで一気にあげられます。
このときのクロックですが、STM32F4ではUSB,RNG,そしてSDIO用の固定値
クロック生成用のPLLが存在して柔軟に対応可能となっています。
F4系で一般的な168MHz動作の時はUSBで必須の48MHzが生成され、同じくこれは
SDIOでも都合よい値となっています。
そしてSDNomalModeの時は規格上SDIO_CKの値は25MHzが上限値なので上記の
コードのようにSDIOモジュール内にあるクロックディバイダを通して48MHzを
2分周した24MHzを生成するような設定にします。過去に私はこの時点で
クロックディバイダを通さず48MHzをモロに引き出して無理やり動作させて
おりましたがこのやり方は完全に誤りで本当はSDカードの規格に存在する
SDHighSpeedModeに切り替えたうえでクロックを48MHzに上げてやる必要が
あることを知りました。
SD_Error SD_HighSpeed (void)
{
SD_Error errorstatus = SD_OK;
uint32_t scr[2] = {0, 0};
uint32_t SD_SPEC = 0 ;
uint8_t hs[64] = {0} ;
uint32_t count = 0, *tempbuff = (uint32_t *)hs;
TransferError = SD_OK;
TransferEnd = 0;
StopCondition = 0;
SDIO->DCTRL = 0x0;
/*!< Get SCR Register */
errorstatus = FindSCR(RCA, scr);
if (errorstatus != SD_OK)
{
return(errorstatus);
}
/* Test the Version supported by the card*/
SD_SPEC = (scr[1] & 0x01000000)||(scr[1] & 0x02000000);
if (SD_SPEC != SD_ALLZERO)
{
/* Set Block Size for Card */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)64;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);
if (errorstatus != SD_OK)
{
return(errorstatus);
}
SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;
SDIO_DataInitStructure.SDIO_DataLength = 64;
SDIO_DataInitStructure.SDIO_DataBlockSize = SDIO_DataBlockSize_64b ;
SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;
SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;
SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;
SDIO_DataConfig(&SDIO_DataInitStructure);
/*!< Send CMD6 switch mode */
SDIO_CmdInitStructure.SDIO_Argument = 0x80FFFF01;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_HS_SWITCH;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_HS_SWITCH);
if (errorstatus != SD_OK)
{
return(errorstatus);
}
while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
{
if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)
{
for (count = 0; count < 8; count++)
{
*(tempbuff + count) = SDIO_ReadData();
}
tempbuff += 8;
}
}
if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);
errorstatus = SD_DATA_TIMEOUT;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);
errorstatus = SD_DATA_CRC_FAIL;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_RXOVERR);
errorstatus = SD_RX_OVERRUN;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_STBITERR);
errorstatus = SD_START_BIT_ERR;
return(errorstatus);
}
count = SD_DATATIMEOUT;
while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))
{
*tempbuff = SDIO_ReadData();
tempbuff++;
count--;
}
/*!< Clear all the static flags */
SDIO_ClearFlag(SDIO_STATIC_FLAGS);
/* Test if the switch mode HS is ok */
if ((hs[13]& 0x2)==0x2)
{
/*!< Configure the SDIO peripheral */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
#if defined (STM32F40_41xxx)
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling; /* This is a baddest work around for STM32F40x and STM32F41x */
#else
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
#endif
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable; /* Set Direct Clock(48MHz) */
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);
errorstatus=SD_OK; /* Enter SDHighSpeedMode */
}
else
{
errorstatus=SD_OK; /* Still SDNomalMode */
/*errorstatus=SD_UNSUPPORTED_FEATURE ;*/
}
}
return(errorstatus);
}
STマイクロのサンプルにはどこからも参照されていないSD_HighSpeed()なる
関数がとあるバージョンから唐突に追加されてフルの規格を入手しないと
わからなかったSDHighSpeedModeへの切り替え方が判明しております。
そんなわけでこの関数を利用して正規にSDIOのクロックを48MHzでドライブ
したい と こ ろ で す が ！
残念ながらSTM32F405/7系のSDIOモジュールには上記のエラッタが存在し、
上記の関数を実行してもハードウエア的に48MHzで安定動作せしめることは
できません。
実際にRev.AのSTM32F407が乗った紅牛板で実験してみたのですがクロック
ディバイダを無効にして48MHz直結の場合は動作しないカードが殆どで動作する
カードは極めて限定的なものでした。しかもreadはかろうじて成功するものの
writeは殆ど失敗してディレクトリまで破壊されることが判明したので一時は
お蔵入りにしていました(このエラッタが明記されたのは2012年の秋以降で、
2011年当時はまだ判明していませんでした)。
てわけでワークアラウンドを講じるとSTM32F405/7系では動作が保証された
クロック上限値は37.5MHzとなり、しかもPLLの分周値を変えてこの周波数に
設定すると今度はUSBで必要な48MHzが作られなくなってしまうので利用が
限定的になってしまいます。
したがって潰しが効くようにコーディングするとSDNomalModeのまま、
SDIO_CKも24MHzのままで使用するべしとなってしまうのです。一応STM32F2/F4
にはGPIOの高速動作を安定化させる"compensation cell"なるものがあり
(こちらのテクニカルノートの75pに解説があります)、有効にしてみたのですが
改善はありませんでした。
一方STM32F42x/43x系では動作周波数が180MHzまで拡張されたせいかGPIOの
絶対的速度も強化され、168MHz動作時クロックバイパスをEnableにして
48MHzのクロックで動かしてもRead,Writeとも安定して動作可能です。
180MHzの時はSDIO_CKは52MHzまで増加しますがこの状態でも全く問題は
ありません。そんなわけで後で紹介する裏ワザを使わずどうしても48MHzの
SDHighSpeedModeで動かしたい場合は405/407系から42x/43x系にお引越し
する必要があります。
ほぼピン互換なのでボードの改造は不要で単純な交換でパワーアップできます！
…と言いたい と こ ろ で す が(こんなんばっかだ)
このSTM32F42x/43x系も1MB以上のフラッシュ領域を使っている時PA12の
電圧レベルが変化すると動作がおかしくなるという意味不明かつかなり
致命的な不具合が存在しますorz。このやばい不具合、rev3でFMCとともに
ようやく修正されたようですがPA12はUSBのD+に相当するためエラッタ
持ちのチップはUSB機能を殺すかもしくはフラッシュの1MB以上の領域を
使用しないという2択を迫られることになりますorz
/*!< Configure the SDIO peripheral */
SDIO_InitStructure.SDIO_ClockDiv = SDIO_TRANSFER_CLK_DIV;
#if defined (STM32F40_41xxx)
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Falling; /* This is a baddest work around for STM32F40x and STM32F41x */
#else
SDIO_InitStructure.SDIO_ClockEdge = SDIO_ClockEdge_Rising;
#endif
SDIO_InitStructure.SDIO_ClockBypass = SDIO_ClockBypass_Enable; /* Set Direct Clock(48MHz) */
SDIO_InitStructure.SDIO_ClockPowerSave = SDIO_ClockPowerSave_Disable;
SDIO_InitStructure.SDIO_BusWide = SDIO_BusWide_4b;
SDIO_InitStructure.SDIO_HardwareFlowControl = SDIO_HardwareFlowControl_Disable;
SDIO_Init(&SDIO_InitStructure);
errorstatus=SD_OK; /* Enter SDHighSpeedMode */
すみません話がそれましたがSTM32F405/407系でどうしても48MHzでSDIOを
安定して使用したい場合の裏技があります。そもそも安定しない理由がI/Oの
変化速度が規定に追い付けずデータが1ビットシフトして取り込まれている
せいなのです。ここでSDIO_CKのクロック送出エッジをNegativeに変えることに
よってクロックは遅れて送出されるがデータの取り込みタイミングは変わらない
状態となるためビットシフトせずうまい具合に取り込んでくれるようになります。
これはクロックバイパスEnable時の直結でも有効(実際はディバイダを噛まさ
ないでもSDIOCLKがそのまま出ているのではなくゲーティングされてSDIO_CKが
生成されている事を示している)で安定して読み書きができるようになります。
この送出エッジをNegativeにすることはデータの破損を招く事になるとして
errataとして設定が禁じられています。ですが48MHz動作だとこの構成の方が
都合がよくなります。おきぱにあるSTM32F4のSDIOドライバは405/407系向け
限定でSDHighSpeedModeを使う際は敢えてこの技を行っています。
もちろん禁を破った動かし方ですので物好きな人だけ試してみてください。
DRESULT disk_read(uint8_t drv,uint8_t *buff,uint32_t sector,unsigned int count)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_OK;
if(count==1){
Status = SD_ReadBlock((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE);
}
else{
Status = SD_ReadMultiBlocks((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE
,count);
}
if (Status == SD_OK) return RES_OK;
else return RES_ERROR;
}
}
return RES_PARERR;
}
だらだらとクロック設定の話ばっかり続けてしまいましたがdisk_read()は
かなり単純明快です。SD_ReadBlock()及びSD_ReadMultiBlock()をセクタ数に
応じて呼び出すだけです。SD_ReadMultiBlock()単体だけでも動作には問題
ないですがセクタ数1の時はオーバーヘッドの方が大きくなるので分けた方が
いいです。
DRESULT disk_write(uint8_t drv,const uint8_t *buff,uint32_t sector,unsigned int count)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_OK;
if(count==1){
Status = SD_WriteBlock((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE);
}
else{
Status = SD_WriteMultiBlocks((uint8_t*)(buff),
((uint64_t)(sector)*SECTOR_SIZE),
SECTOR_SIZE
,count);
}
if (Status == SD_OK) return RES_OK;
else return RES_ERROR;
}
}
return RES_PARERR;
}
SD_Error SD_ReadBlock(uint8_t *readbuff, uint64_t ReadAddr, uint16_t BlockSize)
{
SD_Error errorstatus = SD_OK;
#if defined (SD_POLLING_MODE)
uint32_t count = 0, *tempbuff = (uint32_t *)readbuff;
#endif
TransferError = SD_OK;
TransferEnd = 0;
StopCondition = 0;
SDIO->DCTRL = 0x0;
#if defined(SD_DMA_MODE)
/* Ready to DMA Before Any SDIO Commands! */
SDIO_ITConfig(SDIO_IT_DCRCFAIL | SDIO_IT_DTIMEOUT | SDIO_IT_DATAEND | SDIO_IT_RXOVERR | SDIO_IT_STBITERR, ENABLE);
SD_LowLevel_DMA_RxConfig((uint32_t *)readbuff, BlockSize);
SDIO_DMACmd(ENABLE);
#endif
if (CardType == SDIO_HIGH_CAPACITY_SD_CARD)
{
BlockSize = 512;
ReadAddr /= 512;
}
/* Set Block Size for Card */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t) BlockSize;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_SET_BLOCKLEN;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_SET_BLOCKLEN);
if (SD_OK != errorstatus)
{
return(errorstatus);
}
SDIO_DataInitStructure.SDIO_DataTimeOut = SD_DATATIMEOUT;
SDIO_DataInitStructure.SDIO_DataLength = BlockSize;
SDIO_DataInitStructure.SDIO_DataBlockSize = (uint32_t) 9 << 4;
SDIO_DataInitStructure.SDIO_TransferDir = SDIO_TransferDir_ToSDIO;
SDIO_DataInitStructure.SDIO_TransferMode = SDIO_TransferMode_Block;
SDIO_DataInitStructure.SDIO_DPSM = SDIO_DPSM_Enable;
SDIO_DataConfig(&SDIO_DataInitStructure);
/*!< Send CMD17 READ_SINGLE_BLOCK */
SDIO_CmdInitStructure.SDIO_Argument = (uint32_t)ReadAddr;
SDIO_CmdInitStructure.SDIO_CmdIndex = SD_CMD_READ_SINGLE_BLOCK;
SDIO_CmdInitStructure.SDIO_Response = SDIO_Response_Short;
SDIO_CmdInitStructure.SDIO_Wait = SDIO_Wait_No;
SDIO_CmdInitStructure.SDIO_CPSM = SDIO_CPSM_Enable;
SDIO_SendCommand(&SDIO_CmdInitStructure);
errorstatus = CmdResp1Error(SD_CMD_READ_SINGLE_BLOCK);
if (errorstatus != SD_OK)
{
return(errorstatus);
}
#if defined (SD_POLLING_MODE)
/*!< In case of single block transfer, no need of stop transfer at all.*/
/*!< Polling mode */
while (!(SDIO->STA &(SDIO_FLAG_RXOVERR | SDIO_FLAG_DCRCFAIL | SDIO_FLAG_DTIMEOUT | SDIO_FLAG_DBCKEND | SDIO_FLAG_STBITERR)))
{
if (SDIO_GetFlagStatus(SDIO_FLAG_RXFIFOHF) != RESET)
{
for (count = 0; count < 8; count++)
{
*(tempbuff + count) = SDIO_ReadData();
}
tempbuff += 8;
}
}
if (SDIO_GetFlagStatus(SDIO_FLAG_DTIMEOUT) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DTIMEOUT);
errorstatus = SD_DATA_TIMEOUT;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_DCRCFAIL) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_DCRCFAIL);
errorstatus = SD_DATA_CRC_FAIL;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_RXOVERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_RXOVERR);
errorstatus = SD_RX_OVERRUN;
return(errorstatus);
}
else if (SDIO_GetFlagStatus(SDIO_FLAG_STBITERR) != RESET)
{
SDIO_ClearFlag(SDIO_FLAG_STBITERR);
errorstatus = SD_START_BIT_ERR;
return(errorstatus);
}
count = SD_DATATIMEOUT;
while ((SDIO_GetFlagStatus(SDIO_FLAG_RXDAVL) != RESET) && (count > 0))
{
*tempbuff = SDIO_ReadData();
tempbuff++;
count--;
}
/*!< Clear all the static flags */
SDIO_ClearFlag(SDIO_STATIC_FLAGS);
#elif defined(SD_DMA_MODE)
/* Check if the Transfer is finished */
Status = SD_WaitReadOperation();
/* Wait until end of DMA transfer */
while(SD_GetStatus() != SD_TRANSFER_OK);
if (TransferError != SD_OK)
{
return(TransferError);
}
#endif
return(errorstatus);
}
SD_ReadBlock()及びSD_ReadMultiBlock()の関数は#defineの設定によってDMAか
ポーリングかを分けています。上記コードはSD_ReadBlock()の例ですがブロック/
マルチブロック転送にDMAを使う場合はDMAのキックを関数の冒頭、SDIOコマンド
送出前に行っておかないとラスト数バイトの転送漏れが生じてしまいますので必ず
ここで行ってください。
これはSTM32F1のSDIOモジュールのころに議論にあった問題でSTマイクロの
フォーラムで指摘され講じられた対策がその後のF2/F4の公式のドライバにも
反映されています。コメントでも述べましたがDMAを行う際は転送に使用する
メモリのアドレスを4で割り切れる数、つまり4バイトの境界に合わせてください。
GCCにおいては静的にメモリを確保する際に" __attribute__ ((aligned (4)))"の
修飾子を付けます。これをやっておかないと転送がコケて失敗します。
さらにブロック転送の際の転送するサイズを512バイト単位で行ってください。
これらをちゃんとやっておかないと(ry
ちなみにDMAを使用しない場合のFIFOのポーリング版でも転送速度の低下は
ほとんどありません。使用するリソース/ペリフェラルの優先度と相談して
DMAを使うか否かを決めてください。
また、Writeの際も同(ry
DSTATUS disk_status(uint8_t drv)
{
switch (drv)
{
case SDIO_DRIVE:
{
Status = SD_GetCardInfo(&SDCardInfo);
if (Status != SD_OK)
return STA_NOINIT;
else
return 0x00;
}
}
return STA_NOINIT;
}
disk_status()の実装は一番シンプルです。
SD_GetCardInfo()を実行するだけです。
さて、LPC4088などの多品種のマイコンにも触れたかったのですがそろそろこの
ぶろぐの一記事の文字制限に引っかかりそうなので実際に動かしてみたところは
次回に紹介させていただきます
･･･なんか内容をまとめるどころかどんどん内容が発散していくorz
20150227追：
まぐろ様よりコメントにてSDIOでDMAで4の倍数のバイト数でない数をf_write()で
書き込んだ際にデータが１〜３バイトずれて記録されるという不具合報告を
受けました。いただいた情報を元にこちらでも再現したのでさらに追ってみると
DMA初期化時のメモリ側インクリメント設定が4(バイト)となっていたためか4で
割り切れない数を書きこんだ際に次の転送でずれてしまうと最終的に推測しました。
というわけで対策ですが一番手っ取り早いのは細かいデータを記録していく際は
ポーリングモードで使用することです。どうしてもDMAしたい！場合について私も
もうちょっと調べてみました。するとChaN氏のページからも紹介されている
STM32F4のプロジェクトを専門に取り扱っているtilz0R氏のサイト中のコメントにてTassilo(田代･･！？)という方が同じ問題に
直面した際の解決策を提示してくれました。
私のプロジェクトでいうとsdio_stm32f4.cの291行目以降を以下のように変更します。
変更前：
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Word;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_Full;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_INC4;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;
変更後：
SDDMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_Word;
SDDMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_Byte;
SDDMA_InitStructure.DMA_Mode = DMA_Mode_Normal;
SDDMA_InitStructure.DMA_Priority = DMA_Priority_VeryHigh;
SDDMA_InitStructure.DMA_FIFOMode = DMA_FIFOMode_Enable;
SDDMA_InitStructure.DMA_FIFOThreshold = DMA_FIFOThreshold_HalfFull;
SDDMA_InitStructure.DMA_MemoryBurst = DMA_MemoryBurst_Single;
SDDMA_InitStructure.DMA_PeripheralBurst = DMA_PeripheralBurst_INC4;
上記の対策で不具合は発生しなくなることを確認しました。
太字の部分が変更点です。ねむいさんてっきりメモリアドレスもサイズも
32bit(=4Byte)であるべきと思い込んでいましたのでこんな罠があったの
知らなかったとはちょっと恥ずかしいですorz
しかしながらメモリアクセスを4Byteから1Byte区切りにしたことによる
転送速度の低下や何かしらの弊害あるかもなので次回にみっちり動作検証
して考察してみましょう。
また、STM32F4/F2だけではなく、STM32F1系のSDIOや、はたまた
LPC1788/4088等のMCIでも4バイト区切りでDMA転送を行うものは同じ
不具合がでますのでこっちも同じく検証してできれば対策まで待っていきたい
ところです。
20150409追：
全ての品種で効果がある根本対策を講じました!
STM32F4シリーズを使ってみる12 - FatFsとSDカード再考その1 -
このぶろぐを始めてから今に至るまで｢FatFsがうごきません＞＜｣という漠然としすぎて
すごく返答しづらい内容の質問をコンスタントに頂くのですがその9割が単なる配線ミス
でしたと言うオチだったのですが、残る1割にSTM32に潜んでいた未知のエラッタや
評価ボードの設計不備、および私の不備というｸﾘﾁｶﾙな問題が潜んでいたのが
分かっています。
STM32F4が世に出て早数年、いろんな情報やノウハウも出そろってきましたので
ここで基本に還ってF4中心にSTM32とSDカードを接続せしめる手法について今一度
考察していきたいと思います。まず予習としてChaN氏のFatFsとMMCの解説のページ
は必ず目を通しておいてください。
●STM32F4との接続・ハードウエア編
STM32F4とSDカードを実用的に繋げるためにはSTM32F4の周辺機能であるSPI
若しくはSDIOを用いて接続可能です。SPIはデータ線が1bitのシリアルですが
SDIOは4bit(8bitまで)可能だが8bitバスが利用できるカードは限られている)
まで可能でSDIOの方が高速にデータをやり取り可能です。
その代りSDIOの場合はその機能を最大限に引き出すため使用するI/Oポートは
固定化されていてSDIOを使うときは重複する他の周辺機能は使用不可能に
なります。一方でSPIは柔軟に割り当てが可能なためピン数がすくない品種で
速度をそれほど要しない場面でSDカードを使う際に重宝します。
おさらいですがSPIを使用するときはSD/MMCのSPI互換モード、SDIOを
使用する時はSD/MMCのネイティブモードとして接続します。
当ぶろぐではSDIOを使用するSD/MMCネイティブモードに特に焦点を
当てていきます。
私のおきぱのSTM32F4向けのサンプルではSTM32F4Discovery,STM32F429IDiscovery
ではSPIを、その他のボードに関してはSDIOをそれぞれ使用するようにしております。
↑STM32F4Discoveryとの接続(SPI)
↑紅牛/ECH_BOARD改造基板との接続(SDIO 4bitmode)
SDIO,SPIのいずれの場合においてもSDカード/MMCの電源投入後の初期化時は
オープンコレクタで動作することが前提のため、CLKを除く全てのデータ線は必ず
外付け抵抗でプルアップしてください。
プルアップ抵抗値についてはNexperia(元NxP)のアプリケーションノートAN10911に
極めて詳しい解説があります。私はそれらを吟味した上で10kohmよりちょっと上の
22kohmを常用しております。メーカ製評価ボードでは入手の容易なSDHCカードを想定
しているのか下限値の10kohmで吊っているのが非常に多かったです。また、今日びの
マイコンは内蔵プルアップを有する物が多いですがそれに絶対に頼ってはいけません。
面倒臭がらず必ず外付け抵抗を用いてプルアップしてください。
以前MCIを動作させるのに難儀していた中華LPC1788基板ですがEA互換のはずなのに
EA向けのFatFsのサンプルがそのままでは動かないもんで回路図をよく見たら…
SDIOの信号線にプルアップが無かったorzちゃんとつけましょう！
このブログ記事を書く際に久しぶりに動かしてようやく気づいたorz
CLKは基本宙ぶらりんです。リセット直後のI/Oの挙動が不安な場合は100kohm程度で
Loレベルに弱く固定すれば良いです。私が見た限りではEAのボードは｢宙ぶらりん
(ダンピング抵抗有)｣、ST系のボードも｢宙ぶらりん｣、中華系のは適当で他のI/Oと
一緒にまとめてCLKもプルアップしてたりそもそも基板の設計不良でCLK以外の必須
の信号線すらプルアップしてなかったりしますがCLKに関しては基本｢宙ぶらりん｣で
良いと思います。と言いたいところですが！！
STM32のSDIO_CLKは非常に高速なクロックが走り、パタンの引き回しによっては
信号の反射によって猛烈なリンギングを発生させるため信号の信頼性が著しく低下して
しまいます。よってSDIO_CLKの出力端のごくごく近くに純抵抗成分を配置して
伝送経路のインピーダンスのマッチングを図り信号の反射を抑える必要があります。
最適な抵抗値は回路構成や回路パタンの引き回しに大きく左右されるため0~47ohmを
目安にオシロとにらめっこしながら切った貼ったをして決めましょう。繰り返しますが
直列終端は信号源のすぐ近くに配置しないと後で述べるフェライトビードの配置と
同じく全く効果がないどころか最悪パワーアップさせてしまいますので基板設計の
段階から考慮しておくべきです。
20160110追：
直列抵抗入れてもダメならフェライトビーズも足してください。
プルアップの他に注意すべき点は3つあります。
１．ブレッドボードの使用は避ける
ブレッドボードの使用は｢SDカードが繋がらない｣の諸悪の根源です。結線ミスが
原因のトラブルでブレッドボードで実験していたという証言が非常に多かったです。
ブレッドボードは確かに便利ですが、SDカードに限らず接触不良や接点抵抗の増大
によるさまざまなトラブルのもとに繋がります。面倒でも半田付けを行う癖をつけ
ましょう。とは言え何でもかんでも半田付けもだめです。丸端を圧着せず半田付け
とかもってのほかです＃
同じ理由でSDカードソケットに接触圧が弱く金メッキの薄い中華製の安物を使うと
接触不良につながります。注意しましょう。接触不良の問題は状態が変わりやすく
不具合を特定しずらいので厄介です。
ぇ？お前ブレッドボードより酷いやっけつな使い方してるじゃんですって！？
わ…ゎたしは理解した上でやってるからいいんですよぅ！
２．結線はなるべく短く
これもSDカードに限らず基本中の基本ですね。SDIOの場合はMAX52MHz、通常使い
でも25MHzもの高速クロックが走ります。クロストークが起こらないような配線を
考慮しなければなりません。
とはいえ利便性も考えないといけません。私の場合はSTM32F4Discoveryで使う
場合はトレードオフでカードコネクタに対してこんな配置にしております。
配線長が10cmを超えてしまうとTCK=21MHzだと"あうち"です。なるべく太く短くを
目指しましょう。ちなみにS¥パワーメッシュ基板を使うと配線もしやすくGNDも
安定していろいろ楽ができるのでオススメです。
３．電源
電源は出来合いのボードを使う際の意外な落とし穴になります。SDカードの仕様と
STM32F4で使用できる全てのSDカードのモードを考慮すると最大200mA必要と
します。
STM32F4Discoveryの3.3V(はショットキDi経由してるので3Vくらいに落ちる)
から無理に引っ張ってきても"何とか"動きますが高速で信号のやり取りを
していると特に書き込み動作の際に不安定になってきます。
こんな場合は、フェライトビードを無暗に挟むよりもSDカード電源供給専用LDOを
用意してあげると効果的です。このとき使うLDOはSDカードの高速アクセス時の
大電流の吸い込み吐き出しに対応するためにセラミックコンデンサ対応の負荷の
過渡応答性に優れたものを選んでください。
STM32でSPI限定で使用する場合、仕様上最大で100mAあればよいので秋月さんの
ラインナップでいうとXC6202P332PR-GやTAR5SB33で十分です。勿論LDOの電圧
供給源(ほとんどの場合はUSBの+5V)は評価ボートと同じ系統にしてください。
ねむさいんは当然のごとく攻守ともに優れたLT1963Aです♥
↑秋月さんも私が指摘してた'A'付きにようやく気づいたようでMLCC対応と明記してます。
全然考を察していない内容になっちゃいましたが次回は既存のライブラリを駆使
してMMC/SDIOドライバを組んで実際に動かすソフト編をご紹介します。
いろいろ試す21…という名の今年も反省会
お詫び
私ネムイ・トリノミアスは国土地理院とgooglearthの規約を思いくそぶっちして地図
画像をぶち上げておりました。ここにお詫び申しあげますm( _ _ )m
何がダメだったかというと国土地理院の場合はカシミール3Dを使用して表示した
画面を、googleearthは同プログラムを使用してGPS軌跡を表示した画面をキャプ
チャーしたものをブログ上にそのまま上げてしまったことです。
国土地理院のほうは問答無用の完全アウツでgoogleearthのほうは以前は
googleのロゴが画面中に出ていればOKだったのですが今はそれが完全に禁止され、
使いづらいAPI経由の地図表示でないと許されなくなっていました。
20160729追:
googleの方はくそ使いづらいAPIに苦情がありまくったらしく著作権帰属表記
がなされていれば問題なくなりました。よかったよかった♥
20160729追:
というわけで11月くらいからせこせこと過去の東海自然歩道やGPS/GNSS関連の
記事はそれらの問題に引っかからないように修正を今もし続けておりますす
みません。
とはいえ国土地理院に関しては承認をもらえば逆に参照し放題となるので
この際なので正式に地図の使用承認をもらうことにしました。
20230910追:
現在ではねむいさんのようなケースでは複製承認は不要になりました！
一応過去はこうでしたよという記録として記事はそのままにしておきます。
20230910追:
●国土地理院の地図の複製承認をもらう
以前は手続きが恐ろしく難解かつ面倒で敬遠されていたそうですが今はある程度
易しくなっているそうです。しかしながら相変わらずのお役所処理なので
そこらへんのことはしっかり理解して挑まないといけませんでした。
ねむいさんの場合、ブログ上でカシミール3Dで地理院地図を表示しさらに
GPSデータと高度データを追加で記載した画像、具体例をあげるとこんな画像を
ブログ記事上にて表示するための許可が必要ですが、これが法第２９条
「測量成果の複製承認申請」に相当します。
兎にも角にもこの"複製"が大前提です。では実際の手続きに入ります。
現在ではワンストップサービスなるもので申請が可能です。
このサイトの申請ボタンを押してスタート！…の前にユーザーを登録しなければ
なりません。なぜか先に進めてしまうのですが申請段階でログインしてないと
エラーではじかれてしまいます######
右上のログイン画面へのところで新規登録ができるので先に必ずしておき、
ログインも済ませておきましょう。
申請に関しては「基本測量の測量成果」を選択し、次への矢印をクリックします
すると目的を聞かれますので「地図の作成」を選択て次へ。
最初で述べた「複製」を行いますのでここは「紙地図・空中写真をスキャン（コピー）
し、あるいはラスタデータ型の数値地図（地図画像など）をコピーして基図とする」
を選択してください。
複製目的は「インターネット等により情報を提供する」を選択。
ここから複雑になります。ねむいさんの使い方では上記のようにする必要がありました。
そして使用する地図ではカシミール3D上では電子地形図(タイル)を表示します。
電子地形図(タイル)チェックを入れさらにツリー下のすべてにチェックを
入れてください。
｢複製する測量成果の交付年月日又は地図の発行年次｣は｢すべて最新版｣、
｢複製の範囲又は区域｣についてはねむいさんは日本全国を股にかけるので｢日本全国｣、
｢複製の期間｣は｢一年間(※これを選ぶと承認日より一年分の包括申請となります)｣、
｢複製品の利用方法｣は｢Webサイト等での公開｣、
｢有償無償の別｣はもちろん｢無償｣、
｢複製品の部数｣に関してはねむいさんはDropboxにファイルを置くので、
｢サーバー｣にチェックし、｢1部｣と記入します。
残りの項目は個人なら｢不備があった時の対応者｣以外は空欄で。
備考欄に｢確認のやり取りはメールでお願いします｣とすると電話連絡ではなく
メールのみで迅速に済ませられることができます。
これで申請ボタンを押して申請開始です。早ければ1週間ほどで承認番号を
付与したPDFファイルが登録したメールアドレスに送信されるでしょう。
PDFに記載された指示に従って作成した｢成果物｣を速やかに返信してください。
webサイトの場合はその画像が
あるURLを指定してください。
また、ねむいさんのようにやらかしてしまった人もかなり多く居るらしく、
その場合は速やかに指示に則ったフォーマットで画像を作成し差し替えるべし
と指導を受けました。
また、審査状況は申請処理を行った後に現れる審査状況タブからも参照できます。
そんなわけでねむいさんも国土地理院の地図を堂々と使用することができるように
なりましためでたしめでたし♥あとカシミール3Dから地理院地図を表示しているので
ちゃんと"Powered by Kashmir3D"と使用ソフト表記も追加しております。
●GCC ARM Embedded in Launchpadがアップデート
このぶろぐではデフォルトとなったLaunchpadのARM-GCCが予定よりちょっと早めに
バージョンアップしておりました。前回の更新は従来のGCC4.8.4からCortex-M7が
追加されただけだったのですが、今回はGCC4.9.3に上がっています。去年と同じく
いつものを使ってさっそくlibjpegとlibpngのデコード速度の性能比較をしてみました！
libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte
LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20141119 (release) [ARM/embedded-4_9-branch revision 218278]
@1201_7z SDIO_NSMODE_LIBPNG1.6.15
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 492036 0 492036 78204 main.hex
***libjpeg
174817uSec
***libpng
157300uSec
LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147]
@1201_7z SDIO_NSMODE_LIBPNG1.6.15
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 491948 0 491948 781ac main.hex
***libjpeg
181474uSec
***libpng
167060uSec
…イケてるじゃないですか(セルピコ顔で)
バイナリサイズは若干増加しましたがそれが気にならないくらいパフォーマンスが
上ってます！GCC4.8.4のSDIOのハイスピードモードでも勝つくらいの速さです。
これはすごいです。
…と言いたいところですが！
なんと最適化が効きすぎてメモリマップドI/Oのアクセスがごっそり削除されてしまう
ケースが存在しましたorzこちらのディスカッションでも話題に上がっていますが、
プリプロセッサを経由したちょっとトリッキーなアクセスになる場合、すべて
固定値として処理されてしまいますorz
身近な例ではSTM32F1系の旧USBライブラリ(STM32_USB-FS-Device_Driver)が
過剰な最適化の影響を受けます。ここでUSBのレジスタの読み書きの部分が
GCC4.9.3系でごっそり削除してくれやがるため、USB機能が一切機能しなく
なってしまいますorz
たぶん新しいCube系ライブラリではマクロを多用した抽象化が極めて激しい
ためもっとヤバい事態になると思います。まぁそっちは使わないからどうでも
いいですけど回避策として"usb_regs.c"の全体を-O0オプションでコンパイル
するようにpragmaをぶち込んで事を収めました。
現在F1系のUSB機能使っている作例で公開しているのは
STM32Primer2 GPS/GNSS Tracker
のみなので、旧F1系USBライブラリをご使用の方はそちらを参考にしてください。
ついでなので関数ポインタの怪しい部分も明示的にvolatile化しています。
●年末恒例ねむいさんFAQ
ねむいさんのぶろぐを運営するうえでメールやコメント欄(業者対策で全く機能
しなくなってしまいましたが)、はたまた私が虹裏メイドとしてまっとうに本業を
こなしてる時のスレ上において、そして副業時などで頂いたさまざまな
とんちんかんなご質問に対してわたしがとんちんかんに返答させていただきます…
Q:いままで問題なく動いてたのに急に(ry
Q:OpenOCDが動きません。
A:私もOpenOCDがうまく動かないので困ってググってみたのですがこいつのサイト
ばっかりヒットして非常に鬱陶しいです。なんとかしてくだち。
Q:(捨てメアドで)私は(日本語風の意味不明の文字列なので途中は割愛)
したがってあなたは開発者なのだから使い方をわかりやすくまとめる義務がある。
A:ここを100000000回声に出して読んでください。
なんですぐれたシステムとやらを納入してる実績をお持ちの割にはOpenOCDの使い方
すら理解しようと努力せず丸投げしてくるのか理解に苦しみますがそもそもOpenOCD
を業務で使用するほうが大間違いですがそれをやんわりたしなめたとたんに
仕事じゃなくて趣味の遊びですからとか言って逃げるのマジやめてくだち！
Q:ねむいさんのぶろぐをtwitterで薦めたらいきなりブロックされてしまいました(ﾆﾔﾆﾔ)
A:私のぶろぐを他者を攻撃する武器として使うのマジやめて。
ルネサス系のマイコン、とりわけ旧日立系の産廃H8,SHをﾄﾞﾔ顔で使ってたくせに
今更
STM32にﾄﾞﾔ顔で乗り換えてきたようなﾊﾅｸｿみたいな周回遅れの意識他界系な方々の
プライド最安値を刺激するのかほんとにヒット率高いです…でもそんなねむいさんも
職業訓練のマイコン演習の際に生まれて初めて触れたマイコンはH8とイエローソフト
のCコンパイラで、孫にあげるのはもちろんSTM32。
なぜなら彼もまた、特別な存在だからです。
Q:ねむいさんルネサスのこと嫌ってるくせにルネサスのデジトラ愛用してますよね？
い い え
唯一使用していたFB1A4MはROHMのDTD123YKT146に置き換えました。そもそも
NEC時代のFB1A4Mなのでﾉｰｶﾝですよぅﾉｰｶﾝうふふふ。
これは独り言ですがルネサスの半導体のうち置き換えがきくディスクリートデバイス
は早急に他社のものに置き換えたほうがいいです。旧NECエレの営業さんもROHM製品
を進めてましたしねむいさんの好き嫌いの話ではなく突然使えなくなる事態が迫って
いるので今からでも遅くはないですから急げ１！！！！！
さて問題は置き換えが効かないV850とかのCPUですが、こちらも徐々にARMに変えて
いこうと上司や社長に働きかけてます。すでにASICの代替でpsoc5採用になりましたし。
正確に言うとルネサスが嫌いなのではなくルネサスの中にいる旧日立系の残党が大大大嫌いなのです。
Q:(回路図・コード・てにをは)が間違ってます。
A:すみません教えていただいてありがとうございます。直しました。
Q:何故がた老さんにあなた作の描画ライブラリのバグだしをさせているのですか？
A:ごめんなさいごめんなさい！！！！
ちゃんとこちらでバグの箇所を見つけ修正しました。がた老さんいつもすみません。
Q:こんなバカな質問投げたのどう見てもあんたでしょ
Q:去年は年上にモーションかけてたくせに今年は年下かよ！
A:それわたしじゃありません！でも微妙に歳ごまかしてるように見えて他人のはず
なのになんか自分のことみたいですごいヤですね…副業先でも話題になってしまった。
突っ込みどころが多すぎて言葉に困りますがねむいさん
じゅうよんさいからそっちの33歳の厄年なねむいさんに一言だけアドバイス
送りますよぅ♨
自分のことばっか話すな。ちゃんと人の話を聞け###
Q:FETが焼けました。
A:焼いたFETの数だけ強くなれるはずです。
わざと焼くと逆に弱くなります。
Q:(ハルロックの)ハルちゃんいいよね…
A:いい…
Q:そっちじゃないだろ
A:ハルちゃんいいよね…
Q:ケモナー↓キ↑モいんだよ(C.V.置鮎)
A:気づかれたくなかったのでな…(C.V.麦人)
A:マジレスすると表紙に気合入りすぎて表紙詐欺の同人真っ先に思い出しｔウソウソ
ハルちゃん可愛いよ。マンガ読んだことないけど。
Q:↑をぶろぐに乗っけるといろんな意味でヤバいんじゃないの
A:線画だけだととびぃぶろくんにバレなくてセーフなのに気付きました。
たぶん肌色が見えたらアウトですね〜。
来年は虹メらしく手描きを強化していこうと思います
↑後で知ったのですが作中でSTM32F4を使う描写があったそうで、
ハルちゃんはSTM32を知っていることになり、この手描きは的外れでした。
Q:ねむいさんのぶろぐが会社/学校から閲覧禁止にされてしまいました。
A:
至極まっとうな会社や学校だと思います。
ねむいさんの副業先でも閲覧禁止されて自分のぶろぐ休み時間ですら見れませんから
おあいこですよHAHA!
…ｳｳｯ!
Q:ねむいさんのスレにたまに現れなぞの呪文を唱えるこれは何ですか？
A:そんなのこっちがききたいです…"｢｣はお前を監視している"ということでしょうか…
それはさておきKOUSHIROUさん主演のNHKのドラマがひどすぎて腹筋の筋肉痛が
いまだに直りません…
Q:｢ねむいさん｣って名前の人ってBL好きな人がやたら多いのですが貴女も…？
A:twitterで一押ししてた方のマンガ買って読んでみたんですけど単なる"やおい"に
ならず結構読ませる内容でしたよ…新たな世界が見えた…
ってわけでわたくし虹裏メイドねむいさんは朝田ねむいさんを応援しています♥
ねむいさんつながりですし♥
さて、そろそろ年越しそば作る時間になったのでこの辺で勘弁してあげましょう…
2014年も最後までドタバタ続きでまったく年が納まっていない感じですが
それでは皆様、よいお年を〜Zzz…
OpenOCD小ネタ14 -LPC1500シリーズの書き込み対応-
●LPC1500シリーズのフラッシュ書き込みに対応
長らく肥やしにされておりましたが先週あたりにようやくコミットされました。
LPC1500シリーズはIAPのアドレスがLPC1000やLPC800シリーズとは
別の場所にありますが、単純にLPC1500用のアドレスを追加するだけで
OKでした。上のリンクのやり取りの通り、LPC1500はCortex-M3
シリーズであり常にthumbモードなのでアドレスを奇数に設定してやる
必要があります。ユーザーマニュアルは微妙に取り違えやすい表現に
なっていて最初ちょっと混乱しましたが今はOpenOCD以外にも
オープンソースなプログラムがあるのでそちらも参考にさせて
もらっています。
●LPCLink2ConfigurationTool もパワーアップ！
さて、書き込む対象はLPCXPressoV2が仕込まれたLPC1549XPressoです。
購入当初デバッガ側に書き込まれていたCMSIS-DAPのファームはFL1100の
USB3.0ホストコントローラから認識せず(F**K!)仕方なくmbed版のCMSIS-DAP
を使用しました…
しかしVCP/MSDと折半になるのでただでさえ遅い速度が更に遅くなりしかも
書き込み後もターゲットのLPC1549をつかんだままになるので完了せず
エラーになるというちょっと不便な代物でした。
しかし今年11月になってようやく大幅更新されてリニューアルしました。
こんどのものはmbed版じゃない通常のCMSIS-DAPでも仮想COMが実装され、
MBED版CMSIS-SAPに近い構成になっています。ちなみにLPC-Link2も同じ
ように仮想COMが使用可能となってます。
しかも書き込みスピードがちょっと早くなってます。今のHIDのﾁﾏﾁﾏ書き
込みの制限だと2kb/Secくらいの早さでしたがUSB3.0ポートだと5kB/Sec
くらいにアップしてます！やったね！
…と言いたいところですがUSB2.0のポートだと逆にパワーダウンして
0.48kB/Secに落ち込んるのが判明orz
はやくOpenOCDにもCMSIS-DAPのブロック書き込みが実装されますように…
ちなみに新しいLPCLink2ConfigurationToolはJLinkのファームウェアも
ありますが残念ながらこちらは何ら変更はなくSRSTの直接操作不能バグ
ありのままです。LPCLink2をJlinkとして使用されている方はSRSTの
コントロールは省略してください。Cortex系ではsysresetreqが代用できます。
OpenOCD小ネタ13 -ビルド環境のアップデートとWindows8.x一部対応-
20150106追：
現在おきぱにあるopenOCDバイナリはWindows8系にも完全対応してます。
20150106追：
OpenOCD等のWindows版バイナリをビルドする際は、私はMsys/MinGWを使用し、
GCCのバージョンは4.7.3でずっと使用してきておりました。
しかしこれからのツールの趨勢に備え、相変わらずの重い腰を上げてビルド
環境のアップデートを試みました。
●msys-coreのアップデート
yamidori98氏のレポートによるとパラレルでmakeした時(-j2とかの
スイッチかました時)にハングする可能性が指摘されていてパッチを当てた
msys-1.0.dllに差し替える必要があるそうです。OpenOCDをビルドする際は最後の
makeが並列化してますのでこれは適用すべきかと思います。
(64bit版Win7ではまだハングに遭遇してませんが)
ビルドに関してはコマンド一発でdllその他諸々をアーカイブしてくれるスクリプト
ファイルが提供されていたので非常に助かりました。ありがとうございます。
●makeを3.82に
同じくレポートを参考に現状最新v3.82のmakeをmakeしました。
そうだね駄洒落だね。こちらもスクリプトファイルを用意してくれていたので
ありがたく利用させていただきました。
●GCCをアップデート
最初に述べたとおり、従来よりrubenvbさん所の個人ビルドのGCC4.7.3を
使用していました。実はGCC4.8系に上げてビルドすることを過去に何度か
試してみたことがあったのですが、libgcc_s_sjlj-1.dllが無いとか
InterlockedCompareExchange@12が見つかりませんだとかそういうエラーに
阻まれてとりあえず動くの優先！ということでそれらのエラーが出ない
4.7.3を使ってきた次第です。
これらのエラーはバージョンが上がる際の一時的なものだろうとスルーして
いましたがアップデートを考えていた4.9.2でも同じようにlibgcc_s_sjlj-1.dllが
無い問題が発生したので仕方なくいろいろ調べているとlibstdcとlibgccを
明示的にスタティックリンクにしてやればdllを求められることがなくなる
ことがわかりました。
libusbでいうとCFLAGS,CPPFLAGS,CXXFLAGSに"-static-libgcc -static-libstdc++"
を付与すれば終わりです("-static"は特に付けなくても大丈夫でした)
しかしそれだけではうまくいかなくて得られたlibusb-1.0.dllを差し替えると
今度はlibftdi1.dllでInterlockedCompareExchange@12が見つからないと
エラーを吐いてきました！
こちらに関してはdllとそれ呼び出すexeが異なるバージョンのGCCでビルド
されていた場合に発生することがわかりEXEもDLLも全て同じGCC4.9.2で
ビルドするようにして解決しました。
最終的にOpenOCDをはじめとしてUrJTAG,vsprog,Flashrom,avrdudeも
GCC4.9.2版のビルドで安定して動作せしめられるようになりました♥
●Windows8でSTLink/V2-1がOpenOCDから繋がらないこともなくはない
環境がGCC4.9.2化出来たので、今度は使用するユーザーが増えて多数報告を
戴くようになった"Windows8.x系でSTLink/V2-1が載ったNucleo板がOpenOCD
から繋がらない問題"に漸くまともに取り組みました。
といっても私はWin8機を所持しておらず副業先のPCたちも全部Windows7機
だったので、不具合を再現させるための環境が全くなく問題の切り分けも
困難を極めておりました。で、唯一Windows8.1を所持している知り合いの方に
頼んで３〜４日オーダーのフィードバック速度でああでもないこうでもないを
繰り返し、ついにlibusb-1.0をビルドするときに当てているAsmedia対策の
パッチが原因だったことを突き止めました！またAsmediaか！！
最初にAsmedia対策パッチを検証した際にXPと64bit版Win7では全く問題
ないことを確認していたのですがWin8ではUSBデバイスの取り扱いもさらに
厳しくなった(?)ことからパッチを適用した部分が仇になってデバイスを
Open出来なくなっていたようです。
幸いにも2014年11月現在は別の切り口でAsmedia対策のパッチが提供
されていてそちらのパッチに変更してビルドしたlibusb-1.0.dllでは
Windows8でもばっちり動作しました♥長かった…
というわけでWindows8.1系OSでもOpenOCDが利用できるとっかかりが出来ました。
現在Win8環境下で私が動作保証できる組み合わせは以下のデバッガ
アダプタです。
1:STLink/V2-1(Nucleo板,STM32F053Discovery)
2:STLink/V2(Discovery系板たくさん)
何れもSTマイクロ配布の公式ドライバ(WinUSB)を適用したものです。
もしあなたの環境で上記の場合でもうまくいかない場合、Zadigを使用し以下の
手順でSTLink/V2-1のUSB複合デバイスの親("composite parent") に無理やり
WinUSBを適用して単独の”STLink/V2”として使用する荒業もあります。
ただしこれをやると仮想COMやmbedのマスストレージ書き込みが一切使用
できなくなりますのでご了承ください。
とりあえず通常のドライバを適用した後Zadigを起動し、
"List All Devices"にチェック入れる、
"Ignore Hubs or Composite Parents"のチェック外す
すると"STM32 STLink (Composite Parent)"が現れるのでこれをWinUSBに
置き換える
入れ替えの際に間違えて違うデバイスにWinUSBを適用してしまうと復帰
できなくなる危険性がありますので細心の注意を払って作業してください。
OpenOCD小ネタ12 -HLA向けのcfgファイルの統合-
お盆前に行われたOpenOCDのHLA系コンフィグファイル大変更への対応を
幾つかのターゲット向けの試用実例と交えて解説します。
とその前に！
最近再び似た質問を多数いただくようになったので･･･
●STLinkがOpenOCDで動きません。
NxP系マイコンのCheckSumValidationと同じく何度も言ってますが
何度でもおさらいです。質問が続く限り何度でもなんどでも な・ん・ど・で・も
説明します！
注:STLink/V1はもう持ってないのでサポート外です。STLink/V2とSTLink/V2-1系向けです。
20140902追：
2014年9月現在、Windows8.x系環境下でSTLink/V2-1がOpenOCDから
利用できません。これはlibusbがWin8.x環境下でUSBコンポジットデバイスを
正しく扱えてないことに起因するものだそうです。
libusbに修正かかるまで辛抱強く待つかXP/Win7に戻すのです！！
STLink/V2の方はコンポジットじゃないのでWin8でも問題なく使用可能です。
20141114追：
Windows8.x環境下でのOpenOCDサポート開始です
１．基本的な結線は本当に正しいか
STLink/V2系はSRST,Vtgt(ターゲットのVCC),SWCLK,SWDIO,GNDが必須です。
SWCLKとSWDIOを"てれこ"にしてたりGND繋げてなかったとか論外ですが
(そういったケースもありました…私に直接返信はなく質問された方の
twitter上の発言でそれ知ったのですが…＃)まず第一にGND,SWCLK,SWDIOの
結線がターゲットのMCUと正しくなされているかを回路図を良く見て
テスターで導通をしっかり確認してください。
２．SRSTは繋がっているか
現在ではNucleo/Discovery等のメーカ製評価ボード向けの特製cfgはすべてSRSTを
使用するように設定されています。したがって私の特製cfgもそれに準じております。
stlink-v2.cfgを直接呼び出す使い方を中途半端に真似ると引っかかるので
ご注意ください。Nucleo/Discovery等のメーカ製評価ボードから自作のボードに
環境を変えた際にSRSTの接続を忘れ上手く動かないといった連絡を特に戴いています。
回路図を良く見てテスターで導(ry
３．Vtgtは繋がっているか
また、Vtgtの接続もほぼ必須です。これも"２．"と同様ですが特にNucleo/
Discovery等のメーカ製評価ボードからデバッグ線を引き出して自前のボードと
繋げる際に発生します。
ネット上では情報が倒錯しOpenOCDではVtgt必要ないと断言している記述も
あるのでご注意ください。
ねむいさんは一貫してVtgt繋げろです。
STLink/V2は接続の際にまずSWCLK,SWDIOの電圧を読みに行ってVtgtの電圧
よりも相対的に高い電圧とみなすとその後の一切を弾くのでコケて絶対先に
進めません。これはファームウエアレベルでこういう動作をしますので
特定のソフトに依存はしません。
メーカ製ボード上ではVDDがSBDで切られてVf分のドロップで3.0V前後と
若干低くなった状態で動作しているので気づきません。しかしながら自作の
ボードではほとんどが3.3Vで使用されるともいます。このときSWCLK/SWDIOの
電圧はデバッガ側より必ず大きくなるのでコケます。
また、以前も触れましたが一部のボードではコスト削減のためVtgtにつながる
抵抗が実装されていないものもあります。
ケアレスミスで時間を浪費しないように回路図を良く見(ｒｙ
･･･
STLiink系ばっかりに力入れるわけにはいかないので本題に入ります。
●分かれていたコンフィグファイルが今一つに！
これです。目的はSTLink/V2やTI-ICDI等のHLA(HighLevelAdapter)も
従来のFTDI/JLink等と同じコンフィグファイルを使用できるようにする修正です。
もともとHLAは各メーカが提供する独自のデバッグ用APIをOpenOCDでも利用できる
ようにと組み込まれた機構です。したがってターゲットMCUへのローレベルな
アクセスができない、クロック周波数の設定等のアダプタ側でも細かい制御も
できないといった制約があります。
ですのでその挙動の違いから使用可能なコマンドも分けられており、従来は
各MCU向けのOpenOCDコンフィグファイルも通常のものとHLA系に分けなければ
なりませんでした。
しかし今回の修正でHLA系で使うとエラーになっていたadi_v5系のローレベルの
コマンドがエラーとならずオーバーライド(スルーとも言う)できるようになり、
hla専用cfgは晴れてお役御免となったわけです。
さて、変更されて箇所は分かりましたがそれを実際にどう反映させればよいかと
いうと･･･OpenOCDを呼び出す際の引数として、もしくはcfgファイル内に
"transport select"コマンドを追加で付与します。
以前はHLA系アダプタを使用する場合はトランスポートが決め打ちだったので
STLink/V2やTI-ICDIのcfgファイルに直接記述されていた物が外に追いやられた
形になってます。EFM32TG822F32の例を取って新旧のOpenOCD引数比較をします。
下記の記述はこちらのデバッグ手順に準じますので事前に把握をお願いします。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-f target/efm32tg822f32_hla_flash.cfg
新：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/stlink-v2.cfg ¥
-c "transport select hla_swd" ¥
-f target/efm32tg822f32_swd_flash.cfg
こんだけです。TI-ICDIの場合はJTAG接続専用なので"hla_jtag"になります。
STLink/V2,STLink/V2-1はSWD専用なので"hla_swd"です。
メーカ製出来合いのボードの場合、OpenOCDのボート向けcfgで対策されたのが
ほとんどなのでこちらで修正する必要はないです。
Nucleo-R334板(STLink/V2-1付)の例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f target/nucleo-f3_flash.cfg
因みにcmsis-dapの場合も現状SWD専用なのでswdが自動で選択されるので特に
変更は不要です。トラ技ライタ(LPC11U35)にCMSIS-DAPで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/cmsis-dap.cfg ¥
-f target/lpc11xxx_swd_flash.cfg
さらにJTAGKey2等の汎用のJTAGの場合は何も指定しない時はデフォルトで
JTAG接続となるので余計な指定は不要です。
STM32F407ZGT6にJTAGKey2で繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/ftdi/jtagkey2.cfg ¥
-f target/stm32f4x_flash.cfg
JLINKやVersaloon,FT2232系でSWDしたい場合は宣言は必須ですがこの3つに
関しては私のcfgレベルで対策済なので私が提供するバイナリとcfgを
使う限りは変更不要です。STM32F407ZGT6にVersaloonで繋げる例を示します。
旧：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg
新(旧と全く同じ)：
OCD_ARG = -s $(OCDIR)/tcl ¥
-f interface/vsllink_swd.cfg ¥
-f target/stm32f4x_flash.cfg
現在のOpenOCDでは以下の4つのtransportが存在していますが、hla系は
上記の要領で多少の変更を追加するだけで対応可能となっています。
transport select jtag (transportを何も指定しないときのデフォルト)
->FT2232系,JLINK系,Versaloon,その他多くのJTAGデバイス
transport select swd
->FT2232系,JLINK系,Versaloon,CMSIS-DAP
transport select hla_swd
->STLink/V2,STLink/V2-1
transport select hla_jtag
->TI-ICDI
なお、今回の統合でSWD接続においてレグレッション・テストを行って
いなかったようでSWDでエラーが発生してしまいました。私はお盆前に自作の
パッチを適用したバイナリを公開していましたが現在はこの問題に気付いた
方が別のアプローチからパッチを提出しマージされております。
LPC17xx系でDAPIDの問題が残ってますがマイナーな問題なのでじきに
修正されると思います。
現在はすべてのtransportでスムーズにOpenOCDが利用できます。
あとは微妙に残ってるJTAG依存な処理の完全切り離しとSWDのSRSTコント
ロールの最適化が達成できたらOpenOCD導入のハードルは下がると思います。
というわけでおきぱにあるOpenOCDバイナリもどしどしご利用ください！
OpenOCD小ネタ11 -EFM32 ZeroGeckoとJLinkのSWD接続正式対応-
以前ちらっとお見せしましたがEFM32のZeroGeckoシリーズの
評価ボードをだいぶ前に手に入れて、評価しております。
MCUにはおなじみトカゲのマークがあります。Cortex-M0+コアを持つ
EFM32ZG222F32が搭載されています。
ボードは低消費電力のアプリ作成を意識したものになっていて搭載されて
いる液晶もメモリ液晶と呼ばれる超低消費電力なものとなっています。
最初に書き込まれているプログラムは、メモリ液晶を利用したインベーダー
もどきなゲームを遊ぶことができます。
なおこのゲーム、一機死んだら即ゲームオーバーなかなりシビアな代物です！！！
今回の記事に合わせ、私が基本としているLED&UARTなEFM32評価ボード向けの
GCCプロジェクトも作成しております。
低消費電力モードは使わず極めてシンプルな代物です。
また、以前もふれましたがOpenOCDからもEFM32ZGシリーズも書き込みが
できるように対応しております。EFM32自身はSW-DPしか持たないので
書き込み/デバッグするためにはSWD接続可能なアダプタが必要となりますが
現在ではSTLink/V2,JTAGKey2,Versaloon,そして後で述べるJLinkがSWD接続
対応のデバッガアダプタとしてOpenOCDから使用可能になっておりますので
不自由はしないでしょう。
こちらは素組みのEFM32ZG板をSWD接続版のJTAGKey2でデバッグしてる
ところです。もうおなじみの画面ですね。
話は評価ボードに戻しますがこちらにはJLink-OBと呼ばれる他社向けの
MCU評価ボード専用のJLinkが搭載されております。LPC-Link2等でもほぼ
同じ仕組みでオンボードでJLinkをエミュレーションしていますが従来、
OpenOCDからはJTAG接続だけが可能でした。
したがってSW-DPしか存在しないEFM32ではOpenOCDで書き込みデバッグする
際はオンボのJLinkは無効にしてSTLink/V2やVersaloonのSWD版で使用
せざるを得なかったのですが、少し前にJLinkも
正式にSWD接続に対応し、単体でフル活用できるようになっております♥
オンボJLinkでOpenOCDです。JLink純正のドライバじゃないと外部に
デバッグプローブを引き出すことはできませんが私の場合はJLinkエミュが
可能なLPc-Link2を所持してるので通常はlibusb-1.0のみで十分だと思ってます。
ここでOpenOCDでEFM32シリーズを操作するためのコツですが…EFM32は
リセット直後の短い時間の間だけSWDの信号線が別の独自のデバッグ
プロトコルとして挙動するのでSRSTと組み合わせて操作することが
できません。したがって"connect under reset"は使用不可能になります。
誤って低消費電力モードにしてしまうとOpenOCDからの操作ではもう
元に戻せなくなりますので、くれぐれもご注意ください。
しかしながらEFM32板のオンボJLinkはsegger純正ドライバとEFM32が
提供するデバッグツール"energyAware Commander"から独自プロトコルの
操作が可能なため、初期状態に戻すことができるので心配はいりません。
ここまではEFM32とオンボJLinkについて述べてきました。私はJLink化が
可能なLPC-Link2を持っていますのでLPC-Link2にJLinkのファームウエアを
再び書き込みこちらも同じようにSWDで接続出来るか試してみたいと思います。
↑ターゲットはトラ技ARMライタという名のLPC11U35板です。
ライセンスの関係上NxP以外の製品で使うところはお見せできませんが
OpenOCDではほぼすべてのARMマイコンを書き込みデバッグできる攻守ともに
非常にバランスの良いデバッガアダプタとなりました。
20kBほどの同一のバイナリを同一のUSBポートから書き込んだときの
CMSIS-DAPとJlinkエミュとの速度の比較です。
*CMSIS-DAP on LPC-Link2
wrote 20480 bytes from file main.elf in 10.265428s (1.948 KiB/s)
verified 20204 bytes in 0.437491s (45.099 KiB/s)
*JLink on LPC-Link2
wrote 20480 bytes from file main.elf in 2.624950s (7.619 KiB/s)
verified 20204 bytes in 0.265620s (74.281 KiB/s)
CMSIS-DAPファームの時はOpenOCDの実装がせっかくのブロック転送機能を
フルに利用していない残念仕様のためやたらと遅いのですがJlinkエミュなら
バルク転送がびしばし使えるので超早いです♥但しSRST/TRSTの操作が
ちょっと怪しい所があります。
seggerの純正のツールではちゃんと操作できるので時間を見て両者の挙動の違いを
詰めて行きたいと思います。現状SRSTを必ず要する場面は限られていますので
JLinkエミュにしっぱなしの方がサクサク作業を進められると思います。
ねむいさんのおすすめです。
(※ただしNxP製品以外の書き込み/デバッグに使っちゃ駄目ですよ！)
20140820追:
F**K
今回は数日前のOpenOCDのコミットでHLA(HighLayerAdapter)系デバッガ
アダプタのcfgが一般の物に統合されたというかなり重要なことについても
お伝えしたかったのですが、JlinkのSWD対応の紹介で長くなりすぎましたので
次回じっくりと解説させていただきます。
OpenOCD小ネタ10 -VersaloonのSWD正式対応とKinetisドライバの小改修-
●祝!Versaloonが正式にSWD接続対応になった。
先日、JTAGkey2に代表されるFTDI系のデバイスがSWDに対応しました。
それに続いてVersaloon(OpenOCD内ではvsllinkと呼ばれています)の
コードも大幅に見直しがされてSWD周りのadi-v5の依存部分が完全に分離、
再構成されて晴れて正式にSWDに対応となりました。
それに伴い以前紹介していた導入手順と変更になる個所が幾つか
ありますので、皆さんが迷わないように変更すべき個所を以下に述べます。
1.LibUSBが0.1系から1.0系になった(超重要！)
Versaloonは従来からUSBのドライバとしてLibUSB0.1系APIを使用して
いましたが、今回のSWD対応で1.0系に切り替わっています。
Zadig等の自動インストーラで0.1系ドライバを適用してる場合は
LibUSBKかWinUSBに切り替えておきましょう。
2.Versaloon用cfgファイル
ねむいさんはVersaloonのswd対応用として特別なcfgファイルを提供して
おりました。その中でVersaloon用の固有コマンド"swd_delay"と
"swd_trn"が設定されていましたが、swd_trnは2に固定化されハードコード、
swd_delayはイニシャライズ時のadapter_khzの解釈に取り込まれそれぞれ
廃止になっております。自作のswd用のcfgを作成されている方は
swd_delayとswd_trnの定義は削除してください。
ソースコードを見た限りではJTAGKey2を使う場合と違ってSWCLKの
クロックの設定最初の定義以降は動的に変えられないように見受けられ
ましたが(ソース上では変更できる余地がある)あえてそうした理由も
含めてこれからさらに探ってみます。
私のOpenOCDのバイナリは既に正式にSWDに対応した版に切り替わって
いますがまだVersaloonを現役で使用されている酔狂な方は上記2点を
見直し各自対応願います！
●VersaloonのConnetUnderResetとkinetisドライバと
"今まで正常に書き込めてたのに急にうまく動かなくなった"問題をほぼ解決
してくれる心強いConnectUnderReset機構はSTLink/V2で絶賛活躍中です！
…と言いたいところですがSWD接続の場合、STLink/V2以外の殆どの
デバッガアダプタでマトモに機能していないことが判明しましたorz
それが判明した経緯は私がOpenOCDのgerritにkinetisドライバのちょっとした修正を
送ったことにあります。他のユーザさんから"Kシリーズでセキュリティ状態の
有効/解除上手く出来てるのか?"と問われ、SWD接続の方のVersaloonで試して
みると確かにセキュリティ状態が解除できませんでした。手でリセットボタンを
連打すると解除できたのを不審に感じ、
(Kinetis-Kシリーズはセキュリティ状態の解除に外部SRSTの操作が必須。
3月初めにkinetisのフラッシュドライバに大幅変更がかまされたとき
KL25とかのKLシリーズでしか試してない人がリファレンスマニュアルを
よく読まずKLシリーズに特化して機能を再実装してしまった…！
そのせいでK40とかの古いシリーズではうまくいかなくなるという
憂き目にっていうか前々々回のguranualityがらみでエンバグ直した時もそうだけど
お前らちゃんとリファレンスマニュアル読めやぁあああああああああああああ！！)
…ッ…はぁはぁすみません取り乱しました…ぇっとオシロスコープでSRSTの
動きを観測するとまったくConnectUnderResetしておりませんでしたorz
↑全くダメですこれ
ねむいさんてっきりハイレベルなレイヤでこの機構が入ってると思ってた
のですが････
なんとSWDの場合だけローレベルのデバッガアダプタ依存処理なのでしたorz
というわけでvsllink.cのイニシャライズの所にConnectUnderReset機構
ぶち込んであっさり終了です#
↑これですよこれ！
まさかと思ってJTAGKey2でSWD接続で試してみると同じ結果でしたorz
↑SWD接続orz
↑JTAG接続だとちゃんとConnectUnderResetしている…
手前にresetがHレベルにあるのにTCKが動いてますがこれはSWD-JTAGの
移行シーケンスなので電源投入直後なら特に問題はないです
(正直これもちょっと？？？ですが)
おきぱにあるバイナリは現状VersaloonにだけConnectUnderResetの
ぱっちを当てていますが、FTDI系は一筋縄ではいかずかなり手ごわいので
慎重に対応していきます。
GPS/GNSSモジュールを試用する12 -Canmore GP-102+を使う-
>ＧＰＳモジュール ＧＭＳ６−ＳＲ６（ＧＰＳ／ＧＬＯＮＡＳＳ対応）
お前は選ばれなかった…(C.V.麦人)
消費電流多すぎです。っていうかGPSじゃなくてGNSSモジュールですよ。
>ＧＰＳモジュール ＧＭＳ６−ＣＲ６
お前は選ばれなかった…(C.V.麦人)
GLONASS取れないとか･･･
>GPSモジュール [GM622T]
お前は選ばれなかった…(C.V.麦人)
Gms-g9の性能知っちゃうとどうもね･･･
>極小高性能GPSモジュール [GM5157A]
お前は選ばれなかった…(C.V.麦人)
MT3337ってMT3333/3339の機能シュリンク版じゃないですかー
自由度めっちゃひくいじゃないですかー！ﾔﾀﾞｰ！
･･･
>ＧＰＳロガー Ｇ−ＰＯＲＴＥＲ Canmore GP102+
ぁ、こんなん入荷してる･･･単なる既製品だけどこれでいいや
というわけで2011年初頭より自作GPSロガーの比較・サブ機としてとして長年
連れ添ってきたGP101がとうとう永眠してしまったため新しいサブ機を購入
することになりました。
最初はGarminのナビ付きの高級機を考えていたのですが目的がロギングだけ
なのと地図は必ずアナログデバイス(=電池いらずの紙)を利用すると硬く心に
決めているので結局秋月さんちから販売されていたGP101の後継機ともいえる
GP102+に落ち着きました。価格も安くなってますし。
さて、このGP102+はかなり新しめの製品なのでGPS信号の解析用チップに
SIRFStar4が搭載されておりQZSSの補足も可能になっています。
2014年現在はみちびきから送信されるGPS補完信号が利用できることに
なります。ちなみにGLONASSは利用できません。
恒例のモジュール性能比較…と行きたいところですが今回はGP102+に
使用されているSIRFStar4と私の使ってるGms-g9との分かる範囲での
カタログ比較となります。GP102+全体の性能はまた別となるので
その点は厳重にご注意ください。
また、後でも述べますが付属のマニュアルだけでは操作に？な点が
数多くあるのでJR7CWK氏によるGP102+使用記は必見だと思います。
●ファーストタッチ
さて、このGP102+は操作にかなり癖がありますので注意が必要です。
初期型のGP-101と違い、電源投入はボタン長押しになりましたが投入後すぐに
ロギングは開始してくれません。目的にあったロギング方法を選択してから
スタートとなります。
ちなみに電源OFFはメニューボタンで電源のアイコンにカーソルをもっていき、
そこでメニューボタン長押しです。
詳しい操作はマニュアルをご参照して各自で体で覚えてください(丸投げ)。
…とここまでは一度でも衛星を補足した後の状態の話ですが…なんと購入
直後の場合は最初の電源投入で衛星を補足して現在時刻が得られるまでは
各種操作が一切できません。電波が入らない屋内では文字通り一歩も
進めないのでとにかく衛星を受信しないと行けません
…ねむいさんまずそこでﾊﾏりましたorz
ねむいさん的には電源ONしたら即ロギング開始&衛星受信してなくても各種
設定可能なようにしてほしいと感じました。ちなみに初期GP-101は電源
ボタンを一瞬でも押したら即電源ONでそこから一瞬でも電源ボタン押したら
問答無用で即OFFというザックに無防備に放り込めない代物でしたからそれと
比べたらまだましですがー！
そんでもってUSB-miniBケーブルでPCを接続するとどこかで見慣れたマス
ストレージが現れます。どうやらGP-102+の制御にはSTM32が使用されている
ようですね。なんか私のGPSロガーに似たものを感じて愛着が早くも湧いてきました。
その変わり仮想COMポートは出てきません。
SiRFStarから送出される生NMEAは直接取れないようです。
ファームウェアの更新はおなじみのSTM32のDFUで行います。ちなみにDFU
モードに入るたまには特定の順序でボタン押しっぱにするのですがDFU
モードに入った直後にボタンをすぐに離さないと勝手に電源が
OFFになりやがりますのでご注意ください#ねむいさんここでもハマりましたorz
●実際のフィールドで使ってみよう！
Part1・長浜駅周辺
ねむいさんGWに入る直前に右ひざにヒアルロン酸を注入していたので、
トレイルランのような重負荷の運動が出来ず、GW中はウォーキング程度の
軽い運動をしていました。てわけで長浜駅周辺に観光に行ったついでに
GP102+と自作GPSロガーのロギングデータとの比較を行ってみました。
長浜城です。
大閣井戸と琵琶湖です。琵琶湖北部に来たのはじめてでした。
伊吹山です。ここは今秋にちゃれんぢします！
市街地に戻り北国街道を通って黒壁という場所に行きます。
黒壁と呼ばれるこの区域も観光地となっています。
近江牛のにくまんです♥
お土産たくさん買い込んで帰宅です♥そうだね単なる観光だね。
GP102+はこのように走行距離も表示されます。
ポケットでも邪魔にならないサイズなので普段のランニングにも使用してます。
このようにして取得したログはCanWayなるツールで取り込みGPXや生NMEAに
変換しｔ・・・・
！？
F*********************K！！！！！！！！！！！
何度やっても取り込みしようとしたら上記のようなオブジェクト参照が
うんちゃらのエラー吐いて強制終了してしまいましたorz
CanWay使えなかったらどうやってログデータ取り込むのよ！！！と憤慨して
おりましたが、PCでマスストレージで接続していることを思い出し、SIRFStar
からの生NMEAをSTM32でさらに加工したと思われる拡張子がfitのログ
ファイルを発見しました。
どうやら規格が存在するフォーマットだったようでGPSBabelを使い
NMEAやGPX形式へと無事変換することができました。めでたしめでたし。
注：画像は5/24の生駒山脈にトレランに行ったときのログです。
というわけでカシミール3Dを使用して自作GPSロガーとGP102+の軌跡の比較です。
街中なので正直どっこいどっこいですね…
Part2・近畿自然歩道(生駒縦走路)
ｺﾗｺﾗなに回れ右してるのですかこっからが本番ですよぅ！
近畿自然歩道はねむいさんが全走破した東海自然歩道と同じく日本を代表するトレイル
です。東海自然歩道と違って一本道ではなく、一つのテーマに沿ったルートが網目の
ように近畿圏を覆っています。ねむいさんは既にいくつかの近畿自然歩道を走破して
いますが総延長が3000km以上あるとのことでもうライフワークに
なりそうです。
今回は近畿自然歩道｢生駒山・鳴川峠・十三峠をめぐるみち｣と
｢高安山・信貴山をめぐるみち｣の2ルートを走ります。それではいざ出発！
まずは石切駅を出発し旧生駒トンネルの脇を登り登山道に入ります。
なんとこの日は旧生駒トンネル内御開帳の日だったみたいです！
少しの間急峻な登山道を登り生駒縦走歩道に落ち合ったら緩やかな
尾根道となります。
くさか園地の舗装路にでました。緩やかな舗装路をさらに登っていきます。
トレイルと舗装路を交互に交わして生駒山上遊園地に到着です。
生駒山頂は生駒山上遊園地敷地内のミニSLの中にあり、禁足地(?)です！
生駒山頂遊園地から離れ、暗峠がある国道308号線を目指します。
国道308号線と落ち合った後はすぐに308号線から離れますが･･･
去年と同じく暗峠に立ち寄りました♥
峠の茶屋さんも営業中です。
今年のカキ氷は霙です！！
生駒山頂からは別ルートで暗峠に直接出られます。
生駒縦走路/近畿自然歩道のルートに戻りさらに先を進みます。
車道を登りなるかわ休憩所に。ここは水洗式トイレがあります。
トレイルをひた走り鳴川峠です。
鐘の鳴る丘展望台です。鍵をつけられる場所があり、カップルもよく
訪れる場所だそうです。
十三峠の最高点です。･･･おや･･･？
良く見ると尺取虫さんが･･･ヒルじゃないよ！
十三峠を抜けてすぐのところは注意が必要です。道標にしたがって進むと
ルートミスです！生駒スカイラインと平行に進むのが正しいルートです！
しっかし間違えて進んだルートまで正確に軌跡をorz
３０分くらいルートミスったってここはすぐ京都に帰れる場所だからｷに
しない気にしない！！そそくさと高安山方面に向かいます！
この謎のヘリコプターの発着場みたいなのは国土交通省の航空レーダー
だそうです。ヤマレコでご指摘いただきました。
立石越につきました。高安山までもうすぐです。
高安山からの信貴山への分岐。実は近鉄高安駅から信貴山まで行ったことが
あってこのあたりは結構詳しかったりするねむいさん。
ケーブル高安山駅に到着です。自販機もあるので補給をかねて小休止です。
かつてはここから信貴山門前まで電車が走っていたそうで･･･
近畿自然歩道はケーブル高安山駅で終点かつスタート地点なので折り返します。
画像は八尾方面からも目視できるレーダー観測所。
高安山の山頂分岐はめちゃくちゃ目立たない場所にあるので見逃さない
ようにご注意ください！ていうかなんだこの看板･･･
さて、信貴山への分岐に戻ってきました。舗装路を駆け下りて朝護孫寺
(信貴山寺)に向かいます。
次に目指す矢田丘陵が見えますね〜
ってもう行きましたけどー！
ここを左に行くと矢田丘陵に向かう道です。今回は右に進み信貴山を経て三郷駅へ
向かいます。
朝護孫寺境内に到着です。
今回は信貴山頂上がある空鉢護法へと上ります！
はぁはぁ･･･25km近くフルパワーで走ってきた後ののぼりだからキッツいわ･･･
空鉢護法に到着です。
絶景ですね〜♥
ちなみに空鉢護法では虎ではなく蛇の巳(みー)さんが祀られております。
･･･形は似てますがアラレちゃんに良く出るアレではないですよぅ！
同じく山頂には信貴山城跡もあります。
山頂を離れ境内に下りてきました。本堂が遠くに見えます。
その本堂です。奈良盆地が一望できます。
本道からさらに降りて三郷駅への岐路に着きます。
有名な張子の寅さんです。信貴山頂では蛇ですが山ろくでは寅です。
ここでいったん近畿自然歩道のルートから外れ、開運橋を渡り車道を下ります。
ぐるっと旋回しておなじみの国道25号線と落ち合います。
住宅街を駆け下りてゴールのJR三郷駅に到着です。
次回のルートはここを基点に今一度信貴山寺に行き、
そこから矢田丘陵を目指す道に…
なります。先にも触れましたがすでに走破してますがこちらのレポートも後日に･･･♥
･･･なんですかそのげんなりした顔は！？
というわけで今回走った軌跡の全体図です。距離が長すぎてほとんどぴったり
重なってますが互いに一長一短ではありますが致命的に外してるところは
無いようなのでGP-102+は私の自作GPSロガーのバックアップ機として十分に
活躍してくれそうです。これからもﾖﾛｼｸ！
OpenOCD小ネタ7 -JTAGKey2でSWDできるじゃない！-
20140708追：
ついにSWDに正式対応しました！
20140708追：
ここ数日OpenOCDのgerritにVersaloonのSWDサポートの修正が盛んに
あげられていて、私もいろいろﾖｲｼｮしております。同時に汎用のSWDドライバも
見直されどんどん変化しております。
その矢先になんかすごいの来てました。FTDIデバイスのSWD対応です！
しかも結線がめっちゃ簡単でJTAGKey2(Compatible)系のバッファがついたもの
でも極めて簡単な回路の追加でSWDれます♥
本来FTDIデバイスのSWD対応については約一年前、libswdというのがコミットに
当たりかけていたのですが実装に関する思想をめぐりくだらない激論となり
スクラップ状態で放り投げられていました。今回の奴はそれとは別のアプローチ
で実装された物のようです。末端ユーザーの私たちとしましてはちゃんと
動作して恩恵が受けられるのかが大事です。
そんな訳で早速試してみました！コードレビューにはJTAGで言うTDIとTDOの
間にトライステートバッファをおいてnTRSTでOEを制御してターゲットの
SWDIOと接続すべしと書かれております。SWCLKに関してはそのまんまTCKに
つなげばOKです。さらに"トライステートバッファ噛ますのめどいんなら
220~470ohmくらいの抵抗でワイヤードORでもいけるかもね"とさえ書かれて
いました。
もちろん私はお気楽に510ohmのカーボン抵抗でワイヤードOR作戦です。
当たり前ですがTDIが直接ターゲットのSWDIOに来てショートしないように
抵抗を配置してください。
(私のJTAGKey2Compatibleの回路はそれでも素子の即死はしないように配慮してます)
今回の実験対象はSWDのみ接続可能なNuvotonのCortex-M0コアの
Nano130SE3です。このマイコンも以前からちらっとお見せしていますが
NuvotonネタはFM3の修正がコミットされたら一気に攻めるので今は
まだ脇役なのです。もう少しお待ちください。
JTAGkey2はVref必須故にVersaloonの+3.3Vを拝借してターゲットに
供給しております。使用するOpenOCDは現在の最新のコミットベースの
Versaloon-SWD対応版と、同じく最新のコミットベースで
上記のコードレビューからCheckoutしてきたFTDI-SWD対応版＋αの
OpenOCDバイナリをそれぞれビルドし、VersaloonとJTAGKey2で
同一のelfファイルの書き込みとベリファイ速度を比較します。
↓んでこんなん出ました。
*JTAGKey2-SWD
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -c "transport select swd" -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00358-g5b3885f-dirty (2014-02-19-17:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : Init SWD
swd
none separate
Info : add flash_bank nuc1x nano130se3.flash
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : JTAG->SWD
Info : clock speed 1000 kHz
Info : SWD IDCODE 0x0bb11477
Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
auto erase enabled
Info : DeviceID : 0x00113034
Info : Detect NANO130SE3AN!
Info : Nuvoton NUC: Sector Erase ... (0 to 39)
Info : Nuvoton NUC: FLASH Write ...
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:04
*Versaloon-SWD
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/nano130se_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00350-g6c74255-dirty (2014-02-19-11:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank nuc1x nano130se3.flash
adapter speed: 1000 kHz
cortex_m reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Sep 5 2013)
Info : USB_TO_XXX abilities: 0x0000176E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : SW-DP IDCODE: 0x0bb11477
Info : nano130se3.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
auto erase enabled
Info : DeviceID : 0x00113034
Info : Detect NANO130SE3AN!
Info : Nuvoton NUC: Sector Erase ... (0 to 39)
Info : Nuvoton NUC: FLASH Write ...
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006ec msp: 0x20004000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:02
ログも微妙に違いますが書き込みベリファイの速度に注目すると…
JTAGKey2-SWDが
wrote 20480 bytes from file main.elf in 2.452780s (8.154 KiB/s)
verified 20240 bytes in 0.203096s (97.322 KiB/s)
Versaloon-SWDは
wrote 20480 bytes from file main.elf in 1.905981s (10.493 KiB/s)
verified 20240 bytes in 0.203097s (97.321 KiB/s)
となり、JTAGKey2-SWDの方は書き込みでは2割ほどパフォーマンスが
落ちますがまだコードが練られてない段階ながらも十分実用レベルで
使用可能なことが分かりました♥
ついでにトライステートバッファによる制御がなくても抵抗一本でお手軽に
既存のFT2232系のJTAGデバッガがSWDにも対応できるのでなんというか
CMSIS-DAPとは一体何だったのか感すらあります。
というわけでまだまだコードの手直しが必要な段階ですがFTDIデバイスの
SWD対応はシンプルかつ強力なポテンシャルを秘めていると言えるでしょう！
LPC800シリーズを使ってみる4 -ついでにトラ技ライタも使う-
私もご多忙にもれずトラ技ライタなる基板(雑誌は付録)を買ってきましたよ。
今回は基板単体ではすぐに使うことはできずUSB-miniBコネクタと1.27mm
ピッチ*2のヘッダ、そして幅が狭いタクトSWが必要です。
上記のものはマルツで買わなくても秋月で以前購入したものでほぼ賄えるので、
秋月フリークな貴方は全く問題はないでしょう。私も以前JTAGKey2Compatibleを
作成した時にチョイスした面実装タクトSWを利用しております。
ちょっとコツが要りますが、私のぶろぐ見てる方ならこの程度の
作業は楽勝だと思います。
とりあえず最低限のパーツを付けるとこんな感じになります。あーそうそう、
…2/9はいないさんの誕生日でしたね♥うっかり写っちゃいましたね♥
ぱんつは駄目だったけどぶらなら繊細なぴいぶろ君は怒らないみたいなので学校や職場でどんどん見てほし
さて、このトラ技ARMライタはLPC11U35が載っていて、CMSIS-DAPのファームを
仕込むことによって文字通りライタにせしめることができます。正直これに
関してはLPC812-MAXのMBED版CMSIS-DAPと全く同じなので特記すべきことは
ありません。もちろんふつーにOpenOCDから使用可能です!
ターゲットは300milのDIPと化したLPC811さんです！秋月さんの8PinDIP変換を2連結
で16Pinとして使うのがミソです★
このDIP化ネタ、もはや10番煎じくらいの手あかが付きまくったネタなのですが
やらずに居られません。
前回LPC810で遊んだ時のように空中配線のやっけつです。ところで…
…
CN5にJST-EHの8Pinコネクタつける際に気付きましたが…
LPC-Link2からのコピペですかトラ偽らしい(ﾆｰｻﾝ顔で)…まぁいや
新声社亡き後誤植を継ぐ者はCQ出版だけですから(諦観
20140313追:
あのさぁ…
この程度は誤植のうちに入らぬということかー！！！
20140220追：
ねむいさんの探し方が悪いだけだと思いますがトラ技ARMライタの回路図が誤植
満載の紙媒体以外で全く見当たりません(怒)今どきPDFで回路図提供しないとか
どういう根性しているのでしょうか(ﾋﾞｷﾋﾞｷホントふざけてますね(ﾋﾞｷﾋﾞｷ
やはりカンガルー先輩をオーストラリアから召還し〆て頂かないと駄目ですね
マジで(ﾋﾞｷﾋﾞｷ
思えば過去の記事ではカンガルー先輩に対して"やる気がわかないと仕事をしない
気分屋"とかいう駄目な日本企業にありがちな駄目な経営者目線でレッテルを
貼っています。頑張って仕事して(いる仕草を見せ)ない奴は駄目な奴だ！！！
苦労して仕事をしない奴は生意気だ！！！と言わんばかりの陰湿な主張が
にじみ出ているようでそれとはまったく真逆のマトモな精神を持つカンガルー
先輩はCQ出版と袂を分けて正解だったのであろう
…とひしひしと感じます。
ちなみに現在のカンガルー先輩は本国に帰国後、己の野性に目覚めたのかビルドアップ
した筋肉超満載状態となっております。なぜこんなにムキムキになる必要が
あるのかというと巨大動物図鑑さんからの解説から考察すると上半身(上腕)で相手の
攻撃を制し破壊力がある蹴りで攻撃するという独特な戦闘法を取っている事に
あることが考えられます。ここまで述べた時点でもう気づいた方もいるかも
しれませんが…
そう、これは二代目霊界探偵の仙水忍さんが体得した霊光裂蹴拳です！
あらゆる武術を体得した上でないと使用が許されないあの！
こうなるとカンガルー先輩は暗黒天使(ダークエンジェル)である可能性まで
出てきました。魔界の穴があくまでもう時間はありません！急げ幽助！
MBED版CMSIS-DAPもなひたふさんビルドのCMSIS-DAPも特に書き込みの性能差
はなく、同様に使用可能ですが何度も言っておりますがMBED版の方はVCP
ドライバのインストールを行わないとCMSIS-DAPが認識されないのでご注意ください。
ちなみにフラッシュの書き込みは全般的に遅いです。これはOpenOCDから
CMSIS-DAPを使った時の致命的な弱点で、OpenOCD側のプログラムの構造上
PC->ターゲットのデータ送信時にブロック転送コマンドを使わずすべてちまちまと
転送を行っているからです。Versaloonもおなじような感じなのですがUSBバルク
転送なのである程度ひとまとめにしてドカンとやり取りができ速度的には
まだ何とかなっております。しかしCMSIS-DAPはHIDクラスを利用しているので
バルク転送が出来ず、インタラプト転送になります。
USBのフルスピードの場合はフレームあたり1mSec区切りとなるので、
インタラプト転送でも64バイト送れるはずなのですが、上記のとおり
ターゲットへの書き込みの際にブロック転送コマンドを使用していないため
4バイトずつデータを送っているのと全く同じになってしまい、さらに転送の
確認を行っているため実際には2mSecごとに4バイト書き込むということに
なるためどう頑張っても2kByte/Sec以下の書き込み速度になってしまうの
ですorzさらにマイコン-CMSIS-DAP間のSWDのオーバーヘッドもあるので
実際の書き込み速度は1.5kByte/Sec以上出たら御の字ですorz
(注:READの際はブロック転送をおこなっているので早い)
そう言った弱点をトラ技で解説してさらに対策とか講じるのかなと思った
のですが…OpenOCDに関しては案の定貫徹スルーで商用ツールからの使用を
解説しておりました。解決するためにはadi_v5_cmsis_dap.cにメスを入れて
送信時もブロック転送を使えるようにしなければならないのですが他の
デバッグアダプタと整合性が取れなくなってしまうので私もどうしたら
いいか今非常に困ってます…。
以前も述べましたがLPC-Link2ならばUSBハイスピードで繋がり、フレーム
間隔も125uSecごとにスプリットされるので多少速度的にはマシになります。
OpenOCDからCMSIS-DAPをまともに使いたいのなら現状では
LPC-Link2で行うべきです。
20150406追:
CMSIS-DAPが本来の力を取り戻しました。
糞遅かったOpenOCDからの書き込みも快適に行えます☆
それはさておき今回のトラ技の特集ではなひたふさんがJTAGから始まり
主流になったSWD(正確にはSWJ-DP/SW-DP)に至る流れも含め非常に分かりやすく
解説されているのでOpenOCD等のデバッガの動作原理の理解を深めたい方に
とって必読だと思います。基板はあくまでおまけですよおまけ！
おまけのおまけ
…
F**K!!!!!!
OpenOCD小ネタ6 -kinetisドライバの修正その他-
世間様ではトラ技ライタの話でもちきりですが私は毎年恒例の2/9のいないさんの
聖誕生日に向けたブツをずっとこもりっきりで作っていたのでOpenOCDの
ネタが溜りまくっております。
周りに流されず粛々と消化していきますよぅ〜
●エンバグようやく直る(誰も気づかんかったんかい！)
少し前の話ですがkinetisドライバに作りこまれてしまったバグの修正をgerritに投げ、
マージされております。私もgerritにだいぶ慣れてきました♥
Kinetis-Kシリーズは同じ号数(たとえばK20、K60等)でも動作周波数の
上限の違いでフラッシュのセクタ構成が大幅に違いますのでソフトに落とす
際は厳重な注意が必要ですね。私もユーザーマニュアルを首っ引きで現時点で
分かりうる範囲で全てのセクタ構成のパタンを書き倒してやりましたよ！
尤も私が去年Lシリーズへの対応を試みた時は元のコードはもう少しスマートに
セクタ構成を判別する仕組みをとっていました。"guranuarity"と呼ばれる
その値は上で述べたセクタ構成を示し、RDIDレジスタの特定のビットに反映されて
おりました。しかし、その明確な定義についてマニュアルには一切書かれて
おらず、いわゆる裏ワザ的コーディング扱いされていました。
そういうわけでマニュアルを斜め読みした別の人にこういうのよくないよー
(地獄のミサワみたいな顔で)と言わんばかりに中途半端にハードコードされた値が
いいかげんに設定されてしまいエンバグになってしまったわけです。
私もkinetisから離れて居たので気づかず別の外人さんの"K20で
書き込めない!1!1!!!"という質問メールで漸くエンバグされたのに
気づいて冒頭のとおりぱっちをgerritにブン投げたわけですよF**K!
私は悪くねぇ！
なお、上記問題はKL25等のKinetis-Lシリーズには全く影響がなかった
のでご安心を。
あなたがKL25Zに急に書き込め無くなったのは100%これが原因です。
これから先は従来のFMCとはコマンド体系がガラッと変わったKinetis-Eシリーズ
等も控えていますのでさらに複雑化と混乱が予想されます…。それに入手が
容易で人気があるマイコンは修正が他の人とバッティングする状況が
よくありますので他のコントリビューターの人とも綿密に意思疎通を
行うことも非常に重要です。
疎通ができなかった場合nuvotonドライバが2つ出来てしまうことになりますorz
(↑nuvotonの件に関しては次回にでも詳しく…)
●libusbxがlibusb-1.0に
私はlibusb-1.0準拠のlibusbxを従来から使用しておりました。libusb-1.0の
オリジナルにはない機能や修正がたくさんあたっております。
ところが1月下旬にlibusbxが1.0.18でファイナルリリースになり、以後は
libusb-1.0の本流として修正が続けられることになりました。
そうなったいざこざがここにありました。もめごとの陰にはあの男ありです。
私も変な突っ込み喰らわないようにOpenOCDのパッチを投げる際は
細心の注意を払っています。
それはさておき現在私がぶろぐ上で配布しているlibusb-1.0を使用するバイナリ
は全てlibusbxから"x"が取れたlibusb-1.0.18の自前ビルドしたdllをバインド
しております。
もちろんAsmediaのxHCI対策のパッチも適用済ですのでUSB3.0でも問題なしです♥
●libftdiも1.1に
libftdiの1.x系もバージョンアップし、めでたくlibftdi1.1になりました。
こちらに関しては特に記すべきことはないのですが無理やり話題を作りますと…
libftdiは1.0に上がったころから(0系のファイナルは0.20)ライブラリや
プログラムのビルドにCMAKEとかいうのの使用を強制するようになっています。
従来のconfigure->makeのお手軽コンボとは全く違う概念だったのでブツを
作り出せるようになるまで苦労しました。
しかも1.0に切り替わった直後はMSYS向けにはコンフィグがまともに整備
されていなくてあーでもないこーでもないを繰り返してやっとlibftdi1.dllを
ビルドできた涙ぐましい記憶があります…(しみじみ。
現在ではMsys/MinGWのコンフィグ周りも見直されて手直し無しに一発ビルドアウト
出来るようになっております♥もちろんこちらもバインド済です♥
●OpenOCDにバインドされているDLLのまとめ
現在私が配布しているOpenOCDのバイナリは上記を含めた各種dllを
バインドしております。
どれ一つ欠けてもOpenOCDが起動しませんのでご注意ください。また、他の方が
ビルドしたOpenOCDバイナリに差し替えてもそのまま動かすことができますが、
一方でその逆の行為はおそらく一切できませんので理解したうえでご使用
願います！！
libusb0.dll
->libusb-win32-bin-1.2.6.0から抽出
libusb-1.0.dll
->libusb1.0.xxを自前ビルド(+AsmediaのUSB3.0(xHCI)対策済)
libftdi1.dll
->libftdi1.xを自前ビルド
(以前はlibftdi1.dllをlibftdi.dllにリネームしていました)
libhidapi-0.dll
->hidapiを自前ビルド
各ライブラリのライセンスもOpenOCDの"licenses"にありますのでご参考に。
libusb-1.0.dllはAsmedia対策をしてるのでOpenOCDと全く関係ない方からも
需要があるようです。おそらくUSB3.0ホストの問題、この先もわらわら出て
きそうです…
●罪なき人の平和な日曜日を破壊するねむいさん
ごめんなさいごめんなさい！！！…まさか使ってくれてる人がいたとは…
20140210現在はちゃんと内部RCから144MHzに上げるようにスクリプト変えてます
のでご安心を…あと128kByte以下のフラッシュ容量のFM3マイコンではクロックを
叩き上げるのはあんましうま味が無く逆にデメリットしかないので無理に
クロックは上げないでノーマルで書き込んだ方が効率がいいです。
●ついに日本人で私以外の犠牲者が…
oh...my...
これの問題ですが、MSC経由でKL25Zとかに書き込むときにsrecじゃなくてelfを
D&Dで放り込んじゃうとどうやらelfファイルをパースせずにそのままbinファイル扱い
で書き込みやがるからみたいですね…#
まさにクラウドの落とし穴です！
これelfファイルのFSEC番地が0xFFならまだ救済措置はありますが0xEFなら
完全終了
ですね…私からのアドバイスですがKL25Zをmbed版CMSIS-DAPにしてOpenOCDから
MDM-APのmass-eraseをやってみてください。
もしかしてまだ回復できる可能性があります。また、SRSTの操作がmass-eraseに
必須なので必ず繋げてくださいね(Kinetisのハード的な仕様です)。
GPS/GNSSモジュールを試用する11 -GtopFlashToolの謎に迫る-
今回の記事はSTM32の内容にもがっちり絡んでくるのでカテゴリどうしようか
と悩みましたが結局GNSS関連としました。
前回、Gms-g9のファーム更新の際にGtopFlashToolなるものを使用して
UART経由でファームウエアのアップデートを行っております。
その時にGPSロガーとして使用しているSTM32Primer2に仕込んだUSB-CDCから
ではうまくアップデートを行うことが出来なかったことを述べておりました。
今回時間が出来てようやく重い腰を上げて調べることになったのですが
そこには意外な結果が待ち受けていたのでした。
●COMポートが開かない??
Lチカから先になかなか進むことができないねむいさんが唯一実用レベルで作った
STM32Primer2ベースのGPSロガーはSTM32のUSBデバイス機能を利用して
GPS/GNSSモジュールのNMEAセンテンスの記録の他にUSB-CDCとUSB-MSCを
実現しております。
USB-CDC機能は主にGNSSモジュールのAGPS等の機能設定を仮想COMポートを
開いてシリアル通信の形で、USB-MSC機能はSDカードに記録したデータをPC上
から簡単にTXTファイル形式で参照できるように出来ております。
で、GlobalTop GPS Viewer(v1.8)からでは上記のとおり問題なくUSB-CDCの
仮想COMポートを開きバリバリ通信できるのですが…
なぜか同じGtopが提供しているGtopFlashToolからはCOMポートが開けません
みたいなエラーを吐いてアップデート作業ができません。
一方はちゃんとCOM開けてもう一方は開けないとかイミフだったのですが
検索しているとそれっぽい質問が見つかりました。
Windows環境下ではUSB-CDCをなし得るためにusbser.sysを利用するのですが
infファイルは自前で作らないといけません。MSDNの情報を基にinfファイルを
いじってインストールしてみましたが…やっぱりダメorz
>http://support.microsoft.com/kb/837637/ja
↑ja版のサイトは機械翻訳文
> ユニバーサル シリアル バス (USB) モデムの .inf ファイルは Usbser.sys
> ドライバーを使用して両方および Usbser.sys ドライバー .inf ファイルからを
> 直接参照できます。ただし、お勧めしませんこの。
人間の言葉しゃべれこの。
もしかしてGtopFlashToolが何らかのUSBの通信レベルで何かがコケて仮想
COMポートが見えて無いのかと思い埃をかぶっていた秋月ロジアナを用いてUSBの
プロトコルを解析してみたのですがUSBの通信上ではSTALLした箇所が
見つけられませんでした。
↑USBの解析できるまでのロジアナの設定で苦労しましたorz
ちょっと困り果ててしまいましたが鴨川を散歩してる最中にGPS Viewerから
仮想COM開けてたのを思い出してひょっとして何らかの固有の文字列をやり
取りしてCOM開いた判定してるのかと思ってUARTの通信を見たらなんと仮想COM
開けてて信号のやり取りまで出来ているようでした！ちゃんと開けてる
じゃないですかーヤダー！
しかも制御文字もちゃんと送信されてるのでUART周りは全く問題なしと
判断しました。
そもそも糞詰まり対策もやってダブルバッファリングまでしてるので
STM32のUARTレベルに関する点は問題はないです。
となるとやっぱりもっと上の階層の問題ですか…。
●別の仮想COMではどうなのか
依然述べたとおりFT232Rに代表される出来合いのFTDIのUSBシリアル変換IC
なら全く問題はなし、自作のUSB-CDCが怪しいと思い別の物を試してみました。
1．STマイクロ謹製のSTM32F1のUSB-CDCのサンプル(STM32F103/107共)
->できない
※私のSTM32Primer2のUSB-CDCはこれがベースです。
2. LPC2388のLPCUSBのUSB-CDC
->できない
3. STマイクロ謹製のSTM32F1/F2/F4用のUSB-CDCサンプル
->できるじゃない！
4. MBED CMSIS-DAPのVCOM(FRDM-KL25Zを使用)
->できるじゃない！
…ん？それじゃSTM32F1系のUSB機能がやばいのかしら???
5．Versaloon(STM32Primer2と同じSTM32F1系)のVCOM
->できるじゃない! orz
※VersaloonのUSBのソフトウエア側は独自実装
つまりSTM32のファームウエアの問題ですかorz
でもいろいろ試しててGtopFlashToolのエラーの出方の違いに気づきました！
先にGNSSモジュールをなにも繋がずにフラッシュ書き込みを実行しようと
すると駄目な方は繋いでも繋いでなくても"Fail to open the COM Port"
になってて行ける方はとりあえずCOMポートは開き何か読みに行ってるようで
"DL_HANDLE error code"になっていました。
●SEND_BREAK
というわけでSTM32Primer2のRlinkはOpenOCDでデバッグできないのでそれと
ソフト的に等価なSTM32F107VCTのUSB-CDCを用いて上の
"Fail to open the COM Port"になる瞬間をinsightで捉えました…
ら一瞬で原因が分かったorz
"Fail to open the COM Port"になる直前にVirtual_Com_Port_NoData_Setup()
という関数を通過していて引数に0x23が来てエラーを返していたことが判明。
この関数はホストから送られてくるUSB-CDC固有のリクエストを扱う関数の
ようで…
このページによれば0x23はSEND_BREAKに相当するものであるとのこと。
STM32F1USB-CDCのサンプルでは未サポートとしてエラーを返していたため
Gtop ToolはSEND_BREAKを実行できないCOMポートと判断して"COMポート
開けません"とエラーを返していたことが判明。
ってわけでSEND_BREAKのハンドルを追加してSEND_BREAKのリクエストが
送られてきたらとにかく"USB_SUCCESS"を返すようにしました。
おおっ！
GPSTr@ckerのUSB-CDCでもGms-g9のファーム書き換えできたじゃない♥
GPSViewerではSEND_BREAKは一切送信されていたなかったのでエラーに
ならなかった(=COMポートを開くことができた)ことが理解できました。
ところでSEND_BREAKって何か？ともっと調べてみるとUSB-CDC-ACMの規格で
定められたものだようで文字通り"BREAK信号を送信せよ"という意味です。
そしてBREAKって何というとRS-232Cの規格で定められたものでTxDをスペース
(論理L)に固定する行為を指すとのこと。RS-232Cの電圧レベルでいうと
論理が逆転するので、一定時間+15Vに固定することになります。
そしてGTopFlashToolはなぜわざわざSEND_BREAKを送信していたかという
ことですが、それはMTK系のGNSSモジュールのファームウエアアップデートの
方法にあります。
MTK系モジュールはUART経由で特定のコマンドを受け取るとセルフアップ
デートモードに推移しますがその過程で現在通信しているボーレートから
セルフアップデート通信用に自動的にボーレートが上がります。
具体的には115200bpsに推移します。このときGtopFlashToolからCOMポート
経由でBREAK信号が送られているようです。
9600bpsから急にレートの高い115200bpsに上がって間違ったデータとして
受け取られないように一定期間データの送信を止める措置を行っている
わけです。
というところでいろんなマイコンのUSB-CDCの実装を見ているとSEND_BREAKに
対する取り扱いは現在ではごくまれにしか使われないためかまともにBREAK状態
になる実装はめったになく、適当にOKで返してるのが殆どです。逆に言うと
STM32F1系のUSB-CDCのサンプルはちゃんと"unsupported"で返してたから
マシだったのかも！？
そしてGitHubのGPSTr@ckerは既にGtopFlashToolでもちゃんとファームの
書き換えが出来るように修正済です。さらにFatFs0.10aに更新し今更ですが
USBライブラリもF1系最終のV4.0.0準拠にして益々最強に強めております！
●あのお方
今回いろいろ調べて最終的に気付いたのですがUSBのファームウエアがらみで
困っている人のもとに颯爽と現れ強力な解決策を提示して爽やかに去っていく
tsuneo氏がSEND_BREAKにもやはり言及されていました。
私の中ではFatファイルシステムにChaN氏が居ればUSBにはtsuneo氏が
居るといった感じです。
そういう私は2014年の今でもUSBアレルギーが全く克服してないので
これを機会に今年はUSBを自分の物にすることをテーマに進めていきたいと
思います！
東海自然歩道を徃く27(箕面-嵐山渡月橋)
新春一発目の山行は、東海自然歩道の箕面〜嵐山という大阪と京都を
文字通り股に掛けるコースでした。私にとってはすべての始まりの場所ですが
思い起こせば3年前、未熟な装備と技術で挑んだものの嵐山にまったくたどり着けず、
さらに足首の捻挫という洗礼までくらい中間地点の上の口で敗退してしまいました。
…が、
それから3年の今、東海自然歩道1700km走り倒して着た今！りべんぢを果たします！
総距離54km強、獲得標高差3000m越2000m弱のちょっと過酷に見えるこのコース、
山岳マラソンのレースにバリバリ出てるような関西在住の方にとっては日帰りで
さくっと走って帰ってこれるので非常にポピュラーな"定番"でもあります。
私はそういったレースには参加する気はないものの、東海自然歩道の行程の
中で50kmオーバーを3度ほど経験して中距離移動のノウハウも蓄積しており、
ヘタレな3年前とは全く別の強くてにゅーげーむな状態で挑むことができました♥
●2014.01.11 箕面->嵐山渡月橋
虹裏メイドの朝はほんの少し早い。
まだ日照時間が短いので7時半になっても朝焼けですね…。
今回は54kmをガチで走破するので足回りのメンテは完ぺきにしております！
(去年建てられた石像に向かって)君たちしばらくぶりだねぇ、3年ぶりだねぇ(犬作)
ちなみにこれ、東海自然歩道西の拠点と唱っていますが本物の西の拠点はここから
5.5km先にありますのでご注意を！
3年たつと以外と変わりますね…駅の周辺も観光向けに整備されてました。
朝焼けの阪急箕面駅に見送られて真のラストステージ、スタートです！
まずはエントリポイントの東海自然歩道西の拠点に向かいます。温泉を
主とした観光地を縫って走ります。最初の最初のくせに何気に東海自然歩道の
中でエントリポイントまでの一番長いアクセス距離を誇ります。
(次点は奥三河の滝上-千枚田の激坂5km)
緩やかな坂をひた走ります。
この地は朝でもジョギングや散歩に向かう人が多いですね。
箕面大滝に到着です。普段は人が大勢いる場所ですが、まだ朝なので滝の
音だけが支配する厳粛な場所となっています。
箕面大滝を離れさらに登ります。途中車道を通行するので車にはご注意を。
箕面ビジターセンターです。こちらでは東海自然歩道の高雄までのマップを
販売しております。また、東海自然歩道全踏破者に対して踏破証を交付されて
います。ですがまだ閉まってますね。
ビジターセンター横の府道を登ってすぐに東海自然歩道の西の拠点があります。
東京の東の拠点と違い、人が滅多に入らない場所でひっそりとハイカーや
トレランな人を待ち構えています。
近くにトイレがあるので改めて体制を立て直しスタートです！
ぢつはSTM32Primer2を使ったGPSロガーがこのルートを記録するのは今回が初めて。
Gms-G9を装備し最強に強まった状態で彼もねむいさんと同じく今回の54kmに
りべんぢを挑みます！(ピンク色の物体がGPSロガーです)
大阪ステージは箕面駅から開成皇子の墓までひたすらガンガン登りです。
ガッチガチに凍結したぎふちょう橋をこえます！
崩落個所もなく教科書のような模範的なトレイルが続きます。
結構急な登りですがちゃんと整備されているおかげでサクサク登れます♥
開成皇子の墓です。このあたりで登りは落ち着きます。
このあたり自然観察路が入り組んでます。勝尾寺にも行けるそうです。
北摂霊園近くの車道にでました。3年前には無かった鹿柵がとうせんぼしてます。
北摂霊園から先は一気に高度を下げます！
山道から車道に出てすぐに泉原の湧水があります。普段は人が行列作ってるよう
な場所ですが今は私の独占です♥
ちなみにここの湧水は飲料に適さないと明記されてるのでおなかの弱い方は
ご注意を。ねむいさんはもちろん平気でしたが(ベトナムで副業先の社員さん
全員が下痢した泥味のハス茶や静岡で墓地の隣の井戸水がぶ飲みしても
ねむいさん無傷だった。)
さて、ここから忍頂寺まではひたすらアスファルトの車道となります。
特に見る物もないのでさくっと通過します。
途中で山脈自然歩道なる道と同じくしますが東海自然歩道は屈折します。
意外と間違いやすいのでご注意ください。ですが3年前とは違い矢印がたくさん
設置されてますので多分大丈夫でしょう。
この畑のある場所を越えると第一の難関泉原集落です…！
泉原集落に入ると急に道標がなくなり道を見失います！ここは多くの
ハイカーが散っていった危険ポインツの一つなのでご注意を。
とりあえず道標がないこの個所は左折で！
ですが自分の勘を頼りにみちを間違えてしまった貴女はまだ挽回のチャンスが
あります！広い道路に出てしまったらとにかく左折！そして…
ほどなくして泉原西のバス停に着くでしょう。この奥の道を登ると
正規ルートに合流できます！
この道標が見えたらひと安心です。
素盞鳴尊(すさのお)神社です。
交通が激しい府道110号を横切り源氏講の石碑を越えて上音羽の屈折点に
向かいます。
屈折点を越えると道は下り基調になります。
忍頂寺スポーツ公園です。このすぐ先には忍頂寺跡への道があります。
まだまだ舗装路が続きます。3年前は無かったこんな解説看板がありました。
激坂を登ると宝池寺があります。
寿命院わきのトレイルを登ります。このたぬたぬも3年ぶりです。
しばらくぶ(ry
竜王山山頂です。ここには巨大展望台があります。
さてこの先は問題の箇所…
3年前、たしかこの木階段のあたりで足くじいたんですよね…
テーピングで足首周りの故障対策万全の今はまったく敵ではないです。
危なげなく登山口まで下りてきました。
3年前と違い道標が折れて入口に立てかけられており、さらにそれが誤った
方向を指してるので厳重に注意を！
そして大阪ステージ超最難関、車作集落にやってきました…！
ここで道を間違うと一発アウツのくせに道標が全くありません#
まずはこの小屋がある場所はこのようにV字ターンして降りて行きます。
そして魔の四差路EVIL-Xに差し掛かりました。道標が非常に曖昧な
個所をさしていて大阪/東京方面のどちらから来ても間違いを誘発させる
危険な場所です！
現に多くのハイカーがこの四差路で挫折し散って逝きました。
別アングル(東京方面から見た)四差路です。
なお、虹裏メイドに一度見せたネタは二度は通じないのはもはやこれは常識!
ですがさんざん苦しまされたこの四差路も既に見切ったので楽勝でクリアです。
お前を倒すにはその上(のスピード)をいけばいいと一輝兄さんも言ってますし。
ここまで来ればもう安心です。車作大橋に向かいます。
車作大橋です。上に目をやると新車作大橋が見えます。ここでルートは
一般コースと健脚コースに分かれます。もちろん今回は健脚コースを！
ここダンプカーが高速で行きかっててヤバい…
危険な車道を登りあがると途中に武士自然歩道と道を同じくした分岐が
あります。
ちょっと崩れた山道を登ると竜仙の滝が見えます。
道はそこからさらに登って行き武士自然歩道と別れたところで下りに
入ります。
どんどん下っていくと一般コースとの合流点である萩谷バス停につきます。
そこから先は萩谷総合運動場の中を通過します。
萩谷総合運動場からどんどん下に降りると摂津峡にたどり着きました。
ちょっと戻って白滝を。
この鬼子母神慶住院手前の自販機で小休憩としました。
前半のルートはほぼ予定時間通りに危なげなくクリアーです！
上の口バス停へは右折ですが今回はそのまま嵐山を目指します！
第二ラウンド開始！！
…????…こんなとこ走ったっけ…???
…おや…？これって…
F**K YOU！１！！１！！
さて、気を取り直して神峰山寺へとまず向かいます。
牛さんの仏像？が置かれている鳥居をくぐって登りあがります。
三年前はこことは別のトレイルを走っていましたが崩落により、
舗装路を移動するように誘導されています。
神峰山寺山門です。すぐ背後には御覧の通り通行止めの表記があります。
神峰山寺を越えたらお次は本山寺です。ひたすら舗装路の登坂！
本山寺の参道に着きました。道はコンクリ舗装に変わりさらに坂が
きつくなります。標高も上がってきたので凍結してる個所も！！
ひたすら登って登ってこの石碑がある個所まで来たらもうすぐ分岐点です。
本山寺分岐点です。三年前はそのままポンポン山に向かいましたが
今回は本山寺に寄ります。
本山寺本堂です。
実は本堂の右隣からポンポン山山頂に抜けることができます♥
正規ルートと合流しました。
あとはポンポン山山頂に向かってまっしぐらです！
だんだん雪…というか山道が凍結したちょっとヤバい道に！
↑今回スパイク持ってきてませんorz
滑らないように落ち着いて進んでポンポン山山頂に到着です。ポンポン山の
山頂を境に大阪ステージは終わり、ねむいさんの地元の京都ステージが
はぢまります。
大阪環状自然歩道と別れ東に進みます。大阪環状自然歩道は私の次なる
ターゲッツにしておりますよ！
さらに下っていくと舗装路に出て善峯寺への分岐がある杉谷につきます。
進路を金蔵寺に向けてひた走ります。
受験シーズンですからこんなつるつるゾーンで滑ったりコケたり堕ち
落ちたりしないように気を付けましたよぅうふふ♥
ひ
じ
き
金蔵寺の山門に到着です。ガンガン高度を下げてきましたがさらに下がります。
トレイルを下っていくと集落まで降りました。まだまだ下ります。
三年前は高いトタンの塀で覆われていたこのあたりも道路が出来上がってますね〜
できたての道路をくぐると大原野神社の参道があります。といっても普通の
道路っぽいです。
そろそろ日没を意識しなければならないころに大原野神社に到着です。
時間が押してるので速効元のルートに戻る！
草餅屋はもう閉まってましたorz
お次は花の寺へと向かいます。
ここの参道は東海自然歩道屈指のビューポイントです！
夕日が落ちて丁度いい時間帯に撮影できました♥
さて、花の寺本体はどうでもいいので割愛して今度は住宅街を縫って走ります。
ところどころに矢印入りの道標があるのでトレランの方は走りすぎて見逃さ
ないようにご注意を！
田んぼの真ん中の道をまっすく進んで府道10号(丹波街道)と落ち合います。
ここから沓掛交差点を目指します…が交通量かなり激しいのでまたまた
ご注意を！
こっ…♥
こんなおぱんつ丸出しの注意喚起看板出されちゃったら見とれてしまって
逆に事故を起こしかねないんですけぉ!
ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼…
丹波街道を進んでいくと大きい道と落ち合ってさらにまっすぐ行くと沓掛
交差点が見えます。3年前はまだ工事中だったところですね。
交差点を渡り沓掛バス停で進路を右にとりさらに進むと住宅街の中を
走り抜けます。
が〜き〜ど〜も〜！
交通量が多いロータリーを渡って桂坂公園へと進みます。
もうすぐ日没。太陽も山の裏に落ちました…。既に街灯もつき始めてますね。
懸念していたラスト付近の竹林のトレイルですが、なんとか暗くなり切る
まえに抜けることができました！
しっかしでこぼこしててほんっと走りづらいですここ…
そろそろ10時間くらい経ってきたのでペースをぐんぐん上げます。
地蔵院と思ってたけど本当の地蔵院はもっと先でしたorz
真っ暗ですが苔寺への分岐点です。
鈴虫寺入り口です。
月読神社を通り過ぎて松尾大社です。ここから先の進路は3年前と同じく
桂川に沿って進むルートをとりました！
残り2.2km、いざラストラン！
うぉぉぉぉぉおおおお！！
ぉおおおおおぉ…おっ！渡月橋が見えてきました★
阪急嵐山駅への分岐を通り過ぎ17時33分に渡月橋に到着･･･10時間6分を
かけた長い戦いが終わりました…
そして3年前の雪辱を果たしました！！りべんぢ成功です♥
>
少し戻って多目的トイレで着替えを済ませ、"よっし、家(西院)に帰るか〜！"
…と思ったのですがまだ水平方向に進む体力は十分残ってたので嵐電を
使わずそのまま歩いて西院の自宅へと帰りました。
…ということで2014年の初走りを約54kmの激闘を制する形で〆ました！
前回の高尾山口で東海自然歩道はほぼすべてのルートを巡っているのですが、
3年前は成しえなかった箕面〜嵐山間を今回"ハイキング"ではく"トレイルラン"
でつなぐことで本当の意味で東海自然歩道を全走破できたと実感しております。
私にとってこの嵐山渡月橋が一つのゴールであり、同じくまた新たなスタート
地点となりました。まだまだ攻略すべき山はたくさんあります！
箕面-嵐山渡月橋 GPSログ
ああそうそう、ブラウザベンチマークがARM関連の記事抑えて好評になって
きたので東海自然歩道以外の山行レポートもびしばし上げてこうとおもいます！
ｺﾗｺﾗそんな嬉しそうな顔し・な・い・の♥
OpenOCD小ネタ5 -CMSIS-DAP、来る！-
あけましておめでとうございます。
今年もわたくしねむいさんと虹裏メイドたちをどうぞごひいきに。
さて、早速本題に入りましょう。正月明けから少し経ったころ、以前から少しずつ
修正が加えられていたCMSIS-DAP対応がついに公式にマージされました！
CMSIS-DAPとは以前から述べてきましたがARM謹製のオープンソースのデバッガ・
ハードウエアの名称です。大きな特徴としてPCからはUSB-HIDデバイスとして認識
されるので(mbed版はVCPドライバが必要)ドライバいらずで面倒な設定がほとんど
無く手軽に使用できます。
OpenOCDから使用する際にはOS間の差異を吸収するためhidapiというHIDデバイスの
ライブラリを経由してアクセスされます。つまり、OpenOCDからCMSIS-DAPを利用可
能にするためにはhidapiも使用可能にしておく必要があります。
私のおきぱにあるOpenOCDのバイナリはすでにhidapiが使えるように自前でビルド
したlibhidapi-0.dllをバインドしていますのですぐに使用が可能です。
↑ていうわけでCMSIS-DAP対応のOpenOCDを使ってLPC812-MAX上で
書き込み/デバッグしてるところです♥
なお、CMSIS-DAPはSTLink/v2やTI-ICDIのようないわゆるHLAには属さず、
JTAGデバイスやSWD版Versaloonのようにローレベルまで直接ぶっ叩くことが
可能なアダプタのため、Kinetis系のような雄度の高いマイコン相手でも
バリバリ使用可能です。
特にFRDM系の評価ボードに特化したMBED版CMSIS-DAPのバイナリが
用意され始めているので利用しない手はありません！急げ！
…とその前に…
※MBED版CMSIS-DAP使用上の注意※
MBED版CMSIS-DAPは実際はUSB-MSC,USB-VCP,USB-HIDの3つのUSBコンポジット・
デバイスとして構成されています。しかし最初はMSCしか認識してくれず、
CMSIS-DAP(HID)が使えません。
こちらにあるVCPドライバをインストールすることによってCMSIS-DAPも
認識されますのでご注意を。
ところでずっとフン詰まり状態だったCMSIS-DAP対応がOpenOCDに急にマージされた
背景にはVersaloonの今後に関するちょっとした議論がありました。
かいつまんで言うとVersaloon終了です。もうこれ以上ハードもファームも更新はされる
ことはないでしょう。SWDプロトコル対応のパッチはOpenOCD0.6.0以降は全く更新
されていません。しかも今回のCMSIS-DAP対応により完全に適用不可能となります。
しかし、もうご存知の方もいますがねむいさんはCMSIS-DAPとSWD版Versaloonを統合
して使用可能なパッチを作成しています。ねむいさんのぶろぐを知ってる方は私の目が
黒いうちはVersaloonの恩恵が受けられますのでご安心ください。
最近はOpenOCDの自前ビルドが必須のLinux系&マカーな環境の方からも続々と成功の
報告をいただくようになりました。ありがとうございます。ありがとうございます。
20140715追：
Versaloon復ッ活ッッ!
私もCMSIS-DAP対応を決起に未提出のパッチをgerritにどんどん吐いていく予定でした
のでOpenOCDがオワコンどころか一気にボルテージが上がって今年はさらに深い部分
まで切り込んでいくことになりそうです。
20150406追:
CMSIS-DAPが本来の力を取り戻しました。
遅かったOpenOCDからの書き込みも快適に行えます☆
いろいろ試す20…という名の今年の反省会
今年もいろいろありましたが私としてはやってることはほとんど変わらず
山走りとかに行ったりLチカを極めるべく研究したりOpenOCDのエンバグ
とかです。
特にステップアップらしき事をしたのは今まで利用だけしていたOpenOCDの
プロジェクトに対してパッチを提出する形で能動的に参加したことでしょうか。
言葉の壁はもちろんありますが何度もこなしていくうちにある程度分かって
きますので皆様もオワコンとか言わずにどんどん参加してほしいと思います。
●マイコン向けの最強最後のTFT-LCDをゲッツか
i8080バスで接続できるもので現時点でほぼ最強かと思われるモジュールを手に入れ
ました。320x480(HVGA)・ILI9486L・超広野角・3.8inch・抵抗膜式タッチパネル
付と至れり尽くせりでSTM32F4系のFSMCで接続するには最適です。
これ以上のピクセルサイズになるとRGBやMIPI-DSIのほうが速度的に有利になるので
やはり"マイコン"で使用するのなら320x480が上限と感じます。
以前の主力だった3.45inchの奴(コントローラIC:R61581/B0)と比較してみました。
一回り大きいのがわかると思います。
●GCC ARM Embedded in Launchpadがアップデート
読んで字のごとくですがクリスマス前に合わせて更新というなかなかニクいアップ
デートです。今回からGCC4.8.x系になりました。また今回の目玉は新しいコンパイラ
オプションの"-mslow-flash-data"の追加です。これはどういうものかというとリテ
ラルロードを極力movtに変えてバスの競合を避けパフォーマンスのアップを図ると
いわれるものです。ARM本家のこちらとこちらもご参照のこと。
"-mslow-flash-data"のありなしで吐かれたアセンブラリストの比較をしました。
使用したプログラムはSTM32F4のいつものです。赤でハイライトしてる部分がその違い
ですがLDRで行っていたリテラルロードがmovtに置き換わってるのがわかります。
LDR命令の場合、最短3クロックサイクルかかりバスの競合があるとさらに5クロック
サイクル以上掛かることになります。movtに置き換えた場合はサイズは増加しますが
2クロックサイクル固定です。
次に実際のパフォーマンスを比較してみました。libjpegとlibpngのデコード速度の
実時間を計測して比較しました。表示に使ったのLCDはもちろん最初の項で紹介した
これです！
また表示に使用した画像は320x480サイズにしさらにpngとjpegに変換を行った
いないさんのおぱn…いないさんのｲﾗｽﾂをサンプルとして計測結果をuSec単位で
こんな感じで表示しｔ
…ｹﾞﾌﾝｹﾞﾌﾌﾝ
さて実際の結果ですが、せっかくなのでfreddiechopinさんとこのBleeding-Edgeツール
チェインや役立たずに堕ちたSourceryCodebenchも(←今回の比較のためにわざわざ
登録してインストールしためっちゃめんどくさいF**K!)交えコンパイラオプションも
いろいろ変えて各コンパイラ性能比較も兼ねて行いました。
↓とりあえず各条件の計測時間の羅列です
(※-mfloat-abi=softの時はlibjpegのDCT_FLOATは無効にしていますのでバイナリ
サイズが全般的に下がっております。)
libjpeg/libpng rendering speed compare
uses inai-san's oketsu-pantsu gazou.
PNG : INA~1.png 96128kByte
JPEG : INA~1.jpg 40491kByte
LAUNCHPAD
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]
@@L1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496760 0 496760 79478 main.hex
***libjpeg
182341uSec
***libpng
168305uSec
@@L2222
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489144 0 489144 776b8 main.hex
***libjpeg
181903uSec
***libpng
168485uSec
@@L2222 (nano-lib)
(Using nanolib -u _printf_float) -Ofast-mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 470620 0 470620 72e5c main.hex
***libjpeg
194318uSec
***libpng
234706uSec
@@L3333
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496752 0 496752 79470 main.hex
***libjpeg
182345uSec
***libpng
168311uSec
@@L4444
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 489136 0 489136 776b0 main.hex
***libjpeg
181925uSec
***libpng
168588uSec
@@L5555
(Using newlib) -Ofast -mfloat-abi=soft -mslow-flash-data
=== Total Binary Size ===
text data bss dec hex filename
0 496152 0 496152 79218 main.hex
***libjpeg
186999uSec
***libpng
168740uSec
@@L6666
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 488592 0 488592 77490 main.hex
***libjpeg
187095uSec
***libpng
168490uSec
BLEEDING-EDGE
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors / bleeding-edge-toolchain-130810) 4.7.4 20130613 (prerelease)
@@B1111
(Using newlib) -Ofast -mfloat-abi=hard -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555460 0 555460 879c4 main.hex
***libjpeg
183801uSec
***libpng
170161uSec
@@B2222
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 555436 0 555436 879ac main.hex
***libjpeg
183797uSec
***libpng
170156uSec
@@B3333
(Using newlib) -Ofast -mfloat-abi=soft
=== Total Binary Size ===
text data bss dec hex filename
0 553492 0 553492 87214 main.hex
***libjpeg
187582uSec
***libpng
170098uSec
SOURCERY CODEBENCH
arm-none-eabi-gcc (Sourcery CodeBench Lite 2013.11-24) 4.8.1
@@S1111
(Using newlib) -Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16
=== Total Binary Size ===
text data bss dec hex filename
0 504568 0 504568 7b2f8 main.hex
***libjpeg
184072uSec
***libpng
203915uSec
@@L2222
(Using newlib) -Ofast -msoft-float
=== Total Binary Size ===
text data bss dec hex filename
0 504040 0 504040 879c4 main.hex
***libjpeg
186811uSec
***libpng
203920uSec
かなり条件が入り乱れているので要点をかいつまんで紹介しますと、
まず"-mslow-flash-data"有だと、無しのものより逆にlibjpegのデコード速度が若干
下がるといった結果になりました。libpngはちゃんと速くなったのですが…全体的に
スピードアップすると思っていたのでちょっと微妙な結果です。
おきぱにて公開してるいつものはつぶしが聞くように"-mslow-flash-data"オプションは
デフォルトではコメントアウトにしてます。
↑2014年が明けて一週間たったころにようやくlibpngとlibjpegの評価をあべこべに
書いてたの気づきましたすみませんorzちゃんと修正しました。
"-mslow-flash-data"オプションを付与するとlibjpegでは逆効果になってしまいます。
またLaunchpad特有のnewlibをシュリンクしたnano-libを使用した場合、全体的な
パフォーマンスが低下することが分かりました。libjpegもlibpngもmallocを使用
するので、そこにパフォーマンスの違いが現れていると思われます。
作成するアプリケーションの目的に応じて使い分けるのがよいでしょう。
次に各コンパイラ比較ですが同条件(-Ofast -mfloat-abi=softfp -mfpu=fpv4-sp-d16)
の場合、LaunchpadのGCCがサイズの小ささ/速度ともにトップになりました。
さらにLaunchpadのは"-mfloat-abi=hard"も選択できる(Sourceryのはsoftしかない)
ので、もはやわざわざ登録してまでSourceryCodebenchを利用する意味が全くなく
なりました。
皆様も早急にLaunchpadに乗り換えられることをお勧めいたします。
すぐにだっ！
●よくいただく質問に対する回答とか
というわけで今年のぶろぐもこれでお開きですが、毎年恒例の尺が余ったので
メールや虹裏でいただいた変な質問にぶろぐ上で返信をさせていただきます。
Q:GDBで接続した瞬間に"Remote 'g' packet reply is too long"とい(ry
A:長き戦いよ、さらば！
ていうかちゃんとぐぐりなさいよー！
Q:USB3.0でLibUSBが(ry
A:こちらをご覧ください。
USB3.0のホストのほうもファームやドライバの最新化は必須ですよぅ！
Q:いままで問題なく動いてたのに急にOpenOC(ry
A:変なことやらかした人に限って口をそろえたように"問題なく動いていたのに急に
何ちゃら"は何らかのシンクロニシティなのでしょうか…？？？
Q:(ブラジルポルトガル語と思われるFatFsに関する質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(簡体字中国語と思われるSTM32(←中国で人気のマイコンだそうです)に関する
何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:(日本語と思われる文字列だが日本語としてまったく解読不能の何らかの質問)
A:Sorry,I cannot understand your language,at least in English.
Q:ねむいさんとか言うサイトみたけど役立つ情報が全くない上に何が
言いたいのかよくわからないので
A:私もそう思う。
特に今日の前半のとことか。意識他界方がこんなトコ来ちゃ駄目ですよ…
Q:OpenOCDのWindowsバイナリは配布されておらず
A:ここが見えないのですかここが！！
Q:(企業のメールアカウントで)***なのですが****を希望しますor早く修正してくだ
さい。以上。(←回答納期をつけてくる場合も…#)
A:今年に入ってなぜか急にたくさんいただくようになりましたが……企業内で開発を
行われる場合は有償のサポートが付いたツールを使用されるほうがいいと思います。
もしくはgpl.txtを1000000000000回音読して"利用者が全責任を負う"っていうこと
を体で理解してください。ちなみに私の副業先ではARMはIARで開発しております。
Q:ルネサA:帰れや！
Q:ギンギンに勃○してるのですが
A:ﾔﾀﾞﾓｳ///
Q:ギンギンに○起してるのですが
A:ﾔﾀﾞﾓｳ///
これデザインしたの私と同性の方でしょうか…？
本来のとは逆向きに付いてますし///
Q:ねむいさんで検索すると候補に入院と出てきます。これは何ですか？
A:これは重篤なサジェスト汚染ですね〜！
当職が入院したとかいう体だけ(非性的な意味で)が取り柄のねむいさんのあいでん
てぃてぃを否定する検索が多数行われているのは絶対に許さ
力を。
Q:ねむいさんのぶろぐに右端にあるブラウザベンチマークというリンクをクリック
したら突然大量の画像が貼られるページにいどうして動作が重たくなり、ブラウザ
がクラッシュしてしまいました！！！１！！ファ*クユー!!!
A:びぃぶろ君が悪いんですけぉ！１！！ねむいさんは悪くないんですけぉ！１！！１
Q:ねむいさんはさんざモロはあかんといっときながらブログでモロを進めていたのは
どういうことなの？虹裏メイドだからって何か許された特別な人間だと思ってるの？
A:わかりましたから落ち着いてください。かつて存在した虹裏novという場所があった
のですが話はそこにさかのぼります。そこでは魅力的ないやらしい口元をした紳士
画像を赤と黄色を交互に放射状にした…いわばマケドニア国旗のような非常に目立
ちやすい注目をひく画像に加工したものをスレッドの頭画像とし、おもに紳士に関
する話題やコラージュを中心としたスレッドの進行体系をとっておりました。
しかし、実写のコラージュを用いたスレッド信仰であったためふたば☆ちゃんねる
のｸﾝﾆﾘﾝｻﾝにとって二次元裏のポリシーに反する目の上のタンコブだったのです。
紳士画像のスレッドの住人はそれには構いなしにナイフみたいに尖っては触る者皆
すべてに不許を貫いておりｸﾝﾆﾘﾝｻﾝに対する反逆とも呼べる行為を続けていました。
そしてある日ついに、ついに虹裏novはｸﾝﾆの怒りによってなんと板ごと御取り潰し
に遭うという悲劇的な結末を迎えました。しかし紳士画像のスレッド住人はそれで
息絶えたわけではありません。住人達はもといたimg,may,jun,decにとしあきとして、
｢｣として溶け込みつつもマジスタンスとして2014年になろうとする今現在も続く許
されざるビューティフル・ウォーを繰り広げているのでございます。
現在では、前途の紳士画像を二次元裏@ふたばに貼付するという行為はｸﾝﾆに対する
反逆の証として児童ポルノ画像の貼り付けよりも重篤な一発アウト(スレッド削除・
アクセス禁止措置)が取られるようになっております。safetyに紳士を語るためには
紳士を構成する目元といやらしい口元を隠す黒塗りを施した"加工済紳士画像"の
貼付けにて進行を行わざるを得ないのですがそういった処理前の未加工な紳士画像
がモロ画像もしくは縮めてモロと呼ばれ、爆発性の危険物として扱われています。
しかしながらそういったモロが貼られない状況が紳士スレッド内で続くと突然日清
チキンラーメンのパッケージをはじめ鶏肉を主体とした調理済の料理画像が貼られ、
あたかも"(モロを貼れない)お前はチキンだ！チキン野郎だ！"と言わんばかりの
挑発を受けることになります。挙句の果てには手描きを用いチキンとかはたまた妙に
ウイットに富んだ発音でティキンとかいうモロにストレートな心温まる発言を行ッ
てくれやがります。ですがあなたたちは紳士です！そのような挑発には決して乗っ
てはいけません！奴らはあなたの正義感を巧みに利用してモロを貼らせるように仕
向けているだけです！！１！もし挑発に負けて大人の男怒らせるなよオメーラと言
わんばかりに未加工の紳士画像を張り付けてしまったらゲーム・セットです。たち
どころに大勢のアンパイアが現れつぎつぎにアウトの判定を下され、ポケットモン
スターのアチャモにも｢あちゃ〜…もろ」と吐き捨てられ、仲間であったはずのスレ
ッド住人にdelを叩き込まれてとどめにｸﾝﾆﾘﾝｻﾝになーとアク禁を喰らうでしょう！
Q:東海自然歩道の静岡バイパイコースについて質問です。
玉露の里にかかる橋のマークはなかなかイカス植物ですね？
A:し…しらない…
気のせいでしょうﾊﾊ
Q:東海自然歩道の静岡バイパイコースについて質問です。
休暇村富士の玄関で栽培されてる葉っぱはなかなかイカス植物ですね？
A:し…しらない…
き、気のせいでしょうﾊﾊ
…
ー…そろそろ大掃除しますか…
それではみなさま、よいお年を〜
東海自然歩道を徃く26(西野々-高尾山口)
●2013.12.20 西野々->高尾山口
いつも通り、早い、虹裏メイドの朝…だが今回は特別です。
今回が私の1700kmを越える東海自然歩道のラストジャーニーとなります…。
三ヶ木行きのバスの合間からほんの少しの朝日と津久井湖が見えます。
三ヶ木操車場にて。
向かう高尾山方面は雲海に包まれています。小雨も降っていました。
西野々バス停に到着です。西野々公園広場で支度をしたあとじっくりとストレッチを
します。今回は丹沢ほど急峻な道ではないですが30kmオーバーのロングコースかつ
5つのピークを越えるので侮れません。東海自然歩道の道標があるところまで少し
戻ってスタート！
まずは石砂山へ…道志道を少しさかのぼり道志川を渡ります。
伏馬田集落から石砂山登山口を登りあがります。
石砂山は丹沢山地に属していて山蛭天国です。しかし冬季は安全です。
多くの人が間違えやすいと指摘したこの庚申塔は道標ができていました。
伏馬田分岐です。青根からの分岐はここにつながります。
うっそうとした森の中を進むと急に視界が開けて前回攻略した丹沢の雲海が見えました。
雨で滑りやすくなっているので一歩一歩確実に踏みしめてのぼります。
高度を上げるに従って残雪が見えてきました。
石砂山に到着です。ここがひとつ目のピークです。
滑りやすい道を慎重に下り石砂山登山口に降りてきました。ここにも山蛭に対する
警告(無知なハイカーが蛭を生きたまま集落に捨て被害を拡大することに対する)が
あります。
しばらく篠原の集落の舗装路を進み、次は石老山への登山道となります。
石老山の登山道はかなり急ですが前回の丹沢を経験した今ではおそるるに足らず
です。雨で滑るのは変わらないので慎重に登りあがりました。
金毘羅神社を越えると道が少し穏やかになります。また残雪が見えてきました。
石老山に到着です。本来なら富士山のビュースポットだそうですが…
御覧の通り10m先も見えませんでしたorzおそらく雲海のど真ん中です。
先も長いので早々に山頂を降ります。顕鏡寺への下山路でなんと紅葉にめぐり合い
ました！今年は一気に冷え込んだから青いまま枯れ落ちたもみじとかもあったので
逆にこういう季節外れに生き残ったのもあるのでしょうね〜。
融合平見晴らし台です…がいまだ雲の中。
石老山で700m以上になった標高をどんどん下げていきます。
さらに下りていくと顕鏡寺の奇岩群が現れます。
下界の景色や紅葉に囲まれながらさらに下ります。
顕鏡寺に到着です。ここはまだ山の中腹でここからまだまだ降ります。
東海自然歩道のシンボルマークはモミジでしたね…
…あと10数キロで長い旅も終わる…
石老山は名の示す通り岩づくしの山でした。
顕鏡寺参道まで降りてまた舗装路を走ります。ほどなくトレイルに入りますが見上
げると何と青空が！このまま晴れろと願う…しかし
鼠坂に至るトレイルです。走れる個所はどんどん走ります。
前半の徐行運転でほとんど体力は落ちてません！
鼠坂(ねんさか)です。この近くには相模湖プレジャーフォレストという行楽施設
があります。私はこのそばを北に進みます。目指すは嵐山！
途中で相模湖が一望できる個所もあります。だいぶ晴れてきましたが…
滑りやすい橋を渡る場面が続出します。
そこを抜けると地元の京都の嵐山をほうふつとさせる竹林に入り、その後は
尾根道を登りあがります。太陽が顔を出し日がさしてきました。
嵐山に到着です。相模湖が一望できます。だいぶ晴れてきましたが富士山方面は
いまだ雲の中です。そして残るピークあと二つ…！
そこから一気に下山路を下りJR中央線相模湖駅への分岐に当たります。
少し車道を走り弁天橋に向かいます。
弁天橋です。相模川を渡ります。その後千木良までは登りになります。
相模川と弁天橋と紅葉を千木良サイドから…。
千木良の住宅街を抜けて甲州街道に面した千木良バス停で小休止です。
残りの小仏城山と高尾山を登る力をチャージしました。
小仏城山登山口につきました…がなんだか急激に空が真っ黒になってきやがりました。
正午は晴れてて天気予報がいい意味で外れてくれたと思っていたのに！
対面から山ガール(ねむいさんもですが)急いで駆け下りてきました。そう、何と
ゲリラ豪雨ですorz
ちゃんと雨と風対策はしてるのでお構いなしに進みましたが今度は雨が雹になり
やがりましたorzorz…びしびし当たりまくって痛いorz
本来は小仏城山の登山道は緩やかでポンポン駆け上がれるはずなのですが前半と
同じく落ち着いて踏みしめて登りあがりました。いつの頃か雹は雪へと変わり新雪
に私の足跡が刻まれていきます…。
―――――――――――――
小仏城山に到着です。神奈川ステージの終わりと同時に最終ステージである東京都
ステージのはぢまりとなります！残るピーク、高尾山ただ一つ！
平日で大雪でしたので売店はやってませんでした。-1℃の気温の中猫ちゃんを発見。
私は冬の山道は慣れっこですが彼らも平気なのでしょう…
高尾山に向かうにつれて雪は激しさを増してきました(トレラン用アイゼン装着済)。
ラストを飾るのにふさわしい劇的な展開ですね…懸念していた雷はなかったので
非常にラッキーです…。
一丁平に到着です。すでにここは東京都の管轄ですが首都圏自然歩道というものと
道を同じくしているようです。そして高尾山までほんの少し…！
一丁平を抜けたら雪はやんでいて今度は融雪に悩まされました。超ぬかる道でやはり
最後まで気が抜けません！
もみじ台に到達。…ここは奥高尾と呼ばれる区域だそうです。
そして少し進んで間の前にあるラストの階段を私は登った…！
今回のラストピーク、高尾山山頂に到着です！
平日に加えこんな天気なのでなんと誰一人いませんよ！山頂を独り占めです♥
1700kmを越えてきた自作GPSロガーを誰もいない山頂の三角点に…これは本当に
貴重な体験ですね…。
十分山頂を堪能した後下山にかかりました。ここから先の東海自然歩道はすべて
舗装路(一号路)になります。途中で登る人たちとすれ違いましたがなんとこの日、
日没直前にダイヤモンド富士が見られたそうでたぶんそれ狙いの人たちかと思います。
一号路を下っていくと薬王院の境内に入ります。これは不動堂。
さらに下って薬王院本社を。高尾山も信仰の山です。
薬王院本堂です。ここで家族のお守りと自分用の足守りを買いました。
本堂を去り仁王門をくぐるとあとはひたすら下山です。
男坂・女坂の合流地です。
途中の見晴らし台より。下界はいまだ雲の中…
ケーブル高尾山駅を横目に車道をどんどん下っていきます。
最後の紅葉も見られました。
路はやがて緩やかに、そして石畳みになりました。高度ももう下界です。
そして…。
1700km超の長い旅路を越えてついに東海自然歩道の東の拠点に到達です。
ですがあんまし達成感みたいなものは感じません。そう、他の方と同じく此処からが
また新たな他の山々へのスタート地点となるのですから。
ようやく本当のスタートを切ったのです。
GPSロガー置いてみました。
もうええちゅうねん！
十分東の拠点を堪能して別れを告げました。
長かった戦いよ、さらば！
その後は車道を走り駅前を迂回して鳥居をくぐります。
そして京王高尾山口駅にて本日の山行のゴールです！
長かった…
JR高尾駅も写真に収めて帰りました。
…
前回と同じく新横浜駅で戦利品の真空パックシュウマイを買って京都に凱旋
帰宅しました！
…ということでラストを飾るにふさわしい山行となりました。
天候が良ければもう一時間早く到達できたかと思いますが今回は妥当で
満足いく結果だと思います。
そして今回を持って本線・奈良(山野辺)・岐阜(恵那&伊目良)そして静岡バイパス
コースを含むほぼすべての東海自然歩道のルートの走破も達成しました！
冬季縛りで進みましたがやはり3年は掛かりましたね…。
…総費用もお土産代含めて78万円くらい…
そしてさらに、初めて"山走ろう"と決めた時から東海自然歩道をめぐり全走破
達成までの約3年間で健康的に10kg近くの減量も成功し、
そっち方面でも非常に満足しています♥
もちろんこれからもトレランは(競技としては参加はしませんが)マイペースで
続けていきます。
↑60kgを割って10代後半と同じ57kg台に戻すまでの攻防がほんと辛かったです…
今回のログは無線中継所の影響からか嵐山頂上で乱れてますのでご注意ください。
ヤマレコからダウンロードできるGPXファイルは暴れたデータはトリミング済です。
西野々-高尾山口 GPSログ
謝辞
東海自然歩道を進むうえで最も重要なのはルートに関する情報です。
行程の事前リサーチは一度に30km以上の移動を常とするトレランでは絶対に
必須です！しかし公式に載っている情報だけでははっきり言って到達不可能です。
実地に赴いた皆様の記録や知恵が東海自然歩道の攻略上非常に助けになりました。
この場を借りて以下の方々に感謝の意を述べさせていただきます。
ありがとうございました！！
・参考にさせてもらった山行レポート
Kudou様(箕面〜関ヶ原間)
東海自然歩道を行く
基愛様(箕面-高尾山口までの本ルート・岐阜伊自良ルート)
東海自然歩道を歩こう！
Bracht様(全ルート)
東海自然歩道ぶらり一人歩き
カミガタ様(全ルート・山梨ステージ以降のGPSデータ)
東海自然歩道ルートガイド
・タイムキーピング
今野銀河様(奈良山野辺/神海〜高尾山口(本線ルート))
YAMA☆MIX
↑氏の歩行速度が私の走る速度とほぼ同じペースだったので分刻みの精密な
スケジュールを立てることができ、非常に効率よく山行を行うことができました。
最初見たとき只者ではないと思ったのですが実際超歴戦の方だったのですね。
・参考にさせてもらったGPSデータ
hiking3030様(犬山〜三河大野)
私のウォーキング・ハイキング記録
adoppo様(三河大野〜大平)
ヤマレコ内レポート
STM32F4シリーズを使ってみる9 - STM32F429I-Discovery準備編 -
STM32F429I-Discovery(製品名:STM32F429I-DISCO)、ようやく一般市場でも入手
しやすくなってきましたね。twitterのタイムライン見てると既に手に入れられた方、
使用されている方々の写真もびしばし上がってます。
私の方はというと…少数の方は更新に気づいていたとは思いますが、東海自然歩道へと
向かう前日の11/29にすでに既存のSTM32F4向けFatFs実装例に対応ボードの
一つとして基本部分を組み入れたソースコードを公開しております。
尤も429I-DiscoveryからはぢめてF4シリーズに触る奇特な人もいるかもしれないので
これがどういう物で何ができるか今一度軽く解説をさせていただきます。
※注意※
こことここを見て私のプロジェクトをビルド・デバッグ出来る環境拵えてることが
前提です！"意味が分からない"という方はご縁がなかったということで…
私のFatFs実装例(通称いつもの)は、ChaNさんのFatFsを中心に各マイコンの極めて
基本的な機能を網羅しています。STM32F4においては下に述べる機能を抑えています。
STM32F429I-Discoveryでも勿論使用しております。
1.GPIO操作
->LED点滅・SW入力
2.UART
->割り込みを使用したバッファリングされた送受信・stdioのリダイレクト
3.液晶モジュール
->MCUバスインターフェース(i8080,SPI,I2C)で駆動できる表示素子の操作
STM32F429I-DiscoveryはRGBインターフェースを使わずともSPI単体でも画像
データを送ることができます(遅いですが)。
4.FatFsのローレベル部の実装
->SPIやSDIO等とMMC/SDカードとのインターフェース。STM32F429I-Discovery
ではSPI4を使用しSPI互換モードでSD/MMCを動作させております。
5.外部RAMの制御
->STM32F407系はFSMCでSRAMを、STM32F429I-DiscoveryではFMCで
SDRAMを制御します。
んでもっていつものをSTM32F429I-Discoveryで動かしているところ
DMAの転送に使用される内蔵RAMが圧倒的に増加したので多少転送効率もよくなり、
その分ヒープ領域もたくさん取れるようになったのもうれしいです♥
画像はRAM馬鹿食いのgiflibを動かしてるところ
ファイラーの操作はタッチパネルより。STM32F429I-Discvoeryではコントローラに
内蔵のフィルタがあるSTMPE811が使用されているのでキャリブレーションも簡略化
しました。同基板ではVBATがVCC直結で外部にピンが出ておらずバックアップRAMが
機能しないので苦肉の策です…
タッチパネルからのファイラーの操作は上下でファイルポインタ移動、右で選択、
左でキャンセルと手抜ｋ直感的です！
前回述べていた基礎のとっかかりに関しては対応完了です。このプロジェクトではまだ
STM32F429I-Discoveryの機能のすべてを使いこなしてはいません。以下の項目は目下
実装中のSTM32F429にしか使えない機能です。
1.LCDCを使用したRGBインターフェースによる高速な表示
->前回はやっけつで急ごしらえしましたが過去の資産をなんとか生かせるように
作り変えてます…こちらはもうすぐ完了…。
2.FatFsのファイル読み書き先をSDカードからUSBメモリに
->これ結構作業量ががが
こちらに関しては先人の作例も数多くあるので参考にさせてもらってます。
せっかくUSB-OTGがあるのにSDカードばっか使っててもったいないですから自身
の学習がてらに実装がんばります！
そういうわけでSTM32F429I-Discoveryのフル機能を駆使した作例のほうは
もう少しお待ちください。過去のSTM32F407系の作例と完全に切り離して
STM32F429I-Discovery専用のプロジェクトとして公開する予定です。
おまけ
1年以上前に購入した699元全部載せSTM32F407基板もSTM32F427IIT6に
換装してパワーアップさせました。
実はずーーーーっとF427系のチップが出るの待っていたのです！
こっちはこっちでF407系の資産生かしてなおかつ強化する方向で遊んでいきます。
PARTYHARD!(見えづらいですが左上)
もいっこおまけ
STM32F42xxx&STM32F43xxx系をJTAGから見た場合バウンダリスキャンのTAPIDが
40x系と違うものになってるのでOpenOCDで書き込もうとするとコけます。
この修正はgerritに投げてますのでOpenCOD0.9.0あたりで反映されるはずです。
東海自然歩道を徃く24(朝霧高原-富士吉田/富士吉田-平野)
東海自然歩道のルートも残すところあと5つ(と一つ)ですね…高尾山に近づくにつれ
時間的・金銭的・体力的・技術的な難易度が跳ね上がっていくのを感じます。
今期は2013年内に決着を付けるつもりでラストの関東コースを挑みます！
●2013.11.01 朝霧高原->富士吉田
夜行バスの唯一の休憩地点、土山SAにて…
今回は50km近くの長丁場、しっかり食べておかないと…
…やっと富士宮についた…こっからさらに道の駅朝霧高原に…
この日は平日で早朝のバスはないのでタクシーで移動。
道の駅朝霧高原に到着。やっと車から解放された…。
そして朝食も済ませ足回りのテーピングを完全に施し…
い ざ 出 発 ！
国道139号線を跨ぎ、前回のエントリポイントに向かいます。
今回は70%以上が平地のトレイルで文字通りのトレイルランが出来そうです！
山道に係る川をジャンプで飛び越してふと上を見ると
根原のつり橋が見えました。
A沢貯水池という事務的な名称の池に沿って走ります。
その後すぐ山道です。
端足峠への分岐をかすめて県境に向けたトレイルを走ります！！
走る！走る！
東海自然トイレを過ぎてすぐの場所に県境である割石峠につきました。
約一年かかって静岡ステージを脱出です！
割石峠からは国道139号線への離脱が可能です。
ここから先は迷いやすい問題の山梨県。まずは本栖湖に向けて走ります！
この見るからに毒々しい草、マムシグサというどくどくでした…
迷いやすいといわれる山梨ステージですがこの時点ではまだ牙を剥いてません。
それどころか写真入りで矢印が示されてる箇所も…
本栖の部落へ向かう分岐から"本栖湖"へ進路をとり、県道709号線に落ち合います。
本栖湖に到着です。
駐車場と小さな売店、そして道路を挟んでトイレもありました。
ここでほんの少しだけ休憩。
しばらくの間本栖湖湖畔を走った後県道を横切り、ついに青木ヶ原原生林に突入
します！今はもう消滅した上九一色村の道案内は当時のままです。
国道139号線をアンダークロスして樹海をひた走ります！
ノンストップで走って走って精進湖民宿村まで出てきました。googlemapが出来た
当初に"森の中に謎の集落がある！"とちょっと話題になった場所ですね。
ちょっとルートから外れ精進湖入口も見てました。
さて本ルートに戻りさらに樹海を突き進みます。標高は高い場所ですが道は平たんで
非常に走りやすい場所です。この日は平日だったので他のハイカーも全くおらず一気に
かっ飛ばします。
ぅぉぉ！！
標高が高いのですでに紅葉も色づいていました。
走って走ってだいぶたったころに風穴に到着です。ここからもう少し進むと鳴沢氷穴
があります。
このあたり溶岩がでこぼこしてて晴れててもこけやすいです。
そしてこれまた有名な"めいわく自殺防止看板"を通り過ぎると…
鳴沢氷穴に到着です。ここで紅葉台に向かうための準備を兼ねて小休憩としました。
あの…貸した金返してもらうための相談とかは…
鳴沢氷穴を離れ紅葉台へ向かいます。この案内がある場所で139号線に出られます。
また、富士急バスのバス停も存在します。
紅葉台に到着です。鳴沢氷穴との標高差は100m程なのでここまでは大した登りでは
ありません。尤も1000m以上にある場所なので既に紅葉真っ盛りでした。
しかし…肝心の富士山はちょうどその部分だけ曇ってて全く見えませんでしたF**K!
紅葉台有料展望所を超えてお次は三湖台に向かいます。
三湖台です。先ほど通過した樹海や西湖を見渡すことができます。
三湖台を離れ、足和田山(五湖台)に向かいます。このあたりから登山道は林道と常に
併走するようになります。
木々の合間から西湖が見えます。
やがて林道と離れさらに急になった登りを超えると…
五胡台こと足和田山に到着します。残念ながら樹木が多く湖はあんまし見えません。
富士山はもちろん雲に完全にkk…F**K!
長居は無用なのでとっとこ下山しました。しかもず〜〜〜っと階段攻めorz
足和田山登山口(大田和入口)に下りてきました。たしか一本木登山口という名称の
はずでしたがゲートにあった名称を期したプレートが見当たりませんでした。
こっから先はひたすら車道を進みます…が迷いやすい山梨ステージの本性がついに
現れだしました…！ここは河口湖総合運動場へ行くのが正解です！大田和へ行くと
大きく迂回してしまいます。
このあたりで道を失って行ったり来たりorz
県道704まで出てしまい、大田和バス停方面にばくちで向かった途中でようやく道を
見つけましたよクソァ！！
国道139号を横切ってダートの道を突き進みます。
ここもトラップです！！無視して直進！！
で、直進すると四つ角にでるのですが直進ではなくなぜか道標が富士山頂方面へ
向かう太い道を差しているのですがここで大きい道を道標の示すまま直進してしまうと
ルートミス！！私のたどった軌跡を参考に迷わないようにしましょう！
そしてやっと見つけた道標…クソァ！！
その後も迷いまくって河口湖総合運動場の交差点にたどり着きました。
ここでクロスしている船津口登山道を国道139号線方面に下り漸くルートに戻りました
クソァ！！
ホテルレジーナ河口湖入口です。紅葉がきれいです♥
ここから剣丸尾溶岩流のトレイルを通り国道139号に近づきます。
富士スバルラインを横切り巨大な富士ビジターセンターに到着です。
日がだいぶ傾いてきたので休憩はせず水の補給だけしてすぐに出発です。
ここから先は国道139号線を延々と通過します。
富士急ハイランドを横目に139号線をひた走ります。
たぶんいつかきっとここに家族で遊びに来れると思います…
139号線から離れて北口本宮富士浅間神社に到着です。建物の修繕の真っ最中でした。
次回のルートの無事を祈ります。ここが次回のエントリポイントとなります。
東海自然歩道のルートと離れて富士急行線の富士山駅(旧富士吉田駅)へ向かいます。
途中の下り坂で最後の最後でようやく富士山を拝めました…じわわ。
空に暗がりが広がり始めたころに富士山駅に到着です。
東京から富士山に来るばあいこちらの山梨県側から来られる方が大半のようですね。
力のかけ方が尋常じゃないです…富士宮も頑張れ！
この写真を撮った時はまだ少し明るかったのですが、QSTAのトイレで
着替えを済ませて外に出るとすっかり暗くなってました。
お土産を買った後JR御殿場駅行きのバスに乗り込み帰路につきました。
●2013.11.15 富士吉田->平野
今回は京都から富士吉田まで約10時間のバス攻め…富士急ハイランドが見えたころ
には私のキュートなお尻は崩壊していた(←と言っても漏らしたわけではない)
富士山駅内でモスバーガーが営業していたので朝飯と足回りの準備を固めました。
ストレッチも十分に行いスタート！
北口本宮富士浅間神社に向かう国道137号は富士講の宿場町として栄えていました。
通勤ラッシュも終わり車の通りがゼロなのでこんな無茶なアングルで撮影もできます。
参道までやってきました。前回の道を手繰ります。
北口本宮富士浅間神社につきました。ここが前回からのエントリポイントとなります。
今回のルートの無事を祈りお参りしました。…と、ここでタッチの差で参道から大勢
の観光客が押し寄せてきました。
他の方のレポートでは国道138号線を迂回しなければならないと記述されていましたが
2013年の現在は小川に橋が架っており、国道を経由せず境内から直接行けます。
しばしの間流れが強い用水路のわきを進みます。
そして138号線と合流します。しばし南下したのちルートは富士吉田市歴史民俗博物館
の脇道に入ります。
脇道は素晴らしい紅葉のアーチになっていました♥
しばし脇道を走ると散策路に入ります。道標が全くなく迷いやすいですが迷ったら
ひとまず138号線にでるのが吉です。またこのあたりルートが複数あるのでご注意を。
少しの間のトレイルを超えて鐘山橋に到着です。国道138号線の忍野入口交差点から
もこの場所に来られますのでご安心を。道はすぐにトレイルに戻り、忍野八海へと
向かいます。
下写真の富士学園の手前に道標がない分岐があります。ここは道なり直進で。
忍野八海分岐に出ました。本ルートは右折で山中湖ですが寄り道して忍野八海へ寄り
ました。
なんと平日にもかかわらず観光客でいっぱいです。
気が付いたら草餅買って食べてました…
忍野八海です。ここは富士山の雪解けの湧水が湧出して8つの池ができた場所です。
結構飛ばして走ってきたのですが実は私はここで初めての水分補給です。朝のモス
バーガーで燃料蓄えてたせいでしょか。固形物もさっきの草餅で賄えてます。
忍野八海を離れ、本ルートに戻ります。ぽつぽつ来ていた雨はだんだん雨脚が強く
なってきました。しかし今日は天気予報をみてあらかじめ雨対策万全にしてきたので
想定の範囲内です！
…今回目指す大平山には雲がおっかぶさっていた…。
忍野八海から少し離れた湧出池の浅海を通り過ぎます。
車道を走って今度はハリモミ純林の中の車道を突っ切ります。
ほうとう屋を過ぎた交差点で左折し別荘地の間を抜けたら石割山に続く登山道と
なります。雨は叩きつけるような土砂振りへ変わりました…。
稜線に向けて高度を上げるたびに風もだんだん強くなってきました。
しかし、私は雨中の登山は幾つか経験して来ました。身近なものを利用した電子機器
の防水対策や、濡れたところに強い風に吹かれて一気に体幹が冷やされることによって
おこる低体温症を起こさないための対策とかもこれまた身近なものをうまく使いこな
して完璧にしております！
雷とか土砂崩れ等の不可抗力を除けは注意して進めば怖くな…
ゴロゴロゴロ…ズドドン
…
…なんと稜線にでたころから風雨に加えて雷様も出てきやがったようです
オイオイオイ勘弁してくだち…
普段は風光明媚で富士山とかもきれいに見えるんでしょうけど今は自然が牙を剥いて
襲いかかってきてるような感じです。
しかし東海自然歩道進み続けてたらこんなBADDESTな日なぞよくあります…そのために
いつも特訓して装備も研究して走破できるようにしてるわけですよ…！
私は前傾姿勢になって走るスピードを上げた！
大平山に到着です。雨と風が凄まじいことになってますがイヤホン取ったら風が
バォォォォォォと語りかけます。うまいうますぎる
防風フィルムを体に巻いてなかったらとっくに低体温症になってお陀仏だったかも。
お次は平尾山に向かいます。吹きっ晒しの稜線上からは芙蓉台別荘地がちらほらと
見えました。
平尾山です。漸く雨が弱まって来ましたが風は相変わらずです。
レンズに水が付着しまくってしまいました。
本来ならこのまま平野まで下山ですが、予定より時間よりかなり早くここまできて
しまったので石割山にも行きました。
石割山頂上への最後の直登が泥でヤバかったですがロープが張ってあったおかげで
何とかたどり着けました。気温が落ちてきた所に体が温まったおかげかお尻のポッケ
に入れていたでぢかめのレンズがとうとうケツ露にorz
ｹﾞﾌﾝｹﾞﾌﾌﾝ…すみません。
石割山から平野への分岐にもどり今度こそ平野におります。
下るにつれて雨脚と風もだいぶ弱まってきました。
舗装路まで下りたらもう安心です♥
さらに下って道志道との合流地点である不動明王社に着きました。
そのすぐそばに次回の西丹沢への道標があります。
ここが次回のエントリポイントです！
さらに下って"山中湖平野"のバス停に到着しました。
ここから森の駅旭日丘までラストスパートです！
国道413号に沿ってひたすら走ります。行きかう車が容赦なく水をはねてくるので
その都度ジャンプでかわしました！(←元から濡れてるじゃんってのは無しで)
歩道はやがて紅葉の道になりました。湖畔にも降りられるようになったので
そちらへ進みました。
あんな場所を越えてきたのか…と感慨にふけってる所にもうじき今回の終点が
近づいてきました。
山中湖の巨大なレリーフがある場所で道路に戻り、今回のゴール"森の駅旭日丘"
に到着しました。距離は30kmもなく、難易度もかなり低いルートのはずですが、
中盤〜後半の超悪天候のおかげでなかなかの手ごたえでした。
着替えと土産の購入を終えて気温9度の中をバスを待っていたら"カバです！カバです!"
と妙に真面目なナレーションと共に水陸両用バスKABAが発進しておりました。
転んでひっくりかえったりしたらBAKAみたいｄ
ｹﾞﾌﾝｹﾞﾌﾌﾝ･･･やってきた富士急バスに乗り込み前回と同じく
JR御殿場駅へ向かい帰路につきましたっと
次回はいよいよ東海自然歩道の最難関、丹沢山塊の縦走です。西丹沢と北丹沢の二つ
の過酷なルートに挑みます！
朝霧高原->富士吉田 GPSログ
富士吉田->平野 GPSログ
STM32F4シリーズを使ってみる8 - STM32F429I-Discovery接触編 -
ﾃﾞﾝ！
ﾃﾞﾃﾞﾝ！
…ッツついに来ましたよ…！最強に強まったSTM32F4が…！
後ろに見えるSTM32F437IIT6も後日に…
STM32F429I-Discoveryは現時点のSTMマイコンの中で最強種のSTM32F429とそれが
サポートする64MbitのSDRAMとRGBインターフェースが利用できるTFT-LCDまで
搭載されたまさにねむいさんのために作られたようなボードです！
※正式名称は「STM32F429I-DISCO」だそうです。
STM32F429/439シリーズはRGBインターフェースのTFT-LCDドライバとSDRAMを
サポートするFMC(FSMCからSが取れた)を持ち、最高クロック180MHzで動作する
Cortex-M4Fのコアを持つマイコンです。
ついにSDRAMが…♥もうヒープサイズ気にしなくていいんじゃあんちゃん
ちなみにTFT-LCDドライバのフレームバッファ用にも使われるそうです。
とりあえず電源を入れてみるとSTLink/V2が認識してemWinと呼ばれる小洒落たGUIが
走ります。凄いもんだ…基板上に実装されたTFT-LCDの解像度は240x320です。
タッチするといろいろメニューが選択できます。本来はUSBメモリ等の記憶媒体を
挿しておくようになってるみたいですね。
今は168MHzで動いてるらしいです。
…で、
一通りデモプログラムを確認したのであとはおなじみOpenOCDで内蔵フラッシュメモリ
のバックアップをとり(2MBあるので5分くらいかかりましたよ！) 前もって予習して
いたLEDチカチカプログラムを書き込んで一発動作を確認♥
おきぱのSTM32F4向けサンプルの定義をほんの少し変えるだけで事は済みました…。
お次は目玉のTFT-LCDです。ねむいさんはこっちももちろん予習済です。
STM32F42x/43x系ではUSB用SRAMの容量拡張のほかSPIやI2C等の基本となる
ペリフェラルも数が大幅に増えていて更なる柔軟な回路構成が可能となって
います。
それではここらへんでいつものを…このTFT-LCDのコントローラICは定番の
ILI9341なのでRGBインターフェースへの応用も楽勝ですね♥
今回表示したのはねむいさんの頂き物のｲﾗｽ…ｲﾗｽﾄじゃなくて3D絵です。
あ○たご、抜錨しま〜す♪ぐふふ♥
↑ねむいさんが何のキャラのコスしてるのか最近分かったです…鈍い…
↑ねむいさんて艦これ(ブラウザゲー)やらないの？とよく本職してる時に尋ねら
れますが、6年前からずっとゴルロア続けてますし今もっともアツいブラゲに
嵌ってる(作業的な意味で)のでさすがに他のにまで手を出す余裕がないです…。
なお、びぃぶろ君に確実に怒られると思われるえろすな個所はトリミング済みなので
安心してご鑑賞ください。
20131114追：
タッチパネルコントローラはi2cのSTMPE811です。
こちらも予習済なのですんなりいけました！
というわけで今回はSTM32F429I-Discoveryのファーストタッチをご報告させて
いただきました。基本的な部分は初期のSTM32F4とほとんど一緒なので、
F4Discoveryからの移植はそこまで難しくないと感じました。
まずはFatFsとChaNさんのファイラーを完全に移植させます。12月上旬には
私のおきぱに新しいラインアップが追加されると思います。
OpenOCD小ネタ2
2013年に入ってホビー向けARMマイコンを取り巻く情勢も大幅に変わりました。
導入に結構な金銭的コストが必要だったmbedが、ハードウエア&メーカーの枠が
取り外され、非常に低コストでいろんなメーカのARMマイコンに利用できるように
なりました。さらにARM社も、CMSIS-DAPというCortex系マイコンに特化した
オープンソースのデバッガハードウエアを公開したことにより同じように
GNUのツールに頼らずとも低コストで専用のデバッグ環境をそろえることが
できるようになりました。
導入の敷居を低くすることによりARMマイコン利用者のすそ野を大きく
広げる作戦に出ているようです。
んでもってCooCox等(のEclipseベースですが面倒な初期設定がすべて準備され
かつ無料で全機能が利用できるデバッグサーバ込)のIDEも使い勝手が飛躍的に
向上し環境構築のために時間を費やすorデバッガのデバッグをすると
言った無意味で無駄な行為をする必要もなくなりました。
そういうわけで使いこなせるまでに多くの時間と手間がかかるOpenOCDは最早
無料で利用できるといった唯一のアドバンテージも急速に失いつつ
あります。しかしながら、私を含めた手段が目的になっちゃった人向けに
細々とOpenOCDの解説記事を書いていく所存でございます(以上泣き言終わり)。
●STLink系のアダプタ使うとSPANSIONのFM3マイコンでeraseができない
私がFM3ドライバのエンバグをしていたちょうどその頃、jujurouさんが自身の
ブログ上にてSTLink/V2を使用したFM3マイコンの書き込みについて質問者の方と
やり取りをされていました。私は"単なる結線ミスでしょう"と思ってましたが
丁度MB9AF112KのテストをしてたのでこちらでもSTLink/V2でやってみると
なんとeraseだけできなかった…。
Versaloon(SWD版)やJTAGKey2では問題ないのにSTLink系は駄目。
書き込み動作だけはSTLink系でも可能だったのでOpenOCD側のフラッシュ
ドライバを調べてみるとeraseの操作はtarget_write_u16を使用しレジスタに
16bitのデータを送ることにより行われていました。
分かりづらいユーザマニュアルを見るとたしかにフラッシュ操作の
コマンドは真の16bitアクセスを行う必要があると記述されていました。
一方STLinkやTI-ICDI等のHLAなアダプタはターゲットのメモリの読み書きは
32bitか8bitかのどちらかしかサポートされておらず真の16bitアクセスが
不可能でした。つまりeraseしようとしてtarget_write_u16で必死に送っても
32bitか8bitかの転送コマンドAPIに置き換えられてしまい失敗していたと
いうことになります。
書き込みの時は問題なかったのは書き込み時は書き込みアルゴリズムを
転送してFM3上で実行してるのでこの制約に関係なくwriteコマンドが
成功していたからでしょう。
というわけでeraseの際もアルゴリズムをFM3上で実行するようにして
STLink/V2でも無事FM3マイコンに書き込みができるようになりました。
ついでにjujurouさんの所で質問されていた方も上記のパッチを当てたバイナリを
使用し無事に解決されたようです!めでたしめでたし。
20140227追:
公式にマージされました♥
●USB3.0のホスト(xHCI)でOpenOCDが繋がらない問題は決着か
以前いいところまで原因を追い詰めましたがUSB周りの事は全く分からずドライバを
以前のものに戻してworkaroundとしていました。しかし同様の問題を抱えた方がいた
ようで、その方は自力で解説策を見出したようです。結局ASM1042のドライバのバグが
濃厚で正直libusbx(libusb-1.0も同様)は全く悪くはないのですがlibusbx側で回避
可能なので何時になるともわからないメーカサイドの修正を待つより自分でちゃっ
ちゃとlibusbx側に対策を講じた方がよいのは私も賛同します。
というわけでパッチを当てたlibusb-1.0.dllを作成しねむいさんの環境では動作OK
かつ副作用も全くなし！以前質問を頂いた方々にも協力していただき問題は全て解消
されたとの報告をいただいたので、おきぱで公開しているOpenOCD・UrJTAG・
AvrdudeそしてFlashROMはすべてこのパッチを適用したdllとスタティック
ライブラリを反映しております…っていうか差し替えたのもうだいぶ前ですが
何も不具合報告は頂いてませんので便りがないのはよい便りということで〜
(それでいいのか)
また、USB3.0のホストのドライバ/ファームウエアも最新のものにアップデートして
おかないと不具合につながるケースがあります。
libusbxのwikiにはそのことに対する注意書きも記載されています。
USB3.0ホストが搭載されたここ最近のPCで上手くいかない方は
station-driversで最新のものに変更してから試みることも忘れずに。
●"Remote 'g' packet reply is too long"問題も決着か
長かった…ねむいさんのぶろぐに来た質問でかつて一番数が多かったこの問題も漸く
解決の日の目を見ることになったようです。
"とりあえずFPレジスタ無しをデフォルトにするから弄りたい人はtdesc
コマンドでxmlを指定してレジスタ設定してね"という流れになるようです。
さすがに昔のGDB使ってる人も少なくなりましたからこの変更は必須だと
おもいます。
LPC800シリーズを使ってみる3 -LPC810のことはもう忘れた-
…これが1EURの時代ですか…時代は変わったものですね…!
というわけで私もLPC812-MAXをゲッツしました。ちょっと時間がかかった
理由はというと、値段がキャンペーン価格(1EUR)だったおかげで税関で怪しまれて
止められたというものだったりしますがこういうケースに遭遇したのは
はじめてでした。
以前購入していたLPC812XPressoにI2CなAD/DAとI/Oエキスパンダが加わり、
基板のレイアウトもArduinoのシールドが載るようになっていま…
…コネクタがちょっとずれてる…まぁこれは見なかったことにして！
この基板はXpresso系とは違い、mbedとして利用が可能なLPC11u35が
mbedチップとして載っていてさらにこれはCMSIS-DAPとしても働きKeilの
uVisionからデバッグも可能となっていま…
おや…PCF8591Tの足に変なものが…
…ハンダボール発見！…おいおい
価格は1EUR(送料込)なので細かい部分に文句たらさずミシン針でﾋﾟｼっと弾いて対処
完了です。これにて一件落着！…したら今日のぶろぐ終わっちゃうのでまだ続けます…
●とりあえずVersaloon
私の定番のOpenOCDとの連携です。この時注意すべきはSWDの2つの信号が
mbedチップと干渉するのでMSCブートローダーモードにしてmbedチップ
側のSWDを殺しておく必要があります
(CMSIS-DAPのファームウエア側でトライステートにしてくれたら手間省ける
のですが…)。
も一つ注意すべきは回路図をよく見れば気づくはずですが12MHzのXTALが
繋がっておらずmbedチップ側からクロックが供給されているのでスタート
アップの定義を内部CR発振にするなり半田でつなぎかえる等の変更は必要です。
LPC812に関しては内部の12MHz発振からPLLで24MHzにするのが最も潰しが
効くかなと思います。
そんなわけでおきぱにあるLPC812のサンプルは既にLPC812-MAXにも対応済です。
まだLEDとsystickだけですが順次拡張予定です。
●MBED CMSIS-DAPを試す
話が前後しますがLPC812-MAXをPCと接続するとマスストレージ(MSC)が
認識されます。そこからさらにmbedのドライバをインストールするとコンポジット
デバイスが認識され、続いてUSB-CDCの"MBED VCOM"とUSB-HIDの
"MBED CMSIS-DAP"が認識されてmbedの仮想COMとMSC,そしてCMSIS-DAPが使用
できるようになります。なお、当ぶろぐにおいてはマトモに商用のIDEから
CMSIS-DAPを使うはずもなくいつものOpenOCDから使用することになります。
以前KL25Zを使用した時にCMSIS-DAPをお試ししてましたがその時はほとんど
使い物にならない代物でした。しかしgerritに上げられた後は修正がどんどん入り、
現在ほぼ完成状態になりました。もちろんデバッグ可能なコードサイズの制限は
一切ありません！
さらにSTLink系のHLAアダプターでは不可能なローレベルアクセスも可能です！
Kinetis系のチップ使ってやらかした時も大丈夫！細かい部分は後日OpenOCDの
記事にて解説しますが今はとりあえず使用してみましょう。
フラッシュ書き込み
デバッグ
初期と比べるとかなりいい感じです。
さらっと使用した感じではUSBのパケットを有効利用していないのか書き込みが
極端に遅く感じます。CoFlashではちゃんと早く書き込めているのでここら辺は
さらに改善の余地があるでしょう。
ここをクリアできたらゴールかしら…。
私のおきぱのOpenOCDはまだCMSIS-DAP対応ではありませんが、OpenOCDの
コミットにマージされたら即座にSWD版Versaloonのコードと一体化させて
反映させるつもりです。
●おまけ
KL25ZもMBED版CMSIS-DAP化して書き込んでみました。
PE-MICRO提供のCMSIS-DAPとMBED版CMSIS-DAPは少し仕様が違うのでご注意を。
仮想COMが使えるMBED版をお勧めします。
書き込んだときはこんな感じです
当たり前ですが上記のCMSIS-DAP化したLPC-Link2でも使用可能です♥
HighSpeedなのでちょっと書き込み速度が上がります♥
(ところでLPC-Link2用のMBED版CMSIS-DAPはまだでしょうか‥‥？)
東海自然歩道を徃く22(草薙-興津/興津-富士川)
今年の夏は暑かったですねマジで･･･屈強な高校球児すら熱中症で痙攣するレベルの
猛暑でしたが、やきう場より過酷な場所に果敢に挑んでいきました。
●2013.07.13 草薙->興津
この山行(というか今回は海行)に挑む少し前に富士山が世界文化遺産に登録されました。
同時に今回通過する予定の三保の松原も登録されたようですがはてさて･･･
今回のルートは正規ルートは三保の真崎灯台の手前で終了ですが私はそのまま
次なる戦場となる興津へ向かいます。灼熱の太陽が照りつける海岸線のルートが
勝負の鍵となるでしょう･･･いざ出発！(右端の変な仏像から目線をそらしながら)
南幹線を通過し住宅街をかいくぐると草薙神社に着きます。
こんなところにも龍勢のステマがー！？
立派なトイレがあったのでここで体制を建て直し新たに出発！
静岡バイパスコースは比較的難易度低いですね〜舗装路ばっかで楽チン
･･といいたいところですが夏場は地獄です･･･
虹裏メイドなのに第二のふたばがあるなんて知らなかったそんなの･･･
さて、ぐんぐん舗装路の坂道を越えるといったん下りの道に転じて
日本平への車道とクロスします。ここから山道がはぢまります！
し ゅ ん た
これはいい感じのトレイルですね〜♥
とおもいきやあっという間にそれは終わる。
ここを少しあがると再び舗装路に･･･
日本平ホテルです。
蝉兄貴も夏を満喫していますね…
日本平山頂公園に到着です。ここで水分補給をかねた小休止です♥
(XX高原ミルクってありがちやな･･･)
でもまんまと買ってしまう私･･･
この日は7月上旬にもかかわらずぎらぎらの猛暑でしたがツーリングの人たちも
沢山こられていました。11年前は私もよくドライブにつれてってもらｔｔ
ぶ わ っ
ずびっ･･･失礼しました･･･静岡の海岸線ルートはどうも私の青春時代を刺激
してしまって･･･ぇーっと日本平の山頂です。ここから久能山東照宮に降ります。
日本平山頂から久能山東照宮は山道は一切なく、ロープウェイで移動せざるを
得ません。しかし立派なこれも正規ルートなのでまぁ良いでしょう。
で、ロープウェイ待ちでベンチに座ってると猫ちゃんが2匹ねむいさんの元に･･･
日向をさけで私の足の下に来ましたが･･･
何故かその子の内の一匹が急にベンチを離れ、割れたコンクリの隙間に
頭を突っ込みお尻がはみ出た姿勢で固まっていました･･･そしてそれを
醒めた目でベンチ下から見つめる相方の猫･･･どうやら暑さで頭が･･･
そうこうしてる内にロープウェイがやってきました。
静岡なのでいたるところに世界遺産アピールがありますね！
ロープウェイの到着点は久能山東照宮の入り口になっています。
でも鳳来山のときと違ってお金結構掛かるのでスルー
(私の親父用にお守りだけ買ってきました)
ここからは海岸線に向けてひたすら階段を下ります。
11年前と同じ景色が眼下に広がる･･･(じわわ
上りはかなり辛そうですね〜
ぬふぅ！
ｹﾞﾌﾝ失礼、ここから先は久能街道こと国道150号線(の端っこ)を爆走します。
山道とは違った平坦な道ですが今は灼熱の太陽が容赦なく照りつける極めて
過酷なロードとなります！いざ勝負！
久能海岸は外海なので凪いでるときでも非常に荒々しいです。
JDの頃は良くここにもドライ(ry
眼から鼻水出てきました･･･ずびびびびびび
♪日射しの熱さに思わず目を閉じた 蜃気楼と過ぎてゆく夏の匂い あの日
♪荷物の重さで膝付き傾く背中に そっと触れたから 動きだした
150号線と離れ三保の松原をさらに目指します。ねむいさん作のスペシャル
ドリンクのおかげでこの過酷な天候下でも足の調子は抜群です！
実はこのルートは太平洋自転車道と道を同じくしています。
ここはホントは道に沿って左折せざるを得ないのですが、ぢつは矢印の方向に秘密の
近道があります♥なんで京都の人間が静岡の地元の人間レベルのこと知ってる
のかですって？うふふ
さて、近道の松林を抜けるともうそこは三保の松原"羽衣の松"です。
世界遺産効果か観光客もめちゃくちゃいます。私はここでも
11年前に立ち寄った茶屋で休憩を取りました･･･注文するのは
もちろんいちごみるくちゃん♥♥♥♥♥
やべ･･･一気食いしすぎて頭痛くなってきました･･･
しばしの間羽衣の松とかを見物しました･･･しかし、前日の7/12に先代の
羽衣の松が老朽化により切り倒されてしまい無残な姿に･･･
11年前は(ryこれ松の前で一緒に写した写真もまだのこしてｔぶわっつ
すみません取り乱しました･･･ちょっと眼から鼻水がまた出てきちゃったもんで･･
さて、松の先には三保の荒々しい外海が広がります！松側を振り向くと石でメッセー
ジが砂浜に刻まれてるのに気づきました。消えかかってましたがまだ･･･
オメデトウ2013世界いさん(下に富士山の絵)
メインの先代羽衣の松が切り倒されてしまいだんだん曇ってきたおかげで富士山も
見えませんorzせっかく世界遺産になったのにちょっとしょぼいです。
説明員の人がやってきた観光客相手に孤軍奮闘で解説の大立ち回りをされていました。
さて、たっぷり水分と休憩も摂ったので再出発です。
海岸線を縫うようにひた走ります。
三保灯台です。
こちらは三保飛行場です。
猫ちゃんも夏バテです。死んでるかとおもったら生きてましたよ。
自転車に轢かれないように安全な日影の場所に移して上げました。
三保海水浴場です。たしか11年前はここにシュモクザメ沸いてて遊泳禁止になってたはず･･･
でしたが･･･時代は変わった
真崎灯台です。東海自然歩道はここでいったん終了ですが私はこのまま先に進みます。
ここから先のルートは私の記憶が興津まで再び誘導してくれます(眼から鼻(ry
a>
三保の内海側です。静大ヨット部は健在ですね〜
海岸線を抜けると後は興津までひたすら車道を走り続けます。
この道も何もかも(ry
三保車庫です。ここから先はゴールの興津までひたすら車道！
さっきの三保車庫からJR清水駅はかつて国鉄三保線が走っていたそうです。
現在は自転車道になっているこのルートですが私も折戸駅跡からここに合流しました。
結構長くてきつい･･･湿度も100%あるんじゃないかという気候です。
曇ってこなかったら干上がって死んでたかも･･･
画像は清水といえば鈴与
oh...途中で国鉄三保線が私有地に吸収されてました･･
仕方ないので車道に戻ります･･･
静鉄清水駅周辺です。エスパルスドリームプラザが見えますね･･･。
右端に見てはいけない物体が･･･
杉山君総受け本
ねむいさんはさくらももこより岡田あーみんが好きでしたよぅ！！
というくだらない主張はおいといてJR清水駅に到着です。
旧三保線はこの場所で終了ですが太平洋自転車道はまだまだ続きます。
国道一号線とくっついたり離れたり。
11年前はここもねむいさんドライブで(ry
道はやがて旧東海道と再び合流します。
ここはすでに宿場町興津です。
それっぽい道標や案内板も目立ってきます。
うぉぉもうすこし！！！
ようやくJR興津駅に到着です。
久能海岸以後の舗装路延々走りはかなり効きました･･･三保の松原以降は曇ってきて
日射もかなり低減されたので超糞熱くて汗もダラダラでしたが精神的にだいぶ楽でした。
でも清水駅以降でふくらはぎがまたつりかけたのは反省ポインツです。
この程度で躓いてたら次回の過酷なルートは越えられません！
ねむいさんは次なる戦いに向け新たな決意を元に新幹線の中で爆睡するのでした･･･！
●2013.08.24 興津->富士川
今回は真夏の真っただ中に40km超の過酷なコースを巡ることになります。
ゆえに超激戦が予想されたので7月末くらいから特訓をしておりました。
仕事が終わったら西院から出発して東海自然歩道のルートでもある嵯峨の
六丁峠まで行って帰ってくる走り込みをほぼ毎日行い、特に六丁峠の登坂は
ダッシュで駆け上がり駆け下りてくるといったトレーニングでスタミナと
脚力を強化して挑みました！
出発地点のJR興津駅です。
旧東海道を少しの間手繰ります。
この興津郵便局の手前の交差点は身延道の出発点でもあります。
興津川を越えて薩た峠への旧道へと向かいます。
薩た峠への道標はいたるところにあって安心です。
そこまでやらんでええちゅうに！
この激坂を超えると休憩所とお墓がありその中をさらに通過します。
薩た峠です。
私はこの下を通る国道とかはよく来てたのですがこの峠自身を通過したのは
初めてでした。11(ry
目下には駿河湾の荒々しい海が今日もうねりを上げていました。
それにしても暑い…汗がﾎﾞﾀﾎﾞﾀたれまくってます…。雲は多少ありますが
その隙間から太陽さんはギンギラギンに直射日光を提供してくれます…
写真がちょっと暗いですが露光のせいでこんな風になってます。
薩た峠第二ビューポイントに来ました。
ここは有名な場所ですね〜。しかし肝心の富士山は雲と熱気による霞で
さえぎられてほとんど見えずorz
…おや…国道の立体交差の真ん中にあるあの建物は…？
あのうどん屋まだあった！
11年前ドライブで伊豆に連れてってもら(ry
猛烈な熱気のせいか目から大粒の汗が出てきました…貴重な水分が…
それはともかく灼熱のアスファルト道を超えて浜石岳の登山口にたどり着きました。
この日の静岡の最高気温は34.4度、持参したスペシャルドリンクとSAVASピットイン
リキッドで本日の最難関に挑みます！
浜石岳の山道は蜘蛛の巣だらけの上道が藪の上痩せてて非常に
危険です…ていうか蜘蛛の巣やめて！！１１！
ようやく走れるトレイルにでられた〜
と思ったらすぐに蜘蛛の巣ゾーン！！
藪藪藪藪藪藪
ちょっとでも止まると藪蚊が襲ってくる藪ゾーン
但沼分岐までようやくやってきました…持参した水分もあと500mlと少し…
しかし汗は滝のように出てズボンも発汗でおもらししたようになってます////
最後の急登…ここを登れば終わりだっ…！
予定時間より10分ほど遅れてようやく浜石岳頂上に到着です…
頂上に付いたころには雲が空を覆っていましたがそれを貫く勢いで
お日様光線が…とりあえずちょっと休憩…ぇどっこいしょ
…
……
…
…？
はぅあ！！
私としたことがベンチの上で仰向けで5分ほど意識失ってたようです…
このまま眼覚めなかったら熱中症でまぢで死んでたところですよぅ
長居は無用なので頂上を後にしました。
浜石岳を下りるとその先から静清庵自然歩道と何度も道を同じくします。
東海自然歩道のルートがわかりづらい箇所もありますのでご注意を
東海自然歩道は山道ではなく林道を下ります。
林道をひたすらくだってくだってくだってくだってくだって･･･
やっと民家がちらほら見えてきましたがやばいっす･･･水が切れてきました･･･
浜石岳がもうあんなに遠く･･･ボーっとしつつ間違えて入った道に
なんと共同墓地と水道水とトイレがー！ﾋﾔｯﾊｰみずだ！！１
ｺﾞｸｺﾞｸｺﾞｸｺﾞｸ･･･生き返った･･･
特訓の成果がああってか夏場で猛烈な下りの連続でも全く足が攣ってません。
ぐんぐん下ります！
銚子口の滝にも立ち寄りました。
もちろんここも蜘蛛の巣だらけ！ぬぎゃー
ようやく開けた場所まで降りてきました･･･はぁはぁ･･･。今度は県道76号線にそって
北上しますが、途中に商店と自販機があったので改めて水分を取りなおし
SAVASピットインリキッドも流し込んで２機目のエンジンをかける準備をして
再出発です。
このあたりは水が非常に綺麗で天然のわさびも道路の脇の小川にふつーに自生してます
でも私有地にあるので採っちゃ駄目ですよ！
"かぎあな"で県道とはなれ見晴観音へと向かいます。
勾配のきつい登坂でしたがようやく第２エンジンがかかったのでぐんぐん上ります！
道はやがて山道になります。しかし天候も完全に曇りになって気温も下がり始め
道も比較的歩きやすい山道なので浜石岳よりもさくさく進めます♥
見晴観音とやらにつきましたが･･･？？？観音さまは？
しかも木が邪魔で視界ゼロだし･･･さぁ次です次！
見晴観音から先は山々の縦走になりますがアップダウンもすくなく
走るテンポを上げることができました。まずは大丸山。
お次は大久保山です。
そして大平山･･･ここから野田山公園に向かって下ります！
が･･･ここで猛烈な藪藪藪･･･
下りの藪は足元が分からず非常に危険なので慎重に降ります。
無事に車道まで降りてこられました。
ここは次回行う新蒲原からのルートの合流点です。
警察屋さんがこんな山の頂上まで来てましたが･･･どうやら不法投棄監視の
パトロールされてるみたいですね。こういうとこって絶好の捨て場所ですからね･･･。
さて、エスケープルートはそのまま富士川方面にまっすぐ降りていく車道
なのですがねむいさんはもちろん東海自然歩道をさらに進みます。
ルート上の林道でついに夏富士を拝むことができました････！
さらに進んでいくと南松野の芝川コースと富士川コースの分岐点に着きます。
ここで富士川駅への進路をとります。次回のルートは結構このルートと
被りますね。
ぐんぐん車道を下っていくと新東名が見えてきました。この下をくぐります。
富士山もくっきり見えるようになってきました！
さらに下り、血流川を縫うように進むとこの東海自然トイレに突き当たります。
写真では見えてませんが手前のT字路で右折してください。
富士川の手前で身延道にそって登ります･･･だめだそろそろガス欠･･･
風の宮公園より富士宮方面と熱海方面の新東名高速を望みます。
少しのトレイルを抜け、道の駅富士川楽座をめざします。
視界が開けると富士川が一瞥できていい景色です♥
ねむいさんはもちろん川の風コースを選択！
もう暗くなってきましたし〜
道の駅富士川楽座です。
ここは富士川ICでもあります。
さらに下って富士川橋です。
11年前富士山のふもｔ･･･ぶわわっ
もはや水分は出尽くした･･･
えっと暗いですが両脇に見えるのが岩淵一里塚です。
あたりがすっかり真っ暗になった頃についにJR富士川駅に到着です･･･
足には豆ができまくりましたが懸念された足の痙攣は全行程42kmとおして全く起こらず
特訓の成果が十分に得られたと確信しております。
また午後になって曇りになり急激に気温も下がってきたのが幸いしたと思われます。
夜の帳の下りたホームは風もあって少し肌寒いくらい。
夏の終わりを感じる一日でした････。
なお、この日の夕飯は鯛めしでした♥
飲み物はもちろんゑ・び・す♥
いいんですよぅこの日超がんばったしビールは入るところ別ですし！
というわけで記録的猛暑となった過酷なこの時期に逃げ場なしの直射日光が
照り付けてさらに過酷になる海沿いの2コースをわざわざ進みました。
しかし運良くどちらも途中から曇りになり熱中症になることもなく危なげなく
ゴールに到達できました！いやもちろん適切なアイテムしっかりそろえて挑んだ
のと地元京都で特訓しまくった成果が出ちゃっただけなんですけどね〜
うふふ(地獄のミサワみたいな顔で)
次回は野田山周辺のルートをもう一度なぞりさらに芝川まで抜け、そして静岡
バイパスコースの終点であり本線とのエントリポイントでもある田貫湖をめざす
2013年度の東海自然歩道夏の陣のラストとなります。
草薙->興津 GPSログ
興津->富士川 GPSログ
いろいろ試す19
あっという間に(仕事上の)夏が終わってしまいました･･･日記上は更新
してないので夏ばてしてた様に見えるでしょうけどもじつは更なる跳躍の
ために私なりにいろいろやっていたのですよぅ！
とくに東海自然歩道関連もトレーニングを重ねて猛暑の中で難所をクリア
してきたのでこちらも近いうちにじっくりと･･･
●夏休みの工作☆LPC4088
さて、円高の頃に買い込んでいた基板やチップの中で最後の大物で
残っていたLPC4088に着手をはぢめました。
基板はLPC1788ですがLPC4088はほぼピンコンパチなのでそのまま乗っけ
られます。生基板なので仕事や家事終わったあとに大量の部品をちまちま
ちまちま付け続けお盆休み明けにようやくFatFsまで動作を確認しました。
LPC1788のときと同様に大容量のSDRAM乗っけてます。STM32系と違って
heapやstackとしてがんがん使ってもコケないのがすばらしい！
(STM32F1系のFSMCはerrataとしてFSMC上のSRAMをheapやstackに使うな
ととうとう明記されてしまいました!!!11!!F***K!!!!)
LPC4088はLPC1788には存在しないSPIFIインターフェースを持ちます。
しかし･･･
困ったことにLPC1788系と互換性を保った結果LPC4300系と違いSSPポートの
互換性がなくOpenOCDから書けないことが判明orzOpenOCDはSPIFIではなく
ポート互換のSSPで書いてたんですよね〜
･･･ドライバの対応はnuvotonドライバの時よりしんどそうだったので
早々にあきらめ外付けのコネクタを設けてFlashROMを使って書き込みする
作戦に変更しました。SPIFIは容量を喰うFONTXファイルの置き場に
使用していきます。
あと付けてないのはLCDインターフェースですがこれは私がいつも使ってる
MCUバスではなくRGBでつなげるタイプのものを必要とするのでそれに合う
液晶の調達から手を付ける予定です。
●Kinetis K20/K10シリーズを触る
わざわざ独立の記事にするほどでもない超小ネタなのでここでさらっと
紹介します。少し前にFRDM-K20なるボードが販売されましたがこの
シリーズの一番小規模のチップであるMK20DX32VLF5とMK10DX32VLF5を
ちょっと触りました。写真はK10のほうです。
K20はUSBと内蔵3.3Vレギュレータが付いてて本当にこれひとつで完結した
基板も作れます。実際に安価に製作されている方もいるようです。
ねむいさんがこれを単品で購入した理由はOpenOCDの書き込み/デバッグ
確認のためだけに過ぎません･･･
が、このチップ特有の機能にちょっとはまってしまいました。
以前、私はKL25やKL05を触りOpenOCDへの書き込み/デバッグを可能にして
きましたが、K10/K20もコアがCortex-M4(F無し)違いでKLシリーズと同じ
ように楽勝だろうと高をくくってました。しかしPOR後のウォッチドッグ
タイマの挙動が違っていてブート直後に即効ウォッチドッグの機能を殺しに
いかないとせっかく書き込んだのにセキュリティ状態に突入してしまい、
mass-eraseして解除してからGDBからイメージをもう一回ロードしないと
デバッグできない事態になることが判明!
工場出荷時はセキュリティ状態は解除されてるらしいですがこのウォッチ
ドッグリセットのせいで実質セキュリティ状態になってる為STLink/V2などの
MDM-APを直接叩くことが不可能なデバッガハードウエアでは手詰まりに
なってしまいます･･･ぬぎゃー
(これFRDM-K20が国内販売されたらまたねむいさんのとこにプログラムが
書けなくなったって質問飛んでくるんだろうなぁ････)
●EFM32シリーズもおさわり
同じくOpenOCDの書き込み確認のために単品購入したチップです。
EnergyMicroというメーカのチップでしたが現在はSiliconLabs社に吸収されています。
Gecko(ヤモリ)のマークがチップ上に付けられたイカすデザインでCortex系の
マイコンでは超低消費電力方面に力を込めたラインナップとなっています。
ねむいさんがチラッと触った限りではCMSISライブラリがSTM32ばりに充実
していてCMSISにどっぷりつかったねむいさんの流儀に非常に組み込みやすく
最初の取っ掛かりのLチカ作成が最速の30分で完成しました(逆に一番難儀
したのはあちこちにファイルが点在してて把握しづらく挙句の果てにKeilの
サンプル中にしかCMSISヘッダファイルが無い品種もあるKinetis･･･
てか公式のサイトでリンク切れはまずいですよぅ)。
書き込みデバッグももちろんすんなり完了ですごい相性よかったので
メインのSTM32からちょっと浮気しちゃいそうです･･うそですよぅうふふふ
というわけでOpenOCDのバイナリには上記3品種の書き込みcfgファイルを
追加してます。パッチも前回から不備が見つかったものをさらに改修して
ますので私と同じ環境をお持ちの方は試してみてくださいね〜
･･･すっかりOpenOCDありきのマイコンいじりになってしまいましたが、
実務ではルネさｓ
(日記はここで途切れている)
FM3が富士通からスパンションになりましたよ記念
20161123追：
富士通のFM3を喰ったSPANSIONはCypressに喰われました。
富士通のFM3マイコンに関する記事はもう更新しないでクローズにしようと
思っていましたが、国産マイコンだったFM3シリーズが大人の事情でSPANSIONという
メモリ中心のチップベンダに移譲されたので記念に小ネタを更新します。
前回まではFM3マイコンにFatFsやTFT-LCDドライバなりを積だのを紹介して
ましたが今回はOpenOCDのFM3フラッシュ書き込みドライバの改良についてです。
いつも参考にさせてもらっているjujurouさんによると小規模のRAM物理量が少ない
品種で書き込みが出来ないとのことで、Kinetis-LシリーズやNuvotonのフラッシュ
書き込みドライバを実装して実力をつけた私も調査してみました。
上の二つの図はFM3マイコンに収納されたフラッシュ書き込みのバイトコード
(書き込みアルゴリズム)と書き込むべきデータを簡略化した物の修正前と
後の比較です。
フラッシュ書き込みはJTAG/SWDから内蔵SRAMに流し込んでおいたバイト
コードをOpenOCD側の"run_algorithm"にて実行させることにより行われて
いますが、その中でSRAM上にある"u32DummyRead"と"u32FlashResult"の値を
参照しています。この二つの変数は、アルゴリズムを確保したメモリの先頭に
置かれるため、アルゴリズム開始アドレスは、本来は基底アドレス
(BaseAddress)から+8ずれることになります。
おそらく最初にドライバを作った時のデバイスがMB9BF506Nだけだったようで
SRAMの基底となるアドレスが0x1FFF8000に固定化されていました。
しかしFM3シリーズの内蔵SRAMの構造は、0x20000000をベースとして上下に
伸びていく仕組みなので安全牌で動かすためには本来なら基底を0x20000000に
しなければなりません。現状ではSRAM量が物理的に少ない品種ではOpenOCDの
cfgファイル内でSRAM量とSRAM開始アドレスを"正しく"指定すると、
jujurouさんの指摘通りSRAMが存在しないアドレスを参照することになり、
書き込みが必ずコケる羽目になってしまいます。
というわけで私も私なりに修正してなおかつ書き込みパフォーマンスを上げる
修正を盛り込んでパッチを作成しました。先ず以前使っていたMB9BF618Tで
当然のように書き込みを確認しました。さらに今回の問題が修正されてるのを確認
するためにebayで小規模のFM3マイコンMB9AF112K(Flash:128kB/SRAM:16kB)
を仕入れて動作確認を行いました。
↓やっけつ基板
ログはこんな感じです。ばっちり書き込み出来てますね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/mb9af112k_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00117-gf7fed92-dirty (2013-08-12-20:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_only separate trst_push_pull
adapter speed: 500 kHz
cortex_m reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on May 22 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 500 kHz
Info : Found SWD-DP id:0x2BA01477
Info : mb9bfxx2.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000114 msp: 0x20002000
auto erase enabled
Info : Fujitsu MB9[A/B]FXXX: Sector Erase ... (0 to 2)
Info : Fujitsu MB9[A/B]FXXX: FLASH Write ...
wrote 131072 bytes from file main.elf in 4.344639s (29.462 KiB/s)
verified 33456 bytes in 0.109398s (298.651 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05さて、上記FM3の修正のほかにkinetisドライバとNuvotonドライバのブラッシュアップ
も行い、8月11日時点のOpenOCDのコミットに適用したパッチ群も更新しました。
もちろんOpenOCDのバイナリも修正していますので奇しくも時を同じくして一般販売と
なった｢FM3-USBSTICK｣を購入された方は試してみてください(私はMB9AF112Kで試し
ましたがメモリ構造が同様のMB9AF312Kでもまったく同様に使用できます)。
･･･
本来はこの程度の小ネタはブログトップのサブタイ欄にちょっと書いて終わる
はずなのですがVersaloonのBBSにKinetis-LドライバやNuvotonドライバのパッチを
紹介したことでntfreakﾘﾝｻﾝの目に留まり、OpenOCDのgerritにFM3の修正を含めた
いくつかのパッチを叩き上げられることにめでたく相成りました。
しかし、そのFM3ドライバのパッチはまだバグが修正仕切れてなかった欠陥版
だったのがつい最近判明したので、汚名返上のために私自身もOpenOCDのコード
レビューシステムに電撃参戦する意を決めました！！
とはいえパッチを提供するまでに覚える事柄が非常に多く英語による意思の
疎通も非常に重要になります。なんにせよひとつずつ目的達成までの課題を
あせらずクリアしていくほかありませんが汚名挽回をしてしまわないように
気をつけます･･･。
Discovery系基板を中心とした小ネタいろいろ
2013年7月現在、STM32とそれが搭載されたデバッガハードウエア付きの
超廉価なDiscovery系ボードはホビイストや学生さんにも今回は十分行き
渡っていると思います。今回はそれらを中心とした開発上の小ネタ…
…といっても結構重要なのをご紹介します。
故中島らも氏みたいに過去に書いたことをまた書いてるような箇所が
ありますが大事なことなので2度どころか何度も言います！！！！
●OpenOCDで使いたい！
太古の昔、STLink系のハードウエアはプロプラゆえに当ぶろぐでは
燃えないゴミとして扱われていましたがSTマイクロさんのご厚意により
V1,V2共にAPIが提供されてOpenOCDからも使用可能となりました。
尤も、対応最初期はLibUSB0.1系のAPIからでしか使用できず、メーカ製の
ドライバが(WinUSBが)使用できないのでちょっと不便な代物でした。
その後のlibusb1.0系の移行よってそれも解消され、現状商用andフリー共に
最も融通が利くデバッガハードウエアと言えます(但しSTLink/V1系は
MSCで繋がるので今でもちょっとめんどいです)。
STM32F3Discoveryを例にとると、基板上にビルドインされたSTLink/V2に
よってSWD接続にてターゲットのSTM32F303VCTに接続されています。
おきぱで公開しているOpenOCDバイナリにはねむいさん特製の書き込み
スクリプト込のcfgファイルも同梱しています。
上記のcfgファイル内ではさらにcfgファイルの入れ子構造になっていて
OpenOCD公式が配布しているcfgの内容が差し替わった時もこちらの変更は
ノータッチで継続使用可能なように管理しています。
具体的にこれを書き込みやデバッグにどう使うかは私のSTM32F3のを用いて、こちらとこちらを参考にしてください。
プロジェクト
STM32F3の場合はmakefile内でデフォでSTLink/V2を使う設定にしているので
初めての人でも非常に簡単にできます。
20230828追:
STM32F334-NUCLEO向けのプロジェクトを参照してください
20230828追:
それと最近よく頂くようになった質問で圧倒的に多いのがSTLink/V2でOpenOCD
との接続が上手くいかない繋がらないといった非常に曖昧なものなのですが…
ほぼ100%結線ミスが原因です。
特に気づきづらいのがDiscovery系の基板を使ってオンボード上のターゲット
MPUではなく外部のマイコンに書き込もうとした時なのですが、V2.J15以上の
ファームだとターゲットのVCCの電圧も監視しているため、Vtgtを繋げていないと
エラーでこけます。
しかも多くのDiscovery系基板ではVtgtを取り込む抵抗が未実装のため、
それに気づかずVtgt繋げてるのに上手くできない！といった事態になります。
↑STM32F3Discoveryでは上記の部分に100ohmを乗っけてバイパスする。
同じこと以前も言いましたが大事なことなので何度でも言います
ついでに
↑STM32F3discoveryではSWOまで未接続なので画像の箇所をはんだブリッジ。
これやっとかないと後述のSWVが使えません。
●STマイクロの公式ツールを使いたい！
現在STマイクロさんからSTLink-UtilityなるSTLink用のGUIツールが提供されています。
上で触れましたがOpenOCDがSTマイクロ公式のドライバでも使用可能になったので、
ドライバの差し替え無しにSTLink-Utilityも使用ができます！
フラッシュ書き込み・レジスタの参照など基本的な操作の他に3.0.0以降では
強力なシリアルワイヤビューアも使用可能です(後述)。
一部のサイトではLibUSB0.1系でやってたころの私が公開していた情報を基に公式の
ドライバを使わずzadigでインストールする指示をされている方もいます。
STLink/V2に限ってはそれは今ではもう無意味です。逆にそれをやってしまうと
STマイクロのSTLink-Utilityが使用不可能になりますのでご注意を。
なんでこんなことわざわざ何度も言ってるかというと情報が同期していない
せいで"動かないうまくできない"という質問が私の所にﾀﾞｲﾚｸﾂに飛んでくるからです…。
●セミホスティング考
セミホスティングとは思いくそかみ砕いていうとデバッガを通じてホストPCに
printf関数等の標準出力を吐き出させることができる仕組みです。
詳しい説明はARMのサイトにて。
かみきさんのサイトでも分かりやすい説明が記されております。
LPCXpressoを使用されている方はUARTを介さずprintfを実行する方式として
ご存知かと思います。しかしそれらのメーカーお仕着せのIDEを使わない環境でも
OpenOCDとGDBを組み合わせたり上記のSTLink-Utilityにより再現が可能です。
Cortex-M3系のマイコンでは2通りの方法があります。
1.OpenOCDから…
OpenOCDではすでにセミホスティングに対応しています。そしてプログラムも
当然ながらセミホスティング用にビルドする必要があります。
現在Launchpad-ARMGCCのみで動作を確認しておりますが設定方法は
私のプロジェクト上では以下の要素を。
* makefile内
"--specs=rdimon.specs -lrdimon"をCFLAGSに追加。それに伴いLFLAGSから
"-nostartfiles"を削除(セミホスティング用のcrt.oを使う)。
STM32F3,F4で使用する際はnewlib-nanoの制限によりCCM領域にスタックを
おいているとセミホスティングが正しく働かないので普通のnewlibの
ライブラリに切り替えてビルドしてください。
* ソースコード内
"initialise_monitor_handles()"を標準関数を実行する前に必ず実行。
* デバッガソフトウエアとの連結
当たり前ですが上記の設定でビルドして出たバイナリを書き込んでもそのままでは
何も起きません。OpenOCDで接続してデバッガとホストPCとが通信できる状態に
ならないとだめで、OpenOCD接続時に-c"arm semihosting enable"を追加する
必要があります。
"arm semihosting enable"はセミホスティングを使わないときも実害はないので
つけっぱなしでもかないませんのでmakefileには反映しています。さて、すべて
準備がそろった状態でrunさせるとOpenOCDのアウトプットにprintfの文字列が
表示されます。
* LPCXPressoみたいに小規模マイコンでできるのか？
たとえばフラッシュのサイズが32kbしかないLPC1114でもLaunchpadの
"newlib-nano"と組み合わせることによってなんとバイナリサイズ7kb以下で
printfが可能です！
小規模ゆえに同一RAM領域にスタックとヒープが存在するのでnanoの方でも
セミホスティング可能というわけです。(浮動小数点付も22kb以下で可能)
標準関数組み込んだらバイナリサイズが一気に肥大した〜！
…なんて話は今は昔。
2.STLink-Utilityを使って…
これはCortex-Mの仕様上CortexM3/4専用技ですがSWVを利用してprintfを
実行します。原理はprintfの出力先をリダイレクトするのと全く同じです。
ねむいさんの公開してるプロジェクトでは…
syscalls_if.h内のputch()のdefineをITM_SendChar(x)にするだけで終わり
です。しかも1.の方法と違って垂れ流し方式なのでデバッガと常時接続
しないと先に進まないといった障害もありません。
STLink-Utility3.0.0以降でSWVが使用可能です。
クロック設定はsysclock(ねむいさんのサンプルでは72MHz)に合わせて
ください。ここでハードウエアリセットを掛けるとprintfの文字列が
表示されます。
●STLink/V2がUSB3.0のホストでOpenOCDが繋がらないんですけぉ！１１！！
私が公開しているOpenOCDバイナリのビルドポリシーをLibusbの0.1から1.0系に
変えて少しした(現在は1.0系ライブラリとしてlibusbx1.0.16を使っています)あたりから
STLink/v2やFT2232系のデバイスがUSB3.0で繋がらなくなった！でもUSB2.0ポート
からならいけたという報告を頻繁にいただくようになり、私も調査を開始しました。
…が、ねむいさんのUSB3.0の環境ではそんな不具合全く出ない。
手持ちや後輩が持ってた拡張カードとかいろいろ試したところ特定のUSB3.0ホスト
で且つlibusb1.0系で繋いでくるデバイスの動作がすべておかしくなるのをやっと
突き止めました。
そのUSB3.0ホストとはAsmediaのASM1042!
libusbxを利用するすべてのデバッガハードウエアに波及しやがるのでOpenOCDは
おろかUrJTAGやAvrdudeやFlashromもだめですorz.
libusbxのビルドをログ出力対応にして追跡していったところ、DeviceIoContolの
関数で"IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX"を投げて
"成功"が帰ってきてるのにストアされるはずの値がすべて0に
なっており非接続状態と判断されてコケてるのが判明しました。
ねむいさんの知能ではlibusbxのコードをいじっても全く解決する
手立てが見つからず途方に暮れていましたが、libusb0.1系APIからの
接続やWinUSBを使っているSTLink-Utilityでは全く問題がなかったため
まさかと思ってASM1042のドライバのバージョンをいろいろ変えて
確かめているとなんと動きましたorz.
以下のファームとドライバのVerで安定動作しました(WindowsXPにて確認)。
Firmware:Version 120816-02-02-06D (V3)
Pour Windows Xp/Vista/7/8 32/64bits
Driver :Version 1.14.4.0 Pour Windows Xp/Vista/7 32/64bits
上記のファイルはStation-Driverから取得可能です。
最近出回り始めたASROCKやASUS製のマザボでASM1042がよく使用されているので、
該当されるUSB3.0ホストを使っていてうまくOpenOCDが動かない方は一度上記の
組み合わせを試してみてください。
また、救済手段としてSTLink/V2をlibusb1.0系のAPIで繋ぎに行くビルド
設定にしたOpenOCDバイナリも用意しております。ドライバの差し替えが諸事情で
困難な方はこちらを差し替えてご使用ください。
OpenOCDが0.9.0になるまで公開しておきます。
20131225追:
解決しました。こちらをご覧ください。現在OpenOCD,FlashROM,Avrdude,UrJTAGの
各バイナリにバンドルしているlibusb-1.0.dllはパッチ済なので問題なく動作します♥
20131225追:
ちょっと難ありのASM1042ですが書き込みのパフォーマンスはぴか一で
μPD720202をも凌ぎます！
さらなるドライバの改良が望まれるUSB3.0ホストですね。
wrote 34816 bytes from file main.elf in 2.359314s (14.411 KiB/s)
verified 34004 bytes in 0.265619s (125.018 KiB/s)
↑uPD720202の時のSTM32F3にSTLink/V2つかって書き込み/ベリファイ速度
wrote 34816 bytes from file main.elf in 1.734330s (19.604 KiB/s)
verified 34004 bytes in 0.109372s (303.615 KiB/s)
↑ASM1042の時のSTM32F3にSTLink/V2つかって書き込み速度/ベリファイ速度
●ねむいさんとこのFatFsのSDIOで繋げるほうのSTM32F2とかF4のサンプル使った時
SDカードに4GB超えてデータ書き込もうとするとデータが破壊されるんだが…
ごめんなさいごめんなさい！！！！
SDIOで読み書きする際のアドレスを指定する引数のデータ幅64bitに拡張して更新
しました。これでSDHCの仕様限界の32GBまで大丈夫です…SPI版はすでに対応済
なのでご安心を。
あ、しまった。
画像には見えてませんがdiskio_sdio.cもちゃんと64bit対応してます。
●Versaloon化してしまったSTLink/V2の正規のファームウエアを復活させる
おそロシア
しかも復活後もフツーにファームウエアのアップデートもできますし…
これで失敗も怖くない！？
●Connect Under Reset
STM32をつかっているときwfiやwfeを含むコードを実行するとデバッグユニットへのクロックも
停止してJTAG/SWDで繋がらなくなるのは常識中の常識ですが2013年になった
現在ではさすがに"普通に使っていただけなのに急に書き込み出来なくなった！！１！"
というおまぬけな質問される方はいなくなりました。
実際に回避する方法はJTAG/SWDにつなぎに行く瞬間にSRSTを手動で連打するという
極めて原始的な方法をお伝えしておりましたがOpenOCD0.8.0ではすでにその操作を
実行できる機構が追加されています。
具体的にはcfg内のresetの設定を以下のようにするだけです。
reset_config srst_only srst_nogate connect_assert_srst
これはConnect Under Resetというもので実はSTLink_Utilityにも同じく実装
されています。
私の配布しているOpenOCDバイナリに同梱されているcfgファイルにはコメントアウトの
形で追加していますので適宜コメントを解除して活用してください。
よく頂いていた同種のご質問に"低消費電力モードとかにするとデバッグ
できない！1!!!"という内容もありましたが、大抵はCortex-M3に存在する
Core Debug Resistersのうちの一つ
DHCSR(Debug Halting Control and Status Register)に0x07ぶち込んだら
解決する話しであるということも併記しておきます。
具体的にどうすればいいかというとCMSIS3.xx以降をお使いの方は下記の
コードをWFI();もしくはWFE();実行前に挿入してください。
ただしコアの消費電流はデバッグユニットが働く分増加しますのでご留意を。
CoreDebug->DHCSR |= 0x7;
これはDHCSRレジスタにC_STEP,C_HALT,C_DBGENビットを立てることを
意味します。
同時に立てても効果はでますがC_HALT,C_DBGENビットが立っていない
状態でC_STEP単独で立てることができないことに注意してください。
深いことは考えずにSleep系命令を含むファームのデバック時には実行前に
しっかりCoreDebug->DHCSR |= 0x7;を唱えておきましょう。
これとConnect Under Resetを組み合わせるとWFI();やWFE();を含む
コードでも安定してデバッグが可能となります。
LPC-Link2(という名のLPC4370評価ボード)を使ってみる
前回は2013/06中旬現在も謎に包まれたNxPのLPC4370が搭載されたLPC-Link2を
OSSで動かし、さらにLPC4370がトリプルコアであることまで突き止めました!
今回はまず安定してLPCLink2として動かすところから切り込みたいと思います。
もちろん今回もメーカ製のツールの事はスルーです！そもそも私のぶろぐに基本的な
使い方なんて期待して見に来ている人なんて誰ひとりいませんから…
●LPCLink2をJ-Linkとして"安定して"動かそう
さて、購入時にNxPが提供するdfutoolからJ-Linkファームウエアをダウンロード
するところからはぢめますがちょっとUSBの認識がおかしいのに気づきました。
↑たぶん正しいときのPOR
↑ちょっと変なPOR
気になってリセット波形を見るとLPCLink2上のLPC4370のreset信号のPORの波形が
微妙に違うときがありました。まさかPORの幅が短い時があるせいですか？と思い、
外付けのリセットSWを付けましたがやっぱり認識しない時は駄目。
それでVCC周りから回路をオシロでずーっと調べていたのですがそんな折にNxP
公式のconfiguration-toolがアップデートされ旧J-LinkファームのUSBがコケる問題が
あったことが判明!!つまりファームの問題！Tooooooo S**K!!
2013/05/31付けのファームと入れ替えることによりUSBの認識は安定するように
なりましためでたしめでたし♥J-Linkエミュとして使用されている方は早急にファームの
変更を行ってください。
つぎに本来の目的だったOpenOCDから使うことを目指しました。前回お見せした
通りJ-LinkファームでOpenOCDから書き込みデバッグできるのですが、たまにchain
読めずその時点でコケて上手くいかない状態が出てきました。
以下、STM32F407ZGT6に書き込みしようとした時のログです。
↓上手くいくとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Error: J-Link command EMU_CMD_VERSION impossible return length 0x7008
Error: J-Link command EMU_CMD_VERSION failed (0)
Info : J-Link JTAG Interface ready
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: 0x080450cc msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 16.062500s (39.844 KiB/s)
verified 555708 bytes in 0.656250s (826.946 KiB/s)
adapter 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)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:19↓いかないとき
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00024-g08d4411-dirty (2013-06-06-10:12)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type uknown 0x12
Info : J-Link max mem block 38488
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 58.368 TCK = 12 TDI = 1 TDO = 0 TMS = 1 SRST = 0 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 100ms
Polling target stm32f4x.cpu failed, GDB will be halted. Polling again in 300ms
Info : TAP stm32f4x.cpu does not have IDCODE
Warn : JTAG tap: stm32f4x.cpu UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: stm32f4x.cpu expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Warn : JTAG tap: stm32f4x.bs UNEXPECTED: 0xd0023bff (mfg: 0x5ff, part: 0x0023, ver: 0xd)
Error: JTAG tap: stm32f4x.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Warn : Unexpected idcode after end of chain: 33 0x209820a5
Warn : Unexpected idcode after end of chain: 65 0xffffff83
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Error: Trying to use configured scan chain anyway...
Error: stm32f4x.cpu: IR capture error; saw 0x0e not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0 in JTAG-DP transaction
Error: Target not examined yet
Runtime Error: C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg:85:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'reset' called at file "C:/Devz/ARM/OCD/tcl/target/stm32f4x_flash.cfg", line 85
make: *** [program] エラー 1
> Process Exit Code: 2
> Time Taken: 00:02J-Linkハードウエアのイニシャライズでコケているような感じはしましたが、コケ
るときとうまくいくときに規則性があるのを見つけてOpenOCDコード内のjlink.cに
切り込みました。
ソースコードを読んだ限りではinit関数の中でJ-LinkハードウエアのI/O設定を通過
する部分があり、LPCLink2によるエミュの場合はそこを通過してしまうと逆にまずい
ことが判明。
というわけでHW-Versionを読み取りJ-LinkのハードがLPCLink2エミュの場合はその
場でinit関数を抜けるようにバイパスしたところうまい具合に動作は安定化してchain
を読みに行くときにコケることは一切なくなりました！
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jlink.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
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 speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link LPC-Link 2 compiled May 31 2013 17:31:46
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 18010000
Info : J-Link hw type J-Link on LPC-Link2
Info : Vref = 3.300 TCK = 1 TDI = 1 TDO = 1 TMS = 1 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
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: 0x080449f4 msp: 0x10010000
Info : reduce speed request: 21000kHz to 12000kHz maximum
adapter speed: 21000 kHz
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 655360 bytes from file main.elf in 15.531250s (41.207 KiB/s)
verified 555708 bytes in 0.640625s (847.116 KiB/s)
adapter 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)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:17こちらの修正はすでにOpenOCDバイナリに反映しているのでLPCLink2のJ-Link
エミュでも安心してお使いいただけます。自前でビルドされる方向けにパッチ群も
更新しておきました。
UrJTAGも類似した箇所でコケているのでこちらも調査/修正を
20130620追：
UrJTAGも修正掛けました！
所でLPCLink2をJ-Linkとして動かすとNxPのチップにしか使えないはずなのですが
STM32やFM3とかにもOpenOCDからバリバリ書き込み/デバッグが出来てます。
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら6月上旬の時点でNxPFanﾘﾝｻﾝに〆られてますし。
20130709追:
ライセンス制限が追加され、NxPのデバイス以外で使用を禁ずると明記されました。
OpenOCDからSTM32やKinetisやFujitsuやAtmelのARMマイコンに無制限に書き込み/
デバッグできますが、もう絶対にやってはいけません！やるなよ！絶対にやるなよ！
●LPCLink2をLPC4370評価ボードとして使う
こっからが本懐です！たった2000円と少しでトリプルコアLPC4370が搭載された
マイコン評価ボードが使えるのですから…！
前回のUrJTAGによりコアが3つあるMPUということが判明しています。同時に
LPCLink無印の時みたいにMCUのセキュリティは全くかかっていないのが分かった
のでJTAGkey2でやりたい放題にできちゃいます♥
LPC4370がLPC4350の機能拡張版なのを推定し、LPC4330-Explorerの時に使った
サンプルをLPC4370向けに作り変えてみました。ひとまずM4のみのシングルコア
動作です。
ビルドしたバイナリはボード上にあるSPIFI-SPIROMにプログラムを書き込みます。
ここら辺の操作はLPC4330の時と同じですがspifiブートはリセット2回でコケる
errataは無いのでへんてこなOpenOCDのcfgは書かずに済みます
…しかしLPCLink2上のSPIROMは、openOCDのSPIFIドライバに対応していなかった
のでこちらも対応させました…と言っても単にSPIROMのIDとセクタ/容量を追加
しただけです。
↓OpenOCDのログはこんな感じです。もちろんOpenOCDバイナリ・cfgファイル
は上記の修正を反映済です。M0コアが2つ、M4コア1つが見えますね。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/jtagkey2.cfg -f target/lpc4370_lpclink2_spifi.cfg -c "mt_flash_bin main.bin 0x14000000"
Open On-Chip Debugger 0.8.0-dev-00037-gc60deb5-dirty (2013-06-14-23:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
cortex_m3 reset_config vectreset
none separate
adapter speed: 2000 kHz
Info : clock speed 2000 kHz
Info : JTAG tap: lpc4370.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4370.m0_0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : JTAG tap: lpc4370.m0_1 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4370.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4370.m0_0: hardware has 2 breakpoints, 1 watchpoints
Info : lpc4370.m0_1: hardware has 2 breakpoints, 1 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
background polling: on
TAP: lpc4370.m4 (enabled)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
Info : Found flash device 'win w25q80bv' (ID 0x001440ef)
cleared protection for sectors 0 through 15 on flash bank 0
auto erase enabled
wrote 65536 bytes from file main.bin in 0.953125s (67.148 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x1400350a msp: 0x200029a0
cleared protection for sectors 0 through 15 on flash bank 0
verified 4656 bytes in 0.031250s (145.500 KiB/s)
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target lpc4370.m4 failed, GDB will be halted. Polling again in 100ms
Polling target lpc4370.m4 succeeded again
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:03上記のログで"Warn : Invalid ACK 0x7 in JTAG-DP transaction"が
出ていますが、これはOpenOCDから直接レジスタを叩きcoreresetを掛けて
いるために発生しているので実害は全くありません。
↑いつものデバッグも自由自在です(LPC4370の素性がわかる範囲で)
ひとまず問題なく動くと思われるLPC4370のプログラムをこちらに置いておきますので
物好きな方は試してみてください。最初に述べた通りLPCLink2は余計な
プロテクトは全くないので失敗を恐れずいろいろ試すことが出来るので、
なかなかいじりがいがあるボードだと思います！
いろいろ試す18
GW中は副業(本業は虹裏メイド)が糞ほど忙しかったのですがおかげで給料も
貯ま…るわけがなく円安を迎えた今はひたすら安価な小物や以前に買った
物をただひたすらに消化していきまっす！
●秋月さんとaitendoさんのi2c液晶キャラクタ液晶モジュール
ぇ？昔i2c液晶の記事書いてたやんだって？さぁ？何のことですか？
これのこと？これはキャラクタじゃなくてドットマトリクスですから別物です別物！
…さて、ホビー用途では配線の手軽さから不動の地位を確立したi2c液晶ですが
秋月さんから安価なAQM0802A-RN-GBWが発売され私もi2c液晶でびぅです♥
コントローラはST7032iというi2cインターフェースに特化したものだそうです。
BOLIMYINの提供していたサンプルのおかげで危なげなく表示出来ました！
お次はaitendoさんから販売されているバックライト付きで破格のi2c液晶たちです！
もう基板に組み込んでますが、秋月さんのと同じくST7032iのコントローラICで
簡・単・表・示…
…と思いきやO-Familyさんも遭遇したF**Kな不具合にねむいさんも遭遇し,"i2cバス
リカバリ"の重要さを思い知らされる羽目になったのでした…
(※STM32F4のFatFs実装例ではすでにi2cバスリカバリのルーチンを実装しております)
これについてはいずれ解説するであろう"i2c液晶を使ってみる"でみっちりと…
●OZSSとGLONASS対応のGPSモジュール Gms-g9
去年の冬,Gms-g6aというMT3333が乗ったモデルを使用していましたが、チップ
アンテナを使用しているため、せっかくの新モデルなのに初回補足時間/感度は
あまりよろしくありませんでした。
4月末に某送料が安い方の欧州店でパッチアンテナモデルのGms-g9が
ようやく販売され、遅ればせながら私もｹﾞｯﾂした次第です。
既に使用されている方のレポートによれば消費電流もPA6Cよりはちょっと多い
(GLONASSの処理があるから)ものの十分控えめなのでSTM32Primer2のロガーと
組み合わせても私のトレラン用途には全く問題ないようです。私はすでに
Gms-g6aで予習していたのでロガー側もGN系センテンス対応済みでそのままPA6Cと
差し替えて試せそうです。
というわけでいつものユニット化してみました。いちばん右の黒いのがGms-g9です。
PA6Cよりもパッチアンテナの面積が広いので感度はさらに上がっているでしょう。
あいにく今週から梅雨に入ったのでPA6Cとの比較試験は来週以降、トレランでの実践
投入は6月末を実施予定としています。
●ILI934x Mystery
SPIモードでDeviceCodeの読み出しができるようになるまでのお話。
Seeedstudioの中の人がいかにしてデータシートに記載されていない複雑なコマンド
体系を見つけだしたのかはいまだに謎
それとねむいさんの英語力に突っ込みを入れないように！！！
●LPCLink2
LPCXpressoに密着していたLPCLinkはirukaさんの解析によると変更不可能なOTPに
よって機能が限定されており外部から全くhackすることが出来ずどっかのSTM32では
出来たDiscoveryでVersaloonが出来ないじゃない！と判明しごくごく一部の解析大好きな
好事家からはったくNxPはｾｺｲな!とスル―してｹﾞﾌﾝされておりました‥
が、
今回デバッガハードウエア単体として販売されたLPCLink2は回路図全公開、さらに
ファームウエア変え放題でしかもCMSIS-DAPやJlinkファームウエアまで用意している
という超太っ腹なボードとなっておりました！
ねむいさんも秒速で入手しその威力を早速試してみました…
電圧変換は前回紹介した74LVCxTx45系が使用されています。LPCLink2ではDIRを
入力に切り替え疑似的にOD化し、1.2〜5.5Vの非常に幅広い電圧範囲をカバー
しているようです。
…LPC4370…？
ねむいさんの目的はJ-Linkです。ほかは一切視界に入れません。THE・シカトです。
そっこう中身のファームをDFUでJ-Linkにしようとしましたがホントの最初はドライバ
不要のHIDローダーで認識されDFUをさらに読み込むようです。この時にDFU用の
WinUSBドライバを読み込ませていないとJ-Linkへのアップデートに失敗するのでご注意を。
WinUSBドライバを読み込ませてこれでJlink化完了！
…ぇっとOpenOCDとかで使ってみましたが‥JTAGKey2と比べるとワンテンポほど
反応が遅くてちょっと微妙な感じです。無理にOSSで使うよりSegger提供のツール
使った方がいいかもしれません。ファームウエア(spifiに格納される)はいくらでも
書き換え出来るのでいろいろやってみましょう。
…そう自分で作成したプログラムも…
20130603追：
やっぱりJlinkエミュレーションのファームヤバかったようで
修正版が2013.05.31にUpしてます…。
で、LPCLink2にはTargetのJTAG端子のほかにLPCLink2の心臓部のLPC4370からも
JTAGが引き出されています。LPC4370って検索しても2013年5月末現在は詳しい
資料全く出ていないしLPC4350系のメモリ多い版かしらと思って何気なくUrJTAGで引っ掛けて
みると…
なんとコアが3つありました…
CortexM4とCortexM0が2つの合計3コア…
トリプルコアなの！？
次回に続く！！
Amontec夜逃げ記念☆JTAGKey2互換回路をもっと使ってみる2
20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。
自作される場合はこちらを参考にしてください。
下記の記事はもはや内容が古く、正確ではありません！！
20150514追:
数年前、FT2232Hを利用したJTAGkey2Cloneの紹介をしました。しかしちょっと自分で
も回路上で疑問を感じる点が多く、かねてから再製作の構想は考えておりました。
昨今のロジックICの性能向上も相まって2013年の今、再び満を持しての再製作となり
ました…最初に書いたのもう3年前か…もう3年も経ったの…さんねんも……
ｹﾞﾌﾝ失礼、前回は単に回路図と実に抽象的な使用例を紹介しただけでしたが今回は
どうしてそういう部品選定or回路に至ったかのねむいさん的ポリシーも述べます!
●肝心な回路図は…
実は少し前から公開していたのですが…以下のリンク先"JTAGKey2"のディレクトリ内
にあるpdfファイルが新しいJTAGKey2互換回路の回路図となります。
FT2232Dを使ったJTAGKey無印の互換回路も2009年当初のままですが下記リンク先の
"JTAGKey"のディレクトリに収録していますので同じくご参考までに。
JTAGKey or JTAGKey2Compatible Circuits
神木さんのJTAGKey2互換を参考にして作ったねむいさんのJTAGKey2互換を参考に
して作ったjujurouさんのJTAGKey2互換を参考にした最終形です！
そして以前使用していた"Clone"という単語は以下の理由でそぐわないのでもう使わ
ないようにしました。これからは"互換(Compatible)"で統一といたします。
●オリジナルのJTAGKey2との差異
夜逃げしたAmontecから販売されていたJTAGKey2純正品とは機能面で差異があります。
1．暗号化EEPROM(DS2432)の有無
これはオリジナルではFT2232のB側のバスのどれかに接続され、Amontec社が
提供しているamthal.dllはここから書き込まれた情報を読み出し正規品判定を
行っています。
digilentの"JTAG HS-1"もそれと似た仕組みで判定を行っているようです。
2. LEDインジケーターの設定
ねむいさんのJTAGKey2CompatibleのLEDの設定はJTAGKey無印をベースに
しています。JTAGKey2で変更になったLED表示とは全く合っていません。
3. Lattice-ISPVMの使用可否(OE強制制御)
Lattice"さん"提供のISPVMは数年前にFT2232系デバイスからでも書き込みが
できるように神対応をして下さいました！！しかし純正のJTAGKey2からはOEの
手動コントロールが不可能(MPSSEを強制直結状態にできない)のため蓋を
こじ開けてジャンパを飛ばさない限り使用不可能です。
OpenOCDやUrJTAG等のフリーなツールでは純正/互換品に関わらず同じ"JTAGKEY"
として扱われるのでまったく問題なく使用が可能です♥
●回路解説
いくつかのブロックに分けて主要部の解説をします。
1.FT2232H周辺
JTAGKey2互換初号機と同じくDLPDesignのDLP-USB1232Hを使用しています。
面倒なUSB-HS周辺やFT2232系で必須なEEPROM等の周辺部品を搭載し
モジュール化されており非常に簡単に扱うことができます。
今だとUM-232H等のFT232Hを使ったモジュールなども使用可能と思われます。
ただTx/RxバッファがFT2232Hよりも少なく処理速度に影響しますので、
その点はご留意ください。
2.電圧変換(電圧レベルトランスレータ&バッファ)
JTAGKey2互換回路の心臓部です。ここで+1.4V〜+5.5Vまでの幅広いターゲット
電圧に対応します。前回は+1.65Vからでしたが昨今のロジックICの性能向上に
伴いサポートされる電圧範囲の保証される下限がさらに下がりました。
それ故に型番どころか製造メーカ指定まで必須となります。ねむいさんの
ぶろぐ見てる人は同じ74シリーズの同型番でも製造メーカー間で性能が
微妙に違うという昔からよく知られている事実は常識中の常識のはずなので
理解していただけるかと思います。
DIODES Inc. Semiconductor の74LVCE1G125"、
Nexperia(旧NxP)の"74LVC2T45DC"を指定して使ってください。
他メーカーの同型番は駄目です！
また、各バッファICに繋がりFT2232Hから制御されるOEの制御線は必ず+5V
(回路図中ではVbus)で攣ってください。JTAGKey2をPCと接続したときの
これらは入力/Lo出力の疑似的なOD扱いで制御するPC側アプリが多く、
+5V系で攣っていないと+2.5V付近の中間電圧が掛かってしまい動作不良の
原因を作ってしまいます。
jujurouさんが指摘していた+5V系の動作の考察についてはさらに掘り下げて
別枠で考察させていただきます。
3.ターゲット電圧検知
こちらに関してはJTAGKey互換のころと同じく元NEC現ルネサス製のデジトラを
使用しています(ねむいさん的定番部品です)。
↑Rev.4でルネサスを排除しました。使い勝手良かったのですが…さらばFB1A4M。
代替としてROHMのデジトラDTD123YKT146を指定しております。
↑Rev.5に回路が変わりました！
4.OE強制制御
切り替えスイッチで無理やりバッファのOEをGNDに落としてMPSSEで使用される
ポートをターゲットと常に直結状態にします。これは上述のとおりLatticeのISPVM
やデバッグ用途で活躍します。3Pの少信号用SWならなんでも使用可能です。
●実際に組んでみよう
今回はアイテムラボさんのパワーメッシュユニバーサル基板を採用しました。
本来ならVCCに使うべきレーンもすべてGNDに割り当て高速信号の扱いを意識して
配線を行いました…行 っ た つ も り で す ！ ！
前回はFT2232Hのモジュール上部が吹きさらしで打撃を喰らいやすい危険な
構造でした。今回からアクリル板を加工して屋根を設けました。
いい感じですね♥
10MHz越えの高速信号を外に引き出すので信号線とGNDが交互に来るフラットケーブル
は必須です。さらにSEIWA製コの字型フェライトコアを設けて外来/輻射ノイズを殺す
ようにしています。
もともとチップバリスタも基板上に実装するつもりでしたがフェライトコアだけで
100V/1uSecのインパルスノイズ耐量試験を余裕でpassしてしまったのでチップ
バリスタは未実装のオプション扱いにしました。
一からJTAGKey2Compatibleを作る場合は初めにPCと接続したときにVID/PIDが
FTDIの素のFT2232Hとして認識されます。FT2232Hモジュール上のEEPROMに
データを書き込むために先ずはFTDIのドライバを認識させてください。
JTAGKey/JTAGkey2製作用に特別にinfに書き加えたものを用意しましたので
必ずこちらを使用してドライバを読み込ませてください。
2じゃない方のJTAGKeyを作りたい方もこのドライバを使用可能です。
JTAGKey2Compatibleとして動かすためにはEEPROMのデータを書き込んで
化かさなければなりません。従来はMProgを使用してデータを書き込むように
していましたが、現在はFT_Progに統一されましたのでこちらを使用してEEPROMに
JTAGKey2になるためのデータ(xml)を書き込みます。
上のドライバにはJTAGKey/JTAGKey2用のxml
データもJTAGKey_XML.7zとして収録していますのでこれを使用し書き込みを行って
ください。FT_Progの使用法についてはFTDI公式のマニュアルを参照のこと。
書き込みが終わったらUSBケーブルPC一度抜いてさし直してください。成功したら今度
は"Amontec JTAGKey2"として認識されます。
その後はlibusb系を使いたい場合はおなじみZadigでインストールを、FTDIのドライバを
使いたい場合はそのままとしてください。
注:LibUSBKはドライバの入れ替え無しに0.1系と1.0系APIが同時使用可能な便利な
ドライバですがWindowsXP下ではあらかじめ0.1系のドライバをインストールし
ていないと動作が不安定になるようです。一度0.1系でインストールしすぐに
LibUSBKに戻せば問題なく使用可能です。この操作もZadigを使うと楽ちんです
製作したJTAGKey2の動作確認を簡単にしたい場合はOpenOCDよりもUrJTAG
が便利です。ターゲットデバイスに接続して"cable jtagkey"->"detect"の
たった二つのコマンドでJTAGチェインが見えればチェック完了となります。
さらにpodコマンドでSRST,TRSTを含めたJTAGの信号線単体の個別コントロールも
可能なのでトラブルシュートにも役立ちます♥
●ちょっとしたデザインレビュー
20150512注:
以下の検証はRev.4以前のモロが問題だった頃の回路の内容です。
Rev.5にてオリジナルJTAGKey2のサポート電圧範囲に忠実になりましたので
現在はモロで問題有りません。
20150512注:
さて、実際に信用に足るJTAG用デバッガとして使うためにはいくつかクリティカルな
条件を設け試験する必要があります。JTAGkey2互換回路では大きく分けで2つの考慮
すべき点があり、どちらも回路図中の電圧レベル変換ブロックに集中しています。
1.電圧入力レベルに関する点
FT2232HのI/Oの電圧はMAX30Mbpsの高速信号を扱うため+3.3V系のLVTTLと呼ばれる
電圧レベルで固定化されています。(FT2232D系だと3.3V〜5Vで可変だったのですが)
これを考慮してかFT2232Hは+5VI/Oトレラントとなっており+5V系の入出力に対して
耐性を持っています。ですのでFT2232Hの+3.3V出力に10kohmで+5Vにプルアップ
する程度の衝突ならびくともしません
(この荒業は疑似的なOD制御の時に役に立ちます)。
また、SRST,TRST,JTAG各信号線のゲーティングをしているバッファICのOE端子は
FT2232H側が疑似的にOD出力の形で操作しているため、常に+5Vで吊るのが正しい
です。(FT2232H,74LVCE1G125,74LVC2T45のいずれも+5Vの入力トレラントを持つ)
本回路中で使用されている74LVC2T45DCは+1.2〜+5.5V,74LVCE1G125は
+1.4〜+5.5Vまでカバーしており、何れも+5V入力トレラントも保証しています。
つまり+1.4〜+3.3Vまでの回路の場合は電圧入出力とも全く問題はありません。
しかしターゲットが+5V系のケースでは74LVCE1G125のHレベル入力下限(3.5V)を
満たしません。
こちらについてはjujurouさんの情報をもとに74AHCT541(※)を挟み、
LVTTLから+5VCMOSの電圧変換を行うことによって電圧レベルの問題は一旦は
解消としました……しかし…
(※…NxP製の物は74AHCT541と74VHCT541の特性は全く同じ)
2.信号の伝達遅延に関する点
74AHCT541を挟んだことによって同素子内部のゲートを通過する際の遅延が余分に
追加されることになりますが、最初に組んだときは204MHz動作のLPC4330と
TCK=15MHzで接続し、周囲温度も十分振って安定して書き込みデバッグできたので
問題なし！としていました。
ですが純正JTAGkey2がサポートしてるのが30Mbpsだったのを思い出し"本当に
30Mbpsで通信できるのか？"と感じ、購入後放置していた公証80MHzまで使用可能な
SPI-ROMSST25VF032B-80-4I-S2AFとFlashROMを使ってTCK=30MHzで読み出し
試験してみました。
が、リードしたデータがすべて1bitずれた状態となってしまい玉砕orz
…というわけで真面目に伝達遅延の影響について考察を開始しました。
ターゲット電圧3.3VでTCK=30MHzで通信した際に一クロックサイクルは33.33nSec
であり、FT2232HのTCKからでたクロックがターゲットのTCKに届き、それに準じて
ターゲットMISOからの出力とFT2232HのTDO(SI)に届くまでの時間の合計が
33.33nSecを超えてしまうとビットシフトした状態でデータが取り込まれアウトに
なってしまいます。
データシート記載の使用温度環境-40~+125度で動作させた場合(データシート上で
明記されてないものは一番条件が絞れてる温度範囲)のパラメータを抽出して計算
すると上図のように33.33nSecを余裕で超える遅延が発生することになり74AHCT541
を挟むと30Mbpsの通信が理論上ですら不可能なのが判明orz
74AHCT541を省くと7.0nSec分遅延がなくなるため30MHzでもビットシフトは
起こらない計算になり、実際に74AHCT541を省いたモロにするとSST25VF032Bと通信
(DeviceIDの取得,書き込み,ベリファイ)が問題なくできることを確認しましたorz
やはりモロでなければだめだったのですorz
それと配線の引き回しも非常に重要です。10cmを超えるような引き回しをすると
上記のモロでも駄目でした。また、FT2232Hモジュールからレベル変換ICを何も
挟まないガチの直結も試しましたが10cm以上を超えるとやっぱりだめです。
30Mbpsで安定して通信を行うためには高速クロックで動作する回路を意識しないと
いけませんね。
PicoScope3206AでTCKの波形取得してみましたが74AHCT541付きの波形は
見るからにちょっときつくなってますね…。
↑15MHzの時のSPI-ROMのTCK波形(74AHCT541付)
↑15MHzの時のSPI-ROMのTCK波形(モロ)
↑30MHzの時のSPI-ROMのTCK波形(74AHCT541付)
↑30MHzの時のSPI-ROMのTCK波形(モロ)
ここでちょっと疑問に思ったのですが市販のFT2232H系のJTAGハードウェアは
本当に30Mbpsで動かせられるのか？という点です。10MHz以下までTCK速度を
落とさないとOlimexのARM-USB-OCD-Hでは安定して書き込みできないという報告
もあり、もしかしてそれらはレベル変換にFT2232D系で使用されていた低速な
LV系バッファが使われ続けているのではないのかと訝しんでしまいます。
純正のJTAGKey2ではどうなんでしょ?？さすがにできるはずですが…???
3.モロへの誘い
で、ここで74AHCT541外したら3年前作ったのと全く同じじゃん！
とお思いの方が多い筈です。
それは引っ込みがつかなくなったねむいさん本人が一番強く感じています。
というわけで癪なのでモロで動かしたときに+5V系で本当に問題が
ないのかの実力検証を行いました。
使用MCU:
->ATMEGA1284P
動作電圧:
->+5.65V
(安定化電源にてAVRの推奨上限+5.5Vにさらに+0.15Vのマージンを加える)
試験環境温度:
->-15度~+70度
(-15度はコールドスプレーでJTAGKey2互換回路基板上をくまなく冷却,
+70度はドライヤーで同基板上をくまなく加熱)
試験内容:
->試験環境温度下でATMEGA1284pにOpenOCDを試用しJTAGモード(TCK=10MHz)
で100kByte程のプログラムの書き込み動作を行いその動作中にJTAGの
通信エラーやフラッシュの書き損じが一切出ないことの確認。
JTAGモードにした理由はAVRの場合はコア電圧/クロックに関わらず10MHzの
高クロックでAVR内のOCDブロックとの通信が可能なためです。
結果:
->全く問題なし。
現行のAVRドライバはread動作を行うとOpenOCDごと落ちるｽﾃｷ仕様なので上記
環境下でJTAGKey2をISP端子につなぎ変えたうえでAVRDUDEにてISPモードで
読み出しを行い、さらに読みだしたhexをOpenOCDでJTAGモードでフラッシュの
全領域消去->書き込み。
そこから再びAVRDUDEでISPモードで読み出しを行いhexファイルの完全一致の
確認をもって問題無しと判断しました。
てわけで電圧/温度/TCK速度とも一番厳しい状況を作り試しましたが全く問題は
ありませんでした！試験で使用したOpenOCDはatmega1284pのフラッシュ書き込みに
対応させた奴使ってます。ログは↓こんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/atmegaxxx4p_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.8.0-dev-00011-g70a2ffa-dirty (2013-05-11-14:47)
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 speed: 10000 kHz
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
adapter_nsrst_delay: 100
verify Capture-IR is disabled
Info : max TCK change to: 30000 kHz
Info : clock speed 10000 kHz
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
auto erase enabled
Info : device id = 0x1970503f
Info : target device is atmega1284p
wrote 113408 bytes from file main.elf in 4.453210s (24.870 KiB/s)
Info : JTAG tap: avr.cpu tap/device found: 0x1970503f (mfg: 0x01f, part: 0x9705, ver: 0x1)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05同じくAVRDUDEはFT2232系MPSSEに正式対応した6.0RC1をビルドして使用
しております。JTAGKey2があれば難しい設定もワークアラウンドも必要なく
ARMもAVRも余裕で書き込みできるようになっていい時代となりました♥
+5V系でAHCTバッファ挟まなくても問題なかった理由は、74LVCE1G125のVthが
実際は中間電位の+2.5Vで切られていてそれさえ跨げばちゃんとレベルが遷移
できていたからと推測します。データシート上の規約におもいくそ違反して
ますが実力/マージン共に十分あることが確認でき自分が理解して使用する
範囲ならモロでも全く問題なしと判断しました。
(↑売り物の製品の設計の時はちゃんとデータシートに記載された
指示/定格をすべて守ったうえでみっっっちり動作テストを行うのが大前提です！)
もちろん保証の範囲外なので、他のメーカの同種型番のIC等では入力に
ヒステリシスが設けられて全く動かないかもしれません。真似して製作される
方は回路図中でねむいさんが指定したICを必ず選定してください。
｢違うメーカのレベル変換ICをどうしても使うんだーぃ！｣という方はご自身で
動作検証を念入りにした上で使用してください！！！！！！！
念入りというのは回数だけ無意味に重ねるだけではなく温度と電圧くらいは
最低限振れという意味です。ベストな環境だけで満足すると
後で絶対にしっぺ返しがきますから…。
ということで74AHCT541はオプション扱いにとどめ、TCK=15MHz以下でしか
使用しなくて電圧的に心配な人だけ付けてね！ていう風にして冒頭の回路図に
最終的に落ち着く運びとなりました。めでたしめでたし。
20150210追：
+5V系の時の74LVCE1G125の挙動をもう少しガン掘るトしてみました。
VCC=+5.5Vにして入力をわざとゆっくりと上げ下げした時に実際に何Ｖで
出力信号が遷移するかという実験をしました。
先ずは立ち上がり。2.5Vできっちり信号が変化しだしているのが分かり
ますね。2.5V以降の途中で波形が乱れている件は後で解説します。
お次は立下り。こちらも2.5Vで信号が変化しだしています。
本来ならばCMOSロジックの場合はVthはVCCの中点で本実験の+5V系上限値
+5.5Vの場合は2.75VになるはずですがLoレベル寄りの2.5Vとなっていました。
実際に使われる+5.0Vで換算すると74LVCE1G125の真のVthは2.27V付近となる
ことが容易に分かります。FT2232Hの+3.3V出力直結モロでもドライブ能力を
十分に強化して電圧降下を起こさなければVthをまたいで1V近くのマージンを確保
できるので電気的には全く問題がないことが分かります
(※FT2232HのI/Oドライブ能力を最弱の4mA設定にしても30MHzでぶん
回しても問題ありませんでした)。
そんな訳でホビー用途ならAHCTバッファ無しのモロで十分であるという結論と
させていただきます。逆に売り物にする場合は今回のロジックICに限らずデータ
シートに記載されている事項をすべて守った上で周囲環境条件を十分に振って
みっっっっちり
テストしまくって最終的にどういう仕様に落とし込むかを慎重に決めてください。
大切な事なので二度言いました。
｢ねむいさんのぶろぐに書いてある通りに作ったおれはしらん｣とかいう奴に
エンジニアの資格は無いです。
また両者の波形とも遷移直後に大きく出力波形が乱れていますがこれは入力
スルーレートの規約(5V時5ns/V)に違反しているからで、遅すぎる速度の入力に
よって発振が起こっています。上記の測定結果は入力をオープン(殆どのケースで
中間電位になる)にしていると出力が発振を起こして予期せぬ誤動作に繋がる
という重要な事柄も示しています。
CMOSの入力は吊るか落とすかどっちかはっきりと！
最後にスルーレート規約も守ったうえでVCC=5Vで3.3Vドライブした時の波形の
例を。VersaloonのSWCLK波形を入力にしています。
ご覧のとおり問題なく電圧の遷移が出来ていることが分かりますね。
いろいろ試す17
試"す"というか試"した"結果のご報告の方が多いかも…
●STM32F437シリーズの予習
2013年4月中旬現在はまだチップ単体は手に入る時期ではないのですが
去年買って放置していた超格安全部入りボードを使用して来たるSTM32F437シリーズの
予習をしていました。
ただこれに付属しているTFT-LCDモジュールのタッチパネルドライバICが定番の
ADS7843ではなく、I2C接続のSTMPE811というI/Oエキスパンダと温度計も一体化
された妙に"いんてりじぇんす"なICだったのでそれの対応に非常に苦労しました。
↑画像は春になり発情期を迎えたいないさn
とりあえずいつものが動かせられるようになったので同じ基板を購入した人たちは
無改造で追試できると思います(TFTLCDのドライバはILI932xを選択の事)。
I2Cバスエラー対策はまだ実装していませんので、フン詰まりになったら電源を
いったん落とした後再投入して対処してください。(やっけつ)
また今回はタッチパネルの処理の上位層も少し見直して無駄な記述をしていた
箇所や分かりづらい箇所を廃しております。たとえば、
キャリブレーション画面で青の■をしっかり押せたら…
黄色の■になる！…もちろんこれだけではありませんが細かいところも修正してます。
せっかくなので全体的にソースコードも見直してコメント等をできるだけ随所に
挿入して、プログラムの流れもつかみやすくなるよう努めるようにしました。
本来は書いた本人がプログラムの動作に関する詳しいドキュメントを書くべきなの
ですがこちらのかたが非常に分かりやすい解説をして下さっており、ねむいさんも
いつも参考にさせてもらっていま…あれ？
今回の修正はおきぱにあるSTM32F1,F2,L系のものを始め他社のARMマイコンのFatFs
移植例にも順次反映していきます。
●STM32F4で外部SRAMを使う
ねむいさん非常におまぬけなミスをずっと放置しておりました。
STM32F4向けのいつもののプログラム中でターゲットボードにREDBULLを指定した
場合は外部SRAMを使用できるようにFSMCの設定を行っていたのですが…
REDBULL上ではキー入力も同時に有効にしておりそこのGPIO設定がでたらめ
だったためFSMCのポートにもそれが波及し外部SRAMへの特定の
アドレスのアクセスで頻繁にHardFaultっておりましたorz
一見まともに動いているように見えたので気づくの遅れましたorzorz
今回のソースコードの見直しではぢめて気づきましたorzorzorz
というわけでそこを修正して大容量のSRAMをmalloc系関数のheap領域として
使えるようにして、(さすがに内部SRAMと比べると非常に速度が遅いうえに
マトリクス化されていないのでスタック領域までは割り当てる気がありません…
F4はCCMあるし)これでメモリサイズを気にせずに自由自在に使えるようになった！
…と思いきや、16bitのアラインメントが乱れるようなアクセスが連続で続くと
やっぱりコケます。
これはlibjpegで画像をデコードするような時に特に顕著になりこのように
途中で表示がグレーになったストール状態に、虹裏で見られる富山みたくなって
しまいます。
↑libpngとgiflibだとこの現象一切起こらないのですが…調査はいずれまた…
また、FSMCのバスにSRAM以外に入出力容量の大きいブツ(低速でしか動作できない
一昔前のTFTLCD等)がぶら下がっているとやっぱりこけます。オシロでWRの波形を
見たらオーバーシュートしまくりです。なのでTFT-LCDも影響を与えないものを
オシロの波形とにらめっこして選ぶ必要があります。もしくはFSMCに影響を与えない
SPI接続のLCDの選択も考えてください。
ねむいさんが試行した限りでは16bit区切りになるような、たとえばVRAMとして
16bitにパックされたRGB565のデータをスタティックに確保しただけの状況下の
使用では問題は一切発生なかったのでこの先も慎重に確かめてみます。
●LPC4357全部載せ基板
RMBレートが13円のころに買っておいてよかったです♥USDも99円(20130411現在)
まで回復してますが海外のパーツ・基板漁りはひとまずお休みして買いためたブツを
消化して逝きましょう先ずはNxPのCortex-M系最高峰のLPC4357のボードです！
(2013年01月中旬当初は国際送料込みでなんと13000円台で購入できていた超格安な代物でした。)
以前LPC4330というLPC4300系の基板をいじっておりましたがあっちはプログラムを
格納するフラッシュ領域が全くなく、スズメの涙ほどの内蔵SRAMか低速な
SPIFI-SPIROMから実行せざるを得ない非常に使いづらい代物でした。
しかしこいつは違います！204MHz動作でフラッシュも1MB内蔵なので使い勝手が
改善されて(ると思い)ます！…しかし…
…
4.3inchLCD基板の接合部でみてはならないものが目に入ってしまいました…
…なんだこの隙間は…これのせいでベースの基板もひん曲がってるし…
(後日このヘッダピンを半田槽で外し新しいものにまっすぐ付け直しました)
通電すると動作確認用のサンプルプログラムが起動します。またOpenOCD用の
cfgを作っていませんがLPC4300系のフラッシュ書き込みルーチンもまだ
レビュー段階なので先ずはそこから基礎を固めて試してみましょうか…！
(逆さになった何かを無視しつつ)。
●OpenOCDをさらに使いやすく
年明けくらいからでしょうか、ねむいさんが提供しているOpenOCDバイナリを
STLink/V2から使用する際にドライバをLibUSBからではなくSTMicro提供の
純正ドライバを使うように変更できないだろうか？というご要望をちらほら
いただくようになりました。
まさかとおもってSTMicro純正のドライバをよく調べてみると、Windows向け
ドライバとしてWinUSBが使用されているのがわかりました。
また去年行ったFT2232系FTDIデバイスのMPSSE対応の際にWinUSB(LibUSB-1.0)用の
ビルドができるようになっていたのですが、STLink/V2に関してはVersaloonと
同じくLibUSB0.1系を使用するようにビルドオプションを指定したままになって
いたので純正ドライバは使用できない状態でした。
今となってはWinUSB(LibUSB-1.0)を使用しない道理は存在しないのでSTLink/V2の
ドライバとしてWinUSBを使用するようにビルドオプションを変えて純正ドライバを
そのまま利用できるようになったバイナリを現在は提供しております。
ST-LinkUtilityなどの純正ツールとOpenOCDがドライバの差し替えなしに利用
できるようになったのでぐっと便利になっております。
そのかわり従来のLibUSB0.1系から使用できなくなりますのでご注意ください。
↑一応変更当時はトップにでかでかと告知してたので皆さん移行済みかと思います
追：
ドライバの扱いについてちょっとまとめます。
LibUSB-1.0：WindowsにおいてはWinUSBのラッパーとして働きます。
ですのでLibUSB-1.0のAPIを使いたい場合インストールするドライバは
WinUSBとなります。WinUSBのKMDFを使用しています。
LibUSB-0.1：WindowsにおいてはLibUSB-Win32と呼ばれ、LibUSB0.1(libusb0)の
APIはWDMを使用しています。
LibUSBK ：WinUSBのエミュレーションとして働きますが、WinUSBでサポート
してないアイソクロナス転送も使用可能です。
また、libusb0のAPIとも互換性があるのでLibUSBKをインストール
しておくと1.0系と0.1系APIを使うアプリがどちらもドライバの
入れ替え無しに使用可能となります。
さらにFT2232系デバイスの方もZadigでインストールする際にLibUSBKを選択
することによりWinUSBを使うOpenOCDやLibUSB0.1系を使うUrJTAG/FlashROM
などの便利ツールがドライバの入れ替えなしにシームレスに利用できるようになり、
低いコストと簡単な手順で強力なデバッグ環境をそろえることが可能となって
おります♥
●aitendoさんのanux
>ANUX続けるのやめまーす(←peep.usでページを保存しました)
こ ん な こ っ た ろ う と お も っ た で す よ ぅ ！ ！
そうだねチャイナリスクです…せめて全回路図くらいPDFでくだち…
Kinetis Lシリーズをつかってみる2
20161123追：
FreeScaleはNxPに喰われました！
え？これは何って！？
さぁ…あ、あたしの弟がぁ…かってにぃエントリしちゃって〜
ま、まぁねむいさんセフィロス派ですがmbedには話のタネにちょっと
登録してみただけですよぅ〜
mbed/Arduinoのようなハード・ソフトお仕着せ環境はねむいさんは興味は
ないだけで、そもそも否定はしておりません。それよりもそれぞれの
やりたいことが素直に実現できてそれぞれが面白いと感じたプログラミング
環境をそれぞれが見つけ出し、素晴らしい製品・作品をつくっていくこと
こそが最も重要なことだとねむいさんは声を大にして申し上げさせて
いただきます！(ただしcygwinと素のEclipseは仏敵)
さて戯言はこの辺にして、今回は前回のKL25に続きさらに機能がシンプル化された
KL05シリーズが搭載された評価ボードFRDM-KL05Zを紹介したいと思います。
この子はKL25ZのものよりもさらにArduinoを意識した作りになっていて"シールド"も
+3.3V互換のものなら搭載できるようになっているようです。
とはいえそっちはほとんど興味なかったので前回OpenOCDに突貫で実装したKinetis-L
ドライバがちゃんとほかの品種でも書き込みできるかの実証に移りました。OpenOCDの
バイナリ見られた方は知っているでしょうけど、結論から言うとKL05Zにも問題なく
書き込み・デバッグ出来ることを確認しました。
↓Versaloon+OpenOCDで書きこんだときのメッセージです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/kl05z_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00204-g1da9e59-dirty (2013-03-25-10:47)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank kinetis pflash
adapter speed: 1000 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Mar 4 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : Found SWD-DP id:0x0BC11477
Info : kl05z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20000c00
Rize up to Internal PLLed Clock!
auto erase enabled
Info : Probing flash info for bank 0
Warn : flash configuration field erased, please reset the device
Warn : Kinetis L Series supports Program Longword execution only.
wrote 9216 bytes from file main.elf in 5.421875s (1.660 KiB/s)
verified 8308 bytes in 0.125000s (64.906 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:06STLink/V2でももちろん書き込みデバッグは可能ですが、前回も述べましたが
STLink/V2からではMDM-APを直接叩くことは出来ないので間違って
セキュリティビット掛けてしまったフラッシュの救済はできませんので
くれぐれもご注意を…。
ねむいさん提供のサンプルを使う限りはハード/ソフトの両面から対策されてるので
セキュリティビットがうっかりかかる問題はありません。
そして↑のサンプルですが…FRDMのソフトウエアパッケージのほうのサンプルの
出来があまりというか非常に良くないというかところどころk40シリーズからの
コピペな手落ちが多数見受けられたのでUARTドライバは完全にCMSISに対応する
ように大幅に書き変えております。
同じくKL25Zのサンプルもこちらの変更を反映しCMSIS完全対応してます。
おまけ
●CMSIS-DAPがOpenOCDから使えるようになってるらしい
まぢですか…！とねむいさんも早速ビルドして試してみましたが…
…あかん…
…今後に期待ですね…現状オープンソース系は機能追加が容易なVersaloon一強な
印象です…とはいえFRDM系の基板は書き込み用のハードも一体化されてるので
無理してOSSに走らなくても十分戦えますが、冒頭で述べたとおり自分が取り組み
やすい環境で各々の実現したいことを目指すのがベストだと思います！
と説得力のあまり無い発言で今日の記事をしめくくらせていただきます。
Kinetis Lシリーズはぢめました
20161123追：
FreeScaleはNxPに喰われました！
"OpenOCD + CMSIS-DAP"の検索で飛んできた方はこちらをご覧ください。
バレンタインチ○コのかわりに先行で公開しておりましたが、Versaloonと
OpenOCDを使用したいつもの書き込み・デバッグ環境がFreescaleのCortexM0+
コアが載ったKL25シリーズでもできるようになりましたのでお伝えします。
●もうこういう無駄な買い物は止めようはと思います…が
このFRDM-KL25ZというボードにはMKL25Z128VLK4というKinetis L
シリーズの石が乗っかっています。当時はいち早くCortexM0+コアを搭載を
謳っていた物で、OpenSDAというオープンソース(らしい)デバッガハードウエアも
搭載されて1000円台で販売されてます。それにしてもこのボードも安いですね。
どのメーカもデバッガハードウエアがついて1000円台が当たり前の時代に
なりました。
時系列的には同じくCortexM0+コアを持つLPC800と同時期に入手して
いましたがFreeScaleの石はあまり食指が伸びずほおっていました。
そのまま腐らせるのももったいないのでちょっといじってみようと思い
たったわけです。
私が目を付けたのはKL25Zの石よりもOpenSDAの方でした。とにかくデバッガ
側のUSBコネクタをPCと繋げるとマスストレージとVCPとが認識されます。
このマスストレージはmbedでおなじみのD&Dで書き込みができるってタイプの
奴です。ソースコードデバッグを行うためにはOpenSDAのファームウエアを
書き込む必要があります。同じくこれに対応したGDBサーバをP&Eマイクロから
取得する必要があります。
が、
フリー版のそれは使用に耐えないくらい動きがｶｸｶｸでプログラムのダウン
ロードも制限されています。我慢してこれ使うくらいなら最初のマス
ストレージ使う書き込みでカットアンドトライした方が10000倍マシです。
というわけでボード単体でデバッグ環境建てるやり方に見切りをつけて
冒頭で述べたSWD接続方式のVersaloon+OpenOCDという王道で環境を
作ることにしました。
↑ｶｶﾛｯﾄ！お前がｶｸｶｸナンバーワンだ！
↑ちなみにOpenSDAのファームをCMSIS-DAPに入れ替えるとCoFlashが使えます。
●Versaloon+OpenOCDで使えるようにしてみる
FreeScaleの石といえどもコアがCortexM0+なのでSWDで引っ掛けるのは
たやすいです。先ずはマスストレージで書き込んだプログラムをOpenOCDと
insightでデバッグは問題なく確認できました。ちなみにOpenSDAのSWDは
切り離さずともVersaloonとつながるので基板パタンのカットなどの作業は
必要なくSWDの線を引っ張り出すだけです。
次に書き込みですが…OpenOCDのkinetisドライバは現在KL25Lシリーズには
対応していないのでLPC800の時と同じように自分で実装する必要が
ありました。kinetisドライバはフラッシュ書き込みを行うのにRAMにプログラム
を乗っけて一気に書き込む方式と4バイトずつ書き込んでいく方式があります。
これはkinetisの各モデルで使用できる書き込み方式が決まっていてKL25では
後者の"Program Longword"というコマンドでしか書き込むことはできません。
幸いにもKL25シリーズはチップ固有IDがかなり細かいところまでわかるので
これを利用して既存のモデルの書き込みになるべく影響しないようにKL25の
書き込みルーチンを作りこんでいきました。
↓そして完成したドライバの書き込み結果がこちら
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/kl25z_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00159-g87668ae-dirty (2013-02-15-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
Info : add flash_bank kinetis pflash
adapter speed: 1000 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Feb 20 2013)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : kl25z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20003000
Rize up to Internal PLLed Clock!
Info : Probing flash info for bank 0
Info : KL24/25Series Erase All Blocks
Info : Write to MCU security status unsecure
erased sectors 0 through 127 on flash bank 0 in 0.046875s
Warn : KL24/25 supports Program Longword execution only.
wrote 6676 bytes from file main.elf in 5.453125s (1.196 KiB/s)
verified 6676 bytes in 0.156250s (41.725 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:07先にも述べましたが低速な"Program Longword"による書き込みは現状のkinetis
ドライバではDAPを毎回叩いてﾁﾏﾁﾏホストPCから命令をおくっているため通信の
オーバーヘッドが非常に大きくなりMAX2kByte/Secくらいしか速度が出ませんorz
STM32みたくRAM上に小さいブートローダー流し込んでそこをデータの受け
渡し場にしてアトミックに書き込みを行うようにしないとこれ以上速度は出ませんが
↑結局自分で実装しました！超快適です♥
↓ちなみにSTLink/V2でも当たり前のように書き込み・デバッグが可能です。
20130419追：重要!!!
STlink/V2 firmware version MUST upgrade to V2.J17.S0!
↓
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/kl25z_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00159-g87668ae-dirty (2013-02-15-17:44)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
none separate
Info : add flash_bank kinetis pflash
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.894991
Info : kl25z.cpu: hardware has 2 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x000000cc msp: 0x20003000
Rize up to Internal PLLed Clock!
Info : Probing flash info for bank 0
Info : KL24/25Series Erase All Blocks
Info : Write to MCU security status unsecure
erased sectors 0 through 127 on flash bank 0 in 0.046875s
Warn : KL24/25 supports Program Longword execution only.
wrote 6676 bytes from file main.elf in 5.078125s (1.284 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20003000
verified 6676 bytes in 0.062500s (104.312 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:05まぁOpenSDAのマスストレージからの書き込みが使い勝手が非常に良いので
書き込みはMSCから、デバッグはVersaloon+OpenOCDと使い分けるのがよい
でしょう。そのうちkinetisドライバに手を入れてくれる人が出ると思い
ますから…ふふふふふふふふふふふふふふふふｆ
●FreeScale Kinetisシリーズを使う上で必ず守るべき事項
今回の記事はこの項を特に頭に叩き込んでください！！
知らずにやってしまうとｺﾞﾐにしてしまいます！！！！！
KinetisシリーズのARMマイコンはNxP系のARMマイコンと同じくフラッシュ
メモリの特定の領域にMCUのコンフィグレーションが設定されています。
具体的に言うと0x00000400番地以降の16バイトが相当します。
メーカお仕着せのツールではこの番地にユーザープログラムを置かないように
配慮されておりますがGCCで一からプロジェクトを作り上げる人はこの番地は
コンフィグレーション専用の番地としてしっかり設定して置きましょう。
具体的にどうやるかは私のサンプルを参考にしてください。
ついでですがメーカ提供のUARTドライバというかいろんなものがちょっと
出来が悪すぎるのでSTM32でも使ってるUARTドライバを移植してます。
話がそれましたが、一番気を付けるべきはフラッシュメモリの0x0000040Cから
読みだし設定されるFSECというレジスタです。ここの値の下2bit分が(00,01,11)
の場合Secure状態と判断されSWD経由のアクセスがある特定の操作を除いて
一切不可能になります(マニュアル73-74p参照)。
…もうお気づきだとは思いますが、つまりは内蔵フラッシュメモリの２番目の
セクタの消去orメモリ全消去の操作をしてアンプログラムド(すべてのビットが1)
にしてしまうとコードセキュリティが働いて以後のSWDのアクセスが特定の
操作以外は実質不可能になってしまいます！！！
おまけにSTM32やLPCマイコンでは可能だったシステムブートローダからの
起動によるセキュリティ状態をキャンセルするという軟弱な救済措置は、
KL25シリーズではシステムブートローダ自体が存在しないため不可能という
非常に男気あふれる仕様となっております！！
(注:工場出荷時は0x0000040Cに0xFEを書き込んで出荷されているため、いきなり
動作不能とかはないです)
唯一の解除方法はデバッグポートの下位のレベルの"MDM-AP Control register"
に全消去ビットを送り込んで(この操作を行うと全消去された後0x0000040Cに
0xFEが書き込まれる)で工場出荷時のフラッシュメモリの状態に戻すことです。
ねむいさんが試したところではOpenSDAのマスストレージモードやCMSIS-DAPは
この操作を先に行っているようで、わざと0x0000040Cが0xFFなプログラムとか
書き込んだ後でもふつーに操作可能です。
幸いにもOpenOCD中のarm_adi_v5.cにはkinetisマイコンに対してローレベルで
SW-DPを叩くことができるコードが追加されています。ねむいさんはこちらにも
手を加えて、KL24/25シリーズでもこの復活措置を可能にしました。
しかしながらこの操作はSRSTの物理操作が必ず要求されるため、Versaloonに
SRSTの線を追加するかもしくは手動リセットでタイミングよく解放してやる
等の小手先の技が要求されます。
秒単位の話なのでタイミングに慣れるとそれほどの事じゃないですが…
それと当たり前ですがarm_adi_v5.cを経由しないSTLink/V2やTI-ICDIのような
API召還型のタイプのアダプタは直接SW-DPを叩けないため、この回復技は
一切不可能なのでご注意を。
ちなみに0x0000040Cにはmass_erase許可ビットも4-5bit目に存在しており、
"0xEF"と書き込んじゃうとSW-DPを直接たたく全消去操作もできなくなって
しまい完全にｺﾞﾐと化します
ねむいさんが公開しているFRDM-KL25Z向けのサンプルプログラムとKL24・25
シリーズに対応したOpenOCDはプログラム上でも書き込み時も0x0000040Cに
0xFFにしてしまわないように配慮を行っているので安心してお使いください。
Versaloon+OpenOCDの組み合わせだけでも幸せになれると思います。
ぱっちもここに置いてるのでだれか腕のある人続けてくだち…。
↑結局自分で実装しました！超快適です♥
LPC800シリーズを使ってみる2
-前回までのあらすじ-
OpenOCDで最初の1kByteしか書けなくてふてくされて他の事やってました。
特にいないさんの誕生日が近づいてきているのでそれの準備に虹裏メイドパワーを
お注ぎ申したり(もう製作完了しました！2月9日はこうご期待！)、副業先の引っ
越しに巻き込まれたり500mも移動してませんが住み家の引っ越しやらでいろいろ忙し
かったのですが、ちょっと落ち着いたのでOpenOCDのコミットを見るとLPC43xx系の
フラッシュありタイプの書き込みサポートがレビュー中状態で追加されていました。
気になって変更箇所見てみるとLPC800シリーズの書き込みにも関する大きなヒント
が見つかったので再びチャレンジしてみた次第です。
ゲームは一瞬で終わっていた…ユーザーマニュアルにちゃんと明記されてたorz
LPC812はLPC2000系やLPC17xx,LPC12xx,LPC13xx,LPC11xxx系と違いIAPスタック
の最大消費量が少し多くなるとの事です。少しの差が成否を分けていたようですorz
そいやvsprogのコードにもそんなこと書いてあったような…まぁいいです。
それをもとにちゃんとドライバを作り込むと拍子抜けするくらい簡単に書き込みが
出来るようになりましためでたしめでたし！
↓LPC812完全対応のOpenOCD+SWD接続のVersaloonで書いた時のメッセージです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/lpc812_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
none separate
adapter speed: 250 kHz
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info : USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info : clock speed 250 kHz
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
wrote 2048 bytes from file main.elf in 0.499965s (4.000 KiB/s)
verified 1600 bytes in 0.109367s (14.287 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01↓SWDで繋がるということはもちろんSTlink/V2も使用できるということですね♥
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/stlink-v2.cfg -f target/lpc812_hla_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00151-g4a5c9a4-dirty (2013-01-31-19:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
adapter speed: 1000 kHz
none separate
adapter speed: 250 kHz
Info : clock speed 250 kHz
Info : STLINK v2 JTAG v16 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.869535
Info : lpc812.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x1fff0008 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000c8
wrote 2048 bytes from file main.elf in 0.343750s (5.818 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x1000002e msp: 0x10000ffc
verified 1600 bytes in 0.062500s (25.000 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01STLink/V2のほうが若干書き込み速度が速いですか…！
でもLPC800系はフラッシュ容量の最大が16kByteなので特に気にならないかと
思われます…。
当たり前ですがいつも通りのデバッグもいつも通り可能です。
もちろんSTLink/V2でも自由自在に可能です♥
て訳でLPC812の書き込み・デバッグに完全対応したOpenOCDのバイナリ
公開します。OpenOCDのLPC812対応に関しては全世界でねむいさんが最初です！
あとは秋月さんがLPC810のDIP品を売ってくれるのを待つばかりですね〜♥
あ、ついでにLPC812-LPCXpressoのプロジェクトも更新してます。
おまけ
尺が余ったのでもう少し続けます。
先日ChaN'氏がFatFs0.09bをリリースしました。ドライブのボリュームラベルに対応
しています！ねむいさんもこちらの適用を進めてすでにおきぱにて対応済みのサンプル
を公開しています。今回の作業でSTM32VL,STM32Lでボリュームラベルを設定した時に
ディレクトリ構造が破壊される恐ろしいバグが自分のMMCドライバ側に眠っていたのが
判明したので何気に修正してます。
…ぇーっといままでwriteの方は放置してましたすみません！！
LPC800はぢめました(Versaloonを使ってLPC812に書き込み&デバッグを行う)
……ッッ
ギ ブ ア ッ プ orz
去年末に入手しVersaloon+OpenOCDで書き込みデバッグせしめることを頑張って
きましたがもうお手上げですorz
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすが私！
と書き切ってしまうと今日のブログ終わっちゃうのでvsprogから書き込みを行う別の
突破口を見つけ成功しましたのでLPC812使用記を兼ねてお知らせします。
Cortex-M0+コアが使用されているLPC800系のペリフェラルのアーキテクチャは
M0コアのLPC1114系とは違う部分があります(USB付きだからかLPC11uxx系も
全く違う)。
フラッシュメモリの構造もその一つですが、フラッシュサイズの上限が16kByteまでしか
無いLPC800シリーズではLPC11xx系とは比較すると以下のようにセクタ/ページサイズ
が細かくなっています。
*セクタサイズ
LPC11xx : 4kByte
LPC8xx : 1kByte
*ページサイズ
LPC11xx : 256byte
LPC8xx : 64byte
OpenOCDやvsprogに代表されるフラッシュ書き込みルーチンはLPC系のARMマイコン
ではJTAG/SWD経由でもIAPを召還して書き込みを実行する方式のため新たなデバイスの対応に特段に難しい措置は必要はありません。
だから公式に対応してなくとも自分でセクタ/ページサイズの定義をちょちょいと
追加してやれば終了のはず…
…なのですがOpenOCDでは1セクタ目を書いた時点でHardFaultに
なってしまいアウチとなったのでしたorz
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすが私！
しかしvsprogではあっさり成功してしまいましたので誰かがOpenOCDで頑張ってくれる
までは当分vsprogでLPC812に書き込みを行います。
↓書き込んだときのメッセージです。PN2のコンソール出力キャプチャに対応させる
ため、LPC800と直接関係ない表示系も少しいじってますのでご了承を。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
vsprog -clpc812m101fdh20 -ms -I main.hex -oe -owf -ovf
VSProg 1.0 svn:1364M
CopyRight(c) 2008-2010 by SimonQian
URL: http://www.SimonQian.com/en/Versaloon
mail: SimonQian@SimonQian.com
Info: Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info: USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info: Target runs at 0.000V
Info: SWDID = 0x0BC11477
Info: AHB-AP_ID = 0x04770031
Info: ROM_ADDRESS = 0xE00FF003
Info: CFG = 0x00000000, Little-endian
Info: CORTEX-M0 r0p0 processor detected
Info: CPUID = 0x410CC600
Info: Bootloader version 13.1
Info: Chip-id read is 0x8122.
Info: erasing flash
erasing flash |========================================| 0.06s used
Info: flash erased
Info: SWDID = 0x0BC11477
Info: AHB-AP_ID = 0x04770031
Info: ROM_ADDRESS = 0xE00FF003
Info: CFG = 0x00000000, Little-endian
Info: CORTEX-M0 r0p0 processor detected
Info: CPUID = 0x410CC600
Info: programming flash
writing flash |========================================| 0.39s used
Info: flash programmed for 1600bytes(4.00KB/s)
Info: verifying flash
reading flash |========================================| 0.09s used
Info: flash verified for 1600bytes(16.80KB/s)
> Process Exit Code: 0
> Time Taken: 00:01
OpenOCDはフラッシュ書き込みはできないもののそれ以外のすべての操作は
LPC11xx系と同様に可能です。いつものInsightを使ったデバッグとI/OViewも
自由自在です。もちろんSTLink/V2でもデバッグ可能です。
ということで少々セコ技ですがいつもの構成で開発環境が整ったのでLPC812Xpresso
用のプロジェクトファイルを公開します。
同時にLPC812に書き込み可能なvsprogのwindows用バイナリとLPC812のcfg入りの
OpenOCDも更新しました。
vsprogと同じフォルダにはLPC800系対応のパッチがありますので興味ある
人は自分でビルドして試してみてくださいね。
20130201追：
OpenOCDからも書き込みができるようになりました！！
さすがわた(ry
いろいろ試す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シリーズ(Stellaris Launchpad)を使ってみる
入院をごく間近というか明日に控え、プールしていた小ネタで消化します…
Launchを"らうんち"と呼んでしまうねむいさんですが注文していたのが
やっとこ手に入りました！
Cortex-M4Fコアが乗ったLM4F120シリーズを使った超格安評価基板である
Stellaris LM4F Launchpadです!
なんと同じチップが2つも乗っかってます。そのうちの一つはStellaris-ICDIデバッガ
ハードウエアを構成しています。
I/Oピンはプロトタイプ性を意識して亀の子が出来るコネクタが実装済です。しかし
ピン側は非常に曲がりやすいのでご注意を。
さて、取っ掛りのLED点滅を行いたいところですがStellarisWareのソースコード
だけではCMSISに準拠していないのでTIのサイトに登録し、
"TI-CMSIS-Devices-****.exe"っていう
インストーラを探してCMSIS準拠のヘッダファイルその他を取得する必要があります。
…これでSTM32等でやってたプロジェクトと同じ物が作れました。ベースはまだ
手に入れていないSTM32F3の物です…おきぱにありますので自己責任でどうぞ…
ところでビルドしたバイナリの書き込み/デバッグなのですが残念ながらLaunchpadに
付いているICDIは過去の旧Lumitaryの評価基板にあるようなFT2232系の物やそれの
エミュレーションではなく独自の物となっています。つまりまだOpenOCDにはまだ対応
していません。しかし、STによるSTLink対応の時と同じくTI側の技術者さんも協力
してくれているようで、OpenOCDへの対応は進められているようです♥
それに先立ちオープンソースのLM4Fフラッシュライタも公開されています
(コメント欄のあたり)。
また、従来のVersaloonとかのデバッガは駄目なのかというとそうでもなく、外部に出て
いるJTAGのポートにデバッガハードウエアを繋げてやればSTM32と同じくJTAG/SWDで
読み書きやデバッグが可能です！
JTAG/SWD用のヘッダピンを追加するだけで他のハンダつけ作業も不要です。
当たり前ですがStellaris特有のROMドライバの関数を使った場合、関数の
中まではいけないのでご注意を。
InsightとI/OViewでDID0レジスタを見るとLaunchpadに使われてるLM4F120H5QRの
リビジョンはRev.A3であることが分かりますね。こう言う出始めに超格安で評価
ボードバラまく時って大抵ES品とかエラッタ満載のリビジョンの浅いの乗っけるん
ですがちょっとは良心的だと思います。
↓SWD接続のVersaloonで書き込んだときのメッセージはこんな感じです。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/lm4f120xxxx_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.7.0-dev-00050-g98a41bc-dirty (2012-10-18-09:39)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
adapter speed: 500 kHz
Info : Versaloon(0x15)by Simon(compiled on Jul 18 2012)
Info : USB_TO_XXX abilities: 0x0000072E:0x010001EF:0xC0000007
Info : clock speed 500 kHz
Info : lm4f120h5qr.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000280 msp: 0x20008000
auto erase enabled
wrote 2048 bytes from file main.elf in 0.156251s (12.800 KiB/s)
verified 1124 bytes in 0.140626s (7.806 KiB/s)
adapter speed: 500 kHz
cortex_m3 reset_config sysresetreq
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:01おきぱにあるOpenOCDの32bitバイナリもLM4F120系のMCUの書き込みに対応した
cfgファイルをすでに追加してあります。
FT2232系やSWD接続のVersaloonで書き込みが可能です。
Launchpad付属のICDIもあともう少し待てばOpenOCDに対応される
はずなので首を長くして待ちましょう♥
LPC4330はぢめました -まだLチカもできない-
積み基板どころか"詰み"基板になるのが分かっていながら人はなぜ、
何故、同じ過ちを繰り返してしまうのだろうか？
…しかしねむいさんはLPC1788にMCI版FatFsを移植を行ったので十分挑戦権が
あると自負しています！日本のアマチュアでは今度こそ一番乗りで(あつさんがすでに触ってました…)LPC4330が
搭載されたLPC4330-Xplorerの使用感を報告させて頂きたいと思います！！
この基板インド製だそうですがもう時代は中華大陸飛び越えてインドですよ
インド！
さて、この基板はNxP社肝入りのCortex-M4F+CortexM0のデュアルコアが搭載
された最新のマイコンLPC4330が搭載されています。
最大動作周波数はCortex-M系最高速の204MHzに上り(M4,M0コアの両方とも)、
クアッドSPI-ROMが使えるインターフェース"SPIFI"も搭載されています。
USB-HSのPHYもLPC4330内に搭載しており(USB0のみ)、外付けHS-PHYも必要
ありません！
もちろんねむいさんのいつものに必要なMCIインターフェースもあります！
んでもって基板の構成ですがSTM32F4Discovery宜しく音アプリを強く意識
した構成となっていてAudio-CodecやEthernet-PHYも実装されています。
さらに基板上にMicroSDカードコネクタやSPIFI用のシリアルROMも乗っていて
FatFsの移植も少しは楽になりそうですね♥
さぁケーブル繋いで通電だー！と思ったのですが…
…良く見るとコネクタがなんだか変…
写真分かりづらいですが無理やりねじこんだように金具の上側が微妙に
曲がってます…
そして付属ケーブルの口見たらこんなになってやがりました…
注：最初からこんなになってました。ねむいさん壊してないですよぅ！
もちろん刺さりませんorz
もうﾅﾝ持ってｲｪｪと叫びたくなるのを我慢してさらに基板をよく見ると
手半田で修正した跡がありDIPスイッチが溶けてLEDが焦げてました…
もうﾀﾞﾌﾞﾙｵﾄﾞﾛｷですよねほんと印度クオリティすごいってまたひｔ
インドのNGXから直接購入したので修理交換の手間と金が非常にかかって
しまうと感じ、結局自分でコネクタ・LED他の付け替え修理を行いました。
LPC4330-Xplorerに実装されたmicroUSB-Bコネクタとほぼ似た形状の奴を
taobaoで購入しており、スムーズに付け替えは完了しました。ちなみに
秋月さんちで売ってるタイプの奴はコネクタを挿す向きとピンの
並びが逆のため付け替えができません！ご注意ください。
LEDの交換ついでに3.3VのLDOもMLCCが使用可能なZLDO1117に換装して
おきました。
最初に付属していたUSBMicro-Bのケーブルは捨てて手持ちのを使います。
後はチュートリアルに従いVcomのドライバ入れて基本操作を確認しました。
NGXのチュートリアルにはUSB0サイドのUSBHIDデバイスは挿したらすぐに
動くように見られますがまずUSB1サイドをPCに刺し、その次にUSB0サイドを
PCに刺し、最後にSW2を押すとUSB0サイドのHIDデバイスとして認識される
ようになります。
またSW2を押した後は仮想COMポート上で上画像のように各種チェック
ルーチンが走るようになっています。
同時にEtherNetもアクセス可能です(192.1681.1.123固定なのでご注意下さい)
LEDの操作がブラウザ上から可能になっています。
最後にJTAGで繋いでみてOpenOCDからどう見えるか確かめてみました。
LPC4330-XplorerのJTAGコネクタがちいさ過ぎてTI-StellarisのICDI付属の
ケーブルしかピッチが合うのなかったので、JTAGkey2Cloneの代わりに急遽
これを使いました。
↓で繋いだ状態はこんな感じに…
openocd -s C:/Devz/ARM/OCD/tcl -f interface/ftdi/luminary-icdi.cfg -f target/lpc4350.cfg
Open On-Chip Debugger 0.7.0-dev-00001-ga4830e7-dirty (2012-09-10-17:57)
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 speed: 500 kHz
cortex_m3 reset_config sysresetreq
Info : clock speed 500 kHz
Info : JTAG tap: lpc4350.m4 tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: lpc4350.m0 tap/device found: 0x0ba01477 (mfg: 0x23b, part: 0xba01, ver: 0x0)
Info : lpc4350.m4: hardware has 6 breakpoints, 4 watchpoints
Info : lpc4350.m0: hardware has 2 breakpoints, 1 watchpoints
確かにCortex-M4とCortex-M0のふたつのコアが見えてますね〜
ほんとに触っただけというかそれ以前のやっと修理したばっか状態なのでLチカ
すらも進んでませんが、豊富なサンプルをベースにいつものを作っていきます。
LPC1114を使ってみる3
こちらとこちらの記事に続いて通算3つ目のLPC1114についての記事です。
前回述べたとおり秋月さんよりDIP版LPC1114が180円で販売され私も購入しました。
"どうせLチカ(LED点滅の意)で終わらすんだろ"とお思いの方が大多数とは思います。
その通り私はDIP版LPC1114をLチカせしめてこの記事を書くためだけに購入しました！
と、すべてに対する防御壁作ったところで今日の本題に入ります…。
●DIP版LPC1114のいいところ
1.ブレッドボードに最適なDIP28Pinなのはいいのですが600mil幅という無駄な広さ
IOとかSRAM削ってる(後述)くせにこの広さって…"ほらDIPにするとこんな
無駄にでかくなっちゃうんだよみんな面実装の奴使おうね★"というメッ
セージなのでしょうか…
2.SRAMの容量がTQFP48Pin(面実装品)の物から半分に削られた
"TQFPパッケージは8kByteも使えるよみんな面実装の奴使おうね★"という
メッセージなのでしょうか…
3.I/OピンがTQFP48Pin(面実装品)の物からいくつか削られた
"TQFPパッケージはもう少しI/Oピンが使えるよみんな面実装の奴使おうね★"
というメッs もうええっちゅうに
LPCXpressoに乗っているLPC1114と違う点は上記DIP版はPowerProfileが追加された
第二世代のLPC1100Lにカテゴライズされる製品となってます。現在はLPC1100XLまで
ラインナップされています。
●Lチカる
基本的にLPC1114のソースコードがそのまま転用できますが、上述のとおり
SRAMが4Kbyteしかないのでスタックの値は要調整です。
私の公開してるプログラムはMARYにも対応してる(内部RCをPLLのソースとする)
ので取り合えず定義をこちらにしてやればVCC・GND・SWDIO・SWDCLKのたったの
4本でOpenOCDから書き込み・デバッグできます。
(なぜかリンカスクリプトファイルを全くいじらず8kByteのままでも
ふつーに動きました…STM32F107VBTみたく隠しでSRAMあるのか！？）
が、
OpenOCDで繋がるってことはソースコード一行も書かなくてもGPIOくらいは
動かせられる(＝Lチカれる)ってことで早速やってみました。
ブレッドボードすら使いません！１！
…ねむいさんただTCLの"スクリプト"組んだだけだからねCの"ソースコード"は
一行も書いてないy止めろ石投げるな
●LPC1114(DIP版)にプログラムを書き込む
注:2019年現在はこの方法は古すぎて通用しません！
私の最新のOpenOCDバイナリに同梱されている説明書きと対応MCUをよく読み
コンフィグファイルとコマンドを実行してください！
…さて、今度こそ真面目にソースコードビルドして出来たプログラムを書き込みます。
書き込む方法は何通りもあります。UARTブートローダー(ISP)を利用する場合は
FlashMagicを使って書き込む・ChaN氏のLPCSP使って書き込むという方法が、
さらにSWD接続においてはLPCXpressoを使用して書き込みを行う詳しい方法が
Lynx-EyEDあつ氏から紹介されています。
私が紹介するのはおなじみのOpenOCDからSWD接続のVersaloonやSTLink/V2を使って
書き込みを行う方法です。OpenOCD0.6.0ではCortex-M0並びに一部のSWD接続可能な
デバッガハードウエアのサポートが進められています。
Versaloon使って書き込む方法はこちらやこちらを参考にしてください。
DIP版のはSRAMが4kByteしかないのでLPC1114ではなくLPC11U14
(SRAMが4kByteしかない)と思って書き込みしてやるとうまくいきます。
↑Versaloonで使う場合はlpc11u14_swd_flash.cfgを指定すれば終わりです。
次に、デバッガハードウエアとしてSTLink/V2を使う方法ですがこちらも手順は確立
されていてVersaloon並みに簡単に書き込み・デバッグが可能です。
今回はSTM32F0Discoveryにビルドインされた物をSTLink/V2として使用します。おそ
らくCQ出版系の雑誌記事では営業的な理由で絶対にお目にかかれない内容なので
私が紹介してる方法は貴重なものになるかと思います。
↑外部にSWD線・電源線を引き出す準備です。
↑
lpc11u14_stlink_flash.cfgを選択。
20130501追:
時代は変わり、STLink/v2以外にもベンダ提供APIが使えるデバッガが出来て
きましたので現在はlpc11u14_hla_flash.cfgに変更しております。
-f lpc11u14_stlink_flash.cfg から
-f interface/stlink-v2.cfg
-f target/lpc11u14_hla_flash.cfg
と読み替えてください。
20140829追：
さらに時代は変わりました。
HLA系のデバッガアダプタの使用例はこちらをご覧ください。
ねむいさんのぶろぐで公開しているOpenOCDバイナリはすでにこのコンフィグファイル
は含まれております。また、今回のDIP版LPC1114やLPC11U14等の少SRAMの品種の
書き込みに対応するためにlpc2000.cへのパッチは必須となりますが、ねむいさんの
OpenOCDバイナリはパッチ済ですので安心してお使いください。
20130314改変:
OpenOCDからSTLink/V2を叩く時のデバイスドライバはSTマイクロ提供の物を
そのまま利用可能です。逆に以前使用していたLibUSB(libusb0.1系)は廃止し
使用不可能なのでご注意を！
↓にSTLink/V2で書き込んだときに表示されるメッセージを置きます。
> "C:¥Devz¥Coreutils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/lpc11u14_stlinkv2_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-rc1-dev-00015-g47728f9-dirty (2012-08-29-17:12)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
none separate
250 kHz
Info : clock speed 250 kHz
Info : lpc11u14.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x1fff0040 msp: 0x10000ffc
auto erase enabled
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x81000000 pc: 0x10000004 msp: 0x100000b4
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x10000004 msp: 0x100000b4
wrote 4096 bytes from file main.elf in 0.468753s (8.533 KiB/s)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x100000e2 msp: 0x10000ffc
verified 1580 bytes in 0.062500s (24.688 KiB/s)
shutdown command invokedフラッシュメモリの容量が32kB程度なので速度もそれほど必要ないかと思います。
異なる会社間のツールが使用できるのか！？
そもそも出来たばかりの未知のチップに書き込みができるのか！？
否、出来る、出来るのだ！集中線のフォーカスが明後日の方向いてるけど！
20130427追:
↓うまく書き込みができない場合の確認事項↓
１.そんな結線で大丈夫か
->もう一度ターゲットとSTLink/V2のSWD信号がちゃんと繋がってるか確認！
そんな基本的なこと間違うわけないだろって奴に限って間違ってます！
２.そんなDiscoveryのジャンパ設定で大丈夫か
->STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2はデフォルトでは
STM32側に繋がってます。ジャンパを必ず外しましょう。
STLink/V2はマルチドロップSWDに対応していないため通信がこけます。
３．そんなVtgtで大丈夫か(←これで引っかかる人多し!)
->V17以降のSTLink/V2のファームはvtgtをきっちり合わせないと撥ね
られてなんでか書き込みが失敗します。かならず接続しましょう。
STM32L/F4/F0DiscoveryにビルドインされたSTLink/V2では
VtgtからAD入力に繋がる抵抗が未実装なので回路図をよく見て100ohmも
必ず実装しましょう。
おなじみInsightを使用したデバッグ画面。I/OもIOViewも楽々操作です♥
上記の操作をすぐに試すことができるLPC1114DIP版も対応のプロジェクトファイルは
こちらです。ビルド手順はこちらを、デバッグ手順はこちらを参照してください。
DIPに対応するにはmakefileの定義を少し変えるだけでOKです！
●大事なことなので何度でも言います
最後に注意点ですが(これも過去に何度も何度も言及していますが)LPC1114を
初めて使う際は、NxP系のマイコンに存在する"CheckSumValidation"や
CodeReadProtectionも考慮に入れてください。
詳しい解説は本家のユーザーマニュアルに譲りますが、LPC1114では内蔵
フラッシュからプログラムを実行する場合、下図のような構成にされるべきです。
基本的に"ActiveVectorRegion"のCheckSumValidationより少ないアドレスにある
情報はほぼ固定値となるので(変わるとしたらスタックの頭を変えるときくらい)
リンカスクリプト内でも"KEEP(hoge)"で固めておくとビルドのたびに
CheckSumの値を変える必要がなく非常に便利です。
LPCXPressoやmbedではCheckSum値は書き込み時に自動計算されて書き込まれる
のでユーザーは意識しないで済みますが、上記のことを知っておかないと素で
ビルドした時にLPCXpressoで動くはずのプログラムが"動かない"と詰まる
羽目になります。(実際にはISPに飛んで行ってしまいます)
また、CodeReadProtectionも0x2FC番地という場所にあってこれを厳格に
定義してしまうと0xC0~0x2FBまでのフラッシュ領域が無駄になってしまいます。
よってこちらもあまり変えることが無い".data"や".bss"等のSRAM領域の
初期化ルーチンを決め打ちで置いてやるようにすればフラッシュ面積の
無駄になりません。
私が公開しているプロジェクトのNxP系のマイコンはすべて上記の考慮を
しておりますので、AVRやPICから入られた方は、一度リンカスクリプトや
スタートアップファイルをじっくりと読み、どのように組むべきかを把握して
おくとのちのち役に立つでしょう。
あ、NuvotonのNUC120のこと忘れてた…
いろいろ試す13
DIPのLPC1114の話がここかしこで持ち上がっていますがSRAMの容量半分に
削られてるしねむいさんはふつーにスルーさせていただきま…
と言いたいところでしたがなんと秋月さんからもリリースされましたので方針を
360度変更してこちらでも取り扱います！！！乞うご期待！！！
それと私が提供してるOpenOCDのバイナリとVersaloon使ってデバッグとか書き込
みでしようとして躓く人必ず出てくると思うので思うので一応注意を書いておきます。
下記の2点さえ抑えていれば大丈夫です。
1.SRAMが半分に削られてるのでlpc1114_swd_flash.cfgじゃなくて
lpc11u14_swd_flash.cfgを使用するべし。
2.Windows使いの人以外でOpenOCDビルドする必要がある人はlpc2000.cにパッチを当
てないと書き込みができません。詳しくはここ参考にするべし。
ちなみに2.のOpenOCDビルド手順はubuntuやマカーな方にとっては未だに
需要があるので新たに整備が必要だと感じてきました。逆にWindows使いの
方は9割がたEclipse環境に行くので初見で私のぶろぐまでたどり着く人は
実はものすごく少なくそもそも知っててもみなかったことにさｒ
…さて前ふりはこの辺にしといて小ネタが貯まってきたので消化してきます。
●LPC1788にMCIインターフェース版FatFsを移植する
やっとこ安定化しました…。結局I/Oポートの初期化がおかしかっただけ
だったというなんたるイージーミス…
LPCwareのサンプルも同じ間違いしてるから中の人に伝えておきました。
LPC2388ではメインSRAMに直接DMA出来ないため、ChaN氏はUSBRAMとリンク
リストで順繰りに効率的に転送するかたちを取っていました。私の場合も
LPC1788ではAHBRAMを使用して同じことやってます。AHBRAMとメインSRAMは
独立しているので転送中別の処理やってもフンつまりにならないのです。
MCIのクロックは定格内で20MHzまで設定できます。転送効率が良いのでリード速度は
理想値に近いですね♥ちなみに定格に外れますが30MHzも設定は可能です。
↓外人さんもよく来るので英文でメッセージ
Finally,FatFs for LPC1788 MCI interface turns stable by Nemuisan's works!
You can get sourcecode Here!
●SANDISKのすごく早いUSBメモリ
ごく一部で話題沸騰だったSANDISKのUSBメモリを欧州のebay経由で購入しました！
2012年8月現在は日本国内の通販でも安価に購入可能です。
SDCZ80-032G-X46っていうUSB3.0対応のメモリなのですが、一般に安く売られている
USB3.0な奴と違って小さいサイズのファイルのランダムアクセス(特に書き込み)
にも非常に強く、私のようにレス用画像をUSBメモリに入れてる方にはもってこいの
アイテムです♥
deflaggerで見るとSSDが検知されています。SSDをUSB3.0に変換してるタイプの奴な
のでﾁﾏﾁﾏ書き込みにも強いのですね。こちらの方はさらに詳しく調べられています。
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 195.029 MB/s
Sequential Write : 117.804 MB/s
Random Read 512KB : 144.212 MB/s
Random Write 512KB : 25.899 MB/s
Random Read 4KB (QD=1) : 13.372 MB/s [ 3264.8 IOPS]
Random Write 4KB (QD=1) : 9.992 MB/s [ 2439.5 IOPS]
Random Read 4KB (QD=32) : 11.232 MB/s [ 2742.2 IOPS]
Random Write 4KB (QD=32) : 3.699 MB/s [ 903.1 IOPS]
Test : 1000 MB [E: 0.2% (0.0/29.8 GB)] (x5)
Date : 2012/07/30 9:05:28
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
SDCZ80-032G-X46 FAT32 Vostro3350_Win7x64_USB3.0Renesas_64kbclaster
↑買ったばかりの時のベンチ結果です(検証に使ったPCはDellのVostro3350です)。
スクショ取り忘れたのでこぴぺで…
中身がSSDなので64GB版はさらに早くなるようです。
-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]
Sequential Read : 131.462 MB/s
Sequential Write : 23.899 MB/s
Random Read 512KB : 121.063 MB/s
Random Write 512KB : 5.004 MB/s
Random Read 4KB (QD=1) : 10.935 MB/s [ 2669.8 IOPS]
Random Write 4KB (QD=1) : 0.240 MB/s [ 58.5 IOPS]
Random Read 4KB (QD=32) : 11.655 MB/s [ 2845.4 IOPS]
Random Write 4KB (QD=32) : 0.281 MB/s [ 68.5 IOPS]
Test : 100 MB [E: 0.0% (0.0/14.7 GB)] (x5)
Date : 2012/07/12 9:26:14
OS : Windows 7 SP1 [6.1 Build 7601] (x64)
USM16GQ/SC FAT32 Vostro_usb3.0_64kb
↑SONYのUSM16GQ/SCと比較。やはりSanDiskのほうが性能がダンチです。
↑約一か月使い込んだ後
512kと4kのWriteかなり劣化してしまいましたorz
↑今日日のSSDならSecureEraseとかTrimとか使えるはずですがSanDiskから
そういうツールも提供されていないので黎明期のSSDでよく使われていた
空き領域のデフラグやってみました…ちょっとだけ性能回復したような
気がする…
●中華MP3プレーヤー LYUMO M21
ヨドバシで安さにつられて買ってしまったこれは値段通りの性能でした…
めでたしめでたし。
…で終わるわけがないので捨てる前に分解してみました。
生意気にケースは金属製です。
…チャイナクオリティ…ショートしたらやばいですよぅこれ
操作した時に液晶の切り替えがやたら遅いので気になってましたがどうやら私のぶろ
ぐでは定番のMCUバスタイプの中華液晶モジュールが使用されているようです。
ねむいさんは中華液晶を何年も何種類もいじってきましたのでこの文字列見ただけでも
何を意味するか分かります。お尻の"OTM2201"がコントローラICの型番を示します。
そこからi8080接続タイプで176x220の解像度を持ったTFT液晶モジュールであることも
わかります。
液晶モジュールだけ取り外してSTM32F4でうごかしてみました。ピン配置の判定も
過去のデータベースから推定して一発で判明しました♥
ちなみにOTM2201のはずなのにDeviceIDを読んで判明した正式なコントローラICは
S6D0164でした…まぁ中華クオリティ(ry
●いつもの中華液晶たち
aitendoさんから出ると脊髄反射的に手に入れようとしてしまう性格を直さなければ
と思いつつまた動かしていた…
・S95311
まだデモコードが提供されていませんがコントローラIC(HX8340A)とピン配置が判明
しています。QCIFサイズで8bitバスのモジュールではよくある配置なので楽勝です。
初期化手順も中華サイトを巡ってさらにこの液晶用にガンマと表示方向を指定して
あげれば余裕です。i8080な8bitバス専用です。
8/27の雪子ちゃん誕生日記念の際に作ったコラ絵を映してみました。
※今年はえろす抜きです
・S93610
コントローラICはILI9163Bです。まだデモコードが(ry
i8080な8bitバス専用です。
コントローラICとしては何度も動かした実績があるので今回も楽勝です
・S95417
ピン配置はYHY024006Aと同じタイプの2.4inchのモジュールです。まだ(ry
i8080な16bitバス専用です。8bitに切り替えができません。
こちらのコントローラICはST7787でILI9340やR61526系統のコマンド体系と
なっています。しかしながらSTM32F2/F4のような高速でぶん回せるバスの速さに
追従し切れないようなのでGPIOによるエミュレーションかXMEGA等の少し遅めの
バスで動かすのが良いかと思われます。
・S95461C
WQVGAタイプのTFT液晶モジュールです。ま(ry
i8080な16bitバス専用です。8bitに切り替えができません。(意味深)なチップ抵抗
があることにはありますが載せ替えても16bitのままです。
2年前にHX8352Aのものを動かしたことがあります。今回はHX8352Bです。似通った
コマンド体系ですが細かい部分の動かし方が微妙に違います。特にレクタングル指定
では内部メモリアドレス指定のコマンドも追加する必要がありました。よって初期化時
に双方のコントローラICを判定してそれぞれの初期化ルーチンの最後にレクタングル
指定用の関数のポインタを割り振るようして条件分岐による速度低下の発生を抑える
ように工夫しました。
そしてChaN氏のFatFsも久々に更新されたので、いつものにも更新ついでに上記モジ
ュール他に対応しておきました。いつものに収録されているTFT液晶ドライバ群は
隠れた人気があるようです。特にHX8347Aについては検索で飛んでくる方も未だに
多いので役に立ってると私は思(いこんで)います！！！
●おまけ
本来はNuvotonのNUC120やM051をOpenOCD使ってデバッグするのも紹介する
つもりでしたが、意外とボリュームあるので次回LPC1114DIP板の記事の時に
ご紹介します。代わりに…
taobaoでSTM32の生基板大量に買ったついでにまた買ってしまったTFT液晶たちを。
気が付いたら殆ど使いもしない液晶モジュールを150種類以上持っていた私…
R61509V互換のILI9326をコントローラに持つWQVGAのモジュールです。
H016IN61というH016IT01(H161T01は間違い)のパラレルバス版みたいなの
LEDは2個直列なので6.2Vくらい必要です。
QCIFサイズでSPI接続専用でしかもタッチパネル付きの液晶です。LEDは並列3つで
3.3V単一電源でもOK。以前は3-wire,9bitシリアルの奴に苦しめられましたが、
こいつは4-wire,8bitシリアルで非常に扱いやすいです♥
aitendoさん！！これ国内で販売したら大ヒットまちがいなしですよぅ！
とにかく動かすの優先だったので配線が全てやっけつなのは許してほしい。
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:09FM3の場合はフラッシュの読み書きが非常に速いためRCLKを効かせたLPC2388
並みに速くなっています！
(でもCQ出版系の雑誌記事では大人の事情でわざわざこの性能を殺し、
さらにわざわざめんどくさい使い方やデバッグ方法しか紹介してませんね…)
上記3つの検証ではねむいさん特製の各マイコンに合わせたOpenOCDのスクリプトで
あらかじめCPUの最高速度まで叩き上げてこの数値を出しています。
(最高速にするために動作電圧も+3.3Vを想定しています)。
ということで今回の変更によって益々デバッグの回転力が上がることが期待されます。
また、付加的な利点としてFTD2XXを排したことによりプロプライエタリなライブラリが
なくなるのでOpenOCDのバイナリがおおっぴらに配布できるようになるという私のよう
な教える側の人にとってはARMマイコンのビルド・デバッグ手順の整備が大幅に短縮・
簡略化されることにもなり非常に手間が省けます♥ こっこれで"ねむいさんという
人のページみたけどやり方がさっぱり"って後ろ指挿されることなくなったんじゃ！！
中途半端に尺が余ったので、今までにOpenOCDの操作に関していただいた問い合わせの
中で私が｢初めて触った人が陥り易く、かつ致命的になる｣と感じた問題たちについての
回避策やtipsをご紹介したいと思います。
●STLinkでOpenOCD使ってみたいのですがLibUSBやWinUSBのドライバの
インストール方法が面倒そうででわかりません＞＜;
->zadigれ
●あんたのところの記事をもとに基板作って自作のプログラム書き込んだらJTAGで
一切アクセスできなくなってフラッシュが書き換えできなくなってしまった。責任とっ
てこさえた基板言い値で全部買い取れ。
->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ぶっ挿して一ビットずつ対策方法焼き
こんでくから｣…って私言いましたよね！？
STM32F0シリーズを使ってみる
ッついに！手に入った！！！
ぁすみません・・フォーカスずれてましたね…
このBeachBoysのコレクターCDは探して探して探してカナダの片田舎のレコード屋でやっ
と在庫を見つけてそこの親父にねむいさんのインチキ英語でなんとか意思が伝わって
やっとこ購入できた代物でして存在知ってから入手まで実に2年を要したのですがその
労力を払っても聴く価値のある非常にありがたいCDなのです…!
BeachBoysの新アルバムも発表され、ワールドツアーも行われるようになってねむいさ
んの中でBB熱が再び非常に高まっております。
aitendoさんから販売され、秒速で売り切れたandroid基板をねむいさんも
無事ゲッツしました！twitterのTLを見ているとどうやらこちらの中華PADの中身に使用
されている基板だと判明しているようです。しかしねむいさんはHDMI接続の
モニタ持ってないので、先に購入しているBeagleBoardXMのDVI-Dにも対応した
小型モニタを探す旅から始まりそうです。こうして積み基板が増加していく…。
でもいいんです買っただけで満足ですから！
それでは本題行きます…。今年の春先にSTマイクロさんより"STM32のDNAを御得な値段
であなたにテコ入れする(直訳)"をスローガンにCortex-M0系のSTM32マイコンが発表、
販売を開始しました。国内/海外の展示会場でもゲッツした人もすでにいますが、Digikey
でもSTM32F0-Discoveryが入荷されたので早速購入してみました。
いつものST謹製"Discovery"スタイルの基板で、cortex-M0系のSTM32F051R8T6が
搭載されており、日本円で1000円以下のお値打ち価格となっています。
もちろんデバッガハードウェアのSTLink/V2もオンボードで搭載されていてこの基板と
USB(A-miniB)ケーブルさえあれば開発可能です。
しかも今回はプロトタイピングを重視した作りか同じサイズのユニバーサル基板が
一枚ついています。値段を考えると非常にお得です♥(実際にArduinoと組み
合わせたファームウェアのプロジェクト一式がダウンロードできます)。
現在M0系でポピュラーなのは私のぶろぐでも取り上げていたLPC1114に代表されるNxP
系マイコン(評価基板は3000円前後)ですが、ここに1000円以下の破格値で参入したこ
とによりまたまたホビーユースにおける小規模ARMの勢力図が書き換えられるかと思わ
れます。
さて、最初の基本であるLED点滅から開始するわけですが、LPC1114系のマイコンで培
ったリソースがすでに大量にあるのでこれをベースに15分くらいでSTM32F051R8T6
向けのプログラムをやっけつしてビルドを行います。NxP系と違う点はCRPのための
特別な定義が必要ないところですね。
それ以外はスタートアップやリンカスクリプトもほぼ流用します。
次に書き込み手段ですが…もちろんSTLink/V2をOpenOCDから操作して、書き込みや
デバッグを行います。使用するドライバはSTマイクロ提供の物(WinUSB)です。
STM32F051R8T6もM0なNxP系のマイコンよろしくデバッグ用ポートがSWD接続しか
存在しませんがパッチを当てることによりVersaloonとSTLink/V2がOpenOCDから
使用できます。
さらに気づいたのですが、最近のOpenOCDのコミットではM0系のデバッグ機能が
強化されていて以前はcrcエラーが出てしまい不可能だったフラッシュ書き込み時の
ベリファイも可能になっています♥
↓STLink/V2でOpenOCDから書き込んだときのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f target/stm32f0x_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
1000 kHz
srst_only separate srst_nogate srst_open_drain
Info : clock speed 1000 kHz
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003e msp: 0x20002000
wrote 3072 bytes from file main.elf in 0.265629s (11.294 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20002000
verified 2408 bytes in 0.078126s (30.100 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:↓Versaloonの時はこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd_m0 -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32f0x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00595-g445a54a-dirty (2012-05-28-09:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : OpenOCD runs in SWD mode
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
verify Capture-IR is disabled
Info : Versaloon(0x15)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x0000076E:0x010001EF:0xC0000007
Info : clock speed 1000 kHz
Info : stm32f1x.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080007c8 msp: 0x20002000
auto erase enabled
Info : device id = 0x20006440
Info : flash size = 64kbytes
wrote 3072 bytes from file main.elf in 0.265628s (11.294 KiB/s)
wrote 2408 bytes from file main.elf in 0.093752s (25.083 KiB/s)
verified 2408 bytes in 0.140626s (16.722 KiB/s)
shutdown command invoked
> Process Exit Code: 0
> Time Taken: 00:
当たり前ですがどちらの方法でも危なげなく動作します。
もちろんOpenOCD/Insightを使ったデバッグも無制限でバリバリ可能です！
今回の検証に使用したコードはすでにおきぱにて公開していますので自己責任のうえで
お試しください。また、おきぱにあるCortex系のコードでCMSISが使用されて
いる物のほとんどはすでにSTREX系命令のビルド時エラー対策の修正がされている
CMSIS3.0系を使用していますので安心してビルドが可能です。
STM8Sは値段は安いですがちょっとあつかいにくいきらいがありました。
しかしSTM32F0なら敷居がさらに下がって小規模マイコンでARMを使用する
人も増えるでしょう。秋月さんからの販売がカギとなると思います!
20121115追：
秋月さんから販売されました！
FM3マイコンはぢめました
20140318追:
かつてOpenOCDのFM3ドライバには様々な致命的なバグが存在しておりましたが
ネムイ・トリノミアスさんという美少女の活躍のおかげでほとんどのバグは
解消され、安定して使用が可能となっております。
私のぶろぐにおいてもFM3ドライバのバグが修正済の最新のOpenOCDバイナリ
を公開しておりますので是非ご利用ください。
20131031注：
OpenOCDのFM3ドライバは致命的バグが放置されております。他の方のHP/ブログ
経由で私の所にうまくいかないできないといった質問が何度も来てるのですが、
IF誌収録のバイナリはまだ修正しきれておりませんのでご注意ください。
変なアレンジをしようとしないでまずは私のやり方をまねてください！
私が公開してるOpenOCDのWindowsバイナリは上記致命的バグをすべて修正して
おります。Linux系OSユーザーの方のためにパッチも公開しておりますのでご参考に。
20120708注：
IF誌についてたQEMUはFM3固有のペリフェラルのエミュレーションなぞわざわざ
やってないので、私のやつをビルドして使ってもQEMUでは一切動きません！S**K!
富士通製Cortex-M3なARMマイコンのFM3シリーズであるMB9BF618T。
これが実装された付録基板が付いているInterface誌6月号の明日の販売を控え、
帰宅途中に"たまたま"ふらっと寄った新大阪の某所で売られていた6月号を
購入しさっそく基板を動かして見ました。
…なんかねむいさん変てこりんなこと言ってるような気がしますが多分
気のせいです。あと国産マイコンは絶対に扱いませんといっときながらFM3は
使うのかという突っ込みに対しては中身は英国製ARMコアなのでノーカウントと
させていただきます！１１！！！！
…さて戯言はこの辺にして、今年1月ごろにはすでに基板に関する情報が
出回っていたので先回りしてデータシートやマニュアルを熟読しSystickを使用した
簡単なプログラムを作成、いわば予習はすでに行っていました。
とはいえそれ程仰々しいものでもなく、最早慣れ親しんだCortex-M3だったので
LPC1343とSTM32F107の物をベースにしたスタートアップコードやデータシート
首っ引きでリンカスクリプトをこしらえGCCでビルド・デバッグ出来る物をサクッと
やっけつました。
正直LPC1788の時の方がむずかしかったです。
そしてビルドして出来たバイナリをMB9BF618Tに書く手段ですが‥‥、
これが都合よく少し前にOpenOCDにFM3マイコンのフラッシュ書き込み
ルーチンが実装されていました。
なおかつjujurou氏が別型番のFM3マイコンにてOpenOCDからの書き込み・
デバッグをした時の成果をすでに残されていたのでこちらもありがたく使わせてもらい、MB9BF618Tのフラッシュ書き込みにも対応したOpenOCDを作成し、
万全の体制で今日を迎え撃ちました。
結果ですがOpenOCDからプログラムの書き込み・デバッグに無事に成功です！
↓書き込み時に出るOpenOCDのメッセージはこんな感じです。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00527-gf908bae-dirty (2012-04-24-21:47)
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: 0x20000000
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
verified 804 bytes in 0.421877s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invokedリセット時の内部発振4MHzで動いてる状態です。今後クロックアップさせる
予定なのでもう少し使い勝手が良くなるでしょうね♥
…ぇ？俺も早くOpenOCDビルドして試してみたいですって？
…ふっふっふ、とっくに対応済ですよぅ？
という所で本日試したPORTF3にぶら下がったLEDを点滅するだけのもの
すごく単純なFM3基板(FRK-FM3でしたっけ)向けのGCCでビルドできるプログラムは
こちら。
また、↑をビルドするための超分かりやすいビルド方法はこちらになります。
↑をデバッグするための超分かりやすいデバッグ手順はこちらになります。
そうだね宣伝ｄ(ry
今はLED点滅だけですがこれにUART経由の文字列出力等の基本的なのを順次アップ
デートしていきます。私はSTM32F4弄るのがメインなのでFM3にはそこまで興味は
無く、予定は大幅に伸びるでしょうけども6月の半ばにはいつものがおきぱに現れ
て皆が利用できる状態になるとおもいます。
20120425追:
●OpenOCDからのフラッシュ書き込み速度をアップさせる試み
system_mb9bf61x.c内のSystemInit(でしたっけ？)関数のPLLを使ってクロック
アップしているルーチンをOpenOCDのスクリプトに落としてみました。
ただし、汎用性を保つために大元のメインクロックは外部のシリコン発振器
からの4MHzではなく内部RC発振の4MHzを使用し叩きあげるようにしました。
↓で、こちらが昨日と同じバイナリを書き込んだ結果です。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/mb9bf618t_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00529-gf28a5d9-dirty (2012-04-25-13:27)
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: 0x20000000
Rize up to Internal PLLed Clock!
6000 kHz
auto erase enabled
Info : Fujitsu MB9Bxxx: Sector Erase ... (0 to 0)
Info : Fujitsu MB9B500: FLASH Write ...
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
verified 804 bytes in 0.421878s (1.861 KiB/s)
Info : JTAG tap: mb9bfxx8.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
shutdown command invokedwrote 16384 bytes from file main.elf in 2.046889s (7.817 KiB/s)
だったのが
wrote 16384 bytes from file main.elf in 1.671886s (9.570 KiB/s)
と結構改善してます。比較元のサイズが小さいので分かりにくいですが、バイナリの
サイズがさらに大きくなると違いがさらに出てくることでしょう。
もちろんこちらにも反映済みです。
●毎年恒例の電源ラインは大丈夫か？
※使用したもの
・PCのUSBポート
・Interface2012年6月号付録のFM3マイコン基板(LED点滅書き込み済み)
・5mのUSBA-miniBケーブル+1mのUSB延長ケーブル
・テクトロのオシロ
※USBコネクタを指してPCのUSBポートから+5V電源を供給した時の+5Vラインと
レギュレータ出力の+3.3Vラインの電圧波形を見る
+3.3vの立ち上がり時に+5Vラインが一瞬突入で1Vほどドロップしてるけど
以前みたく上に跳ねてはいないので基板単体で見たら大丈夫だ、問題無い。
※144MHzで動作中の時の+5Vラインと+3.3Vラインの電圧波形を見る
大丈夫だ、問題無い。
※USBコネクタをPCのUSBポートから引き抜いて+5V電源を断った時の+5Vラインと
レギュレータ出力の+3.3Vラインの電圧波形を見る
大丈夫だ、問題無い。
※総評
大丈夫だ、問題無い(イーノックみたいな顔で)
…ってねむいさんが太鼓判押したら大抵悪いこと起きるんですよね〜
STM32F4シリーズを使ってみる5 -libpngを実装する-
誘惑に負けて買ってしまった…盈钰電子のSTM32F4ボード…
176pinなSTM32F407IGT6,1MBSRAM,NAND&NORFlash,HS-USBPHY,Ethernet,I2SCodec,camera....
そして3.2inchのTFT-LCDまでついてオトクな699RMB!
日本円単純換算でも10000円以下の超格安です(2012/5上旬現在)
本来ならばREDBULLの基板をベースにやるべきですが費用対効果が最高なので購入した
方が早いっちゅーことで…しかもSTM3240G-EVALの回路にほぼ互換なのでSTさん提供
のサンプルなんかもほとんど素で動かせられますのでこいつでいろいろ学習していき
ましょ♥
だめだ私すっかりSTM32漬けだ…
さて、前回さらっとご紹介しましたが、libpngのSTM32F2/4への移植についてお伝え
します。私たち虹メにとってpng形式の画像ファイルはコラ等で非常に身近なもので、
jpeg形式と同じく大量に扱われています。それをマイコンでデコードし表示できる
というのはとても有用性があるわけで、かねてからの悲願がかなった形でもあります。
今回は実際の移植の手順も合わせてご紹介します。
●必要なもの
libpng
これは必須ですね。少し前にlibpngのセキュリティホールが発見されているためバー
ジョンには気を付けてください。今回は"libpng 1.5.10"を使用します。
zlib
pngファイルの実画像データは可逆圧縮されていてDeflateと呼ばれる圧縮技術が使用
されています。libpngはDeflateアルゴリズムを処理するためそのライブラリである
zlibの一部コードを必要としています。今回は"zlib 1.2.6"を使用します。
MCU
libjpeg(IJG Jpeg Library)と同じくlibpngはRAMを大量に消費します。
内部SRAMが96kByte以上あるマイコンならQVGAサイズまでなら何とか表示可能です。
●ファイルI/O
こちらはlibjpeg(IJG Jpeg Library)と同じ要領でChaN氏のFatFsと連動させます。
sirius506氏、そら。氏のlibjpegの移植例を参考にしています。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数の上にあるfatfs_read_data()を読み進めてください(丸投げ！)
●makefileに追加するCソースファイル
こちらのSTM32F4サンプル中にあるlibpng.mkを見ていただければわかりますが、
pngファイルの読み取りのみに限ると以下のファイルだけが必要となります。
-libpng
png.c
pngerror.c
pngget.c
pngmem.c
pngpread.c
pngread.c
pngrio.c
pngrtran.c
pngrutil.c
pngset.c
pngtrans.c
上記のうちpngerror.cは一部内容の書き換えが生じます(後述)
-zlib
adler32.c
crc32.c
inffast.c
inflate.c
inftrees.c
zutil.c
ヘッダファイルの方については念のためオミットせずに全部ぶっこんどいてください。
また、libpngを解凍したディレクトリ中の./scripts/pnglibconf.h.prebuildをリネ
ームしpnglibconf.hとしてソースと同じディレクトリにぶっこんでください。
●ARMマイコン上で動作させるための少しの変更
x86なWindowsシステムで動作させるわけではないため、エラー表示などのコンソール
I/Oの処理のオミットは必須です。
pnglibconf.h中のPNG_CONSOLE_IO_SUPPORTEDとPNG_STDIO_SUPPORTEDの
定義はコメントアウトしておき、さらにpngerror.c中のpng_default_error
関数はfprintfからprintfに変えておきます。
(printfのリダイレクトが必要無い場合はすっからかんでもいいです)
ねむいさんの環境では書き換えたファイルはpngerror_std.cとしています。
20140731追:
↑バージョンが上がってヘッダの#defineをコメントアウトすればよくなりましたので
pngerror.cに手を加える必要がなくなりました。
また、txtとハードウエアの倍精度浮動小数点演算、インターレースのサポートも
行わないのでpnglibconf.h中の以下の定義もコメントアウトです。
PNG_READ_INTERLACING_SUPPORTED
PNG_FLOATING_ARITHMETIC_SUPPORTED
PNG_WRITE_zTXt_SUPPORTED
PNG_WRITE_iTXt_SUPPORTED
PNG_READ_zTXt_SUPPORTED
PNG_READ_iTXt_SUPPORTED
PNG_zTXt_SUPPORTED
PNG_iTXt_SUPPORTED
元からコメントアウトされていたものについてはそのままにしておいてください。
さらにpnglibconf.h中のZBUFFERの確保量(PNG_ZBUF_SIZE)をSDカードのセクタ
サイズである512バイトに合わせてください。これ以上の
値にすると512バイト以上読み込んだ際にエラーになりデコード不可能になります。
また、残念ながらlibpngにはlibjpegのような1/(2^x)にするサイズスケーリングは
ありません。
●libpngを呼び出し、画像データを表示する
大まかに分けて以下の順番で実行します。これらは必須です。
1.png_create_read_struct関数でpngファイル全般を制御するポインタ確保
2.png_create_info_struct関数でpngファイルの情報に関するデータをストアする
ポインタ確保(IHDRとIENDチャンクの分）
3.エラーハンドリングの設定
4.png_set_read_fn関数でfatfsのpngファイルポインタと連結
5.png_get_IHDR関数でIHDRチャンクの読み出し
6.画像の形式を24bitRGBに変換する。
7.画像のx,yサイズのチェック(1280pixel以上は撥ねる)
8.png_get_rowbytes関数で1行あたりのバイト数取得
9.png_malloc関数で"6."で取ったバイト数分の配列確保
10.png_read_row関数でIDATチャンクを一行ずつ読み出し、さらにRGBデータ幅を24bit->16bit
に落としてTFT-LCDに表示していく
11.表示が終わったらpng_free関数"7."で確保した配列を解放
12.png_read_end関数でIENDチャンクを読みだす。
13.png_destroy_read_struct関数で"1.""2."で確保したポインタの解放
気を付けなければならないのは各処理ごとにエラーを検知しておかしい場合は先の
処理に進ませないようにすることです。これを怠るとHardFaultに簡単に陥ってし
まいます。またIDATを読み切ってない場合にpng_read_endを実行すると即座にエラ
ーになりますのでTFT-LCDの解像度より画像サイズが大きい場合でも必ず空読みして
読み切ってください。この手順は24bitのpngを想定していますが異なる形式の場合は
24bitに変換するために"5.""6."の間に各種transformの処理が必要です。
実際にどうやってるかは私のサンプルの./lib/display/abstract/src/ts_fileloads.c
にあるload_png関数を読み進めてください(丸投げ！)
一回の表示で消費されるRAMはlibpng自体が必要とする量が約33kByte(デバッガの
追跡により使用量を算出),それに加えてTFT-LCDに表示する際のデコード済みの
データを置くバッファも必要とされるため結局以下の計算式で総消費量が求められます。
NEEDED_RAM_AMOUNT = ((XSIZE-1)*4)Byte+33kByte
式中のXSIZEはTFT-LCDのX軸方向最大ピクセル数ではなくpng画像データのX軸方向
最大ピクセル数です。つまり幅が広くなればなるほど使用するRAMの量が増えます
(libjpegもこの点は同じ)。また、今回のデモはアルファチャンネルを強制付与して
いるため(RGBAのならびになるため)(XSIZE-1)*3ではなく((XSIZE-1)*4)になります。
●実際の表示
今回の検証用のTFT-LCDとして320x480なTFT1P2797-Eを使用します。大規模マイコン
用のディスプレイとしてねむいさんのイチオシです♥
検証用の画像はこちら。こちらのサイトのキャラクタージェネレーターを使って作成した画像に
さらにコラージュを加えた私服のいないさんです。メイド服にコラしたかった
のですが髪型だけで力尽きましたorz…これをTFT-LCDに表示してみます。
ビット深度は24bitのトゥルーカラーです。
表示ルーチンとしてまず画面左上に画像の情報を出すようにしました。
col_depthはビット深度で8*(RGB)で上記の24bitとなります。
col_typeはpngの画像タイプで0がグレイスケール、3がインデックスカラー、
2がトゥルーカラー、6がアルファチャンネル付トゥルーカラーです。
実際の表示に関し、グレイスケールやビット深度が小さい画像も24bitに変換してい
ます。また透過pngやアルファチャンネルつきの物はいったんアルファチャンネルに
変換して、1ピクセルごとのアルファチャンネルを示すバイトは書き込み時に無視して
います。インターレースpngの表示はは私のサンプルではサポートしていません。
誰か腕に覚えのある方実装おねがします…。
てわけでPCとまったく遜色ないレベルでいなちゃんを表示することができました！
メモリが豊富な環境ではpng_read_image関数で一気に読み込みできるのですが、STM32
等のマイコンでは到底足らないので、1行ずつバッファに読みだして表示を行います。
読みだしたデータはRGBの順番で並んでいて8+8+8=24bitで1ピクセルとなります。
最終的にTFT-LCDには5+6+5=16bitにして書き込み、表示させます。
透過PNGを表示させるとこんな感じになります。前述の通りアルファチャンネルは
読み捨ててるので透過部分はRGB(0,0,0)の黒色で表現されています。また解像度の
関係で表示が隠れてしまったのですが、アルファチャンネル付トゥルーカラーに
変換された透過pngを示しています(赤で囲った部分)。
TFT-LCDのサイズよりオーバーする場合の画像では当たり前ですが画面外のデータは
表示できません。また画面からはみ出ている部分もpng_read_rowで全部読み切ってし
まわないとエラーになったりHardFaultに陥ってしまうので注意です。
ChaN氏のbmp表示ルーチンを見習って大きい画像でもUARTからのコマンドで仮想的な
表示開始位置を変えて表示できるようにするのが今後の課題ですね〜
ちなみのこのaraiさんの描いたねむいさんの絵はアダルツなのでこのブログ的にも
見えてない部分は…ｹﾞﾌﾝｹﾞﾌﾌﾝ失礼
減色とかグレースケールにした時の比較です(注：表示の際はすべて24bitのトゥルー
カラーに変換されています。左上の数値は変換前の情報です)。
ビット深度24bitトゥルーカラーの標準的なねむいさんです。
col_depthが8になってますが実際は8bit*3で24bitとなります。
256色のインデックスカラーはこんな感じに。
24bitのグレースケールはこんな感じ。
8bitに落とすとこんな感じ。
さらに4bitに落とすとこんな感じです。
というわけで通常のPCと同じようにpngファイルの表示もSTM32F4上で可能と
なりました。しかしながらメモリはかなり食いますので内蔵SRAMが豊富にある
STM32F4専用の機能ですね〜。
libjpegと絡めると空いた時間でお茶が飲めてしまうくらいビルド時間も
倍加されてしまいますのでご注意ください。
東海自然歩道を徃く15(定光寺〜猿投神社/猿投神社〜香嵐渓/香嵐渓〜伊勢神)
前回は恵那ルートを経由して奥三河の田口まで進みましたが、今回の3行程は
定光寺〜寧比曽岳までの本線ルートを進みます。この本線ルートは根拠なく
恵那ルートよりも安易かと思い込んでいました。しかし思わぬ場面で何度も
苦戦を強いられてしまいました。
●2012.02.26 定光寺〜猿投神社
三河ステージ(注：本線ルート)の最初、定光寺からスタートです！
定光寺の分岐点ですが奥に見える階段は絶対に上がってはいけません！
矢印の通りに進んでください！最初の地点に戻っちゃいますから…
定光寺です。ここによると結構なよりみちです。
上から読んでも山星山
下から読んだらまやしほまや
すでに橋が存在しない稚児橋です。
ここから先はハイカーの方達と多数すれ違いました。
中平橋を越えて…
なぜかヤギ…img虹裏では仔ヤギをコンク(ry
白岩の里を越えると沢沿いに登って本岩巣を目指します
さらに先の雲興寺の迂回路の情報がありました‥いける！？
この日は晴れていてハイカーの人も多数いました。
最徐行で進み本岩巣の展望台に。
岩屋堂です。その周りにはかなり広い岩屋堂公園があります。
もちろん迂回路は進むつもりはないのでこの赤い橋を渡って
東海自然歩道を突き進みます！
で、問題の個所に差し掛かりました。見た目はダイジョブそうですが…
この看板のすぐ左にさらなるう回路の表記があります。"ノープロブレムOK"の
書き込みの迂回路に従って(結構傾斜きついですが)注意深く進みました！
通行禁止になったのはポイ捨てと無断伐採に業を煮やして東大演習林に被るルート
を禁止にしたため。
危なげなく雲興寺に到着です。ここで小休止して猿投山に登る力を溜めます。
猿投山は超人気のハイキングコースなので整備も力入ってますね！
道標の道なりに進んでるとどう行ったらいいか分からなくなってしまいました‥。
東海自然歩道の道標っぽくないけど猿投山頂上の道しるべを発見！
はぁはぁ…なんだこれえらいきづいぞ…さすが猿投山…！
しかし…
！！！…やっぱりね…そんなこったろうと思いましたよ…
…うっかり虹弦流いんちきショートカット発動させちゃったみたいですorz
ここからすぐに頂上に到着しました！ん〜〜いい眺めですね♥
…おや…何か張り紙が…
貼りたてほやほやの警告文が…
地図作った人は親切心からなんでしょうけど良かれと思ってやったことが
あだになるとわ色々損してる人なんでしょうね(哀)(←ねむいさんも同じ性格)
頂上から抜けてすぐ先のカエル岩も…
落書きは止めましょう
気を取り直してグングン駆け下りてくと猿投神社東の宮とこの地域に
特徴的な花崗岩の解説文が出てきました。
道はアスファルトの車道と合流し、再現された水車を越えてさらに速度を
あげて行きます。ゴールの猿投神社まであと少し！
かなり距離長い上に山越えがあるので9時間ほどで見積もってましたが
予定よりかなり早く猿投神社に到着です！
…ってわけで早く着きすぎたのでバスを待たずに徒歩で猿投駅に向かいました…
メモして覚えたかんな！！3日後100倍だかんな！！
ｹﾞﾌﾝ失礼…名鉄三河線猿投駅に到着です。
知立・名古屋を経由して京都へ。
●2012.03.08 猿投神社〜香嵐渓
猿投駅からバスで猿投神社に行くルートは無いので上豊田駅から
おいでんバスで猿投神社へ――
今回は諸般の理由で一気に決めて切り上げたい、そんな気持ちが焦り過ぎて
ルートミスしまくりましたorz.
約10年くらい前にルートが微妙に付け変わったそうです。
猿投神社横のこの道標を頼りに進みます。
棒の手周辺は前途の理由で道標が無くなります。
ここはまっすぐで。
そしてサークルKのある交差点を右に、そしてずっとまっすぐ。
上中山のバス停も越えて…
西中山交差点で左折。
さなげ足助バスの待機所？みたいなとこをこえてすぐの箇所に
東海自然歩道の道標があります。
しばらくの間昭和の森という個所を通過します。
ここまでほぼアスファルトです。
道がトレイルにかわり、ゆるい登坂を続けると地元の子供たちが
整備しているいっぷく峠に。
さらに広瀬に向けて下るとくじ引き付きの休憩所が。
広瀬橋を越えて三河広瀬駅跡に向かいますが…
やな・・・やな・・・ほマ新チｗ？
ｹﾞﾌﾝ失礼、三河広瀬駅跡に到着です。
三河田口のような木造の駅舎ですが、現役時代より整備の手が行き
届いていました。
駅舎内はかつての写真がありちょっとして資料館になっています。
また、三河線の廃線となった猿投〜西中金＋未成路線の西中金〜足助間を合わせて
"でんしゃみち"として整備する計画があるようです。
バス停多すぎですが三河広瀬駅前は今でもバス路線接続の要衝として
利用されています。
猿投グリーンロードを越えて勘八峡まで降りてきました。
足元にはテントウムシさんが…
その先の勘八牧場はとっくにつぶれてNPOの農業演習地として利用されています。
牧場の区間を抜けて少し駆け下りると千鳥寺に着きます…が、
奥につづくアスファルトの道は私有地なので行ってはいけません！
東海自然歩道は寺の手前の解説板の個所で右折です。
千鳥寺です。ねむいさん知らずに奥の車道をつっ切ってしまいましたorz
とは言え合流するんですけどね…。土のうのつんであるトレイルに進みます。
本山中の集落を抜けてさらに山道に入ると本山中峠に。
ここは下りがやたら滑りやすいので注意！
大国橋に向かう途中の集落では道標が高い位置にありなおかつ
形状が違うので注意してください。
写真にしめす個所も道標が無いので矢印の通りに進んでください。
大国橋を渡り巴川沿いのトレイルをひた走ります！
道はやがてアスファルトの車道に合流します。香嵐渓まで
さらにスピードをあげて(るつもりですが)ひた走ります！！
小原橋まで来ました。足助はもう目の前です！
足助大橋に。あと少し！！
予定時間を15分過ぎですが、足助八幡宮に到着！
足助八幡宮を抜けるとすぐ目の前に香嵐渓バス停があります。
今回はここで離脱して帰還します。
…といいたいところですがここ足助では中馬のおひなさんの展示が行われていたので
いろいろ見て回りました。以下にギャラリーを…。
喰ってばっかですね私…。痩せない
とよたおいでんバスに乗って猿投駅へ。
次回でこの駅ともお別れです。
●2012.03.17 香嵐渓〜伊勢神
この日の天気予報は雨のち曇りでした…雨がやんでくれると信じて…
しかし…
香嵐渓についた頃にはさらに雨足が強くなってやがりましたorz
しかし私は刃牙の柔道キャラ(畑中公平さん)の打撃対策並みに降雨対策を完璧に
してきましたので覚悟を決めて進みます！
目指すは三河最高峰・寧比曽岳！
雨強すぎて写真撮る隙がありませんorz
安美京です。
有洞にある大きなヒノキと小さなお寺です。
(よく分からないが雲の中にいる模様)
綾渡平勝寺です。
予定時間を30分オーバーしてしまってるので先を急ぎます…！
※ねむいさんのちょっといい話※
京都でこの後ろの二文字使うともれなくヤクザに恐喝されます。
金蔵連峠に到着です。
朝から降り続いた雨が小路を伝って至る所で小川になってしまってます。
ぬかるみを踏むと滑って逆に危険なので草木の少し生えた個所を
通過します。
金蔵連峠を越えたあたりから林道と交差しつつ寧比曽岳への登坂が
始まります！ぬかるみで転倒しないように警戒度を最大にして慎重に進みました！
防火帯なる個所もいつくか見られます。
ここは風雨が遮るものが無いので足早に通り過ぎないといけません。
筈ヶ岳への分岐‥を降りる個所がまたすさまじい急坂です。
この天候だとそのまま下りると危険なので林寄りに進んでクリア。
登り切ってから撮影しましたが、この地点も超危険ポイントでした。
結局業を煮やして四足獣歩行体勢になってサクッとクリアしましたが、
100m進むのに20分くらいかかりましたorz
危険地帯を抜けると足場もしっかりしてきて周りの景色も自然林に変わってきました
頂上はもうすぐです！
ッッ着いたー！寧比曽岳頂上！
ものすごい強風の上、雨がみぞれになって叩きつけてます。
しかし、あらゆる強化を加えたSTM32Primer2さんは涼しい顔でGPSモジュールから
送られるNMEAを淡々と記録しています！(ピンク色の物体)
おそらく世界で一番厳しい環境で稼動してる個体だと思います(地獄のミサワみたいな顔で)
さて、今回で本線ルートである三河ルートは全走破となり、
これよりルートを離脱して伊勢神に帰還します。
またいつかこの場所に来ることになるでしょう…。
前回は雪で埋もれていた亀の甲石です。
大多賀峠に。ちょっと飛ばして時間に余裕ができたのでそのまま
東海自然歩道を進みます。
伊勢神湿原の説明版です。もう水浸し。
伊勢神遥拝所に到着です。ここも訪れるのは今回で最後になります。
伊勢神峠・旧伊勢神トンネルも写真に収めてきました。
あとは勝手知ったる道を駆け下りてゴール地点の伊勢神ドライブインに
予定時刻より少し早めに到着しました。今回はかなりの悪天候でしたが装備と
その場の臨機応変な工夫で危なげなく乗り切ることができました！
前回は時間が無かったので寄れませんでしたが伊勢神ドライブイン名物の
カレーパンの購入も成功し、頬張りつつとよたおいでんバスに乗って帰還しました
喰ってばっかだと痩せないですけど入る場所が違うので無問題です！
東海自然歩道を進むためにはルート・アクセス・天候などのすべての事前リサーチが
非常に重要なわけですが、今年に入ってからやっとこ体系付けた手法でデータ集めを
することができるようになったおかげで過密スケジュールでも上手くやってこれるよ
うになりました
(思わぬ副収入が入って新幹線代が圧迫しなくなったのも一因です)。
今季の残り２行程は東海自然歩道三大難所のうちの一つ、田口〜三河大野の縦走です。
最後まで気合い入れていきます！
定光寺〜猿投神社 GPSログ
猿投神社〜香嵐渓 GPSログ
香嵐渓〜伊勢神 GPSログ
STM32L-Discovery(STM32LDISCOVERY)をいろいろ使う
…ッッ…や、やっとEtherPod(STM32F107VCT6)にFreeRTOSとuIP実装してその上に
DHCPクライアントとDNSレゾルバとHTTPDとそして目的のNTPから時刻合わせ機能
の実装まで完成した…！uIPやFreeRTOS付属サンプルだけだとこんなん絶対でき
ませんわこれ…。先達たちがネット上に残した知恵を探しだすスキルが鍛えられました。
とにもかくにもこれで漸くこの子を卒業してSTM32F4系EthernetとLwIPに手を…！
ところでなんで去年の9月にできたこともう一度やってるかと言うと、ソースコード入
ったUSBメモリを地下鉄の溝に落っとこして壊してしまって１から全部作り直しになっ
たからです‥‥‥‥orzｶﾂｶﾂに作りこんでてバックアップをサボってるときに限ってこ
ういう事が起こるというorzorz
ちなみに虹裏上の活動で作ったり描いたりしてきた絵やとしあき君&｢｣からの大切な頂
き物は、4重のバックアップ体制で自宅が爆発しようが京都府に巨大隕石が落ちてクレ
ーターになろうが核の炎に包まれてシェルターにどう詰めてもあと二人しか入らないと
言われた瞬間にケンシロウに｢ﾄｷ兄さん!｣と言わせる間も与えずｸﾞｺﾞｺﾞｺﾞｺﾞと扉閉めてあげ
て二週間後にや、やぁ…と余裕こいて挨拶できるくらい絶対に失わないようにしてあ
りますのでご安心くださいまし(ﾆﾔ･･)。
さてさわりはこの辺にしといて前回ほんの少しお話したSTM32L-Discoveryにごく基本
的ないつものを実装したのでご紹介します。
Discovery系で比較される対象はSTM32F100RBT6が載っているSTM32VL-Discovery
ですが、実際はこちらのSTM32L152RBT6が載ったSTM32L-Discoveryの方がはるかに
性能が高いです。
↑ねむいさんが目を付けためぼしい機能比較
STM32L系のほうが後から開発されたので当たり前と言っては当たり前なのですが、そ
のせいかバスの構成やペリフェラルのレジスタ構成などはSTM32F2/4系のMCU群と酷似
しています。私もそうでしたが、移植される方はSTM32F2/4系からのほうが楽です。
今回のいつもの(= FatFs + TFT-LCDドライバテストプログラム)について、当基板に
タッチセンス用のパタンとSTマイクロ謹製のSTM32L向けタッチセンスライブラリが用
意されているのでこちらも入力系に組み込んでいます(基本はUARTの入力のみです)。
お肌が乾燥してるとタッチセンスの入力が無反応になることがあります。S**Kです。
使用するピン/ペリフェラルの構成としてはSTM32VLDiscoveryの時となるべく似せる
ようにしてみました。今回もI/Oリソースの有効利用のためにSWD接続のみで書き込み
デバッグを行うようにしました。STM32L152RBT6は外付けの水晶を付けるとUSBも使用
できるのでこちらも試してみたいと思います。図中のLCDとあるのはLCDグラスドライ
バのことではなくいつものMCU接続タイプのTFT-LCDを指します。
あと使ってて気づきましたが、クロック周波数や多ピン品種の外部バスサポートとか
の超低消費電力とかのうたい文句見てるとXMEGA系みたいな8/16bitのアーキテクチャ
で大規模化したマイコンを潰しにかかってるなぁと感じましたね。どっちも使ってい
る私が言わせてもらうとどう見てもARMのほうが扱いはるかに楽なんですもん…
FatFSのDMA化も楽にできましたし！(←まだ根に持ってる)
動かしているところです。ChaN氏のファイラは上述のとおり定番のUARTの他に基板上
のタッチセンスパタンからも入力可能です。タッチパネルTFT-LCDモジュールの時と
微妙に勝手が違うので差の吸収するために入力方法に工夫してあります。
既におきぱにある他のマイコン向けのデモも順次更新していますが、がた老氏が私の
移植例を使って成功したのを受け、デモ内のファイラにChaN氏のTextファイルビュー
アも盛り込んでいます。(STM32F107系は先行して公開してます)
ついでですが、XMEGAのFatFsのサンプルも大幅更新してます。ChaN氏の最近の実装を
参考にファイラをVRAMを使用しない構成とし、以前は出来なかったQVGAの解像度でも
ファイラを使用できるようになってます。もちろんTextファイルビューアや動画も(遅いですが)
再生可能になりました！
またまた話が逸れますがFatFsのSTM32・LPC2388(LPC1788も近日公開予定)・XMEGAへの
移植例としてChaN氏からリンク貼ってもらってるおかげで海外からのアクセスがうな
ぎ登りになってます。その9割が共産圏(元共産国含む)なのは置いといて海外から来た
人たちのためにリンクをわかり易くしました。これでもう"HENTAI-Siteに飛ばされた"
とは言わせませんよぅ！
日本国内についてはどうかというとアクセス解析やSNS等の発言をリサーチした限りでは私
の作例を参考にされてる方はlinux系OS使いな方たちが圧倒的です。Windows系の場合、
無料で利用できる統合開発環境はかなりの選択肢が存在しています。はじめてSTM32を
触る方々にとっては私のコマンドラインビルド中心な"どういう風にプログラムを組むか"
が主体のブログは全く参考にならずむしろ"その統合開発環境をどう使いこなすか"ことこ
そが往々にして最重要課題となるので、中身のないこと長々と書きましたが私は素の
Eclipseは使いませんったら使いません！！１！メーカお仕着せのやつでも拒絶反応ｇｇ
はぁはぁ…失礼…また話が逸れてしまいました‥
ぇっと後は書き込み/デバッグについてですが、前回ご紹介した通りSTLink/v2に対応
したOpenOCDからすべてを行います。また、私の作例中のmakefileをみたらすぐにわか
るはずなのですが、各デバッガハードウエア&MCU向けのcfgを引数にとってさらに
cfgに記してあるフラッシュ書き込み用のプロシージャコールを呼び出せばtelnetを接
続してﾁﾏﾁﾏしなくてもOpenOCD単体でフラッシュに書き込みができます。
↓STLink+OpenOCDから書き込むとこうなります。
(この記事を書いた当初はLibUSBを使用しておりました)
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f target/stm32lx_stlink_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
1 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Info : clock speed 1 kHz
Info : IDCODE 2ba01477
Info : stm32lx.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bf74 msp: 0x20004000
auto erase enabled
Info : flash size = 128kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x20000012 msp: 0x20004000
wrote 114688 bytes from file main.elf in 12.796548s (8.752 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20004000
verified 111172 bytes in 0.515612s (210.558 KiB/s)
shutdown command invoked前回触れたAsynchronous Algorithmルーチンはすでに最新のコミットに取り入れられ
ています。
確認も終わったのでSTM32L-DiscoveryのSTLinkもVersaloon化しちゃいました！
ローダ共にSTM32F4Discoveryのものと全く同じのが流用できますが、こちらに
STM32LDiscovery用のを用意しましたので興味のある人はどうぞ。
するメリットはUSB仮想COMが使用できる点に
尽きますね♥
※大事なことなので何度でも言います
あと注意点ですが、STM32LDiscoveryは外部リセット入力回路のプルアップ抵抗が省略
されています。R37に10kohmのチップ抵抗を必ず付けてください。
↓Versaloon化+OpenOCDから書き込むとこうなります。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/vsllink_swd.cfg -f target/stm32lx_swd_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00448-gc59a441-dirty (2012-03-01-10:03)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Warn : must select a transport.
Info : OpenOCD runs in SWD mode
100 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : Versaloon(0x34)by Simon(compiled on Feb 29 2012)
Info : USB_TO_XXX abilities: 0x00000008:0x00000040:0xC0000006
Info : clock speed 100 kHz
Info : stm32l.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800bcb8 msp: 0x20004000
STM32L: Enabling HSI
2000 kHz
auto erase enabled
Info : flash size = 128kbytes
wrote 110592 bytes from file main.elf in 17.983915s (6.005 KiB/s)
verified 110492 bytes in 1.140595s (94.602 KiB/s)
shutdown command invokedんんｎ、現在の実装だとswdのクロックを途中で高速に変えられないので
ちょっと微妙ですね…128kByteしかないしまぁいいですか。
正直言うと素のSTLinkでもかなり使い勝手がよくなったので初めて触られる人は
無理にVersaloon化しなくても十分やっていけます。
いやはや良い時代になったものです。
東海自然歩道を徃く14(明智〜伊勢神/伊勢神〜田口)
私は現在、奥三河と呼ばれる交通の便がかなり悪い地域を目指しています。
なんというか現地への移動時間＞＞＞＞行動時間になっちゃってますが、分刻みの
行動スケジュールで動き、少しのルートミスが命取りになるこの辺りのルートは別
な意味でスリルがあります。ねむいさんは知恵と体力と財力でかろうじて切り抜け
ていきました！
●2012.01.28 明智〜伊勢神
いきなりスタートで躓きましたorzなんと中央線の到着が遅れ、瑞浪駅で明智駅行
きのバスに乗り過ごすことに！！…私は帰りの伊勢神峠で最終バスを乗り過ごした
ときの最終手段でタクシーで帰還するつもりにとっておいたトラの子タクシー代
1万円をここで切った！
…タクシーの運ちゃんの運転がWild過ぎてアドレナリンが異常分泌した状態で
アップの必要なくスタートぉ！エントリポイントの八王子神社境内を通過します！
明智光秀や遠山の金さん？の墓があるらしい龍護寺です
大正浪漫館です。この建物の右側を通過します
千畳敷公園からの展望です
♪FULL FORCE 誰よりも速く 明日を見に行けば
自分の足跡だけが 残されて行くのさ
…｢｣にいつも叩かれてたけどねむいさん仮面ライダーカブト好きなんですよぅ…
ここは間違えやすい有名な分岐です！写真の通りに進みましょう
颪と呼ばれる場所まで下りてきました。しばらく川沿いの車道を走ります
？
？？？
串原太平を過ぎて黄梅院に立ち寄りました
柿畑を越えて行きます。電流柵も越える！
三本松休憩所でトイレ休憩を
oh...
閑羅瀬橋を越えると川原越以来長らく続いた岐阜ステージともようやくお別れです
矢作ダムを遠くに望みながら愛知ステージを進みますが‥クマの足跡？
クマに出くわすことなく旭高原少年の家を過ぎ旭高原元気村に到着です。
少年の家を越えたところでオリエンテーリングコースに入ってしまい
時間を喰ってしまいました
長井坂峠を一気に駆け下りた後千人塚と弘法杉がある猿が城登山口に。
再びだんだんと雪深くなってきました！
崩れそうな木階段を登り猿が城跡のある頂上に。今は鉄塔が立っています。
その後は縦走を繰り返し、林道に到達します。
ここから林道の登りです…
林道のピークを越えて一気に駆け下ります！！アイスバーン盛りだくさんの
かなりヤバい道でしたが、ねむいさん人間ができてるから私のぶろぐ見て
くれてる受験生のために滑ったりこけたり落ちたりしませんでしたよぅ！！
一気に駆け下りたあとさらに昔の峠道を登って八百比丘尼の杉と伊勢神峠に！
あと少しで今日のゴールです！
伊勢神遥拝所です。ここが次回のエントリポイントとなります
時間が少し余ったので旧伊勢神トンネル(伊世賀美隧道)に立ち寄りました…狭い
20121107追：
たまに質問もらいますが、"旧々伊勢神トンネル"なんてものは存在しません。
まず伊勢神峠・伊勢神遥拝所が最高点に位置しており、時代によって
伊勢神峠(中馬街道(飯田街道,塩の道とも))
-> 旧伊勢神トンネル(旧国道153号線/伊世賀美隧道が正式名称)
-> 伊勢神トンネル(現国道153号線)と
幹線道路が変遷しているので旧伊勢神トンネルより高い位置にトンネルは掘れません。
完全にガセネタです。
20131222追：
以前はガセネタと切り捨ててしまいましたがなななんと!あと10年くらい待つと
新伊勢神トンネルがさらに新しくできるらしいのでそれに伴って現在の
旧伊勢神トンネル(伊世賀美隧道)が自動的に旧々伊勢神トンネルになります！
おめでとう！
アイスバーンだらけの舗装路をかわしつつ駆け下り、今日のゴールである
伊勢神ドライブインに到着予定時刻より1時間早く到着です！とよたおい
でんバスもちょうどいいタイミングで来ました
2012年現在はパス一発で東岡崎に行ける路線が存在しないため足助でバスを乗
り継いで東岡崎へと帰還しました…うう冷える
●2012.02.11 伊勢神〜田口
新幹線乗ってる時間よりバスの移動時間の方が長いです…おしりが早くも痛いです‥
や、やっと伊勢神ドライブインに着いた…
今回はゴールの田口のバス停の発車時刻が18:14でかなり時間が余るため後述しますが
寄り道プランを立てています。11:00の出発となりますが綿密な事前リサーチのおかげ
でこれでも十分間に合うわけです。
前回のおさらい、伊勢神峠と伊勢神遥拝所に。
今日はここから寧比曽岳を越えて田口まで向かいます。
閉鎖されたいこいの森がある伊勢神湿原を越えていきます。
雪だらけでよく分かりません‥。
大多賀峠に。ここからは登りの一方となります。
有名な亀の甲石も雪に埋まっています。
頂上に向かうにつれて樹木が雪の華を身にまとっていってます
パウダースノーの作りだす幻想的な景色にみちびかれ頂上に――――
っ着いた〜！寧比曽岳頂上！
ここが東海自然歩道恵那ルートと本線ルートの分岐点となります。
都合上私は再びここを訪れることになります。
ゆっくり休憩をとった後田口を目指して駆け下ります！
富士見峠には有名な"あと***キロ"の道標が。
段戸裏谷を駆け下り人造湖段戸湖へ。
段戸湖は凍結していました。ほとりの休憩所には東海自然歩道の
解説板が多数あります。
きららの里の端の道路を登り、今回のルートの要所である田口森林鉄道本谷線跡の
トレイルに突入します！
しばらくの間は野生動物の足跡の案内を‥実はまだこの地点ではまだ森林軌道跡
と少し外れています。
凍結した超危険な木橋がお出迎え…この後何度も苦しめられます…
そしていつの間にか森林軌道跡をトレースするルートに。
脅しではなくマジでめちゃくちゃ滑ります…
ちなみに滑って転ぶとそのまま谷底にまっさかさまです。
ねむいさんはぶろぐ見てくれてる受験生のために(ry
気づくと沢(寒狭川)が並走しています。
浮石だらけでなかなか走れなかったトレイルも坂がゆるくなり
だんだん走りやすくなってきました！
これは森林軌道の遺構、橋脚です…
田口に近づくにつれ駆け下りるスピードを上げていきます。
この辺りは有名な森林軌道の切りとおしが見えます。
と思ったらまた木階段…ここは元は森林軌道の木製の橋脚がありましたが…
木製の橋脚は星霜によりすでにすべて崩れ落ちていました。
崩れ落ちがれきとなった木にうちこまれたボルトが当時の存在の
証明をしています…
森林軌道の解説のある個所まで来ました。
ここからさらにスピードを加速して駆け下りていきます！！
大名倉辺りで森林軌道跡とは分かれ、松戸橋目指してアスファルトの
舗装を川幅が大きくなった寒狭川を横目に駆け下りていきます。
ここ全面凍結しててスパイクはいてても超ヤバかったです(汗
でもねむいさんは受験生の(ry
エメラルドグリーンの水をたたえる寒狭川に掛る松戸橋を越えます。
さて、この橋を越えると奥に見える道標を越えてゴールの田口に行くのですが…
私はここで寄り道して廃鉄な方には超有名な豊橋鉄道三河田口駅の今の姿を見に行きました。
去年の夏、大雨により駅舎はとうとう斃れてしまったとのことですが…
2012年2月現在、すでに路面にはみ出た屋根は取り壊され"曝葬"された状態でした。
後で気付きましたが、駅舎の残骸の一部は少し離れた空き地に移し替えられていた
ようです。しかしこの状態になってしまうと自然に還るのも加速度的に早くなって
しまいますね。
ここにかつて電車が通り、三河田口駅があったという事実はこの看板だけが唯一の
証人となるでしょう…と言いたいところですが後数年後には設楽ダムの建設によっ
てこの辺り一帯は水の底となり、最早誰も近づけない場所となってしまいます…。
東海自然歩道も当然付け替えとなり私ももう二度とこの地を踏むこともないでしょう。
さよなら、三河田口駅。
(※：これらほかにも写真・動画もいくつか撮っていますので、資料としてご入用の
方はどしどしご連絡ください)
おまけですが少し戻ったここにも遺構があります。
通路橋の下に森林軌道の橋脚があるのがわかりますね
さて松戸橋に戻り最後の登りの山道を越えて今度こそ田口の町へと向かいます。
武田信玄の墓があるらしい福田寺です。次回のエントリポイントはこの地点
となり今回はここで東海自然歩道から離脱します。
お約束ですが市街地で迷ってしまいました…
スパーという店を探してたのですがすでに潰れて別の店になってたようですorz
そして30分近くロスして田口バス停に到着です。
着替えを済ませてるうちに日が暮れてしまったようです。
バス(最終便)が来るまでまだ時間がありますが、待合室も閉鎖されおん出されて
しまい一気に底冷えてきた田口バス停の袂でバスを待ちます…ぇっくし！
バスに揺られてJR飯田線本長篠駅まで45分…電車を待つ間本長篠駅のホームで
空を見上げると明かりもなく空気がきれいなのか満天の星がみえました。
京都の市街じゃなかなか見れないです。そして見とれてるうちに列車もやって
きました。ここからさらに飯田線に揺られて豊橋、んでもってこだまで
京都に…ぁー(移動が)疲れた…
今回は恵那ルートの終盤と奥三河の"さわり"の部分に入ったわけですが、定光寺
止まりでうっちゃっていた本線ルートをこれから攻略して再び伊勢神峠を目指し
ます。今期のラストは東海自然歩道3大難所の一つ、奥三河縦走で締めくくること
になるでしょう。
明智〜伊勢神 GPSログ
伊勢神〜田口 GPSログ
いろいろ試す11
●STM32L-Discovery
少し前に秋月さんからSTM32L-Discoveryが販売されましたが、遅ればせながら私も
入手しました！
これでDiscovery系のボードもほとんど手に入れましたね。
さて、いつもなら即座にVersaloonに改造するのですが、2012年に入ってからOpenOCD
の0.6.0系のサポートにSTLink・STLink/V2が加わっています。
しかも生SWD対応です！
去年まではSWDでCorex-Mx系のマイコンに書き込みデバッグするまでがかなりしんどい
方法しかなく(一度コツつかんだら後はスクリプト組んじゃえば楽勝なんですが…)、
皆さん華麗にスルーされてきましたがメーカーやサードパーティの有償のツールを使う
ことなく使い慣れたOpenOCDを利用できるようになりました。
↑STM32L-Discovery(STM32L152RBT6)にOpenOCDで書き込みしてるとこです。
書き込み用のスクリプトはいつもの場所に最新の物をまとめてあります。現在動作確認
してるのは今回のSTM32L-DiscoveryとSTM32F4-Discoveryです。
STLinkやVersaloon(SWD接続)対応のOpenOCDはこちらに。
↑デバッグも自由自在です♥OpenOCDはSTLinkのAPIを呼びだすことで通信を
成立させているようです。MLを追っていくと対応に当たってOpenOCDのdevの人たち
の苦心の様子がうかがわれます。
2013年現在はOpenOCDからSTLink/v2を動かすドライバとして、STマイクロ提供の
純正ドライバが利用できます(といっても中身はWinUSBですが)。
●ほっぽらかしていたBeagleBoard達
去年争奪戦に勝利したにもかかわらず購入した時点で満足して箱に納めてしまってい
たねむいさんですが、aitendoさんの液晶キットを購入したことを皮切りに少しずつ
手をつけ始めています。
↑せっかく奮発してHDMIケーブル買ったのに一旦DVIコネクタ咬ませて変換しとかない
とこの構成だとまともに写らんなんて考慮しとらんよ…orz
副業先のPCのでかくて新しいモニタ使わせてもらいますか…無駄に2980円がががｇ
ぁーでもS端子使うって手もありますね。
↑去年末にBeagleBoneなるさらに機能を絞ったBeagleBoardの仲間が誕生しました！
今流行りのクラウド環境を意識したモノになっていてArduinoからの置き換えを狙った
プロトタイピングに特化した作りとなっているようです。
こちらの導入記は現在まとめていますのでまた次の機会に詳しく述べたいと思います。
●モノクロドットマトリクスSTN液晶
皆さんは去年さらっと紹介した2.5元I2C液晶を覚えているでしょうか？
あの後詳細が判明した途端に5元に跳ね上がりやがりましたが、ねむいさんは
基本的な動作確認を終えシンプルi2cライブラリに加えようと画策していました。
しかし、Nokia5110に代表されるドットマトリクス方式のモノクロ液晶は動かし方が
ほとんど同じことが分かったので、私がTFTでやってるのと同様に汎用のドットマトリ
クスモノクロSTN液晶向けのライブラリを現在作っています。aitendoさんで購入で
きる一部のOLEDも同じ動作方法の物があり、こちらに組み込んでます。
こちらもまとまり次第別記事で詳しくお伝えします。Nokia5110以外のマイナーな
モジュールに関する動作方法のテクニックも同時にお伝えしますね。
↑てわけで自作ライブラリで別の5元のOLEDを駆動。
…これ焼きつき激しすぎです！
●一個忘れてました
STM32系のOpenOCDのフラッシュ書き込みルーチンで現在テスト段階なのですが、
asynchronous algorithmと言うものに換えると書き込み速度がアップするそうです。
20120226追:
公式のコミットにも来たわよ
実際にこのパッチを取りこんで試してみました。
デバッガハードウエアはJtagkey2を使ってますが、ボトルネックがフラッシュ
書き込みにあるのでSWD接続のVersaloonでも変わりません。
*Normal
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00415-g338f5a1-dirty (2012-02-16-10:16)
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
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
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 3750 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: 0x08031280 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 19.750000s (25.924 KiB/s)
verified 454868 bytes in 4.062500s (109.343 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*asynchronous algorithm
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd -s C:/Devz/ARM/OCD/tcl -f interface/jtagkey2.cfg -f target/stm32f4x_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.6.0-dev-00423-gd8b9127-dirty (2012-02-17-21:45)
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
DEPRECATED! use 'adapter_nsrst_delay' not 'jtag_nsrst_delay'
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
3750 kHz
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 3750 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: 0x08031440 msp: 0x10010000
auto erase enabled
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
wrote 524288 bytes from file main.elf in 12.968750s (39.480 KiB/s)
verified 454868 bytes in 4.015625s (110.620 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…てわけで25.924 KiB/sから39.480 KiB/sへの大幅アップです！なにこれすごい。
現時点で書き込み速度がRTCK使っても10KiB/s代しか出ないLPC1769系のフラッシュ
にも対応してほしいですね♥
GPSを試用する6
20230816追:
最強のGNSSモジュールSAM-M10Qをゲットせよ！
20230816追:
今年に入ってからGARMIN社のGPSレシーバーについにQZSS/GLONASS対応の機種が
出てきました!みちびき(QZSS)ではGPS補完信号のみ対応とのことですが、頭上にGPS
衛星がひとつ増えるというのは心強いことだと思います。
ねむいさんもがーみんほしい…
さて、去年11月下旬以来私の方もみちびき対応のGPSモジュールPA6CをSTM32Primer2
を使ったGPSロガーの心臓部として使用しています。そして厳しい環境で功徳の実証を
重ねて市販品ロガーよりダンチな性能が出るのを確認してきました。そして私のぶろぐを
見て購入される方も沢山いらっしゃるようなので、使用に当たってのTips等を今一度
お伝えしたいと思います。UP-501等他モジュールを使用されている方も一般的な部分が
多いと思うので参考にしてください!
※PC上ソフトウエアはWindowsXP/64bit版Win7の使用を想定しています。
●PA6Cにメイン電源(VCC)を供給する
一見簡単そうに見えてまともに動かそうとなると非常に難しいです。
ブレッドボード上でプロトタイピング的なつなぐだけな使い方をすると
全く性能が生かせません。
GPSモジュールはGHz帯のレシーバーでもあるのでノイズ対策を十分考慮
した電源周りの構築をしなければなりません。
Gtop社が提供しているPA6Cのデータシートには推奨動作条件としてVCCの
リップル許容値や高周波ノイズを食い止める電源ラインのフィルタ回路例
などがわかり易く提示されていますのでこれを参考にユニットを作成すると
よいでしょう。
UP-501やPA6Cは単体の消費電流が低いのでまだ影響は少ないのですがGT-723F
等を使用しているときは初回補足時に80mA程間欠的に消費されます。
このときVCC,GND周りの配線がAWG26番以下の細い電線で15cm以上長く引き伸ばす
ような貧弱な配線を行っていると自分でノイズをまき散らして受信を阻害し、
10分近く待っても補足できないなんてことになります。
ハードウエアにあまり詳しくない人が引っ掛かりやすい点です。
GPSモジュールを使用するシステムの基板上に実装して一体となるのが一番
ノイズを抑えられる手法ですが、後付けの場合でどうしてもというときは
太く・短く・モジュールのVCC直前にデカップリング&フィルタ回路を置くように
しましょう。
↑私もこんな風に差し替え可能なようにユニット化しています。
メッシュアース基板や1005サイズのSMD受動部品を利用して少面積で作り、
引き出す電源線はAWG22番線を使用しています。こちらも参考に。
また、世代が進むにつれて使用できるVCCの電圧上限も下がってきています。
UP-501やPA6Cはリチウムイオン/リチウムポリマー2次電池が使用されたモバイル
機器上で動かすことを想定されているため上限が+4.2Vとなっています。
うっかり+5V系のシステムで使わないように気を付けましょう。特にAVRマイコン等
+5Vで動くマイコンで絶対にUARTのTxを直接しないようにしてください。
モジュールが異常発熱したり最悪即死します。
●PA6Cにバックアップ電源(VBAT)を供給する
なぜか見落とされがちな箇所ですがこれも超重要なファクターです。
PA6C・UP501にVbat端子が存在し、常に電源を供給し続けることによりアルマ
ナック・エフェメリスといったGPS補足追跡のためのデータやボーレートや
インターバルなどモジュールの基本動作にかかわる設定を保持し続けます。
解放していてもモジュールとしては動作しますがこの状態だといったんVCCを
切ると設定が全部失われ始めから補足し直し・設定し直しとなってしまいます。
特に単体動作の時はいったんVCCが落ちると何もできなくなってしまうので
VBATは常に電源を供給するようにしておきましょう。
一般的にuAオーダーの消費電流なのでVCCとは独立したコイン電池等でバック
アップしておくとよいでしょう。リポバッテリーなどを使用してるモバイル機器の
場合は電池の出力からじかに1kohm程度の抵抗を直列に介してVbatに繋げ、コイン
電池の代わりにする方法もアリです(私の自作GPSロガーでやってる方法です)。
●PA6Cと通信する
UP-501やPA6C等の新世代のモジュールはモバイル機器に組み込まれるような
使い方を想定されているため、I/OのレベルがLVTTLのみとなっています。
GT-723FはRS232Cの電圧レベルも出てますがその分中でチャージポンプが動いて
るので電流消費がでかいというわけです。ちなみに+5Vトレラントではないので
+5V系のシステムとじかに繋ぐとモジュール内部の入出力バッファが破壊されて
即死します。横着せずにLVTTLの電圧レベルを守りましょう。
また通信のプロトコルは一般的な8bit,ノンパリティ・1ストップビットのUARTで
ボーレートは9600bpsがデフォルト(GT-723G,UP-501も同じ)です。
GPSモジュールから垂れ流しの信号(TxD)のみでシステムを完結させるなら受信側は
RxDだけでも構いません。
ただ、後述するAGPS等の強力な機能を使用するために相互に送受信できるように
しておきましょう。
●PA6Cを設定する
Windows機を使用している方はGlobalTop社よりPA6Cの各種設定を行うとこができる
サポートツールが用意されています。Linux系な方orマイコン制御な方たちはAT
コマンド表片手にコマンドを送ってやれば同じことができます。
↑PA6C設定ツール"MT3339 PC Tool"の操作画面です。
基本的な衛星ID表示画面やPA6C(の中のMT3339)が持つ機能を設定できる項目が
あります。単体でのインターバル補足動作や超低消費電流スタンバイモードへの
移行も可能です。スタンバイモードの移行動作はたとえばガイガーカウンタと連動
してマイコン制御のモバイル記録装置で動作させるような時に有効です。
↑AGPSの設定画面です。
AGPS(AssystedGPS)とはGPSモジュールもしくはチップに内蔵された専用の
フラッシュメモリにアルマナックデータをあらかじめ書き込んで置くことに
よって電源投入直後の初回補足時間の短縮を図る機能で、悪天候・障害物遮蔽が
多い環境で効果を発揮します。なぜかこの機能を活用されていない人が多いの
ですが、ぜひとも活用しましょう！
AGPSはPA6C(14日保持)の他にGT-723F(7日保持),UP-501(14日保持)も利用
できますが、GPSモジュール内部のチップメーカーの違いで設定をするための
ツールも当然違いますのでご注意ください。
GT-723F(Venus6)の場合はGPSViewer、UP-501(MTK3329)の場合はFastraxGPSWorkBench
…はちょっと微妙なのでTransSystemsのGPSViewや有志が作ったフリーのツール
BT747、はたまた上で紹介したPA6C用"MT3339 PC Tool"でもAGPSのみですが
設定可能です。
●PA6Cを"使"ってみる
ここで述べる"使う"は単なる卓上実験ではなく各システム内にGPSモジュールを組み
込んで実際のフィールド上で"使う"という意味合いです。
ねむいさんの使用例はプロトタイピングツール(←強調)であるSTM32 Primer2と組み
合わせてGPSロガーとして使用しています。こちらは以前から何度か紹介してきまし
たが、USB-MSC(USBマスストレージ)機能に加えてUSB-CDC(USB仮想COM)機能も新たに
取り入れさらに使い勝手を上げることに成功しました。
↑各機能は電源投入直後のキー操作で分かれます。
投入直後何もしなければSTM32のクロックも24MHzまで落とし低消費電流で
GPSロガーモードに。
↑投入直後1Sec以内に左キーを押した状態を3Sec保つと、USB仮想COMモードに
なり、ホストPCとGPSモジュール間で直接データのやり取りができます。これ
はAGPS用のデータのダウンロードやGPSモジュールの各種設定等で別に通信
手段を用意する手間が省けて非常に便利です！
↑投入直後1Sec以内に右キーを押した状態を3Sec保つと、USBマスストレージ
モードになりmicroSDカードに記録されたGPSのNMEAデータをPC上からファイル
単位で簡単に取り出せられます。
MSC/CDCバルク転送のエンドポイントはもちろんダブルバッファを構成しています。
が、おかげで複合デバイスのやり方がどうしてもうまくいかなくなって電源投入時
のキー入力で機能選択する方式に落ち着きました。たぶんソース見たら分かる人は
分かると思いますが分離できなかったディスクリプタのWrapperを全部こしらえて
機能選択時に全部の関数のポインタを割り当てる(で表現正しいのかしら???)
というかなり見苦しいことをやっています。
↑外気温−2℃の猿が城跡にて…。
STM32 Primer2ちゃんは生まれつき心臓(電源回路)が弱くシウツをしないと
電源のON/OFFだけで電源回路中のDC-DCが死んじゃう子でしたが、ねむいさんに
よるLDOへの無理やりなリプレース・大容量リポ電池にリプレース等の魔改造を
施されまくり、約２年後には極寒/灼熱の環境にもびくともせずGM-316,GT-723F,
UP-501,PA6CとメインのGPSモジュールを変遷させつつねむいさんの足跡を
ロギングし続けるたふすぎてそんはないSTM32Primer2ちゃんが！！
…それなんか違うだろって突っ込み入れられそうですがこんだけﾊﾞﾘﾊﾞﾘ厳しい
環境で使いまくってますからもう十分元は取れたと実感していますが東海自然
歩道はまだ1/3も進んでないのｄおいこらにげるなせっかくだから見て行きなさい♥
おまけ
GPSモジュールUP-501(MARY-GB基板にも使用されてます)を使用
してる人でモジュールのファームがAXN1.30の人は……
検索エンジンで"150M-ITX.1139.bin"って呪文唱えるといいこと
あるかもしれませんよぅ
東海自然歩道を徃く13(善師野〜御嵩/御嵩〜明智)
犬山から先のルートは本線ルートと一旦岐阜県を迂回する恵那ルートが存在します。
新年一発目の行程は恵那ルートから攻めて見ます。また、青春18切符と現地の安い
宿を駆使してなるべく安価に移動・宿泊しつつ現地に早朝から出発することにより
一気に移動距離を稼ぐタクティクスを練りました。
●2012.01.04 善師野〜御嵩
スタート地点の名鉄善師野駅です。新年一発目はここから御嵩を目指します！
昨年通過した山道を逆行しルート分岐点へと向かいます！
本線・恵那ルート分岐点に。このまま直進して可児にでます。
で、分岐点から続く山道を抜けるとず〜〜〜〜っと舗装道路が続きます。
それもあってか飽きさせないようにQRコードで示されたガイドも道標にあります。
この地点後ろ振り向くとラブホテル街…
可児川と名鉄線に迫るこの地点ですが、道が工事中で道標がバリケードに
隠れて見えなくなっています。写真の矢印の要領で進んでください。
可児川は工事中で水が抜かれています？？
結構開けた住宅街を駆け抜けます。
特に見るものは無いのでひたすら走ります！！
…どうやら微妙にルートミスしてたみたいです…
後藤さんの卵茹でたい
登り坂を越えて三宮神社で小休止。
太多線の踏切から多治見方面をみます。
この地点は矢印の要領で。
大森にある横穴古墳です。
素掘りのトンネルをくぐります。
ひたすら車道を駆け抜け平政公民館を越えたら再び可児川と落ち合い並走します。
この箇所は要注意です！道標がめちゃくちゃな場所を指し示してます！
３枚目写真の要領で進んでください！
昔の街道の跡、今回のゴール地点の御嵩を示す道標が出てきました。
またこのさきの下の写真の個所で左折しますが道標がないので注意してください！
直進してしまうと不気味な通行止めのトンネルに！
久々利の泳宮(くくりのみや)史跡に。1分間ほど小休止。
小渕ダムに向かう道からだんだん勾配がかかってきました。
4時間近く車道を移動してきましたがようやく再びトレイルに！
危険動物の脅し文句もいい感じに効いてますね！
…と思ったらあっさりピークに到着…。そこから少し下ると再び舗装道路に。
この区画はみたけの森と呼ばれています。
ひたすら駆け下っていくと車道が中規模の土砂崩れで埋まっていましたが、
九十九折りの道だったので直接下の道に飛び降りてパスしました！
みたけの森入り口までやってきました。そうめん…ね…そうめん…
みたけの森を出て車道に出ると拡張工事が終了した広い道に出ます。
御嵩駅への案内もでかでかとあるので迷うことは無いでしょう。
みたび可児川を渡り予定時間より1時間上早く御嵩駅に到着です！
名鉄御嵩駅も廃線の危機に瀕しているようです…みなさんも広見線に乗りまくって
御嵩に観光に来まくってあげてください！！１１！
そして痛恨の画面にカメラストラップ混入orz
●2012.01.10 御嵩〜明智
前日18切符で京都から移動。ルートイン可児に宿泊して当日始発の御嵩行に。
可児駅周辺は開けてはいますが都心部の繁華街と比べると・・うｎ
名鉄御嵩駅を見るのはもう最後かもしれない…そんな不謹慎な思いを残し
御嵩駅から出発しました！まずは御嵩宿場町を駆け抜けます。
6時近くの御嵩は真っ暗でひっそりと静まり返っています。
しかし進んでいくに従って少しずつ太陽の気配が見えてきます。
和泉式部廟所です。
この辺りから中山道の標識が出てきます。
中山道のトレイルへ。気温が氷点下を下回っているのかペットボトルの水が凍結
を始めていました。
耳を祀った耳神社です…。いなちゃんのみみｶﾐｶﾐしたい…♥
歌詠み坂から少し抜け、この地で見つかったというマリア像を見に行きました。
中山道は史跡たっぷりのハイキングコースとしてもメジャーで至る所に
案内があり、しっかりとお金をつぎ込んで整備されてることがうかがえます！
一呑の清水と唄清水だそうです…ここの水はちょっと飲む気しない。
さて車道を走っているうちにだんだんと日が登ってきました。
太陽光線に照らされて蒸気が立ち上っています。
開元院に立ち寄りました。駐車場がやたら広いです。
車道をさらに進み細久手の宿場町に到着です。
昔の雰囲気を残す宿場町を後に大湫(おおくて)宿に向かいます。
中山道にはこのような一里塚と呼ばれる盛り土？みたいなのが
一定距離間隔で多数残されています。
こう言う脱字は見逃さない女、ねむい！
弁財天の池です。
のどかな田舎の風景を振り返って撮影。
そう言えば東海自然歩道設立当時はほとんどの道は舗装路ではなく地道だった
そうですが…。
石畳が特徴的な琵琶峠に。
滑りやすい上に足がとられやすいので下りは厳重注意です！
琵琶峠を下ると大湫宿に。
大湫宿を抜けると十三峠と呼ばれるゆるいアップダウンの連続になります。
坂の一つ一つに名がつけられています。
十三峠にある坂と史跡たち。至る所に史跡があり過ぎて写真撮っては進みを繰り返し
てると徒歩と同じくらい遅くなってしまいます…
他の方も良く写真に収められている中山道を代表するスポットです。
???
紅坂一里塚が見えてきました。通過する最後の一里塚になります。
首なし地蔵と言う八つ当たりで頭部を破壊された不憫なお地蔵さんです。
だがメインカメラは(ry
下街道と呼ばれる伊勢方面への抜け道の分岐点(槙ヶ根立場)に来ました。
東海自然歩道もほどなくして中山道と分かれます。
化学工場のある場所で東海自然歩道は中山道と分かれます。
東海自然歩道は南下を続け、明智と言う場所に向かいます。
現代の中山道とも言える中央自動車道をくぐり、さらに南下しつつ高度を上げていきます。
もう恵那市に入っていますね。この地点で5時間30分くらい経過しています。
本来なら終了の所ですが今回は60km走りきる覚悟と装備はキメてきたのでさらに進みます！！
恵那渓カントリークラブの通路をくぐります。
稼いだ高度を一気に消費して野井の威代寺に。ここを抜けるとまた登ります。
昔岩村城の城主が利用したといわれる大名街道を通ります。
高度もずんずん上がっていきます！
12時を過ぎ、日もだいぶ昇りましたが小ヶ沢池はｶﾞｯﾁｶﾞﾁに凍結していますね。
風が無かった分体感温度はそれほどでもありません。
夕立山を抜け、再び舗装路に。
マンホールも"いわむら"に変わり岩村駅が近くなってきたのを感じます。
希庵塚と呼ばれるお坊さんを祀った古いお墓と橋です。
岩村鉄道跡の道を通行し、明智鉄道岩村駅に到着です。
岩村鉄道の岩村駅跡を写真に収め岩村駅を後にしました。
今回はさらに進んで明智まで進みます！次は飯高観音へ！
徐々に道に増えてきた残雪やアイスバーンに苦しめられつつ飯高観音に到着しました。
かなり立派な寺社ですね。
姥石石仏群を越えると登りの山道に入ります。雪が深くなってきました…あわわ
かなり疲れてきて左足もヤバくなってきましたが中山道以降は見るべき史跡がすく
なくなるおかげで写真を撮るために止まる必要がなくなりペースは上がっています。
このさきの下りの山道に入る直前の100mくらい続くアイスバーンがヤバかったです。
滑った時に頭を手で守りつつこけたので背中から凍った地面に何度もたたきつけら
れてしまいましたがザックの一番外側に配置しているSTM32Primer2+GPSモジュール
さんは私の59.6kgの全体重をこめたボディプレスを3発喰らったのにも関わらず全く
の無傷でした…！ たふすぎて そんはない
さらに下って舗装路に差し掛かると大正村のロゴが付いた安住寺に。
これが見えたら今回のゴールの明智駅ももうすぐです！
逆光で見えづらくなってますが東海自然歩道の道に獣よけの高圧のかかった電線
トラップが張られています。私は常に足元は重装備なのでノーダメージでしたが、
脛の肌を露出した軽装のトレランスタイルだったら…ｵｿﾞｿﾞ
川沿いと学校に挟まれた道を進むと改築中の八王子神社に到着しました。
ここが次回のエントリポイントとなり、かつ今回はここで離脱して明智駅へ
向かってはしります。
ねこ
振り返って八王子神社の全景を。
八王子神社からまっすぐに走って10時間15分でゴールの明智駅に到着です。
60km近くありましたが大きな怪我もなく予定時間通りの到着となりました！
…と言うわけで私なりにかなり無茶をしてしまいました。しかし虹裏では震災の時
に帰宅難民に遭ってスーツ姿で高低差がある63km先の自宅まで8時間40分弱で歩いて
帰った｢｣がいたそうで、私はこんなフル装備でもﾎﾞﾛｯﾎﾞﾛなのに一体何なんでしょ
うかと思う次第です…。多分人間じゃなくてカモシカさんか何かなのでしょうか？？
あっちは人外ばっかですし何があってもあんまり珍しくは無いですしと身内ネタで
今日の日記を終えさせていただきます。
善師野〜御嵩 GPSログ
御嵩〜明智 GPSログ
東海自然歩道を徃く11(東津汲〜横蔵/横蔵〜岐阜市内)
関西圏では毎秋になると"秋の1Dayパス"というすごい便利なチケットが
販売されています。11/30まで利用可能だったのでスケジュール詰め詰めで
行けるところまで行ってみました。
それと今回の行程からみちびき(QZSS)対応のGPSモジュールPA6Cの
運用試験を開始です。2011年現在は日本の準天頂衛星システムは
みちびき一基のみで運用されており、その精密な補正機能は1日の
うち8時間しか恩恵を受けられませんがはてさて…
●2011.11.27 東津汲〜横蔵
今回で揖斐駅ともお別れです!(のはずでした…)
コミュニティバスに揺られること40分、前回のエントリポイント
東津汲のバス停に到着です。そそくさと移動の準備を進めます。
そしてこれがっ
QZSS対応のMT3339が使用されているGPSモジュール、PA6Cだぁああっ！！
ちなみにQZSSが極まってないとUP-501と補足性能は全く変わりませんが、
全体的な消費電流はさらに改善されています★
まずは小津集落を抜け、下辻峠を越えてミイラ堂がある横蔵寺に向かいます。
巨大な鉄管をくぐり…
小津トンネルわきの遊歩道を走ります…しかし…
遊歩道は一昨年の土砂崩れで埋まり跡形もありません…
基愛氏の2007年のレポートと全く違っています…
しかしまだまだスタート地点、こんな程度で踏みとどまるわけには
いきませんでした！そのまま飛び込んでいきます！
(…やっぱ走らずここはおとなしく歩こう…)
急に視界が明けたと思ったらと遊歩道のアスファルトの法面がごっそり削られて
いる場所に出くわしました。勢いよく飛び入ったらそのまま落ちて死んでましたね…。
その後も土砂崩れの後を乗り越え小津トンネル遊歩道を抜けてやっとこ小津の
集落を抜けると東海自然歩道通行止めの看板と不自然な東海自然歩道の道標が
ありました。…これは…
自然に朽ちたわけでもなく下辻峠への道標の板が故意に取り外されています。
東海自然歩道の行程でこんなのはぢめて見ました…。
湯の山温泉の時だって通行止めでも余裕で通れたから大丈夫っしょと思って
小津橋を渡りましたが…
…橋を渡った先にあるはずの道標もきれいさっぱり撤去されていたようで、道をおも
いくそ読み誤り1h30m以上ルートミスしてしまいましたorzorzorzorz
変な道に入る私を対岸で偶然見かけてわざわざ車で追っかけて権現山に間違って
登るのを阻止してくれた上に正しい道まで教えてくださった農家のおぢさん、本当
にありがとうございます…
…さて小津橋を抜けたところから再開です…
もう12:30だわ…どう頑張っても神海駅まで到達できませんorz
とにかく行けるところまで行くことにしましたが、東海自然歩道通行止めの警告が
しつこく出てきてさらに進んで山道に入ると倒木の嵐が!!
ぐわー
とうとう踏み跡も消滅しました…この時点でルートミスを取り戻すために
駆け下りてきたのが災いして足が攣りまくってます…
とにかく上に上に上がって登山道に復帰しましたが
下辻峠の直前でまたすごい崩落が！！！
落ちたら大怪我覚悟で渡り切りやっと林道が横切る峠に。
ここからは下りで一安心♥
と思ったらまた倒木！！
ルートミスしたのと倒木だらけでイライラしてきてこの人間の力で何とかなり
そうな倒木に助走付けて思い切り虹弦流・や○ざキックかましたのですが、蹴
りぬけた着地点の10m先でハンターの人たちが立ち話していてものすごく恥ず
かしい思いを///
もう熊とかそんなの気にしてる体力ありません…
その後はアスファルトの道を通過して横蔵寺に。到着時刻がすでに14時を過ぎていて
先に進む気力もなくなったのでここで離脱としましたorz
てわけで谷汲もみじ祭りの真っ最中だった横蔵寺(ミイラ堂&瑠璃殿特別拝観300円
以外はすべて拝観料無料!)のギャラリーをお楽しみください↓
さて、たっぷり写真も撮ったし着替えもしたしとっとと京都に帰るか…と
思ったのですが帰りの名阪近鉄バスが16:20と1時間以上も余っていたので…
せっかくだから車道を歩いて谷汲山華厳寺に行くことにしました！
気温は低いのですが無風だったおかげで少し汗ばむくらいです。
山間部は日が暮れるのも早い…
そして谷汲山華厳寺の参道入り口に到達した瞬間に名阪近鉄バスと落ち合いました！
参道に入ると"いのりちゃん"がおでむかえです。
ねむいさんは黒髪ぱっつんのストレートロングな髪形の娘はすべていないさんに
見えてしまうハードウエアがじっそうされｔ
横蔵と同じく谷汲もみじ祭りの真っ最中だった華厳寺(拝観料無料!←これ重要)の
ギャラリーもお楽しみください♥
すっかり日が落ちてしまいましたが華厳寺の参拝も終えて今度こそ帰路に。
(…いのりちゃんのえろす絵もネットの広大な海を潜るとあるんやろな…gff)
揖斐駅行きのバスを待つうちにすっかり真っ暗に…
揖斐駅とはもう一度お世話になるはめに…
●2011.11.30 横蔵〜岐阜市内
1Dayパスが使えるのは今日が最終日です！そして岐阜ステージの要所
となるJR&養老鉄道大垣駅ともお別れです。
養老鉄道揖斐駅とも今度こそお別れです！
横蔵のもみじ祭りが11/30が最終日でした。
人が多くなるため横蔵の一つ前のバス停が臨時の終点です。
十分にストレッチをして横蔵寺山門からスタートです！
しばし前回のおさらいからどうぞ。
ミイラ堂&瑠璃殿手前の道標が今回の目標の妙法が岳&華厳寺奥の院への
山道のスタートとなります！
横蔵寺からスタートなので体力も十分で九十九の山道もサクサク登ります。
旧横蔵の寺領につきました。仁王門跡です。
馬場跡です。
かなしいエピソードがどうたらこうたら書いてますが
先っちょの形状がちょっと卑猥な稚児が岩です。
熊谷直実という今でもいそうな名前の人のお墓です
旧横蔵寺の本堂跡です。
本堂跡を出てすぐにシャクナゲ平が。
数多くのハイカーを苦しめた妙法が岳へのアップダウンの連続が始まりました！
ねむいさんは４足獣歩行体勢で脚部の消耗をおさえつつクリア
アップダウンが収まってくるとそれっぽい石があります。
写真奥の男性の方たちに妙法が岳山頂はここですかと聞くと、"わしらも
よう分からんかったからとりあえずここで昼飯にした"とのこと
さらに進んで鉄塔を越えた先に今度こそ妙法が岳の山頂が！
山頂を越えると今度は急激な下りが始まります。
どんどん下っていくと華厳寺不動尊堂が。
そして華厳寺奥の院に到着です。
華厳寺奥の院を離れ、さらに下って今度は華厳寺への
分岐まで行きつきました。前回参拝したのでそのまま
樽見鉄道神海駅を目指します。
淀坂峠です。
夏の落し物。
トレイルがアスファルト舗装の道路に変わりました。
ここから先はすべてアスファルト舗装の道になります！
神海橋です。
神海橋を渡ってすぐの分岐点で左折が正解らしいです。
直進しても樽見鉄道沿いに北上すれば神海駅に行きつきます。
神海駅に到着です。喫茶店は無くなっていました…。
駅構内や大垣方面の線路を。
ここで行動食と水分を補給し小休止した後岐阜市内に向けて
再び走りだしました。
道標が少なく迷いやすいという前情報が散見されたので
神海駅から先は詳細なマップを紙に刷り出しておきました！
本巣にあるハリヨで有名な湯の古公園だそうです…
？？？これ？
ついに岐阜市内に！鹿穴峠も舗装路なので一気に駆け抜けます！
下雛倉にある龍峰禅寺です。
ひたすら車道を下って行く途中に見えるかどやがぬふぅ！
則松バス停までやってきました。ちょうどいい時間いいタイミングで
バスがやってきたので今回はここで終了としました。
バスを乗り継いで１時間…私もついに岐阜駅まで来るようになりましたか…！
というわけで今回の2行程の軌跡はこんな感じです。
さて、みちびき対応のPA6Cさんはルートミスしてる最中でも
しっかりと仕事をしてくれていました…
東津汲〜横蔵 ログ
横蔵〜岐阜市内 ログ
時間がへんてこりんになっていますが調査中です…
多分UTCじゃなくてJSTで記録しちゃってるかなこれ…
同時に記録しているスポーツガイドメイトGP-101(CANMORE)との分かりやすい
捕捉性能の比較をお見せします。もう"ダンチ"ですね〜♥
ぇ？肝心の山の中の捕捉はどうなんだって？
…ごめんなさい私も合ってるんだかずれてるんだかよく分かりません…
とりあえずPA6Cが普通にﾊﾞﾘﾊﾞﾘ使えるのが分かったので細かい検証は
次回以降に(丸投げ！)
STM32F4シリーズを使ってみる4 -STLink/V2をversaloon化-
20231002追:
10年以上前の記事となり現在では有効ではないリソースが多数あり、
Versaloonはお勧めいたしません。
もしそれでもどうしてもVersaloonをやってみたい方はメールをください。
20231002追:
Versaloon本家がSTM32F4対応したのを受けて今回はSTM32F4 Discoveryに
仕込まれているSTLink/V2をSWD接続方式のVersaloon化する方法を紹介します。
もう何度も行っていますが、Discovery系の基板をVersaloon化したことによる
メリットは以下の通りです。
1.書き込み・デバッグにOpenOCD(ただしVersaloon対応にビルドしたものに限る)
が利用できる。
2.VersaloonのファームウエアにUSB-CDCも仕込まれているのでUARTの
通信手段を別途用意する必要がない。
3.Versaloonはソフトもハードもファームウェアも無償で利用できるので
自分の好きなように改造できる。
と言ったところでしょうか。ねむいさん的には"2."が実際のデバッグや情報
表示等にかなり使えると実感しています。
●Versaloon化手順 on STM32F4-Discovery
概念についてはこちらとこちらで詳しく紹介しているので基本的な部分は
はしょりますが、Versaloon化するSTLink/V2(STM32F103C8T6)にいつもながらの
DFUブートローダを仕込んでおいてその後にversaloon本体(DFUファイル)を
書き込みます。
DFUブートローダのバイナリはUARTブートローダ若しくはSWD経由でフラッシュに
書き込みを行います。各々の方法も基板に下準備が必要です。
1.SWD経由でDFUブートローダを書きこむ場合
SWDで書きこむ手段として今回はvsprogを使用することにします。
用意するものはVersaloon化したSTLinkですが素のSTLinkでも書き込むまでの
下準備は同様です。
まず基板をひっくり返して写真の箇所のジャンパ抵抗をそれぞれ移転させます。
上記写真の要領でSWCLK,SWDIO,GNDをそれぞれ接続してください。
STlink/V2が仕込まれているSTM32F103C8T6にはReadProtectionのヒューズ
ビットが掛かっていて、これを解除しないとフラッシュの書き換えが
できません！
これはOpenOCDのflash unlockコマンドでも解除できません。
2013年現在ではstm32f2x.cにバグ修正が入ったのでOpenOCDからでも解除
可能です。
vsprogを立ち上げSTM32マイコンを認識したら上記画像の要領でヒューズ
設定を行ってください。エラーが出まくりますが無視してください。
この状態でWriteを押すとエラーが出まくりますが無視して書きに行って
ヒューズを消すことができます。
その後はこちらに用意したSTM32F4Discovery用のDFUブートローダ
(の中のmain.hex)をフラッシュに書き込み、ベリファイまでエラーが
出ずに行えたら書き込み成功です。
2.UARTブートローダ経由でDFUブートローダを書きこむ場合
この方法は以前細かく説明しているので、ここではSTM32F4-Discovery
基板上ではどの線を引き出せばよいかという点に絞ってお伝えします。
DFUブートローダはSTM32D4Discovery用を書き込んでください
実はSTM8S,STM32VLDiscoveryの時と比べてすっごく楽です。UARTブート
ローダ用の線が引き出されていてなおかつ線を引き出しやすいSMDの抵抗が
ライン上にあります。書き込みの手段を持ってない人はUARTブートローダしか
方法がないので比較的やりやすいと思います。"TO_+3.3V"のジャンパは
書き込みが終わったらはずすのを忘れないでくださいね。
UARTブートローダを起動するためのBOOT0につながる抵抗はR7ですが、
シルクの位置が上にずれてるので間違えないようにご注意ください。
3.Versaloon本体のDFUファイルを書きこむ
STM32VL-Discoveryの時と同じくSTM32F4-Discovery基板上のResetボタンを
押しながらPCとUSBケーブルで接続してください。DFUブートローダが正しく
書きこまれていたらPCがDFUを認識します。その後、STM32F4Discovery用VersaloonのDFUファイルを
書きこみます。書き込み方法はこちらを。
書き込み後はPCとST<32F4-Discoveryの接続を切り離し、Resetボタンを
押さずに再接続した時にVersaloonとして認識すればVersaloon化の
成功です！
Versaloon本体のLibusbドライバのインストールはZadigで
行ってください。
USB-CDC用ドライバ(COMonVersaloon)は本家のリポジトリを
手繰って取得してください。
これでおしまいっ！
…と言いたいところですが、Versaloonとして使用する前に下に述べる処理を
絶対に忘れないでください。
4.後始末
SWDでDFUブートローダを書いた場合は最初に移動したジャンパ抵抗と
ジャンパを元の位置に戻します。次にDFU・UARTブートローダ共通ですが、
R68を取っ払ってください。これはSTLink/V2側からターゲットのSTM32F4
マイコン外部クロックを供給するためのもので、Versaloonではこのピンは使用
されていません！
このジャンパ抵抗を外して8MHzクリスタルが効くようにしてやらないと
STM32F4は16MHzの内部RC発振に強制されてしまいます。一見普通に動いて
しまいUART等のタイムベースが重要なペリフェラルの動作で異常になって
しまうので注意してください！
というわけでSTM32F4-DiscoveryもVersaloonで快適デバッグ/書き込みが
できるようになりました♥
先に書いた通り私のお目当ては複合デバイスとしてVersaloonとともにに
仕込まれているUSB-CDCです。
ごてごて外付けのデバイスを接続せずに済みますのでとってもスマートです。
おまけ
今のOpenOCDでデバッグした際に浮動小数点レジスタは見えるのか！？
ねむいさんがバリバリ使っているOpenOCD(V0.6.0)+Insight(GDB7.25)で
やってみましたが浮動小数点レジスタは見えませんでした(; _ ;)
OpenOCD＋InsightがCortex-M3というか無印のARMV7M扱いでデバッグしてる
せい(Cortex-M4FのコアはCortex-M3と上位互換してるから整数演算部は
普通にデバッグ・書き込みできる)でしょか???情報待ちですね。
も一つおまけ
ぜんっぜん関係ないですがtaobaoで超掘り出し物の液晶モジュール見っけ
ました！2.6inch,240x400のWQVGAサイズでタッチパネルつきのTFT-LCDが
たったの20元でしかも新品！もちろんデータシートなんて無かったのですが
運よく推定したピン配置がドンピシャでバッチリ動いてくれました♥
しかも類似品種のピン配置を調べるとSPIも使用可能なのが分かりコスト
パフォーマンス最高だと思います。
あーしまったこの角度で撮るとせっかくのゆっこちゃんの肢体がー(棒)
STM32 Value Line Discovery(STM32VLDISCOVERY)をいろいろ使う
CQ出版より"世界の定番"との触れ込みで大々的に宣伝されたSTM32ディスカバリ本
が発売されました。これはSTM32F100RBT6が使用されたSTM32ValueLineDiscovery
基板を扱い初心者向けに解説されたものであります。
ちなみにSTM32なんちゃらディスカバリな基板はVL&L&F4と3種類あって、
"STM32ディスカバリ"と書かれてしまうとどれを指すのか非常にややこしい
のですがまぁそれは置いておいて…
以前からSTM32VLDiscovery基板については私も秋月さんからひっそりと販売されて
以来ちょこちょこと触れてきましたがこの基板に関する質問のメールをちらほらと
頂くようになったので改めて単独の記事として紹介したいと思います。
ちなみに便乗ではない！！
●FatFsとTFT-LCD表示のデモプログラム
私のブログでいうところのいつもののことですが、STM32を扱う中でごく基本的な
要素を抑えてあります。私の他の物と同じくChaN氏のLPC2388向けのFatFsの
プログラムをベースにしていますが、移植しやすいよう抽象度を上げています。
・フリーのコンパイラを使ったコマンドラインビルドに対応
・基板上のLED操作
・基板上のSW入力(外部4+1方向SWはオプションで)
・printf系標準関数がリターゲット可能なUART
(サイズ節約のためChaN氏のxprintfを割り振ってます)
・sprintf/malloc系標準関数のサポート
・systickとタイマを利用したAVR-Libcと同じ感覚で使えるDelay関数
・STM32間のポートの移植性を容易にしたFatFsのデバイス依存部
・容易に移植が可能なTFTLCD/OLED表示用ライブラリ
SPI-LCDを使った時のブロック転送はDMA化可能。
ほかのマイコンからSTM32というかARMマイコンを始めた人が真っ先に
引っかかるのはsprintf/printf系標準関数がうまく動作しない点だとおもいます。
今となってはFAQレベルの事なのでここを熟読したり私のUARTへリターゲットしてる
部分のコードを読んでうまいこと動作させられるようにしてください。
上記のプログラムについては各ペリフェラルに対しポートの割り振りは
以下のようにしています。特筆すべき点は、後述するSWD接続のVersaloonを
使いデバッグすることに限定してSWDでは使用しないJTAGポートの一部を
SDカードアクセス用に割り振り、使用可能なI/Oをさらに確保したところでしょうか。
※1：STM32VL-Discoveryデータシートより引用・加筆。
※2：単にポート振っただけでSW入力や8bitLCD等実際使用してない個所あり。
定番のSPI接続のTFT-LCD(128x160)を動かしてみたところ。
ChaN氏のTJPegDecでjpeg画像を表示している最中です。
次回紹介予定の2.5元のi2c液晶モジュールも。素晴らしい掘り出し物です！
●STM32VL Discoveryに仕込まれてるSTLinkをVersaloon化
最早これも定番でしょう。STマイクロの**ディスカバリー系な基板にSTLinkとして
仕込まれているSTM32F103C8T6は各基板ごとに微妙にポートの配置が異なっていて
同じVersaloonのバイナリは使いまわしはできませんが、すでにVersaloon本家
ではSTM32VLDiscovery向けのファームウエアがサポートされています。
さて、肝心のVersaloon化の方法ですが本家ではDFU等のブートローダを
仕込まずに直接Versaloonのバイナリを書きこむようになっていますが、
私はアップデートを容易にするためにいつも通りのDFUを仕込むように
しました。以下に私が行った手順を示します。
DFU仕込まない場合は"1."の書き込み時にいきなり本家の方のSTM32VL
Discovery用のバイナリを書きこんでください
(この場合別途ビルドする必要あり)。
1.DFUを仕込む
こちらにSTM32VLDiscovery用DFUブートローダのバイナリを用意しました。
(Versaloon_DFU_Bootloader_for_STM32VLDiscovery_.zip) 最初に
書いてください。
書きこむ方法はSTLink等のフラッシュを書きこむ手段が別に用意
されてる場合はそちらを使ってください。
Jim氏のTakenApartの記事にSTLinkをつかった手順が示されていますので
そちらの記事をもとにDFUブートローダを書きこんでください。
また、STM32はこの基板が初めてでフラッシュを書きこむ手段を他に
持ってない人は、UARTブートローダーを使う方法を、こちらの改造手順2〜8を
参照して書きこんでください。
UARTブートローダを有効にするためのジャンパの引きまわしは
STM32VLDiscovery基板上では以下の写真の通りとなります。
この基板上では足あげ等の加工も水晶の付け替えも必要なく0.5mmピッチの
足からリードを引き出すだけなのでまぁ楽勝ですね。
DFUを書き込んだ後はもちろんジャンパをはずすのを忘れないで
ください！
2.DFUを起動
さて、DFUを書きこんだらPCに接続するわけですがSTM32VLDiscovery基板
上では下画像のリセットボタンがDFUの起動キーとなります。
リセットボタンを押しながらUSBケーブルでPCと接続してください。
USBデバイスとしてDFUが認識されたら成功です。
そうだね画像使いまわしだね。言い忘れてましたがDFUseをインストールした時に
DFUドライバがインストールされますので忘れずにインストールして
おいてください。
3.Versaloonを書き込み/起動
STM32VLDsicovery用のVersaloonのDFUファイルはこちらに。書き込み方は
ここの"14."を参考にしてください。でも向こうにあるDFUファイルは別物だから
使っちゃだめです！
書き終わったら基板を一度PCと切り離し、再度接続します。この時に
Vesaloonとして認識されたら成功です。VersaloonはLibUSBが使用されて
いますが、LibUSBのドライバはZadigでインストールした方が確実です。
20120105追:
以前はSWDのジャンパはあべこべになっていましたが、現在では
差し替え無しでそのまま使用できます。
4.Versaloon化したSTM32VLDiscovery基板上でターゲットのSTM32F100RBT6を
デバッグ冒頭で述べたプログラムをビルド・書きこみを行うわけですが、
用意するものはSTM32マイコンをビルドする環境のほかにVersaloonに対応
した特別なOpenOCDが必要です。
おもな手順はこちらとこちらですでに紹介しています。
てわけで丸投げしまくりのやっけつ手順になってしまいましたが簡単に改造
可能なので(自己責任の上で)お勧めします。
しかも今のVersaloonはUSB-CDCが同時に使用できる複合デバイス構成になって
いるため、これを利用してこの基板上でUARTの通信手段を完結させることが
できます♥
STM32F4シリーズを使ってみる3 -FatFsと下部レイヤ(SDIO・MMC)ドライバたちの実装-
来たぞー！
…って来たのはもう2週間以上前ですけど…
144PinのSTM32F4も手に入ったのでSTM32F2の時と同じく中華生基板に組んで
みました。STM32F2とF4はほとんど同じです。特にコードは上位互換があるので
回路を完全に合わせるとF2のコードがそのまま使用できちゃったりします。
まあでもさっさとCortex-M4F用にしてしまった方が良いでしょう。
↑ということでいつものChan氏のプログラムを走らせて
みました。
特筆すべきはF2系では何とか動くものの安定していなかった48MHz動作の
SDIOがF4系では非常に安定してることで、SDカードとさらに大容量/高速な
データのやり取りができるようになっています。ただし高速なクロックに耐え
うるSDカードの選択は必須で、Class10のカードを必ず選んでください。
最近出回ってるUHS-1の奴は逆に駄目なものもありましたので幾つか購入して
試してみてください。あと当たり前のことですが、配線の引き回しももの
すごく重要なので注意してください。
↑でたらめ書いてました。SDカードの仕様上通常モード(NomalSpeed)は
25MHzが上限値でSTM32F2/F4ではUSBとの共用を考えると24MHzが現実的に
安定して動かせられるクロック上限となります。
お詫びして訂正しましま。
んでもって前回さらっとお見せしたSTM32F4 Discoveryの方のいつものですが、
ちゃんとした実装にあたり、周辺にぶら下がってる回路の影響でどのように
構成すべきか悩みました。なぜならば…
SDIO : SDIO_CLKがCS43L22のSDINとかぶってるから使えない
FSMC : 肝心のnRDがCS43L22のResetに、nWRがUSBの過電流検出に被ってて(ry
その他諸々のペリフェラルが被ってて(ry
SPI3 : CS43L22がI2S3として使ってて(ryついでにI2C1も
SPI2 : MP45DT02がI2S2とし(ry
SPI1 : LIS302DLがSPI1(ry
…
まぢでひっぺがしたろかと思いましたが先に書いた通りSTM32F407ZGTが
手に入ったのでSTM32+SDIO+FATFS+FSMCの構成はこっちに実装してDiscoveryの
方は既存のペリフェラルと何とか共存する道を選んでみました。
てわけで妥協したのが以下のSTM32+MMC+FATFS+SPI-LCDのプラン…。
SDカード : SPI1(LIS302DL(SPI通信)と共用)
TFT液晶 : SPI2(MP45DT02(I2S通信)と排他)
※STM32F4DiscoveryではSPITFT液晶のみ対応
その他 : CS43L22は丸々残す！
UARTはUART2(TX:PA2 RX:PA3)
SDカードとSPITFT液晶はもちろんDMA化してあります。
TFT液晶がシリアルしか使えない上にMOSIがI2Sの入力とかぶってしまうので
MP45DT02とは排他になっていますが、必要な人はGPIOによるソフトSPI
(超遅いですが)で逃げてもよいと思います。
私のLCD表示ドライバは潰しが効くようにかなり柔軟にデバイス依存の部分を
作り込んであります。またSTM32F1系ではペリフェラルはひとかたまり単位で
しかリマップできない構成でしたが、F2系以降はピン単位で柔軟なリマップが
できるようになったのでみなさんもデータシートとにらめっこして工夫して
みてください。
とりあえずSTM32F4 Discovery上でこの構成でハード改造を行わずに音楽
再生はかろうじてできるでしょうか？
音再生関係の作り込みはこれからなのでがんばってみます！
てわけでいつものコードでSDカードの読み出し速度比較を行ってみました。
使用したカードはClass10が策定される前に販売されたATP製4GBClass6の
microSDです。
STM32F4Discovery上で組んだFatFsは先に書いた通りの構成ですが、SPI1は42MHz
まで叩きだせるので読み出し速度もめっちゃ速いです！(注：SDカードは選びます)
音楽再生程度ならもう十分な早さですね♥今回の実装に際してMMCのSTM32用
ドライバも移植性をかなり高めた作りにしてみました(もちろんDMA化も)!
ちなみにDMA化に際する注意事項ですが前回も言及していますが、CCM領域を
DMAの読み書き先として利用することは一切できません！STM32F4系でCCM
領域を高速なスタック領域として使用する前提でF2系から移植を考えた場合、
既存のプログラムがauto変数をDMAの読み書き先として定義されていると
特定困難な不具合に悩まされる可能性がありますのでよく吟味してください。
お次は中華生基板(STM32F407ZGT6)で組んだSDIOの読み出しスピードです。
上にも書いていますが、F2系ではコケまくって全く安定してなかった48MHzの
クロックでも安定してアクセスができるようになり、20MByte/Sec以上の
すさまじいスピードで読み出しが可能になりました♥ちなみにこの
基板上ではFSMCもDMA化してます！
バグ出しもほとんど終わり、最低限のドキュメントもそろいましたので
STM32F4 Discoveryと中華基板対応のいつものコードを公開します。
makeファイル内の定義でSTM32F4Discoveryと中華生基板のビルドを切り替える
ことができます。その他細かい部分のノウハウは口で説明するよりソース見て
もらった方が分かると思います。
だから誰か早くSTM32F4Discoverymp3プレーヤー作ってくだち！！
20121220追:
STM32F4Discovery用でMP3再生機能追加しました！
あ、お伝え忘れてました。今回の公開に当たってSTM32F2系とSTM32F107、そして
最近この検索ワードでアクセスが急増中のSTM32VLDiscovery向けのFatFs+液晶表示
プログラムも大幅に更新しておきました。
んでもってOpenOCD用Flash書き込みCFG群もSTM32F4xx用を追加しておきましたよぅ
STM32F4シリーズを使ってみる2 -STM32F4のメモリ構成を理解し基礎を作る-
20111201追：
最近複数の方からメールでご指摘いただきましたが、私はこのwikiとは関係ありません。
私の今回の記事からいくつかの文章を丸々コピペしていますが、私が後日誤りに
気付いて修正した内容が修正されずそのままになっていますので信用しないよう
注意してください。
20111201追：
今回は前回述べたとおり192kByteに増強された内蔵SRAMをどのように使うかを
決定し、お約束の標準関数の使用やFPUを用いた浮動小数点の計算をSTM32F4
Discovery上で実践してみます。
STM32F4系は192kByteのSRAMを持っていますが、実際は112kByte,16kByte,
64kByteの3ブロックに分かれています。後で図示しますが、112kByte分は
AHBバスマトリクスに接続された汎用SRAMで,16kByte分は同じくAHBバス
マトリクスに接続されているものの、112kByte分のSRAMと同時に読み書きが
できるように(主にEtherNetMAC&USB-OTG(HS)用に特化されているようです)
なっています。
アドレスは連続しているのでEthernetやUSB-OTG(HS)を使うつもりがない人は
128kByte分まるまる汎用SRAMとして使用することが出来ます。
その他細かい制約があるので各自データシートやマニュアルを参照のこと。
☝丸投げ
もうひとつの64kByte分はCore-Coupled Memory(CCM)と呼ばれ、Cortex-M4Fの
コアに直接接続されています。このSRAM領域はAHBバスマトリクス上にはなく、
DMAの読み書き先としてこの領域を使用できません！
(20111026追：実際に試しましたがHardFaultになったりDMAが完了
しなかったりで、やはりDMA用のメモリとして使用できませんでした）
また、128kByte分の汎用SRAMもSTM32F4のコアクロックと同様の168MHzで
アクセスできるので俗に言うTCM(Tightly-Coupled Memory)としての速度的
優位差もほとんどないでしょう。
以上の点を踏まえて、STM32F4系でつぶしが利くようにねむいさんはSRAMの
構成を下図のようにしてみました。
64kByteもある広大なスタック領域を君はどうつかうのか！？
注：CCM領域はDMAできません！！大事なことだから２度言います！！
この構想をリンカスクリプトに落とすと下図のような感じです。
この下にも長−く各セクションの定義が続きますが省略。
この構成で前回のTFT-LCDの表示テストも改めてクリア・またprintf系の
標準関数もUARTにリターゲットして動作を確認しました。
次にFPUを使って浮動小数点の演算のテストに取り掛かりました。
Cortex-M4Fは単精度の浮動小数点ユニットを持っています。GCCコンパイラから
この機能を使うためには浮動小数点命令に落とし込むようにフラグを与えて
あげないといけません。
具体的にどういうフラグを与えるかについては酔漢氏が昨年に考察されていました。
氏の情報を元に私の環境では以下の箇所の変更で単精度の浮動小数点命令に
切り替わりました。
-msoft-float("-mfloat-abi=soft"と同じ意味)
↓
-mfloat-abi=softfp -mfpu=fpv4-sp-d16
-mfpu=fpv4-sp-d16は必須です。これが無いと倍精度の命令を使ってしまい、
実行したとたんにHardFaultになってしまいます。
ちなみに-mfloat-abi=※※※※ の意味はそれぞれ以下のように表されます。
-mfloat-abi=soft ：浮動小数点の演算に整数命令のみで構成された
浮動小数点演算ライブラリ(soft-float)を使う。
-mfloat-abi=softfp ：浮動小数点の演算に浮動小数点演算命令を使うが、
floatを引数にする関数の呼び出し規約はsoft-floatと
同じく汎用レジスタを使って値を渡す。
(↑この仕組みはソフトウエア・リンケージといいます)
-mfloat-abi=hard ：浮動小数点の演算に浮動小数点演算命令を使い、
floatを引数にする関数は浮動小数点レジスタを使って
値を渡す。
酔漢氏のページでは"-mfloat-abi=hard"となっていました(GCC4.5.xからこの
オプションが利用可能)が、無償で利用できるSourceryCodebenchLite版にある
標準関数等のライブラリはsoft-floatでビルドされているため、標準関数を
絡めるとリンク時に引数渡しの不整合がおきてエラーになります。
これを回避するためにはCodebenchLite版のビルド済ライブラリを使わない設定
(-nostdlibオプションを付ける)を付与し、同じ機能を持つライブラリを一から
"-mfloat-abi=hard"でビルドしなおさなければなりません。
というわけでいちいちビルドするのめどいので以後は"-mfloat-abi=softfp"で。
20131226追:
GNU Tools for ARM Embedded Processorsなら"-mfloat-abi=hard"が
使用可能です！！
これでFPUの命令を含むプログラムがビルドできるようになりましためでたし
めでたし･･･と言いたい と こ ろ だ が ！
ここも嵌ると思うので記しておきます。Cortex-M4Fの仕様によるとFPUは浮動
小数点命令が行われる前に(つまり起動時)に有効にしてやらないといけません。
STM32F4xxのサンプルではsystem_stm32f4xx.cのSystemInit()の最初で実行
されているものもありますが、テンプレートからsystem_stm32f4xx.cを生成
するとこの記述が欠けているのでほとんどの場合は自分で追加しないと
いけません。
☝のような感じでFPUの有効化を行ってください。
20120410変更：
実際にコンパイルオプションを変えて浮動小数点演算の箇所のアセンブラ
リストを比較してみました。Launchpad提供のGNUToolchainを使用しています。
●-mfloat-abi=soft
FPUを一切使用しない場合です。FPUのレジスタは一切使用されず、また
浮動小数点演算ルーチンが呼ばれています。
●-mfloat-abi=softfp -mfpu=fpv4-sp-d16
FPUを使用する場合(SoftFP)です。関数の値は汎用レジスタで渡されています。
●-mfloat-abi=hard -mfpu=fpv4-sp-d16
FPUを使用する場合(HardFP)です。関数の値もFPUレジスタで渡されています。
printf関数は暗黙の型変換によってfloat値を渡してもdouble型に強制変換
されます。単精度のFPUしかもたないSTM32F4ではdouble型に変換するための
__aeabi_f2dルーチンが必ず挿入されます。
ってわけでこれでほぼ完全にCortex-M4Fとして開発を行う下地が整いました！
現在はSDカードとSPI接続のTFT-LCDとUARTをつなげていつものをこしらえる
ところまで進みました。STM32F4 Discoveryの回路構成の都合で、SDIOとFSMCが
使用できないのでSDカードもTFTLCDもSPI接続です。
はやくこいこいSTM32F407ZGT6!
あ、そうそう、Chan氏のTJpegDecも組み込ませてもらってます。
STM32F4はぢめました
…きちゃった♥
…STM32F2すら使いこなせてないうちにCortex-M4コアのSTM32F4が来て
しまいました…！
CPUクロックが168MHzにアップした上にFPU&DSPユニットが付きさらに
メモリも192kByteまでお付けしてお値段据え置き(購入当時日本円換算で1280円)
ですって奥さん！！
チップ単体はまだ手に入らないので(これも時間の問題ですね)すが、
評価キットとしてSTからSTM32F4Discoveryがすでに販売されています。
この評価キットはI2SコーデックにMEMSセンサもついていてアナログ信号の
処理も手軽に扱えそうですていうかそういう風に使わざるを得ないでしょうね…
苦手ですが。
20111201追:
秋月さんからも1650円で販売されました!
20230709追:
うわぁああああ4600円になってるうぅうううう１！！１！！
てわけでさっそく動かしてみました。すでにSTM32F4Discoveryの
ファームウエアパッケージで予習済みなのでいつものTFT液晶を
使って何か表示するプログラムをビルドし書き込んでみます。
CodesourceryはすでにCortex-M4Fに対応しています。ビルドオプションと
しては少しの変更でビルド可能です。
(注:上記のオプションではまだ不完全で、FPUを使った演算になりません！
FPUを有効にする方法はこちらを)
STM32F2系(Cortex-M3)とアッパーコンパチであるため、OpenOCDはそのまま
読み書きとデバッグ(FPUレジスタ除く)を行うことが可能です！
ねむいさんはビルドしたプログラムの書き込みにVersaloonのSWDを使用しました。
(注：エラッタのせいでSTM32F2系とまったく同様のMCUIDとなっているようです。
VersaloonはコアIDのほうは判別は行っていないようなので
引っかかりませんでしたがFT2232系のJTAGアクセスではコアIDの判別に
引っかかり、STM32F2系のcfgファイルのまんまだと警告を出しますが、
先に述べたとおりアッパーコンパチのため、とくに実害はありません。
私が公開しているOpenOCD用のCFGファイル群
はすでにSTM32F4対応済です。)
びぃぶろくんが、かわかわ美人さんに欲情すると困るので小さく
20120124追：
Gaijinさんがinai-sanはHENTAIだって
とりあえず今回はほんのさわりだけですが、次回はせっかく192kByteに増強
してもアドレスが連続してるのは128kByte分でそのうちの16kByteはEthernet&
USBOTG-HSのDMA専用に事実上取られてしまうので実質112kByteで残りの
64kByteはバスマトリクス上にないから微妙に使いどころがないという
内蔵RAMの効率的な使い方とかをリンカスクリプトの組み方と交えて実践
していこうと思います！
STM32 EvoPrimerを買った...
世間ではSTM32F4シリーズが発表、音系に特化したSTM32F4Discovery
なんかももうすぐ手に入るようになった昨今ですが、８月末に秋月で纏め買い
してるついでに購入してしまいました･･･。こんなの買ってしまった時点で
｢私は情(に)弱(い)です｣って言ってる様なもんですね･･･orz
･･･まぁいいや。
↑STM32Primer1,2の後継となるEvoPrimerです。
↑今回のはCPUカードを差し替えることによりSTM32F103系、STM32F107系、
STM8S系の評価を行うことが出来ます。
逆に言うとEvoPrimer本体だけ買っても何も出来ません！
↑ねむいさんはSTM32F103VET6が載ったPrimer2を持ってるので
STM32F107系のCPUカードを選択しました。
↑カードを挿して(めっちゃ硬い)真ん中のボタンを押すと"Welcome to STM32!"
のボイスとともに初期設定画面がでます。ちなみに初回購入時はEvoPrimer本体
からCPUカードからスタンバイ電源を供給するためのスイッチをONにして
おかないと起動の度に初期設定をする羽目になるので注意です。
↑早速中身を開いてみました。
QVGAの液晶やI2S等のデバイス盛りだくさんです。ちなみにこのQVGA液晶は
ピンの設定で8bit,16bit,SPI(←これ重要)が使用可能な逸品です！
液晶モジュールのデータシートを穴のあくほどよく見ましたがこの
モジュールはSPIの設定はできるもののSDI/SDOのピンが出ておらず実質
8/16bitしか使用できません。
しかもEvoprimerとしては8bitバスしかサポートしてません。
さらに言うとCタイプだと素直なピン配置になっておらず、わざわざ
ビットシフトしてから書かなければならない回路構成になってやがるので
描画がSPI並みにくそ遅いですorzorz
20130107衝撃の事実判明！！！
ちゃんと調査したところコントローラICはちゃんとILI9325でしたが、
なんとFPC内部でSDOがD0に、SDIがD1に直結されていてSPIでもデータの
読み書きが可能なことを確認しました！！！！
↑STM32Primer2で致命的となってしまった電源回路ですが、回路図を
見渡す限りでは対策がされている様なので今回は大丈夫だと思いますよ。
た ぶ ん
↑STM32Primer2と並んで動かしたところ。
一回りおっきくなってて持ち運びができません…。
その他EvoPrimerと同じく買ってたもののまったく触っていない物達･･･
↑LPC1227LPCXPresso(上)とLPC11U14LPCXPresso(下)ですって奥さん！
11U14の方って反対側にUSBminiBコネクタついてるわりには3.3Vの
レギュレータ無いからうかつに切り離せられないじゃないですかーやだー！
あとXmegaでよく分かられたとは思いますがねむいさんはLPC系の
ARMマイコンでDMAを使いこなす知能がないのでLPC1227の方はあつ氏や
todotani氏の作例を参考に弄ってみようと思います。
ちなみに上記二つのデバイスはSWD接続しかなく、まだVersaloonが
対応してないので手も足も出ません！･･･といいたいところですが･･･(下記に続く)
↑お次は台湾NuVoton製のcortex-M0マイコン、NUC120さんだ！
基本的なドキュメントやサンプルコードは出揃ってるのでこちらも
時間を見て･･･もちろんまったく触ってま(ry
ちなみに書き込みはNulinkと呼ばれるSWD接続可能なライタです。
KeilやIAR等の開発環境からしか使えないと思いきやCooCoxのCoFlashという
フラッシュ書き込み専用ツールを使うとスタンドアロンで書き込みできたり
します♥
↑このCoFlashというツールですがハードウエアが上記のNulinkに加え、
JTAGkey,JTAGkey2やST-Link等の有名どころにも対応してるので書き込み専用
としてもかなり使えると思います！
↑これも脊髄反射で購入してしまった･･･
ほんっとマイコンしか触ってない私ですがFPGA忘れてしまわないうちに
何とかしたいですはい･･･
GPSを試用する3
STM32Primer2を使用したGPSロガーもだいぶ安定してきましたので、
STM32 Primer2GNSS Tr@ckerのファームウェアを公開します。
動作させる際は下記ハードウエアの改造を必ず行ってください。
１．STM32Primer2の電源ICをLDOに置き換えて強化する。
２．リポ電池をこれに交換する。
JSTのコネクタははずしてリードを基板に直ハンダで。ショートに注意！
３．GPSはGT-723FもしくはUP-501を使うものとする。
ボーレートはデフォルトの9600bpsで。
４．GPSの電源はLCDバックライトの3.1V系から取るものとする。
(LDOに変えた時点で3.3Vになりますが)
５．GPSは下記のピンのみSTM32Primer2と接続する(GT-723Fの場合)
1pin(GND)
2pin(VCC)
6pin(SerialOUT,LVTTL)
６．GPSの1-2pin(GND-VCC)の近くに16V,10uF,X5R以上のグレードのMLCCを付ける。
７．STM32Primer2にmicroSD/microSDHCカード(1GB〜16GBまで動作確認済)を
挿しておく。もちろんFat12/32でフォーマットしておくこと！
ファームウェアの動作としてはSTM32Primer2の十字キーのセンター(CTキー)を押して
電源投入。投入時はSTM32は36MHzで動作しています。投入後のキー操作でGPSロガー
モードとマスストレージモードに動作が分かれます。いずれのモードもリポ電池の
電圧が3.3V以下になると自動で電源OFFの操作がされシャットダウンします。
●GPSロガーモード
電源投入直後に十字キーを何も触らなければGPSロガーモードに突入します。
シリアルのボーレートの適正な(9600bps)データが受け取られたら緑LEDが
点滅します。この点滅はGPSが衛星を補足するまで続きます。
捕捉後は緑LEDは消えて以後はmicroSDにデータが書き込まれるごとに赤LEDが
点灯します。ロギングを止めるにはセンターキーを3Sec以上押し続けた後
離してください。
LCDがOFFになっているのでよく分からないとはおもいますが代わりにGT-723Fに
あるLEDが消えるのでOFFされたことが分かります。
●マスストレージモード
電源投入直後0.5Sec以内に十字キーの右を3Sec以上押し続けるとSTM32の動作
周波数が72MHzに上がり、LCDが点灯初期化され、"Start Mass Storage"
と表示されます。
この状態でSTM32primer2にある"STM32"側のUSB-miniBコネクタとUSBケーブルで
接続するとPC上にドライブが見えるようになり、USBカードリーダーのように
通常のファイルの操作を行うことができます。
GPSのデータを取り出すためにいちいちSTM32primer2の蓋開いてmicroSDカードを
取りだして別のリーダーで読みだすと言った煩雑な操作はもう必要ありません！
上記ハード・ソフト構成で捕捉状態だと11時間以上ロギングできるので日帰りならば
十分に使用できる代物だと思います。実際には保険代わりにCanmoreのスポーツガイド
メイトGP-101持ってってますが〜(これはデジタルコンパスがあるので結構重宝する)。
中太郎生・丸八酒店手前にて。
てわけでほとんどの人は興味ないでしょうけど自作のGPSロガーで記録していった東海
自然歩道山の辺ルートの後半編を…
��長谷寺->室生口大野
長谷寺の回廊。
初瀬ダム(まほろば湖)。
室生ダムとダム穴。
��室生口大野->中太郎生(なかたろう)
大野寺の弥勒磨崖仏。
済浄坊渓谷の滝。
亀山峠から見た曽爾高原。
��中太郎生->西青山
伊賀富士・尼が岳。下山路で蜂に追っかけられる。
メナード青山リゾート。
廃墟のような近鉄西青山駅。
��西青山->柘植
青山高原の三角点の手前。強風と大雨が叩きつけるいい天気だ〜！
風力発電の風車…だがガスにおおわれて視界ゼロの恐怖！
新大仏寺の山門。
霊山についてころにはすっかり晴れ、朝に通過した
風車群もくっきりと。
東海自然歩道の本線ルートと合流し、柘植駅に再び到着。
本ルートの関ヶ原から先は11月から再開なのでこれまでは平地を走り込みつつ
ご無沙汰だったSTM32F2の続きやっていこうと思います。
F2向けのUSBライブラリもやっと出たし！
Windows10対応軽量シンプルな環境でARMマイコンをInsightとOpenOCDを使ってデバッグする(2020年度版)
20230711追記！！！
GCC12でビルドされたelfファイルは下記のinsightを使った
方法ではスムーズにデバッグできません！！
現在GDB+CodeLiteによる新しい時代に即したデバッグ
手順を作成しておりますので完成まで今しばらく、
いましばらくお待ちくださいませ！！！１１！！
OpenOCD for Windows is HERE!
↑ねむいさんは自前ビルドのOpenOCDバイナリ公開してます。
解説はこのバイナリを基にすすめますので4649!
この記事は前回からの続きです。前回のものよりちょっと内容が難しくなってます。
前回の内容を基に環境を構築していることが前提で話を進めさせていただきます。
今回はOpenOCDを使用し実際にARMマイコンにJTAG/SWD経由でフラッシュ書き込み
そしてデバッグを行うところまでいきます。
もちろん今回も軽量動作,NO-Eclipse,NO-Cygwinです。
※今回の記事も時代に合わせて適宜加筆修正していきます。
●必要なもの
1.ARMマイコンが実装されたターゲットボード
凡例として、STM32F4シリーズであるSTM32F4Discoveryを使用します。
私が配布しているSTM32F4向けのFatFs移植例は、デフォルトのターゲットボードが
STM32F4Discovery、デバッガハードウエアがSTLink/V2となっています。
Nucleo系板や2015年以降発売のDiscovery系板はSTLink/V2-1に変ってます。
↑とりあえず何も編集しなくてもよくなってます。
2.JTAG/SWDデバッガハードウエア
上記のCortex-M4はデバッグユニットとしてJTAGとSWDという接続方式の両方を
サポートしています。ARM7TDMIはJTAGインターフェースのみでした。
現在、ホビーユーザーが手軽に利用できるものとしてFT2232系を使ったJTAG
デバイスが主流です。
以後の解説はそれを利用したJTAGKey2互換の"JTAGKey2 Compatible"
を使用しJTAG接続にて解説していきます。
JTAGKey2 Comatibleを自作される方はこちらの解説を参考に。
SWD接続についてはCMSIS-DAPが現在の主流となっています。
NxP系の評価ボードにはmbed版としてデフォルトで搭載されているので
もはやおなじみだと思います。
その他の品種ではVersaloonや上記のJTAGKey2CompatibleでもSWD接続可能に
なっています。
2023年現在はCortex-M系マイコンが主流となり、SWD接続がデファクト・
スタンダードなっております。
3.OpenOCD
OpenOCDはターゲットMCU(ARMマイコン)と後述するgdb/insightの仲介役を
果たすフラッシュ書き込み機能を持ったサーバープログラムです。
ねむいさん謹製のビルド済みバイナリを用意しておりますので、
OpenOCDのWindowsバイナリはこちらからダウンロードしてください。
注意すべきはデバッガハードウエアに対するドライバで、上記リンクに
あるOpenOCDバイナリは下記のデバイスとドライバをサポートしています。
*JTAGKey2をはじめとしたFT2232系デバイス:(WinUSB)
*Versaloon:(WinUSB)
*STLink/v2:(STMicro純正/WinUSB)
*TI-ICDI(Stellaris Launchpad):(TI純正/WinUSB)
*J-Link(WinUSB)
*J-Link On LPCLink2(WinUSB)
*CMSIS-DAP(HIDとしてドライバレスだがmbed版はVCPドライバ必須)
*STLink/V2-1(VCPドライバ必須)
各ドライバのインストールは以前は、PID/VID調べてINFファイルを作って
…と非常にめんどくさかったのですが、現在はWinUSB向けのGUIな汎用
インストーラのzadigを使用することによりインストールが大幅に簡略化され、
手軽になりましたのでzadigでインストールを行ってください。
公式のサイトにはインストール手順も英文で懇切丁寧に書かれていますが
見る必要も無いくらい簡単にWinUSBが導入可能です。
注：このOpenOCDは32bit版ですが64bit版Windows環境でも問題なく動作します。
64bit版OpenOCDと比べて速度的な面で大差はないです。
ARMは新旧の情報がweb上のいたるところで倒錯しすぎて何が正しい組み合わせか
分からないと思います。Windows環境でOpenOCDを使われる方は私のぶろぐを
しっかり見ていただければ途方に暮れることだけは避けられるかと思います。
４．Insight(gdb-gui)
InsightはgdbのGUI版です。また、純粋なフロントエンドではなく内部にGDB
そのものが取り込まれているので別途gdb.exeを用意する必要はありません。
当ぶろぐではこれを使用しソースコードレベルのデバッグを行います。
これも詳細は後述しますがバイナリが配布されていますのでビルドする必要は
ありません。
●下準備
１．OpenOCDの準備
かつてWindows環境にてMSYS/MinGWを用いた手順を公開しておりましたが、
OpnOCD0.8.0以降はビルドするまでの手順が大幅に煩雑になり慣れてない
人にはビルドがほぼ不可能になってしまいましたので公開を廃止しました。
代わりとしましてビルド済のWindowsバイナリを公開しております。
ご利用ください。インストール箇所は前回のビルド環境構築手順に倣い、
C:/devz/arm/ocdにあるものとします。
２．Insightの準備
SourceForgeにあるNetXのページのかなり下のほうにある
"arm-none-eabi-insight-7.4.50.20111222-cvs-mingw32-netx.0.7z"を
ダウンロードし、任意のフォルダに展開してください。
こちらもC:/devz/arm/insight/binにあるものとします。
●ターゲットデバイスにプログラムをダウンロード
前回の手順を参考にSTM32F4-Discovery用のmain.elfが作成されたものとします。
デバッグ時は最適化オプションを必ず"-O0"にしてビルドしてください。
１．makeファイルの編集
前回も解説しましたが、makefileにあるOpenOCDとInsightがインストール
されているパスを指定してください。
Insightの引数は下図下段の要領で"--eval-command"で渡すように記述します。
Insight起動後のTargetの設定は一切不要です。引数の内訳は以下の通り
--eval-command="target remote localhost:3333"
-> TCP3333番ポートに接続
--eval-command="tbreak main"
-> 接続後main関数の先頭で一時停止
-nx
-> .gdbinitを作成しない&内容無視
２．PN2の設定
PN2の"TOOL"から呼び出すことが出来るように前回と同じ要領で引数つきで登録し
てください。登録するのは"program"と"debug"です。
３．書き込み
"TOOL"から"make program"を呼び出し、OpenOCDからSTM32のフラッシュ
書き込みスクリプトを呼び出しターゲットデバイスに"main.elf"を
ダウンロードします。
OpenOCDのcfgファイルのパスの指定が間違っているとエラーが出ますので
各自の環境に合わせてパスを修正してください。
４．フラッシュ書き込み用のコマンドについて補足
makefile内では以下のように記述されています。
1.OpenOCDをJTAG・SWDデバイスのcfgファイル・ターゲットMCUのcfg
ファイルを"-f"コマンドで指定して起動する。
2.同時に-cのコマンドでターゲットMCUのcfgに記述されているproc(関数)
を呼び出す。
3.procに記載されている順にコマンドが実行されフラッシュ書き込みを行う。
上記一連の動作にてgdbやtelnetからの回りくどい操作は一切要せず、簡単に
フラッシュの書き込み動作が可能です。
●ターゲットデバイスをInsightを使用しデバッグ
１．makeファイルの編集
正しくプログラムが書き込まれたことを確認したら次はデバッグです。
makeでOpenOCDとInsightを同時起動するためにちょっと工夫を凝らしています。
先に定義したディレクトリパスやコマンドを下記のように配置して、
クリック一発で呼び出しできるようにします。
２．OpenOCD・Insightの起動と接続
"TOOL"から"make debug"を呼び出すと、OpenOCDがターゲットMCUに接続、
その後Insightが起動します。
さらにOpenOCDとInsightのTCP接続まで一気に進み画像のようになれば成功です。
ここで注意ですがWin10ではInsightのメニューにあるTarget Settings関連を
いじるとInsightが固まってしまい動作不能になるため絶対に
触らないでください！
この状態で"Continue"を押すとmain関数の最初の行、一時的にmain()に張った
ブレークポイント(main()の最初の行)に飛びます。このブレークポイントは
一時的なものですぐに消えるのでリソースの無駄にもなりません。
ここまできたらあとはInsight上でステップインとかステップアウトとか
ブレークポイント張って停止させたりレジスタとかメモリとか(条件付で)
I/Oレジスタの値読み出したり自由自在です！
また、デバッグ時の重大な注意ですが、Win10ではInsightのレジスタ
ウインドウを開くと100%落ちてしまいますので面倒くさいですがコマンド
ウインドウから"monitor reg"でMCUの各レジスタを参照するようにしてください。
３．デバッグの終了
終了する時はTools->Stop Toolsで終了させたいところですがが、PN2では
ひとつのプログラムしか終了できず、Insightだけが終了してOpenOCDが
終了してくれません。
私は下記の要領で強制的にタスクを殺すwindowsのtaskkillコマンドを使った
バッチファイルを作成してこれを呼び出して"確実に"終了させています。
↓この呪文をバッチファイルにしてwindowsフォルダに突っ込んで
おきましょう。
taskkill /F /IM openocd.exe
taskkill /F /IM arm-none-eabi-insight.exe
GPSを試用する2
STM32Primer2を使用したGPSロガーですが、やっと長時間安定してロギングを
行えるところまで持っていくことが出来るようになりました。
一番の強敵は衛星を捕捉していてもロギングがランダムで停止してしまう
現象に遭遇したことで、どの部分で問題を起こしているかという切り分けに
かなり時間を要しました。東海自然歩道のルートで言うと湯ノ山温泉->
西藤原のルートから始まって笠置->奈良くらいまでは特別なファームを
あれこれ試したりノイズ抑制のためにコンデンサ追加したり導電性エア
キャップにやさしくくるんだりあれこれ試しようやく不具合を特定しました。
(結局FatFsの書き込み時のエラー処理が不適切なだけだった･･･)
ついでに使っているGPSモジュールもGM316+外部アンテナから秋月さんちから
2月にラインナップに加わったCanMore製のGT-723Fに変更し、なかなかの
結果を収めています。
↑比較表作ってみました。
GT-723Fは衛星を見つける最初期のacquisition(同期捕捉)の段階では
80mA以上喰ってしまってしますがtracking(同期追跡)状態に入ると32~36mA
前後まで落ち着き、結果的に野外で使うなら電池の持ち的にもGM316+外部
アンテナで使うよりも有利なのが分かりました。元主人の持ってたGT-720Fは
常時180mA位馬鹿食いしてたのをかんがみると技術って進歩してるんだなぁ･･･
とおもうことひとしきりです。
↑現在の運用形態。STM32 Primer2からVCC,RxD(STM32 Prime2側),GNDを
引き出し、なおかつGT-723Fは別に基板を設けて固定して機械的にも
接続を強化してます。
また、このモジュールは+3.0Vからの電源入力に対応していますので、
STM32Primer2だとLCDのバックライト電源からパワー(3.1Vavg)を拝借する
形となります。
↑尤もSTM32Primer2いじり倒してる人はとある理由で当然電源周りも改造してて
原形とどめてない人も多いでしょうからもう好きにすればいいと思いますよ
(☝投げやり気味)。
↑JR笠置駅にて。
ねむいさんチキンなので実際に使う時はGPSモジュールを導電性エア
キャップにくるみ、さらにここからSTM32Primer2全体をGPSモジュールごと
くるんで物理衝撃対策してます。
この状態でもザックにぶち込んだ状態で氷点下の環境はもちろん猛暑の中
でも安定して動作したので満足です♥
タフすぎて そんはない
肝心の捕捉精度なんですけどGT-723Fはパッチアンテナのみですが深い森の
中でもしっかり衛星を握ってくれていて、逆にトンネルやトイレ等の電波が
完全に遮断される場所では案外簡単にぱっと手放してくれるようです。
GM-316の場合は電波が途切れても捕捉状態から離れずでたらめな場所を記録
してしまうことがよくあったので山中の行動の記録に使う用途としてはGT-723Fの
ほうが良いかとおもいます。
それとGT-723F買ったときに結局ついでに買ってしまったのですが市販品の
スポーツガイドメイトと比較した場合もほとんど引けをとらない結果になってます。
↑結局買ってしまった･･･Garminは高いから論外で(欲しいけど)
↑スポーツガイドメイトは電源ボタン長押しでOFFではなくワンプッシュで
OFFとなってしまう設計のため、ザックに無造作に放り込んで山野を走る
ような荒っぽい使い方は出来ないのが難点です(自転車に固定して使うことを
想定されているようです)。
PCとの接続は内蔵のUSB-シリアル変換でUSB経由でデータの読み書きをします。
↑これはJR奈良駅から近鉄長谷寺までのルートを同時に記録したものです。
ほとんどぴったり重なっちゃってるんですけど赤のラインがスポーツ
ガイドメイトで青が自作のGPSロガーです。
本末転倒になってしまっていますが、ロギング中に一方が何らかの理由で
停止しても困らないように現在は両方持って山に行ってます。
本当に本末転倒ですがもういいです(投げやり気味に)。
おまけ
私のぶろぐの中でpvが圧倒的に少ない、つまり人気が無いのが東海自然歩道
関連の記事なのですが、一部の方々にブラウザのベンチマークとして使われて
いるのを知ってまぁ少しは役にたっているかなと思ふことひとしきりですが、
それはおいといて山に興味がない方はドリフの雷様的な物と思って
あきらめてください。逃がしません…(ワグナスさんみたいな顔で)
東海自然歩道の山の辺ルートは本道ではないのでぶろぐには書かないつもり
でしたが、今回は特別にダイジェストを･････！
��石山->宇治
このルートは99%舗装路でした。
ゴール地点の平等院鳳凰堂。
宇治茶のアイス(宇治茶+桜だそうな)
��宇治->原山
やっぱり舗装路。
見所(というかこれしかないけど)の鷲峰山。
加茂駅と昔からある倉庫。
(※体力あまってたので原山から加茂駅まで走って帰りました)
��原山->笠置
童仙房山荘。
ないおん！
高山ダム。ここから先が長い。
関西本線が間近に！ｃ
ゴール地点のJR笠置駅にある良く分からない像。
��笠置->奈良
柳生家老屋敷。
一刀石。
日照が体力を削る季節になってきました･･･。
峠の茶屋。
鹿。
��奈良->長谷寺
鹿。
一番やさしいルートですが夏場だけは
逆に一番過酷なルートに！！！
石上神宮。
大神神社領からの展望。
狭井神社のハイテク御神水供給装置。
長谷寺山門
長谷寺駅からの夕暮れ。
これから夏本番です。夏場の激しい運動は熱中症や脱水症状という直ちに死ぬ危険
性の高いリスクが常に付きまといます。ねむいさん絶対に日焼けしたくないので
長袖とUVカットのゴーグみたいな眼鏡で完全ガードしてるおかげで上記のリスクが
さらに高まるので一応そっち対策もばっちりしてる(つもり)です。
欲張らずに走る距離は30km以内に抑え、朝早く出発して遅くとも15時までには走り
終えて帰るというのを心がけるようにしてます。
あとせっかく体重落ちたのに風呂上りにうっかりビール飲まないようにｓｈ…
ビールには勝てなかったよ…ﾌﾟﾊｰ♥
LPC2388向けのデモを整備しました
5月末、STM32F207V/ZGT6を夢中でいじっていた折に、がた老氏からLPC2388
向けのプログラム、とくに割り込み動作について質問をいただきました。
LPC2388については、TFT液晶表示プログラムだけは更新を続けていてそのほかは
去年の1月以来放置状態でしたので、動作チェックがてら更新してみようかと
おもっていたらおもいくそはまったので顛末を記録しておくことにします。
起：Thumbモードで割り込みが動かなくなっていたことに気づいた
まずおかしいと気づいたのがこれで、FreeRTOSとは関係なしに最新の
CodesourceryG++ではThumbモードでコンパイルした場合、ユーザーモードから
割り込み許可するためにSWIかましたら先に進まなくなっていたことが判明。
ARMモードでビルドしたり動作確認した１年くらい前のCodesourceryG++の
Verでは正しく動いていたのでこのときはコンパイラのバグかとおもって
放置していました･･･。
承：FreeRTOSのデモもうごかなくなっ(ry
がた老氏はFreeRTOSからRTC(と割り込み)を動かすこと画策されていて、
私の公開していたFreeRTOSV6.0.1向けのデモとBare-Metalなprintfの
プログラムを参考にされていました。
しかしビルドが通らなかったとのことで、どのファイルをインクルード
もしくは定義すべきかを伝えて私もちょっくら確認しますかとおもって
最新のCodesourceryG++を使用しARMモードでビルドして書き込んでみると
なんと動かなかった･･･。
そもそも公開した当初は｢とりあえずこれなら動く｣状態だったため、
KeilのデモやMarthin'thomas氏やChan氏のプログラムやらが全部まぜこぜに
なっていて一年放置後の私が見ても何がどうなってるのかよく分からない
代物になっていました。
実はほかの方からもちらほらそういう質問いただいていたのですが、
これはまずいと思い立ちこの時点でやっとこ大規模な回収改修を
することにしました。
転：スタック領域のアラインメントを8バイトずつにあわせる
動いていたころのVerは"Sourcery G++ Lite 2009q3-68"でしたが
20110630時点で手に入る最新のものは"Sourcery G++ Lite 2011.03-42"です。
このVerはGCC4.5.2になっていてLinkTimeOptimizationというリンク時に
最適化を行う機能が利用可能となっています。またどちらもどちらもABI
(Application Binary Interface)はEABI(Embedded ABI)となっていますが･･･。
調べてみるとEABIはスタック領域のアラインメントを8バイトにそろえるべし。
と記述されていました。audin氏もこの件について触れています。さらに
FreeRTOSのフォーラムにもこの件についてのやり取りがありました。
audin氏は.ARM.exidxと.eh_frameにも触れられていましたがそちらは幸い
回避済でした。私のリンカスクリプトを調べてみると.stackがalign(4)に
なっていました。あらら。てわけでこちらは修正。
この時点でARMモードでFreeRTOSのLED点滅のみの簡単なプログラムは
動くようになりましたが、FreeRTOS上で割り込みがいまだ動かない･･･。
結1：FreeRTOS上においての割り込みを正しく記述する
Sourcery G++ Lite 2009q3-68では割り込みまわりは結構いい加減でも
問題なかったのですが、Sourcery G++ Lite 2011.03-42だと以下のように
しないといきなり動かなかったり、また動いてるように見えても10sec
程度で止まったりでまともに機能しません。
↑UART0を例にとるとUART0の割り込みハンドラのwrapperを作り
割り込みがかかるとまずwrapperに飛ぶようにします。
↑UART0のヘッダファイル内で上記画像のように定義してやる必要がある
みたいです。
がた老氏は最終的に自力で上記の解決方法を見つけられたようで、私ももう少し
調べてから的確な返事をすべきだったと反省してます。同じくおきばやリンク
張ってるけど放置状態のものも最新のコンパイラでビルド/動作できるように
しておくかもしくはばっさり削除することをしないと後に続く人を混乱させて
無駄な時間を喰わせてしまうことになってしまうのでこれから先はこまめに
対処していきますね。
結2：Thumbモードでふたたび割り込みをうごかす
"Sourcery G++ Lite 2009q3-68"では問題なかったので気づかなかった
のですが、本来ならばタイマやUART等の割り込みのハンドラがある
Cのファイルは必ずARMモードでコンパイルすべき
だそうで、それを守ってmakefile内でARMモードでコンパイルする
ファイルを明示してやるだけでよかった。･･･はずでしたが-fltoの
オプション効かせてるとやっぱりエラー吐いてビルドがとまったり
ビルドできても動かなかったりでmakefile内でThumbモードを指定して
いる時は-fltoのオプションを除外するようにしました。
これで"Sourcery G++ Lite 2011.03-42"でビルドしても大丈夫と
なりましためでたしめでたし。
ていうか自分で注意書きかいててすっかり忘れていましたorz
結3：ほかのLPC2388向けのプログラムもレストアする
て言うわけでコンパイラじゃなくてねむいさんが悪いのが分かったので最低限
おきばで公開してるのは最新化しておきました。
特にLPCUSBを使用したMassStorageClassはChan氏のMCIドライバを連結し、
転送速度UPに成功しました！
58MByteのファイルを読み出し
58MByteのファイルを書き込み
以前は0.1MB/s、がんばっても0.2MB/sくらいだったのですが書き込み
0.4MB/s、読み出し0.5MB/sに！さらにArai氏のLPC1768向けLPCUSBの改修例を
参考に最大4GByteまでしか認識できなかった容量も私の手持ちの
SDカードで最大容量16GByteのものが認識できるようになりました。
STM32Primer2のデモも同じような理由で最大4GB制限があり、
今回対処法が分かったので修正しました。
STM32F2シリーズを使ってみる2
てなわけで前回の記事からはや一ヶ月、手探り状態でいろいろ進めているうちに
ST公式でやっとこF-2デバイス用のペリフェラルライブラリが出たり
BeableBoardXM購入合戦に勝利したもののまったく火入れしてなかったり
ALTERAのFPGA評価ボード買ったり
ステーション型はんだごて購入したり
USB接続型PCオシロスコープPicoscope3206Aを破格値でゲッツしたり
探訪も笠置まで進んでたりそうこうしてるうちにSTM32F2シリーズも
普通に購入できるようになってたりする昨今、いかがお過ごしでしょうか？
震災を境に身の回りの状況が一変してしまいましたが、ねむいさんはいない
さんをひざに乗せてくんかくんかしつつできることから着々と取り組んでいく
所存でございます。
勘違いや無知無学が祟って時間を食ってしまいましたが、STM32F207VGT6で
SDIOとChan氏謹製のFatFsを連結させて安定動作できるまでになりました。
SDIOはもちろんDMAを使って高速に転送可能です♥
以前のSTM32F103VET6のものと同じ条件でReadの速度を比べると若干の
向上が得られました！
SDカードだとSDIOは25MHzまでしか出なかったり(MAX48MHz)カード自身の
転送速度もボトルネックになってるとは思いますが、小規模のマイコンで
もこんだけ早かったら御の字ですよね〜。
さらに前回ちょろっと紹介しましたが480x272pixelの4.3inchTFT-LCDの
ドライバも組み込んで"いつもの"をやってみました。こちらもFSMC使った
高速転送です！
ねむいさんへたれだからSSD1963っていうコントローラつきの液晶モジュール
基板使ってますが･･･。
↑タッチパネル入力にももちろん対応。
↑再びぽぽぽーん
STM32F2になってフラッシュも1MByteまで増えたことだし、フォントも扱える
ようになって機は熟したからそろそろ私もChan氏のファイラーは卒業して
おりぢなるなファイラーを作ろうかな、と。
んでもってSDIOとFSMCの高速な転送を利用して動画再生も試みました。
Chan氏のLPC2388向けの動作再生ルーチンをチューンアップしないでまんま
利用してもQVGAサイズで29.97fpsな動画も余裕で再生できたので相当
"ぱわふりゃーなので余裕"なの確認できました。
やっけつだけど一番乗りだからどっかにアップしたいな〜
とりあえず次の一手としてはオリジナルなファイラーの実装に着手しつつ
先日がた老氏FreeRTOSがらみの質問をもらった機会にご無沙汰だったRTOSの
おべんきょもふたたび進めていくつもりです(BeagleBoard-xMとDE0-Nano
から目を逸らしながら)。
おまけ：
て言うかこっからが本題です！！！！
LatticeのispVMがいつの間にかFT2232デバイスに対応していた件
いままでsvfとかUrJTAGとか使って手間のかかる方法しかできなかったのが
嘘のようです！もうこれでLPTポート無くてもいいです！
↑ふつーに認識
↑そしてふつーに書き込み
JTAGkey2Cloneで使うためにはJTAGのOEを常時イネーブルにしておく
必要があります。※ispVMに対応するようにスルーモードをつけて
回路図差し替えときます。
もちろん外付けSPI-ROMにも書き込むことができます♥ispVMは多種の
SPI-ROMに対応しているわけですが･･･つまりこれはLatticeのデバイスが
JTAGで繋がってればUSB接続のSPI-ROMライタが安価にかつ確実に構築
できるというものすごいことでまさに神対応なわけなのです！！
これでマザボのBIOSいくらすっ飛ばして怖くない！
xilinxさんやalteraさんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…
いろいろ試す8
国内は大変苦しい状況が現在進行形で続いていますが、今は新しい生活が
始まる季節でもあります。ねむいさんも二度とていどひくいと
いわれないように言われないように毎年この時期に新たな決意をしながら
勉強を重ねてきたつもりですが彼ははるかにていどたかくなってしまって
やっぱ資質も必要だよねと思いつつLED点滅で足踏みして茶を濁す毎日を
送っております…そうかあの悪たれも今春から阪大か〜…#
…てわけで前回に引き続き今回も小ネタをこなしていきます。
●キャラクタLCDを2線で制御する
元ネタは中華サイトのBBSより。
2線と言ってももちろんi2c液晶ではないです。最低でもデータ4bit+制御
2bit分合計6本のI/Oの接続が必要なHD44780互換タイプのLCDモジュールを
受動部品を駆使してたった２本のI/Oで制御を行うとこのとです。
コンセプトとしてはでんし研氏の鶏卵問題を解決するAVRライタに近いですね。
↑実際にATMEGA1284Pを使用してやってみました。久しぶりにAVR使った…
20230629追:
11年後も同じ事やってる私
●LPC1114のI/Oトグルが遅い?…
> >>278
> main system clock４８Ｍで、ＩＯﾊﾟﾀﾊﾟﾀは約２Ｍだたよ。
とのことです。んなアホなと私も思いましたが、検証用のI/Oをトグルさせてる
部分のコード↓
while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}をGCC4.5.1の-O2でビルドして出てきた該当箇所のアセンブルリストが
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
390: 4a03 ldr r2, [pc, #12] ; (3a0 ) <-2cycle
392: 4b04 ldr r3, [pc, #16] ; (3a4 ) <-2cycle
394: 2100 movs r1, #0 <-1cycle
396: 50d1 str r1, [r2, r3] <-2cycle
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
398: 3101 adds r1, #1 <-1cycle
39a: 4249 negs r1, r1 <-1cycle
39c: 50d1 str r1, [r2, r3] <-2cycle
39e: e7f7 b.n 390 <-3cycle でリファレンスマニュアル首っ引きで調べると合計14サイクル、理論上でもシステム
クロックが48MHzで約3.43MHzくらいでしかトグルすることが出来ない計算になってし
まうので最適化レベルにもよりますけどやっぱしこんなものですね…
ちなみにガチでLPC1114で理論上とりうる12MHzのトグルスピードを出したいのならば
STR命令の部分だけ延々と続くようにしてやればいいので、
while(1)
{
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
〜(出来る限り沢山並べる)
LPC_GPIO2 -> DATA = 0x00000000; // GPIO, write data
LPC_GPIO2 -> DATA = 0xffffffff; // GPIO, write data
}ってしてやるとよいです。
この場合実際のトグル波形は↓のようになります。
Cortex-M0のSTR命令は最短2サイクルのため、GPIOがAHBバスに繋がっている
LPC1114では48MHzの場合は最高I/Oトグル速度は理論上12MHzとなります。
話は変わりますが、audin氏が指摘しているMARY基板で公開しているソースの
ライセンスが矛盾している件ですが、ねむいさん的には金銭が絡まない限り、
つまりソースコード自身はタダで利用できる状態のうちは別に大きく騒がれない
だろうと思われます(ぉぃ
などと偉そうに言ってるそういうお前はどうなんだと言われそうですが、私の
公開しているものは該当するスタートアップのコードはSTM32のアセンブラの
スタートアップコードを参考にしてarm-v6mでビルドが通すことのできる独自の
ものなので…
…ぇーとあのその…セ、セウト！
20111203追：
その後の顛末
あつ氏の見解
audin氏曰くMARYのライセンス形態が修正されたようです
i2c.h,i2c.cに関しては大本のNxPのKeil向けライブラリのライセンスに関する
文章を引用すると...
> Software that is described herein is for illustrative purposes only
> which provides customers with programming information regarding the
> products. This software is supplied "AS IS" without any warranties.
> NXP Semiconductors assumes no responsibility or liability for the
> use of the software, conveys no license or title under any patent,
> copyright, or mask work right to the product. NXP Semiconductors
> reserves the right to make changes in the software without
> notification. NXP Semiconductors also make no representation or
> warranty that such application will be suitable for the specified
> use without further testing or modification.
とのことです。
ざっと見たところ
"ここにあるソフトは製品(ここではLPC1xxx)のプログラムのしかたに
関する情報をカスタマーに提供する例示的な目的のためだけに書かれました"
ってのと
"(あなたが)このソフト使うことに(NxPは)責任も負債も持ちませんし
特許・著作権・製品のマスクワークのもとにあるライセンスや商標も譲渡しません"
という点がミソですね。再配布(redistribution)の制限に関する記載が見当た
らないのですが、再配布たことによって面倒なことになっても俺(NxP)は
責任持たないよと解釈しておけばよいでしょうか。
おまけ
MARY基板でaitendoさんの格安OLEDボード動かして見ましたねむいさんは
CheepにいくZE！これは公開しているプログラムに反映されています。
●SUG○IHUBはSUG○Iのか
http://www.system-talks.co.jp/product/sgc-4X.htm
ねむいさんはシステムトー○ス製のSUH○IHUBを副業元のノートパソコンで
愛用しています。SUG○Iハブは独自の電力増強回路によりUSBデバイスを安定
して動作させることができるという触れ込みです。確かにやっすいUSBハブでは
よく発生する「バスパワーのUSBデバイス挿しただけで突入電流で電圧ドロップ
して同じハブに刺さってるUSBデバイスも巻き添えで認識外れる」現象が一切
発生しません。しかし…
STM32のマイコン基板を一から組んででLDOの動作確認してる時に気づいた
のですが、このハブを使った時だけダウンストリーム側のVbusの波形が
えらめっちゃ汚い…
※ねむいさんが持ってるSUG○Iハブはこっちの少し古い型なので現行の
モデルでは改善されているかもしれません
恐らく独自の電力増強回路(=+5VDCDCコンバータ)のスイッチング時の
出力波形がもろに出ちゃってる感じです。デジタル回路だけならあんまし
問題無いですが、これアナログ含む回路だとこんだけ揺れてるとちょっと
都合が悪いです。
てわけでハブ側の改造でさらにSUG○くできるかしてみました。
基板はDC-DCコンバータとNEC製のUSBコントローラIC,そして2ポート分
(PORT1とPORT2)だけですがUSBパワースイッチャ(電源監視)ICまで積んで
あります。さらにダウンストリーム側には100uFのアルミケミコンが1ポート
ずつ鎮座しています。市販のハブのほとんどが最低限のパーツで寄せ集めた
チープな作りなのを鑑みると値段にしては超豪華な作りだと思います。
で、こんだけ出力に電解乗ってて波形があれってことはESR不足かな？
てことでDCDCの出力部に低いESRのキャパシタ乗っけりゃ解決かなと
判断してねむいさんのトラの子NEC-TOKIN製NEOCAP(150uF/10V品)を
ぶち込んだ！
よし！
てわけでさらにSUGO○くなれたようです。前途のとおりデジタル回路用途
のみなら未改造でも問題無いので昨今のUSB機能付きのマイコンでバリバリ
開発する人には多少のおいたにはびくともしないこのハブお勧めです！
●某付録のRX62N基板
国産マイコンは諸般の事情で全く興味ないので去年と同じく電源周りの挙動だけ…
電源立ち上がり
電源立ち下がり
去年のSH2A基板はLDOの出力が入力が断たれた後も0.数V程ず〜っとチャージを
保ったままになって次回の電源投入時に不具合が出ていました。しかし、
今回は+3.3VLDOにSBDをかまして素早くチャージを放電するようにしてあり、
しっかり対策されているようですね。
いろいろ試す7
この度の大地震で被災された皆さまには心よりお見舞い申し上げるとともに
一日も早い復興を願っております。私も復興支援を私なりにやってみます！
…てわけで電子工作野郎になる時間がなかなか取れなくなってしまったので
今回はもともとタイトル通りいろいろやるつもりだった内容を大幅縮小
変更してお送りいたします。
●AVRマイコンを使ったバックアップ機能つきRTC時計
前回軽く紹介していましたが実用レベルになれたので改めて紹介します。
目玉はRTCのバックアップをATMEGA644pのパワーセーブモードで行い、外付けの
RTCのモジュールを排したコストダウン仕様となっています。表示部は部品箱の
肥やしになっていたNoritakeのキャラクタVFDを使い視覚性も良好でLM60を
使用した温度センサで気温も同時表示出来るようにしました。
気になるパワーセーブモード時の消費電流ですが、ADVANTESTのnAオーダーで
測定できるデジタルマルチメーターで測定したところMAX3uA,平均1uAでした。
CR2032(約220mAh)なボタン電池でも単純計算で3000日以上余裕でバックアップ
可能なわけです♥
元主人がATMEGA328で作ってたやつはバックアップ時にAVCCを断つというｾｺ技を
駆使しても80uA程喰っていたのでそれを鑑みると非常に満足のいく結果と
感じています。
消費電力削減の為にはファームで省電力レジスタ群をいじったり割り込み時の
ステートを考慮するのはもちろんのことですが、VCCまわりの回路構成も非常に
重要です。AVRはSTM32等の今日びのARMマイコンのように独立したパワードメインは
無いので、逆方向漏れ電流の非常に小さいショットキバリアダイオードで
しっかりと分けてやらないとせっかくファームで省電力化できても外部回路から
ダダ漏れとなってしまいます。
こういうの意識しながら作ることを経験しとくと他でも応用が効くと思います。
時計合わせはUARTのコマンドからのみという手抜…シンプルな仕様！
mega328バージョンでは回路に取り込んでいたAVR309を外に出して手抜…
回路の簡素化を図りました!
●STM32マイコンを使ったUSB-CDCが…
※知ってる人もいるかもですがかなり以前の話です
iruka氏のSTM32を使ったUSB-CDCの考察の最後に出てくる魔の時間帯について。
ループバックして、氏のw32termのテストモードを走らせるとこの時間に高確率で
引っかかってフン詰まり状態になってしまいます。単純にダブルバッファリング化
しても同じ結果だったのでUARTのデータを受ける部分の処理がまずいのでしょう。
てわけで魔の時間帯でもデータを受け付けるように…
…しただけでフン詰まり現象は無くなりました！
UARTの通信込みでこんだけ叩きだせるなら恩の字じゃないかしら！？
でもやっぱし専用ICには到底かなわないので…
遊び以外で使わない方がいいですよ(重文)
上記の成果はおきばにあります。
20110406追：
STM32のUSBライブラリがV3.3.0に上がりVCPのデモもこの問題が修正された
…と見せかけて修正されていないようです。ご注意を！
●STM32 ValueLine-Discovery
を秋月さんから購入しました。ねむいさんみたいに買ってすぐにバラすような人
対策か、ST-Linkの部分が切り離すことができません。しかしこのST-Link部も
Versaloon化できるようになっているのでさっそくVersaloon化してみました。
これについては後ほど別記事で詳しく取り上げたいと思います。
↑お約束のTFT液晶モジュール。8bitバス繋げるのめどいのでSPI接続
方式の液晶で…。この評価ボードのセットはSTM32が二つも付いているので
(部品取り基板として)とても利用価値があると思います。
機能限定で単品物作るなら新品でパーツ揃えるより安上がりで最適でしょう。
●トラ技別冊LPC1114ボード
圓山宗智氏作のMARYと呼ばれるLPC1114と周辺のボード群にちょっと興味が
魅かれたので購入してみました。最初はLPC1114基板とCP2104基板で2枚組かと
思ったのですが、本当に同じ基板が2枚(LPC1114+CP2104の基板が2つ)なのですね…
LPCXpressoと大きく違う部分はLPC1114のメイン発振器が内部オシレータ
(LPCXpressoは外部に12MHzの水晶がある)の使用を想定しているのでスタート
アップ時のオシレータ選択レジスタを内部オシレータにしとかないと
動かないといったところくらいでしょうか。
CQ誌のサイトからダウンロードしてきたMARYのサンプルを参考に過去に
作ったとっかかり用のLPCXpressoのプログラムと共用できるようにしてみました。
MARYで動かす時はmakefile内のボードの定義をMARYに変えるだけでおｋです。
中華TFT液晶モジュールを動かしてみる(概論)
※今回の記事は適宜追加・修正していきます。
Arduino等のプロトタイプボードを使ってaitendoさんで売ってるようなMCUバスで動
かすタイプのTFT液晶を専用基板起こさずに無理くそうごかそうとするとどうしても
ジャンパ線山盛り配線になってしましますがこれを8bitじゃなくて16bitバスでやって
みるとどういうことになるかというと…
こういう地獄絵図になるわけでしてもう二度と横着しないと心に誓う。
さて、上の画像表示に使ったのはコントローラICにILI9327をもつDST9901A-NHと
いう3.2インチ、WQVGA(240x400)の液晶モジュールです。データシートには
コントローラICがHX8352Aとか書かれていますがブツはちゃんとILI9327です。
aitendoさんでも同じのを扱っていますが、私はtaobaoで他の商品と一緒に
まとめ買いした物です。
(ねむいさんはHX8352Aのものもちゃんと持っててこれはDST9901A-NHとくりそつなｎです
が8月位に一度ぱ…動かしてるところをお見せしてますね〜…ぬふふ)
データシートや製品紹介に記載されてる内容が現物と全く違うとか言うのは
中華液晶だけでなく中華製品にはよくある話ですが、TFT液晶モジュールを使って
何かを作るのではなくてモジュールそのものを動作させ(ただけで満足して飽き)
ることが目的と化してしまったねむいさんが得た情報をtaobao経由の購入の
事例にからめてお伝えします。
基本的にTFT液晶(とOLED)モジュールは大きく分けてRGB,MCU,シリアルの3つの
接続方法があります。MCUバスとシリアルバスで接続できるモジュールはフレーム
バッファを内蔵したコントローラICを必ず持っていて、AVR等のメモリ資産が無い
小規模のマイコンでも簡単に扱うことができます。
今回はそのMCUバスとシリアルバス接続方式のモジュールついて説明します。
●MCUバス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
↑i8080タイプのMCUバスの場合
ほとんどのモジュールはi8080タイプの8bit若しくは16bitのMCUバスとして
アクセスを行います。一部のモジュールではM68kタイプのアクセス方式を選択
できるものがありますが一般的にi8080タイプのアクセス方式の方が圧倒的
多数となっています(例外的にHD44780とかはM68kタイプですね)。
中規模のマイコンが持っている外部バスで接続したときは、マイコンからは
アドレスが2つだけあるSRAMに見えることになります。
このi8080タイプの方式はMIPI AllianceDBI(Display Bus Interface) Type B
に相当します。
また、データバス幅はコントローラICのデータバス幅選択ピン、ILI系列のICならIMx
に当たるピンをモジュールへのリセット信号入力時に信号レベルを確定しておくこと
によって選択されます。モジュールによっては外部まで出ておらず、FPC上のチップ
抵抗の配置によって決定しなければならない物や16bit幅に固定されてしまっている
ものがあります。
逆に低解像度でサイズが小さいものはFPCの面積的に8bitに固定されていたりします。
以下にaitendoさんでも購入できるモジュール達のビット幅変更箇所等を。
STM025QVT-001はソフトウエアからビット幅が変更可能な逸品なので
おきぱにあるソースコードを参照のこと…。
YHY024006A
EGO028Q02
上二つはFPC上のジャンパ抵抗(0ohm)の配置でバス幅を決定。
WBX280V009
FPC上のジャンパ抵抗(0ohm)を画像の位置に移すとIM0ピンが外部に出る。
…と以前書きましたが最近出回ってるのは少し違う模様。
なんと写真に示すとおりFPC上のパタンで16bitバス固定になっていました。
8bitバスで使ってる方や、Ardunio使いの方は別のTFT液晶モジュールを
使用しましょう。
DST9901A-NH
ビット幅選択ピンは外部に出ている。FPC上に抵抗を実装できるパタンはあるが、
前途の理由でFPC上で作業は不要。
ちなみにFPC上の該当のピンにIMxが出ていなくて実質上NC(NoConnect)になって
るモジュールもありますが、UEW等の極細の線でジャンパを飛ばしてやれば無理やり
ですが外部から選択もできます。ていうかこうしておく方がなにかと便利ですよぅ！
●シリアル(SPI)バス接続方式について
マイコンとモジュールを繋げる基本構成は下図のようになっています。
今日びの一般的なマイコンではほとんど有しているSPIインターフェースを用いて
接続することができます。基本的にMCUバス接続方式とアクセスの手順は変わらず、
パラレルのデータバスがシリアルになっただけです。
比較的小規模の解像度のTFT液晶/OLEDモジュールがシリアルバスの接続方式を
有しています。一部のモジュールでは外部ピンの設定によりMCUバスも選択できる
ものがあります。
このとき一部のコントローラICではシリアルバス接続だとREADができないものが
あります(よってMISOが不要)。
ST7735は一つのラインがMOSI/MISOを兼ねていたりして制御は少々特殊です。
READもするのならハードウエアSPIよりGPIOのソフトSPIの方が使いやすいです。
この方式はMIPI AllianceDBI(Display Bus Interface) Type Cに相当します。
QVGA以上の解像度ではコントローラICがサポートしているにもかかわらず設定用
ピンが外部に出ていないためシリアルバス接続方式が選択できないものがほとんど
でしたが2023年ではHVGA(320x480)解像度でもSPIインターフェースがありますね…。
逆に大きい解像度のRGBインターフェースをもつパネルにもSPI用のピンが出ている
ことがありますが、これはリフレッシュレートやガンマ値の設定専用という
あくまでRGB_IF(MIPI DPI(Digital Pixel Interface))の補助用です。
以下にシリアルバスで接続できるモジュールたちを。
aitendoさんのおなじみ小型OLEDモジュール。バス選択ピンの設定によりMCUバス
接続方式も可能です。このキャリーボードはSPI固定になっています。
コントローラICはSSD1332。少々癖があります。
・CSは8クロック目でD/Cの同期をとるため、下げっぱではだめ。
同じくaitendoさんでも売ってるH161T01。これを使った「TFT-LCD Shield」が
MTM06でNetSynth.orgのブースにて販売されました！そうだね宣伝だね。
お問い合わせはshield.ioはねむいさんまで!!
taobao経由で購入したシリアルの他にRGB,MCUバスも選択できてQVGAな液晶。
しかし前途のとおりコントローラICがSUCKと言う罠
同じくtaobao経由で購入した、シリアルの他にRGB,MCUバスも選択できて
QVGAな液晶。これはコントローラICが馴染みのILI9325なのでさっきのと違って
暴走とかしないで安定して動きます♥♥
…と思ったらdeviceIDを調べるとILI9325フルコンパチのILI9328であることが
分かりました…。まぁこの程度のチャイナリスクは想定済みです。
最近ebayを試用したときにego-chinaさんから購入したSPI接続専用タイプの
TFT液晶モジュールJD-T18003-T01。コントローラは皆さんおなじみのST7735です。
高速性は必要なくてちょっとした表示に使いたいなんて時に重宝します♥
そして小動物の足。
20110519追:
JD-T18003-T01には型番・外見はまったく同じですが、中のコントローラICが
異なる品種(ST7735R)があります。
ST7735RのものはST7735と初期化手順が異なるのでST7735のコードでは一切
動きません！ご注意ください！
しかもご丁寧にRDIDxで読み出すデバイスIDまで一緒なので私のいつものの
ディスプレイドライバのソースはST7735とST7735Rは分けてあります。
敢えてそうしてあります。
↑購入したばかりの状態だと保護シールのはがしタブの色の違いで
見分けがつきます…
さて、これらのマイコンから簡単に扱える液晶/OLEDモジュールは少し前までは国内
向けのリユース液晶をボｯタ価格で購入せざるを得なかったのですが、現在は大陸系の
電子部品屋であるaitendoさんがいわゆる中華TFT液晶モジュールを販売していて、
日本国内でも使いやすく安価な液晶を手に入れることができるようになりました。
通常の電子工作に使用するならば入手性・価格性・資料性・ユーザともにaitendoさん
で扱っている商品で十分なのですが、もっとマニアックなのを使いたいとかあやしい
液晶モジュールををあえて動かしたいとかいう奇特な人にはtaobaoで購入することを
お勧めします。こっからが今日の本題です！
●taobaoで売っている商品を買う
先ずtaobaoのメインサイトで欲しい商品を検索して探します。検索のときには当然
ひらがなカタカナはNGです。TFT液晶モジュールを探すなら"液晶屏"とかのキーワー
ドを絡めてみましょう。
めぼしいものを幾つか見つけたら買いたいものをいったんリストアップしましょう。
国を跨ぐので中国国内送料に加えて国際送料がかかります。小種類・少数だと効率
が悪いのでよく考えて買う物を決めましょう。
買いたいものが決まったら日本国内で購入代行をしてくれる業者さんに依頼します。
日本国内から業者挟まないで直接購入するのは日本住みでなおかつ故郷にも生きた
銀行口座を持ってる中国人くらいしか無理だと思います。
購入代行業者さんも業務形態・料金の計算方法などはさまざまですので説明をよく読
んだり質問した上で自分が購入する予定の物・値段・量・そして店舗数を考慮して
最適なところを選びましょう。料金の支払いは、落札作業前と日本に発送される前の
2回にわけて請求されることがほとんどです。
業者さんを選んだら購入依頼のやり取りを行いますが出来るだけ詳細を伝えるように
してください。こちらでは周知のことでも担当の人は基本的に部品知識は無いので
意図が伝わらないことが有ります。これこれこういう理由でこうしてくれ・こう伝え
てくれとお願いしましょう。また、購入は現地の落札担当の人が相手先店舗の人とや
りとりを行うことがほとんどです。その際に不明な点がある時は質問が返ってくると
きがあるので丁寧に分かりやすく返答しましょう。また価格が半導体部品で1元とか
異様に安い値段設定されているものもありますが、これはたいてい万個単位で購入し
た場合の価格のことで、**個なら一つ**元だがそれでもいいか？と返事がきます。
逆に他の店舗と比べて2/3くらいの微妙に安い値段で取り扱ってるのはリマーク品や
フェイク品がまぎれている可能性があるためよく吟味してください。
それと超重要な事柄ですが相手先店舗が製品紹介文に"資料は配布する"と明記され
てある時は落札時に必ずもらうようにお願いしましょう。言わないとブツだけが
来て解析に大幅に時間がかかります。もらえるものは全部もらってください！
20110404追：
taobao代行王さんで購入代行依頼した際に上記のお願いしても無視されます。
自力解析出来るor過去に動かした経験がある物じゃないとお勧めできません
しかしこれだけよく考えてやりとりしてもお国柄とんちんかんになりがちですが…
…っというわけで落札が終わりお目当ての商品が届きます…物や地域にもよりますが
2010.12現在だと購入代行依頼してから早くて3週間弱で手元につきます。
いていEMSで届けられます。
●実際に解析して動かしてみる
↑2.2寸の液晶モジュール。
落札時にデータシートを送ってくれと何度も頼みましたが対応してくれませんでしたorz
こういうことは非常によくあります。仕方なく自分で解析を行います。
解析の流れは以下の手順で進めます。
ピン配置の推定
↓
コントローラICの推定
↓
初期化手順の決定
↓
基本動作確認
TFT液晶モジュールを数種類以上触られてる人はご存知かと思いますが、FPCの
ピン配置はメーカーが違えどほぼ同様の"定番"なパタンのものがあります。
たとえばEGO028Q02とWBX280V009はピン配置が全く同じでキャリーボードが
使い回しできたりします(YHY024006Aもピッチは違いますがピン配置は同じです)。
そのことから同じピクセルサイズ&インチ数の液晶モジュールの中でデータシートが
手に入るものを調べ、記載されているピン配置から詳細不明のモジュールの
ピン配置を推定することができます。
幸いにもこのモジュールは一目しただけでわかるレベルでパタンが別れていて
容易にピン配置を推定することができました。
次に、液晶のコントローラICの推定を行います。ピン配置の推定した時と
同じように似たサイズモジュールのデータシートより候補とするコントローラICの
型番を控えます。
2.2寸のものは176x220ピクセルの品種が多いようですね。176x220ピクセル対応の
品種をあらかじめ絞り込んでおきましょう。これをもとにコントローラ内の
レジスタの値を読み出し、コントローラICの決定を行います。大抵は00h番地の
レジスタにコントローラ固有の"device code"をもっています。
ILITEK系列のものはほとんどこれでコントローラの種類を判別できます。電源電圧は
LED用電源を除いて3.3Vでほぼ事足りますが、一般的にはLCDモジュールでは標準的な
2.85Vが作れたらそれに越したことは無いです。
しかしこの液晶モジュールは読みだしても0x00が帰って来るだけでした。違う番地の
レジスタに値を放り込んで読むと放り込んだ値が正しく返ってくることから読み書き
はきちんとできていることが分かります(これができていない時はピン配置の推定まで
戻って調査しなおしです)。
私は上の結果から、176x220ピクセル対応で特定のレジスタ番地にdevice codeが無い
品種のものとして"HX8340B"がこの液晶モジュールに使用されていると推定しました。
ここまで絞りこめたら後はネットでこの型番を検索して初期化手順を調べます。
たいてい中華サイトから見つかるでしょう。なんせ中華液晶モジュールですから…。
ところでコントローラICのレジスタの値を読み出すとか言ってるけど具体的にどうすれば
いいの？という話になりますが、私の場合は動作実績があるILI9325系列のプログラム
を使用し読み出しを行っています。これはChan氏が公開しているOLEDテスト用の
プログラムをベースに各液晶モジュールにも対応できるように構造化させたものです。
またchan氏のFatFsのテストプログラムも兼ねています。
おきぱへ
上のおきぱにあるコードで実践していますが、"汎用で使える抽象的なレベル"と"
デバイス固有のレベル"なコードとを分ける、プログラムのライブラリ化/モジュール化
をしておくようにすると、未知の液晶/OLEDモジュールを調査する時やトラブル
シューティング時の問題の切り分けにも役に立つかと思いますので、コードサイズや
速度を気にしない方に強くお勧めします。
話は脱線しましたが、HX8340Bの初期化手順を作り、確認用プログラムを走らせます。
おっし！
こんな感じで上手くいけたら目的達成です。画面が真っ白でうんともすんとも言わない
場合はピン配置やコントローラICの推定まで戻って解析を進めましょう。
この液晶、大きすぎず小さすぎずで手軽に扱える掘り出し物を引き当てたみたいで、
ねむいさん的にはとても気に入ってます♥
次構想してる基板に載せちゃおうかな見たいな
20110824追：
その後の調査で宇顺电子のS95329というS95215Aを改変したモジュールである
ことが確定しました。
20111110追：
さらにその後改訂版のデータシートを手に入れ"Read HIMAX Device ID"
コマンド(0x93)でDeviceIDを読み出すことに成功しました。
データシートや資料が手に入ればここまで苦労することは無いのですが、何せ相手は
大陸なので資料が手に入ったとしてもまだ安心はできません。ふつーに全く違うデバ
イスの資料付けてきたり素で勘違いしてたりなんて日常茶飯事で私が経験してるもの
だとコントローラICがILI9320ものを指定して購入したつもりが実際に動かしてみると
"ハズレ"のLGDP4531で、資料として送ってくれた"ILI9320"の初期化ルーチンとやらも
見比べるとLGDP4531のものだったとかあってもう勘弁してくだち…
もしLGDP4531のものを引いてしまったら奇声上げながら窓から投げ捨てる以外にない
とおもいますね…(←本気でやっちゃだめよ！)
というわけでオチが無い話をつらつらと書き殴ってしまいましたが、そこまでしてチ
ャイナリスク負いたくない人は中華液晶モジュールばっかいじってる奇特な人と仲良く
なって動作が保証されてるのを譲ってもらうのがいちばんだとおもいまし た！
それといつまでも液晶デバイスばっかいじってても進歩がないので次はまぢで新しい
別の試みに手を出していこうと思います。
ちなみにおきぱで今もメンテを行っているSTM32F4向けTFT液晶モジュール表示
サンプルは以下のコントローラICに対応しています。いろんなサイト巡って集めて
きて、すべて動作確認を取っています。
当エントリは何気に当ぶろぐの一番人気のメインコンテンツの一角となってます！
20161028追:
現在、液晶ブームはひと段落したのか今度はESP-WROOM-02関連の記事が仏契です。
次点はブラウザベンチマークとか日本の自然歩道です。
20230801追:
ESP32やRaspi関連の絡みで液晶関連で参照数と問い合わせが
増えてきました…このエントリもだいぶ追い上げてます…！
↓以下、動作確認済みのTFT-LCDコントローラICです↓
*ILITEK
ILI9160
ILI9163B
ILI9163C
ILI9132
ILI9220
ILI9222
ILI9225
ILI9225B
ILI9225C
ILI9225G
ILI9320
ILI9325
ILI9325C
ILI9326
ILI9327
ILI9328
ILI9331
ILI9335
ILI9338B
ILI9340
ILI9341
ILI9341V
ILI9342
ILI9481
ILI9486L
ILI9488
ILI9806H(HALF-RAMモデルのためMCUバスには向かない)
ILI9806G
*Renesas
BD663474
HD66772
HD66773
R61514S
R61503U
R61505
R61505U
R61505V
R61505W
R61509
R61509V
R61526
R61580
R61581
R61581B0
R61408
*Himax(奇景光電)
HX8309A
HX8310A
HX8312A
HX8340A
HX8340B(T)
HX8340B(N)
HX8345A(T)
HX8346A
HX8347A
HX8347D
HX8347G
HX8352A
HX8352B
HX8352C
HX8353C
HX8353D
HX8357A
HX8357B
HX8357C
HX8357D
HX8369A
HX8369A-00
HX8369A-01
*NEC
uPD161704A
*Solomon Systech (International) Limited
SSD1332(OLED)
SSD1339(OLED)
SSD1351(OLED)
SSD1283A
SSD1286A
SSD1289
SSD1297
SSD1298
SSD2119
SSD1963(外付けタイプ)
*EPSON
S1D19122
S1D19105
*Sitronix
ST7735
ST7735R
ST7732
ST7781
ST7785(ST7787とまったく同じコードで動く/バスアクセスはかなり遅くすべし)
ST7787(バスアクセスはかなり遅くすべし)
ST7789V2
*MagnaChip
MC2PA8201(Nokia6300 & NokiaE51)
D51E5TA7601(HALF-RAMモデルのためMCUバスには向かない!)
*LG
LGDP4511
LGDP4531(←VCCｦ2.8V以下にしないと不安定になります！！！)
LGDP4535
LGDP4522
LGDP4524
LG4538(LGDP4538の誤字ではない)
LGDP4525
LGDP4551
*Samsung
S6E63D6(OLED)
S6B33B6(CSTN)
S6D0117
S6D0128
S6D0129
S6D0144
S6D0151
S6D0154
S6D0164X1
S6D1121
S6D05A1
S6D02A1
S6D04D1
*Raydium(瑞鼎科技股份有限公司)
RM68050(ILI9325と全く同じ)
RM68070(ILI9335と全く同じ)
RM68042
RM68090
RM68110
RM68120
RM68130
RM68180
*Orise Tech(旭曜科技)
SPFD5420A
SPFD54124B
SPFD54126B
SPFD5408A
SPFD5408B
OTM3225(ILI9325とまったく同じ)
OTM8009A(STM32F769I-discoveryでDSIにも対応)
OTM8012A(HALF-RAMモデルのためMCUバスには向かない!)
OTM4001A(R61509Vと全く同じ)
*統宝光電
C1L5-06
C1E2-04
*Novatek Microelectronics(聯詠科技股份有限公司)
NT3915
NT39106
NT39116B
NT35510
NT35516
NT35702
NT35582
*Tomato LSI Inc
TL1793
TL1771
*その他
SEPS525(OLED)
REL225L01
FT1505C
おまけ
駄目押しチャイナリスク
↑ﾜｰｨ USB3.0のExpressCardだ〜！
↑ｳﾎﾞｧｰ!
SWD専用Versaloonクックブック
20120210追:
OpenOCDが0.6.0の2月以降のコミットでSTlink&STLink/v2の素のハードウエアに
対応しました!!もはやVersaloon化すら必要ありません！！
20110829追:
Versaloon本家の対応により、STM8S/STM32Discoveryに組み込まれたSTLink
のハードウエアにもめでたく対応となりました！！以下に長々と書いているかなり
無理やりなハードウエアの改造は、現在行わなくても済むようになっています！
それでもねむいさん(の方法)がだいすきなんだーい！って言う人だけ読んでください！
デバッガを備えた扱いやすい32ビットのプロトタイプボードたちが群雄割拠する現在、
彗星のごとく電子工作シーンに現れそのまま大気圏に突入して消滅した
STM8S-Discoveryには32bitMCUを使用した2線式デバッガハードウエアSTLinkが
搭載されています。
このSTLinkの本体はSTM32F103C8T6というSTM32のARMマイコンで、これは
Versaloonというリソースが公開された汎用のデバッガハードウエアにも使用されて
いるものです。
今回は、そのままでは糞の役にも立たないSTM8S-DiscoveryのSTLink部分に
物理的改造を施し、SWD接続専用の簡易Versaloonとして再生する手順を
紹介します。
注：制限事項
・この改造はVersaloon-miniのハードウエア互換にする改造です。
・VersaloonはARMの他に多数のマイコンをサポートしているが
この改造はARMの、それもCortex-Mx専用になります！
・てわけでSWD接続以外の接続はできない(ていうかできねぇ！)
・頑張ってTDIとかTDOとか引き出せばJTAG接続も使えるけど
すごいめどいからやらないよ！
・3.3V以外の信号レベルでは接続できない(一応5Vトレラント)
・作業工程はWindowsXP以降の環境を使用。Windows7x64環境でも動作します！
・真似して改造して基板がゴミになっても泣かない
・ていうかJTAGKey/JTAGKey2Cloneをすでに持ってる方の補助的な位置づけです。
・ハードの改造がめどいですという方はiruka氏のオレオレblaster化をお勧めします。
・SWD専用ですが、本家の対応でめでたくSTM8S/STM32DiscoveryのSTLink
のハードウエアにも対応となりました！！↓に長々と書いているハードの改造を
無理にしなくても済むようになっています！大事なことなので2度言います！
●必要なもの
1.STM8S-Discovery
これが無いと話になりませんね。750円でSTM32単体買うより安いです。
必要部品はすでに乗っていて一から回路起こすより断然楽です！
2.12MHzのクリスタル
Versaloonの標準的なハードウエアは12MHzの外部クロックが必要です。
STM32の103系って標準が8MHzなはずだが…
ソフトが苦手なねむいさんとしてはハードウエアの方をカチ合わせる方
針で改造を進めます！いちいち修正してビルドするのめんどいし！
3.チップ抵抗
1608~2012メトリックの100ohmを2つ・10kohmを3つ。これはポート保護&
フローティング時の信号レベル固定用です。
4.1列ピンヘッダ
SWDやUARTの信号を外部に引き出す用途に使用します。
5.0.26mm位のUEW・AWG26位のジャンパ線
UEWは48PinTQFPから足を引き出したりジャンパしたりに使用します。
ジャンパ線は3.3Vの電源ラインをバイパスするのに使用します。
6.USB-シリアル変換若しくはパソコンとUARTで通信できる何らかの装備
改造工程でUARTによるブートローダを立ち上げてDFUを書き込む必要があります。
もちろん信号レベルはTTLレベルに各自で合わせておいてください。
(JTAGでも書き換えられますがここでは触れません)
また、DFUを書き込むためにPC側のプログラムはFlashLoaderDemonstratorを使用
しますので各自インストールしておいてください。
DFUを書き込んだ後はDfuSeを使いVersaloon本体を書き込みます。同じくインス
トールしておいてください。
7.2.54mmピッチのショートピン
パソコンでも使用する標準的なショートピンを。STM8S基板にひっついている奴を
流用しましょう。
8.TQFP(0.5mmピッチ)の足を上げたりはんだつけしたりが余裕で出来る技能
まぁこのブログを普段から見られている方はデフォで出来るでしょうからからあ
えて言わずもがなですね…(カメラ目線)
●改造手順
※一気に改造するとなにが悪かったのか切り分けできなくなるので
逐次動作確認を行い、改造していきます。
1.先ずSTM8S-Discoveryのミシン目をカットしSTLinkと燃えないゴミにわけます。
2.次にUART用のPinをUEW線にハンダ付けで繋げ、外部に引き出します。
3."2."で引き出したUARTのピンはピンヘッダを使って外部に出しましょう。
UART-TX(TxD)は10kohmで必ずプルアップしてください。
4.丸内の部分をジャンパします。ここから+3.3Vを外部に出したいなんて人は
AWG24位の太い線でジャンパしましょう
5.次に丸内のBOOT0のPinに当たる部分を丸内の+3.3Vラインに
ジャンパで飛ばします。
6.USBシリアル変換と"3."で付けたピンをTxDとRxDに注意して接続します。
そしてSTLink側のUSBコネクタをPCに挿しこみます。
USBデバイスが認識されないエラーがでますが無視で。
7.FlashLoaderDemonstratorを起動します。STM32のUARTブートローダーが正しく
起動していればこの画面が見えるはずです。操作法などの細かい説明はこちら
にうっちゃりますが、先ずここでDFUのプログラムを書き込みます。
(Versaloon_DFU_Bootloader.zip)
STLinkのファームウエアははこの時点で消去されてしまいます。
8.元STLinkをPCから外し、"5."で行ったジャンパはもう必要ないので外します。
てか外さないと何やってもSTM32のUARTブートローダーが立ちあがっています。
9.次に書きこんだDFUの起動確認を行います。クリスタルを8MHzのものから12MHzの
ものに差し替えます。丸内の箇所にショートピンを挿し替えます。
10.再び元STLinkとPCをUSBケーブルで接続します。USBデバイスとしてDFUが認識
されたらOKです。まだVersaloon本体は書きません！
11.DFUが起動するのを確認したら一旦PCから抜きます。Versaloon本体を書く前に、
SWDを外部に引き出すための改造をします。四角内の部分の足を丁寧に上げます。
12.足を持ち上げたらまとめてUEW線をハンダ付けして引き出します。
13.ターゲットにSWD接続を行うためのピンを引き出します。JTAG用のポートが
余っているのでこれを利用しましょう。
VersaloonはPB6,PB7をSWDIO用,PB13をSWCLK用のポートとして
使用します。図中の表記はこれに倣っていますので間違えないように
してください。
14.SWDに使うポートを引き出す改造が終わったら"10.の操作を再び行いDFUを
認識させます。そして"DfuSe Demonstrationを立ち上げ、
Versaloon本体のDFUファイルを書き込みます。
15.書き終わったらUSBケーブルを外し、"14."で行ったショートピンを
丸内の位置にします。以後Versaloonのプログラム本体の書き換えは
DFU経由で行います。
16.再度元STLinkとPCをUSBケーブルで接続します。USBデバイスとして、今度は
Versaloonが認識されたらOKです。LibUSBのドライバを読み込ませてください。
非常に操作が簡単なzadigを使ってLibUSBのドライバをインストールしてください。
17.vsprog等を使用しSWDで繋がるCortex-Mx系のマイコン
(LPC1xxx,STM32,ATSAM3x,etc)でVersaloonが使用できるか確認します。
結線さえあっていればこの時点でSWD接続で操作できます。
JTAGのTMS = SWDのSWDIO
JTAGのTCK = SWDのSWCLK
Simonquian氏のページで配布しているvsprog/vsgui等のソースをビルドして
利用するかSWDのパッチを当てたOpenOCDをビルドし使用しましょう。
おや…これは…
…というわけで余り物の材料かき集めたら1000円以内でCortex-Mx系の
ライタ/デバッガが手に入ってしまいます。STM8S-Discoveryを買って
しまった人は玉砕覚悟でVersaloonへの改造を試してみてはいかがでしょうか？
20230819追：
上記で紹介したDFUファイルやVersaloonプロジェクトは公開終了しました。
もし今の世でVersaloon作ってみたいなんて方はねむいさんに連絡ください。
LPC1343はぢめました(+Versaloonを使ってSWD接続でOpenOCDデバッグ)
8/16日にARMマイコン パーフェクト学習基板なるものが販売されました。
基板に搭載されているマイコンはLPCXPresso(LPC1343版)とおなじLPC1343です。
奇しくもLPC1114・LPC1769の開発環境のとっ掛りが出来たので死蔵していた
LPC1343もはぢめて見よう か な とおもって手を出してみました。
決して便乗ではありませんよぅ！
肝心かなめのスタートアップはLPC13xx系がCortex-M3なのを利用してSTM32で
使用したものとほぼ同一のものとしました。NxP系ARMマイコンに存在している
CRP&CheckSumValidationももちろんスタートアップに盛り込みます。
また、LPC1343にはUSBインターフェースがあるのでXPresso基板にUSBminiBコネクタ
から+5Vを引けるようにし、とある1.5A/3.3Vレギュレータでシステム全体に3.3Vを
給電するようにしました。SMDだしセラコン使えるし秋月で買うとかなり安値で買えるし
性能高いしで良いLDOだと思います。
え？秋月のはセラコン対応じゃないのになんで無視して使ってるのですって！？
…さぁ？…誰かがなにかを間違えてるんじゃないかなぁ…？ほら型番とか…
↑ねむいさんは画像掲示板の住人なので画像で語る
それはさておき基板単体で給電できるようになったので、次はフラッシュの書き込み&
デバッグに挑戦です。使用するのはSWD接続なVersaloonです。LPC-Link?何スかそれ？
LPC1114ではまだeraseしかできずあまり期待してませんでしたが、LPC17xx系と
同じようにOpenOCDからSWD接続でフラッシュ書き込みを行うことができました…
これは…ありがたい…！
あとはLPC11xx系のフラッシュ書き込みに対応してくれたら…！
20120229追:
JTAGが無いって言われた時にぃ、じゃぁLPC1114でもSWD接続のOpenOCDつかって
フラッシュ書き込み&デバッグできるじゃない！って確かそういった気もするんですよね
先ずはいつものLED点滅からです。邪魔なうんちゃらLinkはもちろんぶった切ってます。
SWD接続なVersaloonでOpenOCD+Insightによるデバッグ中の画面です。
ペリフェラルはLPC1114の時と同じくaudin氏のOpenOCD用IOViewをLPC1343向けに
移植しました。もうLPCXPressoIDEなぞ要りません。
というわけでLPC13xx系の開発環境の足場作りも整いました。これをとっかかりにして
色々広げていきたいと思います。
ところで、LPC11xx,LPC13xxはフラッシュ容量が32kBしかないので外部に何か容量の超
でかいROMをぶら下げる必要があります。記録媒体としてターゲットにしているのは、
少し前になひたふ氏が触れられていたSSTの大容量SPI-ROM
(手持ちはSST25VF016B)です。
これは現在一般PC用のBIOSROMとして超大量に流通し、使用されているのでmouserや
digikeyでも安価に購入できるようになっています。
こいつに自在にデータを書き込めるようになったらPCのBIOSアップデートに失敗しても
もうなにも怖くはありません！！(←実はこれが主目的)
兎にも角にもSPI-ROMを使いこなすのだッ！
↑接写できるコンデジに買い替えたのでむやみに接写
…駄目だ上手く撮れない
追：おきぱを改修しました。
それに伴いSTM32,LPC2388用のTFT表示プログラムも最新に更新しました。
LPC1769を使う2
※連日の猛暑で頭がたいぶ湧いてます。この段落は読み飛ばしてくだち
8月2日はぱんつの日でしたね…♥
訓練されたとしあき君や｢｣ならモザイク掛けても緑と黒と肌色の配色でいなちゃんだっｔ
ぇっとこれは3.2インチの240x400液晶モジュール(aitendoさんのとは別の品)
なんですが…
taobao経由で買ったこれは御多分にもれずユーズド品でいきなりLEDが
ブッ壊れてたりタッチパネルの内部配線が断線してたりで3つ購入したたうち1つしか
まともに動かんorz
さて戯言はここら辺にして、前回少し触ったLPC1769のボードの続きをやってみた
いと思います。今回は100MHz動作から120MHz動作に変更して動きを確かめてみます。
動作周波数(=CCLK)の変更はLPC2388の時と同じくPLLレジスタをいじって目的の
倍数に設定してやればよいです。LPC1768のCMSISライブラリのPLL周辺の初期化
コードが値決め打ちで書いてあって分かりずらいこっちゃないってことで少し
てこずりましたがユーザ・マニュアル片手に120MHz化できました。
LPC1769はUSBのクロック生成専用にもう一つPLLがあって、なおかつメインの
PLLからも従来通りUSBクロックが設定可能という柔軟な対応ができるように
なってました。
てわけで120MHz動作にしたLPC1769でGPIOの単純なトグリングしてみました。
ﾔﾀﾞ超早い…♥
100MHz動作のLPC1768(mbed等)を想定した場合はこんな感じ。
波形汚いのはご容赦を。
以下はCodeSourcery G++(GCC4.4.1)のOptimize-2でコンパイルして吐かれた
アセンブラリストの一部抜粋です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
LPC_GPIO1->FIOSET = (1<<28);
3dc: f2c2 0309 movt r3, #8201 ; 0x2009
3e0: f04f 5280 mov.w r2, #268435456 ; 0x10000000
(↑最初に必ず入る)
3e4: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3e6: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3e8: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3ea: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3ec: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3ee: 61da str r2, [r3, #28]
LPC_GPIO1->FIOSET = (1<<28);
3f0: 619a str r2, [r3, #24]
LPC_GPIO1->FIOCLR = (1<<28);
3f2: 61da str r2, [r3, #28]
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
Cortex-M3はフラッシュアクセスがゼロ・ウエイトの場合かつロード・ストア命令が
連続する場合、Rx,[Ry,#imm] は、常に1サイクルになるので(Cortex-M3マニュアル
参照)、ゼロ・ウエイトで動作が可能でなおかつGPIOがAHBバスにぶら下がっている
LPC1769はGPIOのトグリング周波数がMAX60MHzまで出るということですね。
ちなみにLPC2388の場合は同条件でARMモードでコンパイルした場合、以下のように
展開されました。もちろんLPC2388のFIOのアクセスです。
"DISPLAY_CONTROL_CLR = CTRL_WR;"の部分は
FIO4CLR1 = (1<<1);
FIO4SET1 = (1<<1);
に読み替えてください。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
DISPLAY_CONTROL_CLR = CTRL_WR;
61c0: e3e03103 mvn r3, #-1073741824 ; 0xc0000000
61c4: e2433c3f sub r3, r3, #16128 ; 0x3f00
61c8: e3a02002 mov r2, #2
61cc: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61d0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61d4: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61d8: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61dc: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61e0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61e4: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61e8: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61ec: e5432062 strb r2, [r3, #-98] ; 0x62
DISPLAY_CONTROL_SET = CTRL_WR;
61f0: e5432066 strb r2, [r3, #-102] ; 0x66
DISPLAY_CONTROL_CLR = CTRL_WR;
61f4: e5432062 strb r2, [r3, #-98] ; 0x62
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
ARM7TDMI-Sの場合はstrが最小2クロックサイクルなので、ゼロ・ウエイトで動作が
可能でなおかつGPIOがAHBバスにぶら下がっているLPC2388ではトグリング周波数が
最大18MHzになります(CCLK=72MHzの時)。
↑実際の波形です。波形汚いのは(ry
んでもってSTM32F103BVT6の場合はこんな感じ
"DISPLAY_CONTROL_CLR = CTRL_WR;"の部分は
GPIOD->BRR = GPIO_Pin_12;
GPIOD->BSRR = GPIO_Pin_12;
に読み替えてください。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
DISPLAY_CONTROL_CLR = CTRL_WR;
800459a: f44f 5380 mov.w r3, #4096 ; 0x1000
800459e: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a0: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045a2: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a4: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045a6: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045a8: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045aa: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045ac: 6123 str r3, [r4, #16]
DISPLAY_CONTROL_CLR = CTRL_WR;
80045ae: 6163 str r3, [r4, #20]
DISPLAY_CONTROL_SET = CTRL_WR;
80045b0: 6123 str r3, [r4, #16]
・
・
・
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
STM32F1xx系は72MHz動作だとフラッシュアクセスに2ウエイト掛かるのでトグリング
周波数は18MHzになります。LPC2388と同じ早さです。
STM32F1xx系は72MHz動作ではフラッシュのプリフェッチバッファが効いて分岐なしで
動かした場合はノーウエイトと等価になりGPIOもMAX36MHzでトグリングできるはず
ですが･･･。
STM32ではAHB->APB2(GPIOがぶら下がってるバス)にかかるSTR命令は最短2クロック
サイクル(※)となるため、MAX18MHzで頭打ちとなります。同じ理由で内蔵高速RAM
から実行してもMAX18MHzになります。
※:AMBAの仕様書(IHI0011A_AMBA_SPEC.pdf)参照
↑期待値通りですね。波形汚いのは(ry
GPIO上げ下げだけじゃナンなのでaitendoさんで急に人気沸騰(?)のOLEDを使用して
LPC1769内蔵フラッシュに書き込んだ画像と文字表示を。LPC1769固有のSPI
モジュールの詳細はまだ調べてないので制御はソフトSPIです。
ノーウエイトの超高速のGPIOでブンまわしてもOLEDは付いてきました！
さて、これからLPC1769使って何をするかですが、I2Sのデバイスも数種類手に
入れているのでI2Sの学習しながらベタですがMP3プレイヤーを作るという方向性で
考えています。
JTAGKey2Cloneをもっと使ってみる
20150514追:
2015年現在、JTAGKey2CompatibleのRev.5まで
上がっています。自作される場合はこちらを参考にしてください。
20150514追:
よし
やっと日記書く余裕ができた…MTM05に参加された皆様、本当にお疲れ様でした。
日記はぢめてもう1年たったことだし、ねむいさんもていどひくいと言われないような
仕事をしたいものです。本業の虹メの方がスレの途中で寝落ちしまくっててていどひくいどころ
じゃない状態なのは置いといて。てかいつもスレに参加してくれてる人ごめんなさい…。
さて本題、前回はJTAGkey2のクローンを作成し、LPC2388のフラッシュプ
ログラミングでRTCKの威力を確認しましたが、今回もう少し設定をなぶってみました。
CQ-FRK-NXP-ARMの基板は12MHzの外部クロックが乗っているのでOpenOCD接続時に
デフォルトの内部4MHzRC発振からそちらで動くように切り替えると速度が速くなる
わけですが、PLL使って最高速の72MHzまで叩き上げるとさらに速くなるはずです！
(もう十分早いけど)
↓というわけで試して比較してみました。
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=12MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> 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
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000038bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.671892s (47.906 KiB/s)
> verified 118132 bytes in 0.921881s (125.139 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: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05
●Ext12MHz,With AdaptiveClocking(RTCK),CCLK=72MHz
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf"
> Open On-Chip Debugger 0.5.0-dev-00267-gef72484 (2010-05-26-21:28)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> 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
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x000021bc
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> wrote 131072 bytes from file main.elf in 2.609392s (49.054 KiB/s)
> verified 118132 bytes in 0.234377s (492.212 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: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:05
CCLKを72MHzに叩き上げたことによってベリファイ速度が滅茶苦茶速くなってます…
さすがですね〜。RAMへのダウンロードも同じくらい早いでしょう。
一方フラッシュ書き込みそのものはMAX50kb/Secで頭打ちのようです。これはフラッ
シュ消去/書き込み時間が固定でそこがボトルネックとなっているからでしょう。
STM32の方も同様の理由で頭打ちになってMAX20kB/Secが精一杯ぽいです。これももう
少し早くなると思うんだけどなあ…まだいじる必要があるのか…
あと気をつけなければならないのがOpenOCD用スクリプトのフラッシュ書き込み時の
CCLKの設定ですが、こちらも適切な値に設定していないと正しく書きこまれません。
例としては↓こんな感じです。
RTCK対応のLPC2388用OpenOCDコンフィグは既に72MHz動作対応済みです。
そして今日はもう一件JTAGKey2Cloneを使った重要な事柄があります。
先月発売されたInterfaceには付録としてSH2Aの基板が付いていました。これにはH-UDI
とかいうJTAG用の端子が備わっていて同時期にリリースされた某JTAGデバッガを接続
してデバッグができるようになってます。"た"の人曰く最初はIF誌で同JTAGデバッガの
回路図全公開の予定だったらしいのですが大人の事情で非公開となったそうです。
でもFT2232デバイス(FT2232H)を使っているのは自明かつMPSSEでJTAGとして使える
ピンは固定なのでJTAGkey2Cloneのハードウエアが余裕で使えるんじゃないかと
言うことで実験野郎してみました。
…と思ったらすでにされてる方がいました。
てか某掲示板では動かすまでいろいろアドバイス頂きありがとうございます…。
dllをこう使えばディスクリプタ合わせるためのEEPROMの書き換えすら要らんのか…すげ
てわけでJTAGKey2Cloneまんまで動きましたワーィ
これでSPIROM何発ぶっ飛ばしても無駄な出費払わずにいつもの使って復帰できますね♥
JTAGKey2(無印やクローン含む)があればAltera,xilinx,ARM,SHの開発に使いまわせられます！
でもねむいさん国産マイコンは仕事でうんざりするほど使ってるからSH2Aとかこれ以上
触るつもり全く無いんだし！
おまけ
毎年気になる電源ライン
↓立ち上がり
こっちはふつーですね・・・
↓立ち下がり
あーっとこれは…
1.2Vはスパッと0Vまで落ちてますが3.3Vラインが0.6〜0.4V付近で長時間たむろって
ます…
リセットICの電源も+3.3Vから引いてますがこれは誤動作しやすくなるやもしれません。
1.2Vが立ちあがらないUSBが繋がらない云々の件は3.3Vラインの残存チャージが原因の
一つと見てよいですね。
対策は3.3VレギュレータのVoutからVinにチャージを引き抜くようにショットキバリア
かましてやれば良いでしょう。syslab氏もすでに試されていて実際に効果ありの
ようですね。ていうか基板設計するときにもっときっちりオシロで波け…
…まぁいいや…もうARM9のボードで遊ぼう…淘宝网で買った液晶も
たくさん残ってますし
ねむいさん遊んでる暇あるの！？
届いたわぁ･･･ARM9(LPC3250)のボードが…！
今は別の案件で忙しすぎて触ってる暇すらないけどMTM05終わったk頃くらいに
androidとか動かしてみたいなぁと画策してます…。
ちなみにEmbedded Artisitsさんより直接購入しました。日本国内で代理店通して
同スペックのボード買うとどうしても割高になってしまうので…。
20190726追：上のボードは前の職場にすてｔｹﾞﾌﾝｹﾞﾌﾌﾝ寄贈してきました
ついでにこれも購入しました…しかしOpenOCDでLPC1114/1343書き込み/デバッグ
出来るようになるまで上記のLPC3250のボードとともに塩漬け…。
ついでに"た"の人のARMデバッガCortex-M3対応も期待。
上のARM9のボード購入にあたってJTAGKeyCloneの機能アップ版である
JTAGKey2Cloneの制作を行いました。
お手本にしたのは最初にJTAGKeyCloneを作ったときと同じく神木さんの作例です。
20130422追:
JTAGkey2Cloneの回路図改良しました
JTAGKey2は中のチップがFT2232Hになっています。超高速信号を引き回すことに
なるので、FTDIチップ周りは神木さんのものと同じく出来合いのモジュールを
使用しています。
氏の作例と違う部分はレベルシフタICをJTAGKeyCloneで使用したときとおなじもの
を使用し、FT2232H <-> レベルシフタ間を+5V電圧系で駆動させている点です。
FT2232HのVCCIO上限は+3.3Vなので通常なら思いきり制約に違反している
ところですが、FT2232Hとレベルシフタの+5V入出力トレラント性を大いに利用して
レベルシフタの入力(つまりFT2232Hの+3.3Vな出力)を+5Vでプルアップするという力技で電圧変換の問題をクリアして
います!!
20150218追:
↑の出力プルアップ作戦は470ohmでプルアップしてもFT2232Hの出力バッファの
引き込み能力の方が勝ってしまうため全く意味がありません。
結局出力は3.3Vのままで規約違反です。でたらめ書いてましたすみません。
代わりに+5VCMOSレベルとの動作の際の電圧遷移がどうなっているかを
調べましたので参考にしてください。
20150218追:
20150514追:
電圧レベルに関してケリをつけました！！！！！！
20150514追:
また、前回のJTAGKeyCloneを作った時はDAISENの変換基板に頼っていましたが、
今回はメッシュアース基板を利用してレベルシフタを基板に直付け・UEW線で引き
まわして高速な信号も扱えるようにしています。
↑こうしてみると1608サイズのパスコンが相対的におっきく見えるほと小さいですなぁ…
こうして作り上げたJTAGKey2CloneはJTAGKeyCloneと同じ感覚で使用ができます。
OpenOCDで使う場合なら、jtagkey.cfgと指定しているのをjtagkey2.cfgに変える
だけで使えます。JTAGKey2の売りはUSB-HighSpeedで各種シリアル転送がさらに
高速になった上にRTCK(AdaptiveClocking=自動クロック追従)がサポートされて
いる点なわけですが、これはLPC2388のようなRTCK端子が出ているデバイスで
真価を発揮します。
以下に各条件でOpenOCDからLPC2388に100kB程のデータをフラッシュ書き込み/
ベリファイした時の速度の比較を記載しておきます。
(以下無駄に長いので覚悟してください)
●JTAGkeyClone(FT2232D)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> Error: JTAG scan chain interrogation failed: all zeroes
> Error: Check JTAG interface, timings, target power, etc.
> 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
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> Warn : Bad value '00000000' captured during DR or IR scan:
> Warn : check_value: 0x00000009
> Warn : check_mask: 0x00000009
> Error: JTAG error while reading cpsr
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> Error: Target not halted
> Error: failed erasing sectors 0 to 10 (-304)
> Command handler execution failed
> make.exe: *** [program] Error 1
>
> > Process Exit Code: 2
> > Time Taken: 00:04
↑JTAGKeyCloneでは外部クロックだとフラッシュの書き込みが出来ません！
●JTAGkeyClone(FT2232D)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> Info : device: 4 "2232C"
> Info : deviceID: 67358712
> Info : SerialNumber: 11111111A
> Info : Description: Amontec JTAGkey A
> Info : clock speed 500 kHz
> 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
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x000000d3 pc: 0x00000000
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 7.468798s (17.138 kb/s)
> verified 117280 bytes in 2.812518s (40.722 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:14
↑JtagKeyCloneでは内部4MHz RC(電源投入時のデフォルト状態)でフラッシュ
書き込みするのが無難なようです。
●JTAGkey2Clone(FT2232H)/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> 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: 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
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002028
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 6.750044s (18.963 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:13
↑JTAGKey2Clone(FT2232D)の時と比べて少し早くなってますね。
●JTAGkey2Clone(FT2232H)/LPC2388_Ext12MHz X'tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 200
> jtag_ntrst_delay: 200
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> 500 kHz
> fast memory access is enabled
> dcc downloads are enabled
> 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: 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
> 100 kHz
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Info : JTAG tap: lpc2388.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4)
> Warn : srst pulls trst - can not reset into halted mode. Issuing halt after reset.
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> 500 kHz
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.843788s (21.904 kb/s)
> verified 117280 bytes in 1.015632s (112.768 kb/s)
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:10
↑JTAGKeyClone(FT2232D)では不可能だった外部12MHzのクロックでの
書き込み/ベリファイが出来てます。スピードも速くなってます。
●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_Int4MHz RC
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> 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
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x00002040
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 5.859412s (21.845 kb/s)
> verified 117280 bytes in 2.640642s (43.373 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:09
↑書き込みは少し早くなっていますが、RCLK有効でもベリファイ速度はCCLKの関係で
頭打ちになってますね。
●JTAGkey2Clone(FT2232H) with RCLK/LPC2388_EXt12MHz X'Tal
> > "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
> openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey2.cfg -f C:/Devz/ARM/OCD/tcl/target/lpc2388_rclk_flash.cfg -c "mt_flash main.elf" -c "continue" -c "resume" -c "shutdown"
> Open On-Chip Debugger 0.5.0-dev-00145-g2a17fd9 (2010-04-08-13:41)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.berlios.de/doc/doxygen/bugs.html
> adapter_nsrst_delay: 100
> jtag_ntrst_delay: 100
> trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
> RCLK - adaptive
> fast memory access is enabled
> dcc downloads are enabled
> 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
> target state: halted
> target halted in ARM state due to debug-request, current mode: User
> cpsr: 0x60000050 pc: 0x0000373c
> flash 'lpc2000' found at 0x00000000
> auto erase enabled
> Info : Padding image section 0 with 0 bytes
> wrote 131072 bytes from file main.elf in 2.765643s (46.282 kb/s)
> verified 117280 bytes in 0.921881s (124.236 kb/s)
> requesting target halt and executing a soft reset
> target state: halted
> target halted in ARM state due to breakpoint, current mode: Supervisor
> cpsr: 0x600000d3 pc: 0x00000000
> shutdown command invoked
>
> > Process Exit Code: 0
> > Time Taken: 00:04
↑ううん早い
JTAGkey2Clone+RTCKの組み合わせではJTAGKeyCloneと比べるとフラッシュ書き込み
ベリファイとも約2.7倍ほど早くなってます。LPC2388はROM容量が大きいので早いに
越したこたぁ無いですね♥これでLPC3250を迎え入れる体制ができました！
…あ、わかってます、遊ぶのはやる事やってからです…！！
ついでにLPC23xx系のマイコン使うときのTipsですが、このマイコンは電源を起動する
とフラッシュに書かれたプログラムとは関係なく先ず内蔵のブートローダーが立ち上が
ります。大まかな流れとしては以下のようにしてブートシーケンスを行うようです。
P2.10ピンの状態を読みに行く,P2.10=Lowの時
->ISP起動
P2.10=Lowではない時
->0x14にかかれたチェックサムが有効かどうか確認
チェックサム有効
->ユーザープログラム起動
チェックサム無効
->ISP起動
(本来これにCRP他も絡みますが詳細はUserManualのp606以降を参照してください)
したがってフラッシュロムに何も書かれていないとP2.10LowでなくてもISPが
起動します。このときにJTAGから書こうとするとISPのアドレスに飛ばされて
しまってうまくいかない時があります。がた老氏も同じ問題に遭遇されていましたが私も
JTAGKey2Clone使った時に初めて気づきました(JTAGKeyCloneでは出なかった)。
この問題はinit後即soft_reset_halt->フラッシュ書き込みで回避できました(OpenOCD-0.5.0)。
確証が完全にとれたらcfgファイル更新しときますね。更新しましま。
んでもって現在のOpenOCDのLPC2xxx系のフラッシュ書き込みはチェックサムを計算
して0x14番書き込んでくれる機能がありますがこれやってしまうとベリファイで引っか
かってしまいます(難儀だ)。
どうしてもベリファイしたかったらフラッシュメモリの0x14番地に割り込みベクタの
チェックサムを前もって計算してスタートアップに書き込んどくとOpenOCDからも
ベリファイすることができます
(割り込みベクタなんてほぼ固定ですしこれでも良いと思います)。
もちろんこれやる時はcfgファイル中の"calc_chacksum"は消しておくように！
XMEGAを使ってみる3
Versaloon関連で飛んできた人はこちらへ
年度末になると何でか糞忙しくなりますね〜…私はというと企業研修で来ている知り
合いの学生の子(去年11月下旬からSTM32初めてあっという間にマイクロマウスまで
製作ってた!!)に私のブログの内容をしてねむいさんていどひくいと罵られたり、
お客さんの現場で生暖かい目で見つめられながらハーネス打ちかえたり、私より一回
り年下の弟が私より一回り年上の彼女連れてきたりするなかで隙を見てマイコンの
勉強をやってきてます…。
LPC2388やSTM32系のMCUで動かしてきた大きめのTFT液晶、EGO028Q02や
YHY024006AをATXMEGA128A1にも導入すべく準備を進めてきました。
前回、現行のATXMEGA128A1にはPORTLが存在しないため4PORT-EBIが実質上
使用不可能と書きましたが、メモリアドレスを2つ(アドレス線は一本)しか使用しない
上記液晶たちは話が別です。FPGAボードを接続する前の肩慣らしに先ず4PORT-EBI
でTFT液晶を制御する試みを行いました。
ATxmegaのEBIに供給されるクロックはシステムクロックの2倍なので最高64MHzの
クロックスピードで動作させることができます。
高速のSRAMは恩恵を受けられるでしょうが、LCDからしてみると早すぎです。
read時だけウエイトを0->4に落とす等の細工をしています。
長々と書きましたが4PORT-EBIは無事機能して,YHY024006Aに画像やフォントを
表示することができました。
↑まだFatFs積んでないので容量の都合上このサイズの画像しか表示できないです。
ァァ残念だー(棒
あとATXEGAで試してみたい機能はADC,RTC,事象システム,FatFs(SPIをDMAにする)
搭載、それと今回試したEBIを今度は3PORT-EBIモードで大容量SRAMというか
それが乗っかったFPGAボードと接続する。そんな感じでしょうか
また、すｚ氏やいえなが氏も現在進行系でXMEGAを触られているのでお二方の
作品の完成もたのしみですね。
と、いつもならここで力尽きて日記が終わるわけですが…ていどたかい虹裏メイドを
目指すねむいさんもうちょっと頑張ってみます！！次いつ更新できるか分からないし！
私も多分にもれずSTM8S-DiscoveryというSTM32ボードを購入しましたが、以前から
目をつけていたVersaloonという汎用JTAGライタ/デバッガに改造を試みました!!
このVersaloonに使用されているマイコンはSTM32の48pin,ROM62kb,RAM20kB,
ペリフェラルとしてUSBが存在する物のようですね。そしてSTM8S-DiscoveryにSTLink
として乗っかってるSTM32F103C8T6はVersaloonになる条件をすべて満たします。
んでもっておあつらえ向きに書き換え用のJTAGの端子も出ているのでまずはUrJTAGで
様子を見てみました。
↑とりあえずJTAGKeyを繋げる…
↑ふつーのSTM32ですね〜…ちゃんとJTAGで見えます(ﾆﾔ･･
次にOpenOCDからフラッシュのバックアップを取ろうとしましたが…
↑やっぱしダメか…
というわけで一度STM32のフラッシュを書き換えてしまうともう2度とSTM8Sを
Discoverすることが出来なくなってしまうわけです。しかし！ねむいさんは
STM32のボードを購入したつもりなので容赦なく消しましたｵﾗｰ！！
次にVersaloon用の回路(後述のRelease1の回路構成)に作り替えます。必要なものは
12MHzのクリスタルです。STM8SにつながっているSWIMを構成している一部のピンは
VersaloonとDFUの動作を阻害するので必ず足上げしたりジャンパカットしてください。
注：基板の改造は必ず情報の1次ソースで提示されてる回路を参照してご自分で
判断を行ってください！！実験色が非常に強いのでここでは詳しく書きません！！
↑ねむいさんは横着なので基板からSTM32を外さずに無理やり上記の改造をしましたが
真似される奇特な人は基板から外して別に組んだ方がいいですよ?
ちょろっと出てるUEW線は用が済んで外したTDIとTDO。
↑使わなくなったSWIMのピンはDFUモードに入るためのモード
設定ピンに再利用しました。
中途半端に起立しているチップ抵抗がやっつけ感漂う…
VersaloonはDFUによりセルフアップデート出来る構成をとっています。
それに倣って最初はDFUを書き込みます…。
STM32F107系に慣れてしまった身ではとてももどかしいです。
JTAGで書くに越したことないですが、持ってない人は必要なピンだけジャンパ
引き出してシステムメモリからブートして書き込むって方法もあります…。
↑DFUが立ち上がりDFUDemonstratorが立ちあがったところ。
ここまで来たら勝ちです！
現在、Versaloonはいくつか種類があり、製作者のSimonquan氏のページから
ソース、回路図、ホスト側プログラム、OpenOCDへの対応方法などの情報は
すべて提供されています。
今回私はRelease1の回路を構成しRelease1用のファームをビルド、そして
DFU経由でVersaloon本体を書き込みしました。
↑出来上がったVersaloonを別のSTM32ボードと接続して、vsprogにて
JTAGモードとSWDモードそれぞれの方法で認識させたところ。
↑vsprog(gui)で書き込みもできます。STM32だけではなく
AVR/MSP430/PSOC/STM8Sも書き込めるようです。
↑SWDに対応するパッチを当てたOpenOCDを使用してSWDでデバッグ。
今は動作確認の為のやっけつの仮組ですが目的のSWDで使えそうなのがわかったので、
STM32を別の変換基板に移し替えて汎用のJTAGデバッガ/ライタに仕上げるつもりです。
今回の実験に使ったVersaloon用のDFUとVersaloon本体のプログラムをこちらに。非常に
実験色が強いので完全自己責任のご意見無用とさせてもらいます。
仕事納め
何とか時間取れました…なんか忙しくってホントに年末って感じがしませんね…
それはさておきaitendoさんのSPI液晶H161IT01ですが時間を見て少しづつ
いじってきましたが、ようやく使えるようになってきました。
使用の上での分かったことをいくつか…
●この液晶モジュールはSPI接続でしか使えない。
●SPI接続だと書き込み専用でしか使えない。よってシリアルINは要らない。
●バックライトLEDは3つ。一つ当たりの電流値typが15mAなので
全部で45mA流す必要がある。
●3.3V系でも使用可能だがやっぱ単一だとやっぱ暗い。バラつきを考えて定電流
制御ができるDCDCコンバータICを使用するのが良いでしょう。
●45mA流してもまだ暗いんで55mA流すとそこそこかしら。
●ZY-FGD1442701V1と比べると青みがなく自然に近い色です。
●少ピンでのマイコンシステムには最適でしょう。しかし変換基板が…
といったところでしょうか。変な癖も無く、使いやすい液晶だと思います。
んでもってこのSPI液晶を使用した応用編…
↑以前紹介したEtherPodにFreeRTOSを乗っけたときは外部表示機能がなかった
のですが今回SPI液晶を表示機として使用してみました。
文字の表示法もセクスィ部長氏とProjectC3氏
のページから勉強させてもらいました。
フォントはフリーの美咲フォントを使用しています。他のサイズのフォントも
いろいろ試してみようと思います。
↑実は日本語フォントは上手くいかなくでず〜っと詰まってたのですがやっと
一つの壁を超えた感じです。
さぁつぎは避けまくってるUSBデバイスだ！…はまだ無理なので追々と。
と、今年はこんなところで…。仕事の中でマイコンや回路設計を覚えていって
その折にこのブログも始めて、さらに他の方とも共同で作業をするようになって
来ると一人で制作している時は見えてなかった部分がいろいろ見えてきたりもしました。
この業界に身を置く限り、常に新しいことの勉強勉強の連続の日々なわけですが、
これからも気力の続く限りずっと続けていきたいものです。
STM32 Primer2にFreeRTOSを乗せる1
年末に差し掛かって糞ほど忙しくなっています。そんな中でも合間を縫って更新ッ…！
前回はSTM32 Primer2上にRIDEやCiecleOSなぞガン無視のBARE-METALな自分環境で
USBマスストレージクラス対応のミニフォトフレームなんか作ってたわけですが、今度は
すっかりおなじみのFreeRTOSを乗せてちゃんとしたシステムを作ることにします。
こちらもフォトフレームの制作時と学習を兼ねて段階的に進めていくつもりです。
えーと先にもいいましたがSTM32Primer2のコミュニティサイトに既に移植されたのが
ありますがそれはあえて一切視界に入れない方向でやっていきます！！！！
↑後発だから一味違う！！１！
まずは第一歩、以前CQ-STARM向けに一番簡単なのをこさえていたのでこれを2Primer2
(STM32F103VET6)向けに移植を…。プログラムの内容はLEDのタスクだけを動かすとい
ったごくごく単純なものです。しかーし！！コミュニティにあるのと違う点はFreeRTOS
が最新なのと真中のボタン長押しで電源が切れるという革新的ｎ
…や やめて石投げないで
※公開停止しました。ソースコードほしい人はメールください。
このプログラムがこれから先のFreeRTOS+STM32Primer2のたたき台になります。今度
こそ横着しないでRTOSをまともに使いこなしていこうとおもいます。ついでにUSBもち
ゃんと学習していきたいとおもいます。今度は本気出す！
また、↑のと並行してNuttXという別なフリーのRTOSの勉強も初めています。
これはGenie氏が手掛けているEtherPodというSTM32F107が乗ったマイコンモジュール
(まだ試作段階ですが)に標準で搭載され、またそれに合わせた様々な機能が
サポートされる予定になっているのでEtherPodと併せて非常に注目すべき
OSとなるでしょう。
↑…実はすでにFreeRTOS+webserverのデモまで私が動かしててさらにこれのロー
レベルドライバもこしらえてる最中だったりしたり
STM32 Primer2をBARE-METALで使ってみる(終) -フォトフレームを作る-
大きなバグ出しも終わってやっとこ使用に耐えるものが完成です。上位層の作り込みは
Chan氏のFatFsやターミナルプログラムの凡例のおかげで開発期間の大幅な短縮が
できました。そしてCircleOSに頼らないBARE-METALな試みも今回でいったん終了
です。
昨今の電子工作は回路検証はもちろんケーシングも非常に重要なファクターになって
いますが、もとからケースに入っているSTM32Primer2はとてもありがたいですなぁ。
…ってことで、
以下今回製作したフォトフレームの使用例を…
※20091226:電源監視機能を強化しました。
※20091126:USB-MSC(マスストレージクラス)機能を追加しました。
↑4+1入力キーの"真ん中"を押して電源投入。これはハード的に処理されています。
↑電源投入->タイトル表示後はSTM32Primer2に挿入されているSDカードを読み込み、
ファイラを起動します。ファイルシステムはFatFsを使用しFAT12,FAT16,FAT32の
フォーマット・およびロングファイルネームが使用可能です(画面上の表示は
8.3形式ですが）。
↑ファイラ画面の基本操作は↑↓がファイルポインタの移動、→がEnter,←がCancel
に相当します。
↑画像はbmp形式が表示可能で128x160pixelまでの物が使用できます。
それより小さいサイズは、真ん中合わせで表示されます。
画像はひねもすのたり氏画の私(ねむいさん)。
…びいぶろ君が欲情すると困るからピンボケ！
↑…すみません…お口直しに癒し系小動物を。otter-beerは結構有名らしいです。
↑動画はimg形式。img形式のファイルは同梱のChan氏謹製の付属ツールでaviから生成
できます。再生中→キーで一時停止、その後↑↓キーでコマ送り、戻しができます。
上の画像のは虹裏で活動している名無しの絵師さんの動画をお借りしました。
20091126追加
↑USBマスストレージモードに入るためにはUSBケーブルをSTM32Primer2の
"STM32"側のコネクタに挿し、ファイラのルートディレクトリでLeftキーを押します。
LCDの画面が暗転し、PCにディスクドライブがマウントされたら成功です。
20091126追加
↑MSCモードからファイラに戻るためにはLeftキーをもう一度押します。
ディスクドライブがアンマウントされ、ファイラの画面に戻ります。
↑UART2からの通信にも対応。上記結線(TTLレベル)でホストPCと接続。
↑ホストPCのターミナル(230400bps,8,N,1)上からESCキーを押すことで、ファイラは
終了し、FatFsのUART上のモニタプログラムが走ります。
↑現状では時刻設定はUART上のモニタプログラムからのみ可能です。
↑電源OFFは"真ん中"のキ―長押しで行います。この画面が出てからキーを放すと
FETスイッチが切れ"電源OFF"となります。
と、こんな感じです。ミニフォトフレームに機能を絞っているので以下に挙げる機
能は基板上には存在しますが使用していません。後は各人がソース変えてお好みで
付け足してくださいね(ひでぇ)。
*Not Used Devices
-Touch Sensor
-3D MEMS Sensor
-I2S Peripheral
-IrDA
また将来搭載予定の機能は以下に。
*Future Features
-USB-MSC 実装済
-LCD-Backlight Adjustment
-Adjustment Configuration which does not rely on host PC.
-Improve Backup Register Function.
-Improve Power Management 実装済
最優先はUSB-MSC。SDカードの抜き差しは面倒ですもんね。
USB-MSC実装しました。
IJG JPEG Library を実装しました！
んでもって修正すべき項目は以下に。
*Known Issues
-Cannot execute program if there's no Li-Ion Battery jumper. Fixed.
-Cannot execute backup function. Fixed.
現状Li-Ion電池のジャンパしてないとNo Batteryと判断されてしまいすぐに強制shutdown 修正済
されてしまいます。電源電圧の上手い監視方法見つけたらこちらはすぐに修正します。
ということでまだまだ手を加えるべき点はありますが、興味を持たれた人は試して
みてくださいね。ご利用は自己責任で〜
最新のFatFs移植例はこちらにあります。
よりみち
開発上でいくつか大きな変更があったので、ちょっと寄り道させてもらいます。
先日、STマイクロより待望のUSBライブラリの新版がリリースされました。しかし…
残念ながらUSB-HOST/OTGのサンプルはないっぽいorz。しばらく海外のForumを
旅して
きますか…。
既存のプログラムの動作の確認は、先にリリースされていたRC版で予習済なので今回
のライブラリをフォルダごとごっそり差し替えるだけで終わっています。
もちろん動作も確認済。
そして先に告知していましたがSTM32F103のMiddleDensity系は今回の更新で
クローズ、あとSTM32F107VBTの方はSTM32F107VCT6と統合するので削除とします。
これから先はSTM32F107VCT6とSTM32Primer2(STM32F103VET6)を中心に開発を
進めていくつもりです。
また、おきばの方も近々リニューアルする予定です。
それともう一点、いつもARMマイコンのビルドに使っているCodeSourcery G++が
バージョンアップしてGCCが4.4.1に変わっていました。以前3系->4系に
変わったときに最適化のされ過ぎでビルドが通っても思ったよう動かない
等の問題があったので試しにいくつかのプログラムをビルドして動かして
みると案の定変な動作するものが出てきました。
具合的に言うとLPC2388のプログラムでswitch文を含むコードを最適化して実行すると
暴走する箇所があり、原因を調べるとリンカスクリプト内のアラインメントの
設定でした。
これは元々AT91R40708でRAMスタートするときに行っていた処置で,.text内の記述で
. = ALIGN(4);であるところを
. = ALIGN(8);としていました。
それを他にもツブシがきくようにと別のARMマイコンのリンカスクリプトにも移植
してその時の環境では動作に問題なかったため放置していましたがこれがあだに
なってしまっていたようです。
それらは". = ALIGN(4);"に直して無事正常動作を確認しました。
ビルド環境がバージョンアップしたり変わったりするとよくこういうことになりが
ちですが,こまめに直していかないといけないですね…。
STM32Primer2をBARE-METALで使ってみる3 -ADCによる電源監視とUART2-
前回はSystickタイマを利用したスイッチ入力で電源の制御を行いました。しかし
電源を付けっぱなしにしているとどんどん電力が消費され、ついには3.5Vを切って
しまいます。（リチウムイオン電池の詳細な特性については他の専門に解説されて
いる方たちにうっちゃる(うｎ？)として、）実際3.5V以下になると急速に電圧が低
下していってしまうという特性があるので3.5Vできっちり止めなければなりません。
STM32Primer2はリチウムイオン電池の電圧低下をハードウエアで監視する機構がな
いのでSTM32に内蔵されたADCを利用してソフト的に監視し、3.5V以下になったら強
制的にシャットダウンする必要があります。今回はCircleOSのDMAを利用したADCと
過去の自分のコードを利用して電源監視ルーチンを作りました。
電源監視ルーチンはCircleOSで行っている方法とほぼ一緒で、1Secごとに移動平均
化されたVbatの値が3500(3500mV)になりさらにそれが15秒間連続した時にSHUTDOUN
信号を出してFETスイッチをOFFにするというものです。
そしてこの機構が実際に機能しているかどうかを確認するためにモニタリングする
必要がありますが、この検証には背面の拡張コネクタから出ているUART2を利用し
ました。このUART2のルーチンも自分の過去の(ry)でprintfにリダイレクトさせるよ
うにしています。
以前107系等で組んでいた時はUART-Txだけは割り込みを使用せず、ポーリングで回し
ていました。今回UART-Txも割り込み方式に変えています。それで初めて気づいた
のですがprintf等使用時に高速にバッファに転写すると早すぎて割り込み処理が
間に合わず、文字列が反転した状態で出てきてしまいましたので少し細工を行い安
定して文字列を送信できるようにしました。
↑大活躍の極小USB-Serial変換(画像右上)。
以上の条件下(72MHz駆動,LCDバックライトは未制御のため全点灯)でUART2から文字
列を排出した状態で電源電圧低下を感知して自動で切れるまでモニタリングを行い
ました
上図の結果のとおり、満充電4.1Vから徐々に電圧が落ちて行って3.5Vに差し掛かっ
たところでFETスイッチが切れています。また3.6V付近から電圧の落ち込みが急速に
早くなっているのが分かりますね。自働強制シャットダウンまで約4時間まるまる
かかりましたがCPUは最高速度,LCDのバックライトも未制御の最大輝度ですのかな
り電流喰っている状態です。この二つを制御できたらさらに持つでしょうね。
次回はFSMCを使ったLCDの制御に入ります。
FSMCは全く使用したことがないので少々手こずりそうです。
STM32Primer2をBARE-METALで使ってみる2 -Systickタイマと電源制御-
前回は一番基本的なLEDの点滅を行いました。点滅だけなので、STM32 Primer2の
バッテリーの制御(電源OFF)ができません。これから先いちいちUSBケーブルを抜き差し
するのは不便なので今回は電源制御を行います。
電源の制御にあたって、STM32(というかCortex-M3)に搭載されているSystickタイマ
を利用し、定期的にSWポートをスキャンしてある条件を満たしていれば電源をOFFに
することにします。これはCircleOSと同じ仕様ですね。
具体的には1mSecごとにCenterキー(PA8)を走査して5000mSecの間連続してHi
レベルにあったときにSHUTDOWN(PC13)をHiレベルにしてFETスイッチをOFFに
します。4入力キーの定義も行っていますが、今回は使うのはまだCENTER
キーだけです。
↑4+1キー入力と電源制御(SHUTDOWN)周辺
またRLINKのフラッシュの方法も少し工夫しました。RFlasher7でちんたらやってた
ら非常に煩わしいので、OpenOCDを使ってた時よろしくmake programでコマンドラ
インのフラッシュライタを呼び出し、バッチ処理しています。これでOpenOCD使って
た頃とまったく変わらない操作性になりました。やっぱこっちのスタイルの方がい
いですね〜♥もちろんRLINKのデバイスドライバはWinUSBの方で！
↑OpenOCDのフラッシュプログラムの処理をRLINKに置き換える
土台が整ったので、ここから先は駆け足になると思います。同じ事やってても何も
身につかないのは自覚してるので浅く広く早くでやっていくつもりです。
一応ねむいさんの基本スタンスは…
●無償で公開されてるライブラリ・プログラムは極力有り難く利用させてもらう。
●↑のことした場合は"ネットで見つけた"とか書かずに公開元のルールのもと引
用先をブログやソース内で明示させてもらう。
●使わせてもらう前にざっとでいいからコードを眺めて流れを把握する。
●ここは自分でやらないとだめだ！って部分は自分で調べてフルスクラッチで書く。
●真似てやって壊れても潰れても燃えても泣かない(これ重要)。一度壊したけど。
●他の方がされていることに過度に干渉しない(これ重要)。
この辺虹裏内での立ち回りと全く同じなわけですが、気をつけます。
STM32Primer2をBARE-METALで使ってみる1
BARE-METALとか横文字でかっこつけてみたけれどつまりCircleOS(とそのAPI)
使わないでやってみるというわけです。
STM32F103VET6(を使ったSTM32Primer2のハードウエア)に合わせたフレーム
ワーク作りをやって行きます。
今までSTM32F103VBT6(CQ-STARM),STM32F107VCT6とやって来てリンカス
クリプトやスタートアップの組み方は熟知してますので定義だけ変えて
あげれば終わりです。
STM32F107VCT6をベースにしてPrimer2上の2つのLEDを交互に点滅するプログラムを
こしらえるのが今回の最初の目標です。(FWライブラリは勿論V3.1.2の最新で）
STマイクロさんが用意してくれているCソースのシステムクロック用の設定は、
デフォルトが103,101系は8MHz,107系は25MHzの外部クロックを想定しています。
STM32Primer2は12MHzのクリスタルを使用するため、system_stm32f10x.cにある
クロックPLLを設定する関数内で一部定義を書き換える必要があります。
提供されたライブラリにはなるべく触りたくなかったので、コピーした
ファイルをリネームしてmain.cと同じ場所に置きました。
↑赤で囲った部分がPLLの定義を書き換えたところ
さらに、使用している外部クロックを決める定義(HSE_Value)はmakefile内で行っています。
プログラムの書き込みは先日無理やり適用したWinUSBのドライバで安定して動くよ
うになったRlink(ビルドイン)を使い、RFlasher7で書き込みます。
まだ電源制御は乗っけていませんのでtodotani氏のブログ内の記述にある
とおり電源のONは出来てもOFFはできません。電源切る時はリチウムイオン電池の
ジャンパとPCにつなげてるUSBケーブル引っこ抜いて切る必要があります。
次回はこの電源制御を中心としてsystickタイマ・キー入力の実装を行うつもりです。
ペ プ シ あ ず き
ペプシあずきっていう際物のペプシ飲んでみたのですが…
…うおえっぷ。子供向けのシロップ状の薬思い出してしまった…。
そしてそんなことやってる間にも私の周りの世界はどんどん回っていく。LPC2388のコ
ンテスト受賞者が発表されていますね〜。私がFreeRTOSを知り、使うきっかけとなっ
た今井健太郎氏やUSBデバイスの開発で詰まったときに参考にさせてもらっているマイ
コン工作実験日記氏の作品が入賞されています。
私はチェンジニアリング(=他人の成果物使って切った張った)しかできないから一つの
プロジェクトを決められた時間でフルスクラッチでバシッと組めるってのは尊敬して
しまいます。この業界に転職して早一年と少し、なんとかしがみ付いてきたけどこの先
数年もしないうちにまた違う職種に移ってるんだろうけども何かひとつくらいはでっか
いの残していきたいな〜なんて妄想してます(げんぢつから目をそらしながら)。
久しぶりの日記がここで終わってしまうと歯切れが悪いのでもうちょっと書いてみます。
●STM32 Primer2
以前から少しずつSTM32F107系の記事書いてきましたが、そちらと並行して
STM32Primer2をCircleOS無しで動かす構想を考えています。
目標は…FreeRTOSを乗せて動かす！
…と書いてしまいましたが実際ことに移すとコレ結構厄介です。まずは開発環境が…。
STM32Primer2にはビルドインされたRLINKがあるのですがこれがSWD接続の為にOpen
OCDから直接操作ができません(20091104現在)。
そしてRLINKのデバイスドライバ(Windriver)が未だにバージョンが低いものを要求し
ているため、AVRJTAGICEmk2等で使用されている最新のVerのものを使用することがで
きません！無理やり使うと確実にB.S.O.D.になってしまいますorz(XP環境の話です)
実はねむいさんがSTM32Primerを使用することに消極的だったのはこのドライバの問題
なわけで、よくよく調べてみるとWindowsVISTA以降のOSはマイクロソフト純正の汎用
USBドライバであるWinUSBなる物が提供されていてVISTA以降のOSではRLINKの
ドライバとしてこちらが適用されているようです。ねむいさんは
このWinUSBってやつを無理やりXPにも適用して難を逃れました！！(セコいな)
FreeRTOSを乗せる過程は一気にはできないので次回以降でぼちぼちとやっていきます。
●aitendoさんのTFTモジュール
たくさん売れたおかげで専用の拡張ボードまで起こしてもらって再販になっています
(20091104現在)。一枚絵の表示くらいならAVRでも十分にできるのでひとつくらいは持
ってても良いかと思います。私もLPC2388,STM32F107で表示させてきましたが
そら氏と同じく青みがかかった画面を何とかしようといろいろあがいてみました。
しかし結局大きな改善はできませんでしたがVMCTR1(VCOM control1）という
レジスタの値を変えるとコントラストは変えることができたので少しいじって
濃いめに出すようにしました。
STM32F107VCT6のプログラムはUSBライブラリのリリース待ちの関係で公開を
保留してましたけど一項に出る気配がないのでW.I.P.ですが置いておきます。
FatFsは先日R0.07eがリリースされていましたのでこちらも適用してあります。
LPC2388の方もSTM32とおなじ修正を施しておきました。以前はUART版とVCOM版は
分けていましたが今回からmakefile内で切り替えられるようにして一本化を行いました。
こうしておくと管理楽ですからね〜。ついでにchan氏のmp3プレーヤーで使用している
mp3モジュールを使用したスイッチ入力にも対応しています。詳細は同梱のdocフォルダを。
●OLIMEXのAT91SAM7S256プロトタイプボード
ず〜〜〜っと前からやるやる詐欺してましたがこちらも腐らせるにはもったいなさす
ぎるので手をかけることに決めました。こちらの目標はいくつか買い込んであった
TFTモジュールを使用したUSB接続のミニフォトフレームの製作をしてみようと
思います。
↑やるやる詐欺
いろいろ試す3
ハロウィンネタ&他のキャラの誕生日お祝いネタの仕込みで本業(二次裏)が糞ほど忙しく
なってます。しばらくこっちは更新できそうもないので今のうちに書けることを…。
●この前のTFT液晶の在庫数が
一気に減ってたaitendoさんの900円液晶、私がこのブログに使用記を公開したあたりから在庫数が一気に
減ってました。皆様子見だったのですね〜…。
もうじき在庫ゼロになりそうな勢いです。
私はLPC2388向けにサンプルコードを公開してましたが、STM32はUSBライブラリが(ry
のおかげでまだ二の足踏んでます。まぁRCは出てるから時間の問題とは思いますが…。
あとSTマイクロ側がUSB-OTGのデュアルロール機能のサンプルとか公開してくれたら
神なんですけお…USBホスト関連のスタックは今でもそれ作るだけでお金になる
ようだから無対価で手に入るの(=枯れる)はずっと先になりそうです。
●STM32F107でUSB_DFU_Bootloader使う件
んでもって前回行ったSTM32F107/5系のブートローダーが機能しない件の回避策
ですが、ねむいさんはブートローダーをDFU一本に絞ることにしました。
したがって以後は下図のような構成でマイコン遊びを続けていきたいと思います。
20091102変更:
BOOT0とBOOT1を取り違えるという最悪なミスに気づいたので修正orz
20091216変更:
PB5は10kohmでも問題ないことが分かり修正orz
STM32F103系と違ってdfu使うための領域とかスタートアップの設定とかを
気にしなくてよくなったのは良い点だと思いますね。errataさえなければ！
●シンプルi2cマスタライブラリ
ライブラリ固め
AVRでの使用例とか
LPC2388での使用例とか
●OpenOCDのビルド方法が少し変わった
現在、zus氏のOpenOCDのビルド方法をそのままやるとビルドエラーで失敗します。
svnからgitに変わったのでgitで最新のソースを落とせとのこと。
gitでの取得のコマンドはsvnと微妙に違って
git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
だそうです。けっこう時間かかります。
んでもっていつものフラッシュ書き込みやってみました。
STM32F107VCT6の例です↓
> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.3.0-dev-00405-g1e5daf5-dirty (2009-10-22-11:15)
$URL$
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : stm32.bs: nonstandard IR mask
Warn : use 'stm32.cpu' as target identifier, not '0'
Info : device: 4 "2232C"
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080061a4 msp: 0x20010000
Info : device id = 0x10016418
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 95952 byte from file main.elf in 5.906250s (15.865079 kb/s)
verified 95952 bytes in 1.921875s
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
> Process Exit Code: 0
> Time Taken: 00:10…OpenOCD+Jtagkeyをほとんどフラッシュ書き込み機としか使っていない私。
●FreeRTOSがV6.0.0になってた
なってました。私が使用しているMCUには特に大した変更の影響はないみたいですが…。
いまはSTM32F107VCT6に重点的になっててLPC2388の更新したのずいぶん前に
なっちゃってましたので動作確認がてらにソースの見直しをしました。
LPCUSBを使用したUSB-CDCのソースコードも一本化して可搬性あげるよう
努めてます。
他のMCUにも言えることですがBare-MetalとFreeRTOSで分けていたソースは
#define切って同じファイル使いまわせるように直していくつもりです。
今見返すとつぎはぎだらけでひどかったorz
LPC2388用FreeRTOSのサンプル
LPC2388もある程度遊んだらクローズしてSTM32に集中したいです。今後はSTM32にFreeRTOSの組み合わせが日記のネタの要になるでしょう。
●STM32 Primer2の電源ICがすぐぶっこわれて云々の件
私が検証記事を載せた数日後に公式も同様な見解を述べています。
ううむ、私の読みが完全に当たってしまった…ってわけですか…。
電源IC壊れちゃった人はこの際私みたく別のLDOに変えちゃうのもいいかもしれま
せんね…。(もちろん自己責任で)
LPC2388にもTFT液晶モジュールを
よし。
LPC2388の高速なFIOでもノーウエイトで十分に動かせられるのでかなり使えますね〜。
とりあえずaitendoさんに追加で発注掛けときました。これは良いものだ(マ・クべ顔で)
ソースはこちらに。ご利用は自己責任でどうぞ。今日はこれにて！
…と言いたいところだが！！話はSTM32、現在私が使用している最中のSTM32F107VCT
の話に戻ります。STM32のフォーラム見てたら例のブートローダーが動かないバグが
正式にerrataとして上がってました。
> During the boot loader activation phase,
> if the USART1_RX (PA10), USART2_RX (PD6,
> remapped pin), CAN2_Rx (PB5, remapped pin),
> OTG_FS_DM (PA11) and/or OTG_FS_DP
> (PA12) pin(s) are connected to low level or left floating,
> the boot loader cannot be used.
> It is not possible to connect to the boot loader through either
> of CAN2 (remapped), DFU (OTG
> FS in Device mode), USART1 or USART2 (remapped).
だそうです。本来ならSTM32F103VBT6でうまくいってた接続ではSTM32F107/5系に
乗り換えても本来は正しく動くはずですが、errataのせいで正しい状態に遷移出来てな
かったようです。んでWorkAroundは…
> ● For 100-pin packages: depending on the used peripheral
> the pins for the unused
> peripherals have to be kept at a high level during the
> boot loader activation phase as described below:
> . If USART1 is used to connect to the boot loader
> : PD6 and PB5 have to be kept at a high level
> . If USART2 is used to connect to the boot loader
> : PA10, PB5, PA11 and PA12 have to be kept at a high level
> . If CAN2 is used to connect to the boot loader
> : PA10, PD6, PA11 and PA12 have to be kept at a high level
> . If DFU is used to connect to the boot loader
> : PA10, PB5 and PD6 have to be kept at a high level
一応回避策はあるようですね。…しかし…
>● For 64-pin packages: none. The boot loader cannot be used.
> In 64-pin packages, the USART2_RX remapped pin PD6 is not available and is internally
> grounded. Therefore, the bootloader cannot be used at all.
ねむいさんはSTM32F107VCT6(100Pinデバイス)なのでまだ負けていません。
回避できるかどうか早速試してみました。STM32F103VBTで使用していたUSART1は
107系ではUSB-OTGのvbusとぶつかってしまう為にremapされたUSART2を
使うのが都合が良いようです。
あとシステムメモリブート起動時のプルアップはworkaroundには"kept ata high
level"とだけ
書いていますがこれが10kohmとかでプルアップしただけじゃ全然ダメで、
一部のポートは1kohmくらいで強めに引っ張り上げとかなくてはなりませんでした。
20091216変更:
PB5に別の検証で使ってたデジトラのコレクタがぶら下っててこれ取り除いたら
10kohmでも問題ないことが分かり修正orz
20101206追加:
デジトラのコレクタがぶら下ってて気づくの遅れたのですが、どうやら
最初にサンプルで貰ったSTM32F107VBT6では1kohmで引っ張らないと無理です。
まぁESですから文句は言えませんね
remappedされたUSART2でブートローダーを使うときには以下の組み合わせで…。
PA10(USART1_RX) :10kohm
PD6(USART2_RX) :10kohm
PB5 (CAN_RX) :10kohｍ
PA11&PA12(USB_DATA) :4.7kohm
USART2(とUSART1も結局試したけど)はブートシーケンスに入るタイミングがかなり
シビアです。
ちんたらしてるとすぐに失敗します。なんとかホストPCとの通信に成功すると
いつものダイアログが出てくれます。
ここまでくれば安定してフラッシュの読み書きができます。でもここまでに至る過程が
非常に不安定です。それにCQ-STARMの基板流用してUSBから電源供給してるので
USART2からのブートのためにPA11,PA12(DP&DM)プルアップしてるとダイアログが
出まくって非常にうっとうしいです。USBと絡めて使うときはUSARTのブートは
使えませんね。
次にDFUで起動するかどうかを試しました。DFUでブートするためにはPA11,12の
プルアップはもう必要ないですが、vbus供給必須です！
先にも述べましたがvbusはUSART1のTXにぶち当たるのでリマップさせない限り
USART1は使用できなくなります。STM32EVAL-CのデモもすべてUSART2(remapped)
に切り替わってるのでSTM32F105/7系でUSART1をあえて使う理由もありませんが…。
念願のDFUが起動しました…
シリアルナンバーは"STM32"で固定です。一度ドライバ読んだら次からはUSBポート
のどこさしてもドライバは要求されません。
内部フラッシュメモリの読み書きのほかにoptionbyteもいじれるみたいですね。
書き込み速度は流石にJTAGにはかなわないです。でも単体でUSB経由でファームの
更新できるので出先でも書き換えができます。(実装次第ですが)
…と懸念事項であったSTM32F105/7のブートローダーが起動しない問題も
workaroundで一応の解決を見たのですがerrata-sheetを見るとUSB-OTGや
EthernetMACのerrataもたんまり増えてます。
これから使いたい機能にもろかぶりしてしまってるので、はまって足止め
くらわされないようにじっくり検証していきたいですね。
色々直す…
…前回の検証でSTM32 Primer2に乗っかっているSWレギュレータIC(L6928D)を、
2つとも吹っ飛ばしてしまいましたが、これらはU9:メインMCU電源供給(2.85V)、
U17:バックライト用電源(3.1V)向けという非常にクリチカルな部分に使われており
どちらか一つでも壊すと、もはやPrimer2は使用不可能になります！！あほか！
仕方がないので代替で使用できそうなレギュレータを探し貼っ付けました
L6928Dは非常に繊細だとのことでもう使わない方向で…
まずバックライト電源生成部。元の設計上では3.1V出力ですが実際は3.2V近くです。
また、カラーLCDのバックライト電源は3.3Vまで使用可能でなおかつSTM32Primer2が
監視しているリチウム2次電池のシャットダウン電圧が3.5Vな点から、いつものLT1963A
先生に代役してもらうことに。電流は500mAも引かないので3.5Vまで落ち込んだ時の
ドロップアウト電圧も気にならないレベルです。これでもう一寸安くなってくれたら
ねむいさん的に最強のLDOなんですけお…性能が高い分お値段も高いんですよね。
次に2.85V生成部なんですが身近にすぐ手に入る2.85V出してくれるちっさいサイズの
レギュレータがLP3988しかありませんでした。残念ながら150mAしか引けないので
STM32Primer2回すだけで精いっぱいです。外部に機器を接続する時は別口でとらざるを
得ないです。耐圧はL6928Dよりも0.5V高いので過渡電圧余裕も確保…かしら？
一度は死んだSTM32primer2でしたが措置を施し電源が修復強化されて無事復ッ活！！
ちなみに10月11日は同僚のヤクいさんの誕生日なのでした！
そしてもうひとつ、不注意で壊してしまった(輝度が異様に下がってしまった)OLEDの
代わりに新しいOLEDの基板がやってきました。前々回もお見せしましたが、chan氏の
LPC2388用のOLEDアクセスプログラムをSTM32F107VCT6に移植しています。
LPC2388のFIOはI/Oクロック36MHzの高速アクセス(最高I/Oトグルスピード18MHz)が
できてOLEDも非常にスムーズに表示できたのですが、STM32もほぼ互角のI/Oアクセス
性能を持ちます。
ただし、STマイクロ提供のライブラリ関数からだと呼び出しオーバーヘッドが掛かり、
直接GPIOレジスタにアクセスする必要があります。
さらにSTM32に(というかCortex-M3)はビットバンドによるアクセスができるので、
うまく組むとLPC2388より早くアクセス可能でしょう。
今回は便宜上GPIOEのみを使用してOLEDを制御したので1命令分多くかかっています。
というわけでSTM32F107VCT6でOLED動かしたところ↓
嗚呼残念だ、せっかくのいなちゃんのえろすな絵が輝度が高すぎて光学迷彩が
掛かったみたいな写真になってしまったー(棒
…とふざけるのはここら辺にしといてカラー写真とかもOLEDでは綺麗に表示できてい
ます。モデルはコツメ氏。カワウソって良いですよね♥特に頭の形とか♥
はてさて、STM32の新(OTGを含む)USBライブラリのリリースはもう少しのはずです
が…。待ち遠しいですね〜。
涙目のネムイ2(STM32 Primer2壊しました)
STM32F107VCTでもOLED使えるようになりました。64kBもあるRAMのおかげです♥
え？"なにも映ってないだろこの茶デブが!"ですって！？よっっく見てください！！
うっすらとシルエットが見えるでしょう？…OLEDを物理的に潰さなければもっと
綺麗に写ってるはずなのです！なのです！！
…いないさんの美しい肢体は新しいOLEDモジュールが来るまでおあずけ…
…さて本題、先日STM32 Primer2について黒田さんより電源IC(U9,U17のL6928D
というIC)が破損対策がされているのにもかかわらず破損したとのコメントを
いただきました。遊びでも仕事でもも電源周りのトラブルで泣かされている
ねむいさんはこれ以上Primer2で憂き目にあう人が出てしまわないように調査を
開始しました。
まず問題の部分、以前はU17のGNDが信号線扱いで間違って細いパタンが引かれてしま
ってGNDのインピーダンスが高い状態になってしまって電源投入直後の入力の過渡電圧
でIC死亡となっていた問題は、出荷時にU17のGND(4Pin)を太いジャンパで強化するこ
とによって回避しています(したはずでした)。
しかし対策されたはずの基板でも破損が発生したということは同じ問題が解決していな
いかもしくはまた別な問題があると思われます。とにかく現状何が起こってるかをオシ
ロで観測することに。
VCCINとGND,実際はC23の+と-の電位差をモニタし、FETスイッチがONになった瞬間の
電圧遷移を測定しています。
VCCINの波形は電源供給元によりかなり特性が変わります。これはリチウム2次電池のみ。
こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。
最後にUSBケーブルの給電＋リチウム2次電池。
L6928Dの絶対最大定格が+6VですがFETスイッチが入った瞬間の過渡電圧が+5V近く
まで迫っています。私の環境では定格内に収まっていますが、違う環境(USB給電で
使用時、かつVbusが+5Vより少し高いようなPCの環境)では+6V以上に跳ね上がる
可能性がありますね。
また黒田さんが教えてくださったRaisonance側の見解は、
>The two L6928D regulators (U9 and U17) are very sensitive.
>To solve this issue, the patch on U9 is the main measure.
>But it seems not to be sufficent.
>A second measure consists in replacing the input capacitors (C23 and C56)
>by multilayer ceramic capacitors (instead of tantalum).
>We will modify the web page to recommend this additional measure.
これはESRが低い大容量のMLCCを使って過渡電圧を抑制しようという試みでしょうか??
十分な性能を持ち、手に入れやすいMLCCを使って私も検証してみました。
※参考になる記事
…ほんとは電源周りに使うなら十分な耐圧持ったX7R、最低でもX5Rは欲しい。
とっかえました。撮影の際見やすいように電源ICは一旦取り外してあります。
>2012サイズではちょっと取り付けが苦しそうですね。
はい。確かにちょっと半田しずらいですorz。半田で盛って何とか取り付けました。
この状態でもう一度、FETスイッチがONになった瞬間のVCCINの電圧遷移を
測定しました。
これはリチウム2次電池のみ。
こちらはUSBケーブルの給電のみ。裏のジャンパは外した状態。
最後にUSBケーブルの給電＋リチウム2次電池。
波形に関しては目に見える効果が表れています。チップタンタル使ってた時に発生して
いた過渡電圧の"ヒゲ"がバッサリ削られています。これだと十分にL6928Dの定格に収め
られますね。
L6928D破損の原因がFETスイッチのON時に発生する過渡電圧ならばC23,C56の
チップタンタルをESRが低いMLCCに交換する手法は非常に有効でしょう。
20120522追:
Achan22氏のさらなる解析によると、出力段FET(Lxピン)に外付けのフライホイール
ダイオードを付与して回生エネルギーによる破損からFETを保護する必要もあるようです。
この後もいろいろデータ取りたかったのですが残念ながら続行できませんでした。何
故かというとオシロのプローブあちこちつなぎ換えてるうちにどっか変なトコ触っちゃ
ったのか知りませんがL6928Dを潰してしまったからです…。
しかもU9とU17の2つとも！！！！orz
>The two L6928D regulators (U9 and U17) are very sensitive.
>very sensitive.
繊細すぎる…さてと代替品探しに行くか…。
STM32の新しいライブラリを試してみた
前回も終わりのあたりでさらっと触れましたが、まず標準周辺ファームウエアライブラリ
(STM32F10x_StdPeriph_Lib)がv3.1.0->v3.1.2に変更しています。それとまだRC版ですが
USBライブラリ(STM32_USB-FS-Device_Lib)もV3.0.1->V3.1.0RCになっています。前回
はさっと見ただけで済ませてましたが、もう少し深く立ち入って検証してみたのでその
所感をば…。
●STM32F10x_StdPeriph_Libの方
全体的に大変更は無く、若干のコメント記述の変更やデモプロジェクトの追加等でお
さまってるようです。ライブラリそのものもごっそり入れ替えるだけ公開してきたいくつか
のサンプルで正常動作を確認しています。
また、前々回FreeRTOSを動作させた時スタートアップ周りのコードをそのまま使っていると
数秒で止まってしまった問題は私が設定したスタートアップのdefine漏れと私自身が作成
したi2cローレベルルーチンのバグ(ACKフラグの消し忘れ)が原因だということが分かり(orz)、
結局そこを直しただけでわざわざ変更修正していたsystem_stm32f10x.cも配布の物を
そのまま使える状態で動かすことができています。
つまらん時間食ったぜ…orz
●STM32_USB-FS-Device_Libの方
現状まだRC版ですが内容物を見たところ、7月頃に公開されていたConnectivity-Line
用のUSBOTG-LIBと合併した形で公開されています。おそらく正式リリース版もこの形で
提供されることになるでしょう。また、評価ボードごとのヘッダ・ソースファイルも今回より新
しく提供されていました。私のようにCQ-STARM基板を改造しまくって使用し、かつライブラリ
付属のサンプルを流用してる人は要注意です。
ちなみにSTM32F103系で使えてたUSBライブラリはUSB-OTG(とOTG用のPHY)が乗った
107系には転用できません(だからライブラリもわざわざ別にされてたわけなんですが)。今回
のライブラリの合併(サンプルプロジェクト付き)によって107系でも手軽にUSBが扱えるよう
になりました。でもって肝心の動作の方なのですが、STM32F103系はそのまま差し替える
だけで問題なし。STM32F107系もOTG-LIB関連のファイルを追加してビルドするようにすると
USBデバイスとして動かすことができるようになりました。現状では、USB-CDC・MSCの
二つは動作を確認できています。提供されているサンプルは今のところターゲットデバイス
のみに絞られており、OTGの機能をフルに使ったものはまだないようです。
今後の充実に期待ですね…私もUSB-miniABコネクタ買っとかないと…。
前回は新ライブラリで動作を確認次第公開していたサンプルコードも順次差し替えていくと
言いましたが、上述のとおりUSBのライブラリももうすぐリリースされそうなのでこちらの
正式リリースを待って公開としていこうと思います。今から急いでも仕方なしですからね〜
…特に107系は。
あ、いちおう言っとくけどLPC2388はUSB-OTG用のPHYチップ付けないとOTGの機能使えま
せんから！USB-TargetだけもしくはUSB-HostだけならPHY無しの直結でも動きますけどね…。
STM32F107VCT6に乗り換えた
今をさかのぼること数年前、まだ私が｢｣がいるほうの二次裏で活動していた頃、タッチ
ペン使ってめどいさんと云々なDSのゲームの妄想ネタがあった(はずだとおもう)のです
が、STM32Primer2使って似たようなこと再現してみました。
bare-metalで組んだ方が勉強になる(ｷﾘｯ とかでかい口叩いてしまいましたがやっぱし
APIとか提供されてたらそっち使った方が楽ですよね〜ﾊﾊ、ﾊﾊﾊ…。今回紹介したのも
CircleOSにビルドインされてるDRAW関係のAPI呼んだだけ。アプリよりこれ用の絵を
引き直してる時間のが長かったです。
↑いないさんとあそぼう(性的な意味で)。びいぶろ君が欲情すると困るので画像をぼか
してる上にちいさいのはあしからず。そのかわり虹裏には鮮明な画像を投下して
おいた！
Primer1と比べると発色・視野角ともに良好で美しいいないさんのイラストがさらに
際だちますね♥写真はぼけてるけど。
↑もちろんタッチペン入力に対応。ペンの先っちょで"先っちょ"をつんつんすると…♥
…ごめん、もう二度とこんなことしないからゆるして…
さて本題、先日digi-keyよりSTM32F107VCT6を購入したので以前CQ-STARM基板に載
せ替えていたSTM32F107VBT6と交換しました。当たり前ですが先日走らせたFreeRTOS
もそのまま無事に動作しています。また懸念されていたシステムメモリから起動する
方のブートローダーが動かない件はVCT6になってもやっぱり駄目でした
(リビジョンは同じ'Z')。まぁJTAGあるから良いでしょう…。
そしてSTM32の Standard Peripherals Library(FWLib)がv3.1.2 に上がったので
こちらのライブラリもFreeRTOSのデモに組み込んで無事動作確認。あとは過去に
公開したSTM32F103VBT6,STM32F107VBT6用のプログラムも順次FWLibを3.1.2に
最終アップデートしてclosedとし、以降はSTM32F107VCT6一本で遊んでいきたい
と思います。
と書いているうちにUSB-OTG対応のUSBライブラリのRC版がリリースされたようです。
こちらも早速評価してみます。
まさか君も秋月ARM基板を買ってしまったのか・・・
少し前にSTM32 Primer1/2用のOS,CircleOSがバージョンアップしてます。同じく
してRaisonance RIDE7の開発環境も新しくなっていました。
ねむいさんはCodesourceryをメインに使っていますがRIDEに使用されている
コンパイラもCodeSourcery。
RIDEのはまだツールチェーンのバージョンがひとつ古いです(2009年9月20日現在)
早速RIDEを入れ替え、CircleOSを新しくしようと思ってRFlasher起動させてRLINKを
認識させようとするといきなりB.S.O.D.に！！！再起動掛けて同じ事やろうとしても
やっぱりB.S.O.D.…orz
仕方ないので一度RIDEの環境を全部消してまっさらな状態でもう一度インストールを
行い(USB周りのデバドラももちろん全部消した上で)、試すと今度はOK。
…RAMディスクにデータ乗っけて作業してること多いのでマジ涙目なお話。
追：WinUSBのドライバをXPでも使えるようにすると涙目が治りました。
…前フリはおいといて、秋月はSTM32 Primer2というARMマイコンのプロトタイプ
ボードを販売していますが、それよりもずっと前にARMの基板を販売していました。
ご存じの方が多いと思いますが、販売当時のネット上の状況、とりわけ2chの電電板の
反応をみると芳しくない反応だらけでした。ボード単体では何もできないとかROM書く
のにMITUIWAボードなるLAN搭載のボードを別途購入してそのボードにROMを載せ替え
て書き込む必要が、つまりは別途ROMライタが必須だとか、そのボードはせっかく
LANがあるのに何でかシリアル経由で書く必要があるとか程度のことですが。
…うn?
なんかもう持ってるだけで情弱扱いされてしまいそうですが、それを言ったら上記の
Primer2だって買っても使いたおさなければ情弱アイテムになりかねないのは同じで
すしでもこれ以上ネガチヴなことは言うのやめてせっかくタダ同然で私の手に入った
ので使ってみようと決心しました。でもほんっとに基板だけしかなかったので先人が
ネット上に遺してくれた資料だけを頼りに動かしてみることに。
この秋月ARM基板の詳しい説明はなひたふ氏、HRA氏が残されています。AT91R40807
はMCU内にフラッシュロムがなく、8kbのPrimaryRAM,128kbのSecondaryRAMのみが
あります。秋月ARM基板には外付けでAT29LV1024というフラッシュロムが乗っかって
いますが、MITUIWAボード(=ROMライタ)を使用せずにJTAG経由でなおかつ安価な
方法でROMの書き換えを秋月ARM基板単体で行う方法をHRA氏は実現しています。
少し詳しく言うとJTAG経由でRAMにIAP(In-Application Programming)を転送
実行し、秋月ARM基板そのものをROMライタ化させている…といった感じです。
HRA氏はIAPの転送を行うJTAGアクセスの方法としてなひたふ氏が当時無料で公開して
いたMITOUJTAG体験版を使用していますが記事が書かれて数年後の今、MITOUJTAGは
残念ながら私たちホビイストの手の届かない場所に逝ってしまいました。しかし今は
OpenOCDという超強力なツールがあるので私はOpenOCDを使って同じことを再現する
ことにしました。
またサンプルコードについては何分大昔の物なので私が愛用しているCodeSourceryG++
の環境ではまともにビルドが通りません。結局スタートアップやリンカスクリプト等は
ほぼすべて1から書きなおしています。AT91R40807に当たっては避けて通れない
リマップのし方とかOpenOCDで同CPUを叩くスクリプトの書き方とかはすごく勉強に
なった…。
以下各モードでの動かし方とか動かした様子とか。
ROMスタートモードで実行するときは、まずIAP(ここではRomloader.elf)をSecondary
RAMに転送&実行し、UART1上で本来書き込むべきプログラムをフラッシュロムへと
ダウンロードします。本来はDCC経由で書くべきなんでしょうけどもHRA氏が作成
されたツールを最大限に利用させてもらいました…。
ROMに置かれたプログラムは、スタートアップルーチン内でSecondaryRAMに転送
され、そこでさらにbss領域初期化などの処理を経てmain関数へと飛びます。
RAMスタートモードで実行するときは、ROMに書かれた内容はガン無視でリマップ
されたSecondaryRAMに0x00100000からダウンロードします。さすがに早いです！
ROMスタート時と違って一切合財SecondaryRAMに押し込むので少しかさが
増えてます。
OpenOCDを使用した上記RAM,ROMスタート方法の具体的なテクニックは後に示す
ソース中のmakefikeを見てくださいね。
OpenOCD+CodesourceryG++のARM開発環境下でRAM,ROMスタートの方法を
見つかるまでかなり時間がかかりましたけどいつものUart経由でprintf
出力の所まではできました。
こっから先は回路図持ってないので出来ません…。ていうかSTM32F107とかLPC2388
とかの魅力的な石が出回ってる現在ではこれ以上この基板に時間をかける気はもう
微塵もありません！！
…しかし、時間が死ぬほど余ってる&この基板をただで手に入れたぜ〜！
なんて人は、リマップやROMなしCPUにおける外部ROMスタートの仕組みを学ぶのに
うってつけだと思います。
※20090930：
祝！秋月さんＨＰにてついに回路図が公開されたようです！
ねむいさんはもうこの基板やらないけど！
今回のテストプログラムはこちらです。最低限の部品で動きます。
またAT91R40807用のOpenOCDのスクリプトはこちらに。
上記サンプルソースにはビルド済のRomloaderのelfがあるけど別途コンパイルしたい
なんて方のためにこちらに置いときます…。
以上ご利用は自己責任で…。
全然関係ないけどAT91R40807が正解なんだけどAT91R40708といつも間違えてしまうorz
STM32F107はぢめました
http://belogic.com/uzebox/
いつ見てもすごいなこれ
…は置いといてSTマイクロさんにサンプル請求していたSTM32F107VBT6が
ねむいさんちにやってきた！！！！
このSTM32F107xxxってやつは今年の7月にリリースされたSTM32の新機種、Connect
ivitiy-lineという種で、今までのSTM32の機能に加えてEthernet-MAC,USB-OTG(PHY
も内蔵),I2Sインターフェースとてんこもりになっています。NxPのLPC2388も同じ
数だけ周辺がありますが、多分どっちも使い切れんだろうね…orz
このチップはCQ-STARMに乗っかってたSTM32F103VBT6とピン・機能互換なので、その
まま載せ替えが可能です。というわけで早速載せ替え〜！
まずCPUだけ。STM32F107はUSB-OTGなので以前のUSBライブラリはそのまま使用でき
ません。しかしそれ以外は互換性があります。以前のプログラムをJTAG経由で書
き込み、UART,RTC,ADC,I2Cの動作を確認。載せ替えは(物理的に)上手くいっている
ようです。
次に上記のプログラムをベースにSTM32F107VBT6(Connectivity line)用にリンカ
スクリプトやスタートアップを適用していきました。またEthernet-PHYを使用
することも考えてメインのクリスタル(HSE)は25MHzの物に差し替えています。
少しの変更で作成したSTM32F107用のプログラムですが問題なく動作しました。
後はUSB-OTGのライブラリのちゃんとしたのが出そろうのを待つばかりですね〜。
それまではFreeeRTOSのSTM32F107用デモ(Ethernet-PHY制御含む)の完全動作を目標に
していきたいと思います。
あと雑多な所感とか…
STM32 Connectivity lineのMCUはシステムメモリにUART1,UART2,CAN,DFUの
ブートローダーが仕込まれているとのことで特にシステムメモリからDFUが使えると
スタートアドレスやリンカスクリプトをいじる必要もなくなりさらにやりすいかなぁ
…と思って早速試してみたのですがなぜか起動しない…orz
STマイクロのフォーラムを当たると私と同じ症状の人がいた。ううむ所詮はサンプル品
なのかはたまたerrataなのか…情報がたまるまで待ちましょうか…まぁJTAGで書き込み
とデバッグは出来るのでそちらの方法で行えばいいのですけれども(涙目で)。
STM32のコネクティビティ・ラインはブートローダーに致命的なバグがあります。
そんでもってSTM32ではJTAGで書いた消したやってるとうっかり__WFI();でループす
るようなプログラム書いちゃうとJTAGにすらアクセスできなくなってしまうのですが、
これはWFI実行したことによってJTAGの周辺回路のクロックまで止まってしまうからです。
内蔵フラッシュメモリじゃなくてシステムメモリからブートした状態からだとJTAGが
ひっかかってくれますので改めてフラッシュの内容を全消去によって復活しますので
やっちまった時の逃げわざと思っていてください。
それともうひとつ…OpenOCDでフラッシュ書き換えたときに出てくるメッセージとかを…
> "C:/Devz/AVR/WinAVR/utils/bin/make.exe" program
openocd -f C:/Devz/ARM/OCD/daemon.cfg -f C:/Devz/ARM/OCD/tcl/interface/jtagkey.cfg -f C:/Devz/ARM/OCD/tcl/target/stm32_flash.cfg -c "mt_flash main.elf"
Open On-Chip Debugger 0.3.0-in-development (2009-09-03-18:39) svn:2663
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
For bug reports, read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Warn : use 'stm32.cpu' as target identifier, not '0'
Info : device: 4 "2232C"
Info : deviceID: 67358712
Info : SerialNumber: 11111111A
Info : Description: Amontec JTAGkey A
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001b40 msp: 0x2000c000
Info : device id = 0x10016418
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 44704 byte from file main.elf in 2.812626s (15.521527 kb/s)
verified 44704 bytes in 1.125051s
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
> Process Exit Code: 0
> Time Taken: 00:05STM32F103VBT6の時はJTAGチェーンが見つかったときに
nfo : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
って出てましたがさすがに違いますね(あたりまえか)
続くdevice idも
STM32F103VBT6では
Info : device id = 0x20016410となっていましたが
STM32F107VBT6では
Info : device id = 0x10016418
となっています。
あとあともうひとつ…
リンカスクリプトいぢってみて分かったのですがSTM32F107VBT6はRAM48kByte
のはずだと思ったのですが、実際には64kByteありました…。
…なんだこれ？？？…やっぱサンプル品だから仕様外の物もあるってことでしょうか？？？
日々是学習
夏の喧騒も過ぎ去り、朝夕はすでに秋の気配を感じさせる季節になりましたが、皆様
皆様いかがお過ごしでしょうか？私は到来した民主政権の乱世を生き抜くべく棘付き
肩パッドとモヒカンカツラと火炎放射器を用意したぜﾋｬｯﾊｰ！!!でも七つの傷を持つ
男だけはかんべんな！
…と検索で情報を求めて飛んできた人をまわれ右させたところで本題に入ります…
ゆっこ(伊勢乃宮雪子)ちゃんの誕生日のお祝いも終わってひと段落した所でかねて
より構想していた、LPC2388用MCIアクセスプログラムのVCOM対応版の実装に
取り掛かりました。
以前はOLEDとVCOMの出力先を切り換える部分で死んでいたのですが、深く調べた
ところまだuart処理の部分が残っていたのが分かり、これもVCOMの処理に置き換え
ることでクリア。
んでVCOMを実装したことによりスーパーバイザモードでスタックオーバーフローしてた
のが分かったのでスタックをかなりおごってあげることにより不安定だったモニタの
動作も安定化しました。
あと、ほんとにいまさらですがMartinThomas氏のIRQ-wrapperの処理を穴のあくほど
見てLPC2388上ではどのようにして割り込みの動作がなされるかも再度確認…っと。(割り込みの解説は素直にHITOPのcookbook見た方が良いです)
…うｎ私まだARMの動作よくわかっていない部分があるんだ。
うむむUSB周りはほんとに難解ですね…やっていくうちに霧が晴れるようにわかるどこ
ろかますます視界がふさがっていくような感じです…(個人的に霧は大嫌いだし)。
それでも進んでいくしかない。次はUSB-MSCの実装で残っていた課題のMCIアクセスの
DMA化を目指しましょう。
といったところで今日のソースを…。ご使用は自己責任で…。
過去にリリースしたソースも改良すべき点や明らかな間違いを見つけた時は適宜修正
したりしてます。落として試されたことがある方はご留意ください。
LPC2388でUSB-MSC(MassStorageClass)を使う2
やっぱ難しいやUSBって…
前回はLPC2388でMCI経由で動く"だけ"の物をこしらえてました。ですのでつぎ
はぎだらけのがかなりいい加減でしたがここ1週間(1作業日)で自分なりに流れが
理解できる構成に変えました。これはUSB-CDCで行ったのと同じものです。
debug出力はフットプリントが少ないchan氏のxprintfに替え、かつ動作クロックを
48->72MHzに上げて、んでもってUSB接続で時折コケてた部分を修正してます。
肝心の機能の方は…MMC,SD,SDHC(4GBまで)対応で、LPCUSBが唱っている最大
250kb/sの読み書きもおこなえているようです。
SDカードをいくつか試してみると、容量の少ない物だと上記の速度で読み書きが
行えるのですがSDHCみたいな大容量のものだと半分以下の速度しか出ない事が
分かりmp3ファイルとか移動するときは速度が足らなくて不便に感じます。
あとMCIのドライバはESFLの物を流用させてもらっています。しかしこれはDMAを
使用していません。DMA使えたらSDHCとかでもう少し速度が改善できるんじゃ
ないかなと思っています。
すでに泥沼にはまっている気がしてますが違う事やろうとするとUSBはやっぱし
難しいですね…。まだまだW.I.P.なソースはこちらに。
ご使用は自己責任+ご意見無用でお願いします。
ついでにですが先に紹介したchan氏のLPC2388向けmciアクセスプログラムの
FatFsR0.07c+RTC適用版で相対パスのオプションを有効にしてコンパイルすると
正しく動作しなかったことが分かったので修正版をあげてます。
MCI_OLED
LPC2388でUSB-MSC(MassStorageClass)を使う1
"有益＝ソースコードそのまま流用できる"なんて根性でやってると痛い目にあいます。
ええ確実に。…そんな根性をしていた時期が…私にもありました(刃牙顔で)
重箱の隅までは理解しなくてもいいけど最低限どうやって桶屋が儲かってるのかくらい
は知っておいた方がいいとおもいますよマジで！CQ誌提供のGCCサンプルソースとかも
(ワザとじゃないだろうけど)明確な間違い仕込んでたりしてますんで遊びであっても
くだらないことで時間や金を消費しないように気をつけましょうというお話。
とくにLPC2388は…、
.org 0x1fc
__: .word 0x43218765
のたった二行をスタートアップに仕込まれただけで文字通りゴミ基板になるしでも
こんなあくどいことするやつさすがにいないだろけど…私はそんなことしないよ？…ふふふ
…さて本題、ここ最近はLPCUSBを使用してUSB Mass Storage Class(以下MSC)をLPC2388
で何とか実現できないかと模索しています。SPIアクセスのサンプルはすでにあるのですが、
せっかくSDIO(MCI)があるのでこれで使えるものにしていこうかな、と。
現状こんな感じです。
なんか微妙な…ディスク容量が…うまく表示されてない…
SDHCも認識できているようです。が…実際の動作は？？
このMSCをchan氏のmp3プレーヤーと結合させてSDカード取り外さずにデータ書き込め
たら手間が省けてうれしいのですがはてさて…
WorkInProgressですがソースも置いときます。検証段階ゆえに自己責任+ご意見無用で…。
次回に続く
現状USB関連の書籍を買ったり借りたりしておべんきょ進めてますが…私はぶっちゃけ
おべんきょとセンセイが大嫌いです…しかしUSBを必ず物にして恐怖症を克服したいです…
追：
OpenOCDのWindows用実行形式ファイルがftdiのライセンスがらみでダウンロードできなく
なってしまいましたが、ZUS氏がビルド方法の詳細な解説をされています。
私も氏のページを参考にビルドしたもので書き込み・デバッグ・メモリダンプができるのを
確認しました(OpenOCD ver 0.3.0 r2578)。また、JTAGkey互換デバイスを使っているのなら
ベステクさんところで配布してるバイナリを使わせてもらうという手もあります。
追2：
OpenOCDのソースはsvnではなくgitを使用して取得するようにしてください。
涙目のネムイ(STM32 Primer2のあれ)
秋月さんとこからもSTM32マイコン評価キットのSTM32 Primer2が販売されています。
大量在庫で6100円の格安です！
ねむいさんは4月頃にDigi-keyで9600円くらいで購入していたので今すげぇ涙目です。
くやしい…でも…使用記書いちゃう！
20110824追加:
超実用！！USBマスストレージ機能つきGPSロガー
20091206追加:
USBマスストレージ機能付きいないさんのえろす画像表示機の制作
20091114追加:
ねむいさんがついに重い腰をあげましたの巻
早く座らせてくれ
20091012追加:
電源IC壊れたけどヤクいさんのために気合いで直しましたの巻
20091008追加:
電源ICが壊れて涙目の巻
20091004追加:
STM32 Primer2を使用したアプリ"いないさんと遊ぼう(性的な意味で)"を追加
オレンジのボタンを押して主電源を入れると"Welcome to STM32Primer2!"と喋ってくれ
ます。おお、なんかすげぇ！入力デバイスはおなじみMEMS加速度センサ、そしてPrimer1
には無い4方向キーパッドやタッチパネルなんかもついていたりします。
少し4方向キーパッドがおしづらいです。日本携帯ゲーム機に慣れている方は戸惑うかも〜
タッチパネルは指のほかにもペンタブの先っちょでも使えます。というか画面が小さいので、
ペン入力デバイスをペンタブ売ってるとこで買っといた方がいいでしょう。指でやるとすぐ
指紋だらけになるし。画像はmp3を再生するアプリ。音質はそれなりです。
裏蓋を外したところ。Primer1ではガバガバだった蓋はけっこうかっちり閉まるように
なってます。裏には拡張用コネクタ、リチウム電池、デバッグ用・アプリ用USBコネクタ、
ステレオジャック、MicroSDカードスロットなんかがついてます。カードは別売りです。
基板のRevは1.1です。
表蓋は木ネジで固定されています。結構固いです。壊さないように丁寧にはずしました。
基板表面には部品がいっぱいのってます(はしょるはしょる)。
……おや？何かリワークしたあとが…
細いラインを太いジャンパで補強しています。グランドを強化してる感じです。これは…
調べるとこういう記述がありました。
多分アートワーク設計の時にGNDをただのプルダウンと勘違いして細いライン引いちゃ
ったのでしょうね…それでインピーダンス上がって寄生インダクタンスが出来てしまって
共振して高電圧が出てレギュレータ壊したと…あれ？どっかで聞いたような…まぁいいや…
どっかの基板と違ってちゃんと対策されて出荷されているので安心して使用できます。
むき出しの状態で使用してみる。タッチパネル液晶の発色がきれいですね〜。
STN液晶のPrimer1と比べてみる…視野角が全然違いますね…さすがTFT液晶
おまけ。Primer1の表蓋外したところです。ねむいさんはCQ-STARMだけでもひいこら
言ってるのでPrimer1,2で遊んでる余裕なんて無いと思います。他の方の応用例に
期待をしたいと思います！
この記事を書いて約1年後、時代はmbedを使ったクラウド環境の開発が栄えてしまい、
ふつーに使っただけで電源回路が破壊されるSTM32 Primer2とかすっかり情弱基板
扱いになってしまったのでしたorz
DDT誌のLattice基板で試してたAVR_Coreってあれから…
去年の今頃、私は何をしてたか…確か主人の引き合いで全く関係ない職種(今も兼業で
してるけど)から2Xさいでこの世界に首突っ込んで三相交流とかまだ存在すら知らなくて
"if(hoge=0)"とかお約束のボケかましててUSBaspすげぇぇぇぇぇぇぇぇとかいちいち感心
してたころかしらね･･･
でもまったくの未経験な私でもしっかり飯食わしてくれてるこの業界は素晴らしいとおもうよ！?
でも来年くらいには私はまた違う場所で違う仕事やってるんだろなーともおもう･･･。
少し前にAVR_coreの記事についてコメントいただいたので思い出したようにやりかけて
たのを引っ張り出していじっていました。
以前AVR_Coreで組んだプログラムはごくごく簡単な処理だったのでちゃんと動いている
ように見えましたが、少し複雑な処理(重たい処理)をしだすとすぐコケることが分かり安定
させるための方法を5月以降ず〜〜〜〜〜〜〜っと探っていました。
現時点で分かった致命的なところは、複数の割り込みがかかるような、たとえば送信受信の
リングバッファ組んだシリアルで大量のデータを吐かせながらタイマ割り込み動かしてると
確実に不安定になるという問題で(実機は全く問題なし)、ねむいさんはこれを秘孔と呼んで
現状ではこの状況におちいるのを避けるようにプログラムを組むように心がけてます。
次にAVR_Core本体のコードなのですが…pm_fetch_dec.vhd内のフラグの処理にバグが
あったらしく、opencoresにある最新のものでは修正が入ってましたのでこちらの修正を移植
してます。これやっとかないと割り込みとかなにもかけなくても単にループ回してるだけで
10分に2~3回くらいは"ひでぶ"してたもんで･･･
とりあえず上記2点の考慮で今のところは安定かな？といったものがやっとこできてきたので,
LPC2388基板やSTM32基板でやってたことをAVR_Core上で再現してみました。
ChanさんがぷちFatFsなるものを公開されていたのでこれもついでに盛り込んでます。
以前はROM:8192Byte,RAM:4096Byteとってましたが(ねむいさんの力量では)こんだけ入れると
コードが入りきりません。仕方ないもんでRAMを2kByteに削りROMを16kByteに増強してます。
んで、RAM削ると今度はmega103のスタックの定義が合わなくなってまたべつの問題ががｇ
･･････しかし、よくよく調べてみるとmakefile内でスタックのアドレスを明示してやるだけで
よいことが分かりWinAVR付属のmega103用のリンカスクリプトは一切いじらずにやり過ごす
ことができました。
プログラムの流れは下図のとおり。エレキジャックでおまけに付いてたLM73のルーチンも
ついでなんで突っ込んどきました。
ずっとソフトウエアi2c使ってきたのはもとはと言えばAVR_Coreでi2cデバイス動かしたかった
からと言うのもあります…。決して内蔵レj(ry
VHDLはいまだに"--"くらいしかまともに出来ないけどLatticeの基板でここまで出来たぞー！！
と言うわけで今日のおソース…試される場合は自己責任で…
そうだね基板使い回しだね
きょうのおまけ
ATMEGA32で上のプログラムの再現･･･そうだね使い回しだね
ソフトi2cとmega32内蔵のi2cいずれの方法でもアクセスできるようにしてます。
あとAVR_Coreの予習のためにソフトspi使っています･･･。
こちらに
もう一つおまけ
先日の日記で公開したLPC2388のプログラムの中にLM73のルーチンも突っ込んどきました。
あとRTCの処理に起因するバグ(6月34日とか表示される)と環境によってコンパイル・エラー
になる場所(ST7032i.c & rtc.c内の部分)も修正してますので、真似して試される場合は
前回公開したのはつかわないでなるべくこっちを使ってほしいんだ♥
2電源レベルシフタICを使う
ARMやロジックデバイスの記事(つうか今までほとんどそればっかだ)を書くときは
JTAGKey(の互換回路)のことに触れる機会がとても多くあるのですが、そのたんびに
かみきさんの作例を引用させてもらうのは非常に忍びないので自分でもJTAGkey
互換の回路図起こしました。私が実際にARMやFPGAの書き込み・デバッグの際に
使用しているものです。
以前にも触れたとおり、ほぼかみき氏の物と同じですがなるべくJTAGkeyに似せる
べくEEPROMを外付けにしてVID,PIDを書き換えられるようにしてます。
(これやっとくとOpenOCD使うときいちいちcfg書き換えなくてすむし)
FTDIのドライバEEPROMの設定一式は"おきば"にありますので真似して作られる奇特
な人はそちらも参照のこと。
回路図は配線ミスがないか私のほうで念入りにチェックしてますが、それでも
見落としがあるかもしれません。ご利用の際は自己責任でお願いします。
…やばい、前置きがえらくまともになってしまった…もう疲れてきたよパトラッシュ…
でも後もうチョットだからね待ってていないさん…(ﾊﾟﾀ)
何で長々とJTAGkey互換回路の話ししたかというと、この回路中に信号レベルを変換
できる2電源レベルシフタIC(と5Vトレラントな1,2ゲートロジック)が使われているからで、
これが間に挟まってると1.65V〜5Vの信号までなら異なる信号レベルの問題も
気にすることなく書き込み・デバッグできるからなのです。
で、実際にこれはどの程度使えるものなのかということを検証していきたいと思います。
今回のお題：
上記2電源レベルシフタICを利用したI/Fを用いて、低電圧駆動時のAVRマイコンに
安全かつ確実に書き込みができるかどうかの検証。
実験装備：
１．今回の実験のために特別な回路で特別に動く｢USBaspx改改｣を実験用AVRライタの
ハードウエアとしてこしらえる。V-USBのバージョンアップに合わせて地味に更新中。
２．PC側の制御ソフトはavrspxのVID,PIDの記述を最新のものに
書き換えてリコンパイルした物を使用。
３．テスト用マイコンとしてATTINY2313(rev.C)を使用。試験回路はこちら。
万が一の事態に備えて19.2MHzのクリスタルを装着&使用できる状態にしている。
４．ATTINY2313のヒューズ設定は出荷時のまま。プログラムはIOパタパタさせるだけの
プログラムに、無駄にprintfライブラリのリンクをさせて2kバイトギリギリの容量に調整。
実験内容：
３．の実験用回路に１．のAVRライタを接続し、ライタ側のdelay設定は｢-d5｣にした
状態にて各電圧ごとに｢書き込み｣&｢ベリファイ｣を10回試行し、すべて正常に行えるか
どうかを確認する。
また各試験電圧時のTCKの波形を2電源レベルシフタICの入力・出力について記録しておく。
結果：1CH:レベルシフタ入力 CH2:レベルシフタ出力(測定したのだいぶ前です)
まず3.3Vから。ぜんぜん余裕です。
次に2.5V。まったく問題なし。
目標の1.8V。ぜんぜん余裕でした。波形もきれい。
ちなみに備え付けのクリスタルの駆動(19.2MHzの高速)に切り替えても1.8Vの電源電圧
で正常に書き込み・ベリファイできてます。
まとめ：
●やっぱ専用のレベルシフタはすごいね〜。
●今は通販で容易に手に入るので物怖じせずにどんどん使っていこう。
ＥＸ：
このまま1.8Vよりも電源電圧を下げてくとどうなるのか？
注：危険ですから絶対にまねしないでください!!!!!!
メーカーが保障してない電圧範囲でAVRマイコンの書き込み動作をすると、
以後デバイスが使用できなくなる可能性があります!!!
特にチップリビジョンがB以前のATTINY2313はRSTDISBLを0にしたりSPIENを1に
したりするとパラレルライタでも回復不可能になります！！！！
リビジョンC以降はダイジョブです
結果：
1.6V。まったく余裕ですな。
しかし19.2MHzのクリスタル動作だとここでダウン。以後は内蔵ＲＣ発振で。
1.4V。異常なし。ど根性AVR。がんばれ！がんばれ！
1.2V。何！？まだいけるというのか！？
1.1V。あ、とうとうベリファイエラーでた。でも今までよくがんばった。すごいぞAVR。
1.0V。もはや同期すらできない(-d20とかでもだめ)。内部基準電圧が1.1V(typ)だから
物としてもここが限界でしょう。2電源レベルシフタICの出力波形もかなりなまってます。
しかしこの電圧でもちゃんとレベル変換の仕事はしている。
まとめ：
●がんばったら乾電池一個で動くかもしれないATTINY2313。
●レベルシフタは速度さえ気にしなければ1Vでも動く。
それでは実践行ってみましょうか
LPC2388上のFreeRTOSにUSB-CDC乗っけてみる(だけ)
いつもは最初の段落で本題どころか電気電子とは全っっったく関係ない
話をして検索で飛んできた人の見る気をゴリゴリに削いでいる私ですが
今日は違います。たまには頭っから真面目に工作ものの紹介しますよぅ！
↓デビューしてまだ一月も経ってないのに即レ●プされるi2c液晶の図
…
…ふ〜〜〜…最近全然会ってないけど赤ロリさん元気してるかな…
さて本題、FreeRTOSがLPC2388上でも動作したと以前の日記でふれましたが、
他の方はLANと組み合わせた作例を試されているので、私はUSBデバイスでやってみます。
丁度LPC2388のUSB-CDCを試してたところなのでこいつを組み込ませて動作するか
どうか試しました。
実装の際に懸念されるのは、割り込み周りの処理に関する部分でした。まず、
ビルドを通すために割り込みの処理の部分の記述をFreeRTOSの流儀に変え、サンプル
にあるLANのプログラムを頼りにOSレベルで必要な処理も見よう見まねで加えました。
また、基板もCP2102とLP2388のUSB-CDCが同時に使用できるように改造。同時挿しも
可能なようにしてあります。
結果は…ちゃんと動きました。USBの割り込みの動作も問題なかったようです。
まだ文字列吐かすだけの単純なのですけどね。
USB-CDCを組み込んだFreeRTOSのLPC2388版のソースはこちら。
試される場合は自己責任で…。
zipファイルにも注意書きがありますが、このソース単体ではビルドはできません。
別途FREERTOSのアーカイブを入手する必要があります。
調子に乗ってchanさんのSDカードのアクセスプログラムでもUARTをUSB-CDCに置き換えて
試してみましたがこっちは残念ながらNG。どうやらシリアルとOLEDの出力関数を切り替え
る部分？であっちの世界に逝っちゃってるぽいですが、現段階では調査中です。
USB-CDC版でもちゃんと動きました。
LPC2388のCDC(仮想COMポート)を使う
１週間前、臨時収入が入りましたので今まで購入したいと思っていた電子部品
や評価基板をいくつか注文しちゃいました。夏物の服は「茄子」が入って
バーゲンになって値段下がってからでいいや。それまでに売れてくれるなよ…！
…そのまえに今年茄子あるかな…。
少し前にLPC2388にあるUSBホストのサンプルの追実験をしましたが、USBターゲット
を含めたサンプルコード集もNXPのサイトで提供されてます。コード集にはUSB-CDC
(仮想COMポート)の作例もあってRTCやUARTは簡単にできたので次はこいつを
ポーティングしてやろうと画策しました。
…しかし、これのUSB-CDCのは割り込みや構造体の定義がGCCとの互換性が
全くと言っていいほど無くてコードをポーティングするのが一苦労。しかもコンパイル
無理やり通してバイナリ焼き込んでも案の定動作できねぇ！！１！
XPでUSBデバイスを認識したときのあの｢♪ﾃｺﾝ」が鳴ってくれない…
結局２〜３日格闘して私のぎじゅつ力じゃこれ以上は無理と白旗上げてしまいました。
(ネットの記事漁るとちゃんと出来てる人もいるみたいです…くやしい…でも…)
なんかよい情報はないものかと海外のLPC2000のフォーラム等をいろいろあたると
GCCでソースが公開されているLPCUSBなる物があることを知り、これを叩き台にして
LPC2388向けのUSB-CDCデバイスをこしらえることに。
もともとはLPC2143用だったみたいですが、数年前にLPC2378向けにも使えるようにアップ
デートされていて、大きな変更もなくLPC2388基板で無事｢♪ﾃｺﾝ」を聞くことができました。
その後はSTM32とおんなじようにprintf使えるようにリターゲットして、以前のRTCの
サンプルのCDC版が動くとこまで確認。
懸念してたUSBの動作と他の複数の割り込みの動作の干渉も特に問題ないみたいです。
とりあえずLPC2388上で"動く"とこまで持ってけましたが、"どのようにしてUSBデバイス
として動いてるか"の理解ができないとこっから先はやってけないと感じてます。
点と線だけで繋いでいた知識のリンクを面で囲っていけるようにしたいです。
私のおべんきょはさらにつづく…。
というわけで本日のおソース。試される場合は自己責任で…。
TFT−LCD表示プログラムのUART処理部に統合しました。
ねむいさん向けにかなりいじくり倒してるので、本格的にされる方は本家の
ソース当たった方がいいと思います。
いろいろ試す…
ブログ始めて1月ほど経とうとしています。書いてる記事はARM系が多いのですが、
このブログのヒットカウントの稼ぎ頭が以前少し触れたJTAGkey(の互換回路)の紹介と、
JTAGkeyとUrJTAGを使ってDDT誌のLattice基板へ書き込むの記事だったりします。
まぁ私がブログの記事をメモ帳代わりにして参照してるのでこのページカウント
だけ多いといったら当然なんですけど…そんな私のブログへの一番のリピーターさんは
googlebotさんだったりするorz
ううむ…もうちっと真面目に書くか…あーでも来週1週間は二次裏での活動に
集中したいしなぁ…困った…
話変わって、LPC2388の基板でできる事柄の追実験を私もいくつか行いましたの
で紹介します。まぁいわゆる他人のふんどしです。
●FreeRTOSを載せる
OS乗っけることによる恩恵って何なのでしょうかと自問自答する私。
そのまえにOSとはどういうものか、どのようにして動かすのか/動くのか等の
おべんきょが必要な段階です…山の頂上は遠い。
後閑氏のFreeRTOSの解説ページとFreeRTOSの公式サイトで配布されてるZIP中に
あるLPC2468用のデモを頼りにLPC2388の物に移植してみたところ、
先に作成したLPC2388用のファイルを組み込むだけであっさり動きました。
リンカスクリプトの修正もLPC2388用のアドレスに差し替え以外は特に
大きな変更もなくprintf/sprintf等の標準関数が使えてます。
時間の空きを見てこのOSの仕組みやOS使用時の定石等を覚えていきたいと思います。
そういやLPC2388のエラッタでPLLが300MHz以上だったかは動かないとか
言う記述がありますね。私が買ったのすべてチップrev.Bでエラッタの範囲外
なので高めに設定してます。
雑誌の付録は多分みんなrev.Bだから大丈夫だとは思うけど…
(雑誌記事等のPLLてやけに低めに設定されてたのはここら辺の理由ね…)
ARM7_LPC2388_xxxxxxxx.zip 試される場合は自己責任でどうぞ。
●USBHostLiteを使ってみる
くんくん氏がGCC環境にてUSBHostLiteを使いやすくした形で公開されていましたので
こちらを使わせていただきました。前回の日記のをベースにUSBHostLiteのプロ
グラムを付け足す形で作成してます。ターミナルから「u」もしくは「U」を打つと接続
されたUSBメモリにアクセスを試みる形にしました。ちゃんと読み書きできていれば
適宜メッセージが表示されます。こんな感じでうまくいけてます。
現在の外観はこんな感じです。サクサク書き込み&デバッグができるJTAGkey大活躍です。
左下に見えるLatticeの基板はAVR_Core使ってSDカード読めるところまでいってますが…
まだまだ初歩の段階です。こっちはいまだ手探りです。
●ChanさんのMCIアクセスプログラムを試す。
LPC2388用の拡張子基板がボリ松若松通商から発売されていますがSDの読み書きを
試すだけに6000円ペイするのは(趣味であっても無駄な所に金を落とすのは)
できなかったので残り物かき集めてSDカードのインターフェースだけこしらえました。
自分で作ると200円。基板組むのに25分ほど。さほど負担にはなりません。
イーサネット用の回路も自作に頼ることになるでしょうね。
プログラムはchanさんのWinARM20060606用のコードをCodeSourceryでコンパイル
できるようにmakefileを書き替えただけで後はコピペしただけで難なく動作して
しまいました。
RTCの時刻情報を反映できるような付加機能とかができたら公開したいと思います。
STM32の基板にもRTCとこいんでんちいっこいれる
ｺﾞﾄｯ
これはUSBのJTAGデバイスの普及間違いなしですね〜
いい時代になったものです…私はもう作ったからいいや(しれっと
昨日はLPC2388の基板にRTCとバックアップ用の電池付けましたが、STM32にも
同じ事やってみました。STM32もLPC2388と同じくVbatでバックアップできる
独立したパワードメインがあるのでコイン電池一個でRTCを動かせます。
CQ-STARMはVbatはジャンパ抵抗で切り離せられるようになっているので
改造も楽ちんです(他のリワークがきついけど)。こんな感じで各部品を実装です。
RTCのプログラムのサンプル
のプログラムをベースにRTC部分の割り込みと、UARTの受信割り込みを足しこんで
昨日のLPC2388のプログラムになるべく似せるようにしてます。
(どっちかと言うとSTMのがオリジナルなんだけどまぁいいや)
自己責任でどうぞ。あと32.768KHzの水晶は必ずつけるように！
ARM7TDMIに並行してCortexも本格的に覚えようかしら…ブログで公開するに
当たって深いとこまでいじって来たけどなかなか面白い。
明日絶対に筋肉痛になるな…
注！最悪PCまでつぶれるので真似しないでください
今回のお題
IF誌5月号付録LPC2388基板に品質の悪いUSBケーブルを使用して接続すると
接続した瞬間に発生する高電圧で基板上のレギュレータを壊してしまう件の検証。
また、発生する高電圧を抑制して壊れないようにする対策の効果の検証。
IF誌が同時に勧めているショットキダイオードは上記現象とはあんまし関係ない
ので今回は付けない。
追：
simさんちのコメントで関係がない割には妙に事情に詳しい人が弁解をされておりました。
dv/dtのコントロールが出来てない回路では突入電流で過電圧が発生して素子が
破損するリスクがあるなんてのは聖闘士にとってはもはや常識中の常識です。
それ以前に誤植や思い込みによる間違いが多過ぎでCQ出版はひどすぎです。
実験装備：
１．CQ-FRK-NXPARM(IF誌5月号付録LPC2388基板)。
２．品質の悪いUSBケーブルとやらがないので
USB2.0のA-B1mを一本,USB2.0の5m延長2本使って合計11mの規格オーバーの
ケーブルを用意。(ケーブル組成はすべてVCC&GND:AWG24、D+&D-:AWG26
っぽいです。)
３．2012サイズ、X5R,16V,10uFのチップ積層セラミックコンデンサ(MLCC)
USBの規格上VCCにぶら下げられるキャパシタ容量上限が10uFだから
これ選びました。
実験内容：
LPC2388基板とUSBコネクタをズボズボしたときの+5Vの電圧をオシロで観察する。
上記３．のコンデンサをうまく実装して同じことをする。
左下にコイン電池みたいな物体が見えるけど気にしないでください。
結果：(測定したのだいぶ前です)
コンデンサない時
コンデンサある時
考察：
It's groovy...
じゃなくて確かに電源の立ち上がりでオーバーシュートして一瞬ですが耐圧
オーバーしてますね。憶測ですが元からあるレギュレータの入力コンデンサの
CとUSBケーブルのLでちょうど共振しちゃっているのでしょうかね。
(電源立ち上がりの時定数が早すぎるとか??PID制御思い出した)
10uFぶら下げてやると水を打ったように電源の立ち上がりがなだらかになります。
対策は上手くいっているようです。
あと、わかっているとは思いますが、なだらかになるからと言ってむやみ
やたらに220uFとかでかいコンデンサ付けると今度は突入電流でUSBのホスト側が
過電流と認識してUSBデバイスを認識させなかったり最悪+5VUSBが大きく
ドロップしてマザボごと強制リセットとか憂き目にあいますのでUSBの規格に
従いましょうね。
ねむいさん的にはレギュレータの問題よりもVbatがVccに直けｔ(ry
EX:
私が出せる全力スピードでUSBコネクタを激しくズボズボする。
それはもう200回くらい。もちろんコンデンサは実装しない状態で。
結果:
レギュレータは全くの無傷。今日も元気に3.3Vを生成しています。
腕が攣った。
基板側の¥120で買ったUSBリセプタクルがｶﾞ●ｶﾞ●ﾏ●ｺｲになったので付け替えた。
考察:
(今日の日記のタイトル)
VCP(仮想COMポート)DEMOを動かす
SkyDriveにうｐしたソースコードのファイルのURLが全部別のに
変更されていた！少し前に仕様が変わって10MB以下のファイルでも
直リン不可になってしまっていたらしいorz
人が見に来るようになる前にソースのダウンロード先だけは
確実に落とせるように変更しておきました。(←うつけ)
幸い画像の直リンはまだ出来るみたいだから画像の処置は様子見ですよぅ。
20190714追:
OneDriveになってPublicフォルダすらなくなりやがりましたFUCK!!!
マイコン使って仮想COMポートを実現する…今ではいろんな手法があります。
tiny45などのAVR使って簡易なCDCなんかもできたりしていやはや
すごいな〜なんて。CQ-STARMに乗っかってる石にもUSBのインタフェ
ースがサポートされてるので当然のごとく仮想COMポート(以下VCP)の
デモなんか用意されてるわけですが…
これがなぁ…コンパイラのバージョンにシビアでコンパイルすら通らなか
ったり通ってもwarningわんさか出たりそれ潰してフラッシュしてUSBが認
識された！と喜んだのもつかの間ポート開いた瞬間に固まったりでもう一回
warningで出てたとこ穴のあくほど見て修正してやった開いた！と思ったら
今度は文字が送信出来てなくてもう一回ソースや海外の掲示板の投稿を穴
のあくほど見てまわりまわった挙句結局最適化のせいだとわかって修正し
てやっとこ使える代物になれたかなでも所詮はDEMOだと言ってしまえば
それで終わりですがそう言い切るのもなんだかな…あーつかれた。
いかんまた前振りが長い。
20110129追:
107系のUSB-OTGの物とソースを一本化し、なおかつエンドポイント３をダブルバッファリング
にしてさらに大量のデータを受信したときに取りこぼすバグを修正しました。こちらからどうぞ。
おソースはこちらです。USBライブラリV3.1.0のデモを適用してます。
上で長々と書いた私の無駄な努力が修正されています。
(どうやらV3.0.0でもまだ不具合あったみたいですねorz）
20101221追：
今気づいたけどダブルバッファリング化して動作をさらに安定化させたverにふつー
のバグ満載verを上書きした状態で放置してました。でもローカルのソースも破棄して
残してないからもう修正できないやごめんね(ﾃﾍｯ♥
でもこのV3.X.X系ってライブラリの構成が大幅に変わってますね。
調べてみるとこの規格に合わせたといったところでしょうか。
てかこれだいぶ前の情報じゃないか…。
ねむいさんの知識は断片的で非常に危ういです。日々お勉強はつづきます。
あと私が使いやすいように独自の修正加えてます(これまで
公開したのもほとんど私仕様にしちゃったけど)。"Nemui"でコードを
サーチすると何やってるか分かると思いますが、重要なのを一つ。
void Virtual_Com_Port_init()関数開始直後にあるGet_SerialNum();
をコメントアウトしてUSBシリアルナンバを"STM3210"固定にしてます。
どうもこの関数がとってくるユニークIDとやらがうまくシリアルナンバを
反映してくれない。他のUSBデバイスだとあまり気にならないのですがVCPは
COMポートが増設され、違うUSBポートにさすごとにどんどんCOMポートが
増殖していくのでシリアルを固定にしてそれを防がなくてはなりません。
(多分うまくやる方法があるんでしょうけどね、現状はこれで満足…)
以下ねむいさん流仮想COMポートの消し方(WinXP32bit用)
１．提供された仮想COMドライバにアンインストーラがあれば
それを使用する。
２．１．が無い場合、
環境変数に画像の変数を追加する
変数名:DEVMGR_SHOW_NONPRESENT_DEVICES
変数値:1
３．パソコンを再起動。
４．ファイル名を指定して実行で"COMPMGMT.MSC"と入力、実行。
５．「デバイスマネージャ」を選択し、ウインドウの表示(V)をクリック。
６．プルダウンメニューの「非表示のデバイスを表示」をクリック。
７．「デバイスマネージャ」-> ポート(COMとLPT)をクリックすると
半透明のCOMポートが見える。不透明は現在物理的に繋がっているデバイス。
８．「削除」で憎いあいつを消す！これでCOMポートが消えます。
でも何度も言いますが提供された仮想COMドライバにアンインストーラが
あれば必ずそれを使用しましょうね。
９．たまにB.S.O.D.になって泣く
JTAGkeyClone(FT2232系JTAG I/F)製作のすすめ
20130521追:
FT2232系デバイスを用いたJTAGKey/JTAGKey2製作に関しては
こちらを参照してください！
お仕事の方でサーボモータのおべんきょを一からしてます。
そもそもねむいさんは4年制大学を卒業したにもかかわらず就職氷河期の下、
20代後半まで介●の仕事をしながら本業の虹裏メイドをしていたので電気の分野は
ほぼ一からおべんきょなのですが、私の場合は元主人が遺したARMマイコンに
関するリソースが最初から大量にあったのでARMマイコンに関しては強くて
ニューゲーム状態だったのです。
とはいえまったくのどしろうとでもべんきょうさせてもらえながらちゃんとしごともさせて
もらえてさらにおきゅうりょうまでもらえるくみこみぎょうかいってすごいとおもいます。
ちなみにねむいさんのほんしょくのにじうらめいどはちょうぜつぶらっくでにんきのない
めいどは｢｣たちにすぐよごれきゃらのきゃらづけをされてあらしのどうぐにされてすてら
れるというれつあくかんきょうなうえにおきゅうりょうがはなくそていどしかもらえません。
ふぁっくです。
きょうのにっきおしまい。
…真面目に読んでしまった人すみません、続行します。
以前はJTAGの制御といえばPCのLPTポートに少しばかりのロジックデバイス、
おもに信号レベル変換のバッファが乗った回路を接続してI/O直叩きで制御
ってのが主流でしたよね。CPLD/FPGAを提供している各社もLPT接続タイプの
書き込みケーブルの回路を公開していて、趣味で開発やっている人も自作が
容易にできていました。
時は流れ、いまどきのナウでヤングでスタイリッシュなPCにLPTポートなんて
時代遅れのものは搭載されなくなり、代わりにUSB接続のダウンロード
ケーブルがメーカから提供されるようになりました。
しかし、USBのそれは各社のノウハウになっていて真似して自作できる
代物ではなくなってしまいました。
しかも安くても３諭吉くらいしてホビー用途には手が出しづらい。
しかしながら数年前くらいからFT2232等のJTAGのライブラリが
サポートされるデバイスが出てきて有志の人たちがフリーで多目的に
使用できるアプリケーションを作られてきました。
そのFT2232を使用したJTAGハードウエアで有名なのがAmontec JTAG keyですね。
容易に自作できるのでFT2232系は上記を含め多くの派生があります。それを通じて
ARMマイコン等のJTAGポートを備えたデバイスにアクセスできる(フリーで使える)
PC側のソフトは、OpenOCD、UrJTAG等などたくさんあります。
先の日記で何度か言及してますが、私もかみき氏の作例をベースに一つ
作成しました。2電源レベルシフタがミソです。氏の回路と違う点は、ターゲットに
電源供給する回路を廃したことと、外付けEEPROM(AT93C66A)の回路を追加して
Amontec JTAG keyに化かすことを目的としました。
自分自身の学習の意も含め、かみき氏互換のJTAGkeyCloneの回路図を起こしました。JTAGkey2Cloneに関してはこちらをご参照ください。
また、JTAGkeyCloneに化かすためのeepromのデータですが、こちらにある
JTAGKey用のデバイスドライバのZIPファイルを展開するとJTAGKey_eepData
というフォルダがあります。この中にあるamontecJTAGKey.eptというファイルを
MProgで読み込んでeepromに書き込んでください。
もちろんEEPROMの書き込みの際は先にFTDIのドライバをインストールして
おかなければなりません。
これは先のZIPファイル内のftd2xxというフォルダにあります。
20130521追:
JTAGKey/JTAGKey2製作に関してはこちらを参照してください！
以下JTAGkey互換回路を制御できるアプリの使用時の画面とかを。
詳しい使用記は以後の日記で幾つかをぽつぽつと。
IF誌付録LPC2388基板にOpenOCD+insightでデバッグ
asagaoでDWM誌2008年9月号付録のColdFire基板のEzPort経由のプログラム書き換え
OpenOCDで秋月ARM基板のRAMスタート
UrJTAGのSVF機能でDDT誌付録のLatticeXP2基板を高速にコンフィグ
fenrir氏作成のcblsrvのFT2232対応版を使用してxilinx IMPACTからコンフィグ
(注：fenrir氏によってISE11.x以降でも使えるようになりました！)
そして本懐のamtsvfplayerでSVFを再生…できねぇ！
20120215追:
amtxhal.dllはグルーロジック(非公開)が組まれたPORTB側のDS2432という
EEPROMに仕込まれたキー情報も読みに行っているのでクローンの場合は
amtxhal.dllを使用するプログラムは一切使えなくなります…が
amtsvfplayerくらいしか使われてるの見たことないのでJTAGkeyCloneでも
それ以外の用途では全く問題はありません。
JTAGkey系のCloneでsvf使いたいならUrJTAGを使いましょう。
STM32にJTAG経由でDFUを書き込む
20121108追：
内容がものすごく古てもう実用に耐えない内容なのでこちらを参照してください。
STM32に限らず普遍的な内容を網羅してあります。
急に冷え込みましたね…えっくし
あの子は今寒さに凍えて体を冷やしていないだろうか…？
…温めてやれないのでしんぱいです。
ARM系のCPUでJTAG経由のフラッシュプログラミング方法なんて
巷にものすごく詳しく解説付きであふれてるので、ねむいさん的には
皆さんに全く参考にならない方法を紹介していきたいと思います。
20120517追：
レガシーポートを使用する方法はもうお勧めできません！
●レガシーなLPT経由の方法
私はM570RUのユーザーです。こいつにはLPTなんてレガシーなもの存在
しません。じゃぁどうやってやんだよ！というとExpressCard接続のLPT拡張ユニット
をつかってLPTポートを"物理的に"設けます。昔ながらのIOポート直叩きができます♥
認識されるとこんな感じ。しかし！エクスプレスカード=PCIExpress接続の拡張
LPTなので物理アドレスがいつもの0x378とかじゃなく0x3CD8とかへんてこりんな場所に
置かれます。もちろん0x378にアドレスの変更なんてできませんでしたorz
(物理アドレスもらえるだけマシだが…)
というわけで使えるアプリケーションは限られます。H-JTAGというJTAGサーバー
を提供するソフトは0x3CD8でも設定可能なのでこれが使えます。
LPT接続用のJTAGインターフェースの回路図はこちら。Wiggler互換です。
なんでJTAGのコネクタをわざわざ10Pinから20Pinに変換してるのかというと、
AVRJTAGICE/JTAGICE mk2とALTERAのJTAGインターフェースがこの10Pinの配列で、
ねむいさん的にはこれを基準としてすべての制作物を合わせているからです。
ARMしか使わない人は元から20Pinでいくか各自のやりやすい配置で行きましょう。
H-JTAGの基本設定はこんな 感じに してください。
実はWiggler互換じゃなくてもLPTにつながりゃ何でも行ける。
Coretx-M3専用のTAPコントローラの設定は必ず行うこと。
そして難なく認識。
書き込み消去もほとんどストレスなくサクサク行けます。
話変わりますが、なひたふ氏のMITOUJTAG評価版0.31&トラ技特別版は
上記の拡張LPTは一切使用不可でした。0x378,0x3BC,0x278の物理アドレス
しかサポートしてないみたいです。残念。(まぁ評価版だし…)
ちなみにlinuxのioperm()関数とかもサポートするアドレスの範囲が
0x3ffまでなのでそれ使ってる直叩き出来るアプリも全滅。全アドレスに
使えるiopl()関数に適宜書き替えてやる必要性があります。
●USB(JTAGkey互換回路)経由の方法
アマチュアのARM開発ではこちらが今現在最もポピュラーな方法ですね〜。
私のM570RUでもこれならスマートかつ無問題です。
(なぜかM570RUは物理COMポートがある。Linuxのデバッグ出力用だろうか？)。
先にも紹介しましたJTAGkey互換回路はかみき氏のものを流用させてもらって
います。扱える電源電圧範囲が1.65V〜5Vとだだっ広いです。
+5Vトレラントな2電源レベルシフタのおかげなのですが、JTAGkey単体の評価や
レベルシフタの実力は別件で測ってますのでまた後ほどにでも。
また、かみき氏の回路にAT93C66Aの外付けEEPROM回路をさらに追加して、
Amontec JTAG keyと全く同じVIDとPIDにしています。EEPROMの設定を含めた
ドライバファイルはこちらに。MProgで書き込んでください。
STM32基板との接続も最もポピュラーな構成を流用しています。
STM32(というかARM全般)--JTAGkey互換(FT2232レイヤ)--OpenOCD(server)という
つなげ方です。
20120517追：
OpenOCDを使用した内蔵フラッシュの書き込みはこちらを参照にしてください。
前振り長くなりましたが、DFU(DeviceFirmWare)をJTAGkey互換回路で
STM32に書いてみます。,今回のおソースはこちら。最新のSTM32-USBファーム
ウエアライブラリとDFUのデモソフトウエアを適用してます。わかっているとは
思いますけど試される時は自己責任でよろしくお願いします。
開始アドレスは0x08000000固定です。makefike内で0x08003000開始も設定
できますけど当然動きません。気を付けてください。
新しいDFUをJTAG経由で書きこんで見ます。成功したときのログは
以下のようになります。STM32はJTAGデバイスが2つ見えます。
> "C:¥Devz¥AVR¥WinAVR¥utils¥bin¥make.exe" program
openocd-ftd2xx -f interface/jtagkey.cfg -f target/stm32_flash.cfg -c "flasher main.elf" -c "resume" -c shutdown
Open On-Chip Debugger 0.2.0-in-development (2009-05-09-21:00) svn:1606M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
500 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched
Warn : no telnet port specified, using default port 4444
Warn : no gdb port specified, using default port 3333
Warn : no tcl port specified, using default port 6666
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000ed8
Info : device id = 0x20016410
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
Warn : not enough working area available(requested 16384, free 16336)
wrote 8508 byte from file main.elf in 0.640630s (12.969411 kb/s)
verified 8508 bytes in 0.437502s
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020, Part: 0x6410, Version: 0x1)
Info : JTAG Tap/device matched
> Process Exit Code: 0
> Time Taken: 00:05DFUが正しく書きこまれていれば、DFUseを起動するとこの画面が見えるはずです。
これでJTAGさえあればDFU書き潰して0x08000000でスタートするプログラム
書きこんでも大丈夫ですね。…と言いたいところですが！
STM32のコアクロックが停止する__WFI命令等を実行しっぱなしの
プログラムを不用意に書きこんでしまうと起動->__WFIでクロック停止->JTAG
インターフェースも仲良くおだんまりとなってJTAG経由のアクセスが
一切できなくなってしまいます!
これを回復するには先日紹介したシステムメモリからのブートでシリアル
経由でフラッシュの消去を一旦行うか、リセットボタン連打しながらJTAG経由で
うまく引っかかるまでひたすら消去動作を行い続ける方法があります
(ファミコンの裏ワザみたいだ)。私としては
STM32のフラッシュプログラミング
当記事の内容はもう古すぎるのでこちらを参照してください。
…あづい…あづいですね…まだ５月なのに〜…
まぁおかげでバイト帰りのいなちゃんの汗ｎ
CQ-STARMは最初からUSB経由でファームウエアのアップロードができる
DFUというプログラムが書きこまれているため、外部のプログラマーが
必要ないのが特徴です。
その代り、開発に際してプログラム開始位置は0x08000000->0x08003000
からになる。という制約を受けます。
DFUを使用してアプリケーションを作るときは、0x08003000からプログラムが
スタートするように考慮しなければなりません。DFUのプログラムは
0x08003000に決め打ちですっ飛んで行きますので。
(この辺AVRだと楽なんですよね〜、ブート領域がメモリの後方にあって
ヒューズビットでいつでもスイッチできるからアプリの方はプログラム
メモリ容量以外は何も考えなくていいという)
考慮の方法は以下の2点です。
１．ソースコード内の割り込みベクタのアドレスを
0x08000000->0x08003000にする。
２．リンカスクリプト内のスタートアドレスを
0x08000000->0x08003000にする。
デバッグはDFU経由で書いて本ちゃんはまっさらからスタートしたい、
もしくはDFUなんていらんという人もいるでしょう。そういう時こんなの
いちいち書き変えてたらめんどいのでmakefileの記述で一発で切り替え
できるようにしちゃいましょう。
１．の部分、こんな感じで
２．の部分、ここをこうして
最後にmakeで切り替えられるようにする
と後あと楽です。ケアレスミスもなくなりますし。
以前のMassStorageClassDemoにもこれを適用していますので詳しくはこちらをご参照ください。
(欲しい人メールくだち)
ちなみにCQ-STARMでDFUを使う場合、USBディスコネクトの回路を追加して
いると「Leave DFU mode」が正しく動くようになります…ってこれが当たり前か。
DFUなぞ使わないという人にはJTAGで書く方法とシリアルで書く方法が
あります。今回はシリアルで書く方法を紹介します。JTAGは次回にでも。
STM32はオンチップフラッシュROM、オンチップSRAM、オンチップのシステム
メモリの3種のブートモードをサポートしていて,DFUや通常のアプリは
フラッシュROM、RAMスタート時はオンチップSRAM、そしてSERIAL経由で
STM32のフラッシュを書き換えたい時はシステムメモリからの起動を選択できます。
JTAGあるしシリアルなんていらんジャンなんていう人もいると思いますが、
変なプログラムを書きこんでしまってJTAGが一切アクセス不可能に陥った
場合、強力な回復手段となるので、このモードがあるというくらいは
覚えておいてくださいね。
私はフラッシュ、システムメモリの2つのブートモードが選択できる
ように拡張基板にタクトスイッチを追加しました。どことどこを繋ぐかはこんなかんじで〜
シリアルは、USB-SERIAL変換のICしか使う気がないのでレベル変換かまさ
ずにTTLレベルのままで置いときました。
USB-SERIALのユニットはCP2102使って、TTLレベルでRxD,TxD,GNDの３つだけ
しか使わない凄く小さいのを一つ作っておくと使い回しが効いて楽です。
用意ができたらBOOT0をVCCに吊ったままリセットを解除してシステムメモリ
からの起動を行います。その後PCにインストールしたFlashLoaderDemonstratorを起動します。USB-SERIALが繋がってる仮想COMポートを選択し、正常に通信ができていれば
こういう画面になります。そっからはフラッシュを消したり読んだり
書き替えたりプロテクト掛けたりと自由自在です。
CQ-STARMを仮想COMポートに化かしてももちろん行けます。基板2つもってる人は
一方を仮想COMポートにして試してみるよいでしょう。
MassStorageClass DEMOを動かす
最近工作ものばっかに手を取られて本業の二次裏メイド業が
おろそかになってる私。下描きでほったらかしているいないさんの絵が
早く仕上げてと訴えている。もうちょっと待っててね♥
さて本題、てDWM誌2008年5月号の付属基板と同梱のCDには
DFU経由でCQ-STARM基板に書き込みができるように
いくつかのデモがすぐに使えるようにとdfuファイル形式で
入っていました。しかし、紙面の説明がとても乏しく、そのとおりに
やっても動かない云々の意見と(その対策)が出ていたのは
みなさんご承知のとおりと思います。
この同梱されたdfuファイルというのはCQ-STARM向けではなく
STマイクロが提供する評価キットSTM3210B-EVAL/STM3210E-EVAL
向けのものです。
CQ-STARMはSTM3210B-EVALの回路構成を真似て設計されており、
STM3210B-EVAL向けのdfuデモファイル群も一応動くのですが、
その中でMassStorageClassの奴をそのまま使ってしまうと
ちょっとまずいことが起こります。
CQ-STARM上ではSDカードを挿入したときに必ずLになるポート
が出力になっており、ショートしてCPUおよびSDカードに
ダメージが行きます。どうなってるかはここ見てくださいね。
この件も私が見つけたわけではなく、去年すでに騒がれたこと
なのですが、忘れ去られた頃に新たにCQ-STARMに触る人がいる
かもしれないから書き残しておきます。
以下私が行ったわーくあらうんど。
●ソフトウエア
初期のデモでは確かSTM3210B-EVAL上のLED４つが同時点灯するという
コードのようでしたがV3.0.0/V3.0.1のデモコード見ると最小限のLEDのポートが
出力になるようになってました。前回のコードはV3.0.0を適用してあるので
そっちを使ってもらえればいいかなと思います。
LEDの出力もCQ-STARMに合わせて変えてます。でも下のパタンカットは必須ですよ！
●ハードウエア
STM3210B-EVALは本来MicroSD搭載なのでライトプロテクトと挿入検知は
存在しない。だからここにつながるパタンいらないからカット！
こんな感じで。
ついでだから他の便利な改造も基板に施してますので紹介します。
●USBディスコネクト
USBのデモにはRESETをかけるとUSBが切り離される"USBディスコネクト"
のコードが含まれているのですが、CQ-STARMはハード的に駆動させるための回路
が存在しません。したがってDFUで書いてはUSBケーブル抜きを繰り返す
必要があり非常にめどいです。だからこの部分を追加。
具体的な改造はこんな感じ。パタンカットもなくビアとポリイミド
テープを駆使してなんなく達成。これでUSB-miniBコネクタが激しい抜き差しで
ｶﾞﾊﾞｶﾞﾊﾞになるのを避けられます。
●加速度センサにコンデンサ追加
加速度センサ周りに10uFのチップセラコンと1nFのチップセラコンを追加する。
これは加速度センサの指示ですね。つうか本来はじっそうすべきなのですがなぜか
この基板を設計した人はそれを無視して動作不安定になるような回路設計を
してらっしゃいます。
10uFのチップセラコンは+3.3V系以下の系では秋月のこれを愛用してます。
こいつは2012サイズなのに大容量でかつ静電容量変化率も少ないので、
セラミックコンデンサ対応のLDOとも相性バッチリです。
1nFのチップセラコンは1608のをビアと近接のGNDパタンはがして実装。
10uFの方は元の1uFは一旦どいてもらってポリイミドでガードした上
に仲良く同居。こんな感じで。
使ってみた感じですが、わたしの手持ちの256Mb,512MB,1GB,2GBはすべて
Windows上のディスクドライブとして認識、読み書きもできました。
残念ながらSDHCはファームウエアで対応しておらず認識できないようです。
Project Examples and Misc Files
ねむいさん専用のFatFs中心のサンプルコード・プログラム置場です。
私が使いやすいようにGCC環境に勝手にポーティング&改造してあります。
文書の記述間違い・バグを見つけた場合は勝手に修正しています。
太字のリンクは更新頻度高。試される場合は自己責任でお願いします。
Dear All
Here is my ChaN's FatFs implementation examples.
Those projects are suitable to build in GNU-GCC environment.
If you have any question,see here to contact me.
●ARM
(Confirmed on 64bit Win7,8,10,11 by ARM-GCC)
ビルドの仕方はこちら
Building Method on Native Windows Environment is Here.
-Cortex-M7
STM32H7xx(STM32H747I-Discovery supported!)
(CubeH7:V1.12.0/HAL:V1.11.5)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32F7xx(STM32F769I/746G-Discovery supported!)
(CubeF7:V1.15.0/HAL:V1.2.9)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M33
STM32H5xx(STM32H563ZI-NUCLEO supported!)
(CubeH5:V1.1.0/HAL:V1.1.0)
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
STM32L5xx(STM32L552ZE-Q-NUCLEO supported!)
(CubeL5:V1.5.0/HAL:V1.5.0)
20250501更新停止
(+ libjpeg,libpng and giflib decode example)
*SPI-TFT Control Example with ChaN's FatFs(SDMMC-Interface)
It supports SDXC and eMMC!
-Cortex-M4F
STM32F4(STM32F407ZGT6/PowerAVR-RedBull Compatible Circuit
& STM32F437IIT6/盈钰電子STM32F4xxIxT6开发板互換
& STM32F407VGT6/STM32F4Discovery
& STM32F429ZIT6/STM32F429I-Discovery are also supported!)
(FWLib:V1.8.0)
(+ HelixMP3/AAC,libjpeg,libpng and giflib decode example)
*TFT/OLED Control Sample with ChaN's FatFs(SDIO&SPI-Interface)
It supports SDXC and eMMC!
STM32F401xx(STM32F401RET6/NUCLEO-F401RE Compatible Circuit)
(CubeF4:V1.24.1/HAL:V1.7.6)
*KickStart & I2C-LCD/OLED and many Devices example
STM32F334(STM32F334R8T6/NUCLEO-F334R8 Compatible Circuit)
(CubeF3:V1.11.0/HAL:V1.5.3)
*KickStart & I2C-LCD/OLED many Devices examples!
LPC4088(LPC4088/EA4088 Board Semi-Compatible Circuit)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4357(盈钰電子LPC4357开发板互換)
*ChaN's FatFs Sample(SDMMC-Interface)
It supports SDXC and eMMC!
LPC4330(LPC4330-Xplorer Compatible Circuit)
20150912更新停止
*Dual/SingleCore-KickStart
LM4F120H5QR(Stellaris Launchpad Compatible)
20150912更新停止
*KickStart
-Cortex-M4
K20(MK20DX32VLF5)(Bare-Metal)
*KickStart
-Cortex-M3
STM32F103(STM32F103VET6/STM32 Primer2)
(FWLib:V3.6.1 ,USBLib:V4.0.0 ,
FatFs STM32F1 SDIO-Interface Imprementation)
*Bare-Metal GPS & GNSS-Tracker using ChaN's FatFs
EFM32TG822F32(Bare-Metal for TinyGecko)
*LED-Blink & UART
LPC13xx(LPC1347/LPCXPresso Compatible Circuit)
20150912更新停止
*KickStart
STM32F2(STM32F207ZGT6/PowerAVR-RedBull Compatible Circuit)
20150912更新停止
(FWLib:V1.1.2)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SDIO-Interface)
STM32F107(STM32F107VCT6/CQ-STARM-JUNKBOARD Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1 ,USBLib:V4.0.0)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
STM32VL(STM32F100RBT6/STM32VL-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V3.6.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32VL SPI-Interface)
STM32L(STM32L152RBT6/STM32L-Discovery Compatible Circuit)
20150912更新停止
(FWLib:V1.1.1)
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(STM32L SPI-Interface)
MB9BF618T(FRK-FM3-GARBAGEBOARD Compatible Circuit)
20150924更新停止
*(Deprecated) LED-Blink & UART
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MFS SPI-Interface)
MB9AF112K(Bare-Metal)
20150912更新停止
*(Deprecated) LED-Blink & UART
LPC177x/8x(LPC1788/EA1788 Board Semi-Compatible Circuit)
20160331更新停止
*(Deprecated) ChaN's FatFs Sample(MCI-Interface)
-Cortex-M0+
STM32U083xx
(STM32U083RCT6-NUCLEO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32C031xx/STM32C011xx
(STM32C031C6-NUCLEO/STM32C011XX-DK Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
STM32G03xxx(STM32G0316-DISCO Compatible Circuit)
*KickStart & I2C-LCD/OLED and many Devices examples!
LPC824(LPC824/LPCXPresso Compatible Circuit)
*KickStart
KL25(MKL25Z128VLK4/FRDM-KL25Z Compatible Circuit)
*KickStart
KE02(MKE02Z64VQH2/FRDM-KE02Z Compatible Circuit)
*KickStart
EFM32ZG222F32(For EFM32ZG-STK3200)
*LED-Blink & UART
STM32L05xxx(STM32L053C8/STM32L0538-Discovery Compatible Circuit)
*KickStart
LPC812(LPC812/LPCXPresso Compatible Circuit)
20160331更新停止
*(Deprecated) KickStart
KL05(MKL05Z32VFM4/FRDM-KL05Z Compatible Circuit)
20170629更新停止
*KickStart
-Cortex-M0
STM32F03x(STM32F030R8T6/NUCLEO-F030R8 Compatible Circuit)
(CubeF0:V1.7.0/HAL:V1.5.0)
*KickStart & I2C-LCD/OLED and many Devices examples!
NUC120LE3(NUC120LE3AN/NuTiny-SDK-NUC120 Compatible Circuit)
*KickStart
M0516LBN(NUC120LE3AN/NuTiny-SDK-M0516 Compatible Circuit)
*KickStart
LPC11u35(LPC11U35/501 CMSIS-DAP Compatible Circuit)
*KickStart
STM32F05x(STM32F051R8T6/STM32F0-Discovery Compatible Circuit)
(CubeF0:V1.3.0)
20150922更新停止
*(Deprecated) KickStart
LPC11xx(LPC1114/LPCXPresso and MARY and DIP28-package Compatible Circuit)
20150922更新停止
*(Deprecated) KickStart
-ARM7TDMI
LPC23xx(LPC2388/CQ-FRK-NXP-ARM-JUNKBOARD Compatible Circuit)
20181222更新停止
*(Deprecated) TFT/OLED Module Control Sample with ChaN's FatFs(MCI-Interface))
●AVR
-AVR-Dx
AVR128DA48 CuriosityNANO
(and AVR128DB28,AVR64DD28 baremetal supported)
*UART & Internal Temperature Test
-XMEGA
ATxmega128A1/Atxmega128A1U
20240101更新停止
*(Deprecated)TFT/OLED Module Control Sample with ChaN's FatFs(SPI-Interface)
●Windows Tools and Misc
- OpenOCD for Windows
ocd-0.12.0+dev-00927-g6834f022b(built on 20250413)
Windows 32bit Binary Nemuisan's Special Version
*Supported OS*
->Windows7,8,10,11(x86 or x64)
->WinXP last version is here.
*Supported Debugger Hardware*
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
->JLink On LPCXpressoV2/V3(WinUSB)
->JLink-OB(WinUSB)
->STLink,/V2,/V2-1 and /V3(STMicro's Distributed USB-Driver/WinUSB)
->Versaloon(WinUSB)
->TI-ICDI(TI's Distributed USB-Driver/WinUSB)
->CMSIS-DAP(Generic USB-HID/Mbed VCP Driver)
->Nulink(Generic USB-HID)
*OPENOCD FOR WINDOWS BINARY HERE!
SHA-1 HASH:dbd869c023d119b05d879fee52125d16530cef71
OpenOCD(0.13.0)'s Specific MCU cfg Files for Flash Programming=
*OpenOCD spesific MCU-Aimed cfg files Nemuisan Special
↑Notice:Already contained in my OpenOCD Binary.
For self build users & linux users only.
OpenOCD(0.13.0)'s Patch Set(Useful Functions & Fix Patches)
*OpenOCD Patch Set Nemuisan Special
↑For self build users & linux uses only.
- AVRDUDE for Windows
AVRDUDE for Windows v8.0 32bit Binary(built on 20250413)
Nemuisan's Special Version
Supported OS
->Windows7,8,10,11(x86 or x64)
*AVRDUDE FOR WINDOWS BINARY HERE!
-SPIROM Writer Tools
FLASHROM for Windows(SPI-ROM Writer) (built on 20250413)
1.6.0-devel (git:v1.5.0-44-g4d4688cc) 32bit Binary
For FT2232/FT232H Devices(WinUSB)
*Flashrom_v1.5.0-44-g4d4688cc.7z
-JTAG Tools
UrJTAG for Windows v2021.03 #d9a2943f(built on 20250413)
*urjtag.tar.gz
SupportedHardware
->JTAGKey,JTAGkey2 and many FT2232 Devices(WinUSB)
->JLink(WinUSB)
->JLink On LPCLink2(WinUSB)
-JTAG Hardware
-Schematic of JTAGkey2 Compatible Circuit Rev.5
(Supports 1.4〜5.5V WideVoltage Range)
*JTAGKey2CompatibleCircuit_Rev.5
かつてこの欄でFirefox拡張｢合間合間に｣のバックアップを公開していました。
20191124更新：
waterfox向けの｢合間合間に｣のふたばの仕様変更対応版をサルベージしましたので
こちらでも公開します。
※｢赤福Firefox版」/｢合間合間に｣は有志の方がGitHubにて管理されています。
※unmhtはこちらに残っています。
免責・連絡先は↑のリンクを
↓SNSもやってます↓
powered by まめわざ
- ARM/STM32 (117)
- OpenOCD (27)
- ARM/NxP (34)
- ARM/Cypress (5)
- ARM/Others (3)
- ARM/Raspi (1)
- AVR (13)
- FPGA (4)
- GPS/GNSS (19)
- MISC (84)
- STM8 (2)
- Wirelessなアレ (16)
- おきぱ (1)
- ブラウザベンチマーク (29)
- 日本の自然歩道 (27)
- 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ねむい (12/18) - 中部北陸自然歩道を往く -砺波平野の県境を駆け抜ける！-
⇒ ひかわ (12/15) - STM32U0はぢめました
⇒ ねむい (08/07) - STM32U0はぢめました
⇒ ひかわ (07/28) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ ねむい (05/17) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - STM32H5を使ってみる3 -待ち受ける初見殺しの罠たち-
⇒ どじょりん (05/16) - いろいろ試す61(と今年の反省会)
⇒ ねむい (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/02) - いろいろ試す61(と今年の反省会)
⇒ ひかわ (01/01)
- April 2025 (1)
- March 2025 (1)
- February 2025 (1)
- January 2025 (1)
- December 2024 (2)
- November 2024 (1)
- October 2024 (1)
- September 2024 (1)
- August 2024 (1)
- July 2024 (1)
- June 2024 (1)
- May 2024 (1)
- April 2024 (1)
- March 2024 (1)
- February 2024 (2)
- January 2024 (1)
- December 2023 (4)
- November 2023 (2)
- October 2023 (2)
- September 2023 (1)
- August 2023 (2)
- July 2023 (1)
- June 2023 (2)
- May 2023 (3)
- April 2023 (1)
- March 2023 (1)
- February 2023 (1)
- January 2023 (1)
- December 2022 (2)
- November 2022 (1)
- October 2022 (1)
- September 2022 (1)
- August 2022 (1)
- July 2022 (1)
- June 2022 (1)
- May 2022 (1)
- April 2022 (1)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (2)
- October 2021 (1)
- September 2021 (1)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- April 2021 (1)
- March 2021 (1)
- February 2021 (1)
- January 2021 (1)
- December 2020 (3)
- November 2020 (1)
- October 2020 (1)
- September 2020 (1)
- August 2020 (1)
- July 2020 (1)
- June 2020 (2)
- May 2020 (1)
- April 2020 (1)
- March 2020 (1)
- February 2020 (1)
- January 2020 (1)
- December 2019 (3)
- November 2019 (1)
- October 2019 (1)
- September 2019 (2)
- August 2019 (1)
- July 2019 (1)
- June 2019 (1)
- May 2019 (1)
- April 2019 (1)
- March 2019 (1)
- February 2019 (1)
- January 2019 (1)
- December 2018 (3)
- November 2018 (2)
- October 2018 (1)
- September 2018 (1)
- August 2018 (1)
- July 2018 (1)
- June 2018 (1)
- May 2018 (1)
- April 2018 (2)
- March 2018 (1)
- February 2018 (1)
- January 2018 (1)
- December 2017 (2)
- November 2017 (2)
- October 2017 (1)
- September 2017 (1)
- August 2017 (1)
- July 2017 (1)
- June 2017 (1)
- May 2017 (1)
- April 2017 (1)
- March 2017 (2)
- February 2017 (2)
- January 2017 (2)
- December 2016 (7)
- November 2016 (2)
- October 2016 (2)
- September 2016 (1)
- August 2016 (1)
- July 2016 (1)
- June 2016 (1)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (1)
- January 2016 (1)
- December 2015 (3)
- November 2015 (1)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (3)
- June 2015 (3)
- May 2015 (4)
- April 2015 (2)
- March 2015 (4)
- February 2015 (1)
- January 2015 (3)
- December 2014 (3)
- November 2014 (2)
- October 2014 (1)
- September 2014 (2)
- August 2014 (2)
- July 2014 (3)
- June 2014 (2)
- May 2014 (1)
- April 2014 (1)
- March 2014 (4)
- February 2014 (4)
- January 2014 (3)
- December 2013 (5)
- November 2013 (4)
- October 2013 (3)
- September 2013 (2)
- August 2013 (2)
- July 2013 (2)
- June 2013 (3)
- May 2013 (2)
- April 2013 (2)
- March 2013 (2)
- February 2013 (2)
- January 2013 (3)
- December 2012 (4)
- November 2012 (2)
- October 2012 (2)
- September 2012 (4)
- August 2012 (1)
- July 2012 (3)
- June 2012 (2)
- May 2012 (3)
- April 2012 (3)
- March 2012 (2)
- February 2012 (3)
- January 2012 (3)
- December 2011 (5)
- November 2011 (3)
- October 2011 (2)
- September 2011 (2)
- August 2011 (2)
- July 2011 (2)
- June 2011 (2)
- May 2011 (2)
- April 2011 (2)
- March 2011 (2)
- February 2011 (2)
- January 2011 (3)
- December 2010 (7)
- November 2010 (1)
- October 2010 (1)
- September 2010 (1)
- August 2010 (3)
- July 2010 (4)
- May 2010 (1)
- April 2010 (2)
- March 2010 (2)
- February 2010 (2)
- January 2010 (3)
- December 2009 (3)
- November 2009 (8)
- October 2009 (7)
- September 2009 (5)
- August 2009 (4)
- July 2009 (6)
- June 2009 (6)
- May 2009 (14)
- January 1970 (1)
Copyright(C) B-Blog project All rights reserved.