dsPIC-Chips laufen mit einem Bruchteil der normalen Geschwindigkeit

Ich habe zwei Leiterplatten. Einer hat einen dsPIC30F6012a, der andere einen dsPIC30F6015. Beide werden mit einem PICkit 3 aus separaten eigenständigen HEX-Projekten in MPLAB X programmiert. Beide Firmwares wurden vor diesem Zeitpunkt problemlos auf Dutzende von Einheiten angewendet. Derzeit funktioniert die Firmware ordnungsgemäß, wenn sie von allen PCs bis auf einen programmiert wird. Auf diesem einen PC programmieren beide Firmwares ab gestern ohne offensichtlichen Fehler, aber mit ungefähr 1/20 normaler Geschwindigkeit. Vor gestern hat dieser PC auch diese Karten problemlos programmiert.

Begrüßungsbildschirme dauern zwei Minuten statt fünf Sekunden, die Lichter blinken sehr langsam, und ansonsten funktioniert alles korrekt. Es ist fast so, als ob die Oszillatorkonfigurationsbits geändert worden wären, aber mir ist nirgendwo in MPLAB X bekannt, was für ein eigenständiges Projekt möglich ist.

Also zwei verschiedene Firmwares, auf zwei verschiedenen Chips, auf mehreren Instanzen desselben PCB-Designs, die mit unterschiedlichen Geschwindigkeiten laufen, abhängig davon, welcher PC zum Programmieren verwendet wird. Das Neuprogrammieren einer langsamen Karte auf einem "guten" PC behebt das Problem. Wenn Sie dieselbe Karte auf dem "schlechten" PC neu programmieren, wird sie zurückgebracht. Ich kann mir nur vorstellen, dass auf diesem einen PC jemand auf die Schaltfläche "Langsam fahren" geklickt hat, aber ich kann nichts finden, das mit dieser Bezeichnung versehen ist. (Unsere Techniker sind jedoch ziemlich kreativ.) Ich deinstalliere derzeit MPLAB X, lösche die Benutzereinstellungen und installiere eine neuere Version neu. (Von 1,3 auf 1,6.) Aber selbst wenn das das Problem behebt, bin ich immer noch nicht glücklich, nicht zu wissen, was los ist. Hat jemand einen Einblick in dieses Problem?

In MPLAB X können die Konfigurationsbits nicht getrennt vom Code gesetzt werden (wie bei MPLAB 8). Die Konfigurationsbits können nur dann "falsch" sein, wenn jemand den Code geändert hat. Da Sie ein eigenständiges HEX-Dateiprojekt verwenden, ist dies unwahrscheinlich.

Sie haben nicht gesagt, ob die Neuprogrammierung einer der "schlechten" Karten auf einem "funktionierenden" PC das Problem tatsächlich behebt. Probieren Sie es aus.

Eine andere Möglichkeit (wenn Sie keinen Codeschutz verwenden) besteht darin, die HEX-Datei aus einem "funktionierenden" Setup zurückzulesen und in eine der fehlerhaften Karten zu flashen. Dies sollte Codeänderungen als eine der Unsicherheiten beseitigen.

Ein weiteres (unwahrscheinliches) Szenario besteht darin, dass Ihr dsPIC-Bestand mehrere Revisionen abdeckt und eine schrittweise Änderung Ihren Code irgendwie ungültig gemacht hat. Stellen Sie sicher, dass die IC-Teilenummern korrekt sind. Wenn das PICkit3 eine Verbindung herstellt, sollte ein Revisionscode angezeigt werden, auf den Sie mit der Silizium-Revision verweisen können.

BEARBEITEN: Es ist jetzt Zeit sicherzustellen, dass die verschiedenen Installationen von MPLAB X auf allen PCs übereinstimmen - sind sie dieselbe Revision? Sind sie die neueste Version?

Immer wenn es eine neue Version von MPLAB X gibt, wird die PICkit3-Firmware häufig aktualisiert. Möglicherweise liegt ein Fehler oder eine Inkompatibilität mit der älteren PICkit3-Firmware und Ihrer HEX-Datei vor.

Ich hatte kürzlich eine ähnliche Situation (jetzt, wo es mir gerade aufgefallen ist - duh), in der eine HEX-Datei, die ich auf meinem Computer mit MPLAB X und XC16 generiert habe, auf meinem Computer korrekt programmiert wurde, aber nicht auf einem anderen Computer mit MPLAB 8 v8. 50 - Der Code schien langsamer zu laufen (Initialisierungs-LEDs schienen träge zu sein). Als dieser PC mit MPLAB 8 v8.88 unter Verwendung desselben Programmierers und derselben HEX-Datei aktualisiert wurde, funktionierten die Dinge wieder. Seltsam.