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バイナリのみの提供とさせていただいております。

いろいろ試す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の見えなくなった画像早く復旧してください
Ａ：ぇっと…
　　今年は大事なことにたくさんエネルギー使っちゃったので
　　
　　来年からがむばります！

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小ネタ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使ってる人も少なくなりましたからこの変更は必須だと
おもいます。

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:02



J-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からバリバリ書き込み/デバッグが出来てます。"NxP
のチップしか使ってはならない"っていう規約的に使用不可であることを示す文面は
どこにも見当たらないのでねむいさんみたいな使い方しても全く問題ないでしょう。
問題あったら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でくだち…

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さんもこういうの見習ったらｲｲﾅｰ
･･･絶対ありえないですが…

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本体のプログラムをこちらに。非常に
実験色が強いので完全自己責任のご意見無用とさせてもらいます。

いろいろ試す…

ブログ始めて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の時刻情報を反映できるような付加機能とかができたら公開したいと思います。

DDT誌付録のLatticeXP2基板にAVR_Coreを実装する(するだけ)

少し前から下描きでずっと放ってあったいないさんの画像レス用の絵を
ガーっと仕上げて二次裏内で本人にいくつか使用してもらいました。
思えば私、ひさびさに真面目に虹メ&女主人らしい活動をした気がします。
やればできるジャン私！…そして滞るブログの更新。






少し前にAVR_CoreのLED点滅&UART垂れ流しのデモSVFだけ公開してましたが、
ある程度まとまりましたのでここに実装の仕方とか箇条書きで記しておきます。
ねむいさんが後から読んでわかるレベルのことし書きませんので悪しからず。
なんせまだ検証途中なもんでこれから先もどんどん変わる。

「お前の前フリはいつも長い」という方の為にソースは最初につけておきます。
自己責任でどうぞ。

１．ハードウエアを準備しないとね
　a.LatticeXP2基板はLDO&外部OSCを必ずつける。
　　内部も使えますがシリアル吐かせたい時は正確なクロックが必要なので。
　　クロックは30MHzを使用(kawasan氏のソースは内部で4分周してるので実際は
　　7.5MHzでうごいてます)。これは私がやってるお勧めできない実装例。

　b.LatticeXP2に何らかの手段で書き込みができるようにしておく。
　　内蔵フラッシュにはUrJTAG+JTAGkeyでsvfファイルの再生という形で
　　コンフィグができます。
　　JTAGkey(と互換回路)は持ってるけどLPTポートが無いPCやなひたふさんの
　　78kライタが使用できる基板を持ってない&無駄にCOMポート増やしたくない
　　なんて人は私がやってる方法で試してみてください。

２．論理合成用のソフト群のインストール…
　アカウントもらえるの時間かかるけどがんばれ。
　れっつごー

３．AVR_Coreのソースは…
　kawasan氏がxilinx用に実装を試みています。今回はこちらを使わせてもらって
　LatticeXP2向けとして実装していきます。

４．プロジェクト作って…
　ねむいさんは鳥頭でvhdlの文法はもうすっかり忘れてしまいました。だから
　なるべくソースはいじらない方向で、かついきなり本体に実装で行きます！！
　(シミュレーション等を一切考えてないとか一番ダメな手法だろうけど…)。
　プロジェクトに統合したvhdファイル群と階層構造はこちら。
　
５．AVR側のプログラムは…
　WINAVR(20090313)を使用してATMEGA103用のプログラムをコンパイルします。
　後述しますがRAMは実デバイスとほぼ同じ4096バイト取るのでコンパイラ側で
　リンカスクリプトなどの細工とかを考える必要は全くなしです。
　(cyclone基板の頃はDWM誌に具体的な説明が何一つなくてホント苦労した)
　kawasan氏のhex2vhdl.cを実行形式ファイルにしておいて、make一発で
　prom.vhdまでプリッと出るようにしておきました。kawasan氏に感謝です。
　肝心のプログラムの内容はソースを参照のこと(はしょるはしょる)
　とりあえず前回とほぼ同じで、動いてますよ程度のものです。

６．とにかく一回合成してみる
　時間長い。すげぇ長い。仮想PC上で動かしてるからこんなものなのでしょうね多分。
　合成の結果を見てみるとROM、RAM共ブロックRAMを類推してくれてます。
　kawasan氏のxilinx用のものがそのまま使えるようです。kawasan氏にマジ感謝です。

７．外部に信号を出す
　外部に引っ張り出す信号の設定をします。今回は最小限の確認なので
　こんな感じに。後述しますがreset引っ張るときは元のソースは論理が反対に
　なってるので注意です。

８．jedファイルに落とす
　ピン配設定まで終わったらここでjed作ります。jedからsvfはこちらを参照のこと。

９．svfを書きこむ
　UrJTAGのバッチモードで一気に。svfファイル内のeraseいじっておくとあっとい
　う間に終わるのは前にも述べたとおり。
　あと、何度かやってるうちに分かりましたが、バッチで動かすとUrJTAGがdetect
　に入ったときに時折フン詰まりになることがわかりました
　バッチの記述にdetectの前にfrequencyの設定を2回記述して回避してます。
　(原因はあとで調べます…)

１０．うごいた。
　動いてます。ねむいさん自身はほとんど何もしてません。先達が残された偉大な
　足跡に感謝ですね…。というわけでもう一回おソース。冒頭のと同じです。
　試されるときは自己責任でどうぞ(定型文)

１１．考察
　a.AVR側のプログラム容量の制限
　　なんも考えなしにべーっと合成した場合、RAM:4096byte(固定),ROM:8192byte
　　が限度でした。ブロックRAMは166kbitあるのでRAMが4096byteだとROMは
　　16384byteでもギリでいけると思いましたが…駄目。
　　RAMを2048に減らすと通るかしら？そうなるとRAMENDを細工しなきゃならない
　　のでしたくないのですが…
　　でも現状こんだけRAMROM使えたらおんの字ですよね！？
　　
　b.AVR_Core側
　　kawasan氏のvhdlソースをなるべく変えないスタンスで行きましたが、
　　DDT誌基板のSW入力ピンをリセットとして使うと、論理が逆になってしまう
　　のでソース中の記述も変えました。
　　また、ROM容量を8192byteまで取ったのでROMのビット幅も変えてます。
　　この二つの変更だけでDDT誌のLatticeXP2基板にAVR_Coreを実装できました。
　　あ、prom.vhdのこと忘れてた。



…実装は上手くいきましたが、AVR_Core使う場合はこっからがやっとこ始まり
ですね〜…一応RAM&ROM容量の見積もりがついたんで作りたい物のめどはつけてます…
vhdlとか論理回路とかの再おべんきょは避けられないのかorz

ディジタル・デザイン・テクノロジ付録基板のLatticeXP2にUrJTAG+JTAGkey互換回路でコンフィグする

2011.05.26追：
LatticeのISPVMがFT2232デバイスに正式対応となりました！
これで手軽に読み書きができるようになります。
いい時代となりましたね♥
追の追:
内蔵Flashに書くときは.jedファイルを指定します。
SPI-ROMに書くときは.bitファイルを指定します。
あとHS-1はGNDに落としておくこと。

2009.07.31追:
Latticeの付録基板を使用中、書き込み・消去が失敗すると以後基板からヤバ目
の発振音がしてJTAGで一切アクセスできなくなる事態に陥いることがあります。
これは「不完全なコンフィグ->コア電流異常消費->電圧ドロップ->再コンフィグ」
のループを繰り返してデッドロック状態に陥ってるからです。

この状態から回復するにはnPROGピンを(Lattice基板上でCN2_B07を)LOWに
引いたまま電源を投入して電源投入直後のコンフィグを開始させない状態で
JTAGにアクセスし、書き込みor消去を正しく完了させる必要があります。
依然としてこのページのアクセスが非常に多く大事なことだから2度言います。




DWM誌が廃刊休刊となり、新たにディジタル・デザイン・テクノロジ誌、
略してDDT誌が刊行されました。ご多望にもれず、付属基板なんかがついてます。
石はLatticeのLFXP2-5E-5TN144Cですね。フラッシュベースの不揮発型FPGAですって。

ねむいさんはLPC2388基板と秋月ARM基板動かすのに夢中になってたので
ほうっておいていましたが少しだけ触ってみましたよ。LPTの書き込みアダプタはもはや
作る気がなく、なひたふ氏の78kを使ったライタはCOMポートが増殖してしまいます。
ねむいさん的にはテストを兼ねてUrJTAG+JTAGkeyを使ってSVFファイルの
再生と言う形でLatticeの基板に書き込みをして見ようと思います。


…5月17日現在、ネットで検索してもデモのLEDチカチカを書きこんだ！
以外の作例が全くと言っていいほど見当たりません。
それどころかLEDチカチカの記事すらほとんどないのがさらに不安をあおります。
唯一chanさんはミクを動かしてレヴェルの違いを見せつけてくれていました。すげぇ。


私も一つ組んでみました。30Mhzの水晶とM25P40-VMN6P、LDOのADP3339なんか
つけてみました。あれ？このADP3339って…とお思いの方、かわいそうに…そう、+5V電源を
指示どおりに接続すると高い確率で発振するかのSH2基板に乗っかっていたアレですね〜。
今検索すると"「接続すれば発振する」は通用しない"と言う一文がトップに躍り出て
とても意味深です。でもADP3338/ADP3339はわるないよ？

それはおいといてこんな感じに各部品を実装。電源は容易に脱着できるように
JST-XAを。JTAGの端子は10Pinありますが、実際に信号が出てるのは
TCK,TMS,TDO,TDI,Vcc,GNDだけなので、馬鹿避け用に真ん中の一本はカットしてます。
ついでに9,10Pinもカット(最初からつけなきゃよかったorz)もちろん対になる8Pinコネクタ
(どうせ残りの9,10Pin繋がってないし…)はカットした真ん中の一本に
メクラをかませて馬鹿避けを実現してます。

ADP3339用のコンデンサは裏に実装してます。VinにはGRM21BB31C106KE15を、Voutには
秋月のこの子を付けて常時安定した+3.3Vの供給を行っています。
秋月のセラコンは+3.3V以下のセラコン対応のLDO用に大量に買っておいてもいいと思います。
あ、言い忘れてた、ADP3338/3339使うときはRP1、RP2は必ず除去してください！
真似する人はちゃんとデータシートで確認すべし。
さらに今回はSPIEEPROMは付けたけど一切無視するのでHS1のジャンパもカット。
やっとかないとSVFで書けません。

書き込む準備は出来ましたので次はsvfファイル生成ですね。
ISPLEVERとその他ツールはインストールしてあるものとして話を進めます。
jedの生成までは紙面にあるので省きますよ！！
(ツールをインストールするまで一苦労でしたね〜…認可もらえるまで
時間やたらかかったり、まぁその分しっかり審査しているということなのでしょう。
ちなみに私は組織名:二次裏メイド協会、名前：キリ・イセノミヤで通りました。
はぢめて上司が役に立った(笑)…っていいのかこれで)



では行きましょうか。
というわけでだいぶ端折ってjedが生成されたところからスタート。
これから先は画像付きで。
��jedが生成し終わったらispVMを起動する
��ChainConfigration1と言うウィンドウは即効消す。
��UniversalFileWriterを起動
��生成ファイルにSVFを選択
��InputDataFileに先に生成したjedを選択
��RUNTEST FROM REV.C をONにする
��OutputDataFile名を指定する。
��Genereteボタンを押してSVFを生成

はい出来ましたね？できてなくても次行きます。
次はいよいよ書き込みです。前ふり長くなりましたがこっからが本番です。
UrJTAGをダウンロードしてインストールしてください。JTAGkeyと通電した基板を接続し、
UrJTAGを起動。生成したsvfをUrJTAGと同じフォルダに置いて以下のコマンドを順番に。
その前に！HS1のジャンパカットし忘れてたら電源落としてカットしておいてね！

>cable jtagkey
>detect(ちゃんと繋がっていればここでチェーンが見える)
>part 0
>instruction length 8
>svf (生成したSVFのファイル名) progress
１分ほどたつと
>Scanned device output matched expected TDO values.
と表示され、FPGAがロードされます。

あと小技ですが、svfファイルの中のeraseの記述で
>! Erase the device
>
>! Shift in ISC ERASE(0x03) instruction
>SIR 8 TDI (03);
>! wait 1.20e+002 SEC
>RUNTEST IDLE 120000003 TCK;
の
>RUNTEST IDLE 120000003 TCK;
を
>RUNTEST IDLE 5000003 TCK;
くらいに減らしてやると書き込み時間を大幅に短縮できます。
最速で40秒くらいでコンフィグできます。それぞれの環境で調整して見てください。

また、もし書き込みが失敗してFPGAが不安定な状態に陥ったらnPROGピンを(基板上で
CN2_B07を)LOWに引いたまま電源を投入して再び書き込みを行って回復して
くださいね。基板捨てんじゃねぇぞ！あきらめるな１！！(←乙女の雄叫び)



こんなかったるいコマンド入力いちいちやってられるか！！と言う
方はバッチで実行するやり方もありますのでご紹介します。
こちらの中にサンプル付きでありますので中のファイル見てねむいさんが
何をしたいかが理解できる人だけ自己責任でどうぞ。
30MHzの外部OSC必須です。でもUART要らない人は特に周波数に気にしなくてもいいです。

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を使いましょう。

Project Examples and Misc Files

ねむいさん専用のFatFs中心のサンプルコード・プログラム置場です。
私が使いやすいようにGCC環境に勝手にポーティング&改造してあります。
文書の記述間違い・バグを見つけた場合は勝手に修正しています。
太字のリンクは更新頻度高。試される場合は自己責任でお願いします。
Dear All
Here is 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.5.0/HAL:V1.5.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-00982-gafbd01b0a(built on 20250506)
　 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:6aadcdf5703a67fc893380639edc4a162b092514

　 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はこちらに残っています。

Go to top of page