Hallo Leute! Erstmal vielen Dank, dass es so ein schönes Forum zum Thema qC gibt! Ich habe eine kleine Frage und zwar benutz ich WinAVR und uploade mit AvrDude. Ich habe einen Atmel ICE JTAGMK1 Programmer von www.elektronikladen.de funktioniert auch einwandfrei. Aber sobald ich einmal mit AvrDude programmiert habe bleibt der Programmer wohl im JTAG Modus denn das LED am Programmer blinkt dauernd. Das ist in sofern kein Problem, AVRDude stört sich bei späterem Programmieren überhauptnicht daran. Wohl aber AVRStudio :-/ da es dann den Programmer nicht findet. Hat einer das Phänomen schonmal gehabt?
Hmm, der mkI hat keine Möglichkeit, sich von ihm ordentlich ,,abzumelden'' (der mkII hat das). Auch wenn du AVR Studio beendest, blinkert die LED doch fröhlich weiter, oder?
Ne das AVRStudio scheint den vernünftig herunterzufahren. Blinkern tut der natürlich noch wegen Debuggen, werde mal morgen probieren mit AVRStudio nur zu uploaden...
Wenn du irgendwas findest, was ich anders machen kann, tu ich's gern. Ich finde nur nichts in der Appnote dazu. Ich habe auch bislang von keinem über derartige Probleme berichten gehört, allerdings habe ich selbst seit einiger Zeit kein mkI mehr in der Hand gehabt.
Also ich habe gerade nochmal getestet. Wenn man nur mit dem AVRStudio flasht ohne ein Projekt zu öffnen wird auch dann das JTAG ordnungsgemäß zurückgesetzt ("Leaving programming mode") und keine LED blinkt danach. Ich weiß nicht wirklich wieso das bei AVRDude nicht so funktioniert. Es ist per Programmers Notepad2 und Make angebunden. Mein JTAGMK1 ist wie gesagt das von Olimex und zwar die USB Variante die einen COM Anschluss emuliert(FTDI halt...). Ich kann mir aber nicht vorstellen das das nur bei mir so ist. "Wenn du irgendwas findest, was ich anders machen kann, tu ich's gern." Hast du etwa AVRDude mitentwickelt? Ich würde dir gerne helfen, den Fehler einzugrenzen aber ich habe nun wirklich keine AVR/JTAG low level Kenntnisse ;-)
> Also ich habe gerade nochmal getestet. Wenn man nur mit dem > AVRStudio flasht ohne ein Projekt zu öffnen wird auch dann das JTAG > ordnungsgemäß zurückgesetzt ("Leaving programming mode") und keine > LED blinkt danach. Leave programming mode macht AVRDUDE (natürlich) auch. Das ist mehr oder weniger Standard. > "Wenn du irgendwas findest, was ich anders machen kann, tu ich's > gern." Hast du etwa AVRDude mitentwickelt? Ich würde dir gerne > helfen, den Fehler einzugrenzen aber ich habe nun wirklich keine > AVR/JTAG low level Kenntnisse ;-) Die musst du nicht haben -- die habe ich auch nicht. Alles was du brauchst ist Atmels Appnote AVR060 sowie eine Möglichkeit, die RS-232-Kommunikation in deinem Windows mitzuschneiden. Falls es für letzteres kein Spezialtool gibt (weiß ich nicht, ich hab' kein Windows), sollte es ggf. ein generisches Tool tun, mit dem man die Systemaufrufe mitschneiden kann. Auf der AVRDUDE-Seite kannst du die Kommunikation auf einigermaßen höherer Ebene durch Angabe von -vvvv verfolgen. Auf AVR-Studio-Seite gibt es leider ein derartiges Tool zumindest offiziell nicht für die Kommunikation mit dem JTAG ICE (das STK500.exe-Tool hat sowas). Im Gegensatz zu mir besitzt du hier zwei Dinge, die wesentlich sind: Ein Windows mit AVR Studio sowie ein JTAG ICE mkI. Ersteres hatte ich nie und möchte es nicht haben, zweites habe ich nicht mehr.
Ich werde mal sehen was ich rausfinden kann. http://www.essential-freebies.de/board/viewtopic.php?t=8808 wird mir bestimmt helfen.
Ja, zum Beispiel. Ich bin dir auch gern beim ,,Dekodieren'' des seriellen Datenstroms behinderlich. Das Gescheiteste wäre es eigentlich, wenn wir das Ganze auf der (englischen) avrdude-dev [at nongnu.org] Mailingliste dann abwickeln. Da ist es im Moment sowieso recht ruhig, dann könnten aber bei Bedarf auf andere avrdude-Entwickler an der Diskussion teilhaben, und es ist auch noch sinnvoll für die Nachwelt archiviert.
http://www.sysinternals.com/Utilities/Portmon.html ist ein ganz brauchbarer "COM-Port"-Sniffer. (Hat vor einiger Zeit auch schon geholfen, einen Fehler in der STK500v2 Protokollbeschreibung zu finden, fuehrte dann zur Korrektur der AppNote).
Stimmt die netten Leutz von Winternals sind auch immer auf Zack gewesen Bitte net sauer sein, wenn das etwas dauert ehe ich mich melde da ich nebenbei auch noch an ein paar Projekten arbeite und tagsüber keine Zeit habe...
So endlich mal Zeit gehabt, mich darum zu kümmern. AVRS Test.log - AVR Studio 4.12.490 COM4 Log AVRD Test.log - WinAVR 20060421 COM4 Log Logs habe ich mit PortMon von sysinternals.com mitgeschnitten. Komisch ist auch, dass die 0xA4 0x41 0x41 Sequenz bei AVRDude mit sehr vielen Resets und Timeouts einherkommt :-/ Genaueres müssten aber vielleicht die Pros diagnostizieren...
> So endlich mal Zeit gehabt, mich darum zu kümmern. Danke! > Komisch ist auch, dass die 0xA4 0x41 0x41 Sequenz bei AVRDude mit > sehr vielen Resets und Timeouts einherkommt :-/ Nö, keine Resets oder Timeouts. Das Einzige, was da auffällt ist, dass AVRDUDE bei jeder Schreiboperation den serial IO timeout auf 500 ms setzt und bei jeder Leseoperation auf 5000 ms, während AVR Studio die eigentlichen Transfers mit einheitlich 2500 ms Timeout abwickelt (davor aber auch teilweise mal auf 70 ms runtergeht -- habe ich nicht näher analysiert, was da gemacht wird). Könnte man als uneffektiv ansehen, weil viele Syscalls abgearbeitet werden, die nicht zum Datentransport beitragen. Derjenige, der seinerzeit den Modul für die serielle Kommunikation under Windows geschrieben hat, hat sich das so ausgedacht. (Es müsste Martin Thomas sein, wenn ich das Copyright richtig deute. Kein Unbekannter hier in diesem Forum.) Ansonsten ist der wesentliche Unterschied, dass AVR Studio mit dem Kommando "Leave programming mode" aufhört, während AVRDUDE noch ein "Reset", gefolgt von "Go" dahintersetzt um sicherzustellen, dass das Target auch wirklich wieder in den Run-Modus geht. Ich bin mir nicht ganz sicher, ob das nach dem "Leave programming mode" ggf. auch automatisch der Fall wäre, dieses Verhalten ist aber auf jeden Fall Absicht und das, was die meisten Leute erwarten. Ich habe selbst kein JTAG ICE mkI mehr, und da ich kein Windows und damit auch kein AVR Studio benutze, kann ich dein ursprüngliches Problem ja auch nicht verifizieren. Wenn du gewillt bist, dir mal ein AVR Studio aus dem Sourcecode zu bauen, können wir gern gemeinsam sehen, ob das Weglassen von Reset und Go OK wäre und dein Problem lösen würde. Was du dafür brauchst (außer dem Sourcecode von AVRDUDE natürlich) wäre ein MinGW + Msys. (Ich kann mir einen JTAG ICE Clone auf einem STK500 zusammenstöpseln, um zumindest den prinzipiellen Funktionsnachweis zu haben.)
Mhh das wird Zeit brauchen :-( Wäre es vielleicht möglich, dass du mir die mal kompilierst und ich teste sie hier bei mir?
> Mhh das wird Zeit brauchen :-( Sollte in weniger als einem Abend erledigt sein. > Wäre es vielleicht möglich, dass du mir > die mal kompilierst und ich teste sie hier bei mir? Gern, wenn du ein FreeBSD hast? Ein Linux-Binary bekomme ich vielleicht auch noch zusammen, aber Windows habe ich eher schlecht als recht.
Ich werde mal sehen, das mit MINGW selbst hinzukriegen (DevCPP hat den doch auch drin?), kann aber wie gesagt wirklich dauern...
Da mir gerade mal ein Windows übern Weg gelaufen ist auf Arbeit: http://www.sax.de/~joerg/avrdude-5.2cvs-jtagmkIhack.zip Hier die Prüfsummen: MD5 = 1d21cb9c6fa833cec83de0a13b0759f1 SHA1 = 9d7b8e10110f932fd69f077e7face8fad3d280b2 Hmm, da fällt mir gerade ein: das Teil ist gegen die libusb-win32 gebaut. Die musst du dir dann auch installieren (sorry, war auf der Maschine gerade so). Die bekommst du bei sourceforge.net. Wenn jemand Lust hat, den AVR Dragon damit zu testen: das sollte gehen.
Vielen dank! Er deaktiviert sich jetzt auch (Led aus) aber irgendetwas harkt immernoch, AvrStudio will sich dann auch nicht mehr mit dem Programmer verbinden. Wenn man den Programmer vom qC abzieht gehts wieder (Led strahlt kontinierlich hell, wie immer).
Hmm, tja. Nun mach' ich aber die gleichen Kommandos (zumindest am Ende) wie AVR Studio: disable programming mode ist alles, danach ist Schluss. Was mich aber daran auch interessiert: läuft die Target-CPU nach dem Programmieren damit los? Du kannst ja mal tracen, was das AVR Studio denn mit dem ICE versucht zu reden, wenn's nicht klappt. Vielleicht gibt das ja einen Rückschluss.
Ja nach dem Programmieren wird ordentlich resettet und der qC führt das Programm aus. Komisch ist das schon aber was anderes kanns nicht sein, der COM Port wird ja wieder frei gegeben :-/ Jawohl, werde mal das AVR Studio noch mitloggen ^^
> Ja nach dem Programmieren wird ordentlich resettet und der qC führt das > Programm aus. Schön, dann ist es zumindest "safe", diese Vorgehensweise zu benutzen. Vielleicht committe ich das dann ins CVS, aber nur fürs mkI. Beim mkII gibt's deine Probleme ja nicht, weil man dem ordentlich ,tschüss' sagen kann (und sollte).
So hier das Log wenn AVR Studio sich per "Connect" mit dem Programmer verbinden will. Es kriegt einfach keine Synchronisation hin :-(
Ah. Ich glaube, ich weiß, worüber der stolpert... AVRDUDE setzt die Baudrate zum Programmieren auf 115200 hoch und belässt sie dabei. AVR Studio arbeitet wohl zumindest am Anfang nur mit 19200 Bd. Man müsste das ICE also auf diesen Wert zurücksetzen. (AVRDUDE hat keine Probleme, da es bei Bedarf alle sinnvollen Raten durchprobiert.) Probier' mal bitte, ob du mit -c jtag1slow das Problem los wirst. Wenn ja, würde ich dich um einen Bugreport auf https://savannah.nongnu.org/bugs/?group=avrdude bitten. Da baue ich dann mal irgendwann ein, dass er vor dem Ende die Baudrate wieder rücksetzt auf 19200 Bd.
Ich korrigiere mich, hatte wohl nen Fehler gemacht. Es FUNKTIONIERT hervorragend! Ich stelle einen Bugreport zusammen!
Hier nocheinmal der Vollständigkeit halber: https://savannah.nongnu.org/bugs/index.php?18262 Und danke nochmal!
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.