Hi,
bei mir läuft der Übergang nicht ganz flüssig. Bisher konnte ich meinen
atmega162V wunderbar über das xilinx cable mit dem avrdude mittels ISP
programmieren.
z.B. mit diesem command
avrdude -p m162 -c xil -e -U flash:w:default/XXXXXXX.hex
nun zum Problem:
Der Dragon wird vom System erkannt und kann auch die richtige Spannung
messen (4,9V). Außerdem hat er eine Versorgung über einen externen USB
Hub mit 2A-Netzteil.
Trotzdem erhalte ich schon beim Auslesen der device ID im Studio die
Meldung
Die Verbindung habe ich mehrmals überprüft. MISO des drachen liegt auf
MOSI des targets und umgekehrt.
gibt es irgendwelche Tools mit genaueren Ausgaben, wo das Problem liegt?
einen logic analyser habe ich nicht, aber man sieht, dass der Dragon
RESET auf low zieht.
Alle anderen Bauteile am Atmega habe ich entfernt! Der Takt kommt vom
intern Oszillator und hat damit 8MHz. Das Auslesen der ID klappt aber
bei keiner der Frequenzen, die man auswählen kann.
Leider habe ich keinen neuen µC herumliegen. Wie kann ich eine
Fehlfunktion des dragons ausschließen?
ihr habt natürlich recht; gestern nach einem langen Abend der
Fehlersuche habe ich wohl irgendwo gelesen, dass das so verschalten
werden muss; oder das Gelesene zumindest so verstanden...
die guides sind da ja ziemlich eindeutig ;)
anyways, der Fehler besteht auch bei andersrum verbundenen
Datenleitungen - so wie ich es ursprünglich hatte.
ja. Das Programm, das derzeit drauf ist, läuft mit internem oszillator
und benutzt auch die SPI-Pins, über die die ISP läuft.
Da ich mit der Programmiererei so viele Probleme habe, habe ich aber
alle Bauteile außenherum vom Brotbrett entfernt. Es sind nur noch die
Stützkondensatoren übrig!
was mich vor allem ärgert ist die Fehlermeldung: "Mach alles richtig,
dann klappt's auch." Gibt's denn kein Diagnoestool, mit dem man den
Fehler gezielter suchen könnte? z.B. ganze ISP mit pullups versehen und
dann prüft er die einzelnen Treiberbausteine am dragon; der Fehler
scheint ja häufig zu sein, dass die sterben, und spannung messen kann er
auch.
Ein logic analyzer ist leider teurer als einfach mit allen meinen
Projekten komplett auf Microchip zu wechseln! Und einfach auf gut Glück
ohne genauere Hinweise einen zweiten Drachen zu kaufen kommt für mich
auch nicht in Frage.
Ich habe heute die ISP-Leitung auf 10cm gekürzt... keine Änderung
es kann höchstens noch am USB-Kabel liegen, bei dem die Schirmung kaputt
ist. Aber so weit möchte ich nicht gehen, denn das Firmwareupgrade
funktioniert über das Kabel ja auch!! Und das Auslesen der Spannung...
A. S. schrieb:> Bisher konnte ich meinen atmega162V wunderbar über das xilinx cable mit> dem avrdude mittels ISP programmieren.
Du kannst avrdude übrigens auch für den Drachen benutzen. ;-)
Da allerdings die Aktivierung des ISP immer noch dem Drachen obliegt,
fürchte ich, dass dir auch avrdude dann kaum eine bessere
Fehlermeldung bringen wird in diesem Falle, probieren kannst du's
aber.
Die Fehlermeldung klingt schon sehr nach einem Verkabelungsproblem.
Versuche mal ein anderes USB-Kabel. Ich habe hier auch so einen Dragon,
der eine Vorliebe für ein bestimmtes Kabel zeigt. 3 andere Kabel
funktionieren mit Allem und Jedem -nur mit diesem Biest nicht.
MfG Paul
avrdude mit dragon habe ich auch schon ausprobiert. Er findet aus
irgendeinem Grund den Dragon am USB-Port nicht; genauer gesagt, er
findet den usb port an sich nicht;
möglicherweise liegt das daran, dass ich für die Spannungsversorgung
einen aktiven 2A USB Hub verwende. aber davon möchte ich nicht weggehen,
denn ohne den Hub erhalte ich von win7 die Meldung, dass der port nicht
genug Strom liefern kann. Ich sehe aber keine verkohlten bauteile auf
dem dragon ;)
soll ich wirklich auf Verdacht ein anderes Kabel kaufen, wenn das
flashen funktioniert? hast du das firmware upgrade des dragons auch mal
mit deinem "defekten" Kabel getestet?
Das liest sich als ob der Ziel-µC in einer anderen schaltung steckt,
daher meine Frage:
Hast du den Ziel-µC auch mit Spannung versorgt?
Hab den Dragon und AVRDude in verbindung mit Arduino-Boards verwendet.
Hab dabei das "Arduino" weggelassen und es einfach als Platine mit µC
betrachtet. Funktioniert super, solange das Datenkabel richtig rum drauf
steckt und beide Boards( also Dragon und Arduino) mit Spannung versorgt
sind.
Jörg Wunsch schrieb:> Klingt nach libusb-Problem.
die Frage ist, wie viel zeich ich da hineinstecken sollte. Urpsrünglich
wollte ich nur den avrdude testen, um evtl eine bessere Fehlermeldung zu
bekommen. Das Studio sagt ja nur "geht nicht".
Für mich sieht es so aus, als spielen evtl mehrere Fehler zusammen.
Fragt sich, wie ich die nacheinander finden kann.
Kaj schrieb:> Das liest sich als ob der Ziel-µC in einer anderen schaltung steckt
Genau. Wie gesagt: ich habe den µC auf einem breadboard mit externer
Beschaltung (SPI I/O). Um die ISP-Kommunikation nicht zu stören, habe
ich die beiden angeschlossenen Schieberegister aus dem Brett gezogen.
Aber wenn ich sie hineinstecke funktioniert das alte Programm auf dem µC
tadellos.
Der µC wurde früher ebenfalls über ISP programmiert - nur eben mit einer
anderen Schnittstelle.
ich habe eine Idee aus einem anderen Thread übernommen: LEDs an den
Ausgangskanälen zeigen mir an: die Treiber von Reset, SCK und MOSI
scheinen zu funktionieren.
RESET ist immer HI
Die beiden anderen Kanäle sind LO
klickt man auf "device ID auslesen", schaltet RESET auf LOW. SCK
leuchtet etwa doppelt so hell wie MOSI. Ich denke mal, dass das
gesendete pattern mehr 0en als 1en hat. Betreibt man das bei niedrigster
Frequenz, dauert der Vorgang lang genug, um das erkennen zu können
(knapp 1sek).
Packt man das ganze Gerät zurück an den Mikrocontroller, sieht man auch
dass MISO einen kurzen Signalpuls als Antwort generiert.
Soweit klingt es nach diesem Problem:
Beitrag "AVR Dragon liefert nur noch Nullen - tot?"
Also habe ich nach einer Möglichkeit gesucht, die Antwort so
auszuwerten, wie, das der Kollege damals gemacht hat. das
Kommandozeilenprogramm, das mit dem Studio mitkommt, meldet "Got 0xC0,
expected 0x00". Ich bekomme also nicht die Nullen, aber doch etwas
anderes als erwartet.
soll ich diese ICs auch mal auf Verdacht wechseln? Wofür sind die
Analogschalter zuständig? Warum geht es nicht ohne?
Ist keine bessere Fehlerdiagnose möglich?
niemand mehr eine Idee?
oder ist das ein klassischer Fall von: ich sollte einen neuen thread
aufmachen, da die wichtigsten Infos nicht mehr ganz oben im ersten post
stehen? :D
Thread beobachten
Seitenaufteilung abschalten