Hallo Leute,
ich arbeite das Tutorial ab und bin nun gerade bei dem Punkt UART.
Da Fusebits sehr häufig Probleme bereiten, habe ich bisher nicht daran
rumgestellt. Nun wollte ich aber auf externen Taktgeber umfusen und nun
funkt ISP nicht mehr. High Voltage geht, aber ISP nicht.
Mein Setup für ISP:
-STK500, keine perepherie
-ISP6Pin mit Sprog2 verbunden (polung gechecked)
-Jumper richtig (Vtarget, Aref, Reset, Xtal1, Oscel gesetzt)
-Oscillator gibt Takt und Testprogramm läuft einwandfrei und friert ein
bei Oscel-jumper nicht gesetzt
-Habe die Maximalfrequenz von 3.6864 MHz eingestellt
-Habe sichergestellt, dass ISP-Frequenz deutlich drunter ist (460kHz)
-Habe sichergestellt, dass die Spannung über 5V ist (5.1V)
Meine Takteinstellung (FuseBits über AVR Studio):
Ext RC Osc 0,9-3.0MHz StartupTime: 18CK + 64ms
(wenn ichs auf Default zurückstelle funktioniert es auch nicht mehr)
(Dazu eine Zwischenfrage: was bedeutet 18CK + 64ms StartupTime? Warum
kann man da verschiedene Einstellungen wählen?)
HV-Prog funktioniert wie gesagt, ISP nur nicht. Andere Fusebits habe ich
nicht angetastet als SUT_CKSEL. Ein anderer Mega8 (hab mir gleich
mehrere besorgt, für eben solche Fälle) funktioniert normal.
Im Grunde ist es nicht schlimm, dass nur noch HV-Prog funktioniert, da
ich den eh nur für Testzwecke verwende, aber kann man eventuell über die
Taktfrequenz einstellen, ob ISP noch zu Proggen ist? Ich hab mal
gelesen, dass man ISP deaktiviren kann und nur noch HV-Programmierung
möglich ist. An welchen Fuses kann man das sehen?
(Ich habe schon eine menge Beiträge durchgelesen, aber keiner mit diesem
Fehler. Ich bin bemhüht keine FAQ zu stellen. Sollte diese eine FAQ
sein, dann bitte ich um entschuldigung)
Besten gruß, Fiete
Auch wenns FAQ ist, nochmals:
ISP-HV-Prog:
Diese Betriebsart arbeitet mit einem vom Programmiergerät kommenden
Takt, benötigt daher keinen eigenen Takt des Kontrollers, daher geht es.
external Osc.
wohl einer der häufigsten Fehler, mit dem man sich aus dem Kontroller
aussperrt.
Der Kontroller erwartet hier einen von extern angelegten Takt, sein
eigener Oszillator ist stillgelegt, daher geht ISP natürlich nicht, wenn
nur ein Quarz außen angeschlossen ist.
Das STK500 bietet die Möglichkeit, einen externen Takt anzulegen, dann
geht ISP wieder.
external Crystal:
Diese Betriebsart ist meistens gewünscht. Da arbeitet ein extern
angeschlossener Quarz bzw. Keramikschwinger mit dem Oszillator im
Kontroller zusammen.
HV-prog wird durch den Anschluss von 12V an reset eingeschaltet, geht
meines Wissens immer, ohne durch fuses abschaltbar zu sein.
ISP ist mit einer ISPEN-fuse abschaltbar, die logischerweise nicht im
ISP-Betrieb änderbar, sondern nur im HV-Betrieb.
Auch reset über den reset-Anschluss lässt sich per fuse abschalten,
damit wird ein weiterer Pin verwendbar. ISP geht dann nicht, nur
HV-prog.
Start.up.time:
Der Kontroller muss beim Einschalten von Vcc erst einmal abwarten, bis
volle Spannung erreicht ist und bis der Quarz-Oszillator voll schwingt,
(das dauert recht lange).
Dafür ist die längste start.up-Zeit optimal, denn da geht es immer.
Wenn man auf schnelle Startzeit angewiesen ist (und nur dann ) kann man
die Startzeit verkürzen. Da kann es aber dazu kommen, dass der
Kontroller beim Start Unsinn anstellt.
Danke Peter für die Schnelle Antwort.
Ich bin mir nicht sicher, ob du dir genau durchgelesen hast, was ich
geschrieben habe, und nur wieder gedacht hast: "oh mann, wieder einer
von diesen Fusebits Idioten, die Forenbeiträge nicht lesen können". Kann
ich verstehen, die Frage kommt auch oft, aber ich glaube mein Problem
ist anders:
Der Controller emfpängt ein Taktsignal vom STK500. Das kann ich
Feststellen, indem das Testprogramm läuft und einfriert, sobald ich den
Oscel-Jumper entferne - es fehlt ja dann in der Tat die Taktfrequenz.
Wenn ich den Jumper wieder setze läuft das Programm weiter. Also der
Controller ist nicht eingefroren. Zumindest nicht im "normal" Betrieb.
Ist möglich, dass das bei der ISP-Programmierung anders aussieht. Aber
das wäre mir neu.
Selbst wenn ich die Taktfrequenz auf Default (also Intern) setze (habe
ich auch oben geschrieben) funktioniert ISP nicht mehr.
Dann gucke ich mal nach, wie das mit der SPIEN-Fuse ist...
Oder ist der Controller eventuell einfach defekt?
Funktioniert. Der Tipp mit dem ISP-Deaktiviren funktionierte. Aus
irgendwelchen Gründen hat sich die SPIEN-Fuse verstellt und somit ISP
deaktiviert.
Danke für deine Hilfe Peter. Sei Nachsichtig mit solchen
Anfänger-Problemen. Ich beschäftige mich erst ein paar Tage damit und
der Umfang ist wirklich enorm. Allein wegen dieser Fusebit bin ich schon
2,5h beschäftigt. Aber macht bock!
Besten Gruß, fiete
Ob SPI blockiert ist oder nicht, kann man doch am ehesten feststellen,
indem man die sogenannte Signatur liest. Die wird ja vom Kontroller über
die SPI-Schnittstelle an den PC gemeldet.
In Deinem Post sind mehrere Fragen enthalten, auch wusste ich nicht ganz
genau wo das eigentliche Problem liegt. Deshalb kam eben recht viel
Zusatzinformation, die garnicht nötig war. Hoffentlich ist auch die
richtige dabei.
Dass bei internem Oszillator ISP nicht läuft, lässt darauf schließen,
dass SPIEN falsch steht.
Geht das Testprogramm mit internem Oszillator ?
ISP benötigt den Reset-Pin, wenn man den als I/O-Pin konfiguriert, geht
es nicht mehr. Hast Du vielleicht doch in den Fuses RSTDISBL
eingeschaltet?
Mirko
Danke nochmals für die Hilfe. Funktioniert nun.
Es lag an der SPIEN-Fuse. Ich bin mir echt sicher, dass ich da nix
verstellt habe. Peter, du hast geschriben, dass man das auch mit 12V am
Reset-Pin hinbekommt. Wird dabei wirklich die SPIEN-Fuse gesetzt oder
nur der Controller bis zum nächsten Reset in diesen Modus versetzt?
Ich habe zwar nie 12 V intern benutzt, aber ist es möglich, dass aus
irgendwelchen Gründen Spannungsspitzen diese Fuse verstellt haben? Der
µC war die ganze Zeit im STK500.
Gruß, fiete
Üblicherweise ist zur Änderung von Fuses eine Befehls-und Datenfolge von
mehreren Bytes notwendig. Zufällige Änderungen der Fuses ist deshalb
erst einmal unwahrscheinlich, da es erst nach mehreren Byte Befehl zum
Brennen des/r Fusebyte/s kommt.
Es kann aber folgendes passieren:
Die Programmiersoftware schützt zwar das SPIEN-Bit, indem es an dieser
Stelle des Byte nur eine 1 zulässt. Ein Übertragungsfehler
(Wackelkontakt) während der Übertragung des fuse-Byte geht aber an der
Software vorbei und kann SPIEN trotzdem verbiegen, da dieses ja nur ein
Teil des übertragenen fuse-Byte ist.
Beim Ändern von z.B. der Oszillator-fuses könnte dann auch das SPIEN
ungewollt mit verstellt werden.
Das HV-Programmieren ist sozusagen die übergeordnete
Programmierfunktion.
Damit kann man praktisch alle fuses verbiegen, auch SPIEN und RSTEN.
ISP-Programmierung ist auf Takt im/am Kontroller angewiesen und auch aus
anderen Gründen ist daher ein "Aussperren" möglich.
