Hallo an die Spezialisten, ich habe ein kleines Projekt mit einem PIC18F4550 auf Basis von Opensource etwas angepasst. Kernstück der Anpassung war der Einsatz eines adum1401 zur Potentialtrennung zwischen dem PIC auf der USB-Seite und einem RS485-Bus. Für mich war das der erste Kontakt mit PICs. Hat alles prima funktioniert, Leiterplatten wurden gefertigt, bestückt und getestet. Läuft einwandfei. Nun wurden aus der gleichen Serie vier weitere Leiterplatten bestückt, allerdings kamen PICs aus einer anderen Charge zum Einsatz. Ergebnis: funktioniert nicht mehr. Messen an der Schaltung ergibt, dass Pin RC7 (wird als serieller Eingang verwendet) auf High-Pegel liegt und sich selbst mit 1kOhm nach Masse nur wenige Millivolt nach unten bewegt. Meiner Meinung nach ist das ein Zeichen für einen aktiven Ausgang, klar, dass da nichts geht. Der Probeaufbau eines weiteren Exemplars mit einem Prozessor einer weiteren Charge ergab wieder eine einwandfreie Funktion, am Programm kann es also definitiv nicht liegen. Nun die Frage: Kann es sein, dass bei den vier fehlerhaften Exemplaren noch irgendwelche Einstellungen des PICs fehlen (oder vorhanden sind), die selbst ein Löschen und neu Programmieren (Galep-4 mit Adapter) nicht gerade zieht? Wie schon gesagt, ich habe keinerlei Erfahrungen mit PICs. Klar, die fehlerhaften Prozessoren werden ausgetauscht, kein Problem, aber die Ursache interessiert mich schon. JTAG haben die Dinger ja wohl nicht auf Port C ;-). Gruß Thomas
Hast du schonmal die Fuses überprüft? In MPLAB IDE unter Configure -> Configuration Bits kannst du die Bits deiner neuen PICS mit denen deines alten vergleichen.
Andreas schrieb: > Hast du schonmal die Fuses überprüft? > In MPLAB IDE unter Configure -> Configuration Bits kannst du die Bits > deiner neuen PICS mit denen deines alten vergleichen. Natürlich geht es da nur in MPLAB IDE. Der Galep müsste auch irgendwo ein Menü haben um die Fuses setzen zu können.
Wenn ich einen funktionierenden PIC auslese, sollten doch alle Daten (Programm, Fuses, EEPROM) mit gelesen werden und dann auch auf dem neuen Exemplar landen, oder? Lese ich einen funktionierenden PIC aus und vergleiche dann mit einem nicht funktionierenden, ergibt das keinerlei Abweichungen. Daher auch der Verdacht, dass da irgendwelche verdeckten Einstellungen selbst ein Löschen überstehen. Oder die Dinger sind schlicht und ergreifend Schrott... Thomas
>Wenn ... oder?
eben NEIN!
Schon mal was von Ausleseschutz gehört?
Falls dieser gesetzt ist (i.d.R. macht das jede Profifirma so, denn in
der SW steckt ja das Knowhow) so kannste den Chip eben NICHT mehr
auslesen und clonen.
Nur eine Teil-Identifikation ist lesbar, über den man (der SW-Autor)
festellen kann welche version seiner SW drin ist.
Steht alles im Datenblatt des uC.
Dort suchen nach "code protection" bzw. "CONFIG5L" "CONFIG5H",
Kapitel Program Verification and Code Protection
Ein geschützer Baustein liefert beim auslesen immer "Müll" oder "leer".
Er kann allerdings gelöscht und erneut programmiert werden (wenn man ein
Programm dafür hat).
Gruss
Wie im Erstposting zu lesen ist, habe ich das Programm selbst geschrieben und die funktionierenden wie auch die nicht funktionierenden Bausteine sind nicht geschützt. Die Bausteine lassen sich alle erfolgreich programmieren und verifizieren, auch ein Vergleich des Inhalts eines nicht funktionierenden mit einem funktionierendem Baustein ist erfolgreich. Die Frage ist nun eben, ob die Pics (mit denen ich Null Erfahrung habe) irgendeine Gemeinheit (also ein Feature) besitzen, was auch ein Löschen und neu Beschreiben des Bausteins überlebt, beim Vergleich nicht auftaucht und derartige Probleme verursachen kann. Ich kann es mir zwar nicht vorstellen, aber es bleibt ja nur übrig, dass alle vier Pics die gleiche Macke haben. Thomas
Du solltest benennen, welche Tools bzw. welches Programmiergerät du benutzt. Ich verwende ausschließlich MPLAB mit den originalen ICD3 sowie PicKit3 . Gruss
Thomas P. schrieb: > Nun die Frage: Kann es sein, dass bei den vier fehlerhaften Exemplaren > noch irgendwelche Einstellungen des PICs fehlen (oder vorhanden sind), > die selbst ein Löschen und neu Programmieren (Galep-4 mit Adapter) nicht > gerade zieht? Er hat einen Galep-4 mit Adapter, also hat er uns gesagt welche Hardware er zum proggen nimmt! Ich würde aber auch auf die Fuses tippen, oder da stimmt was nicht beim setzen der Ports...das sieht man aber nur mit Code (Glaskugel) Ich weiß nicht ob und wie man bei Galep-4 Fuses setzen kann. Gruß Ich
Die config words (fuses) hängt der Assembler oder Compiler normalerweise an die HEX Datei mit dran und der Programmer verarbeitet die auch richtig.
>Die config words (fuses) hängt der Assembler oder Compiler normalerweise >an die HEX Datei mit dran und der Programmer verarbeitet die auch >richtig. Wenn man sie im Quellcode definiert. Wenn man sie nur über die IDE einstellt wäre ich mir da gar nicht so sicher das die auch in der Hex Datei landen. Da sollte man vieleicht mal nachsehen.
Die Fuses werden im Hex-File (300000) bereitgestellt. Aus dem List-File: Configuration Fuses: Word 1: 0E24 PLL5 CPUDIV1 USBDIV HSPLL NOFCMEN NOIESO Word 2: 0E3F NOPUT BROWNOUT BORV21 VREGEN NOWDT WDT128 Word 3: 0500 CCP2C1 NOPBADEN LPT1OSC NOMCLR Word 4: 0080 NOSTVREN NOLVP ICSP1 NOXINST NODEBUG Word 5: C00F NOPROTECT NOCPB NOCPD Word 6: E00F NOWRT NOWRTC NOWRTB NOWRTD Word 7: 400F NOEBTR NOEBTRB Auch beim Auslesen werden die Fuses mit gelesen, ebenso beim Compare mit Verglichen - immer ohne Fehler. Thomas
So, das Thema hat mir keine Ruhe gelassen. Es blieb als Fehlerquelle ja nur noch das Programm selber übrig. Da das nicht von mir stammt (aber alle Quellen liegen vor) und ich auch keine Lust hatte, den CCS extra zu installieren, habe ich mal im lst-File herumgesucht. Es ist schon interessant, was ein Compiler aus einer Zeile Hochsprache so macht. Ursache war letzten Endes ein in einer Funktion versteckter Befehl BCF TRISC.RC7, der nach dem Setzen von RC6 und RC7 in den EUSART-Modus RC7 wieder auf Ausgang setzt und damit die Blockade verursacht. Wird im Hexeditor der Befehl durch einen NOP ersetzt, funktioniert alles wie gedacht. Interessant daran ist aber, dass es Revisionen des PIC18F4550 zu geben scheint, die diesen Effekt nicht aufweisen; also ein Umschalten von RC7 auf Ausgang nach dem Setzen des asynchronen EUSART-Mode ignorieren. Irgendwelche errata-Listen habe ich jetzt nicht mehr durchsucht, aber so ein inkonsistentes Verhalten gefällt mir nicht, auch wenn das eigentliche Problem der Programmierer war. Thomas PS: Ich mag PICs immer noch nicht.
Hast Du mal in den Microchip-Foren gefragt, da bekommt man sofort kompetente Antwort.
Thomas P. schrieb: > Interessant daran ist aber, dass es Revisionen des PIC18F4550 zu geben > scheint, ... welche Revisionen hast du denn? Wenn ich das Errata überfliege sind da einige Änderungen drin die den EUSART betreffen und damit zu tun haben könnten. Das Errata zu lesen halte ich für auch für obligatorisch. Wofür ist es denn sonst da? Microchip ist in Sachen Fehler zu kommunizieren sehr offen und professionell das sollte man nutzen. usuru schrieb: > Hast Du mal in den Microchip-Foren gefragt, da bekommt man sofort > kompetente Antwort. Evtl. nachdem man seine Hausaufgaben bzg. errata gemacht hat.
Jens Martin schrieb: > Wenn ich das Errata überfliege sind da einige Änderungen drin die den > EUSART betreffen und damit zu tun haben könnten. Wenn ich das überfliege, finde ich nichts, was auf mein Problem hindeutet. Für schnelles und genaues Lesen/Verstehen ist mein Englisch nicht gut genug. usuru schrieb: > Hast Du mal in den Microchip-Foren gefragt, da bekommt man sofort > kompetente Antwort. Bis gestern habe ich ja nicht gewusst, wie das Problem zustande kommt. Für mich ist das jetzt gelöst (-> korrekte Programmierung) und die Motivation für weitern Aufwand hält sich in engen Grenzen. Jens Martin schrieb: > Evtl. nachdem man seine Hausaufgaben bzg. errata gemacht hat. Die habe ich gemacht und u.a. die Schlussfolgerung gezogen, mich auch in Zukunft so gut wie möglich von PICs fern zu halten. Hat mir bis heute keine Nachteile beschert und wird hoffentlich auch so bleiben ;-). Thomas
Thomas P. schrieb: > Für schnelles und genaues Lesen/Verstehen ist mein Englisch > nicht gut genug. ... >> Evtl. nachdem man seine Hausaufgaben bzg. errata gemacht hat. > > Die habe ich gemacht und u.a. die Schlussfolgerung gezogen, mich auch in > Zukunft so gut wie möglich von PICs fern zu halten. Dann ist ja alles gut ;-)
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.