(toppers-users 209) Re: serial_open( )

[Takayuki WAKABAYASHI]

豊橋技術科学大学の若林です。

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