(toppers-users 209) Re: serial_open( )
Takayuki WAKABAYASHI
takayuki @ ertl.ics.tut.ac.jp
2001年 6月 13日 (水) 06:23:17 JST
豊橋技術科学大学の若林です。
Takeda Masaru さんは書きました:
> serial_open( )という関数内で全く動かなくなってしまいます。
> 原因はさっぱり分かりません。
関数名だけではどこで止まっているのかさっぱりですが、
できる限りソースレベルで追跡してみました。
#以前からSH3に関するご質問が続いていましたので、
#今回もSH3だと仮定します
serial_open内で止まっているとするなら次のどこか。
・config/sh3/cpu_inst.h:87,98 (set_sr, etc.)
上記個所の特権命令stc,ldcが不当命令例外を発生させている
#しかしloc_cpuはinlineではないので可能性は低い
原因 -> どこかでユーザモードに落としている(?)
・config/sh3/DVESH7700/hw_serial.h:99 (hw_port_initialize)
while文の条件が成立してない
原因 -> BSC-RFCRが正常に動いていない
RFCRのvolatileが外れてる(HIOREG <= volatile word)
RFCRのアドレス自体がおかしい
ちょっとこれ以外には止まるポイントが見つけられませんでした。
前者に関しては、serial_openに入った時のSRのMDビットを見れば判
ります。
後者に関しては、DRAMコントローラの初期化をちゃんと行っているか
どうかや、リフレッシュカウンタの設定を行っているかなどをチェッ
クしてみてください。パッとみた感じでは、jspの中自体ではDRAM初
期化は行っていないので、自分の使っている環境に合わせて、
hardware_init_hook等を作る必要がありそうです。
#gdbのスタブを使っていると、スタブがSDRAMコントローラを初期
#化してくれているので、初期化を忘れていることに気付かないこ
#とが多いです。
コードがここまで実行されているところを見ると、もしかしたら
SRAMで組まれていることも考えられます。そうであれば、この部分
はただ時間を稼いであげればいいだけなので、nopループを差し込む
のも一つの手です。
volatileに関しては、一回gccの-O2を外して-O0とかでやってみるの
も手かも知れません。たまに動くときがあります。
#この場合、だいたい勘違いコーディングが原因ですが...
デバッグの手段としては、もなかさんが仰るように、通過ポイント
を調べるためのコードを差し込むのがいいと思います。
#LEDデバッグ系は、組込み系では避けたくとも避けられない
#デバッグ技法のひとつではないかと思います。
具体的には、私なら次のようにしてみます。
・hw_serial.h:97にLEDをつけるルーチンを付け足す
・hw_serial.h:100にLEDを消すルーチンを付け足す
これで点灯(X点滅)すれば、間違いなく後者の部分で止まっています。
あとsh3.h:354でも止まりそうに見えますが、こちらは上が原因で
なかった場合に回します。
#シリアルから一文字も出力されないならこの可能性が高い
以上、ご参考まで。
//-------------------------------------------------
//Takayuki WAKABAYASHI (わかばやし たかゆき)
// mailto: takayuki @ ertl.ics.tut.ac.jp
//-------------------------------------------------
//豊橋技術科学大学 工学研究科 情報工学専攻
// 組込みリアルタイムシステム研究室
// Embedded and realtime system laboratory
// Dept. of information and computer science
// Toyohashi univ. of technology