テージ用Speeduino

アルドウィーノを使った
オープンソース、オープンハードの
ローコストＥＣＵ

テージのＥＣＵが壊れているみたいなので
Ｓｐｅｅｄｕｉｎｏに装換します。

その１４：ＳＭＴ３２＿ｍｅｇａＣＰＵボード
ＳＤカードの不具合解析、ＲＴＣの不良解析
新作ハーネスでエンジン始動

２０２４年
８月２７日
ＳＤカードの容量を取得するのはＣＭＤ９コマンドです。ＳｄＦａｔライブラリ内でＣＭＤ９を検索すると、ｃｐｐには無いですが、ヘッダファイルに見つかりました。

ＳＷＤ（ＳＴ－ＬＩＮＫ）のステップ実行を使い、ＴｕｎｅｒＳｔｕｄｉｏのＳＤカードのダイアログを開いた時に呼ばれる関数を確認しておきます。下はＳｄＳｐｉＣａｒｄ．ｃｐｐのｓｅｃｔｅｒＣｏｕｎｔ関数です。ｒｅａｄＣＳＤ関数を呼んでいます。

下はＳｄＳｐｉＣａｒｄ．ｈのｒｅａｄＣＳＤ関数です。ＣＭＤ９を引数にｒｅａｄＲｅｇｉｓｔｅｒ関数を呼んでいます。

８月２８日
ＴｕｎｅｒＳｔｕｄｉｏのＳＤカードのダイアログを開いた時に呼ばれる関数が分かったところで、不具合をデバッグします。まず、ＳｐｅｅｄｕｉｎｏとＰＣアプリとの接続がＵＳＢの場合は直ぐ障害が発生し、デバッグが出来なくなりました。ＵＳＢは通信が行われていない時にも周期的にフレームが送受信され、接続が保たれていることを確認しています。デバッグのためプロセッサが停止すると、このフレームに対応することが出来なくなり、ＰＣアプリのＴｕｎｅｒＳｔｕｄｉｏがオフラインになり、以降操作ができなくなります。ＰＣとの接続をＵＳＢからＢＴモジュール（ＵＡＲＴ）に変更して、デバッグが可能になりました。

ＴｕｎｅｒＳｔｕｄｉｏのＳＤカードのダイアログを開いた時のＳＤカードのアクセスをデバッグします。下はＳｄＦａｔライブラリのＣＭＤ９コマンドでカード容量を取得しているｒｅａｄＲｅｇｉｓｔｅｒ関数部で、ＣＳＲ（カード特性データレジスタ）の読み出し時にエラーが発生しています。エラーの種別はＳＤ＿ＣＡＲＤ＿ＥＲＲＯＲ＿ＲＥＡＤ＿ＲＥＧです。

８月３１日
ＳＤカードの容量が不明になる不具合のデバッグ中です。ブレークポイントで止めると、赤枠のＣＡＬＬＳＴＡＣＫに呼んだ関数一覧が出てきます。ステップインで関数を実行して行くと、呼び出した関数の一覧が増えます。ＴｕｎｅｒＳｔｕｄｉｏのＳＤカードダイアログを開くと以下のように動作することが判明しました。
・ＣＭＤ９コマンドでカードの容量を取得します。
・この時、ＳｄＳｐｉＣａｒｄ.ｃｐｐ内のｃａｒｄＣｏｍｍａｎｄ関数が呼ばれます。
・ＣＭＤ９コマンド発行前にダミーの１バイトの送受信を行い応答を確認します。
・不具合発生時はこの応答が無く、タイムアウトになります。
このダミー送受信時のＳＰＩ信号をロジックアナライザで測定すると、何か分かるかもしれません。

ステップインを進めて、最終的にはＳＴＭが提供したライブラリに行きつきます。ＣＡＬＬＳＴＡＣＫの関数をまとめて、関数一覧を作成しておきました。

９月１日
ＳＤカードスロットから配線を引き出して、アナログディスカバリのロジックアナライザのＳＰＩプロトコルアナライザで波形を測定します。

こちらはダイアログ内でフォーマット後のＲｅｓｅｔａｎｄＷａｉｔボタンを押した時のプロトコルアナライザ波形です。ＦＦのダミーの後、ＣＭＤ９の４９が出力されてＳＤカード側もＣＳＤレジスタと思われる値を出してトランザクションが終了してます。

下はダイアログ内でフォーマットしていない時のＲｅｓｅｔａｎｄＷａｉｔボタンを押した時のＳＰＩのプロトコルアナライザの波形です。本来はコントローラがダミーのＦＦを出力するはずですが、何故か００を出しています。ＣＳ、クロックは正常ですが、ＭＯＳＩ、ＭＩＳＯともＬＯＷです。連続でリトライしていますが、タイムアウトで終了します。複雑な不具合では無く、全然動作していないので分かり易いです。どこか単純な間違いと思います。

９月２日
その後、ＳＤカードがアクセスできない原因が判明しました。ＴｕｎｅｒＳｔｕｄｉｏを起動した時のＳＤカードの初期化アクセス（ＣＭＤ０、ＣＭＤ８など）は正しく行われます、その後、ＭＯＳＩ、ＭＩＳＯの信号がＬＯＷになり、コマンドの前に出力される１バイトのＦＦダミーアクセスが正しく送信されず、ＣＭＤ９コマンド（カード容量取得）がタイムアウトになっていました。一旦は正しくコマンドのやり取りが行われますが、その後、動作しなくなくなることが分かりました。デバッガとプロトコルアナライザで確認したところ、ＭＯＳＩ、ＭＩＳＯの信号がＬＯＷになるのはｓｅｔＰｉｎＭａｐｐｉｎｇ関数の引き素がａｒｄｕｉｎｏ＿ＭＥＧＡのｂｏａｒｄＩＤ＝３で上書きされるからでした。ｐａｚｉ８８さんのＢＭＷＰｎＰのｂｏａｒｄＩＤは３１です。ＳＤコンソールでＳＤカードをフォーマットすると、ＭＯＳＩ、ＭＩＳＯが再設定されるので以降は信号が正しく出力され、再度アクセスできるようになるということです。ちなみに、下のｉｎｉｔ．ｃｐｐのボードのピンの設定部分で赤枠のように強制的に３１を設定すると、動作良好になることも確認しました。

フォーラムで質問したところ、エンジン設定にボード種別の設定があるとの情報がありました。赤枠のようにプルダウンメニューでコントローラボードが選べました（笑）。ｐａｚｉ８８さんのＹｏｕＴｕｂｅではこの設定が無く、すっかり忘れていました。この設定すると、ｓｐｅｅｄｕｉｎｏ.ｉｎｉの変更やプログラムの書き換えをしなくても、ＳＤカードが正しく動作するようになりました。ただ、まだ完全ではなく、外部ピンによるログ開始、ＲＴＣの時間ずれが大きい、ミニターミナルが応答しないなど、まだ少し問題があります。

９月３日
ＳＴＭ３２＿ｍｅｇａのＲＴＣの時間ずれを確認中です。赤枠の１１：４８：５６にＰＣの時間をｓｐｅｅｄｕｉｎｏに設定します。

２時間後に参照すると１３：４８：５６位のはずが、赤枠の１３：５６：０２で、約７分（４２０秒）と大幅に進んでています。普通の水晶の精度は２０ｐｐｍ（月差約１分）位ですが、仮に精度が１００ｐｐｍ（１／１００００）でも、３２７６８Ｈｚで、ずれは約３.３Ｈｚになり、進む方向で３２７７１.３Ｈｚです。３２７６８分周すると１．０００１秒になり、２時間後に７２００．０７２秒なので約０.７２秒進むだけです。負荷容量が合っていないというような問題では無く、安定して発振していないなど、何かおかしいです。他にボードが２枚あるので後で確認します。

９月４日
他の２枚のボードのＲＴＣずれを確認しました。左が設定時、右が１日弱経過語の参照時です。ボード２は正しくＲＴＣがバックアップされて動作しています。

ボード３は大幅に進んでいます。電源断後、電池でバックアップした時の結果なので、通電していても遅れるのかは後で調べてみます。

９月５日
ＳＴＭ３２Ｆ４０７ｘでは無いですが、Ｆ１０３Ｘのデータシートに負荷容量１２.５ｐＦのコンデンサは絶対使うなという文言があります。

ちょっと調べたところ、ＳＴＭの水晶振動子のデザインガイドがありました。今、実装されているエプソンのＦＣ－１３５（負荷容量１２.５ｐＦ）は推奨ではないようです。Ｆ４の項目がありません。

デザインガイドにＦＣ－１３５と同じサイズのＦ４０７ｘに推奨する水晶が複数あります。

これが原因で不具合が起きているのかは不明ですが、ＲＳコンポーネンツに上記の負荷容量６ｐＦの水晶があったので、発注しておきました。ＰＳｏＣ５ｌｐは送料無料の調整用です。

９月９日
ＳＴＭ３２＿ｍｅｇａではｍｉｎｉターミナルのコマンド応答がａｒｄｕｉｎｏ＿ＭＥＧＡの時と異なるので調査します。ＰＣとＵＳＢ接続するとＴｕｎｅｒＳｔｕｄｉｏが切断されてデバッグできないし、ＢＴ接続ではＴｕｎｅｒＳｔｕｄｉｏにＢＴポート設定がありません。解決策は本物のシリアルポートを使うと上手く行きそうです。アマゾンでＲＳ－２３２とＴＴＬレベルを変換するＭＡＸ３２３２ボードが売っています。３枚で７００円と安いです。購入したボードが到着しました。

デスクトップＰＣのシリアルポートを９ピンケーブルで変換ボードと接続しますが、回路図は無いないので、基板を解析して接続しました。例えば、コネクタにＴＸＤと書いてあっても、自分のＴＸＤなのか？相手のＴＸＤに繋がるＲＸＤなのかで、入出力が逆になり、これ永遠の難題です。電源は５Ｖに接続して、ＴＸとＲＸをループバックします。回路図が付属していれば悩まなくてもいいんですけど。

シリアルポートはＣＯＭ１です。ＴｅｒａＴｅｒｍでループバックテストして動作良好です。

９月１０日
ｍｉｎｉターミナルの続きです。ＢＴモジュールの代わりにレベル変換をＳｐｅｅｄｕｉｎｏのシリアルポートに接続します。Ｓｐｅｅｄｕｉｎｏに載っているＴＸの５Ｖ－＞３Ｖ変換アッテネータはそのままでも動きました。ＴｕｎｅｒＳｔｕｄｉｏのポートをＣＯＭ１に設定して、ＳＷＤを接続してＶＳＣで制御できることを確認しました。

９月１１日
ＶＳＣで動作を追ったところ、ｃｏｍｍｓ.ｃｐｐのコマンド分岐部でレガシィフラグを確認しています。これが偽になるので、Ｆコマンド以外の１字コマンドは実行されません。Ｆコマンド（プロトコルのバージョン、現在は” ００２”）だけがレガシィモードに関係なく動くようになっていました。電源投入時にはｉｎｉｔ.ｃｐｐ内でレガシィフラグがレガシィにセットされます。ＴｕｎｅｒＳｔｕｄｉｏと接続後に、正しいコマンドが処理されるとレガシィフラグがクリアされ、以降、非レガシィになり、Ｆ以外の１文字のコマンドは処理されません。この時の動作フローは２文字目をｗｈｉｌｅで待って永久ループとなり、次の受信バイトが入るとループを抜けてタイムアウトのエラー（０ｘ００、０ｘ０１、０ｘ８０、０ｘ３Ｆ、０ｘＢＡ、０ｘ６Ｃ、０ｘＡＤ）が返ります。永久ループ中は点火、噴射などの処理は停止します。当然、エンジンは止まります。

因みに、強制的にレガシィフラグがクリアされないようにすると、′Ｓ′、′Ｑ′や′？′などの１文字コマンドが応答します。という事で、ａｒｄｕｉｎｏ＿ＭＥＧＡと異なる動作は、不具合では無いようです。

９月１５日
ＲＳコンポーネンツで購入のＳＴＭ３２Ｆ４ｘｘに推奨の３２.７６８ＫＨｚの負荷容量６ｐＦ水晶発振子が到着したので、早速、交換しました。両端のコンデンサは２０ｐＦから１２ｐＦに変更しました。

朝７時半に時間設定して、買い物から帰って、約６時間後に確認して、８分位進んでいるので、水晶が原因ではないようです。原因はデバイスか？プリント基板？でしょうか？

ＳＴＭ３２のＲＴＣのリファレンスマニュアルを見ると、ＲＴＣクロックを６４分周した信号をポートＰＣ１３に出力することができます。コントロールレジスタの最上位のＣＯＥビットを立てれば良いですが、ＲＴＣレジスタは不用意に書き換えられないように、おまじないが必要です。ＶＳＣのペリフェラルレジスタでアクセスしても上手く行かないので、ＲＴＣ初期化コードにＣＯＥビットを操作を追加します。

ＶＳＣで追うと、コントロールレジスタを操作しているＨＡＬ＿ＲＴＣＥｘ＿ＥｎａｂｌｅＢｙｐａｓｓＳｈａｄｏｗ関数が見つかりました。この関数を呼ぶと、シャドウレジスタをバイパスして、カレンダ値をカレンダカウンタから直接読み出すように設定します。

この関数にＣＯＥビットを立てるコード（赤枠）を追加しました。前後にはおまじない（具体的にはＲＴＣ＿ＷＰＲレジスタに０ｘｃａ、ＲＴＣ＿ＷＰＲレジスタに０ｘ５３を書き込み）がありあます。ＰＣ１３はａｒｄｕｉｎｏのＤ５２ピンで未使用です。このピンを周波数カウンタで測定すれば、３２７６８Ｈｚを６４分周した５１２Ｈｚが観測されるはずです。調子の悪いボードは少し高い周波数が出ているか？または不安定になっているか？確認できそうです。因みに、このポートはコイン電池のＶＢＡＴで動くので電源を切っても出力されます。

９月１６日
初めに上記のＲＴＣのクロック出力のコードが正しく動作しているか確認します。動作良好な２番基板で測定します。電源無しで、Ｄ５２ピンから引き出してカウンタに接続します。５１２Ｈｚで正常です。周波数カウンタは古い岩通製のＵＣ－６１５２です。

不具合のある１番基板はコンデンサを２０ｐＦに変更して、周波数は５１１.９Ｈｚ、６４倍するとＲＴＣのクロックは３２７６１.６Ｈｚです。周波数が６.４Ｈｚ低いです。この時１秒は約１.０００２秒になり、２時間で約１.４４秒遅れるはずです。この出力波形は連続的で良好なボードと同じ感じです。

２時間後にＲＴＣの時間を確認したところ約３分進んでいます。デバイス不良でしょうか？

９月１７日
ＲＴＣの不具合はＳＴＭ３２を交換してみます。５００円クーポンがあったのでマルツ経由のＤｉｇｉＫｅｙで２個発注しました。

ヤフーオークションで購入のサンハヤトのＳＭＴ取外し用の低温ハンダが到着しました。値段はアマゾンでは６０００円位ですが、少し安くて送料別で４３００円でした。

早速、一つ外してみました。融点が６０～７０℃で、半田コテ１本でも簡単に取り外すことができます。

９月１９日
新しいＳＴＭ３２のＣＰＵがトレイに入って到着しました。３番基板のＣＰＵと水晶を交換しました。６４分周出力は５１２Ｈｚですが、偶に５１１．９Ｈｚになります。両端のコンデンサは１２ｐＦですが、本来は６～７ｐＦが適正と思われます。ＳｐｅｅｄｕｉｎｏでＰＣの時間と合わせて、約６時間後に約４秒遅れになりました。水晶のみを交換した１番基板は５１１．９Ｈｚにも関わらず、２時間で３分進むのでやはり、ＣＰＵが原因と思われます。この後、６ｐＦのコンデンサを入手して、１番基板のＣＰＵも交換する予定です。

９月２２日
１番基板のＣＰＵと水晶、コンデンサを１２ｐＦに交換して、３番基板と同一にしました。６４分周出力は５１２Ｈｚでした。ところが、約５時間後に約６分進んでいました。ＣＰＵの不具合では無いことになります？不可解です。

ＳＴＭのフォーラムなどで質問しやすいように、問題を簡単にします。Ｓｐｅｅｄｕｉｎｏのプログラムを使わないで単純なプログラムでＲＴＣの確認をします。ＰｌａｔｆｏｒｍＩＯのＳＴＭ３２ｄｕｉｎｏＲＴＣライブラリにＳｉｍｐｌｅＲＴＣというサンプルプログラムがあります。これにｒｅｃｅｉｖｅＣｏｍｍａｎｄ関数を追加して端末からＲＴＣの開始の時分を入力できるようにしました。下はｓｅｔｕｐ部で、時間が設定されていなければクロックをＬＳＥ（外部３２．７６８ＫＨｚ水晶）に設定し、ｒｔｃ．ｓｅｔｘｘ関数がＲＴＣ＿ｓｅｔＴｉｍｅ関数を呼んで時分秒を設定します。

ｌｏｏｐ部では１秒待って、ｒｔｃ．ｇｅｔｘｘ関数で時間を取得して、シリアルに時分秒を出力します。

ＰＣの時計に合わせて、時分を入力し、一定時間後にＰＣの時計と比べれば、Ｓｐｅｅｄｕｉｎｏとは無関係にＲＴＣの動作を評価できます。下は１番基板のＳｉｍｐｌｅＲＴＣの結果です。５時間で約８分進んで、明らかに異常です。

下は３番基板のＳｉｍｐｌｅＲＴＣの結果です。６時間で約４秒遅れています。６４分周出力が偶に５１１．９Ｈｚになるので、遅れの方向で誤差が大きいですが、正常と思います。

ＳｐｅｅｄｕｉｎｏのＲＴＣの時間設定と比べてみます。時間が設定されていなければＲＴＣ停止、クロックをＬＳＥに設定、ＲＴＣ開始、ｒｔｃ．ｓｅｔｉｍｅ関数がＲＴＣ＿ｓｅｔＴｉｍｅ関数を呼んで日時を設定しています。基本的にＳｉｍｐｌｅＲＴＣと同じです。

時間取得はｒｔｃ．ｇｅｔｘｘ関数で、基本的にＳｉｍｐｌｅＲＴＣと同じです。

９月２５日
アナログディスカバリで平均値が出せるので１番基板の６４分周出力（ＲＴＣ＿ＣＡＬＩＢ）の平均周波数を測定します。

立ち上がりでトリガをかけた時は５１１．９４Ｈｚです。

因みに、立ち下がりでトリガをかけた時にはジッタのため、約５１６Ｈｚです。６４倍すると、３３０２４Ｈｚ、１秒は０．９９２２秒になり、５時間で１４０秒進みます。これが４８０秒くらいだと、関連がありそうでしたが、無関係と思われます。

リファレンスマニュアルに立ち上がりで測定するように指示があります。

追加で他の基板も測定しておきます。２番基板の平均は５１２．０１Ｈｚです。

１番基板は５１２．０４Ｈｚです。

９月２６日
ガレージ内の気温もだいぶ下がってきました。３２℃位でしょうか？作業を再開します。

右ハンドルスイッチの汎用スイッチはセカンダリマップの選択、ＳＤカードのログ開始に使います。セカンダリマップは論理の選択ができます。

一方、ＳＤカードのログ開始はＨＩＧＨに固定されています。

汎用スイッチがＯＮでログが開始した方がいいので、汎用スイッチの論理を反転させます。初めに配線図を修正しました。

続いて実車です。コネクタからコンタクトを抜いて、配線を入れ替えました。

９月２８日
ＲＴＣの不具合の続きです。初めから調子の良かった２番基板の水晶をＳＴＭの推奨する負荷容量６ｐＦに交換してみました。両端のコンデンサは１２ｐＦです。１時間で約２分進んでいます。ん～不可解です。

実車の汎用スイッチの論理を入れ替えたので、エンジンエミュレータでＳＤログの開始／停止を確認をしたのですが、ＬＯＷでログが開始します。ダイアログのヘルプにはＨＩＧＨで開始、ＬＯＷで停止と書いてあります。因みに、ヘルプにはポーリングとトグルの動作モードの記述がありますが、ダイアログに動作モードの選択ボタンはありません。

ソースコードを調べてみます。ＳＤ＿ｌｏｇｇｅｒ．ｃｐｐに外部ピンによるログの開始のコードがあり、ＬＯＷで開始になっていました。

外部ピンをＡｕｘに指定すると、ゲージに表示ですます。２４ピンをＡｕｘ２に設定してゲージ表示させながら、エンジンエミュレータで２４ピンを変化させてＳＤログの開始／停止の動作を確認しました。ＬＯＷで開始で間違いないです。実車の汎用スイッチは前の状態に戻します。

９月３０日
ＲＴＣの５１２Ｈｚを測定して気が付いたのですが、アナログディスカバリの周波数偏差の測定値がトリガ位置によって少し変わります。下はトリガ位置がセンタで偏差が大きい時です。最小は５０７.９Ｈｚ、最大は５１６Ｈｚです。偏差は約８Ｈｚです。

下はトリガ位置を左に移動させた時。最小は５１１.９Ｈｚ、最大は５１２Ｈｚで、偏差が少ないです。多分こちらが実際の測定値ではないかと思っています。ＤＩＧＩＬＥＮＴのフォーラムに質問してみました。

今日のガレージ内は２８℃位で過ごしやすいです。汎用スイッチの論理を再度反転して、元に戻しました。

６月の中旬にガレージ内が暑くなり、中断していたハーネスの確認作業を再開します。記録ノートと配線図を見ながら、残っているセンサとＥＣＵコネクタ間の確認をします。記録ノートは湿気でカビだらけです。

気温センサに取り付けた、燃調調整ボリュームが反応しないので分解しました。原因は赤枠の半田不良でした。

基本的なハーネスの確認作業は終了しました。

１０月１日
アナログディスカバリの周波数の偏差がトリガ位置によって違う件でＤＩＧＩＬＥＮＴのフォーラムから回答がありました。オシロスコープ波形のトリガエッジの指定と周波数測定のエッジは別物でした。ちょっと分かりにくいです。下はスクリーン左端に立ち上がりエッジが出現します。この時、周波数測定は立ち上がりエッジで行われ、偏差は少なくなります。