Hallo allerseits! Erstmal kurz ein Wort zum Forum hier: Ich finds toll, wie viele sich hier beteiligen, dieses Forum hat mir schon das ein oder andere Mal weitergeholfen! So, jetz aber genug geschleime ;) So alltäglich das Thema auch klingen mag, ich hab bisher keine Lösung dazu gefunden, deshalb muss ich zum ersten Mal eure Hilfe beanspruchen. Das ganze sieht so aus: Ich hab einem ATmega16 auf nem Steckbrett (im Mom einziger IC) per AVR Studio und USB AVR Lab, das ein STK500 emuliert, ein Test-Programm zum Ansteuern und umschalten eines 7-Segment-Treibers (per BCD) draufgespielt. Dabei hab ich auch Fuses umprogrammiert (verdächtig!), weil der uC ein 4MHz-Quarz verwenden soll. Die Fuse-Bytes wurden beide auf 0xFF geschrieben, was eigentlich die richtige Einstellung sein sollte. Außerdem hat meine 7-Seg-Anzeige auch ein bisschen Stuss angezeigt, am uC müsste also ein Takt anliegen... Na ja, jedenfalls hab ich aufgrund der verwirrenden Anzeige einen Programmfehler ausgebessert, und BÄM! - ich kann meinen uC nicht mehr erreichen! (Entering Program Mode... FAILED!) Hab schon mal ein bisschen rumprobiert, z.B. die ISP-Frequenz variiert (immerhin funktioniert das noch), oder erfolglos versucht, die Signature-Bytes auszulesen. ISP-Freq kann ich ja verwirrenderweise auslesen... Wie siehts mit HW Settings aus? Muss ich da iwas bestimmtes einstellen (hier hab ich bisher auch nur erfolglos rumgeschraubt)? Noch kurz zur Schaltung: Ein Abblockkondensator ist vorhanden, auch der Quarz ist mit 2x 22pF gegen Masse abgeblockt. Also, danke ersmal fürs durchlesen dieser Wall of Text! Mein Problem ist, dass ich keinen Schimmer hab, woran das liegen könnte... anfangs dachte ich, es wären die Fuses, aber des wär ja auch iwie unlogisch... LG Hannes
Angehängte Dateien:
-
FUSE.JPG
36 KB
Wenn du das rot markierte Bit auf '1' gesetzt hast, hast du dich ausgesperrt. Da hilft dann nur noch HV-Programming - z.B. mit dem STK500.
> Wenn du das rot markierte Bit auf '1' gesetzt hast, hast du dich > ausgesperrt. Meines Wissens nach, kann man dieses Bit im SPI-Modus garnicht verändern. mfG ingo
Hans Schmitt schrieb: > Kann man, und wie Frühschichtler schrieb ist man dann draußen. Mag sein, aber dann ist das Datenblatt falsch. Da steht bei mir unter "26.2 Fuse Bits" (S. 265):
1 | SPIEN(1) | 5 | Enable SPI Serial Program and | 0 (programmed, SPI prog. enabled) |
2 | | | Data Downloading | |
3 | ... |
4 | Notes: 1. The SPIEN Fuse is not accessible in SPI Serial Programming mode. |
Irgendwie möchte ich es jetzt aber nicht ausprobieren :-)
Hannes schrieb: > Außerdem hat meine 7-Seg-Anzeige auch > ein bisschen Stuss angezeigt, am uC müsste also ein Takt anliegen... Kannst du das noch anders Überprüfen? Oder mal ein Bild von der Beschaltung geben. > ISP-Freq kann ich ja verwirrenderweise > auslesen... Ist diese Frequenz nicht nur im Programmiergerät verhanden und nicht im µC selber? Grüße, Benni
> ISP-Freq kann ich ja verwirrenderweise > auslesen... Die steht nur im Programmiergerät. Wenn wirklich die Fuses auf 0xFF sthen ist SPIEN definitiv abgeschaltet. Ob sich die SPIEN-Fuse im Serial-Mode tatsächlich umprogrammieren läßt oder nicht möchte ich momentan nicht ausprobieren. Ist womöglich die Reset-Leitung disabled worden? Auch per Fuse im seriellen Modus möglich, dann hast du dich ebenfalls ausgesperrt. Ich vermute etwas in diser Richtung, weil die Signatur-Bits nicht ausgelesen werden können. Wenn das Teil, das den STK500 "emuliert", auch dessen HW-Fähigkeit der HV-Programmierung kann, läßt sich der ATMEGA16 wiederbeleben.
Die üblichen STK500-clones, so auch das USB-lab mit STK500-Firmware, verzichten auf das HV-Programmieren, die 12V Spannungsversorgung dazu ist zu viel Aufwand. Allerdings braucht das Lesen von FF aus den fuse-bits nicht unbedingt zu heißen, dass die tatsächlich so gesetzt sind. Das kann auch die Folge irgendeines hardware-Fehlers sein. Ich würde auf jeden Fall mit externem Takt versuchen, die Signatur zu lesen. Die ISP-Frequenz ist Sache des "STK500". Es betrifft den zu programmierenden Kontroller nur insoweit, dass der Takt des Kontrollers 4mal so schnell sein muss wie der des ISP.
Ich weiß, wovon ich weiter oben schrieb, habe mir deshalb den Fusebit Doctor nachgebaut (und auch schon benutzen müssen :-): http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/
Whoa, das ging ja mal flott :) Danke soweit! Hmmm, dass mit den Fuses für SPI, RESET, usw. hab ich mir auch schon gedacht. Komisch ist nur, dass SPIEN im AVR Studio gar nicht verändert werden kann, um das verfusen durch Tollpatsche wie mich nicht ganz so leicht zu machen (das Häkchen ist übrigens nie gesetzt?!) ;) Trotzdem steht dann unten bei den Werten der Fuse-Bytes 2 mal 0xFF... Im übrigen bin ich mir SICHER, dass ich die Finger von Bits, die das Programmierverhalten oder die Funktionsweise von wichtigen Pins verändern, gelassen habe, weil ich schon wusste, was man damit anrichten kann... Peter R. schrieb: > Ich würde auf jeden Fall mit externem Takt versuchen, die Signatur zu > lesen. Wie genau muss ich mir das vorstellen? Wenn die Fuses wirklich so gesetzt sein sollten, wie es angezeigt wird, müsste der AVR ja auf den 4MHz Quarz ansprechen. Was die Fuses angeht, denke ich, dass es an der Software (AVR Studio) liegt, denn ich kann sie ja gar nicht auslesen. Wahrscheinlich zeigt der nur irgendwas an und nicht das, was ich letztes Mal reingebrannt hab. Zum Schaltplan: Da ich gerade kein gscheites Programm hab (nur FreePCB, nicht mal ein ATmega verfügbar, werd mir mal EAGLE besorgen), beschreib ichs mal kurz: Programmier-Pins alle am Prog angeschlossen (ohne Pull-ups oder -downs), zum Betrieb verbinde ich Reset mit +5V. Vcc & AVcc an +5V, alle GND-Pins an Masse, 100nF von Vcc nach Masse. Vier Ausgangs-Pins zur Ausgabe des BCD Codes und ein Ausgang zum Latchen des 7-Segment-Treibers (der ist vorübergehend von der Stromversorgung getrennt). Und ein Taster, der einen Eingangs-Pin auf Masse ziehen kann (pull-up im AVR).
Hast du ein Eval-Board? Dann setz ihn doch mal da rein. Sonst kann ja auch der AVR über die Wupper/Jordan/Mississippi sein.
> zum Betrieb verbinde ich Reset mit +5V ???
Beim Programmieren wird dieser Pin aber vom Programmiergerät
beeinflusst. Er muss über einen Pullup-Widerstand (10k) an 5V, sonst
funzt das Auslesen/Proggen nicht.
Das Problem hatte ich auch mal, bei mir wars die Reset Leitung, nicht richtung angeschlossen, da zeigte mir die AVR Software auch nur 0xFF bei den fuses an.
Achso, ich dachte den Pullup braucht man nur wenn man den AVR in der Betriebsschaltung proggen will. Jedenfalls hab ich den Resetpin über 10k / 4k7 an +3,3V (das Programmiergerät verwendet nur 3,3, im Betrieb sinds dann 5V) angeschlossen. Hat leider in keinem der beiden Fälle funktioniert... Klaus Wachtler schrieb: > Sonst kann ja auch der AVR über die Wupper/Jordan/Mississippi > sein. Ähm, ich checks net ganz... meinst du, er is im Eimer? ^^
Entweder der AVR, oder deine restliche Schaltung. Deshalb probiere ihn doch mal in einem Eval-Board. Wenn er da auch nicht geht, gibt es für wenige EUR einen neuen notfalls (bis du jemanden findest, der HV-Programmierung kann).
Hm, vielleicht kann ich mir mit nem anderen AVR nen "resetter" bauen, der per HV die Fuses auf Werkseinstellungen zurücksetzt und einen Memory Reset durchführt. Die HV muss doch nur an den Reset-Pin oder? Ich bräuchte also nur nen passenden Transistor (oder?), aber mit denen kenne ich mich überhaupt nicht aus... was wär denn da denkbar?
> Hm, vielleicht kann ich mir mit nem anderen AVR nen "resetter" bauen Liest du auch die Antworten, die man dir hier gibt? > Ich weiß, wovon ich weiter oben schrieb, habe mir deshalb den Fusebit > Doctor nachgebaut (und auch schon benutzen müssen :-): > http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/
Danke nochmal für die ganzen Tips! ;) Hab mir den Doktor vorhin schon mal kurz angesehen, aber für zu kompliziert erachtet. Jetz hab ich kapiert, dass man nur den einen Controller braucht und der Rest nur verschiedene Sockel sind (umpf^^) Genauer hinschauen lohnt sich halt doch meistens ;) Deaktiviert ein nicht gesetztes SPIEN auch den HVSP Mode oder nur ISP? Sonst könnte ich das Teil auch auf HVSP beschränken und vlt mit nem 8-beinigen µC betreiben. Oder gibt es abgesehen von den paar gesparten Sekundenbruchteilen noch irgendwelche Vorteile des HVPP? LG
Ich könnte das Prog auch probeweise mal auf nen Mega8 laden, nur hab ich Angst, diesen zu verfusen (wie evtl. den 16er). Die Einstellungen CKSEL 3..0 auf 1111 (also unprogrammiert) CKOPT auf 1 SUT 1..0 auf 11 sollten doch eigentlich für nen 4MHz-Quarz stimmen, oder? Oder hab ich da irgendwas falsch verstanden?
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.