STK500 - halbdefekt

Hallo,

seit einiger Zeit besitze ich das STK500 und habe damit problemlos gearbeitet. Doch seit kurzem kann ich damit keine Controller mehr programmieren - weder über ISP noch mittels HV-Programmierung.

Folgende Analyse habe ich zusammengestellt - vielleicht kann mir ja jemand sagen, wo ich den Hardwarefehler am Board (bin mir so ziemlich sicher) suchen soll.

0. Upgrade des STK funktioniert ohne Probleme (inkl. verifying).

1. Verbindung mit STK500 klappt reibungslos, auch die diversen
Boardparameter lassen sich problemlos einstellen und wieder zurücklesen und liegen im grünen Bereich.

2. Bei Programmierung über ISP erscheinen immer folgende Meldungen:
a) Setting mode and device parameter OK
b) Entering program mode failed
c) Leaving program mode OK
Es ist weder Lesen noch Schreiben mögich.

Wenn ich probeweise keinen Prozessor stecke, dann kommen auch immer die Meldungen b) und c) - mit Ausnahme von a).

3. HV-Programmierung (Verbindungen garantiert richtig hergestellt):
a) Signature does not match device
b) Löschen der CPU scheinbar möglich
c) Schreiben und Lesen von Lock- und Fusebits scheinbar möglich.

In Wirklichkeit wird aber nichts in den Controller geschrieben.
Sonderbar ist auch, dass bei mehrfachem Click auf Lesen von Fuse- oder Lockbits sich die Werte willkürlich ändern.

Ein extern programmierter Controller arbeitet im Board (d. h. die LEDs werden z. B. angesteuert, das Programm läuft).

Ich habe diese Versuche an allen Sockeln mit unterschiedlichsten CPUs durchgeführt, das Board hat definitiv ein Hardwareproblem. Vielleicht habt ihr ja Tipps, wie ich den Fehler einkreisen kann.

Vielen Dank im voraus

MC im richtigen Sockel?
ISP Geschwindigkeit kleiner als 1/4 der Taktfrequenz?
MC hat keinen Takt.

Ja, habe ich alles überprüft - sogar die ISP-Geschwindigkeit auf Minimum reduziert. Es zeigen auch sämtliche Sockel das angeführte Problem.

Hat jemand einen Rat?

Da der PC mit dem stk500 vernünftig labern kann, kommt eigentlich nur noch die Verbindung zum Zielprozessor-Sockel in Frage.

"Sonderbar ist auch, dass bei mehrfachem Click auf Lesen von Fuse- oder Lockbits sich die Werte willkürlich ändern".

Hast du auf den Port Pins noch Kabel stecken (Kapazitäten), dann schmeiss die mal runter. Ist das 6-polige ISP-Kabel OK? Lose Kontakte? Tausch es doch mal aus. Ein 10-poliges, mittig eingesteckt, tut es testweise auch.
Sonst kommen IMHO nur noch die Doppeltransistoren Q900 & Co., bzw. Q203 für den Reset, in Frage, aber dann brauchst du ein Scope zum checken der Impulsformen.
Benutzt du das AVR-Studio?

Wenn du noch ein anderes Board und einen anderen Programmer hast, kannst du auch zum Fehlereingrenzen probieren vom STK aus das andere Board zu programmieren und mit dem Programmer den Kontroller im STK-Sockel.

Die Boardpins sind komplett unbeschaltet.
Heute Abend werde ich mal testweise auf einem Breadboard versuchen, ob ich einen MC mit dem STK programmieren kann.

Vielen Dank für eure Tipps.

Wie versprochen, die Erkenntnisse meiner Versuche:

1. Da ich noch einen myAVR-USB-Programmieradapter (AVR911) besitze, habe ich damit probeweise einen ATmega8 auf einem Breadboard gelöscht, gefust und programmiert.

2. Die gleichen Versuche auf dem STK500 zeigten wieder die tags zuvor benannten Ergebnisse. Da ich nun nicht den Prozessor im auf dem Board sondern auf dem Steckbrett programmieren wollte, fiel das Thema "schlechtes Kabel" schon mal weg, denn das 10-polige ISP-Kabel hat ja mit dem myAVR funktioniert.

3. Ich hatte Demoversionen (Codebeschränkung) von VMLAB und BASCOM auf meinem Rechner; nun war mein Ziel, die Situation mit diesen Softwareplattformen zu testen - normalerweise habe ich nämlich über AVR-Studio und C programmiert.

4. VMLAB: Nach Auswahl von STK500 kann ich die Boardspannung und die Taktfrequenz schreiben und lesen.
Im ISP-Mode gibt es ebenfalls wie im AVR-Studio die Fehlermeldung, dass der Programmmodus nicht aufgerufen werden kann.
Bei Umschaltung auf HV (und garantiert richtig gesteckten Kabelverbindungen auf dem STK500 und zwischenzeitlich wieder auf den grünen Sockel des STK500 zurückgesteckten ATMega8) kann ich die Lock- und Fusebits lesen und schreiben und den Prozessor löschen (zumindest erscheint jedesmal eine grüne Anzeige im Fenster), das Überprüfen der Signatur scheitert jedoch. Ein Rücklesen bzw. Verify der Bits gibt jedoch ebenfalls eine Fehlermeldung (es wurde also kein Bit im Controller verändert!).

5. BASCOM (SPI): Im Dos-Fenster wird eine korrekte Verbindung zum STK500 angezeigt, die darauffolgende Zeile meldet jedoch: "Entering programming mode failed".

Fazit:
===
Egal ob der zu programmierende Mikrocontroller im STK500 steckt oder extern über ISP angesprochen wird, über ISP ist mit keiner Software eine Verbindung zustandezubringen.
Bei gestecktem Prozessor im STK500 und korrekten Kabelverbindungen sieht es so aus, als ob das Lesen und Schreiben der Fuse- und Lockbits funktionieren würde; ein Rücklesen bzw. Verify liefert jedoch keine Änderung - außerdem ist die Signatur immer fehlerhaft.

Ich habe mir bereits über die Hilfe des AVR-Studios die kompletten Schaltpläne heruntergeladen und ein Oszilloskop besitze ich auch. Da ich den genauen Zusammenhang der einzelnen Bauteile auf dem STK500 nur vage kenne, wäre ich für jedmögliche Unterstützung sehr dankbar.

Vielleicht hat ja der eine oder andere noch eine Idee, wo und wie ich am besten mit meinen Messungen vorgehen soll.

Viele Grüße

Hallo francesco,

mach doch einfach mal ein Foto* vom nicht funktionierendem Aufbau und stell es hier ein!

Gruß, Michael

*scharf und hochauflösend

Na gut Michael, hier 2 Bilder - einmal als ISP und 1x HV.

Ich glaube zwar nicht, dass ich einen Fehler gemacht habe, aber ich lasse mich gerne belehren.
Übrigens, die Spannung des Boards ist auf den Fotos nicht ein, da ich es zum Fotografieren an einen helleren Ort gebracht habe, wo keine Steckdose in der Nähe war - die LEDs zeigen aber korrekt an und die gemessenen Spannungswerte (Target, Uref) stimmen auch.

francesco

Mess mal mit dem Scope den Reset Pin direkt am MC wärend der Programmierung und schau, ob der zwischen drin zuckelt und dadurch die Programmierung versaut.

Hallo francesco,

was hat der "Reset" Test mit dem Scope ergeben?
So wie deine Jumper stecken, kommt der Clock vom STK500, einstellbar im AVR Studio irgendwo bei HW Settings.
Oder benutzt der Atmega8 den internen Oszillator?
Die ISP-Frequenz ist <= 1/4 der Taktfrequenz?

Gruß, Michael

Hallo JohnnyP, hallo Michael,

meine Messungen mit dem Oszilloskop (kein Speicheroszi) ergaben, dass im SPI-Mode der Reset von 5V für ca. 20-50ms (während der Fehlermeldung "Entering programming mode ...FAILED") auf 0V gezogen wird und bei HV-Programmierung geht er von 5V auf 12V hoch.

Übrigens, ich habe auch probehalber mal einen (per myAVR-Programmer geprüften und gelöschten) ATTINY2313 mit 1MHz internem Takt in den roten Sockel gesteckt, da die HV-Programmierung für diesen Typ nur aus den beiden Kabeln PROG CTRL<==>PORTD und PROG DATA<==> PORTB besteht - es tritt das gleiche Verhalten wie zu Beginn des Threads beschrieben auf, d. h. scheinbare Programmier- und Löschmöglichkeit, jedoch bei Read oder Verify ERROR sind die alten Daten unverändert vorhanden. Tja und seriell geht ebenso wieder überhaupt nichts (kein Entering programming mode).
Probeweise habe ich auch schon mal einen 8 und 16 MHz Quarz versucht und den Jumper umgesteckt. (Ach ja, für die SPI-Programmierung habe ich auch schon alle Frequenz ausprobiert - bis auf 1,2 kHz runter, wobei das für die HV-Programmierung aber keine Auswirkung haben sollte - die geht ja auch nicht).

Eine weitere Erkenntnis habe ich noch im Parallelmode hinzugewonnen: Ich habe extra ein relativ großes Programm mit mehreren KBytes in den MC übertragen. Während der paar Sekunden Programmierzeit blieb der Resetpegel auf 12V, doch nach Ende der Übertragung gab es exakt diese Fehlermeldung für den ATMEGA32:
---------------------------------------------------------------------------------------------------------
Getting isp parameter.. SD=0x03 .. OKOK
Reading FLASH input file.. OK
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH .. OK!
Reading FLASH .. OK!
WARNING: FLASH byte address 0x0000 is 0x20 (should be 0x0C).. FAILED!
Leaving programming mode.. OK!

Im SPI-Mode sieht das ganze so aus, wobei sofort mit Fehler abgebrochen wird:
---------------------------------------------------------------------------------------------------------
Getting isp parameter.. SD=0x03 .. OKOK
Reading FLASH input file.. OK
Entering programming mode.. FAILED!
Leaving programming mode.. OK!

Wenn ich mal viel Zeit habe, muss ich mal hinter die Geheimnisse des Boards steigen, ich bin mir jetzt fast ganz sicher, dass es ein Hardwareproblem ist. Habt ihr noch welche Tipps ](*,)

Franz alias francesco