OpenOCD0.6.0を使ってLPC1114に書き込み＆デバッグする為のめそっど

20160311追：
もう4年前の非常に古い記事ですがアクセスがいまだに多いので補足します。
LPC1100(u系も含む)をOpenOCDで書き込み・デバッグしたい場合は、
ねむいさん謹製のcfgファイルlpc11xxx_swd_flash.cfgをお使いください。
現在はLPC1100系は上記のファイルですべてカバーできるようになっております。
上記cfgファイルを含むねむいさんがビルドしたOpenOCDのバイナリはこちら。





SWD接続が可能なデバッガハードウェアVersaloonは、STM32使いの人たちの間では
オープンソースでSWD接続が手軽に利用できる数少ない手法の一つとして重宝されて
いますが私のぶろぐにもコメントをよくいただいている竹本氏のVersaloonに関する
記事が2012年2月号のトラ技に紹介され、さらに多くの注目が集まるようになりました。
ちなみに記事最後の参考文献の所でトラ技名物の誤植どころか段落が下の段落に
めり込んでめちゃくちゃになって肝心なURLがわからなくなってしまっているのですが
記事を書いた竹本氏は何一つ悪くないです。悪いのはチェックが毎回適当で誤植や検証
もせずにいい加減な記事のせてるCQ出版のほうなんですから！！１１！(憤怒
野獣と化したカンガルー先輩に喝入れ直してもらった方がいいと思います。
いちおう丁寧に文章がぐちゃぐちゃになってる箇所をご指摘して差し上げたのですが、
もちろんお詫びと訂正には反映されませんでしためでたしめでｔ…たくねぇ！


はぁはぁ…すみません話逸れ過ぎました…。
NxP社のLPC1114に代表されるCortex-M0系デバイスはデバッグ用ポートにJTAGは
なくSWDしか存在しません。おまけにOpenOCDのCortex-M0系コアのデバッガの
実装はSWDしか接続方法がないゆえに手が入っておらず、またまたおまけに
Cortex-M0系コアの実装がまだ不完全ゆえにフラッシュ書き込みルーチンも
不完全と３重苦となっています。
しかしながらCortex-M0系のコアはCortex-M3系コアのサブセットなのでほんの
少しの箇所の変更で何とかできるようになります。
また、当たり前のことですが多くのCortex-M0デバイスはSWDしか存在ないので
SWD接続が可能なVersaloonもしくはSTLink/v2必須です



20120712追：
公式でCorte-M0がサポートされるようになりました♥しかしワークメモリが少ない
LPC11U14はopenOCDのビルド時にフラッシュ書き込みのソースにパッチを当てる
必要があります。こちらの手順をご覧ください。


以下の話はVersaloon対応のOpenOCD(0.6.0)がビルドできる環境&ビルド時の多少の
トラブルを回避できる能力を持ってる人対象です！ここでようやく本題！

●LPC1114(Cortex-M0系)専用のOpenOCDを作る
１．先ずはノーマルで動作を確認
　gitからとってきた新鮮なOpenOCDのコードにVersaloonのパッチを当ててビルド、
　LPC1769やLPC1343にSWD接続で繋がりフラッシュの書き込み/デバッグが正常に
　できてるかチェック。問題があれば不具合のないコミットまで巻き戻そう！(逃
　2012/01/26現在は私はこれで動作確認しました。あと最近のコミットはSTM32F2/4
　系で大バグが作りこまれていますが後述

２．ソースコード修正
　openocd/src/target/cortex_m.c内の2025行目あたりにある下記の内容
　
　 /* Cortex-M3 has 4096 bytes autoincrement range */
　 armv7m->dap.tar_autoincr_block = (1 << 12);
　を
　 /* Cortex-M0 has 1024 bytes autoincrement range */
　 armv7m->dap.tar_autoincr_block = (1 << 10);
　に書き換えて再ビルド。

　これでLPC1114(Cortex-M0)専用OpenOCDができました。めでたしめでたし。
　この中にも上記修正他をまとめたcortex_m0.patchがあります。



３．といいたいところですが
　OpenOCD+VersaloonでLPC1114を動かすための特別なスクリプトファイルを
　意する必要がありますね。
　既に私がフラッシュ書き込みルーチン付きのものを用意しているので、
　こちらを使ってくださいね。

　ただ注意すべき点は、私も過去に何度も述べてきたNxP系のARMマイコンに存在する
　CheckSumValidationです。LPC1114もご多忙にもれず"calc_checksum"を付与
　して自動計算した値をフラッシュの所定の番地に書き込んでおかないとユーザ
　プログラムが実行されずISPの番地に勝手にすっ飛んでしまいます。
　calc_checksum付けなくても前もって計算結果を埋めこんどいてもよいです。
　これはmbed等のクラウド環境から離れ初めて地に降りた時"動くはずのプログラム
　が動かない"とよく引っ掛かるポイントです。ねむいさんクラウドよりもセフィロス派
　なのでmbedはとんと興味ないのですが大事なことなので何度でも言います。


４．LPC1114以外のCortex-M0のマイコンでは可能か？
LPC1227:
->できるじゃない！
　同じCortex-M0系のLPC1227も書き込み&デバッグが可能です。しかしLPC1227は
　リセット直後はウオッチドッグがONになっているせいかデバッグが途中からに
　なってしまいます。うまく動く組み合わせを検証中です。
20120210追：
　OpenOCDでattachした直後に一旦ISPのアドレス(0x1FFF0000)に飛んでから
　実行するとmain関数の先頭で停まるようになりました！
　このスクリプトファイルは公開しております。

LPC11U14:
->できるじゃない！
　LPC11U14はフラッシュ書き込みに必要なワークメモリの最小値がどうしても確保
　できず、書き込みはできませんでした。フラッシュメモリの消去のみと別な方法
　でフラッシュに書き込んだ後デバッグ動作はできます。
20120530追:
　LPC2000.c内のマイコン内ワークメモリアロケ―ターの下限値を下げることに
　より書き込みが可能なことが分かり、パッチに反映しています！

STM32F0:
->余裕でできるじゃない！

　NuvotonのNUC120はvsprogのほうは対応されたのでOpenOCDももうすぐですね♥






尺が余ってしまいましたので小ネタをいくつか
●最近のOpenOCD(0.6.0dev)でSTM32F2/F4系のマイコンにつないだ瞬間に
　OpenOCDがセグメンテーションフォールトする

とあるコミットからFlashSizeRegisterなるメモリアドレスにSTM32F2/4系の固有値と
して書き込まれているらしい内蔵フラッシュメモリの実サイズ値を読みだして設定
するという実装に代わっていますが…こいつがでたらめな値を引っ張ってきて設定
しやがるため即ひでぶしやがります…。
"私の環境では問題ないです"とおっしゃられてる方もそういわずに100kByte以上の
バイナリ作って書き込んでみてください。おそらく最初に作りこんだときにLED点滅
するだけのような10kByte以下のバイナリのサイズでしかチェックしてなかったので
ひでぶを免れていただけだったのでしょう。


なんでこんな変なことしてるんだろうと思ってSTM32F4のリファレンスマニュアル
(Doc ID 018909 Rev 1)を参照すると…


先ず0x1FFF7A10に各チップごとに固有のuniqueIDがあって

次に0x1FFF7A10に16bitサイズのFlashSizeがストアされたれじすｔ…
…アドレスが被ってる!?

なんかドキュメントが変ですよこれ！？
てわけでねむいさんの虎の子のOpenOCD+InsightでSTM32F407ZGT6(RevY)に接続し
該当するメモリの付近を捜索してみましたが…
…アドレス0x1FFF7A22に0x0400(1024kByte)が見える…
これが本物のFlashSizeRegisterかしら…

念のため手持ちのSTM32F2/4系のマイコン片っ端から引っ張り出してアドレス
0x1FFF7A22の値調べてみました。私の手持ちはすべて1024kByteの品種なので、
このアドレスが真のFlashSizeRegisterならば全部0x0400(1024kByte)にならな
ければなりませんがはてさて…


STM32F207VGT6(ES) :0xFFFF
(現在のOpenOCDの実装は0xFFFFだと1024kByteを想定して書くのでセーフ)

STM32F207ZGT6(RevY) :0x0400

STM32F407VGT6(RevA) :0x0400

STM32F407ZGT6(RevA) :0x0400
…ビンゴかよ…ES品の207VGT6は仕方ないですが。
とりあえずOpenOCDとSTMicroの中の人にメッセージ投げときましたけど気づいて
くれるでしょか???だめだったらフォーラムにも。
20120214追:
STから問い合わせ結果返ってきました。やはり0x1FFF7A22が正しいです。
リファレンスマニュアルも後日差し替えしますとのことです。
また、OpenOCDのほうも対応してくれました。



●aitendoさんのTFT-LCDモジュールを使う
そうだよまただよ

こっちとこっちは至ってごく普通のモジュールなんですが、TFT2P0327-Eのほうは
Vledが3.2VtypではなくLED2個直列つなぎの6.2Vなんです…データシートが3.0~3.4
って書いてあっておもいくそ間違ってます。まぁチャイナクオリティ(ry

といいたいところですけどねむいさんが買った3つがたまたまTFT2P0327-Eにくり
そつの別のLCDモジュールだったかもしれませんし大陸系の店は何があるかわから
ないんですけど買ったの今のところ私だけみたいですからまぁいっか…

半透過式の液晶なので視野角が広く太陽光下でもそれなりに見える代物らしいです

東海自然歩道を徃く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ログ

いろいろ試す10

あけましておめでとうございます。
今年もねむいさん(と虹裏メイドたち)を宜しくお願いします(ﾍﾟｺﾘ

と関係者向けのごあいさつを終えたところで今日のブログはおわ…ったら去年の
二の舞になってしまいますので、今年こそは本気を出して出来る限り前へ前へと
進んでいこうと心に誓う次第でございます。虹裏に投下する絵やコラももう少し
増やせるようにネタの回転力もあげたいなと。



さて、MentorGraphics社に買収されたCodeSourceryが去年暮れにリニューアル
して新バージョンがリリースされています。
やはりと思いましたが落とすのにメールでユーザーの登録を求めて
来るようになり、非常にかったるくなってしまいましたがこちらからフツーに
落とせますのでご活用ください。

今回の変更点はGCC4.5.1からGCC4.6.1にアップした点ですが、LinkTimeOptimization
の効果が少し変わっています。以前と同じままだと必要な部分まで削られてしまい
ますので以下のように変更しておいてください。細かい変更はGCCの本家に丸投げ
-flto -fipa-sra
↓
-flto-partition=none -fipa-sra
またデバッグ時にLTOを有効にしてるとブレークポイントが上手く張ることができない
ことがあるので無効にしておきましょう。
さらに最適化レベルに-Ofast(-ffast-mathを強制付与)が加わりました。

新しいSourceryでCMSISを含むコードをコンパイルしていると以下のような
エラーを吐いて

"Error: registers may not be the same -- `strexb r0,r0,[r1]"
というエラーメッセージを吐いてビルドが止まることがあります。
この対策は･･･
20241009追：
つべこべ言わずCMSISv5使いなさい！！！１１！！！
20241009追：


"ことがある"と書いたのはコードの流れによってはエラーを回避できる機械語に落とし
込まれる場合もあり、発見が遅れるケースが出てきます。
この件についてはこちらのディスカッションにある内容が詳しいです。
回避方法は…
引っかからないようにレジスタ変数を強制的に割り当てるというベタベタ
なコードに置き換えるのが唯一の方法です…。_STREXBとか_STREXHとか使わないから
コメントアウトするというのは後で困ることになるのでなるべく避けましょう。
__STREXB関数の変更例。__STREXHも同じような感じで変更してください。
uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
uint32_t result=0;

__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
return(result);
}

↓

uint32_t __STREXB(uint8_t value, uint8_t *addr)
{
register uint32_t result asm ("r2");
register uint8_t value1 asm ("r0") = value;
register volatile uint8_t* addr1 asm ("r1") = addr;
__ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr1), "r" (value1) );
return(result);
}


audin氏のブログのコメントにてiruka氏によりスマートな回避方法が提示されています。
上にあるディスカッションにも記述されていますがインラインアセンブラに早期破壊
オペランドを示す修飾子"&"を付与することによって__STREXB、__STREXHをコンパイル
した時にオペランドが同一レジスタとなりエラーが出るのを回避するとのことです。

CMSIS1.x系はcore_cm*.cに記述されていますが、CMSIS2.0以降はcore_cmInstr.hに記述
されています。変更する内容はどちらも同じです。CMSISの方が修正されるまでこれで
回避しておきましょう。

20120529追：
CMSIS3.0x以降では早期破壊オペランドを使用する修正になっています。
おきぱにおいてあるサンプルはすべてCMSIS3.01にしておりますので安心して
お使いください。
これらは液晶表示デモも兼ねています。今回の更新にあたり、多数のSPI液晶を含め
た液晶モジュールのドライバも追加しています。少し前にaitendoさんより販売された
S95591-AAA(コントローラIC:S6D0129)とTFT1P2797-E(コントローラIC:ILI9481)
のドライバももちろん作り込んでいますので参考にどうぞ。
あと業務連絡ですが、S95591-AAAとTFT1P2797-Eの初期化手順は全く違いますので
勘違いされないようご注意ください。




おまけ
もうキリがないからやめようと思ったのにまたやってしまった中華液晶モジュール
のコレクションたち…さらに詳しい詳細は私までご連絡を…




↑
176x220サイズのQCIFなSPI専用液晶。コントローラICはHX8340Bなのですが…
なんとHX8340B(N)という細かい型番が存在しているようで初期化手順どころかレク
タングルの指定・GRAMの書き込みコマンドまで全く違う別物でした…以前紹介した
HX8340Bは本当はHX8340B(T)という型番だそうです。
しかもSPIは9bit固定でした！！！！orz
てわけでハードウエアで9bitシリアルがサポートされてるMARY(LPC1114)とかには
いかがでしょうか？ちょっと解像度的にきついと思いますけど…


↑
Mouserで購入できるSDT018ATFTと言う液晶モジュール。コントローラICはILI9163C
だそうですがこいつも外に出てるピンの関係でシリアル接続は9bit固定でしたorz
てわけでハードウエアで9bitシリアルがサポートされてるMA(ry
(8-bit 8080,9-bitSerial接続）


↑
これはセカンドソースがたくさんあり、ebayでも最安5USD前後で購入できるNOKIAの
液晶です。情報元はこちらの方のページです。
コントローラICはSPFD54124Bです…が案の定外に出てるピンの関係でシリアル接続は
9bit固定でしたorzてわけでハードウエアで9bitシリアルがサポ(ry

↑
それとねむいさんのぶろぐ見てる人なら楽勝でしょうが、0.4mmピッチのハンダつけが
出来る人向けです。
(8-bit 8080,9-bitSerial接続）





↑
最後に128x128以上の解像度がなかなか手に入らないアクティブマトリクスOLEDの中で
176x220のQCIFサイズなC0200QILC-Cを


視野角とか素晴らしいのですが、OLEDの弱点である焼きつきが起こるので同じ画像を
ずっと表示することはできず、フォトフレームとかに使うと泣きを見るでしょう。
ここ最近は広い視野角TFT液晶がどんどん出てきているので無理してOLEDを選択する
必要も無くなってきました。

クリスマスの時の頂き物を…。いなちゃんは性的すぎる…♥

Go to top of page