Dragon Troubleshooting

[Michael E. (rince)]

Hallo

Mein Dragon funktioniert seit einiger Zeit nicht mehr. Ich bekomme den 
berüchtigten "ISP frequency" Fehler.

Um die gängisten Fehler auszuschliessen habe ich eine Schaltung mit 
einem ATtiny13 aufgebaut die mit dem Dragon und mit dem USBProg 
abwechslungsweise per ISP programmiert werden kann.

Mit USBProg funktioniert z.B. das auslesen der Signatur einwandfrei, der 
Dragon bringt mir bei exakt gleicher Schaltung und Verkabelung den ISP 
Fehler und meldet ab dem zweiten Versuch nur noch 0x00 0x00... als 
Signatur.

Nun habe ich auch mal den sump.org Logicanalyzer zur Hilfe genommen. 
Dies sind meine ersten Experimente mit einem LA, ich weiss daher nicht 
ob ich alles richtig eingestellt habe.

Hier sind zwei Bilder die das erfolgreiche Auslesen der Signatur mit dem 
USBProg bzw. die erfolglosen Versuche des Dragon zeigen:

http://pozor.ch/usbprog1.png
http://pozor.ch/dragon1.png

Kann man daraus vielleicht ablesen was schief läuft?

Danke für eure Hilfe,

Michael E.

[Werner B. (Gast)]

Ist der Vref Pin an der ISP Schnittstelle belegt?
Ohne die zeigt mein Dragon das gleiche Verhalten.

[Michael E. (rince)]

VTG ist belegt, ja. Die Spannung wird korrekt eingelesen. Ich kann auch 
mit dem Dragon kommunizieren um z.B. die ISP-Frequenz zu ändern oder die 
Firmware upzudaten.

Grüsse,

Michael

[Jörg W. (dl8dtl) (Moderator)]

Kannst du die LA-Bilder mal so aufzeichnen, dass du mit der HL-Flanke
an /RESET triggerst und dann die ersten SCK-Impulse danach zeigst?
Bitte auch eine Zeitskala mit angeben.

[Michael E. (rince)]

Ok, hab ich jetzt mal gemacht:

http://pozor.ch/dragon2.png

Die Samplinrate liegt bei 500 kHz, die ISP-Frequenz bei 125 kHz.

Ich musste einen delay von 25 ms einstellen um die ersten SCK-Impulse zu 
kriegen. Zu den Zeiten in der Skala muss man also noch 25 ms dazurechnen 
nach der HL-Flanke von RST.

Hoffe das hilft für das Troubleshooting.

Vielen Dank,

Michael E.

[Michael E. (rince)]

Niemand eine Idee?

[Jörg W. (dl8dtl) (Moderator)]

Hmm, bis hierhin ist noch nichts falsch...  Die 25 ms Wartezeit sind
OK (20 ms sind vorgeschrieben), und es wird 0xAC 0x53 ausgegeben.
Erst bei der Ausgabe des dritten Bytes (0x00) sollte dann die 0x53
als Echo bei MISO erscheinen.  Die steigende Taktflanke für Bit 0
der 0x53 ist ganz rechts im Bild zu sehen, die fallende Flanke ist
nicht mehr drauf, d. h. die Sequenz für die ersten beiden Bytes ist
gerade noch nicht ganz vollständig auf dem Bild.  Du müsstest also
weitere 16 Takte zur rechten Seite noch mit ansehen.

Ist das Ganze eigentlich an den Pins des Zielprozessors abgegriffen
oder irgendwo davor?