Was kann einem PIC16Fxxx das Programm zerschießen?

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:
> (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.

Fred R. schrieb:
> POR

Meinst du BOD?

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.

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.

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.