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
> 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.
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).
> 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?
