AVR Dragon Probleme: RSP_FAILED

bernd schrieb:
> Im Anhang sind die Debug-Ausgabe von avrdude und die Ausgabe von
> Pulseview/Logicanalyzer.
>
> Wenn ich am ISP-Header des Targets einen USBasp anschließe, kann dieser
> das den Controller ansprechen/programmieren. Daraus schließe ich, dass
> die Verkabel und das Kabel in Ordnung sind.

Kann es sein, dass der ISP-Takt deines Dragon zu hoch eingestellt
ist?  Probier' den AVRDUDE-Aufruf mal mit -B10.

Im gezeigten Trace antwortet der Controller jedenfalls rein gar nichts,
obwohl die vom Dragon kommenden Signale vorhanden sind.  Um genau zu
sehen, was auf diesen Leitungen passiert, müsstest du allerdings mal
reinzoomen.

bernd schrieb:

> Ich meine ich hatte es schon mit -B10 probiert. Sicherheitshalber
> nochmal mit -B10, das Log ist im Anhang.

OK, schau' ich mir an.  Irgendwie fehlt mir da was drin, ich muss
das mal genauer analysieren.

> An welcher Stelle soll ich zoomen? Ich hab die Pulseview-Session mal
> angehängt, solltest du Pulseview haben kannst du selber zoomen.

Hab' ich nicht.  Mich würde ein einzelnes SIGNON-Kommando interessieren,
das sind 4 Bytes (AC 53 00 00), also 32 SCK-Takte.

> Ist es eigentlich normal, dass der avrdude aufruf (avrdude -c dragon_isp
> -P usb -p t45 -vvvv -B 10) nur einmal funktioniert?

Nein, natürlich nicht.

Eine Zeitachse wäre natürlich schön …

Ich habe das Gefühl, dass die Timing-Parameter da irgendwie verschütt'
gegangen sind, sodass der ISP-Takt viel zu hoch ist für den Controller.
Dann wiederum ist es auch kein Wunder, dass er nicht antwortet.

Das sind 5 ms pro Byte, sehe ich das richtig?  Das wären ja 1,6 kHz,
das sollte auf jeden Fall langsam genug sein, sogar für einen
32-kHz-Oszillator mit CKDIV8-Fuse …

Dafür ist es seltsam, dass da nichts reagiert.

Einen Fehler im Dragon selbst würde ich allerdings erstmal nicht sehen,
denn offensichtlich sind dessen Signale ja OK (wenn auch langsam), und
es ist das Target, welches gar nicht zuckt.  Das Einzige, was mich
wundert ist, dass zwischen den einzelnen SIGNON-Versuchen die
Reset-Leitung nicht kurz zurückgenommen wird.  Das würde das Protokoll
eigentlich vorsehen.

Mach mal bitte einen Bugreport auf und wirf all deine Logdaten etc.
da hinein.

https://savannah.nongnu.org/bugs/?group=avrdude

bernd schrieb:
> Der lässt den Reset ebenfalls nicht los.

Muss er ja auch nicht, denn er gewinnt ja bereits bei ersten Versuch
die ISP-Session. ;-)  Das mit dem kurzzeitigen Loslassen des Reset
ist nur als Resynchronisationsmaßnahme vorgeschrieben, wenn ein
Verbindungsaufnahmeversuch scheitert.  Da das /RESET ja als slave
select für den SPI-Slave fungiert, kann man nur damit das Rücksetzen
des internen Zustandsautomaten (und damit definierte Bedingungen)
garantieren.

Es fällt natürlich auf, dass der USBasp sehr viel schneller arbeitet,
das dürften 10 µs SCK-Periodendauer (also 100 kHz Takt) sein.

Ich wüsste zwar nicht, warum ein vollstatisches Design nicht auch
(sehr) viel langsamer arbeiten können sollte, aber es ist zumindest
ein Bug, dass der Dragon nicht mitgeteilt bekommt, mit welcher
ISP-Geschwindigkeit er arbeiten soll.  Ich hatte mal kurz per
trial&error paar alte Stände ausprobiert, das scheint noch nie
geklappt zu haben.

bernd schrieb:
> kann ich dabei was zerstört haben?

Nö.

> Sollte es wirklich an avrdude liegen, was ich ja irgendwie bezweifle,
> mit welchem slternativen ISP-Programmiertool könnte ich es denn
> probieren?

Untested würgaround:

avrdude mit -tuF aufrufen, dann im interaktiven Modus den ISP-Takt
neu setzen (bspw. auf 10 µs).  Den merkt sich der Dragon, danach
nochmal die Kommandozeile probieren.

Mist, dadurch, dass er erst noch debugWIRE probiert, macht er nicht
mit dem nicht initialierbaren ISP weiter. :(  (Das sollte er mit -F
eigentlich tun.)

Ich schau mal, was sich da machen lässt.

Thosch schrieb:
> Hast Du vielleicht bei Benutzung des Dragon Dein Zielssystem nicht
> extern mit Spannung versorgt?

Das würde der Dragon erkennen.

bernd schrieb:
> Einen NLAS2066 getauscht und schon tuts.

Herzlichen Glückwunsch!

Den Bugreport würde ich trotzdem mal offen lassen, denn ich denke
immer noch, dass das mit dem SCK-Timing nicht so ist, wie es sein
sollte.