Ich habe zwei Platinen. Einer hat einen dsPIC30F6012a, der andere einen dsPIC30F6015. Beide werden aus separaten eigenständigen HEX-Projekten in MPLAB X unter Verwendung eines PICkit 3 programmiert. Beide Firmwares wurden vor diesem Zeitpunkt problemlos auf Dutzende von Einheiten angewendet. Derzeit funktioniert die Firmware korrekt, wenn sie von allen PCs bis auf einen programmiert wird. Auf diesem einen PC lassen sich seit gestern beide Firmwares ohne offensichtliche Fehler programmieren, aber mit ungefähr 1/20 der normalen Geschwindigkeit ausführen. Bis gestern hat dieser PC diese Boards auch ohne Probleme programmiert.
Begrüßungsbildschirme dauern statt fünf Sekunden zwei Minuten, Lichter blinken sehr langsam, und ansonsten funktioniert alles einwandfrei. Es ist fast so, als ob die Konfigurationsbits des Oszillators geändert wurden, aber mir ist keine Stelle in MPLAB X bekannt, die für ein eigenständiges Projekt durchgeführt werden kann.
Also zwei verschiedene Firmwares, auf zwei verschiedenen Chips, auf mehreren Instanzen des gleichen PCB-Designs, die mit unterschiedlichen Geschwindigkeiten laufen, abhängig nur von dem PC, der zu ihrer Programmierung verwendet wird. Die Neuprogrammierung einer langsamen Karte auf einem "guten" PC behebt das Problem; Neuprogrammierung derselben Karte auf dem "schlechten" PC bringt sie zurück. Ich kann mir nur vorstellen, dass auf diesem einen PC jemand auf die Schaltfläche "Lass es langsam gehen" geklickt hat, aber ich kann nichts finden, was so beschriftet ist. (Unsere Techniker sind jedoch ziemlich kreativ.) Ich deinstalliere gerade MPLAB X, lösche die Benutzereinstellungen und installiere eine neuere Version neu. (Geht von 1.3 zu 1.6.) Aber selbst wenn es dadurch behoben wird, bin ich immer noch nicht glücklich darüber, 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 es MPLAB 8 früher zuließ). Die einzige Möglichkeit, wie die Konfigurationsbits "falsch" sein könnten, besteht darin, dass 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" Platinen auf einem "funktionierenden" PC das Problem tatsächlich behebt. Probieren Sie das aus.
Eine andere Sache, die Sie tun könnten (wenn Sie keinen Codeschutz verwenden), ist, die HEX-Datei von einem "funktionierenden" Setup zurückzulesen und diese in eines der fehlerhaften Boards zu flashen. Dies sollte die Codeänderung als eine der Unsicherheiten eliminieren.
Ein weiteres (unwahrscheinliches) Szenario ist, 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, und wenn das PICkit3 eine Verbindung herstellt, sollten Sie einen Revisionscode sehen, den Sie mit der Silizium-Revision vergleichen können.
BEARBEITEN: Es ist jetzt an der Zeit sicherzustellen, dass die verschiedenen Installationen von MPLAB X auf allen PCs übereinstimmen - handelt es sich um dieselbe Revision? Sind sie die neuste Revision?
Immer wenn es eine neue Version von MPLAB X gibt, wird die PICkit3-Firmware in der Regel aktualisiert - es kann ein Fehler oder eine Inkompatibilität mit älterer PICkit3-Firmware und Ihrer HEX-Datei vorliegen.
Ich hatte kürzlich eine ähnliche Situation (jetzt, wo es mir gerade dämmerte - 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). Als dieser PC mit MPLAB 8 v8.88 mit demselben Programmierer und derselben HEX-Datei aktualisiert wurde, funktionierten die Dinge wieder. Seltsam.
Benutzer17592
Stefan Colling
Chris Stratton
Stefan Colling
Kevin Chen