PIC 12F508 Osccal Wert

[Transistortöter]

Hallo alle zusammen

Ich habe ein kleines Problem: Ich habe den Osccal wert des 12F508 versehentlich überschrieben. 0x000 bzw 0x0FFF anderer Proz.

Da ich Neuling auf dem Gebiet der Pic´s bin habe ich net so Recht die Ahnung davon.

Gibt es eine Möglichkeit, den Osccal wert wieder herzustellen?

Ps: Habe mir vorsichtshalber ein paar neue gekauft.

Mein erster Brenner war ein JDM-Brenner ist aber nicht der Hit (selbstbau).
Jetz habe ich einen von Vellmann K8076 mit dem Proggi WinPic2009.


Mfg Daniel

[RoboHolIC]

Nein, eine Wiederherstellung im Sinne von "undo delete" gibt es nicht.
Bei den nächsten Chips solltest du einen Aufkleber mit dem jeweiligen vorweg (also VOR der ersten Programmierung) ausgelesenen Eichwert auf den PIC aufkleben.

Ansonsten bleibt noch der Weg, ein Minimalprogramm mit genau definierter Schleifendurchlaufzeit zu erstellen oder aber eine Interruptroutine für z.B. 1 Sek., dort ein Bit für eine LED zu toggeln, Zeitbedarf zu messen und dich dann Bit für Bit an den korrekten Kalibrierwert heranzutasten. Das sind acht Iterationen: Bit setzen ... messen, ob zu schnell/langsam ... Bit behalten/löschen ( ... nächstes Bit einpflanzen), beginnend mit dem MSB.
Gibt es im Datenblatt eine Angabe über den Zusammenhang zwischen numerischem Kalibrierwert und prozentualer INTOSC-Frequenzveränderung? Das wäre der direkte Weg zum neuen alten Kalibrierwert.

[Transistortöter]

Hallo RoboHolIc

Danke für deine Tips nur kann ich damit nicht so recht was anfangen.
Ich bin absoluter Neuling auf dem Gebiet aber schön das du auch in Berlin wohnst so wie ich.

Ich habe da was im netz gefunden, ob da was zu steht über den Zusammenhang zwischen numerischem Kalibrierwert und prozentualer INTOSC-Frequenzveränderung weiss ich nicht.

Hier mal de Link:----->http://www.google.de/url?sa=t&rct=j&...,d.Yms&cad=rja


Ist das Datenblatt......

Mfg Daniel

[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.