通常の数分の1の速度で動作するdsPICチップ

2つのPCBがあります。1つはdsPIC30F6012a、もう1つはdsPIC30F6015です。どちらもPICkit 3を使用して、MPLAB Xの独立したスタンドアロンHEXプロジェクトからプログラムされています。どちらのファームウェアも、この時点までに数十のユニットに問題なく適用されています。現在、ファームウェアは1つを除くすべてのPCからプログラムされたときに正しく動作しています。その1台のPCでは、昨日から、両方のファームウェアは明らかなエラーなしにプログラムされますが、通常の速度の約1/20で実行されます。昨日まで、そのPCはこれらのボードも問題なくプログラミングしていました。

スプラッシュスクリーンは5秒ではなく2分かかり、ライトは非常にゆっくり点滅しますが、これに加えてすべてが正しく動作します。発振器の構成ビットが変更されたかのように見えますが、スタンドアロンプ​​ロジェクトで実行できるMPLAB Xのどこにも気づいていません。

したがって、2つの異なるチップ上の2つの異なるファームウェア、同じPCBデザインの複数のインスタンス、それらをプログラムするために使用されているPCのみに依存して異なる速度で実行されます。「良い」PCで遅いボードを再プログラミングすると、問題が修正されます。「不良」PC上の同じボードを再プログラミングすると、元の状態に戻ります。私が理解できるのは、その1台のPCで誰か​​が[ゆっくり実行する]ボタンを押したということだけですが、そのラベルが付いたものは見つかりません。（ただし、私たちの技術はかなり独創的です。）現在、MPLAB Xをアンインストールし、ユーザー設定を消去し、より新しいバージョンを再インストールしています。（1.3から1.6に変更されます。）しかし、それで問題が修正されたとしても、何が起こっているのかわからないので、私はまだ満足していません。誰かがこの問題について何か洞察を持っていますか？

MPLAB Xでは、設定ビットをコードと別に設定することはできません（MPLAB 8を使用して行うことができます）。構成ビットが「間違っている」唯一の方法は、誰かがコードを変更した場合です。スタンドアロンのHEXファイルプロジェクトを使用しているため、これはほとんどありません。

「動作している」PCで「不良」なボードの1つを再プログラミングしても問題が実際に解決するかどうかは、まだ明らかにしていません。試してみてください。

（コード保護を使用しない場合に）できるもう1つのことは、「動作中」のセットアップからHEXファイルを読み戻して、誤動作しているボードの1つにフラッシュすることです。これにより、不確実性の1つとしてコード変更が排除されます。

別の（ありそうにない）シナリオは、dsPIC株式が複数のリビジョンをカバーしていて、段階的な変更が何らかの理由でコードを無効にした場合です。ICの部品番号が正しいことを確認します。PICkit3を接続すると、シリコンリビジョンと相互参照できるリビジョンコードが表示されます。

編集：MPLAB XのさまざまなインストールがすべてのPCで一致していることを確認する時が来ました-それらは同じリビジョンですか？それらは最新のリビジョンですか？

MPLAB Xの新しいバージョンがあるときはいつでも、PICkit3ファームウェアはアップグレードされる傾向があります-古いPICkit3ファームウェアとHEXファイルとのバグまたは非互換性があるかもしれません。

私は最近同様の状況になりました（今はそれが私に始まったばかりです-ええと）MPLAB XとXC16を搭載したマシンで生成したHEXファイルは私のマシンでは正しくプログラムされましたが、MPLAB 8 v8を使用する別のマシンではプログラムされませんでした。 50-コードの実行速度が遅いようです（初期化LEDが遅いようです）。そのPCが同じプログラマーと同じHEXファイルを使用してMPLAB 8 v8.88で更新されたとき、物事は再び機能し始めました。変だ。