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.
Gast
#830497
Ist der Vref Pin an der ISP Schnittstelle belegt? Ohne die zeigt mein Dragon das gleiche Verhalten.
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
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.
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.
Niemand eine Idee?
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?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.