Ich habe Probleme mit meinem AVR Dragon: Das Target scheint nicht erreichbar. 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. Wenn die Versorgungsspannung des Dragon fehlt, merkt er es und avrdude meldet einen anderen Fehler (RSP_NO_TARGET_POWER). Woran liegts?
Angehängte Dateien:
-
screenshot.png
15 KB
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.
Jörg W. schrieb: >> 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. Ich meine ich hatte es schon mit -B10 probiert. Sicherheitshalber nochmal mit -B10, das Log ist im Anhang. > 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. An welcher Stelle soll ich zoomen? Ich hab die Pulseview-Session mal angehängt, solltest du Pulseview haben kannst du selber zoomen. Ist es eigentlich normal, dass der avrdude aufruf (avrdude -c dragon_isp -P usb -p t45 -vvvv -B 10) nur einmal funktioniert? Beim nächsten mal leuchtet die rote LED am Dragon nicht mehr und es kommt zu Timeouts...
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.
Angehängte Dateien:
-
screenshot.png
50 KB
Jörg W. schrieb: > Hab' ich nicht. Mich würde ein einzelnes SIGNON-Kommando interessieren, > das sind 4 Bytes (AC 53 00 00), also 32 SCK-Takte. Okay, ist im Anhang.
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.
Angehängte Dateien:
-
screenshot.png
74 KB
Jörg W. schrieb: > Eine Zeitachse wäre natürlich schön … Sorry, eine neue Version ist im Anhang
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
Angehängte Dateien:
-
screenshot1.png
20 KB
Ich hab mal einem USBasp bei der Arbeit zugeschaut, siehe Anhang. Der lässt den Reset ebenfalls nicht los. Unterschied ist allerdings, dass MISO vorher HI ist.
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.
Puh, das ist ja frustrierend. Ich hab heute nochmal einen Attiny2313 ausprobiert, selbes Spiel. Als erstes hatte ich einen Arduino Nano Clone an den Dragon gehängt, kann ich dabei was zerstört haben? Sollte es wirklich an avrdude liegen, was ich ja irgendwie bezweifle, mit welchem slternativen ISP-Programmiertool könnte ich es denn probieren?
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.
Selber Fehler:
1 | $ avrdude -c dragon_isp -P usb -p t85 -tuF |
2 | avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED |
3 | avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire |
4 | avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_DEBUGWIRE_SYNC_FAILED |
5 | avrdude: failed to sync with the AVR Dragon in ISP mode |
6 | |
7 | avrdude done. Thank you. |
Findet avrdude kein USB device sagt es nur "avrdude done. Thank you.", und ich dachte schon es funktioniere...
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.
Meine USB3 Ports haben gestern noch rumgesponnen, ich hoffe es liegt nicht am Host-Rechner, auch wenn ich es mir eigentlich nicht vorstellen kann. Ich werde heute Abend mal sehen, ob ich einen Windowscomputer finde und es dort mit dem Atmel Studio ausprobieren.
Mal 'ne ganz blöde Frage: Hast Du vielleicht bei Benutzung des Dragon Dein Zielssystem nicht extern mit Spannung versorgt? Aber beim USBASP den VTarget-Jumper gesetzt? Dann wäre dein µC vom USBASP versorgt, aber im Falle des Dragon nicht, was den Lowpegel auf der MISO-Leitung erklären würde...
Thosch schrieb: > Hast Du vielleicht bei Benutzung des Dragon Dein Zielssystem nicht > extern mit Spannung versorgt? Das würde der Dragon erkennen.
Ich habs jetzt unter Windows mit dem Atmel Studio probiert und es funktioniert auch nicht. Die Fehlermeldungen sind wenig Aufschluss... Sind dem Verhalten nach die bekannten Hardwareprobleme mit dem Dragon unwahrscheinlich? Kurzschluss MISO nach GND oder so?
Angehängte Dateien:
-
screenshot1.png
75 KB
Ha, ich bin einen Schritt weiter. Ich hab mal das naheliegende (wieso komme ich da erst jetzt drauf?) gemacht: MISO vom Dragon nicht mit dem Target verbinden und den Logic-Analyzer mit dem Target verbinden. Und siehe da, das Target antwortet. Also doch ein Dragon-Hardware-Problem?
Am Dragon messe ich ohne Spannungsversorgung von MISO nach GND 16 Ohm, mit Spannungsversorgung des Dragon kein Durchgang.
Ha, das wars! Einen NLAS2066 getauscht und schon tuts. Es war der, der näher an der USB-Buchse ist...
1 | % avrdude -c dragon_isp -P usb -p t2313 -B 10 -t |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.15s |
6 | |
7 | avrdude: Device signature = 0x1e910a (probably t2313) |
8 | avrdude> |
9 | avrdude: safemode: Fuses OK (E:FF, H:DF, L:64) |
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.