別の小さいながらも非常に有益な戦術レッスンを実施する機会がありました
この投稿のトピックは、Sherlock Omsからのニュースレターに触発されました-さまざまな電子デバイスを診断する際に発生した重要なエンジニアリングの問題に関する記事が定期的にあります。 なぜだと思いましたか？ 主題は非常に具体的であり、非常に特定の高度に専門化された知識を必要とし、読者の幅広いサークルにとって興味深いものではないことを完全に理解していますが、ハードウェアの謎の専門家の狭いサークルに数分の楽しい時間を提供できます。 したがって、データバスとは何か、どのように設計されているかを知っている人にとっては、 船、靴、シーリングワックス、キャベツのヤシの木。
すでに説明したMK 1986BE1Tでデバイスを設計するプロセスでは、かなり高速なインターフェイス（できれば並列）を介して外部FLASHメモリチップと対話する必要がありました。 幸いなことに、検討中のMKにはこのような可能性があり、メモリにマッピングされているがMK自体の構造には含まれていないデバイスへのアクセスを整理するために、完全な（32ビットのアドレス、32ビットのデータ、2つの制御信号、4つの追跡信号）外部を使用できますいつものように、このオプションを含めてくれた開発者のおかげで、いつものように、明らかに不十分なドキュメントへの不満を表明していますが、投稿はそれについてではありません。 多数の開発およびコントローラー機能により、データバス幅全体が使用されたわけではなく、検出された問題を説明するのにまったく意味のない03ビットから始まる8ビットのみが使用されました。 Mkは、すべての出力バッファとともに+3.3で駆動され、さらに他のデバイスの動作を保証するために、プルアップ抵抗2kΩがデータバスへの電圧+5に接続されました。 プロトタイプデバイスを組み立てた後、デバッグが始まり、最初のテストケース（もちろん、または言うまでもなく）が機能しませんでしたが、その後、それらが採用されました（以下、複数の理由があります。 Habrに投稿を書くことを望んでいない）オシロスコープで、その場しのぎを見るために登った。 そして、興味深い現象が発見されました。 データバス上の信号の予想される波形は、次のようになります（赤と緑の色-思いつきませんでした。Habrにアップロードしたときに発生しました）。
番号2のラベルが付いた波形の断片は、アドレス指定された外部デバイスがない場合のバスの予想される動作です（サンプル入力を非アクティブ状態に変換することにより達成されます）。 MKはバス（上の図の黒い線）からデータを取得し、その上の電圧が給電抵抗を介して電力に引き込まれ始めます。 しばらくすると、MKは読み取り信号のアクティブレベル（ゼロ）を発行し（下図の緑の信号）、その時点で外部デバイスはデータを送信する必要があり（非アクティブであるため、プルアップが継続します）、一定時間後に読み取り信号のアクティブレベルが削除され、外部デバイスタイヤを解放し、バス上のそれ以上の状態はあいまいです。この場合、プルアップは継続します。 すべてが論理的で理解できるものですが、実際には、セクション1に示されている図が最初に検出されました。この場合、読み取り信号が送信される前に、MKはバスに高レベルを与え、読み取りの間、さらに重要な後だけ、それを保持し続けました。データバスがオフ状態になった時間（ミリ秒単位）。 やや予想外ですが、最初は注意せずに状況に反応しました-ピン設定にエラーがあり、それを探す必要があると判断しました（プログラムは若い同僚によって書かれたため、私がそれを書いた場合、可能性のあるエラーの存在を推測するのは簡単でした、状況はそれほど明確ではありません:)）。 設定エラーの存在に対する確固たる信念は、16本のデータライン（32本のうち）すべてが同じように構成され、そのうち4本のみが故障しており、これらはビット4,5、8、11であることが確立された後、消滅しました
さらに考えて実験します。 録音後すぐに読むことは不可能であるという考えがあります（これはドキュメントには反映されていませんが、Milanderで作業しているときは、すでに何かを推測することに慣れています）。したがって、2番目が正しくなることを期待して、2回連続で読み取りを行います。
data=*buffaddr; data=*buffaddr;
そして、ここで最も興味深い部分が始まります-2番目の読みが本当にうまくいきますが、最初の読みも正しくなります-非常に興味深い現象-私はそのメカニズムを絶対に想像できません-つまり、前のコマンドに対する次のコマンドの影響の合理的なメカニズムを想像できません。 生成されたアセンブラコードをざっと見てみると、ヒントが得られます-最初の読み取りコマンドの場所のアドレスは、リンカの特性により変更されました-アドレスがコマンドの実行にどのように影響するかのメカニズムを考えるのは簡単です。 MKの動作を調査するために、不要なものをすべて削除して、一般的なプログラムから外部バスとの交換に関連するフラグメントを選択します。 そして、別の驚きがあります。コマンドのアドレスは変更されていませんが、1回の呼び出しでも誤った読み取り値は観察されません。 削除されたフラグメントを挿入して戻すと、CRC16計算関数が接続されている場合、誤った読み取りが観察されますが、欠落している場合はそうではなく、この関数は明らかに外部バスと相互作用せず、合理的な方法で読み取りに影響を与えません さらなる実験により、重要なのはCRC16カウント関数ではなく、中間和のデータブロック、さらにこのブロックのサイズ、つまりコードの存在が重要であることが示されました。
static CRC16Buff[256]; static CRC16Buff[215]; ( 215) -
このフラグメントは、まったく異なる場所で実行されるコードにどのように影響しますか？ グローバル変数に必要な場所が変更されたため、唯一の変更はスタックの値にあることがわかります。 つまり、特定のスタック値で特定の場所からコマンドを実行すると、誤った処理が発生し、ワード内のエラービット数が少ないことがわかります。 エンジニアの最初のルール、「世界には奇跡はありません」を思い出してください。 これはある種のデバッグ機能VHDLの残りの部分であり、特定の状況についてのシグナルであり、リリースから削除されていないと想定できます。 スモークの多い開発者の考えのように見えますが、神の介入を拒否するため、これまでのところ他の仮説はありません。 別の考え-「ここにいる、トナカイ」-私たちは本を見つけましたが、まったく無意味ですが、誰がそれらを理解できるのか、NSAの人たちです。
私たちは調査を続け、（NOPを追加して）コマンドを異なるアドレスに移動しても何も起こらないことに驚いています-スタックの異なる値に対してエラーが表示されない、または消えない、つまり、アドレスの仮説は拒否されるべきです しかし、2番目のコマンドを追加すると最初のコマンドにどのように影響しますか？ アセンブラコードをより詳しく見て、より多くの変更を見つけます。つまり、一度読み取ると、コンパイラが生成します。
mov r0, sp ldrh r1,[r4] strh r1,[r0]
そして、2回の連続読み取りで、彼は最適化を実施しました。
mov r2, sp ldrh r1,[r4] strh r1,{r2] ldrh r1,[r4] strh r1,[r2]
信じがたいことでしたが、レジスタr0に非常に特定の値が含まれている場合にのみ不正な読み取りが行われ、このレジスタが将来使用されるかどうかは関係ありません。 スタックポインターとコマンドカウンターの関係についての以前の絶対に狂った仮説と比較すると、明確な進歩が見られます。さらなる実験により、最後のサイクルでユニットが記録され、ユニットがレジスタr0に書き込まれたデータビットで強制的に高いエラーレベルが観察されることが示されています、さらに、現象は明らかにトリガーです-記録後の最初の読み取り中に発生し、一定時間保持されますが、この時間はMK周波数とはまったく関係ありません（エラー内で IA）が、顕著な結晶温度との接続を（温度保持時間が増加する増加）を有しています。 データバスの上段の出力バッファの制御信号は非アクティブレベルであり、対応するレジスタの放電からの信号は、静電容量がリーク電流で再充電されるまで誘導されると想定できます。 仮説は良いのですが、残念ながら、より適切な説明を誰かが思いついた場合、トリガーは説明しません。コメントしてください。 さて、実際の部分では、最終行として、データをレジスタr0に読み込む前に、ゼロを書き込むと、バスは正常に動作します。これは、上記のオシログラムで次のコードで確認できます
mov r0, #0xFFFFFFFF ; ldrh r1,[r4] ; - 1 strh r1,[r4] ; , - mov r0,#0x00000000 ldrh r1,[r4] ; - 2
ところで、オヘンリーのように、王やキャベツはありませんでした。