Hallo, habe hier einen NWT4 mit einem PIC16F876-uController. Plötzlich ging das Gerät nicht mehr. Habe dann nach etlicher Fehlersuche den PIC neu geflasht und jetzt läuft wieder alles, wie es soll. Anscheinend war also ein Fehler im Programmspeicher entstanden. Gibt es klassische Ursachen für dieses Problem? (vielleicht kann ich irgendetwas an der Schaltung verbessern, damit das nicht mehr passiert)
Dann zeig doch mal deine Schaltung.Dann können wir sie vl. verbessern.
Vielleicht hast Du den Controller 5000x geflasht. Aber auch wenn nicht es reicht eine defekte Speicherzelle, die ihre Ladung nicht dauerhaft halten kann und Dein Programm stürzt ab. Wenn das nicht oft vorkommt, dann würde ich einfach mal auf einen Montags-Controller tippen. Ansonsten habe ich bei AVRs schon erlebt das bei extremer Hitze, z.B. Heißluft, die Firmware schäpps war. Also nochmal aufgeflasht werden musste. Das habe ich mehrmals erlebt. Bei den PICs noch nie... Gruß, H
HB schrieb: > Gibt es klassische Ursachen für dieses Problem? Z.B. schlampige Programmierung. Dieser µC kann seinen Programmspeicher selbst beschreiben, und wenn er das tut, weil z.B. ein aktivierter aber nicht behandelter Interrupt auftritt, hüpft er evtl. in das Stück Code, das den nötigen Overhead für das Schreiben des Flash enthält.
Angehängte Dateien:
-
EEprom.jpg
280 KB
HB schrieb: > (vielleicht kann ich irgendetwas an der Schaltung verbessern, damit das > nicht mehr passiert) Was mir spontan einfaellt: Stelle sicher, dass die Betriebsspannung stabil ist.Solltest Du das EEprom benutzen kannst Du Pech haben, dass unter Brown-Out-Bedingungen das EEprom mit falschen Werten beschrieben wird.Greift der Controller auf das EEprom zu kommt es fast zwangslaeufig zum Absturz. Eventuell Brown-Out aktivieren: #pragma config BOR = ON
Ich hatte ähnliches schon mit anderen µC. Also zerschossenes Flash und gesetzte Flags (wie security-Bit). Extrem sporadisch, ein Bastler würde das nie haben - von zehntausenden Geräten im Feld nur wenige. Das war mutmaßlich kein Fehler vom µC-Hersteller, sondern war auf die Stromversorgung zurückzuführen. Zumindest war der Fehler bei Geräten verschwunden, die eine verbesserte Versorgung hatten. Bei den alten war die Spannung beim Einschalten nicht monoton steigend. Brown-Out ist also ein gutes Stichwort. Auch gut ist, mal ein Scope dranhängen, und kucken, wie Hochlauf und Ausschalten aussehen. Stimmt die Spannungssteilheit? Gibts Einschränkungen im Datenblatt in der Hinsicht? Was tut der Resetpin, ist der Pegel dort stabil? Wenns nochmal passiert: Erst mal das Flash dumpen. Dann siehtst du, obs ein Page-Erase war oder ein gekipptes Bit. Ein Bit kann man per Software eigentlich nicht einzeln kippen, ein Page-Erase kann auch ein Softwarefehler sein.
Würde auch UMBEDINGT als erstes das POR setzen. Das hat schon bei manch schlechte Spannungsversorgung geholfen. Eventueller Versuch: Programm auslesen, in den Config Bits den POR setzen. Neu flashen. An den Resetpin noch einen kleinen Keramikkondensator. Ich hoffe mal, das der Reset Pin nicht rausgeführt wurde und als Eingang o.ä. dient.
Du könntest rund um die Sequenz der Schreibbefehle auch GOTO's an den Resetvector einfügen, so dass nur ein gezielter Einsprung an genau die Adresse einen Lösch/Schreib-Vorgang auslöst, nicht jedoch ein durch Glitches oder Programmierfehler "entlaufener" Programmzähler. Nutzt du die Table-Write Befehle für einen Bootloader oder als EEPROM-Ersatz?
Vlt. war das Programm nicht "zerschossen"? Es könnte auch einfach ein Bug in deinem Code sein, welcher zu genannten Verhalten führt... Wenn du nun neu beschreibst, läuft es wieder. Vlt. kommt der Fehler aber irgendwann wieder...
Keine Ahnung was ein NWT4 ist, aber bei einem meiner Projekte wurde der PIC-Flash ebenfalls sporadisch gekillt. Ursache waren Spannungspitzen, erzeugt von einer induktiven Last (Motor), die von einer PWM gesteuert wird. Zudem gab es eine Drehzahlmessung per Back-EMF, die über einen der ADCs im PIC gemessen wurde, also ein Rückkopplungszweig vom Motor direkt in den Controller. Nach einigen Minuten Betrieb war der Flash jedesmal im völlig desolaten Zustand. Zurücklesen und Vergleich mit dem Original ergab das Ausmaß der Zerstörung, das war schon erstaunlich. Gelöst habe ich das Problem durch passende Drosseln. Seitdem gab es keine Probleme mehr.
MaWin schrieb: > Fred R. schrieb: >> POR > > Meinst du BOD? Nein. Meinte den Brown Out Reset. War ein kleiner Fehler meinerseits. Solange es sich um keine Low Power Applikation handelt, sollte der Power Up Timer sowieso aktiv sein.
Hallo, Danke für die vielen Antworten und Vorschläge!!! Hier vorab noch die beiden Hex-Files, das Orginal-File (fw_119_7_mit_bootloader.hex) und das File, das ich vor dem Neuflashen vom Pic ausgelesen habe (119_7_von_def_PIC_gelesen). Kenne mich selber mit Pic-Controllern nicht aus, hatte extra für den Bau des NWT4 einen Brenner gebastelt.
Hallo HB Ich habe mal Deine beiden Hex-Files durch den Disassembler laufen lassen. Die Fehler musst du aber schon selber raussuchen (ist ja schon optisch sehr unterschiedlich). mfG Ottmar
Ottmar K. schrieb: > Die Fehler musst du aber schon selber raussuchen (ist ja schon optisch > sehr unterschiedlich). Die ersten 16 Byte sind unterschiedlich. HB schrieb: > Anscheinend war also ein Fehler im Programmspeicher entstanden. Kannst du nicht vor'm proggen das WRT bit im config löschen? Verhindert internes flash schreiben. Aus dem Datenblatt: ... is that the WRT configuration bit, when clear, prevents any writes to program memory (see Table 4-1).
Das ist der aktuelle Zustand der Configbits: FOSC HS oscillator WDTE Disabled PWRTE Enabled BOREN Enabled LVP Disabled CDP Disabled WRT Enabled DEBUG Disabled CP Disabled X4U schrieb: > Kannst du nicht vor'm proggen das WRT bit im config löschen? Verhindert > internes flash schreiben. Also WRT --> Disabled Der PIC muss im laufenden Betrieb die Kalibrierungsfrequenz (interne CLK vom AD9851) speichern können (ich denke mal, im EEPROM). Stört dann WRT Disabled?
PS: Danke auch an Ottmar fürs Disassemblieren! Fred R. schrieb: > Einen Sprut Brenner? Glaube nein, es ist ein Brenner mit Parallelport und 74ALS05.
HB schrieb: > habe hier einen NWT4 mit einem PIC16F876-uController. Hmm.. Also so wie ich die Entwicklung der Funkamateur-Wobbler gesehen habe, ist sowas kein Wunder. Hab selber einen (mit AD9951, bis 160 MHz, vom FA) und die originale Firmware sah so aus, daß sie einen Bootlader enthielt, um eben per serieller Schnittstelle neue Versionen der Firmware auf den PIC laden zu können. Ist zwar GENIAL.. gedacht, führt aber dann, wenn man den zugehörigen Jumper gesteckt hat oder mal eben im Wobbler was gemessen hat, gelegentlich zum Generallöschen des PIC eben durch den Bootlader. Sobald der PIC nach dem Reset den RB0 auch nur kurz auf low sieht, ist die Firmware weggelöscht. Durch sowas zusammen mit anderen Unüberlegtheiten sind dann diverse Pins blockiert (z.B. RB0 und weitere ADC-Eingänge) und deshalb ist die originale Firmware von Andreas ausgesprochen unflexibel. Kein Wunder also, daß da offenar der Wunsch entstanden ist, alle nase lang eine andere Firmware draufzuflashen. Ich hab den ganzen Kram durch was Eigenes ersetzt, sowohl auf dem PIC als auch auf dem PC. Aber dort eben nur für Windows (wg. Delphi) und eben nicht für andere OS - und ohne den Bootlader. W.S.
Mal ausführlich: X4U schrieb: > Aus dem Datenblatt: > ... is that the WRT configuration bit, when clear, > prevents any writes to program memory (see Table 4-1). HB schrieb: > Also WRT --> Disabled Die Funktion nennt sich WRT was wohl write bedeuten soll und write flash meint. Wenn das also enabled ist dann ist schreiben erlaubt. Das deckt sich mit dem Datenblatt. In der Beschreibung des config registers steht da: bit 9 WRT: FLASH Program Memory Write Enable 1 = Unprotected program memory may be written to by EECON control 0 = Unprotected program memory may not be written to by EECON control Gilt also nur für das flash und nicht für das EEprom. Da steht imho auch das gegen auslesen geschützter Speicher immer gegen überschreiben geschützt ist. Du hast also 2 Möglichkeiten.
HB schrieb: > Der PIC muss im laufenden Betrieb die Kalibrierungsfrequenz (interne CLK > vom AD9851) speichern können (ich denke mal, im EEPROM). Vermutlich kann man das prüfen indem du: - das EEprom löscht - das ganze einmal durchlaufen lässt - prüfst ob das EEprom noch leer ist
ESD würde ich als Ursache auch nicht ausschließen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.