2012/07/29

[無駄話]動作確認できないものを作る

FeliCa Developers' Blogを見ながら移植してみた。
持ってないし、動かしたことがないのでよくわからん。
単にコンパイルが通ったというレベル。
動いたらびっくりだ。
https://sites.google.com/site/hiro99ma/home/files/other/libhknfcrw_Arduino.zip?attredirects=0&d=1

今のところ買う予定はないが、何かの拍子に入手するかもしれないので、まあいいや。

[os]アプリとライブラリを分離

FM3+TOPPERS/ASPに、自作NFCライブラリを持ってこようとしている。

消費電力とか効率とかはまったく考慮せず、PCで動かしたのと同等くらいのものが移植できたんじゃないかな、と思う。
移植といっても、C++だったものをCに置き換える作業がほとんどだったがね。

https://github.com/hirokuma/toppers_snep_target

 

NFC部分はヘッダファイルとライブラリだけにしてもビルドできるようになった。
まあ、-gで-O0なので、中身は見放題じゃないかね。

 

gccのリンクって、oファイル単位だったような気がする。
違ったっけ。。。こんなのがあるらしいが、やったことないな。ここにも記載がある。
R/W操作を1ファイルにしているので、けっこう大きくなるかも。
試しに--ffunction-sectionsと--gc-sectionsを付けてみたが、--gc-sectionsがあるとTOPPERS/ASPのcfgってのに怒られた。
なんかあるんじゃろうね。


libhknfcrwはTOPPERS向けに作ったところは特にないとおもう。
移植対象は、hk_misc.hとhk_devaccess.hに分けているので、そこに環境向けの実装を書けばなんとかなるんじゃなかろうか。

今回は、hk_misc.cとhk_devaccess_toppers.cというのにしている。
私が作った中で、唯一μITRONっぽいことをしている箇所だ。
シリアルの送信なんて非同期でやってるので、do-while()でぐるぐる待たせてるくらいだから、あんまりいいしくみではない。
送信側はイベント待ちにして眠らせ、送信完了割込でイベントを発生させるようにすりゃいいのかな?
まだこの辺りの流れがよくわかってない。

[os]InJumpForDEPで失敗しているだけか

FM3+TOPPERS/ASPでSNEPを動かそうとしているが、電源ONだとうまくいくけどリセットだとうまく行かない。

しかし、デバッグしてみると、単にInJumpForDEPでStatusがSUCCESSになってないだけのように見えた。
どっちでもいいや、と思ってInitiatorとして動かしていたのだが、InJumpForDEPはTargetがいないと失敗するんだったっけ。。。

記憶がないので、そういうことにしておこう。


電池で動かすような端末にするならば、Targetにして待ち受けた方が消費電力としては少なくなる。
TgInitTarget実行後は、RF検出するまでパワーダウン状態になるからだ。
パワーダウン状態は最大で100uA。
手元にあるエネループは2000mAhなので、もしRC-S620/SをTargetにしたまま放置したなら、2000÷0.1=20000時間。2年以上保つ計算になる(こんな計算よね?)。
まあ、マイコン側をまったく考慮してないし、通信のことを考えていないからだけど。

 

FM3の直流特性を見ると、STOPモードが1mA。
けっこう食うなあ。MB9B610Tシリーズはそういう用途ではないってことか。
LPC2388のパワーダウンモードは113uAで、ディープパワーダウンだと20uAまで減るから、手元にある基板で長時間保たせるなら、LPC-2388の方がよさそうだ。

今回はお遊びなので、そんなに考えなくていいや。
ってことで、SNEPをまったく行わないとすると、2000÷1.1=1818時間。2ヶ月くらいか。

今日の開発環境(2012年7月)

ときどき、開発環境の写真を撮るようにしよう。
image
Interface誌のFM3基板を使っているので、こういう環境になっている。
ブレッドボードの真ん中に乗っているのが、FM3基板。
その右側が、ARM-USB-TINY-HというJTAGデバッガ。
赤黒のよりよりは、リセットボタンにつながっている。
基板の下側から緑と青の線をブレッドボードにつなぎ、そこからRC-S620/Sにつなげている。
これは、UARTのTX/RX。
直接つなげてもいいのだけど、ロジアナで波形を見たかったのでブレッドボードを介している。
ロジアナは、写真左下のやつだ。

ブレッドボードの左下にあるのは、最近買ったI2C液晶画面。
キャラクタ表示が可能らしい。
らしい、というのは、まだ動かしてないから・・・。
やっぱり、ちょっとした表示がほしくて買ったのだけど、まだドライバを作っていないのだ。

このFM3基板、FRAMが載っている。
これもまだ使ってないのだけど、1兆回の読み書きが可能らしい(FRAMは読むときも破壊するそうな)。
これもI2C接続で、I2Cスレーブとして動くし、ドライバがInterface誌に載っていたので、うまいこと持っていけばLCDも表示できるだろうと目論んでいる。
まあ、目論見はいつもすんなりいかないものだがね。

stdbool.hを使ってももういいよね

誰に問いかけてるんだか・・・。

C99になって、boolが定義されたstdbool.hというものが使えるようになった。
trueとかfalseもあるので、C++のbool型がそのまま載せ替えられる。

CodeSourceryのstdbool.hを見ると、_Boolをtypedefではなくdefineでboolにしていた。
目的が「置き換え」だからそうしたのかな。

では、_Bool自体はどうなっているのか。
もしかして、「typedef int _Bool;」なんてやってたらやだなー、と思ったが、CodeSourceryには_Boolの定義がなかったので、中でちゃんとやってるんだろうと思う。

そうなってくれていないと、trueで比較するところがあったら、置き換えないといかん。
なるべくfalseと比較するように実装しているつもりではあるが、忘れてるかもしれないし、借りてきたところはそうなってないかもしれない。

 

ただ、C99オプションを付けなくてもstdbool.hはincludeできるし、使えている。
ということは、_Bool型もC99オプションなしで使えるのだろう。
「for(int i, ・・・」みたいな書き方は、C99オプションなしだと怒られる。
そういうもん、ってことでいいのかな。

 

「int型でやりゃいいやん」といわれそうだけど、ライブラリによって戻り値の意味が異なるのはめんどくさいので、標準のものがあれば使いたいのだ。
あるライブラリでは戻り値0が成功だったり、別のライブラリではTRUEが成功だったりすると、レビューするときにライブラリのことを調べてからやらんといかんので、めんどくさい。
基本的に戻り値はboolにして、エラーが知りたければ何か用意する、でもいいかと思っている。

 

そういいつつ、今の実装も0がSUCCESSに置き換えてしまいそうな気がするが、まあそんなもんだ。

2012/07/28

[os]大山鳴動してスタック不足

タイトルがすべてを表しているが・・・。

あまりに原因がわからないので、タスクのスタックを512byteから1024byteに増やしてみた。

そしたら・・・動いた。

 

えー、スタックオーバーフローかよー。
そりゃ、ソースを見ている分にはわからんはずだ。
それより、そんなに使うようなソース書いた、という方がショックだ。

 

確かにSNEPに関する部分は、プロトコルスタックそのまま実装したので、SNEP→LLCP→DEPと階層が深い。
その分、関数コールも深くなってしまった。

また、いつも仕事で使っているのが16bitマイコンで、その気分が抜けないまま32bitマイコンを使っているというのもあるだろう。

 

nfcpyを相手にすると、ちゃんとサンプルが動いた。
なので、実装自体はそんなに間違っていないようである。

めでたしめでたし、とするには、ちょっと早いようであるが、少し気が楽になった。

[arm]Imprecise data bus errorとは何者じゃ

TOPPERS/ASP+FM3基板で遊んでいるが、Hard Faultが発生している。
「Hard Faultかぁ」で止まっていたのだが、レジスタの値を見るともう少し調べることができるそうだ。

 

Fault系のステータスレジスタってものがある。
HFSR(E000_ED2C), MMFSR(MMSR? E000_ED28), BFSR(E000_ED29), UFSR(E000_ED2A)らしい。
MMSR, BFSR, UFSRは、レジスタとしてはCFSRの一部になるのかな?

HardFaultは、HFSR。
見ると、0x4000_0000で、FORCED=1だった。
説明を見ると「他のステータスレジスタをみなされ」だそうだ。なんじゃそりゃ。

仕方なく他のステータスレジスタを見ると、BFSRが0x04だった。
これは、IMPRECISERR=1。

Imprecise data bus errorらしい。


このビットが立ったときには、データバスエラーが起きている。
なおかつ、BFARレジスタにはfaultしたアドレスは残さない、となっている。
残す方のエラーは、PRECISERRのようだ。

IMPRECISERRは非同期で発生するらしく、エラーになった箇所が問題だとは限らないらしい。
プロセッサ側で優先度の高い作業をしていたら、それが終わってからエラーになるんだと。
優先度が高い側ではっきりした?エラーが発生したら、そっちの要因もビットが立つんだとか(このページのIMPRECISERR説明より)。

 

うーん、それは困った。。。


データバスエラーというのは、データバスに対してアクセスしようとしてエラーになることのような印象を受けた。

  • アドレス不正
  • アラインメント不正

どっちかじゃなかろうか。

 

そう思ったけど、関数は何回か呼ばれていて問題ないし、変なポインタキャストもしてなさそうだし、なんだかわからないなぁ。。。

[nfc]NDEFは短いのだけで許してくれんか

NFC勉強会(not 福岡)があってたので、NDEFのだけ見た。
バイナリの話とあっては、見ざるを得ない(?)。

 

自分の過去記事を振り返ると、案外NDEFのことを書いているのだが、中身についてはほとんど書いていない。
バイナリ解析好きなのだが、NDEFってアプリ寄りなので、なんとなくやる気が起きないのだ。

 

先日SNEPを実装したとき、NDEFを送信しないといけないので、さらっと読んで実装した。

https://github.com/hirokuma/libhknfcrw/blob/master/src/HkNfcNdef.cpp

よく考えると、私も相手のnfcpyもNDEFを解析するところまではサンプルに作ってないので実はなんでもよかったような気はする。

 

NDEFは、SR(Short Record)というビットがあり、SR=1の場合はペイロード部255byteまでという制限になるが、ペイロード長が1byteで済むのでNDEFレコードを小さくできる。
MIFARE UltralightもUltralight Cも、256byteはない。
FeliCa Liteもやはり256byteはない。

なのでもう、NDEFって短いのだけでいいんじゃないかな、と何となく思った。


が、大きなデータを送信する方法もあった。

SNEPみたいにデータ長の制限が特にないものでは、使い勝手が許す限りの巨大なNDEFデータを送信できることだろう。

あるいはカードエミュレーションして、途方もないメモリを持つNFCカードとして振る舞うってのもあるだろう。

 

巨大なデータになると、NFCはペアリングのみにしてもっと高速な通信網を使うというのが流行(?)のようだが、NFCだけでもまだまだいけるかもしれん。
まあ、使い勝手次第だろうけどね。

2012/07/27

[os]なぜかハードフォルト

TOPPERS/ASP + FM3基板。
まだまだすんなり動かない。

image

今日はここでハードフォルトが発生した。
この次の「mov.w」を実行したところで飛ぶようだ。
うーむ。

mov.wって、たぶん16bitデータコピーだろう。
r0レジスタに1という値を入れる、ただそれだけだと思うのだが。。。
この部分は何度も動いているのだが、あるときハードフォルトになるようなのだ。
うーむうーむ。

 

いつも「ハードフォルトかぁ」で止まってしまうが、実はもっと情報が載っていて、なんかわかるようになってるんじゃなかろうか?

というところで、今日の作業はおしまい。

今日の帰りがけに、なくしたnimocaを探すために同じルートで帰ってみたけれども、24時間後の地球には私のnimocaはなかったようだ。
がっくしだ。もう引退が迫っているのだろうか。。。

2012/07/25

[無駄話]NFCの勉強って、何をすればいいんだろう (2)

なぜ2回目を・・・。
理由は、前回があまりにNDEFを絶賛しているかのような終わり方になってしまったからだ。
私らしくない。

NDEFなんて知ったことかー!
NFC Forumに俺を縛ることはできないィィ!!

というロックな人(?)は、ISO/IEC 18092とか、ISO/IEC 14443なんかを読むのがよいと思う。
「仕様なんか知りたくねぇ」と思うかもしれないが、考え直してほしい。
これは「聖典」みたいなものだ。
この2つの仕様書の外側というのはあまりないと思うから、世界の端っこかもしれない。
世界の端っこなんて、なんかロックな感じがするではないか。

もっとコアな人がいるかもしれない。
俺がNFCだ、とか。
そういう人はいっそのこと、R/Wを作ってみるといいんじゃないだろうか。
私が知ってるのは、OpenPCDだけだが、作ることができれば、自分のNFC規格を立ち上げることも可能だと思う。
そこまでやれば、もう文句は言わせない、という自信が身につくだろう。

ライトな層の人も大切だ。
例えば、PCとPaSoRiは持ってるけどソフト作っても誰も使ってくれなくてAndroidで作りたいけどNFC端末持ってないから何とかならんかなあ、というような人。
こういう人は、ずいぶん前に途中まで移植したAndroid-x86にPaSoRiをつなぐ部分を完成させてほしいものだ。
JavaとAndroidのしくみがわからず、放り投げているところなのだ。

とまあ、適当なことを書いていったが、自分で得るものがあれば勉強だろう。
あまり難しく考えず、勉強すればいいんじゃないかね。
そういいつつ、参加しない私であった。。。

2012/07/24

[無駄話]NFCの勉強って、何をすればいいんだろう

もうすぐ、福岡でNFC勉強会がある(私は行かんけど)。
いままであまり考えてなかったのだが、NFCの勉強って何だろう?
何をするとNFCの勉強になるんだろう?
素朴な疑問は、なかなか回答が出ないものだが、少し考えてみよう。

NFCの原理とか?

まず勉強といえば、原理を知りたいんじゃなかろうか。
・・・そうか?
NFCって、電波でなんかやってるのよね? とか、NFCって近距離なのよね? とか、そのくらい知ってたらいいんじゃないだろうか。
まあ、知らないよりも知っていた方がいいことは多いと思うのだが、もうちょっとあとでもいいのかも。
最初に原理から入ると、興味がないと眠たくて飽きるかも。


NFCの扱い方は?

まあ、こっちの方が面白いだろう。
扱い方といっても、これは幅が広い。
NFCカードやR/Wのようなハードウェアもあれば、タグやNDEFのようなソフトウェアもあるし、NFCIDのような運用もある。
何をやるかは別として、ここら辺が「勉強」って感じがする。


NFCの応用っていうのは?

NFC単体は、それほどああだこうだいうものがない。
応用して初めて役に立つものだ。血肉を与えるっていうんかね。
勉強だけしていると、応用が思いつきにくい(のは私だけか)。
ただ勉強せずに応用だけ聞くと、なんか魔術を見ているような気になってしまうので、勉強したあとの方がよかろうか。

私の思っている「勉強」ってのは、どうも扱い方を知ることのようだ。
では、その視点で分類わけを適当にやってみよう。
適当だ。

  • ハードウェア
    • NFCカード、シール
      • 種類とアクセス方法
    • R/W
      • アクセス方法
    • Mobile NFCチップ
    • Secure Element
      • ??
  • ソフトウェア
    • プロトコル
      • エアプロトコル
      • タグ
    • NDEF
    • API
      • Android
      • BlackBerry
  • 運用
    • 規約
      • NFCIP-1, 2
      • NFC Forumのドキュメント
      • ISO/IEC 14443
    • サービス

ネタが尽きた・・・。
NFCカードとタグが別になってるのは、カードはほんとにカードだけで「このType x Tag用」っていうハードで、Tagはそれを使えるように意味づけしたもの、という気持ちが入っているからだ。
まあ、私の感覚がそうだってだけだがね。

私は、サービス関係と、携帯電話に関係するところがさっぱりだめだ。
だめだし、強化するつもりがさらさらない。

でもまあ、やってみないと勉強にはならんわな。
動かしてこそ華だと思うのだ。

なので、最初はR/Wとカードで実践するのかな、と考えてたけど、Android端末とかだとAPIで操作できるし、そういうことになると、NDEFから始めるのがいいのかもしれん。
データ構造はAndroid(というか、libnfc-nxp)が吸収しているのだけど、知っておいて損はないだろうね。
そう言うほどNDEFの知識はないので、この辺で終わっておこう。

2012/07/23

[os]なんとなく動く

TOPPERS/ASPというμITRON実装をInterface誌FM3基板で動かそうとしている。
いろいろ勘違いしているところがあり、直していくとなんとなく動くことが確認できた。
よかったよかった。


勘違い1:シリアル送受信APIの戻り値は、サイズ

正常に動いた場合、シリアル送受信APIは転送サイズを返すようになっている。
が、私はE_OKを返すんだろうと思ってラッパ関数を作っていたので、いつもエラーになっていたのだった。



勘違い2:シリアル送信は同期ではない

送受信サイズを返すのなら、転送完了まで確認する同期呼び出しなんだろうと思っていたが、そうじゃなかった。
送信バッファにためたら、戻る。
これはTOPPERS/ASPだからかFM3移植だからかは知らない。

ロジアナで波形を取っていたのだが、同じ処理を書いているのに送信が途中で止まることがあったので、どこだろうどこだろうと探し続けていたのだったが、単に送信割り込みで送っている途中でブレークさせたので波形が止まったというだけのことだった。

最初に調べろよなぁ、私。。。


そんなこんなあったが、RC-S620/Sが動いた。
まだポーリングしか動かしていないけど、基本部分はきっと動いてくれるだろう。

あとは・・・C++実装している箇所をC実装に変更する作業と、ライブラリ化が残っている。
もしかするとC++のままでもちゃんとやれば動いていたのかもしれないが、まあいいや。
やっぱりドライバはC実装の方が落ち着く気がする。

あ、残っているといえば、送受信を別タスクに割り振る作業があった。
今回はシリアル転送を同期で行うようにしているけど、消費電力を減らすのであれば避けられまい。
転送もDMAを使えばさらに減らせるんだろうけど、あんまりそういうのが得意ではないのよねぇ。

2012/07/21

[os]昨日の動かないところを調べよう

昨日は眠たすぎて、よくわからないことを書いていた。
整理しよう。

TOPPERS/ASP + FM3で、シリアルポートをオープンすると、Cortex-M3のHardFault例外が発生する。
箇所は、x_unlock_cpu()したときのset_basepri()。

image

上の図で、msrするところは進んだけど、次のaddでステップ実行すると例外が発生。
ちなみにOpenOCDのtelnet側でpollすると、こんな感じになる。

image

HardFaultってのがわかるんですな。


set_basepri()だが、こんな実装になっている。

image

MSRという命令は、普通のレジスタの値から特殊レジスタへ書き込みを行う。
ARMv7-Mでは、BASEPRIも指定できるので、問題ない。
うーむ。

上のアセンブラを見るとわかるが、これは関数呼び出しされている。
-O0でコンパイルしているからかも。
なんとなくだが、これはインライン展開されないとよろしくないようになっているのでは?


そうかどうかはわからないので、BASEPRIを見てみよう。

2.1.3. Core registers

Base Priority Mask Registerらしい。
Interface誌にも書いてあった。割込のマスク制御関係らしい。
じゃあ、これ自体は呼び出してもあんまり関係ないか。

 

「Privileged」と書いてあるので、特権モードじゃないと使えないのだろう。
Cortex-M3は、どういう動作モードがあるのだろうか?

3.2.1. 動作モード

おや、「スレッドモード」と「ハンドラモード」の2つしかないんだ。
OpenOCDで「current mode」に出てくるあれは、これだったんだ。
pollって打つとこれが見られるので、msr実行時に見てみればよいか。

image

スレッドモードやん。。。
いや、よく読め。
スレッドモード・ハンドラモードは「動作モード」で、これとは別に「特権アクセス」がある。
スレッドモードでも、特権アクセスは可能なのだ。

CONTROL[0]をクリアするとユーザモードらしいので、CONTROLレジスタというものを見ればよいのかな。

・・・Eclipseに出てくるレジスタ一覧に出てこない。
そういえば、BASEPRIもレジスタなのだけど、出てこないな。

telnet側から「reg」と打つと、出てくるらしい。

image

CONTROL[0]は、0。
よって、ユーザモード。

つまり、スレッドモードかつユーザモードで動いている、と。
なして?


controlでソースを検索すると、sense_context()で使われている。
unl_cpu()の頭にあるCHECK_TSKCTX()で呼んでいる。
ここでは、0x02が返ってきているので、regで見た値と同じだ。

sense_context()は、CONTROLレジスタの値と0x02をANDして、0x02ならばfalse、それ以外ならtrueを返すようになっている。
CONTROLレジスタのbit1は、スレッドモードでスタックとしてメインスタックとプロセススタックのどっちを使うかを決めているところのようだ。
ASPにはCONTROL_PSP(0x02)とCONTROL_MSP(0x00)があるので、PSPがプロセススタックポインタ、MSPがメインスタックポインタを意味しているのだろう。
こちらがわかりやすい。

sense_context()がfalseを返し、falseはPSPで、PSPはスレッドモードでしか使用できない。
これが意味するところは何だろうか?
sense_context()はCHECK_TSKCTX()で呼んでいると書いたが、マクロでこうなっている。

   1: /*
   2:  *  呼出しコンテキストのチェック(E_CTX)
   3:  */
   4: #define CHECK_TSKCTX() {                                    \
   5:     if (sense_context()) {                                    \
   6:         ercd = E_CTX;                                        \
   7:         goto error_exit;                                    \
   8:     }                                                        \
   9: }

trueだと、エラーらしい。
だから、PSPであるのが正しい、という流れだ。つまり、スレッドモードで正しいのよ。
(PSPのときは「タスクコンテキスト」と呼んでいる)

なんだなんだ?


落ち着け。
だいたいこういうときは、自分が何かミスをしているのだ。

まず、現象が起きているのは、CPUロック状態の解除を行う、x_unlock_cpu()の中で呼んでいるset_basepri()。
CPUロック状態を解除するということは、その前にロックを行っているということだ。
それもset_basepri()を呼んでいるはずで、そこでは失敗していない。
よし、そこを確認しよう。

 

ロックは、x_lock_cpu()。
流れはunlockと同じで、コンテキストがタスクコンテキストであることを確認し、set_basepri()している。
書き込む値は、0x10。
pollを見て、まだスレッドモードにいることと、regを見てユーザコンテキストであることを確認。
さて・・・問題なし。

 

ということは、msrがどうのこうのではなくて、CPUロックを解除したことによって何か割込が発生して、そっちが原因ということか。

そうだよな、msr命令で例外が発生するなら、実行してすぐに発生するはずだけど、1ステップ後だったからな。


アボートモデルによると、HardFaultが発生する要因は4つあると。
どれも凶悪だ。
さて、なんだろうね。

シリアルポートをオープンした直後だから、シリアルの割込関係か。
そういえば・・・cfgファイルをかなり適当に設定してたよな。

   1: INCLUDE("target_timer.cfg");
   2: //INCLUDE("syssvc/syslog.cfg");
   3: INCLUDE("syssvc/banner.cfg");
   4: INCLUDE("syssvc/serial.cfg");
   5: //INCLUDE("syssvc/logtask.cfg");
   6:  
   7: #include "snep_target.h"
   8:  
   9: CRE_TSK(LED_TASK, { TA_ACT, 0, main_task, 7, 128, NULL });
  10:  
  11: CFG_INT(IRQ_VECTOR_MFS4RX, { TA_NULL, INTPRI_SIO });
  12: ATT_ISR( { TA_NULL, INTATR_SIO, IRQ_VECTOR_MFS4RX, NULL, 1} );
  13: CFG_INT(IRQ_VECTOR_MFS4TX, { TA_NULL, INTPRI_SIO });
  14: ATT_ISR( { TA_NULL, INTATR_SIO, IRQ_VECTOR_MFS4TX, NULL, 1} );

よくよく読むと、INCLUDEしているsyssvc/serial.cfgの中でtarget_serial.cfgをINCLUDEしていた。
target_serial.cfgは、各ターゲットごとのファイルで、cq_frk_fm3_gccではこうなっていた。

   1: /*
   2:  *  SIOドライバ(cq_frk_fm3用)のコンフィギュレーションファイル
   3:  */
   4:  
   5: #include "target_serial.h"
   6: ATT_INI({ TA_NULL, 0, sio_initialize });
   7: ATT_ISR({ TA_NULL, SIO_PORTID, INTNO_SIO_RX, sio_rx_isr, 1 });
   8: ATT_ISR({ TA_NULL, SIO_PORTID, INTNO_SIO_TX, sio_tx_isr, 1 });
   9: CFG_INT(INTNO_SIO_RX, { TA_ENAINT|INTATR_SIO, INTPRI_SIO });
  10: CFG_INT(INTNO_SIO_TX, { TA_ENAINT|INTATR_SIO, INTPRI_SIO });

 

私はRC-S620/Sを1番につなぎたかったので、target_config.hでSIO_PORTIDを2に変更している。
そうすると、INTNO_SIO_RXなどはtarget_serial.hの中でIRQ_VECTOR_MFS0RXなどに変更される。
私はMFS4RXなどを使いたかったので自分のcfgで定義したんだけど、これだと割込を使うくせにハンドラが登録されていないってことになるのかな。

とりあえず、はずしてみよう。

   1: INCLUDE("target_timer.cfg");
   2: //INCLUDE("syssvc/syslog.cfg");
   3: INCLUDE("syssvc/banner.cfg");
   4: INCLUDE("syssvc/serial.cfg");
   5: //INCLUDE("syssvc/logtask.cfg");
   6:  
   7: #include "snep_target.h"
   8:  
   9: CRE_TSK(LED_TASK, { TA_ACT, 0, main_task, 7, 128, NULL });

 

・・・例外が発生しなくなった。
前も同じにして動いていたのだけど、あれはRXDをRC-S620/Sに挿してなかったからなのか?
いやいや、前回そうしたのは、セマフォIDが入らなかったからだ
なぜだ、なぜなんだ・・・・・・・。

今日は時間がないから、深追いはやめよう。
だが、送信でまた失敗するので、追うことになりそうだ。

2012/07/20

[os]今日のうまくいかん場所メモ

OpenPCDがエラーを出してつながらなかったが、気にせずつなぎにいくと、案外うまく行くような気がする。
気のせいかもしれん。

 

しばらくうまくいかん気がするので、だめだった場所にメモを残していこう。
今日は、シリアルポートのオープンでCPU例外っぽくなる。
HardFaultっぽい。
シンプルなサンプルではシリアルオープンできていたのだが、なんだろうねぇ。

image

/*
*  BASEPRIのセット
*/
Inline void
set_basepri(uint32_t val){
    Asm("msr BASEPRI, %0" : : "r"(val) : "memory");
}

2012/07/18

[os]自作関数を呼ぶと、CPU例外が起きた

TOPPERS/ASP用に、今までC++で作っていたライブラリをCに置き換えた。
ラッパだけ作ろうかと思っていたのだが、ASPでC++が動くかどうかよくわからなかったので、いつかやろうと思っていたこともあり、移植したのだ。

全部じゃないけど、RC-S620/SからACKが返ってきそうなコマンドの実装が終わったので、組み込む。
ライブラリなので、arm-none-eabi-arでまとめて.aファイルにし、リンク。

途中、memcpy()類がないということで怒られ、newlibを入れようかどうしようか迷ってビルドまで通しかけたものの、遅くてもいいや、ということで自前実装した。
NFCIDの生成にrand()も使ってたのだけど、そっちはもう固定値にした。
通ればよかろう、なのだ。


リンクが通ってasp.exeもできたので、TINY-Hを使って焼き、実行。

うん、CPU例外が発生するね。

default_exc_handler()の中でexcnoに例外番号が入る。
これは「例外のタイプ」らしく、私は3になった。

3は、ハードフォールト。英語で書くと、HardFault。
うーむ。

 

こういうときは、逆アセンブル表示させて細かく追おう。
これが、飛ぶ寸前のところ。

image

blx ?
Cortex-M3のことで検索すると、しばしば出てくるような気がする。

http://morizzos-buglife.blogspot.jp/2011/11/gcccortex-m3.html

ああ、blxというのはCortex-M3では使えないらしい。


gccで

  • -mcpu=cortex-m3
  • -mthumb
  • -mthumb-interwork

くらいをつければよさそうだ

 

これがまた、なかなかうまくいかなくてねぇ。

`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
cc1plus: error: bad value (cortex-m3) for -mtune= switch

などといわれるので、ずっとあーだこーどやってた。
しかし、ここで文句を言っているのはcc1plus、コンパイルする前らしい。
そういえば、依存関係のために-MMしてたなあ。

というわけで、-MMのときにはインクルードパスの設定だけ渡して、コンパイル時に-mcpuなんかを渡すようにした。

 

image

blxもなくなった。

実行すると、CPU例外を起こさなくなった。
・・・起こさなくなっただけで、まだまだうごかんねー。

2012/07/16

[os]シリアルドライバのセマフォID

まずはUARTを動かしたかったので、簡単なソースを書いた。

   1: serial_opn_por(1);    //ch4
   2: serial_wri_dat(1, "1234", 4);

 

   1: INCLUDE("target_timer.cfg");
   2: //INCLUDE("syssvc/syslog.cfg");
   3: INCLUDE("syssvc/banner.cfg");
   4: INCLUDE("syssvc/serial.cfg");
   5: //INCLUDE("syssvc/logtask.cfg");
   6:  
   7: #include "xxx.h"
   8:  
   9: CRE_TSK(LED_TASK, { TA_ACT, 0, main_task, 7, 128, NULL });

 

システムログを使うとUART資源が減ってしまうので、切った。
私はFM3のch4を使いたかっただけなので、target_config.hのSIO_PORTIDを1以外にしてしまうという方法もあったのだけど、なんかね。
MakefileにTOPPERS_OMIT_SYSLOGを定義し、それでも呼ばれそうだったのでlogtaskの中をifdefで切るようにした。

このあたりがすぐにわかったのも、OpenOCDでデバッグできたからだ。
よかったよかった。


これでポートオープンはできるようになったのだが、送信ができない。
serial_wri_dat()の中でエラーを起こしているようだ。

よくよく追ってみると、送信するときにセマフォでリソースを確保しようとしているのだが、セマフォIDがおかしいということでエラーにされているみたい(えらく大きい値だった)。

セマフォIDは、syssvc/serial.cの内部に持っている値で、どうも外から設定している気配がない。。。
と思ったら、こんなconst値だった。

   1: static const SPINIB spinib_table[TNUM_PORT] = {
   2:     { SERIAL_RCV_SEM1, SERIAL_SND_SEM1,
   3:       SERIAL_RCV_BUFSZ1, rcv_buffer1,
   4:       SERIAL_SND_BUFSZ1, snd_buffer1 },
   5: ・・・

 

このSERIAL_RCV_SEMxとSERIAL_SND_SEMxがセマフォIDのようだ。
ってことは、固定値なのか。

送信なのでSERIAL_SND_SEM1だったのだが、検索しても芳しくない。
target/cq_frk_fm3_armcc/uvision/kernel_cfg.hか、あとはそれぞれのcfg1_out.cとkernel_cfg.h。
それぞれのcfg1_out.cは、

#define SERIAL_SND_SEM1    (<>)

となっていた。
???
エラーにならんのかい?
いや、そもそもこれはCソースだ。includeして使うタイプなのだろうか。

それに、kernel_cfg.hに定義してあるのにその値になってなかったということは、読み込まれてないということなのだろうか?
いやいや、serial.cには"kernel_cfg.h"をインクルードしている。
うーん、別のkernel_cfg.hを読んでるのか?


途中を省いて結果だけいうと、UARTの割込を有効にしておかないとFM3のUARTオープン途中で設定が終わってしまい、セマフォIDなどが未設定になってしまう、というような感じになっているみたいだ。
target_serial.cのsio_opn_por()の最後にやってる割込マスク解除あたりで何か起こっているみたい。

とりあえず空実装でcfgに追加すると、シリアル出力することがロジアナで確認できた。

   1: INCLUDE("target_timer.cfg");
   2: //INCLUDE("syssvc/syslog.cfg");
   3: INCLUDE("syssvc/banner.cfg");
   4: INCLUDE("syssvc/serial.cfg");
   5: //INCLUDE("syssvc/logtask.cfg");
   6:  
   7: #include "snep_target.h"
   8:  
   9: CRE_TSK(LED_TASK, { TA_ACT, 0, main_task, 7, 128, NULL });
  10:  
  11: CFG_INT(IRQ_VECTOR_MFS4RX, { TA_NULL, INTPRI_SIO });
  12: ATT_ISR( { TA_NULL, INTATR_SIO, IRQ_VECTOR_MFS4RX, NULL, 1} );
  13: CFG_INT(IRQ_VECTOR_MFS4TX, { TA_NULL, INTPRI_SIO });
  14: ATT_ISR( { TA_NULL, INTATR_SIO, IRQ_VECTOR_MFS4TX, NULL, 1} );

 

デバッガとの接続とか、UARTの動作とか、そんな初歩っぽいところでつまると、かなりがっくりしますわ。
昔の私は、もうちょっと応用性があったんじゃないか、とか、そんながっくり感。

 

まあ、歳のせいばかりにしてられないので、ふんばろう。
次はRC-S620/Sに送信して、ACKをもらうところだな。


調べて、やってみてうまくいったものの、UARTと割込の件はあまり納得していない。
FM3に移植したTOPPERS/ASPを使ったサンプルで、そういう記述がないからだ。
システムログをまったく止めたことで悪影響が出ているのか、なんか考え違いをしているのか…。

   1: /*
   2:  *  シリアルI/O割込みのマスクを解除する.
   3:  */
   4: if (!opnflg) {
   5:     ercd = ena_int(p_siopinib->intno_rx);
   6:     assert(ercd == E_OK);
   7:     ercd = ena_int(p_siopinib->intno_tx);
   8:     assert(ercd == E_OK);
   9: }

 

この部分。
ここでassert()を通っていたのだ、割込を有効にしていなかったら。

_kernel_bitpat_cfgint[]を見て、割込が有効じゃなかったらエラーを返すような感触だった。
でも、assert()を通ったからといって死ぬわけでもなく、進んだようだった。
これはコンパイルオプションとかの関係かもしれん。

このあとはreturnで値を返すだけで、assert()するだけで死ななかったら、他に影響を及ぼすような感じもしない。
しないのだけど、spcb_table[].p_spinibの値が変わってたのよねぇ。

デバッガでアドレス指定の書き込みブレークなんかも設定できるんかいな。
できるなら、そのタイミングを見ればいいんだけど。

[openocd]なんとなく動く

OpenOCDで、まだ怒られる。
GDBが何か要求したけど、そんなレジスタはないぞ、といっているようだ。
image

ftd2xxドライバに変更してビルドし直したけど、そういう問題でもないようだ。

けっこういろいろやったあと、また参考サイトに戻ってやってみた。
http://todotani.cocolog-nifty.com/blog/2012/05/fm3openocd-ecli.html
動く・・・
LEDが点滅するサンプルで試したのだが、これなら動くんだ。

でも、TOPPERS/ASPのサンプルはだめだ。。。
なんだろうねぇ。

Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff01c
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff01c
Warn : Block read error address 0xe59ff018
Info : JTAG tap: mb9bfxx6.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Error: mb9bfxx6.cpu -- clearing lockup after double faulttarget state: halted
target halted due to debug-request, current mode:
Handler HardFaultxPSR: 0x00000003 pc: 0xe59ff018 msp: 0xe59feff8
Polling target failed, GDB will be halted. Polling again in 100ms
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff014
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff014
Warn : Block read error address 0xe59ff010
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : Block read error address 0xfffffff8
Polling succeeded again
Info : dropped 'gdb' connection
Info : accepting 'telnet' connection from 4444
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff01c
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xe59ff01c
Warn : Block read error address 0xe59ff018
requesting target halt and executing a soft reset
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0xe59ff018 msp: 0xe59ff018
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc
Warn : Block read error address 0xfffffff8


そんなに壁が高くて厚いとは・・・。

あれ・・・TOPPERS/ASPの自作サンプルが、普通にやっても動かんやん。
前回動いてたはずなのに・・・と思ったら、間違ってた。
まあ、よくあることだ。
今度は、焼いて動くことを確認してからOpenOCDと接続。
動くやん。
ブレークポイントで止まるやん。
まあ、よくあることだ。

今回は、Eclipse上でやった。
Insightのビルドができないので諦めてたけど、ビルド済みのものがあるらしい。
まあ、気が向いたら今度試そう。
以前は日本語がまったくだめだったのだけど、今はどうかな?

こちらを参考にしてます。
http://todotani.cocolog-nifty.com/blog/2012/05/fm3openocd-ecli.html
OpenOCDは、ビルド済みの0.5.0を使った。
FLASHは512KBまでだけど、まあいいや。

OpenOCDの起動設定

初回は、設定をする。
ここの2番目にある「openocd-0.5.0」ってのを作る。
image
こんな感じで。
Working Directoryを「選択してるプロジェクト」にしておくと、FLASHに焼くときが楽。
プロジェクトをひょいひょい切り替えるのだったら、あんまり効果がない。
タブ「Main」以外は入力してない。
image
Argumentsで指定しているcqfm3.cfgは、参考サイトのものそのまま。
チップ名が「mb9bfxx6」だけど、これをxx8とするとエラーになる。
これは、OpenOCDが0.5.0では対応していないからだろう。

デバッグ設定

今度は、デバッグ。
初回は、設定を行う。
image
zylinというプラグインが入っている前提で。
image
Cygwinのほうでやるみたいだ。
プロジェクト名の選択を取りあえずやって、C/C++ Applicationは短いので直接入力した。
image
mainで止まる、みたいな設定はあんまり有効じゃないらしいから、もう切っておく。
gdbは、PATHに設定済みじゃなかったらフルパスなのかしら? ようわからん。
image
参考サイトそのままだったけど、FLASHに書き込むのは自分でやるので、loadとかを外した。
break mainは効くのかな?
「tbreak main」かも。
TOPPERS/ASPだと、mainで止まっても仕方ないかもしれないので、メインタスクか何かにブレークポイントを張っておくのかいな。

OpenOCDの起動

ARM-USB-TINY-HとFM3基板を接続し、PCに接続してFM3にも電源を供給したあと、EclipseのProject Explorerからデバッグしたいプロジェクトをクリックしたあと、作ったコマンドを実行する(プロジェクトをクリックしてなかったら、エラーが出る)。
そうするとずらずら何か出てきて、最後にブレークポイントがいくつだ、などと出てきたら、たぶんうまくいってる。
TINY-HのLEDが点滅を始めるようだ。

telnet

コマンドプロンプトを立ち上げて「telnet localhost 4444」と打つ。
うまくいくと、「Open On-Chip Debugger」という文字が出てくる。

FLASHを焼く

telnet上で「flash write_image erase asp.srec」と打つ。
「asp.srec」は、コンパイル時にできたSレコードのファイル(たぶん)。
うちだと、11KiB/sくらいで焼いてくれた。
焼きたくないときは、焼かなくていいだろう。

デバッグの開始

つくったデバッグ設定を実行する。
パースペクティブの切替とか始まって、うまくいくとどっかで止まる。
今やったら、「tbreak main」の実行で「mainは定義されてないぞ」っていわれた。
TOPPERSではmain()は作ってないのかも(sta_kerか?)。
エラーもなんかでるけど、ブレークポイントには止まってくれるから気にしなくていいのかも。
ようわからん。
image
ハンドラでブレークすると、スレッド表示が増えてた。
image
と思ったけど、単なるスタックトレースみたいね。

やり直し

途中まで実行して、やっぱりやり直そう、と思った。
リセットさせるようなボタンもないし、telnetで「reset」とやっても動きが変になった。
あきらめて、Thread表示のどこかにフォーカスを当てた状態で赤い四角を押して終了させ、もう一度デバッグの開始からやり直すことにした。
OpenOCDは起動させたままでもよさそうだ。

終わらせる

もういいや、と思ったら、OpenOCDごと終了させる。
image
OpenOCDの方をクリックしてフォーカスを当てて、赤い四角を押す。
arm-none-eabi-gdbの方がどうなるかわからないけど、気に入らなければ下図の右側にある××を押して消せばいいと思う。
私は気になるので、とにかく消している。
image

なんか変になったとき

とりあえず、OpenOCD関係のものを落として(Eclipseはそのままでいいかも)、基板も電源を落とし、TINY-HもPCから抜いて、一息入れてからやり直すといいと思う。
やり直すときも、そうした方が安全な感じだ。


まだまだわからんところは多々あるが、なんかは動いたのでよしとしよう。
Eclipseの恩恵を受けているような受けていないような、そんな微妙な感じは残るのだが、まあよしとしよう。

CQ FM3基板+TOPPERS/ASPで試したLED点滅のサンプルを置いておこう。
こういうファイルは、自分ですぐ変更して動かなくしてしまうので、一度確定させておかねば。
https://sites.google.com/site/hiro99ma/home/files/other/cqfm3_led_sample.zip?attredirects=0&d=1

OpenOCDがまだ動かん

私はこんなこともできんのか・・・とがっくりだ。

まだOpenOCDがまともに動いていない。
FLASHに焼いたりとかはできるのだけど、デバッグができないので意味がないのだ。

オリジナルのビルド版0.5.0だと、何かは動いていたのだ。
ステップ実行したりできたし。
しかし自前のやつを使うと、だめ。
だめだだめだー。

 

やはり、OpenOCDの説明をまったく読まずに、ネットで動いている人の情報だけでやろうとするから、いろいろと違う部分の意味がわからずに苦労するのだ。
もう少し調べよう。

OpenOCDをARM-USB-TINY-H向けにビルド

OpenOCDがうまくうごかん。。。
どうやら、OpenOCDというのは自分でビルドするもののようだ。

FM3は最近になってOpenOCDに追加されたようなので、OlimexのCD-Rには含まれていないのだろう。


うちでは、cygwinを使っている。

 

OpenOCDを落としてくる

git://openocd.git.sourceforge.net/gitroot/openocd/openocd

 

その前に、libftdiを落としてきて、configureとmakeとmake install

http://www.intra2net.com/en/developer/libftdi/

 

OpenOCDをビルド

最初は適当にやっていたのだが動かず(あたりまえ)、Olimexのサイトを見ると、OLIMEX ARM DEVELOPMENT PACKAGE V1.1にOpenOCDの最新版をビルドする方法が書かれている、と書いてあった。
ここにたどり着くのに、何時間かかったことやら。。。

ただ、このままやってもFM3は対応がもうちょっと必要らしい。
手順は、ここを見てやった。
http://nemuisan.blog.bai.ne.jp/?eid=188402

OpenOCDにあてるパッチファイルは、こっちに入ってたものを使った。
http://jujurou.blog34.fc2.com/blog-entry-294.html

$ patch -p1 < openocd_temp/mb9bf618.patch
$ patch -p1 < openocd_temp/armv7mx.patch

ビルド。

$ ./bootstrap
$ ./configure --enable-maintainer-mode --disable-werror --disable-shared --enable-ft2232_libftdi

ビルドが通ると、/src/openocd.exeができている。

あとは、tcl/内にあるものとopenocd.exeをどっかに放り込んだ。

 

動作確認。

C:\Winappli\openocd>openocd -f cqfm3.cfg
Open On-Chip Debugger 0.6.0-dev-00620-g2aab7d3-dirty (2012-07-16-00:36)
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
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 : accepting 'telnet' connection from 4444

 

とりあえず、動いたようだ。
まあ、皆さんのやってることを後追いしただけだがね。

2012/07/15

ARM ICEを買いました

とうとう、ARMのICEを買ってしまいました。
あーあーあー。

買ったのは、ストロベリーリナックスさんから。
OLIMEXのARM-USB-TINY-H

 


とりあえず、分解。

 

20120715a

 

反対側。

 

20120715b


大きいチップは、FTDIの2232HL。

2232HLか・・・。
いや、このチップが悪いわけではなく、仕事で使っているので感慨深いだけだ。

2232HLは、2つのインターフェースがある。
USBの口としては1つなのだけど、相手側が2つあるのだ。
ホスト側はMPSSEというプログラマブルな部分があり、相手がUARTやSPIみたいなものでも制御できるし、WindowsやLinuxならライブラリもメーカーが提供している。

うん、提供している。


写真を撮るときには、1つ注意しておこう。

それは、動作確認を終わってから撮影すべし、だ。
だって、初期不良とかもあり得るのだから、それを行わずに分解してしまうと保証がなくなってしまうではないか。

 

当たり前のことだけど、忘れていたので書いておこう。
最近、こういう凡ミスが多いんだよなあ(動かしていないだけだ)。

2012/07/14

[nfc]B (3)

NFCID0は、毎回取得するたびに変わる。
とはいえ、仕様としては「電源ON時」だったと思う。

なら、搬送波が出ている間なら同じ値が取れるのか?

 

と思ってやってみたが、2回目はInListPassiveTargetに対する結果が、NG。
NbTgが0になっているのだ。

ほほぅ。
すぐに2回目をやったからかもしれん、と1秒開けてみたが、そういう問題ではないようだ。

他のはどうなんだろう、と思ってやってみると、NFC-F(FeliCa Lite)は、2回目も成功。
Mifare Classic 1KとMifare Ultralight Cは、2回目がNG。

ほほぅ。
よく知らない仕様が、まだまだあるんだろうな。

PC/SC

免許証がICカードになったので、カード仕様が公開されている範囲でどこまで読めるものなのか見てみようとしている。

ええ、性格的に(自分が思っている)悪いことはしないんですよ。


SDK for NFC Starter Kitでも説明はあるが、どうやら「PC/SCアクティベータ for Type-B」なるものが必要らしい。

PC/SCねぇ。。。
私のイメージでは、PC/SCは単なるインターフェース仕様で、アプリ層の共通化を目的としたものだ。
だから、PC/SCでアクセスするソフトを作ったとしても、ドライバ部分を作ってR/Wコマンドに置き換えないといかん。

じゃあ、最初からR/Wコマンドでもいいやん、と思ってしまうのだ。
(R/Wメーカーが共通インターフェース仕様を出す、というのがありがたいがね。)


しかし、なぜType-BはPC/SCのインターフェースがよく使われるのだろうか?

住基カードやICパスポートなんかもType-Bらしいが、情報がなかった。

 

IPAの資料は全部読んだわけではないが、いろいろ書いてあった。

  • 相互運用するためにはインターフェースの共通化が必要
  • インターフェースはISO/IEC 7816で定義されるけどセキュリティなどが関わるとカードごとに違いが出てくる
    • PKCS#11
    • ベンダ独自ミドル
    • ベンダ依存のデータモデル

雑誌Interface誌の2012年4月号にPC/SCについての記事がある。
これを読むと、PC/SC 2.0ではISO/IEC 7816をベースにしてISO/IEC 14443まで拡張したものということだ。
zipファイルをダウンロードしようとしたが、ファイルがないといわれたので、やめた。
(個別でPDFをダウンロードするほどの気力はない。。)

 

共通化したかったのと、セキュリティは必須だったのが相まって、Type-BならPC/SCでセキュリティの部分を共通化できるしいいんじゃないの、ということだったのかなあ。

こういう、決定したらかなりな長期間変更できない仕様を決めるのって、大変そうだ。


では、私もPC/SCでアクセスして・・・という気にはならない。
実際にPaSoRiに流れているデータをキャプチャする、という手もあるのだろうが、私の好みではない。
あくまで仕様書から正しく情報を得て、その通りに動くことを確認したいのだ。

まあ、急ぎではないので、μITRONを先にやらんといかんかな。

[nfc]B (2)

健康診断の前日は、昼が貧弱、夜はバグがなかなか取れずに食事限界時間を過ぎたのでさらに貧弱。
貧弱貧弱ゥ。。。という声が聞こえてくるくらいで、ひどく機嫌が悪い。

ストレス発散のため、更新しておこう。

(なんで3連休の初日に健康診断なんて入れてしまったんだ。。。)


PN533のドキュメントを見ながら、PaSoRiを動かすことにした。
SDK for NFC Starter Kitには、ちゃんとNFC-Bのアクセスができるようになっている(はず)。

だけど、Windowsのソフトを組むような気力はないので、Cygwinからlibusbを使うことにした。
した、というか、そういう環境がすぐにあったというだけだ。

 

カード検索は、InListPassiveTargetを使う。
4Aコマンドだ(数字で覚えておいた方が、ログを見るときは楽)。
パラメータは、0x03らしい(PN533ドキュメントより)。
AFIは、0x00でとりあえずやってみた。

[R]50
[R]43
[R]00
[R]89
[R]04
[R]00
[R]00
[R]00
[R]00
[R]b3
[R]81
[R]c1
[R]01
[R]01

PN533ドキュメントによると、赤文字はATQB、青文字はATTRIBになる。


ATQBをさらにわける。
ここからは、NFC Forumを参照。

 

[R]50
[R]43
[R]00
[R]89
[R]04
[R]00
[R]00
[R]00
[R]00
[R]b3
[R]81
[R]c1

青文字が、NFCID0。4byte固定。
これは毎回変わる。試していないが、搬送波を出している間は同じ値になるはず。

赤文字が、Application Data。

[R]00  AFI
[R]00  CRC_B(AID)[0]
[R]00  CRC_B(AID)[1]
[R]00  Number of application

全部0x00なので、よくわからんな。

 

茶文字が、Protocol Info。

[R]b3  Bit_Rate_Capability
[R]81  [FSCI:4][Protocol_Type:4]
[R]c1  [FWI:4][ADC:2][FO:2]

読み取れるのは、

  • Listen ModeとPoll Modeは同じbit rate divisor
    • 2と4をサポート
  • 最大フレームサイズ:256bytes
  • NFC Forum Device in Listen Mode compliant
  • TR2 : 1792/fc
  • Frame Wainitng Time Integer : 4
  • Advanced protocol features not supported
  • Application is proprietary
  • NAD not supported
  • DID supported

よくわからんし、あまり関係ないような気がするので間違ってるかもね。


ATTRIB_RESがよくわからん。

最初のがLengthで、その次がLength分だけデータがひっついてくるらしい。
スロットについてかな、という気もするが、PN533の例でもこんな値だから、まあいいや。

 

さて、あとは中身を読むだけだ。
仕様もある、とまどろみさんがいっているから、ちゃんとやれば動きそうだ。

 

あー、おなかすいた。

2012/07/13

[nfc]B

Fはやった。
Aまでやった。
しかし、しかしBは・・・。

そして今日、免許更新によってBのカードが手元にやってきた。
はじめてのNFC-Bである。


初回なので、まずはポーリング。
NFC-Bの使い方は知らないけれども、SDDというか、カードを見つけるしくみは他のと同じで、SENSB_REQ/RESを使うことになりそうだ。

と、記憶だけで話してみたが、実際はよくわからん。
とりあえず、昔実装したまま使ったことがなかったAPIを呼んでみよう。

 

うん、昔の私は偉かった。
何か返ってきた。
これは、どこまでどうなのかってのはあるが、0x50に続く4byteはPUPIだったはず。
NFCID0で、AとかFみたいにカードに紐づけられておらず、NFC-Bカードに電源が入ったときに生成するランダムな値になるとか。
PUPIは、Pseudo Unique PICC Identifierの略だ。

 

試してみると、確かに毎回異なる値が取得できるみたいだ。
とりあえず、Bデビューした、といってもいいんじゃないかね。

2012/07/08

[nfc]SNEPの資料をつくった

TOPPERSのことばかり書いていて、NFCはやめたの?と思われそうなので、資料を作った。
最近までやっていた、SNEPのことだ。
以前「一人でもNFC開発」というスライドを作ったので、なんとなくシリーズ化してみた。

やっぱり、背景はグラデーションとかかけない方がいいかもね。
モアレがかってしまった。

内容は、これも以前作った「FALPとLLCP」のLLCPを抜き取って、SNEPを追加したようなものだ。
ただ、あのときにはわからなかったものが、実装してわかったこともあるので、多少は具体的になったところが気に入っている。
それに、テンプレートとかクリップアートとかを使ったので、今までの中では派手な方だと思う。

さらに細かいところは、スライドでやってもわかりにくいので、なんかもういいかなって気がしている。
ここにもさんざん書いていたしね。

NFC-DEPの個人資料は作っていたので、EPUB化して置いてみた(ここ)。
「なぜEPUB ?」と思われそうだが、私が使っている一太郎2012がEPUB出力に対応したのでやってみたかっただけだ。

[os]SkyEyeとGDBで接続できんのはSkyEyeバグらしいのでGDBバージョンを落とした

こんな組み合わせで動かそうとしているが、うまくいかない。

SkyEye
skyeye_devm_package-1.0.5.zip

$ arm-none-eabi-gdb --version
GNU gdb (Sourcery CodeBench Lite 2012.03-56) 7.2.50.20100908-cvs

 

$ ../../skyeye/bin/skyeye.exe -d

(中略)

big_endian is false.
arch: arm
cpu info: armv3, arm7tdmi, 41007700, fff8ff00, 0
mach info: name at91, mach_init addr 0x41d650
uart_mod:0, desc_in:, desc_out:, converter:
SKYEYE: use arm7100 mmu ops
debugmode= 1, filename = skyeye.conf, server TCP port:12345
Remote debugging using port:12345
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.

 

$ arm-none-eabi-gdb asp.exe
(中略)

Reading symbols from e:\prog\toppers\eclipse\sample1\asp.exe...done.
(gdb) target remote localhost:12345
Remote debugging using localhost:12345
vector_table () at ../../asp/arch/arm_gcc/common/core_support.S:61
61          ldr pc, reset_vector       /* リセット             */
Trace is already running on the target.
Reply contains invalid hex digit 117
(gdb)


現象としては、これだろうと思う。
これが解決したのが2011年の1月4日、TOPPERSのSkyEyeの1.0.5リリースが2010年11月1日。

GDBが7.2だとうまくいかなくて、7.1だとうまくいくようなので、Interface誌に書いてある「動作実績のある」バージョンじゃないってことなのだろう。

うーむ。

GDBのバージョンを下げるのがてっとり早いか。。。

 

うん、動作確認できている2010q1-188だと動いた(NU gdb (Sourcery G++ Lite 2010q1-188) 7.0.50.20100218-cvs)。


では、Eclipseのリモートデバッグに切り替えよう。
本当はinsightを使ってやろうと思ってたんだけど、cygwinでコンパイルエラーになってね。。
Tcl/Tkとかなんとかの移植に関するところみたいで、ずっとやってたけど腹が立ったので、Eclipseでやろうと思った次第だ。
最近はinsightの話を聞かないと思ったけど、Eclipseがあるからいいか、というとこなんだろうな。

 

やりかたは、こちらのページに従った。
実際は、この手順通りにやってもうまくいかなくて、コマンドラインからgdbを実行しても動かなかった、というのがさっきの話なのだ。

Eclipseからも、GDBを古いのにすると動いた。
やれやれ。。。あれ、フォントが化けている。
TOPPERS/ASPはEUC-JPらしいので、Eclipseのプロジェクト設定でテキストのエンコードを・・・選択しにEUC-JPがない!

検索すると、直接「EUC-JP」と打てばいいんだとか。
やると、直った。
やれやれ、ようやくスタートラインに立てたようだ。

[os]SkyEyeというシミュレーション環境

ここまでやってようやく知ったのだが、SkyeEyeというTOPPERSカーネル向けシミュレーション環境があるようだ。

Interface誌2012年5月号には「TISE」となっているが、ホームページではISSになっている。
SkyeEye自体は、ARMだけじゃないシミュレータらしい。
それをTOPPERS向けに拡張してあるとか。

 

私は勉強目的でやるから、最適だ。

これを見つける前に、とうとうARMのJTAGデバッガを注文してしまったのだが、まあそれはそれでよかろう。

[os]オリジナルだと動いた

動かん動かんといっていたTOPPERS/ASPだが、そういえばオリジナルのまま動かしてなかったな、とやってみると、あっさり動いた。

うん、よくあることだ。

シリアル入出力が必要、というのはサンプルソフトの動作として必要なだけで、TOPPERS/ASPとして必要なわけではないようだ。


そういえば、TOPPERS/ASPを使ってRC-S620/Sを動かすサンプルがあったよな、とInterface誌4月号を開いた。
第8章に載っているが、いくつか誤記がある。

  • p.100 : 図5の(a)はInListPassiveTargetコマンドで、(b)がRFConfigurationコマンド
  • p.100 : 図5の(a)にシステム・コード(リトル・エンディアン)とあるが、ビッグエンディアン
  • 全体的にシステムコードをリトルエンディアンで書いてあるので、それがビッグエンディアンになる。

まあ、リトルエンディアンだと思って全体がそうなっているので実装としては間違わないと思うが、仕様書を読んだときに困るかもしれんな。
無線のような通信系がリトルエンディアンというのは、あんまりないと思う。
だが、NFC-Fコマンドのいくつかはリトルエンディアンを含んでいるので注意がいるな。

細かいことだが、カード検出にInListPassiveTargetを、システム切り替えにInCommunicateThruを使ってPOL_REQを送信しているが、どっちもInListPassiveTargetでやった方が安全な気がする。
R/Wが内部で状態を持つことがあるので、「ポーリングしたいのだ」という意志を持ったコマンドを使った方がいいかな、という程度だ。

それなら最初から共通領域向けのポーリングでもいいような気がするが、どうなんだろうね。
FeliCaのガイドライン通りにやると、検索はワイルドカードで行い、その次にシステムコード指定、となっているから、そうした方がいいんだろう。

つらつらと書いたが、TOPPERS/ASPで書くときの参考にさせていただこう。

それにしてもこの人、Interface誌のいろんな記事で見かける。
いろんな記事で、ということは、幅がかなり広いということだ。
どんな人なんだろう、と調べてみると、すごい人のようだった。
http://www.jasa.or.jp/et/ET2011/visitor/program_dvt.html


まあ、その前にTOPPERS/ASPのお勉強からですな。

[fm3]PizzaFactoryを使ってみよう

あれからずっとTOPPERS/ASPをやっているが、動かん。
QEMUでも動かない。
ネットにあったGCCでビルドできるプログラムを使ってみたが、これもQEMUでは動かなかった。
焼けば動くので、QEMUではなんか動かないものがあるのかもしれん。


ここで悩みたくないので、Interface誌に載っていたPizzaFactoryを試すことにした。
ずいぶん昔に試したことがあったような気がするが、あれはなんのときだったか。。。
今ではバージョンが8になっているようで、付属DVD-ROMにはCQ版が入っていた。

なんで試すことにしたかというと、GDB内蔵エミュレータがあるようだったからだ。
QEMUで動いたとしても、デバッグをどうやろうか考えてなかったので、GDBでデバッグできるなら願ったり叶ったりだ。

インストールはすんなりいったのだが、雑誌のとおりにやっても動かない。。。
パッチがあるようだったので手順通りにやったが、それでもだめだ。
(手順の最後で「Install New Software...を実行」とあるが、実行してから何するのかがよくわからんかった。とりあえず、Work withにPizzaFactoryのURLがあったので選択し、出てきたものに全部チェックしてインストールした。)

Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:10000

こんなことをいわれる。
remoteだから、ポートをFirewallとかが遮断してるのかと思ったけど、そうでもない。
雑誌には特に書かれてないし。。。

と思って図を見ると、「Remote Target」のチェックが外れている。
デフォルトと異なる部分は、書いておいてほしいな。。。
はずすと、次に進んだ。そしてエラー。

次のエラーは簡単だった。
そんなファイルはないよ、である。
説明に「fileに続けてフルパスで」と書いてあったので、Windowsのフルパスを書いていたのだが、デリミタが\ではなくて/にせんといかんかった(図もそうなってた)。
まあ、GDBだからそうなんだろうけどさ。。。


気を取り直して、TOPPERS/ASPに付属していたサンプルソースを動かしてみた。
プロジェクト作成をPizzaFactory用にしてないから、動かないかも。。。

案の定、動かない。
エラーにはならないが、進まない。
止めると、こんなのが出てきた。

Program received signal SIGINT, Interrupt.
0x0000003c in _kernel_vector_table ()

ベクタテーブルは0x00000000から配置されるようだ。
アドレスを書くだけみたいなので、4で割って15。
15番目は、SysTick Handlerのようだ。。。。ではなく。

ベクタテーブルはアドレスだけだから、PCがここに来てはいかんのだ。
やはり、PizzaFactory用じゃないとだめなのか。

2012/07/07

[os]TOPPERS/ASPを使ってみよう

いきなりだが、TOPPERS/ASPというμITRONを使ってみようと思う。
人間、唐突なこともあるのだ。

自分でタイマを引っ張り回すのもめんどくさそうなので、既にあって使えそうならば使うのが楽だろう。

それに、私はμITRONというものをまったく知らない。
10年くらい前にセミナーに行ったようなのだが、記憶がない。。

雑誌Interface誌の2011年4月号を読みながら基礎を学ぶのがよさそうだ。
環境は、せっかくなのでFM3基板を使おう。幸いなことに2012年7月号でASPの移植も行われている。


2012年7月号のApp3に書かれた順序で、makeまで通った。
ただ、この手順で作ったサンプルは拡張基板がないと動かないらしい。
では、シンプルにLEDが光るだけのサンプルを作ってみよう。

光るだけだとなんだかわからないので、点滅がいい。
2011年4月号の第3章にそのままのサンプルがあったのでまねをした。
これはLPC2388用で基板も持っているのだが、FeliCa Plugがせっかくつながっているので残しておこう。

ビルドは通ったが、ちょっと気になることが。
2012年7月号の説明には、サンプルでは拡張基板のシリアル入出力を使っているということだった。
なんか悪さをしたらいかんので、asp/target/cq_frk_fm3_gccの中に入っているシリアルっぽいファイルを削除した。
そしたら、ビルドが通らんごとなった。。。

 

どうもシステムログが関係しているらしい。
あちこちファイルを探したがよくわからないのでネット検索したところ、TOPPERS_OMIT_SYSLOGという定義をするとシステムログ関連を組み込まなくなるようだった。

試すと、ビルドが通った。
そしてソフトは・・・動かなかった・・・。
target_initialize()のとこにLEDが光りそうな記述をしたのだが、光らず。
うーむ。

[nfc]ISO/IEC 18092を読み直す

SNEPがなんとなく動いたので、NFCはしばらく放置しそうな気がする。
しばらくというのは、自分がNFCのついた端末を何か買うまで、とか。

その頃にはすべてを忘れていそうだから、少しずつ整理していこう。


 

タイトルにISO 18092って書いてるのに大人は嘘つきだ!と思われそうだが、そうではないのだ。
私のイメージでは、NFCIP-1という仕様があり、それをISO/IEC 18092とか、ECMA-340とか、JISX-5211とかで実体化させている、なのだ。
まあ、本当にそうなのかどうかは知らんけどね。


NFC ForumのDigital Protocolドキュメントと近い位置関係になると思う。

NFCIP-1の方が処理フローなどが図になっているので見やすい。
SDDのやり方なんかは、こっちを読まないとわからないんじゃないかな、と思う。
まあ、SDDを把握したからどうなるってのはあるんだけど、NFCIDの取得をどこでやってるのかというのは興味深いのではなかろうか。

データ交換についても、こちらを読んだ方が「どういうことなのか」がわかりやすい。
こっちを読んでからDigital Protocolを読み直すと、ああそういうことか、と理解しやすかった。

 

そうなると、NFC Forumドキュメントは役に立たないのか、というと、そうではない。
ISO/IEC 14443やISO/IEC 18092、それにNFCIP-2であるISO/IEC  21481(というよりも、14443のType-B)をまとめて、整理したというところが重要なのだ。と思う。