_★
データ化け問題
相変わらず、K君と一緒にデータ化け問題の原因追究。
当該バスのタイミングについては机上計算では十分に余裕にあることは分っている。
が、下位8bitだけが化ける。しかも、ビットが0->1にならない模様。
高級オシロスコープで観測してみるとバス上の信号の立ち上がりが異常に鈍い。ダラダラと上がっている。
パターンが長いのでESL増大により立ち上がりが鈍くなっていると思った。
そこで、信号が上がり切るまでの時間を稼ぐためウエイトを1発入れた所、エラーが集束した。
ウェイトを入れんとスレッショルドレヴェルに達しないままCPUがバス上のデータを読んでしまうので化けるのだろう。
その後、詳細にバスを観測してみるとESL増大説を否定する観測結果が出た。
また、上位bitの立ち上がり波形は非常に良くバスクロックの半クロック以下で立ち上がるのに対して下位ビットは1クロック以上遅れて立ち上がり切る。ざっくり3倍違う。
うーむ、色々と調査したけど真の原因がハッキリしない。(;_;)
だた、現状の基板では、
1)上位ビットに比べて下位ビットには接続されているデヴァイスが多い。そのため負荷容量が多そう。
2)重くて高速なバスの割には実装してあるプルアップ抵抗値が大きい。
3)また、パターンが長いのでESLや分布容量が増大傾向にあり伝送線路の条件が厳しい。
原因は、これら複合要因かも知れんなぁ。
あ、もしかしたら電子が如来空間に補足された結果、伝播速度が遅延したとも考えられる。(すんません。すんません。すんません。すんません。)
ソフトデバッグを進めるために取り敢えずはウエイトを1発入れることで回避することにした。
ウェイトを入れることでバス速度低下は必至なので製品では当初の設計通りのタイミングにするために真の原因を追究せにゃならん。
さらにテストプロではエラーが集束したが実際のアプリケーションでは未確認なのでまだ予断は許されない。
原因追究を急がねば。
プルアップ抵抗を低くすると電流が多くなるのでイヤなんだよなぁ。(ボソ)
今回は技術試験基板作って正解だったと思う。
初物デヴァイスだらけで色々とハマった箇所があった。
もし、いきなり試作機を作っていたら大変なことになったに違いない。
(最初、某部長には開発基板の製作は反対されたけど)
あと、高級オシロスコープに感謝。
でも、このクラスのオシロスコープが社内に無いってのは大問題だと思う。
少なくても開発をしていると名乗るためには設備投資が必要でしょ?