Ich probiere jetzt schon eine Weile herum, den Debugger Atmel ICE zum Debuggen zu bringen. Leider wird das Teil unter Linux nicht unterstützt (zum Debuggen), was mich zum AVR Studio 7 (7.0.634) auf einer Windows 7-Installation in einer Virtual Box-Umgebung gezwungen hat. :o( Nun die Problembeschreibung: 1. Ich benutze einen kleinen, selbstgelöteten Adapter für die Umsetzung von 6-poligem Kabel auf 10-poliges Kabel (Vcc, Reset, SCK, MISO, MOSI). Programmieren der Software und Lesen/Setzen der Fuses per ISP funktionieren mit dem verwendeten ATMega88 problemlos. Meine Platine habe ich noch ein paarmal angesehen, Verdrahtungsfehler habe ich keine entdeckt. 2. Beim Debugging-Versuch fragt das AVR Studio 7, ob es die DWEN-Fuse setzen soll. Ich sage "Ja", das Teil fordert mich auf, dem Target die Spannung zu nehmen und wieder zu geben und dann "ok" zu klicken. Mache ich auch. 3. Danach meint das Ding, nicht debuggen zu können. Folgende Fehlermeldungen bekomme ich: 20:23:27: [ERROR] debugWIRE physical error. Debugger command Activate physical failed., ModuleName: TCF (TCF command: Processes:launch failed.) 20:24:00: [ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool), ModuleName: TCF (TCF command: Device:startSession failed.) 4. Der AVR lässt sich nicht mehr ansprechen und ist zum "Ziegelstein" geworden. Glücklicherweise habe ich ein STK600 und kann das Ding per HVPP wieder zum Leben erwecken. Dabei sehe ich, dass DWEN gesetzt ist und auch SPIEN. Nachdem ich DWEN gelöscht habe, lässt sich der Chip normal wieder per ISP ansprechen. Zur Hardware selber: ATmega88, auf eigenem Mini-Board mit 10 MHz-Oszillator, 5 V Betriebsspannung an VCC/GND und AVCC/GND inklusive jeweils 100 nF, Reset-Pin per 10k Pull-up an Vcc. Ansonsten nur die ISP-Pins beschaltet. Ich habe schon eine Weile lang im Netz gesucht, die Fehlermeldung gibt es recht häufig, wenn die Hardware falsch verdrahtet ist - also beispielsweise eine Kapazität am Reset-Pin hängt. Allerdings hilft mir das alles nicht weiter, ich finde keine Ursache. Insbesondere scheint auch bei der Falschverdrahtung das Problem des "Ziegelstein"-Erzeugens nicht typisch zu sein. Gibt es ähnliche Erfahrungen oder Tipps, was das Problem sein könnte?
Diese Fehlermeldung ist echt Schrott. Hatte ich auch schon mal. Genauen Text weiß ich nicht mehr, aber Got 0xc0 war dabei. Die Lösung war sehr profan: Einfach mal mit den verschiedenen Typen experimentieren. Also anstatt ATmega88 den ATmega88A auswählen. Mir scheint, als ob die ProzessorID abgefragt wird, und bei Nichtübereinstimmung das Got 0xc0 kommt. Mit der Virtualbox stand ich auch mal auf Kriegsfuß. Dessen USB-Implementation ist nicht so Toll. Qemu-kvm dagegen tut es prächtig; vmware player nach hörensagen ebenso (wobei ich vmware mit Linuxviren assoziier, bin halt unerfahren).
Ja, tatsächlich. Mit einem ATmega328 funktioniert es. Aber auch nur sehr buggy: Wenn ich DWEN automatisch setzen lasse (also einfach das Debugging starte), wird auch der 328er zum Ziegelstein, genau wie der 88er. Setze ich DWEN manuell, kann ich debuggen und während des Debuggens über "Debug --> Disable DebugWire and stop debugging" das alles wieder zurücksetzen. Den 88er bekomme ich so aber nicht mit dem Debugger zusammen zum Laufen. Der verwandelt sich immer wieder zum Ziegelstein. Die DWEN-Fuse wird zwar gesetzt, aber das Debugging funktioniert nicht. Manchmal fragt er auch bei Debugging-Start nochmal, ob er DWEN setzen soll, obwohl das schon gesetzt ist. Irgendwie versucht die IDE dann wohl per ISP mit dem Teil zu reden, was eben zu der folgenden Fehlermeldung führt: "[ERROR] Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool), ModuleName: TCF (TCF command: Device:startSession failed.)" Ist das Zeug wirklich so schrottig oder gibt es da noch einen Trick? So ist das praktisch unbrauchbar. Mal abgesehen davon, dass die ganzen Funktionen irgendwie in dem AVR Studio verteilt sind und die ganze Aktivierung und Deaktivierung von DebugWire ziemlich undurchsichtig machen...
:
Bearbeitet durch User
Angehängte Dateien:
-
Studio7_JTAGICE3.jpg
23 KB
Hi Leute genau das selbe Problem mit dem Atmega88, habe ich im Moment. Stk 500 Resetpin off, JTAGICE3 über ISP im Studio7 debuggerWire, siehe Bild. Geht leider nichts, Fehlermeldung und das Teil ist dann Tot, muss mit HVSP Mode zurück gesetzt werden. Hat da schon jemand den Trick raus, oder geht es mit dem Atmega88 nicht ? Gruß Oliver
USB-Implementation der VM ist halt schrott bzw. nicht für irgendwelche timing kritische Sachen zu gebrauchen.
uwe schrieb: > USB-Implementation der VM ist halt schrott Kennst du Oliver? Wenn nicht, woher nimmst du sonst, dass er eine VM benutzt?
> Kennst du Oliver? Wenn nicht, woher nimmst du sonst, dass er eine > VM benutzt? Weil es im originalpost um Win7 in einer VM ging. > was mich zum AVR Studio 7 (7.0.634) auf einer Windows > 7-Installation in einer Virtual Box-Umgebung gezwungen hat. :o(
uwe schrieb: >> Kennst du Oliver? Wenn nicht, woher nimmst du sonst, dass er eine >> VM benutzt? > Weil es im originalpost um Win7 in einer VM ging. Das war aber vor einem Vierteljahr. Der TE braucht vermutlich dafür keine Antworten mehr. Oliver hatte das nur ausgegraben, weil es so aussieht, dass er das gleiche Problem haben könnte. Er schreibt auch nicht, dass er ein generelles Kommunikationsproblem mit dem Programmer hat (wie es bei einem USB-Problem der Fall wäre), sondern nur, dass er ganz konkret mit debugWIRE ein Problem hat. @Oliver: bist du dir sicher, dass deine Schaltung überhaupt debugWIRE-fähig ist?
Jörg W. schrieb: > @Oliver: bist du dir sicher, dass deine Schaltung überhaupt > debugWIRE-fähig ist? > VM Maschine ? Hallo nein natürlich keine VM Maschine Win7 64bit Pro Hatte gerade andere Probleme mit der neuen Version 7.0.79 geht aber jetzt. Nur leider das gleiche Verhalten, wie gesagt: STK 500 Resetpin off, JTAGICE3 über ISP debuggerWire. Am Resetpin sehe ich auch übertragene Daten Reset wird für 40ms low dann ca. 95ms Daten dann wieder 40ms low, dann geht der Resetpin wieder auf high. Dann kommt im Studio Debugger nach einer Zeit Timeout, anscheinend antwortet der Prozessor nicht korrekt. Vielleicht hat einer noch eine Idee ? Gruß Oliver
Oliver K. schrieb: > anscheinend antwortet der Prozessor nicht korrekt. Nochmal: ist deine Schaltung debugWIRE-fähig? Dazu darf an /RESET entweder gar nichts dranhängen oder bestenfalls ein Pullup von 4,7 oder 10 kΩ. Auf keinen Fall irgendein Kondensator. Da müssen Impulse im Mikrosekundenbereich durchlaufen (Eindrahtbus), nicht einige 10 ms wie beim normalen Programmieren. Edit: du hast das Target auf einem STK500, verstehe ich das richtig? Ich fürchte, die Kabelei auf dessen Platine ist einfach viel zu lang für debugWIRE.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Oliver K. schrieb: >> anscheinend antwortet der Prozessor nicht korrekt. > > Nochmal: ist deine Schaltung debugWIRE-fähig? > > Dazu darf an /RESET entweder gar nichts dranhängen oder bestenfalls > ein Pullup von 4,7 oder 10 kΩ. Auf keinen Fall irgendein Kondensator. > > Da müssen Impulse im Mikrosekundenbereich durchlaufen (Eindrahtbus), > nicht einige 10 ms wie beim normalen Programmieren. > > Edit: du hast das Target auf einem STK500, verstehe ich das richtig? > > Ich fürchte, die Kabelei auf dessen Platine ist einfach viel zu lang > für debugWIRE. Hi Jörg ich denk ja den Reset vom STK500 getrennt. Und mit dem Oszzi am Resetpin, sieht alles gut aus, auch die Flankensteilheit ist ok kein Verschleifen durch zu hohe Kapazität. Gruß Oliver
Oliver K. schrieb: > Und mit dem Oszzi am Resetpin, sieht alles gut aus, auch die > Flankensteilheit ist ok Du schriebst aber oben was von Millisekunden. Das passt nicht zu debugWIRE, das sollte deutlich schneller ticken.
Angehängte Dateien:
Jörg W. schrieb: > Oliver K. schrieb: >> Und mit dem Oszzi am Resetpin, sieht alles gut aus, auch die >> Flankensteilheit ist ok > > Du schriebst aber oben was von Millisekunden. Das passt nicht zu > debugWIRE, das sollte deutlich schneller ticken. Ja das ganze Packet dauert ms. Im Bild sieht man die Datenbits kommen mit 125 kHz, weiß allerdings nicht ob das ok ist. Gruß und schönes Wochenende Oliver
Oliver K. schrieb: > Im Bild sieht man die Datenbits kommen mit 125 kHz, weiß allerdings > nicht ob das ok ist. Ist nicht viel, müsste aber OK sein. Irgendwie versuchen die wohl, die Datenrate dynamisch auszuhandeln.
Der Debugger bricht mit der Meldung ab "Timed out waiting for device to reset" und am Oszzi bleibt der Resetpin High, es ist mein erster Debug Versuch mit dem Atmega88, vielleicht habe ich etwas vergessen vorher einzustellen. Denke aber eher nicht, darum die Frage im Forum, hat jemand je schon mal mit einem Atmeg88 Debuggwire erfolgreich eingesetzt ? Gruß
Oliver K. schrieb: > Denke aber eher nicht, darum die Frage im Forum, hat jemand je schon mal > mit einem Atmeg88 Debuggwire erfolgreich eingesetzt ? Ja, aber was genau hilft dir das jetzt?
Jörg W. schrieb: >Hat jemand je schon mal >mit einem Atmeg88 Debuggwire erfolgreich eingesetzt ? > > Ja, aber was genau hilft dir das jetzt? Vielleicht geht das mit dem Studio 7 und dem Atmega88 prinzipiell nicht über debugWIRE. Gruß Oliver
Angehängte Dateien:
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.