Was ist bei Nutzung des debugWIRE Interface zu beachten?

[Klaus (klaus_z)]

Moin,

dumme Frage. Habe den AVR Dragon zuhause und programmiere gerade einen 
ATMEGA328P xplained. Habe mir dort Wannenstiftleisten (wie beim Arduino) 
und Pins draufgelötet um per ISP zu programmieren.

Ich habe jetzt ein Programm geschrieben um per Schieberegister ein 
Knight Rider Lauflicht auszugeben. Bei Visual Studio funktioniert es 
ohne Probleme. Also ich bekomme eine Ausgabe wie im Anhang.

Ich könnte jetzt hier meinen Quellcode posten und ihr sagt mir, wo der 
Fehler liegt, aber ich würde es gerne selber lösen, da ich auch schon 
ziemlich nah an der Lösung dran bin.

Im Datenblatt des Dragon steht, dass ich im µC ein Fusebit ändern soll 
um Debugging per debugWIRE Interface zu aktivieren, allerdings wäre dann 
die ISP Schnittstelle deaktiviert und ich bin mir unsicher, ob ich dann 
das Fusebit SPIEN wieder auf HIGH setzen kann.

Also im Datenblatt:
https://ww1.microchip.com/downloads/en/devicedoc/atmel-42723-avr-dragon_userguide.pdf
steht auf Seite 19, das ich debugWIRE einfach wieder im Debugging 
Fenster deaktiviern kann. Allerdings würde ich mir lieber das OK von 
euch erfahrenen holen, bevor ich mir den Zugriff zum Controller nehme.

Also in kurz: kann ich das FUSE auf LOW setzen und dann später im 
Debugging Teil wieder aktivieren, wie es im Datenblatt steht? Und macht 
es überhaupt Sinn in Microchip Studio zu debuggen (man kann es ja auch, 
über Visual Studio (in meinem Fall) machen)? Ich kann halt nur nicht 
wirklich sehen, wie die logischen Verknüpfungen arbeiten, oder?

[Klaus (klaus_z)]

Moin,

ich habe es endlich nach langem hin und her geschafft, das Programm zum 
laufen zu bringen, habe mich aber nicht getraut das SPIEN Fuse 
auszuschalten. Hat mir leider keiner das Okay gegeben :(

Kann es sein, dass die pow(a,b)-Funktion aus math.h auf dem 
Microcontroller nicht so richtig funktioniert? Bzw. habe ich die 
vielleicht falsch genutzt, weil merkwürdige Werte rauskamen.
Also ich konnte es nicht auslesen, aber sehe ja am Lauflich das etwas 
nicht stimmt. Habe es jetzt halt ohne diese gelöst, die einzelnen 1er 
Stellen auszugeben.

Oder gibt es vielleicht einen ganz leichten Weg, binäre Werte seriell 
auszugeben? (ans Schieberegister)

[Johannes T. F. (jofe)]

Klaus schrieb:
> Oder gibt es vielleicht einen ganz leichten Weg, binäre Werte seriell
> auszugeben? (ans Schieberegister)

Das macht man über das SPI. Siehe dazu AVR-Tutorial: Schieberegister 
(dort allerdings Assembler, habe auf die Schnelle nichts dazu im 
GCC-Tutorial gefunden).

[Stefan F. (Gast)]

Klaus schrieb:
> habe mich aber nicht getraut das SPIEN Fuse auszuschalten.

War auch besser so. Wenn du die aus schaltest, verlierst du den Zugang 
zum Mikrocontroller. Dann lässt er sich nur noch im High-Voltage Modus 
ansprechen, dafür müsstest du ihn aber auslöten.

Wenn du in der IDE eine Debug-Sitzung beginnst, kümmer diese sich darum, 
vom ISP Modus auf DebugWire umzuschalten. Und du brauchst dann auch 
wieder die IDE, um vom Debugger zurück auf ISP zu wechseln.

Wenn etwas schief geht kann es dir passieren, dass die IDE schließt 
während die Debug Sitzung noch aktiv ist. In diesem Fall kannst du die 
IDE nach erneutem Start wieder in den Debug Modus versetzen, und dann 
das Debuggen beenden.

Soweit ich weiß beendet Avrdude den Debug automatisch, falls nötig.

Was es sonst noch zu beachten gibt: Der Debug Wire ist der Reset Pin. Er 
funktioniert nur ohne kapazitive Last. Also wenn du da einen 
Reset-Kondensator dran hängen hast, mache da einen Jumper zwischen um 
ihn abzutrennen.

Noch ein paar Infos zu den Fuses: 
http://stefanfrings.de/avr_verfused/index.html

[Klaus (klaus_z)]

˙ɟ uɐɟǝʇs schrieb:
> Noch ein paar Infos zu den Fuses:
> http://stefanfrings.de/avr_verfused/index.html

Schöne Seite, habe ich gleich als Lesezeichen gespeichert.

˙ɟ uɐɟǝʇs schrieb:
> Wenn du in der IDE eine Debug-Sitzung beginnst, kümmer diese sich darum,
> vom ISP Modus auf DebugWire umzuschalten. Und du brauchst dann auch
> wieder die IDE, um vom Debugger zurück auf ISP zu wechseln.

Auf deiner Seite steht folgendes:
DWEN: Wenn man dieses Fuse ein schaltet, verliert man den Reset Pin und 
damit auch die ISP Schnittstelle. Stattdessen wird der Pin nun zum 
Debuggen als DebugWire verwendet.

Verliere ich, wenn ich das Fuse einschalte, auch die Möglichkeit die 
Fuses umzustellen? Weil ich versteh noch nicht so recht, wie ich sonst 
in den Debugging Mode mit einer ISP-Schnittstelle kommen kann.

Meine IDE fragt mich folgendes: Do you want to use ISP to enable the 
DWEN fuse? Also kann ich da bedenkenlos Ja drücken, oder eben selber das 
Fuse aktivieren?

[Jörg W. (dl8dtl) (Moderator)]

Klaus schrieb:
> Verliere ich, wenn ich das Fuse einschalte, auch die Möglichkeit die
> Fuses umzustellen?

Ja, erst einmal. Du musst das Teil wieder in den ISP-Modus bringen, um 
die Fuses zu ändern.

Der kritischste Punkt ist: an /RESET darf kein C hängen, also auch nicht 
zu viel Leitung. Ein Pullup von 4.7 bis 10 kOhm kann die Situation 
zuweilen verbessern.

[Stefan F. (Gast)]

Klaus schrieb:
> Verliere ich, wenn ich das Fuse einschalte, auch die Möglichkeit die
> Fuses umzustellen?

Jein. Man kann den Debug mode mit einem Debug Kommando temporär 
verlassen. (Nach einem Powercycle wärst du wieder im Debugmodus). In 
diesem temporären Zustand ist ISP wieder ansprechbar, so dass die IDE 
die DWEN Fuse wieder aus schalten kann. Das hilt dann dauerhaft.

> Weil ich versteh noch nicht so recht, wie ich sonst
> in den Debugging Mode mit einer ISP-Schnittstelle kommen kann.

Wie gesagt kümmert sich die IDE darum. Sie schaltet die DWEN Fuse ein 
wenn du die Debug Sitzung startest.

Vor der Debug Sitzung muss ganz normal ISP aktiv sein.

[Stefan F. (Gast)]

Klaus schrieb:
> Also kann ich da bedenkenlos Ja drücken, oder eben selber das Fuse
> aktivieren?

Ja, wenn du keinen Kondensator am Reset Pin hast, oder irgendwas anderes 
was die Debugwire Kommunikation blockiert. Denn nach dieser Aktion 
kommst du nur durch ein Debug Kommando wieder zurück in den ISP Modus.

[Klaus (klaus_z)]

Danke für all Eure hilfe. Hat alles geklappt mit dem Debuggen.