PIC 12F508 Osccal Wert

[RoboHolIC]

Hallo, Daniel.

Mehr oder weniger interessant in diesem Zusammenhang sind folgende Teile der von dir verlinkten Doku:

Kapitel 4.1, Seite 15
Kapitel 4.6, Seite 24
Kapitel 7.2.5, Seite 44
Kapitel 10, Table 10-4, Seite 75
Keine Angaben zur quantitativen Wirkung eines OSCCAL-Inkrements. Aber zum Glück habe ich falsch getippt: Es sind ja nur sieben Bit !

Der reale Resetvektor des PIC12F508 ist die letzte Programmadresse. Dort steht ab Werk der niemals geschützte (Zitat: "uncode protected", vermutlich kein Oxford-Englisch) Kalibrierwert, verpackt als MOVLW XX-Befehl. Nach dessen Ausführung beim Reset landet die Programmausführung durch Überlauf des Program Counters bei 0x0000.
Den so in W geladenen Wert kann man ignorieren und den effektiven Resetvektor als 0x0000 annehmen.
Andernfalls kann man den durch das MOVLW XX ins Working Register W geladenen Wert in das Register OSCCAL schreiben und so die Werkskalibrierung erst zur Wirkung bringen.

Beim nächsten frischen Controller dieser (Eigen-)Art solltest du also VOR dem ersten Programmieren/Löschen den Programmspeicher auslesen und den fälligen MOVLW XX -Befehl durch disassemblieren ermitteln oder aber als Zahlenwert auslesen und anhand des Befehlssatzes den Kalibrierwert rekonstruieren.

Das Implantieren des Kalibrierwertes geschieht im Assemblercode durch
ORG 0x0000 ; Absolut-Positionierung von Code, hier: der effektive Resetvektor
MOVWF OSCCAL ; Kalibrierwert zur Wirkung bringen

... <more individual code >


ORG 0x03FF ; Absolut-Positionierung von Code:
; an diese Adresse schreibt der Assembler den/die nachfolgenden Befehl(e)
; das muss die letzte Code-Speicherzelle und somit der tatsächliche processor reset vector sein
MOVLW dein_kalibrierwert
END ; directive 'end of program'

Ich habe in PIC16F876-Assembler geschrieben; evtl. muss das angepasst werden. Das Prinzip ist hoffentlich erkennbar.
Alles klar? Sonst frag nochmal nach.

Gruß
Christian.

[Transistortöter]

Hallo Christian ,nach der Frage ob alles klar ist muss ich nein sagen.
Das sind für mich Bömische Dörfer....
Ich habe bis vor 4 Tagen noch nichts am Hut mit den PIC's gehabt,geschweige irgend etwas geschrieben bzw programmiert
Von daher grübel,grübel
Ich glaube ich werde es nicht schaffen,
den wert alleine reinzuschreiben...



Gruss Daniel

[Transistortöter]

Hallo Cristian ich habe da mal was probiert nur es geht immer noch nicht.

siehe hier: ORG 0x0FFF
MOVLW 0x0C16
END

Jenes habe ich als ASM File gespeichert und dann mit MPASM assembliert

Die assemblierte datei als Hex file gespeichert
sieht dann so aus:

:21FFE00160CBF
:00000001FF

wenn ich jene hex File brennen will ändert sich der Osccalwert trotzdem nicht:

Wo ist der Fehler??????

Gruss Daniel

[RoboHolIC]

Hallo Daniel.

Wenn ich mich recht erinnere, ist die höchste Programmadresse des fraglichen Controllers die 0x1FF, entsprechend 512 Worten Programmspeicher ( 0 .. 511).
Folglich muss die ORG-Anweisung zu

ORG 0x01FF

korrigiert werden. Dann sollte die Kalibrierung eigentlich wieder greifen.

Allerdings kann das Register OSCCAL nur ein Byte speichern, du gibst aber 12 Bit an. Es wird vermutlich nur 0x16 wirksam werden. Das nicht implementierte Bit 0 ist dabei noch das geringste Übel.

Christian.

[RoboHolIC]

Ich hab mich geirrt, der Controller kann nur 512 Programmbefehle. Ich habe es oben korrigiert.

[Transistortöter]

Habe es geschafft die Osccals bei allen Pic´s wiederherzustelln Man nehme einen Fabrikneuen Pic lese ihn aus und speichere die daten als Hex files.
Dann lädt man die hexfile hoch in das Programm (bei mir PigProg2009) und setze den Osccalwert unten ein), und dann alles Brennen........

Es kann doch so einfach sein....... hier der Hexcode:
:1003F000FF0FFF0FFF0FFF0FFF0FFF0FFF0F140C7B
:021FFE00FF3FA3
:00000001FF




@ Christian nochmals vielen Dank für Deine Hilfe

[RoboHolIC]

... die Osccals bei allen Pic´s wiederherzustelln Man nehme einen Fabrikneuen Pic lese ihn aus und speichere die daten als Hex files.
Dann lädt man die hexfile hoch in das Programm (bei mir PigProg2009) und setze den Osccalwert unten ein), und dann alles Brennen.......

Hmm, den Ablauf oder aber den Sinn dahinter verstehe ich noch nicht: Jeder PIC hat doch prinzipiell seinen eigenen, individuellen Kalibrierwert.
Hast du an dieser Stelle etwa Statistik geführt und evtl. entdeckt, dass deine Chips alle aus derselben Charge stammen und dass alle Kalibrierwerte einer Charge (fast) gleich sind? Ansonsten macht es ja keinen rechten Sinn, einen Chip mit einem fremden Kalibrierwert auszustatten.

[Transistortöter]

Hmm, den Ablauf oder aber den Sinn dahinter verstehe ich noch nicht: Jeder PIC hat doch prinzipiell seinen eigenen, individuellen Kalibrierwert.
Hast du an dieser Stelle etwa Statistik geführt und evtl. entdeckt, dass deine Chips alle aus derselben Charge stammen und dass alle Kalibrierwerte einer Charge (fast) gleich sind? Ansonsten macht es ja keinen rechten Sinn, einen Chip mit einem fremden Kalibrierwert auszustatten.

Hallo Christian
Genau so habe ich gedacht.Ich habe die restlichen Pics alle ausgelesen,und da die Kallibrierwerte fast alle gleich waren,habe ich einen Mittelwert genommen.
Es war für mich die einzigste Alternative jene wieder gangbar zu machen,mit Erfolg.Jenes Proggi was ich dir gesagt habe, diente als Testversuch,
und es hat geklappt.

Mag sein ,Es war ne Schapsidee aber immerhin sie funktioniert:........


Gruss Daniel

[RoboHolIC]

. . . da die Kallibrierwerte fast alle gleich waren, habe ich einen Mittelwert genommen.

Wenn du alle 12F508-Controller auf einen Rutsch gekauft hast, ist die Wahrscheinlichkeit einigermaßen hoch, dass sie alle aus derselben Charge stammen und dein Vorgehen ist gar keine Schnapsidee sondern sehr sinnvoll. Das wird der Hersteller vermutlich nicht anders machen, sonst müsste man die Chips wohl mit Gold aufwiegen.