ねむいさんのぶろぐ

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();を含む
コードでも安定してデバッグが可能となります。

東海自然歩道を徃く21(蔵田-宇津の谷峠/宇津の谷峠-草薙)

あれ？なんで半泣きになってるの？そんなに嬉しかった？ちゃんと前に言いまし
たよね…？今年は東海自然歩道の夏の陣やりますって！さぁれっつらごー！！
いきますよぅ！

●2013.05.18 蔵田->宇津ノ谷峠

藤枝…かつてぴちぴちのJDのころは下宿先の静岡市街からここまでよく通ってたっけ…
おっといけないいけない、目から鼻水が出てきちゃいました…ｽﾞﾋﾞｯ
こっからバスでまずは"ゆらく"まで移動します。

温泉施設"ゆらく"バス停まではこの自主運行バスで向かいます…
ここからさらにバスを乗り継ぎすスタート地点の蔵田に向かいますが…

で、この乗り継ぎのバスがすごかった…だいぶｵﾝﾎﾞｒ使い込んだバスで
運転手のおじいさまもﾛｰtｒ超ベテランなお方でねむいさんが通っていた某大学の
お話で時間オーバーしてまで延々と話していただき出発したらあまり太くはない
県道をGetWildな運転で駆け抜けていって蔵田の手前の勾配のきつい坂で野生動物に
道をふさがれよく見たらその野生動物はアナグマちゃんでまぁそれはいいのですが
先に進めないので"どけ、どけ"とねむいさんも一緒にアナグマちゃんに向かって
ジェスチャーしてたら運良く対面から静岡県警のパトカーが来やがってしまい警察屋さん
がたぶんねむいさんの行動を勘違いして急停止したのですが運良く警察屋さんも
アナグマちゃんの存在に気づいてアナグマちゃんどかして事なきを得たのですが
この時点でもう疲れた…はぁ～～～…
まぁ春先ですから動物さん出てきても何もおかしくはないですよね～

というわけでこの蔵田バス停から静岡バイパスルートのスタートです！

ですがその前に本線との分岐点まで戻ります。

本線の清笹峠への道は危険な状況に差し掛かっているのかバリケードが
さらに強固になっています。これは当分の間通れませんね…
さっきの静岡県警のパトカーは地すべりの定期見回りかもしれません。

そしていよいよバイパスルートに向かいます！
ほかの方のレポートでは道がわからないという報告もありますが、2013年の
時点では道標はほぼすべて完璧に整備されており、一切迷わないように
なっていました。

蔵田は意外と標高の高い場所です。
茶畑の中をひたすら下っていきます。

さっきバスで通過した県道の道と落ち合いました。
ここからは山道になります。

つり橋を渡り、いよいよ山道が始まります。

ひたすら上っていくのですが、途中の竹林がやばいです。
笹の枯れた葉が堆積して異様に滑りやすくなっていて超危険！

竹林を抜けたら林道と落ち合いました。
ここはビオトープガーデンがあります。

ビオトープガーデンからはひたすら車道を走ります。
途中にびく石に通じる山道への分岐があります。ここを上ると
崖みたいなのと説明板に差し掛かったのですが…。

崖と思っていたのがびく石本体でした。

びく石を登って裏手に回ると休憩所がありました。
なんとここには上水道の蛇口まであります！！

頂上付近には富士見石なる石がありますが、残念ながら富士山は
この日は見えませんでした。

さて、今回ののぼりはこれにて終了で後はひたすら下って行きます。
途中に笹川八十八石なる石があるそうです。ここを越えて岡部宿に向かいます。

この笹やばすぎ…滑ったらそのまま谷底にまっさかさま



おり始めて少し経つと八十八石めぐりが始まります。
一つ一つに名前があります。

今年はらくださんをキレさせないようにねむいさんの可愛らしい絵を沢山描いて
いただけるように私も模範的な虹メを目指したく…
(ﾁｯ、許せーな…)許してま～っす(←反省してない)

どんどん降りて行くと傾斜がなだらかになりこんなメッセージの入った
瓶も発見しました。

"表石"を越えたら八十八石めぐりも終了です。
後はひたすらアスファルト舗装の車道を走りぬきます！

許されざる角度に傾いた道標も次の休憩地点の"玉露の里"を示しています。

ちょっと寄り道して不動(不動男女)の滝も見てきました。
やんごとなき方がここを訪れたようで。

本線に戻り、朝比奈川に合流してさらに下って行くと玉露の里に到着します。

玉露の里はその名の示すとおり玉露の三大産地のひとつであるこの朝比奈地区
に作られた大規模な庭園のある施設です。ねむいさんがここに立ち寄った目的は…
この玉露アイス(玉露フレークつき)です！！

アイスも食い終わって庭園の写真を取り巻くってたら後ろから近づいてきた
説明員のおじいさんに"朝比奈龍勢"なる巨大ロケット花火の説明を20分くらい
連発式ロケット花火のように聞かせていただきました…ぐは…
ねむいさんが美少女だったから張り切ってしまったのでしょうk

さてだいぶ時間食ってしまったので次の場所に向かいますよぅ！
干して燃やした煙吸ったらやばそうなｲｶｽ葉っぱのマークのある橋をわたって朝比奈川に沿って下ります。

これがさっきの朝比奈龍勢の発射用やぐらです。ここからさらに
車道をひたすらひたすら南下して行きます！

や…やだ…何このさぼてん…いやらし///

朝比奈川を何度も渡り返し東名の下にある桂島公園も越えて折り返し地点の若宮八幡宮に
つきました。ここからすぐに旧東海道に合流します。

旧東海道と合流地点である総合案内所につきました。
旧といってもここは現役バリバリの幹線道路です。

東海道に面したこの岡部地区は昔の古い建物がいくつか残されており、資料館になっています。

歴史あるこの道は今は国道一号線の一部となっています。車の流れがすさまじいです。

この日のゴール地点である坂下バス停に到着しました。
次回はここの分岐点から"明治のトンネル"を目指します。

で、着替える場所がないのでちょっと戻って道の駅宇津の谷峠のバス停から
(ついでに家族のお土産買って)静岡に戻りました。

●2013.06.15 宇津ノ谷峠->草薙
静岡バイパスルートの前半は上りも少なく舗装路が非常に多くイージーなルートです。
また、山を離れて海沿いのルートもあるのが特徴です。

季節は梅雨…のはずですが雨は降らずどんよりとした天気。
トレランに向かうねむいさんにとっては逆にありがたいですが雷雨はかんべんな！

前回のエントリポイントである坂下バス停に…しかし…
急にお○○こしたくなったので(※伏字は猥褻行為をさすものではない)トイレがある道の駅
宇津の谷峠に再び行く羽目に…

…道の駅のベンチで完璧に調子と準備を整え出発です！

今回から自作GPSロガーに使用するモジュールをGms-G9に交換しています。
実力のほどはこちらと今回の記事のラストを参照のほど…。

それでは改めてスタートです！まずは国道一号をアンダークロスして坂下地蔵尊へ。

このお寺の脇から"明治のトンネル"に向かうトレイルが始まります。

明治のトンネルの入り口です。現在は徒歩でしか通行できないようになっています。

トンネルの真ん中と出口です。こういう場所でありがちな落書きが一切ないのは
ところどころに仕掛けられた監視カメラが(あと徒歩でしかいけないのもあると思います)

出口にはトイレと宇津の谷峠の立体解説があります。
昔からこの場所は交通の要衝である証拠ですね。

"明治のトンネル"を抜け昔ながらの宿場を模した集落をさらに超えると現代の国道一号に
落ち合います。そして…

宇津の谷峠には静岡側も道の駅があり、そこに到着します。
…11年ぶりにこの場所に来た…あのころは忙しい平日でも車でここまでドライブにつれ
てってくれたりしｔ…目から流れ落ちる鼻水をぬぐって小休止しましたがまったく変わって
いませんでしたね…このちょっとおまぬけな丸子宿の看板も11年前のままです…(じわわ


ずびっ
さて、道の駅宇津の谷峠(静岡側)に別れを告げ林道を走りあがって満願峰への
登山口に至りました。そしてこの先で思いもよらない事態に…

この沢道あたりで取りつかれてたかと思います…。あいつに…！

ずんずん上って行くと東海自然歩道のいつもの道標が見えました…
(↑まだ気づいてない)

この写真をとった後ふと左腕を見るとねむいさんが何度も見慣れた
尺取虫風の動きをしつつ尺取虫は絶対行わない捜索行動をするものすごく
ちっさいwormが！！１１！っｯこれ山蛭！？

ねむいさん幸いにも真夏の直射日光とアスファルトの照り返し対策に非常に
目の細かいNorthFaceのロングスリーブインナーシャツを試験導入済みだった
ので血が吸えず左上でただ踊っていたそいつを平手でおもいくそ打った後倒木
にテイクダウンして手のひらでパウンドかまして自然と一体化していただき
ました…はぁはぁ

ってわけでまた蛭にたかられるといやなので急いで駆け上がりました…
トレランの癖に上りは歩いてたのかよと突っ込みいれられそうですが歩いて
ましたよぅｺﾝﾁｸｼｮｰ…あ、頂上についた…

満願峰の頂上はよく整備されていて休憩する場所が沢山あります。
別ルートから来た登山客の人も沢山いました。
残念ながら曇りだったので富士山は見えず…

満願峰を離れて次は花沢山に向かいます。
茶畑跡をひたすら抜けて山道に…

日本坂峠か！？と思ったらまだまだ先…

日本坂峠に着きました。ここからもうひとのぼりで花沢山です。

少し上って反射板が見えたら頂上はすぐそこです。

花沢山山頂です。
山頂は分岐と外れた場所にあるのでご注意を。

花沢山を離れ用宗駅に向かいます。
勾配がかなり急なので用宗側から行くのは結構つらいと思います。

車道を駆け下り、新幹線を見送りました。
さらにその先にある東海道線の踏切を越えると――

用宗海岸に―
そして東海自然歩道の海ルートの開始…

ねむいさんここもよく車でつれてってもらって…ｳｳｯ
ｹﾞﾌﾝｹﾞﾌﾌﾝ…もこっとした海に面した山は大崩海岸です。

海岸沿いを走り虹裏に毒された人が見たら卑猥に見えるﾓﾆｭﾒﾝﾂを
直角に曲がり山側に向かうとJR用宗駅に到着します。

東海自然歩道は本来はここで電車に乗りJR草薙駅へと向かいますが、ねむいさんは
このまま走って草薙駅へと向かいます！

ここから先は道標も地図もなくても私自身の記憶が草薙駅まで導いてくれます…
用宗港です。

安倍川の最南端にかかる南安倍川橋を越えます。

安倍川の河口です。なんか風力発電機ができてる…。

大浜公園プールです。

国道156号線と合流しました。ここも11年以上前にドライ(ry
目から鼻水が出っ放しです私！

大谷放水場に来ました…11年前に私(ry
11年前とまったく変わってない懐かしい景色たちに目から鼻水出過ぎて脱水症状に
なりそうです１！！１！１


大谷放水場で海岸とはなれ内陸に向かいます。

大谷街道と合流する手前にある静岡大学に寄りました。

静岡大学大谷キャンパスは山の中にあるため地元の人も散歩やジョギングに
訪れる場所です。理学部の建屋も2000年代中盤に池潰して新しい研究棟
(写真真ん中)追加された以外は11年前とまったく変わってな
…もう11年も…あたし１１ねん…

食堂手前にある小広場…ここも11年前とまったくおな(ry

"定年坂"を駆け下り懐かしいこの場所ともお別れです。

<静岡大学から少し下った場所にある大谷街道と合流してゴールの
草薙を目指します。

草薙総合運動場と草薙スタジアムです。

南幹線に添って進み、JR草薙駅に到着です！
次回はいきなりひたすら登りから始まり日本平を目指します。

…ナンダコリャ丸

そんなこんなで東海自然歩道夏の陣のスタートを切りました。静岡バイパス
ルートは直射日光が叩き付ける海沿いを駆け抜けるルートばっかりです。
しかも今年は記録的猛暑だそうですが…ねむいさんも山之辺や地元灼熱の
京都で確実にノウハウを積み重ねております。炎天下の恒常性維持をさらに
強固にした状態で挑む所存でございます！

※今回からカシミール3D＋電子国土による軌跡表示に切り替えました。
蔵田->宇津ノ谷峠　 GPSログ

宇津ノ谷峠->草薙　 GPSログ


おまけ
GP101とMT3333搭載のGms-g9を使ったトラッキングログの比較です。
もう隔世の感がありますね～♥