Hallo Alle zusammen, ich hab mir eine USB Steuerung für ein paar stärkere 12V EMotoren gebaut. Leider vergisst der PIC 18f2550 immer wieder seine Programmierung. Nach 2 - 3 Benutzen (Strom Aus, Strom An) wird der Controller nicht mehr am BUS erkannt und der Bootloader hat sich gleich mit verabschiedet, so dass ich den Chip aus der Schaltung holen muss und ihn neu programmieren... Es handelt sich dabei auch nicht um einen Fehler eines einzelnen Chips. Inzwischen habe ich ein neuen verbaut und das gleich Verhalten beobachtet. Zur Funktion: An sechs IO Pins hängen RC Glieder und ich knöpfe mir zyklisch immer eins vor. Erst wird der Pin auf analogen Input umgeschaltet, dann die Spannung gemesse und wenn sie nicht im Zielfenster liegt entweder ein paar Instruktionen lang geladen oder entladen. Die Spannung am RC Glied füttere ich dann in die Leistungsstufe - siehe Bild. Das funktioniert soweit. Die Versorgung ist ein PC Netzteil mit 12V für die Motoren und 5V, die ich schonmal für die Versorgung des Controllers benutzt habe. Den Controller mit der Versorgungsspannung vom Host zu betreiben hat da auch nichts geändert. Ground des Buses und des Netzteils hab ich zusammen gelegt. Und nun meine Frage: Warum vergisst mein Chips sein Programmierung ?
Angehängte Dateien:
-
treiber.png
7,2 KB
Der Pic kann seinen eigenen Programmspeicher selbst flashen. Stell' mal die entsprechenden Config-Bits (Write-Protection) entsprechend ein und überprüfe dein Programm, ob Du irgendwo ins Nirwana springst. ( Und dann dort 'code' ausführst, der Dir deinen Flash ruiniert. Falls Du mit Boot-Loader flashst klappt das mit dem Write-Protecten natürlich nicht. Hier musst Du sicherstellen, daß dein BootLoader Niemals im laufenden Betrieb aktivert werden kann. (Auch hier liegt der Verdacht nahe, daß Du aus Deinem Programm in den Bootloader springst und dadurch irgendwas überschreibst. Viele Grüße, Marcus
Hi, Marcus schrieb: >... Und dann dort 'code' ausführst, der Dir deinen Flash > ruiniert. > ... > Auch hier liegt der Verdacht nahe, daß Du aus Deinem Programm in den > Bootloader springst und dadurch irgendwas überschreibst. DAs oben geschriebene wird wohl mit Abstand die häufigste Ursache für zerstörte Programmspeicherinhalte sein. Es gibt aber (neben Einzelfaktoren wie schadhafte Bausteine) noch einen Fehler der allerdings heute immer seltener Auftritt, aber im Falle das man Probleme hat durchaus Kopfzerbrechen bereiten kann. Wenn die Programmierspannung zu gering ist kann es sein das die Programmierung scheinbar erfolgreich war, aber nicht wirklich dauerhaft ist und der Pic dann ganz schnell vergesslich ist. Je nachdem wie dramatisch die Spannungsunterschreitung ist um so schneller tritt das Vergessen ein. Aber wie gesagt, die Oben von Markus genannten Ursachen sind um welten Wahrscheinlicher... Erst wenn du da nichts findest solltest du dich um mögliche EMV Probleme und erst dann um diese Möglichkeit kümmern... (Zu zeiten als man noch mit ein paar Widerständen und Dioden am PArallel- oder Seriellport gearbeitet hat -oder wo selbstbaubrenner noch an der Tageordnung waren- kam soetwas noch häufiger vor. HAtte das auch das eine oder andere mal das der 16C84, später 16F84 der sich ja definitiv nicht selbst löschen kann, nach ein paar Tagen auf einmal nicht mehr wollte...) Gruß Carsten
Vielen Danke für die Antworten ! Dass der Programcounter einen Ausflug in kreative Bereiche des ROMs unternimmt will mir nicht einleuchten. Die Firmware ist komplett in C ohne goto geschrieben. C Sprachkonstrukte können - bis auf einen Kompilerfehler - keinen Sprung ins Blaue erzeugen. Der Interrupt Handler und der Bootloader haben natürlich jeweils ein goto auf eine feste Adresse, die auch richtig sein muss, da der Chip erstmal seine Arbeit klaglos verrichtet. Durch die Harvard Architektur kann auch nicht eben Mal irgendwo eine Write Instruction für das ROM entstehen und die einzige Stelle an der es schon eine gibt ist im Bootloader. Der wiederrum schreibt nur, wenn er das Passende Kommando über den Bus bekommt ... oder ein misteriöse Sprung direkt in den Kontrollzweig für das Löschen bzw das Schreiben stattfindet. Zu letzt ist dann noch die Sache mit dem Timing. Der Fehler tritt irgendwann auf, wenn ich das System wieder in Betrieb nehme. Zu diesem Zeitpunkt habe ich den Kontroller schon einige Male über Stunden laufen lassen und auch mehrmals ein und aus geschaltet ohne das der Fehler aufgetreten ist. Wenn es also in meiner Software einen Fehler gibt, sollte er doch viel wahrscheinlicher wärend des Betriebs auftreten ... Was den Bootloader angeht, so ist das der von Microchip und ich unterstelle mal, dass der keine großen Bugs hat. Ich hatte auf einen bekannten elektrotechnischen Grund gehofft, wie Spannungsspitze durch die Induktivität der Motoren oder etwas in der Richtung. Ich mach den Programspeicher jetzt erstmal schreibgeschützt, programmiere das Ding ohne Bootloader und sehe dann ob es wieder vorkommt. Gruß an alles Leser
Ein häufiger Fehler ist, daß das Brownout nicht eingeschaltet ist. Ein MC mit Bootloader oder EEPROM aktiv braucht zwingend ein Unterspannungsreset. Sonst kann eine Unterspannung fehlerhafte Codeausführung bewirken, also z.B. ein Flash oder EEPROM Schreiben. Peter
Das Schreiben ins FLASH eines PIC ist nicht so einfach, wie Ihr das Euch vorstellt. Es muss eine bestimmte Befehlsfolge eingehalten werden und ein bestimmtes Timing. Accidentell kann das eigentlich nicht vorkommen. ABER: der Schreibvorgang ins EEPROM ist nahezu identisch mit dem ins FLASH, ist hier - falls EEPROM beschriebn wird - evtl ein "klitzekleiner" Programmierfehler reingerutscht?
Hat zwar nichts mit diesem Bootloader-Problem direkt, aber doch indirekt zu tun: Ich hatte mal beim PIC12F508 den Fall, dass wenn die Versorgunsspannung "glitch-artig" eingeschaltet wurde der kleine PIC hin und wieder mal mitten ins Programm gesprungen ist oder anderen Unsinn ausführte. Selbst der Power-On-Timer half da nichts. Gelöst habe ich das Problem, indem ich den gesamten restlichen Speicher mit Reset-Sprüngen auffüllt und ausserdem eine kleine Hash-Berechnungsroutine (Addieren, XORs mit Konstanten, ...) in der Initialisierungsteil packte und die erwarteten Resultate dann an verschiedenen Stellen des Programms abfragt. Stimmte das Resultat nicht überein, gab es sofort einen Reset. Das hat das Problem komplett gelöst.
Carsten Sch. schrieb: > Wenn die Programmierspannung zu gering ist kann es sein das die > Programmierung scheinbar erfolgreich war, aber nicht wirklich dauerhaft > ist und der Pic dann ganz schnell vergesslich ist. Je nachdem wie > dramatisch die Spannungsunterschreitung ist um so schneller tritt das > Vergessen ein. Ich kann das von Carsten beschriebene nur bekräftigen. Es gibt ganz offensichtlich Grenzbereiche bei denen die Programmierung zwar klappt, aber eben nicht dauerhaft ist. Erlebe das selber oft bei Sachen die einen Bootloader benutzen, und somit die eigentliche VPP für den PIC nicht wirklich festgelegt ist. Wenn da dann die Batterien ausgelutscht sind, oder dier Versorgung nicht 100% ist so das zwar alles noch funktioniert, aber halt gerade nur so, dann kommt es oftmals dazu das der betreffende PIC irgendwann sein programm "vergisst". Auch mit "irgendwas-das-geht" Programmern habe ich schlechte Erfahrungen gemacht. Seitdem ich "Standard" Programmer benutze habe ich das nichr mehr erlebt. Selbst di billigen PicKit-Clones machen da keine Probleme. Grüße, Chris
Horst Horstmann schrieb: > C Sprachkonstrukte können - bis auf einen > Kompilerfehler - keinen Sprung ins Blaue erzeugen. Das stimmt so leider überhaupt nicht. Insbesondere der C18 macht da treilweise ganz seltsame Dinge, insbesondere wenn man Pointer auf Funktionen beuntzt. Dürfte bei Dir aber wohl eher nicht der Fall sein. Grüße, Chris
Sergey schrieb: > Gelöst habe ich das Problem, indem ich den gesamten restlichen Speicher > mit Reset-Sprüngen auffüllt ... ?? Keine Ahnung wie das bei den PIC12 ist, aber zumindest bei den 18 (und ich glaube ich 16) ist es so das gelöschter Speicher ein NOP represäntiert, und somit der µC das ganze solange NOP't bis er an das Ende seine Speicher gekommen ist. Dann wird er Befehelscounter auf 0 gesetzt und das ganze fängt beim "echten" Start wieder an. Grüße, Chris
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.