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