dsPICのEEPROM読み取り/書き込みエラー

Microchip dsPIC30F6012aを実行しています。私はいくつかのPCBにこのチップを搭載しており、すべて同じソフトウェアを実行しており、それらすべてに同じ問題が見られます。これは、1回限りの運用上の問題ではなく、システム上の問題を意味します。問題は再現可能でもあります。つまり、どこを見るかわかっていれば、問題を解決できるはずです。しかし、アプリケーションのデバッグはまだ驚くほど困難です。

テスト中のボードは24Vを受け入れ、V7805を介して5Vに降圧されます。チップは、内部発振器と16x PLLで動作し、約29.5 MIPSの動作速度を提供します。このボードの関連コードは基本的に非常にシンプルです。ウェイクアップし、EEPROMからデータを読み取り、無限ループに入ります。ミリ秒ごとに割り込み、環境データを観察し、更新された値をEEPROMに書き込みます。他にも状況はありますが、無関係なコードがコメント化されていても問題が発生するので、当面の問題に関連していないことは間違いありません。

一般的な使用では、95％の時間は、ボードがメモリ内の正しい値で起動し、そのビジネスについて続行します。ただし、残りの5％の時間は、不正な値で起動します。具体的には、持っているはずのデータのビット反転バージョンで起動します。私が見ているのは4バイトの符号なしlongであり、longの上位ワードまたは下位ワードのいずれかが反転する可能性があります。たとえば、10は2 ^ 16-10になり、後で2 ^ 32-10になります。手動で数十回電源を入れ直すことでグリッチを再現できますが、これはあまり一貫しておらず、スイッチフィンガーがすり減っています。

問題を制御された方法で再現するために、テスト中のボードに24V電源を駆動する2つ目のボードを作成しました。（別のdsPICがダーリントンオプトカプラーを駆動します。）テスターボードは24Vを1.5秒間オフにし（5Vレールが実質的に0に下がり、そこに1秒間留まるのに十分な長さ）、その後、構成可能な時間だけ24Vをオンにします。 。約520 mSのオンタイムで、毎回5回の電源サイクルでこのEEPROMグリッチを再現できます。

5Vレールは適切に動作しています。スコープを信頼できると仮定すると、ターンオンから1 mS以内に5Vで安定し、おそらく.4Vのオーバーシュートになります。ターンオフ時に指数関数的に0Vまで減衰し、50ミリ秒以内に1Vに達します。私は関連があると思われるビルド警告はなく、ファイルの最後にある未使用の変数と改行がありません。

私はいくつかのことを試しました：

• MCLRの有効化/無効化
• WDTの有効化/無効化
• コード保護の有効化/無効化
• 電圧低下検出電圧の有効化/無効化/変更
• パワーオンタイマーの有効化/無効化/変更
• メイン内部発振器のさまざまなPLL設定
• PICkit 3プログラマの接続/切断
• 5Vレールに470 uFの容量を追加
• MCLRピンの4.7kプルアップで.1 uFを追加/削除する
• コード内のすべての割り込みを無効にし、メインループにEEPROM更新のみを残す
• EEPROMの読み取りを開始する前に、スタートアップルーチンに1.5秒の遅延を追加する

また、値を変更せずにEEPROMに継続的に値を書き込んでから読み取るだけの別のテストコードも作成しました。数万回の反復でエラーは発生しませんでした。私が結論づけることができるのは、EEPROMの読み取りまたは書き込み、特に電源投入/電源切断で問題が発生したことです。

2007年以来、同じEEPROMライブラリを使用しています。時々不具合が発生しましたが、再現性はありません。関連するコードはここにあります：http:
//srange.net/code/eeprom.c
http://srange.net/code/readEEByte.s
http://srange.net/code/eraseEEWord.s
http：/ /srange.net/code/writeEEWord.s

他のアプリケーションで以前にEEPROMエラーを見たことがありますが、常に1回限りのグリッチであり、再現性や一貫性はありません。

誰かが何が起こっているのか考えていますか？試してみることが不足しています。

2つのことが頭に浮かびます。

まず、データシートによると、消去/書き込みサイクルには少なくとも0.8ms、最大2.6msかかります。書き込み操作につながる可能性がある1msごとに割り込みがあると言います。コードで、消去の一部と書き込み関数の一部の割り込みを無効にすることを確認しました。しかし、関数呼び出しのインタリーブがおかしいかもしれません。おそらく、消去と書き込みのシーケンス全体の割り込みを無効にするときに役立ちますか？

次に、電源が落ちている間に書き込みを行うと、電源電圧が動作電圧を下回った瞬間にEEPROMの書き込みが行われます。電源電圧を監視して、それが4.5Vを下回ると書き込みを拒否できます。これは、最小動作電圧として2.7Vを超えても十分長く続くことを想定しており、電圧低下検出はそのポイント以下でのみトリガーされるように設定されています

考えられるハードウェアの問題の多くを見てきました。それは問題ありませんが、これはおそらくファームウェアのバグです。

残念ながら、ソースコードは十分に文書化されておらず、視覚的に理解しにくいようにフォーマットされています。最初のファイルの上部には、外部ルーチンの宣言が含まれています。

void readEEByte（unsigned int、unsigned int、void *）;
void eraseEEWord（unsigned int、unsigned int）;
void writeEEWord（unsigned int、unsigned int、void *）;

このような宣言をクライアントモジュールにプライベートに置くことは悪い考えであるだけでなく、単一のコメントも見えません！これらのルーチンの名前から何を実行するかを推測することしかできず、呼び出し引数は完全に文書化されていません。さらにそのファイルには、「//」で始まるさまざまな行と等号の行全体があります。これらは視覚的な混乱を追加し、コードを追跡しようとするのが非常に面倒になります。

これはコードの操作にとって重要ではないと言うかもしれません。ただし、このような不適切なプログラミング方法は重要です。これにより、コードの記述が不十分になり、バグを発見したり、コードが実行するはずのことを発見したりすることが難しくなります。このすべてが、あなたが発見しているように、問題を見つけるのを難しくしています。2007年以降、このコードから時々不具合が発生しているとあなた自身が言っていました。それは、おそらく全体的なデザインが悪いバグの強力な手がかりであるはずです。

混乱を修正し、すべてのインターフェースを適切に文書化し、共通の宣言を一度書き込んだインクルードファイルに入れ、必要に応じて参照します。また、私に関連があると思われるビルド警告がないというあなたの声明は、巨大な赤信号です。再び、混乱を修正します。デバッグするときは、常に、簡単に再現可能で修正可能な問題から先に進んでください。時々それらは実際に困難な問題の原因であるか、時にはそれらを修正する際に他の問題の原因を発見します。コンパイラは、銀の大皿でだらしないことを警告しています。これ以上何が欲しいですか？未使用の変数はコードを理解しようとする人を混乱させるため、使用しないでください。新しい行が欠落していることに対する言い訳はまったくありません。繰り返しますが、特に他の誰かにコードを確認するように依頼する前に、それらの明らかな混乱を修正します。

清楚さと細部への注意。たくさん。

4個のdsPIC30F6014A（過去数か月で約10個使用）と同じ動作をしましたが、電源オフ時に散発的なデータ破損を回避する唯一の方法は、シャットダウンの直前にMCLRをゼロに設定することです。

明らかにこれは実際には実行可能ではないので、誰かが代わりに別の解決策を持っている場合は、「悪い」dsPICの交換を選択しました...