DAQ Test Log
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
#attach
[[準備 ]]
*2011.8.12 new v1190 動作チェック [#l6142c31]
-全てこれまで同様のアドレス、ウィンドウ等でチェック。
-動くことは確認。
-bit落ちはとりあえずDAQの都合上少し放置。(一応現状でも統計がたまれば十分見られるはずなので、パラレルに進める)
-試しにMCPのバックグラウンドラン。基本的には大丈夫。が、z_sum v.s. z_subの傾きが変わった。
-tdcのch間のばらつきなどがもしかするとある?
-これも今後パラレルにチェック。
*2011.7.29 TDC bit落ち調査 [#d856f5f1]
-データファイルの追加
-その1 &ref(bitKEK_1.root); &ref(bitKEK_1.dat);
-その2 &ref(bitKEK_2.root); &ref(bitKEK_2.dat);
*2011.7.25 TDC bit落ち調査 [#xe444f31]
-KEKにて、これまでとは別のv1190、bit3、rpv130、vmeラック、PCを用いてテスト
-こちらでもその辺にあったpmtを使って、ランダムな信号をつっこんだ。
-その結果、bit落ちは見えた。
-ただし、chは異なるようである。(絵はkekのPCに入っているままなので後で追加)
-これまでの試験の結果も踏まえると、やはりtdcそのものが悪い(そういう仕様?)あるいは、読み出し部(デバイスドライバ?)あたりがあやしい模様。あるいは、
あまり関係ないかもしれないが、micro handlerのfirmwairのバージョンをあげてみると案外サックと直るのかもしれない。
-今後は、firmwairのアップデートor別のデバドラ(例えばKEKで過去に使っていたもの)を使って測定をしてみる予定。
*2011.7.20 TDC bit落ち調査 [#yf6af32f]
-その辺にあったシンチ+PMTを用いてランダムな信号をTDCにつっこむ
-まずはMCPの時と同じTDCのセッティングで取得→同じ傾向が見える。
-trigger subtractionをdisableにしてみる→変化なし
-triggerのパルス幅を極限まで小さく(20nsecちょっと)してみる→変化なし
-(ちなみに通常は25nsec)
-triggerを入れるタイミングのみずれしてみる→変化なし
-chを変えてみる。(32ch×4のチップで処理しているので、別のチップにいれてみる)→変化なし
-TDC resolutionを変えてみる→変化なし
-ここまでの段階で、やはり内部clkかバッファ部がおかしい気がする。
-次は外部clkを与えてみる予定。コネクタ等がないので要購入or調査+工作
-2pinコネクタで使えそうなものを見つけたのでケーブル作成
-外部から50MHz Clkを与えて測定→tdc chはclkに対応して変化。だがbit落ちは変わらず。
-というわけで、clkのタイミングというよりも、バッファ部や、データ部の方が問題である可能性が高い。(あるいはそもそも壊れているか。)
*2011.7.19 TDC check [#x9b140e5]
-分解能に関して、マニュアルを再度調べると、内部クロックを最大で回した場合は98psとのこと→reasonableな値であった。
-bit落ちチェック。
-使用データ:MCPにβ線源を一様にあてたときのもの(testMCP_1.dat-testMCP_8.dat)~
-データ取得環境等は追々。
-それぞれのデータに対する、ch0~ch6のtdc hitヒストグラムと抜けているビット~
-(ビット落ちの定義はtdc値=0 & 隣あうtdc値との差が10以上)
-データセット、マクロ &ref(./testMCP.zip);
-testMCP_1 &ref(./MCP_1.root); &ref(./bit_1.dat);
-testMCP_2 &ref(./MCP_2.root); &ref(./bit_2.dat);
-testMCP_3 &ref(./MCP_3.root); &ref(./bit_3.dat);
-testMCP_4 &ref(./MCP_4.root); &ref(./bit_4.dat);
-testMCP_5 &ref(./MCP_5.root); &ref(./bit_5.dat);
-testMCP_6 &ref(./MCP_6.root); &ref(./bit_6.dat);
-testMCP_7 &ref(./MCP_7.root); &ref(./bit_7.dat);
-testMCP_1 &ref(./MCP_8.root); &ref(./bit_8.dat);
-これを見る限り、必ず同じビットで落ちている模様。
-今のところパッと思いつくのは、
--TDC(バッファ部)そのものが壊れている
--triggerと内部clkとの同期がうまくとれていない
--データ構造がたまに同じところで壊れる
-など。
*2011.7.15 TDC time resolution measurement [#u62b43bb]
-時間分解能をはかる。
-Clock gen.からの信号を計測し、tdc hitの差分をみてやる。
-1,2,5,10MHzのシグナルを入れる。
-(1000, 500,200,100nsecが見えるはず。)~
&ref(./1000nsec.gif,50%);&ref(./500nsec.gif,50%);~
&ref(./200nsec.gif,50%);&ref(./100nsec.gif,50%);~
-横軸はTDC chの差分⇒もし100psならば、100nsecは1000chになるはず。
-しかし、結果は微妙に異なったようだ。
-1000nsec:10240ch
-500nsec:5120ch
-200nsec:2048ch
-100nsec:1024ch
-→分解能:97.7ps
-linearlityもこの範囲では問題なし。
*2011.7.12 テスト用DAQソフト [#h5acbc35]
-ver.0として作成。
-とりあえず生データをひたすらテキストでつめる。
-データフォーマットは、~
ffffffff~
ch val~
ch val~
ch val~
・・・~
ch val~
のようにヘッダ+2列のデータ~
-プログラム &ref(testDAQ.zip); ~
*2011.7.12 v1190テスト [#g50c6990]
-データ取得確認
-ch毎に読めていることも確認
-時間分解能に関して。clk 1M 5M 20M Hzを入力したときの得られた生データの各ビット間隔は10240, 2048, 1024。これだと分解能は~98ps。正しい?
-仮に違ったとしても、データの読み方のみをかえればよいと判断。
-とりあえずDAQ ver.0を作ることにする。(rpv130+v1190)。
-v1190のテストプログラム &ref(v1190_test.zip);~
*2011.7.5 v1190テスト [#d8e032f0]
-RALで用いているコードを見せてもらい、チェック。
-設定パラメタは基本的に同じ。
-ソフト的には問題なし。
-もう一度ハード的に見てみる。
-以前とは異なりちゃんとした50Ωターミネータでtrigger lineをターミネート。
-値がつまった!
-はずしたりしつつ再現性チェック→再現を確認。
-試しに以前と同じターミネートの方法(lemoから他のモジュールの50Ω終端におとす)でチェック→見えない。
-以前の方法では、実はちゃんとターミネートできていなかった模様。
-今後細かくチェックを進め、DAQ全体コード実装まで進める。
*2011.7.4 v1190テスト [#b46ec97e]
-ドライバ変更前にもう少しだけトライ。
-bit3側のジャンパを少し変えてみる。→変わらず。
-レジスタアクセスの際、32ビット転送がうまくいっていない可能性を少し疑う。
-マップサイズを大きめにとってみる。→変わらず。
-base addressをまた変えてみる。→変わらず。
-vector、IRQレベルをいじってみる。→変わらず。
*2011.6.24 v1190テスト [#c6312b1e]
-23日にできなかった分(元のクレートで試したこと)を試す→変わらず。
-クレート返却のため撤収→元のクレートに戻す。
-友野さんからコメント。
-同様にハマったらしく、その時はデバドラを変えたら行けたとのこと。
-ioctrlかbus accessのあたりがkinokoではだめということか?
-とりあえず保留してcollab. meet.後にその辺を変えてみる。
*2011.6.23 v1190テスト [#d7a4f0ca]
-借りたクレートで、ケーブルスワップ等以前と同様の変更など。→変わらず。
*2011.6.22 v1190テスト [#m205aaf6]
-KEKからモジュール到着。
-早速導入。ちなみにtermのswitchはoffになっていた。
-base f0030000
-同様の挙動。。→モジュールそのものはこわれていないということか。
-セットアップparametersをKEKのものと全て揃えてみる→変わらず。
-数時間ならば他のVMEクレート+bit3を借りてよいということなので借りてそちらで試してみる。
-クレートを変更してみたが、なぜかinterrupter(正確にはsignal handler部)がうまく作動しない。
-base address, IRQ level等も変更してみたがinterruptのみうまくかからない。
-outputは出る。
-クレート+bit3を借りられる期間を今週いっぱいに変更してもらえた。
-もう少しだけいじってみて、無理そうならば時間の無駄になるのでクレートは返却して他の方法を試す。
-interrupter問題は解決。bit3本体のIRQジャンパが全くささっていなかった。。
-v1190の返す値はやはり同じ。→クレート、bit3による問題ではない。
-少し手詰まり。単なる勘違いの部分がある可能性も捨てきれないので、とりあえずコンスタントにぼちぼちと進める。
*2011.6.20 v1190テスト [#o21c7a85]
-確実に動くKEKにあるモジュールを送ってもらった。21or22日理研着予定。
-待っている間に少しだけいじってみる。
-ケーブルスワップ→変わらず。
-試しにtrigger matching mode →Continuous storageモードに。
-バッファにつまっている値が変わった。何かしら値がつまっている?
-しかし、data readyレジスタを見ても変化はない模様。
-さらに、実はDRDYのLEDはこちらのモードだとずっとついている。
-FULLのLEDもずっとついている。
-trigger matching modeにすると、CPUが寝ているときは実はDRDYのLEDがついていない?
-window width等を少しいじってみる→やはり変わらず。
-trigger lineをターミネートしてみる→変わらず。
-やはりtriggerの与え方かデータ信号の与え方がおかしい?
-あるいは初期不良?
-とりあえず動くものを待って、そこから次に進むことにする。
*2011.6.17 v1190テスト [#w9104cae]
-rpv130と共に簡易テスト。17日までのまとめ。
-セットアップ。ブロック図は以下の通り。~
&ref(./tdc_test.png,50%);~
-tdc parameters &ref(./tdc_stat.txt);~
-base: v1190 0x00100000、rpv130 0x2000
-Data readyフラグが立たない。。
-色々お試し。
-base addressを変更 ->0x11100000, 0xcc100000。変わらず。
-mapping時のmap sizeをいじってみる。変わらず。
-データ取得部をいじる。
-データの[31..27]にヘッダー、テイル、データ情報があるのでそれを読む。
-データが読みおわると残りのバッファーにfiller情報があるのでそれを読む。
-両方だめ。そもそもfillerしかつまっていない。やはりデータがちゃんと入っていない。
-転送方式をかえてみる。v32d32->v32d32dma,v32d32nbdma。特に変わらず。
-tdcへのデータ入力chを変えてみる。0-3ch→32-35ch, 64-67ch, 96-100ch。変わらず。
-trigger信号の幅を変えてみる。25nsec->30nsec, 40nsec, 60nsec。変わらず。
-VMEクレートへの挿す位置を変えてみる。変わらず。
-rpv130へのinterruptをなくし、pollingでとって見る。変わらず。
-現状のtest program &ref(v1190_test_ver0.zip);~
-現状わかってること。
-v1190のレジスタ、Microcontrollerへのread/writeはできている。
-v1190 front panelにあるLEDは、~
PWR,TERMは点灯しており正常。busアクセス時にはDTACKも点灯しており正常。データを入れているときはDRDYが点灯しているので正常そう。
-少なくとも、何かしら信号がきているというのをv1190は認識している。
-busアクセスもできている。
-triggerがちゃんと与えられていない?
-実はデータ信号がちゃんと与えられていない?
-実はbase address付近がメモリ干渉をおこしている?
-rpv130も動いているし、v1190のアクセスもできているから問題ないと思われるが、device driverによる依存性?
-関係ないと思うが、Microcontrollerのfirmwareのversionを新しくすべき?
-初期不良?
*2011.6.13 v1190テスト [#ma442cd1]
-色々バグあり。
-Microcontrollerへのアクセスがうまくいっていない。
-Microレジスタ(0x102e)とMicro Handshakeレジスタ(0x1030)があることに要注意。
-ここに注意してセットアップ関数のデバッグ。
-確認用にStatus関数も追加。
-daq mode、trigger条件、edge detection、分解能、読み出し条件、chチェックを見られるようにした。
-セットアップ→Statusでチェック→うまく動いている模様。
-その後ようやくデータ読み出し部のコーディング。
-ざっくりはできた。後は実機に信号を入れてみてチェック&デバッグ。
*2011.6.10 v862準備 [#g8c874a5]
-v862マニュアル(&ref(v862_manual.pdf);)&br;
*2011.6.10 v1190テスト [#r611286a]
**コーディング [#va11a631]
-各種パラメタをいじる部分について
-Microcontrollerを用いてセットアップ
-このレジスタに書き込む際は、ある程度時間がかかる模様なので、間にsleep()等を入れる必要あり。
-あるいは、書き込み可能かどうかのstatusレジスタがあるようなので、ここでflagをたてるようにすればよい。
-大体書けた。後はデータ読み出し部でOK。
*2011.6.9 v1190テスト [#u6a63ac7]
-v1190マニュアル(&ref(v1190_usersmanual.pdf);)&br;
**v1190アクセスチェック [#tcbf5914]
-KINOKOベースのsrcはなさげ。
-1からコーディング。
-まずはアクセスチェック。
-設定 base : 0xee000000
-ベースの設定が普通のbitのディップスイッチと違い、hexのロータリースイッチ。
-桁の読み方が最初わからなかったが、(物理的に)モジュールの下から順番にhexで8桁目〜5桁目。
-つまり、bitで言うと[31..28]、[27..24]、[23..20]、[19..16]。
-ちなみに、このモジュールはAddress modifierはA24/A32。今回はA32使用。
-データ転送も普通のPIO転送D32使用。~
-単純にモジュールをVMEクレートにさしただけの状態でアクセスチェック。
-Configuration ROMがあるので、まずはここのレジスタにアクセスして、
期待したものが返ってくるかチェック。
-はじめは失敗。
-base addressを変更 0xee000000→0x00100000
-やはり失敗。
-mapping部分で、mapsizeが小さすぎる。0x1000→0x40000に変更。
-OK。
-プログラム(&ref(v1190_access_check.zip);)&br;
*2011.6.6 rpv130テスト [#sd1ffd9d]
**bit3マウント+vmedrvインストール [#v01da262]
-bit3(PCI)をPCにマウント。
-PC立ち上げ→失敗。
-reboot、BIOSでネットワーク立ち上げをdelete、PCIボードを一度はずす。→全て立ち上げ失敗。
-GRUBでXenを選ぶと落ちること発覚。
-Xenではないデフォルトのものでboot→立ち上がる。
-vmedrvインストール(横山)→問題なく成功。
-&color(red){注意:rc.local等は変更していないので、PCをbootする度、~daq/VME_driver/vmedrv/Linux2.6_Bit3_617/にて、suでmake installを実行する必要あり。};
**rpv130動作テスト [#sbab20df]
-manual (&ref(repic-rpv-130.pdf);)&br;
-test program (&ref(rpv130.zip);)&br;
-/home/daq/VME/rpv130/ にて作業
-テスト内容:signal output + signal input(interrupt)
-まずは簡単なoutput。
-設定:base : 0x2000、IRQ level:3、ID:3、Vector:(F0)SUB{16};
-アクセスできず。。
-baseを変更(0x2000→0x4000)、VMEのスイッチON/OFF→失敗。
-bit3、rpv130をしっかりと差し直す→OK。
-baseを戻す(0x4000→0x2000)→OK。
-outputを確認。
-次にsignal input。
-rpv130とPC側(ctrl+c)のIRQ levelがかぶっている。→あまり問題ではない。
-実行を強制終了するために(ctrl+z)を割り当て。
-Gate Gen.からrpv130のFIN1に信号入力→信号を検出。
-input+output組み合わせ。
-Gate Gen.→rpv130 fin1→CPU→rpv130 output。→OK。
-&color(blue){プログラムの使い方簡易まとめ(詳細は気が向いたらまとめる。)};~
./main で実行。~
上に貼り付けてるプログラムだと100秒間プログラムが動き続ける。~
この間にrpv130のFIN1に信号を入れると、outputのch1から信号を出す。~
また、ctrl+cを入力しても、outputのch1から信号を出す。~
終了したいときはctrl+z。
終了行:
#attach
[[準備 ]]
*2011.8.12 new v1190 動作チェック [#l6142c31]
-全てこれまで同様のアドレス、ウィンドウ等でチェック。
-動くことは確認。
-bit落ちはとりあえずDAQの都合上少し放置。(一応現状でも統計がたまれば十分見られるはずなので、パラレルに進める)
-試しにMCPのバックグラウンドラン。基本的には大丈夫。が、z_sum v.s. z_subの傾きが変わった。
-tdcのch間のばらつきなどがもしかするとある?
-これも今後パラレルにチェック。
*2011.7.29 TDC bit落ち調査 [#d856f5f1]
-データファイルの追加
-その1 &ref(bitKEK_1.root); &ref(bitKEK_1.dat);
-その2 &ref(bitKEK_2.root); &ref(bitKEK_2.dat);
*2011.7.25 TDC bit落ち調査 [#xe444f31]
-KEKにて、これまでとは別のv1190、bit3、rpv130、vmeラック、PCを用いてテスト
-こちらでもその辺にあったpmtを使って、ランダムな信号をつっこんだ。
-その結果、bit落ちは見えた。
-ただし、chは異なるようである。(絵はkekのPCに入っているままなので後で追加)
-これまでの試験の結果も踏まえると、やはりtdcそのものが悪い(そういう仕様?)あるいは、読み出し部(デバイスドライバ?)あたりがあやしい模様。あるいは、
あまり関係ないかもしれないが、micro handlerのfirmwairのバージョンをあげてみると案外サックと直るのかもしれない。
-今後は、firmwairのアップデートor別のデバドラ(例えばKEKで過去に使っていたもの)を使って測定をしてみる予定。
*2011.7.20 TDC bit落ち調査 [#yf6af32f]
-その辺にあったシンチ+PMTを用いてランダムな信号をTDCにつっこむ
-まずはMCPの時と同じTDCのセッティングで取得→同じ傾向が見える。
-trigger subtractionをdisableにしてみる→変化なし
-triggerのパルス幅を極限まで小さく(20nsecちょっと)してみる→変化なし
-(ちなみに通常は25nsec)
-triggerを入れるタイミングのみずれしてみる→変化なし
-chを変えてみる。(32ch×4のチップで処理しているので、別のチップにいれてみる)→変化なし
-TDC resolutionを変えてみる→変化なし
-ここまでの段階で、やはり内部clkかバッファ部がおかしい気がする。
-次は外部clkを与えてみる予定。コネクタ等がないので要購入or調査+工作
-2pinコネクタで使えそうなものを見つけたのでケーブル作成
-外部から50MHz Clkを与えて測定→tdc chはclkに対応して変化。だがbit落ちは変わらず。
-というわけで、clkのタイミングというよりも、バッファ部や、データ部の方が問題である可能性が高い。(あるいはそもそも壊れているか。)
*2011.7.19 TDC check [#x9b140e5]
-分解能に関して、マニュアルを再度調べると、内部クロックを最大で回した場合は98psとのこと→reasonableな値であった。
-bit落ちチェック。
-使用データ:MCPにβ線源を一様にあてたときのもの(testMCP_1.dat-testMCP_8.dat)~
-データ取得環境等は追々。
-それぞれのデータに対する、ch0~ch6のtdc hitヒストグラムと抜けているビット~
-(ビット落ちの定義はtdc値=0 & 隣あうtdc値との差が10以上)
-データセット、マクロ &ref(./testMCP.zip);
-testMCP_1 &ref(./MCP_1.root); &ref(./bit_1.dat);
-testMCP_2 &ref(./MCP_2.root); &ref(./bit_2.dat);
-testMCP_3 &ref(./MCP_3.root); &ref(./bit_3.dat);
-testMCP_4 &ref(./MCP_4.root); &ref(./bit_4.dat);
-testMCP_5 &ref(./MCP_5.root); &ref(./bit_5.dat);
-testMCP_6 &ref(./MCP_6.root); &ref(./bit_6.dat);
-testMCP_7 &ref(./MCP_7.root); &ref(./bit_7.dat);
-testMCP_1 &ref(./MCP_8.root); &ref(./bit_8.dat);
-これを見る限り、必ず同じビットで落ちている模様。
-今のところパッと思いつくのは、
--TDC(バッファ部)そのものが壊れている
--triggerと内部clkとの同期がうまくとれていない
--データ構造がたまに同じところで壊れる
-など。
*2011.7.15 TDC time resolution measurement [#u62b43bb]
-時間分解能をはかる。
-Clock gen.からの信号を計測し、tdc hitの差分をみてやる。
-1,2,5,10MHzのシグナルを入れる。
-(1000, 500,200,100nsecが見えるはず。)~
&ref(./1000nsec.gif,50%);&ref(./500nsec.gif,50%);~
&ref(./200nsec.gif,50%);&ref(./100nsec.gif,50%);~
-横軸はTDC chの差分⇒もし100psならば、100nsecは1000chになるはず。
-しかし、結果は微妙に異なったようだ。
-1000nsec:10240ch
-500nsec:5120ch
-200nsec:2048ch
-100nsec:1024ch
-→分解能:97.7ps
-linearlityもこの範囲では問題なし。
*2011.7.12 テスト用DAQソフト [#h5acbc35]
-ver.0として作成。
-とりあえず生データをひたすらテキストでつめる。
-データフォーマットは、~
ffffffff~
ch val~
ch val~
ch val~
・・・~
ch val~
のようにヘッダ+2列のデータ~
-プログラム &ref(testDAQ.zip); ~
*2011.7.12 v1190テスト [#g50c6990]
-データ取得確認
-ch毎に読めていることも確認
-時間分解能に関して。clk 1M 5M 20M Hzを入力したときの得られた生データの各ビット間隔は10240, 2048, 1024。これだと分解能は~98ps。正しい?
-仮に違ったとしても、データの読み方のみをかえればよいと判断。
-とりあえずDAQ ver.0を作ることにする。(rpv130+v1190)。
-v1190のテストプログラム &ref(v1190_test.zip);~
*2011.7.5 v1190テスト [#d8e032f0]
-RALで用いているコードを見せてもらい、チェック。
-設定パラメタは基本的に同じ。
-ソフト的には問題なし。
-もう一度ハード的に見てみる。
-以前とは異なりちゃんとした50Ωターミネータでtrigger lineをターミネート。
-値がつまった!
-はずしたりしつつ再現性チェック→再現を確認。
-試しに以前と同じターミネートの方法(lemoから他のモジュールの50Ω終端におとす)でチェック→見えない。
-以前の方法では、実はちゃんとターミネートできていなかった模様。
-今後細かくチェックを進め、DAQ全体コード実装まで進める。
*2011.7.4 v1190テスト [#b46ec97e]
-ドライバ変更前にもう少しだけトライ。
-bit3側のジャンパを少し変えてみる。→変わらず。
-レジスタアクセスの際、32ビット転送がうまくいっていない可能性を少し疑う。
-マップサイズを大きめにとってみる。→変わらず。
-base addressをまた変えてみる。→変わらず。
-vector、IRQレベルをいじってみる。→変わらず。
*2011.6.24 v1190テスト [#c6312b1e]
-23日にできなかった分(元のクレートで試したこと)を試す→変わらず。
-クレート返却のため撤収→元のクレートに戻す。
-友野さんからコメント。
-同様にハマったらしく、その時はデバドラを変えたら行けたとのこと。
-ioctrlかbus accessのあたりがkinokoではだめということか?
-とりあえず保留してcollab. meet.後にその辺を変えてみる。
*2011.6.23 v1190テスト [#d7a4f0ca]
-借りたクレートで、ケーブルスワップ等以前と同様の変更など。→変わらず。
*2011.6.22 v1190テスト [#m205aaf6]
-KEKからモジュール到着。
-早速導入。ちなみにtermのswitchはoffになっていた。
-base f0030000
-同様の挙動。。→モジュールそのものはこわれていないということか。
-セットアップparametersをKEKのものと全て揃えてみる→変わらず。
-数時間ならば他のVMEクレート+bit3を借りてよいということなので借りてそちらで試してみる。
-クレートを変更してみたが、なぜかinterrupter(正確にはsignal handler部)がうまく作動しない。
-base address, IRQ level等も変更してみたがinterruptのみうまくかからない。
-outputは出る。
-クレート+bit3を借りられる期間を今週いっぱいに変更してもらえた。
-もう少しだけいじってみて、無理そうならば時間の無駄になるのでクレートは返却して他の方法を試す。
-interrupter問題は解決。bit3本体のIRQジャンパが全くささっていなかった。。
-v1190の返す値はやはり同じ。→クレート、bit3による問題ではない。
-少し手詰まり。単なる勘違いの部分がある可能性も捨てきれないので、とりあえずコンスタントにぼちぼちと進める。
*2011.6.20 v1190テスト [#o21c7a85]
-確実に動くKEKにあるモジュールを送ってもらった。21or22日理研着予定。
-待っている間に少しだけいじってみる。
-ケーブルスワップ→変わらず。
-試しにtrigger matching mode →Continuous storageモードに。
-バッファにつまっている値が変わった。何かしら値がつまっている?
-しかし、data readyレジスタを見ても変化はない模様。
-さらに、実はDRDYのLEDはこちらのモードだとずっとついている。
-FULLのLEDもずっとついている。
-trigger matching modeにすると、CPUが寝ているときは実はDRDYのLEDがついていない?
-window width等を少しいじってみる→やはり変わらず。
-trigger lineをターミネートしてみる→変わらず。
-やはりtriggerの与え方かデータ信号の与え方がおかしい?
-あるいは初期不良?
-とりあえず動くものを待って、そこから次に進むことにする。
*2011.6.17 v1190テスト [#w9104cae]
-rpv130と共に簡易テスト。17日までのまとめ。
-セットアップ。ブロック図は以下の通り。~
&ref(./tdc_test.png,50%);~
-tdc parameters &ref(./tdc_stat.txt);~
-base: v1190 0x00100000、rpv130 0x2000
-Data readyフラグが立たない。。
-色々お試し。
-base addressを変更 ->0x11100000, 0xcc100000。変わらず。
-mapping時のmap sizeをいじってみる。変わらず。
-データ取得部をいじる。
-データの[31..27]にヘッダー、テイル、データ情報があるのでそれを読む。
-データが読みおわると残りのバッファーにfiller情報があるのでそれを読む。
-両方だめ。そもそもfillerしかつまっていない。やはりデータがちゃんと入っていない。
-転送方式をかえてみる。v32d32->v32d32dma,v32d32nbdma。特に変わらず。
-tdcへのデータ入力chを変えてみる。0-3ch→32-35ch, 64-67ch, 96-100ch。変わらず。
-trigger信号の幅を変えてみる。25nsec->30nsec, 40nsec, 60nsec。変わらず。
-VMEクレートへの挿す位置を変えてみる。変わらず。
-rpv130へのinterruptをなくし、pollingでとって見る。変わらず。
-現状のtest program &ref(v1190_test_ver0.zip);~
-現状わかってること。
-v1190のレジスタ、Microcontrollerへのread/writeはできている。
-v1190 front panelにあるLEDは、~
PWR,TERMは点灯しており正常。busアクセス時にはDTACKも点灯しており正常。データを入れているときはDRDYが点灯しているので正常そう。
-少なくとも、何かしら信号がきているというのをv1190は認識している。
-busアクセスもできている。
-triggerがちゃんと与えられていない?
-実はデータ信号がちゃんと与えられていない?
-実はbase address付近がメモリ干渉をおこしている?
-rpv130も動いているし、v1190のアクセスもできているから問題ないと思われるが、device driverによる依存性?
-関係ないと思うが、Microcontrollerのfirmwareのversionを新しくすべき?
-初期不良?
*2011.6.13 v1190テスト [#ma442cd1]
-色々バグあり。
-Microcontrollerへのアクセスがうまくいっていない。
-Microレジスタ(0x102e)とMicro Handshakeレジスタ(0x1030)があることに要注意。
-ここに注意してセットアップ関数のデバッグ。
-確認用にStatus関数も追加。
-daq mode、trigger条件、edge detection、分解能、読み出し条件、chチェックを見られるようにした。
-セットアップ→Statusでチェック→うまく動いている模様。
-その後ようやくデータ読み出し部のコーディング。
-ざっくりはできた。後は実機に信号を入れてみてチェック&デバッグ。
*2011.6.10 v862準備 [#g8c874a5]
-v862マニュアル(&ref(v862_manual.pdf);)&br;
*2011.6.10 v1190テスト [#r611286a]
**コーディング [#va11a631]
-各種パラメタをいじる部分について
-Microcontrollerを用いてセットアップ
-このレジスタに書き込む際は、ある程度時間がかかる模様なので、間にsleep()等を入れる必要あり。
-あるいは、書き込み可能かどうかのstatusレジスタがあるようなので、ここでflagをたてるようにすればよい。
-大体書けた。後はデータ読み出し部でOK。
*2011.6.9 v1190テスト [#u6a63ac7]
-v1190マニュアル(&ref(v1190_usersmanual.pdf);)&br;
**v1190アクセスチェック [#tcbf5914]
-KINOKOベースのsrcはなさげ。
-1からコーディング。
-まずはアクセスチェック。
-設定 base : 0xee000000
-ベースの設定が普通のbitのディップスイッチと違い、hexのロータリースイッチ。
-桁の読み方が最初わからなかったが、(物理的に)モジュールの下から順番にhexで8桁目〜5桁目。
-つまり、bitで言うと[31..28]、[27..24]、[23..20]、[19..16]。
-ちなみに、このモジュールはAddress modifierはA24/A32。今回はA32使用。
-データ転送も普通のPIO転送D32使用。~
-単純にモジュールをVMEクレートにさしただけの状態でアクセスチェック。
-Configuration ROMがあるので、まずはここのレジスタにアクセスして、
期待したものが返ってくるかチェック。
-はじめは失敗。
-base addressを変更 0xee000000→0x00100000
-やはり失敗。
-mapping部分で、mapsizeが小さすぎる。0x1000→0x40000に変更。
-OK。
-プログラム(&ref(v1190_access_check.zip);)&br;
*2011.6.6 rpv130テスト [#sd1ffd9d]
**bit3マウント+vmedrvインストール [#v01da262]
-bit3(PCI)をPCにマウント。
-PC立ち上げ→失敗。
-reboot、BIOSでネットワーク立ち上げをdelete、PCIボードを一度はずす。→全て立ち上げ失敗。
-GRUBでXenを選ぶと落ちること発覚。
-Xenではないデフォルトのものでboot→立ち上がる。
-vmedrvインストール(横山)→問題なく成功。
-&color(red){注意:rc.local等は変更していないので、PCをbootする度、~daq/VME_driver/vmedrv/Linux2.6_Bit3_617/にて、suでmake installを実行する必要あり。};
**rpv130動作テスト [#sbab20df]
-manual (&ref(repic-rpv-130.pdf);)&br;
-test program (&ref(rpv130.zip);)&br;
-/home/daq/VME/rpv130/ にて作業
-テスト内容:signal output + signal input(interrupt)
-まずは簡単なoutput。
-設定:base : 0x2000、IRQ level:3、ID:3、Vector:(F0)SUB{16};
-アクセスできず。。
-baseを変更(0x2000→0x4000)、VMEのスイッチON/OFF→失敗。
-bit3、rpv130をしっかりと差し直す→OK。
-baseを戻す(0x4000→0x2000)→OK。
-outputを確認。
-次にsignal input。
-rpv130とPC側(ctrl+c)のIRQ levelがかぶっている。→あまり問題ではない。
-実行を強制終了するために(ctrl+z)を割り当て。
-Gate Gen.からrpv130のFIN1に信号入力→信号を検出。
-input+output組み合わせ。
-Gate Gen.→rpv130 fin1→CPU→rpv130 output。→OK。
-&color(blue){プログラムの使い方簡易まとめ(詳細は気が向いたらまとめる。)};~
./main で実行。~
上に貼り付けてるプログラムだと100秒間プログラムが動き続ける。~
この間にrpv130のFIN1に信号を入れると、outputのch1から信号を出す。~
また、ctrl+cを入力しても、outputのch1から信号を出す。~
終了したいときはctrl+z。
ページ名: