DebugWire AVR

Andreas Ruetten schrieb:

Anfrage bei avrfreaks.net empfehlen oder ggf. auch bei avr at atmel

Nur so, was sollen sie denn sonst tun, als eine ,,hinrissige Fuse''

Sie wollten ganz offensichtlich bei den ,,Kleinen'' der Applikation nicht noch weitere Pins entziehen und haben den /RESET-Pin daher

(Du plenkst, bitte abstellen.)

Das solltest du sehr wohl. dW sollte die Fusebits genauso setzen

AVaRICE-Einbindung des JTAG ICE mkII noch nicht so weit, dass ich dir

nicht, und *Studio finde ich sowieso unbedienbar von dem, was ich bislang von derartigen Teilen erlebt habe. Der Vorwurf geht dabei aber weniger an Atmel als mehr an das Vorbild, das sie sich genommen haben und dessen besch***e Bedienung sie sich damit aufgehalst haben. Daher nehme ich aber auch Unix und GDB und AVaRICE.)

Wenn du die dW-Fuse wieder entfernt hast, kannst du doch mit ganz normalen ISP-Methoden auf den Chip, oder was vertehe ich hier nicht?

programmiert haben.

Falls das aber wirklich der Fall sein sollte, dass AVR Studio da mehr

zu einem Bugreport an oben genannte email-Adresse raten. Die Jungs in Norwegen sind in der Regel recht schnell mit antworten und -- im Gegensatz zu dir -- auch sehr freundlich.

Gerald Oppen schrieb:

Nun, auf dem normalen Upgrade-Weg kannst du ja in der Firmware immer nur nach oben gehen. ;-) Dann merken sie es wohl.

Aber ich denke, hier haben sich die Jungs wirklich selbst ein Problem geschaffen. Die Funktion set device descriptor akzeptiert nur einen descriptor mit exakt der Länge, der zur aktuellen Firmware-Version gehört. Solange man nur mit einer Instanz von AVR Studio arbeitet, haben *sie selbst* natürlich kein Problem damit -- aber bereits als Hersteller einer Drittversion (ich also mit AVaRICE :-) kannst du dir nicht mehr einfach raussuchen, jetzt eine neue Firmware drüberzunageln, nur weil dir die im ICE nicht gefällt. Das habe ich ihnen auch schon artikuliert. Dass das natürlich auch mit AVR Studio selbst Probleme geben kann, war mir dabei gar nicht in den Sinn gekommen -- da würde ich dir auch einen Bugreport nahelegen.

Von der Kommandozeile aus müsstest du (mit jtagicemkii.exe oder so ähnlich) wohl auch eine beliebige Firmware laden können, so wie ich das verstanden habe. Habe das Tool aber nie selbst benutzt.

Das ist logisch, da dW ja die Funktion des /RESET-Pins außer Betrieb nimmt.

Mit avrprog.exe nochmal versuchen, ob du was laden kannst? Ansonsten aufmachen, den 6poligen ISP-Stecker nachlöten und darüber programmieren. Ggf. auch eine Mail an Atmel mit der Bitte um ein Image des Bootloaders.

Joerg Wunsch schrieb:

Wenn mann aber Stunden sinnloserweiser mit Bananasoft und schlechten Tools verbracht hat, muß der Überdruck raus:)

Dann schau dir mal einen C8051F300 an. Der kann das sehr wohl ohne Fuses. Da entscheide ich alles per Software, und genau so muß es sein.

s.o. Silabs kanns

schön nur leider kann die Software das nicht. Allerdings bin ich mit meiner

Na wer wird den wohl ausfallend werden?

Ja das habe ich getan, nur wenn du dW benutzt wird am Anfang über die Jtag Verbindung ( hier als SPI ) die DWEN Fuse gestzt, nur leider werden eben auch andere Fuses auf Auslieferungszustand zurückgestzt.

Andreas

Solange du dein Feedback nicht Atmel zukommen lässt, wird sich daran aber auch nichts ändern. Die Jungs dort müssen schon wissen, wo ihren Anwendern der Schuh drückt, damit sie auch Abhilfe schaffen können.

Ich schrieb ja schon, ich komme mit diesen Klickibunti-IDEs ohnehin rundum nicht klar -- aber daher benutze ich sie auch gar nicht erst.

Och nö, ich möchte keine Controller mit 30 Jahre alter Technologie mehr programmieren. ;-)

Per welcher Software? Application software? Was, wenn die gar nicht mehr funktioniert? Schließlich will ich die ja debuggen, da kann ich mich doch nicht auf die Applikation verlassen -- oder was verstehe ich hier flasch?

Ich finde zumindest den Grundansatz nicht verkehrt (sofern das ICE es auch wirklich zuverlässig schafft, den /RESET-Pin wieder zurück zu definieren, damit es kein Suizid wird wie bei ATmega8's RSTDSBL Option).

Antwort vom ,,kurzen Dienstweg'':

``You may be aware of the fact that there is only one way to disable the debugWIRE fuse in AVR Studio, which is the button in the mkII options dialog.''

Dann nimm doch bitte den langen Dienstweg in Form der von mir genannten email-Adresse. Ich habe im Laufe meiner Opensource-Software-Arbeit einiges mit den Norwegern zu tun gehabt und bislang immer schnell und unbürokratisch Hilfe bekommen.

Joerg Wunsch schrieb:

Aber ein Auto mit 100 Jahre alter Technik benutzt du schon? Der Core von Cygnal/Silabs ist eine komplette Neuentwicklung mit Risc Technologie.

Wieso sollte die nicht mehr funktionieren?

Schließlich will ich die ja debuggen, da kann ich

Das debuggen geht immer, die Applikation kann nur alles einstellen. Es wird halt immer mit internen Takt gestartet. Die Applikation hat dann vollen Zugriff auf alle Hardwarefunktionen. So als könnte der AVR zur Laufzeit die Fuese selbst proggen. Und nur so ist es sinnvoll. Was Atmel mit den Fuses macht ist dummfug. Allein, das durch eine falsche Programmierung der ganze Chip unbraucbar wird ist eine Zumutung.

s.o.

OK, werde ich tun. Entwickeln denn die Norweger überhaupt das AVR Studio?

Andreas

Einführung ca. 1983 also nur etwas über 20 Jahre. Der 6502 ist fast 30 Jahre, da war die Architektur aber ohnehin besser.

MfG JRD

Nö. Ich muss die Motorleistung nich mehr mit Rastzähnen einstellen, habe keine Pferdewagenfedern mehr im Auto, komme beim Betätigen der Bremse auch bei etwas höheren Geschwindigkeiten auf kurzem Weg zum Stehen, ... Davon abgesehen, ich fahre eher Fahrrad, aber selbst da sind die Unterschiede zu vor 100 Jahren drastisch genug.

Also ein Mercedes mit dem UI eines Trabanten. Nein, auch das würde ich nicht benutzen wollen. ;-)

Wenn sie funktionieren würde, warum soll ich sie debuggen wollen?

Die Diskussion hatten wir neulich schon. Wenn du die AVRs nicht magst, warum nimmst du sie dann?

Ja, wer sonst? Der AVR ist komplett eine norwegische Entwicklung.

Joerg Wunsch schrieb:

Aber der Verbrennungsnotor hat immer noch die gleiche Funktion. Und das drumherum ist nur verbessert worden. Und der C80F51Cxx ist eben auch kein alter 8051 mehr.

Vileicht einfach mal anschauen, und nicht sofort ablehnen, weil es nicht von supercoolen Studenten aus Norwegen gemacht worden ist.

Weil ich muß, warum sonst. Wenn die Kunden die haben wollen, dann gibt es die ebend. Davon abgesehen, finde ich die Architektur gelungen. Nur die AD-Wandler und die Fuses sind ein grauen.

Ja der AVR, das heißt aber nicht zwangsläufig, das die AVR Studiosoftware in Norwegen gedengelt wird. Atmel ist ein global agierendes Unternehmen!

Andreas

Andreas Ruetten schrieb:

Wesentliches K.O.-Kriterium für mich ganz persönlich (und ich muss damit kein Geld verdienen): es gibt keinen GCC dafür, und auch sonst keinen wenigstens einigermaßen ausgefeilten freien Compiler. SDCC ist nach allem, was ich davon gehört habe, doch eine ganz Nummer kleiner, und mit Software von Dr. Keil habe nicht nur ich bereits genügend schlechte Erfahrungen machen dürfen, als dass ich sie mir nicht freiwillig nochmal antun würde (und für ein Hobby schon gar nicht). Andere Leute mit schlechten Erfahrungen, deren Meinung ich hier durchaus ernst nehmen mag, verdienen übrigens ihre Brötchen damit.

Nicht, dass ich den GCC für AVR für den totalen Stein der Weißen halten würde, er holpert schon heftig mit Harvard, aber es ist dennoch ein ordentlicher C-Compiler. Nach einer kurzen und leidvollen PIC-Erfahrung habe ich den für meine weiteren Hobbyprojekte ganz oben auf die Liste von ``must have''-Dingen gesetzt.

Btw., die Leute da sind alles andere als Studenten... Klar, es gibt auch welche, die noch in den 20ern sind, aber auch Leute in meinem Alter. ;-)

Ich kann mit den Fuses leben, und der AD-Wandler ist wohl eher dafür bestimmt, dass man mal ein Poti als Eingabemedium benutzen kann oder seine eigene Batteriespannung abschätzen kann, als dass man damit irgendwelche Präzisionsaufgaben lösen können soll. Dafür taugt er aber allemal.

Ist es, aber sowohl Design als auch die Software um den AVR herum sind aus Norwegen. Produziert wird er sicher woanders, vielleicht in Frankreich, weiß ich auch nicht genau.

Hast du nun eigentlich mal dein Problem dorthin gemailt?

Ja. ATtiny13. Lief alles so, wie es im Handbuch stand,

Keine Ahnung. Die Updates vom STK500 und JTAGICE MKII haben immer funktioniert.

Kann das JTAGICEMKII auch selber - die SPI-Unterstützung hat er. Steht auch in der Dokumentation.

Debugwire ist keine Programmierschnittstelle, sondern nur eine Debugschnittstelle.

Das sollte nicht passieren.

Bei Deinen ganzen Äußerungen kann ich mir nur vorstellen, daß das Problem vor der Tastatur sitzt. Sorry.

Mit freundlichen Grüßen

Frank-Christian Krügel

Frank-Christian Kruegel schrieb:

Bis jetzt auch, nur dieses eine mal nicht!

Genau das steht doch oben. Der "simple SPI Programmer" ist die SPI Unterstützung. Wer lesen kann, ist klar im Vorteil.

Nein?, warum kann er dann die DWEN wieder zurücksezten? Warum kann er dann das Programm uploaden?

Und wenn ich deine Äußerungen lese, kann ich mir nur vorstellen, das du überhaupt keine Ahnung hast, und das auf andere projezierst. Also , wenn du nichts anderes beizutragen hast, außer Unfähigkeit zu unterstellen, dann schreib besser nichts!

Andreas

Andreas Ruetten schrieb:

Weil das wohl notwendiger Bestandteil des Protokolls ist. Wie sonst sollte man aus dem dW-Modus wieder zurückkommen?

Weil er über die Debugschnittstelle auch SPM ausführen kann, genau wie JTAG auch. Das muss er schon deshalb, weil er sonst keine BREAK-Instruction einfügen könnte.

Lass deine Ausfälle bitte stecken, sonst wirst du dir keine Freunde machen und keinerlei Hilfe mehr bekommen. Den einzig vernünftigen Weg zur Lösung deines Problems, nämlich den Kontakt mit Atmel zu suchen, bist du ja vermutlich immer noch nicht gegangen.

Sicher, Frank-Christians Unterstellung war nicht unbedingt fundiert (aber du hattest zuvor auch nie erwähnt, dass bei dir normalerweise dW funktioniert hat und nur dieses eine Mal nicht), aber deshalb musst du hier nicht ausfällig werden.

Joerg Wunsch schrieb:

Ja warum kann mann dann keine anderen Fuses setzen ( Über dW) wenn die eine schon geht. So wie es jetzt ist, brauch man 2 Schnittstellen. dW und SPI. Ich glaube die haben das einfach noch nicht im Studio integriert.

Und das würdet ihr beide nicht als programmieren bezeichnen? Er schreibt das Programm in das Flash. Was soll das anderes sein als über SPI ins Flash?

Das war kein Ausfall sondern eine adäquate Antwort auf seine "Unverschämtheit".

Den einzig vernünftigen Weg

Schon wieder eine unfundierte Unterstellung. Ich habe denen das Problem geschildert.

Ich habe nie behauptet, das die dW grundsätzlich nicht geht! Ich habe mich nur geärgert, das AVR Studio beim setzen der DWEN Fuse über Simpel SPI andere Fuses mitbeeinflußt. Und ausfällig bin ich bis jetzt nur gegenüber den Toolherstellern geworden.( Weil ich mich eben schwarzgeärgert habe )

Andreas

Andreas Ruetten schrieb:

Sehr wahrscheinlich. dW ist ja auch noch recht neu, und die Chips, mit denen es geht, sind auch erst seit paar Monaten wirklich in Massen verfügbar.

Ich werde mich wohl für AVaRICE/GDB auch bald mal damit auseinandersetzen müssen.

Es ist halt trotzdem eine Debugschnittstelle, nicht eine Programmierschnittstelle. Vermutlich ist das Protokoll da auch noch etwas ,,optimierungsbedürftig'', da sie das dW selbst nicht offengelegt haben, kann auch gut sein, dass das ICE noch gar nicht alles davon kann. Kann auch sein, dass einfach die bisherige Art und Weise der Einbindung von alle dem Fuse-Geraffel in AVR Studio hier ein Klotz ist, so dass sich das intern nicht gescheit mit dem dW-Modul verheiraten ließ. Das werde ich spätestens dann wissen, wenn ich dW in AVaRICE und/oder AVRDUDE abhandeln kann. ;-)

Dein Tonfall hier unterscheidet sich insgesamt drastisch von vielen anderen in dieser Newsgruppe, auch von denen, die mit irgendetwas anderem nicht zufrieden sind. Nimm dir das doch bitte einfach mal an.

Dein Ursprungsposting kann man selbst bei wohlwollender Interpretation nur als ,,wüstes Rumgeschimpfe'' ansehen. Von Sachlichkeit nicht viel, damit bist du eben auch ausreichend weit weg von der Sache selbst geraten.

(Kontakt zu Atmel)

Na schön. Dann wird es ja hoffentlich wenigstens eine Erklärung geben, vielleicht auch eine Lösung.

Nun, *gesagt* hast du das nicht, aber als unbedarfter Leser konnte man aus deinem Ursprungsposting sowas durchaus herauslesen. Es genügt eben nicht, rein formal etwas nicht zu sagen, sondern man fährt besser, wenn man sich gar nicht erst missverständlich ausdrückt. Dazu gehört eben auch das Nennen von scheinbar unwichtigen Randinfos wie ,,Bisher hat das dW bei mir immer funktioniert, aber diesmal hat es mir beim Abschalten plötzlich alle Fuses zerschossen. Ist euch das auch schon so gegangen, oder habe ich hier einen Einzelfall?''

Am Tue, 14 Jun 2005 10:09:26 +0000 (UTC) schrieb Joerg Wunsch :

UI beim Auto: Primär Lenkrad, Gas, Bremse, (Kupplung),... Zum Glück sind die wesentlichen Funktionen des UI gleich, das erleichtert das Fahren fremder/neuer Autos ungemein. Obwohl der Stern schon bei der Handbremse aus der Reihe tanzt. :-)

Martin schrieb:

Und der Trabbi erst... Nur durch genaues Hinsehen, wie weit der Schalthebel nach unten zeigt, konnte man zweifelsfrei feststellen, ob man nun gerade den 1. Gang oder den Rückwärtsgang eingelegt hatte. ;-) Nee, einen im Trabant-Outfit verpackten Mercedes würde sicher niemand kaufen. Ungefähr so würde ich aber das Verpacken einer modernen µC-Technologie in einem altertümlichen 8051-Befehlssatz und -Modell verstehen.

Das liegt daran weil man in vielen Firmen denkt, dass $BUNTES&TEURES_WINDOWSPROGRAMM aufgrund der intuitiven Bedienung und dem tollen Support am schnellsten zum Ziel fuehrt ... was halt nicht immer stimmt.

Ack, ich habe mit dem 3.3er auch bei groesseren Programmen (80KiByte, da hat der alte AMD K5 schon eine halbe Minute zum kompilieren gebraucht) wenig Probleme festgestellt. Hatte mich da im Vorfeld auf schlimmeres eingestellt ... ohne die (sehr guten) FAQs im INet waere es auch deutlich muehsamer geworden.

Micha

Michael Baeuerle schrieb:

Nur weil Windows draufsteht sicher nicht, man sollte sich schon etwas Mühe geben das man wenigstens die gängisten Regeln einhält und das ganze Intuitiv gestaltet.

Gerald