mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik SPIen gelöscht durch AVR Dragon mittels debugWIRE ?


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe ein Problem beim on-chip debugging meines Atmega168.
Ich habe ein kleines Programm geschrieben und wollte es mittels Dragon 
debuggen. Wegen einer Fehlermeldung war dies aber nicht möglich. Nach 
Neustart von AVR-Studio ist es nun leider auch nicht mehr möglich 
überhaupt auf dem Controller zuzugreifen. Bei "Read Signature" kommt 
z.Bsp. folgende Fehlermeldung: Setting device parameters:..O.K.!
                               Entering programming mode..FAILED!
                               Leaving programming mode..O.K.!

Das eigenartige dabei ist, das in den Fusebits auf einmal SPIEN gelöscht 
ist. Und SPIEN kann man ja nur über HV oder JTAG löschen.
Liest der Dragon das einfach nur falsch aus ?
Hat jemand eine Idee, wie ich meinen Controller wieder ansprechen kann ?

Michael

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Debugging per dW aktiviert ist, dann funktioniert ISP nicht, weil 
der Reset-Pin eine andere Funktion bekommen hat. Man muss zuerst mittels 
dW diesen Debug-Modus wieder beenden.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In verschiedenen Artikel steht, dass man eben nur über Jtag oder 
HV-Programmierung SPIEN löschen kann, deswegen verwundert mich das ja. 
Und warum löscht sollte sich in den fusebits was ändern, wenn ich 
irgenetwas mit den debuggen nicht funktioniert ?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Hat jemand eine Idee, wie ich meinen Controller wieder ansprechen kann ?

Du startest noch mal in den Debugger und schaltest unter Debug->AVR 
Dragon Options mit Disable DW den AVR wieder in den normalen Betrieb. 
Dann funktioniert ISP wieder.

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael: Ich würde nicht drauf wetten, dass bei nicht funktionierendem 
ISP die per ISP ausgelesenen Fusebits korrekt angezeigt werden.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Du startest noch mal in den Debugger und schaltest unter Debug->AVR
>
> Dragon Options mit Disable DW den AVR wieder in den normalen Betrieb.
>
> Dann funktioniert ISP wieder.

Das habe ich mitr auch gedacht, nur kommt vorher leider schon eine 
Fehlermeldung, sodass ich den Dragon micht mehr in den Normalbetrieb 
schalten kann.
Der Chip ist anscheinend noch im "Debug-Mode" und lässt sich so eben 
nicht normal betreiben. Aber wie komme ich da wieder raus ?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das habe ich mitr auch gedacht, nur kommt vorher leider schon eine
>Fehlermeldung, sodass ich den Dragon micht mehr in den Normalbetrieb
>schalten kann.

Der Dragon ist manchmal etwas zickig. Im einfachsten Fall hilft es den 
Dragon mal von der Schaltung und USB zu trennen.

MfG Spess

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hilft leider auch nichts.

Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus. Wenn ich 
nen anderen Atmega dranhänge, lässt sich auf den ganz normal zugreifen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:

> Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus.

Es geht nicht um den Modus des Dragon. Sondern um den des AVR. Solange 
der AVR seinen Reset-Pin als dW-Pin versteht gibt es kein ISP. Nicht mit 
den Dragon, nicht mit dem STK500 und nicht mit dem AVR-ISP.

Wenn du mit dW arbeiten willst, dann wird per ISP der AVR auf dW-Betrieb 
umgestellt. Von dem Moment an gibt es kein ISP mehr. Rückwärts geht 
ähnlich einseitig: per dW wird der AVR wieder auf ISP-Betrieb umgestellt 
und von dem Moment an gibt es kein dW mehr.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Im übrigen ist der Dragon auch gar nicht mehr im Debug-Modus. Wenn ich
>nen anderen Atmega dranhänge, lässt sich auf den ganz normal zugreifen.

Der Dragon nicht. Aber wahrscheinlich dein AVR. Was passiert denn, wenn 
du mit dem ATMega das Debugging startest ('Start Debugging')?

MfG Spess

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur komme ich leider nicht mehr in den dW-Betrieb und kann den Zustand 
somit auch nicht abschalten.
Als Alternative gibt's dann nur HV-Programmierung, oder gibt es noch 
eine andere Möglichkeit ?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Der Dragon nicht. Aber wahrscheinlich dein AVR. Was passiert denn, wenn
> du mit dem ATMega das Debugging startest ('Start Debugging')?

Zuerst sieht es danach aus, als ob es mit den debuugen funktionieren 
würde, unten erscheint im Textfeld ganz normal "load programming 
memory...", nach ein paar Sekunden kommt dann leider aber die 
Fehlermeldung: "Platform has been disconnected, leaving programming 
mode".

Das passiert mir jetzt auch schon beim zweiten Controller. Es muss wohl 
irgendetwas mit meinen Programm zu tun haben.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das passiert mir jetzt auch schon beim zweiten Controller. Es muss wohl
>irgendetwas mit meinen Programm zu tun haben.

Nicht sehr wahrscheinlich. Der richtige Controller ist eingestellt?

Und wie sieht die Beschaltung vom Reset-Pin aus?

MfG Spess

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Nur komme ich leider nicht mehr in den dW-Betrieb und kann den Zustand
> somit auch nicht abschalten.

AVRDUDE kann das, das interessiert sich (anders als AVR Studio) nicht
für die Vorgeschichte.  Du gibst einfach ein normales ISP-Kommando
ein, also beispielsweise:
avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m

AVRDUDE stellt dann fest, dass das Aktivieren des ISP-Modus nicht geht
und versucht "im Weggehen" noch, das debugWIRE wieder abzuschalten.
Nach dieser Aktion ist man (laut Atmel) ohnehin gezwungen, die Sitzung
mit dem JTAG ICE / AVR Dragon zu beenden und neu zu beginnen, was
AVRDUDE dadurch erreicht, dass es sich an dieser Stelle beendet.
Danach muss man jedoch nur nochmal das gleiche Kommando eingeben (also
im cmd.exe oder in der Unix-Shell: einmal <Cursor nach oben>, danach
<Enter>), und sofern man zwischendurch nicht am AVR die Spannung
abgeschaltet hatte, funktioniert diesmal der ISP-Modus.

Obiges genanntes Kommando stellt die high fuse auf den Auslieferungs-
zustand zurück, d. h. es wird (u. a.) DWEN abgeschaltet.

Der temporäre ISP-Modus bleibt übrigens bis zum nächsten power cycle
erhalten, danach wird DWEN neu eingelesen und bewertet, um darüber zu
entscheiden, ob debugWIRE zu aktivieren ist oder nicht.  Man ist daher
keinesfalls gezwungen, in diesem temporären ISP-Modus überhaupt die
DWEN-Fuse anzufassen: man kann genausogut einfach ein neues
Flash-Image laden, danach einmal "power cycle", und man kann die
Debugsitzung fortsetzen.  (Geht allerdings vermutlich nicht mit'm AVR
Studio, weil das den Zustand "debugWIRE ist schon aktiv" nicht
verträgt, sondern diesen Zustand partout selbst herbeigeführt haben
will, bevor es damit arbeiten kann.)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Nicht sehr wahrscheinlich. Der richtige Controller ist eingestellt?
> Und wie sieht die Beschaltung vom Reset-Pin aus?

Die Beschaltung vom Reset-Pin war falsch, d.h. der 10k Pullpu Widerstand 
hat gefehlt. Leider ändert es nichts an der Tatsache, dass der 
Controller nicht ansprchbar ist. Beim Versuch in den Debug-Modus zu 
wechseln, kommt jetzt aber der Hinweis, dass SPIEN enabled sein muss.

Ich lade mir mal den AVRDUDE runter und teste es mal aus, ob es so 
funktioniert.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:

> Die Beschaltung vom Reset-Pin war falsch, d.h. der 10k Pullpu Widerstand
> hat gefehlt.

Der Pin hat einen internen Pullup.

> Beim Versuch in den Debug-Modus zu
> wechseln, kommt jetzt aber der Hinweis, dass SPIEN enabled sein muss.

Unsinnige Aussage: wenn ISP nicht geht, lässt sich die Fuse gar nicht
lesen, und die nicht (richtig) gelesene Fuse wird dann als
deaktiviertes SPIEN misinterpretiert (weil vermutlich die Fuses allesamt
als 0xff erscheinen).

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider kommt folgende Fehlermeldung bei Eingabe von
avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m

avrdude: usbdev_open(): Did not find any USB device "usb"

Ich benutzte die Version avrdude gui v0.2.0. Ich habe bis jetzt leider 
noch gar nichts mit dem DUDE gemacht. Unterstützt wird der Dragon schon 
auch unter Windows vom AVRDUDE ?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Leider kommt folgende Fehlermeldung bei Eingabe von
> avrdude -p m168 -c dragon_isp -P usb -U hfuse:w:0xdf:m
>
> avrdude: usbdev_open(): Did not find any USB device "usb"

Hast du die Filter-Version der libusb-win32 installiert?

> Ich benutzte die Version avrdude gui v0.2.0.

Was auch immer das ist.  Was spricht dagegen, das AVRDUDE von
WinAVR zu benutzen?  (Aber auch die bringen den falschen USB-Treiber
mit, den Filter-Treiber muss man m. W. dort trotzdem noch separat
installieren.)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>
> Unsinnige Aussage: wenn ISP nicht geht, lässt sich die Fuse gar nicht
> lesen, und die nicht (richtig) gelesene Fuse wird dann als
> deaktiviertes SPIEN misinterpretiert (weil vermutlich die Fuses allesamt
> als 0xff erscheinen).

Beim Versuch in den Debug-Modus zu wechseln erscheint folgende Meldung:

" Unable to connect to device.
  ...
  For connection issues please press the help button

  xx  Retry debug wire connection
  xx  Use SPI to enable debug Wire interface

Beim Anklick von "Retry debug wire connection" tut sich nichts,
bei Anklick von "Use SPI to enable debug Wire interface" kommt die 
Fehlermeldung:

Failes to enter SPI mode
...
if the SPIEN fuse is not enabled, the part must be programmed using 
high-voltage.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Beim Anklick von "Retry debug wire connection" tut sich nichts

Bist du dir sicher, dass dein debugWIRE jemals funktioniert hat?

Nicht, dass du da am /RESET was versaut hast und debugWIRE läuft
rein gar nicht.  In diesem Falle ist das Setzen der DWEN-Fuse
natürlich purer Selbstmord für den Controller.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Was auch immer das ist.  Was spricht dagegen, das AVRDUDE von
>
> WinAVR zu benutzen?  (Aber auch die bringen den falschen USB-Treiber
>
> mit, den Filter-Treiber muss man m. W. dort trotzdem noch separat
>
> installieren.)

avrdude.exe ist unter den Installationspfad von WINAVR installiert. Wenn 
ich draufklicke erscheint nur kurz ein schwarzes Eingabefeld. Wie kann 
ich das öffnen ? Und wie kann ich libusb-win32 installieren ?

Tut mir Leid um meine blöde Fragen, aber ich kenne mich leider noch 
nicht so gut aus.

Autor: SaschaNoob (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin zwar selber noch Anfänger ... hatte aber mal ein Problem mit den 
gleichen Symptomen ... bei mir hatte ich die Fuse für den externen Quarz 
gesetzt obwohl gar keiner dran war und anschliessend ging garnichts mehr 
... musste den ATmega168 tauschen (die Profis hier hätten bestimmt einen 
Tip gehabt was ich tun kann um den Controller zu retten, da kannte ich 
das Forum aber noch nicht).

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die fuses sind auf einen externen 8Mhz Quarz gesetzt worden, und es ist 
auch wirkliche in 8Mhz Quarz angelötet. UART Kommunikation war ja auch 
einwandfrei möglich. Daran kann's eigentlich nicht liegen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:

> avrdude.exe ist unter den Installationspfad von WINAVR installiert. Wenn
> ich draufklicke erscheint nur kurz ein schwarzes Eingabefeld.

Nicht alles im Computerleben lässt sich anklicken.

Die Kommandozeile schrob ich ja bereits weiter oben, die man dafür
eingeben darf.  Damit du das tun kannst, musst du einen Kommando-
interpreter laufen haben (cmd.exe, im Windows-Jargon auch
fälschlicherweise "MS-DOS-Fenster" genannt, obwohl das seit WinNT
mit MS-DOS nichts mehr gemein hat).

> Und wie kann ich libusb-win32 installieren ?

Indem du den Namen in die Suchmaschine deiner Wahl eintippst, dem
ersten Link zu sourceforge.net folgst und dir dort das Paket lädst
und installierst, das das Wort "Filter" im Namen hat.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Bist du dir sicher, dass dein debugWIRE jemals funktioniert hat?
>
> Nicht, dass du da am /RESET was versaut hast und debugWIRE läuft
>
> rein gar nicht.  In diesem Falle ist das Setzen der DWEN-Fuse
>
> natürlich purer Selbstmord für den Controller.

Also egnau genommen, hat die debugWire Funktion auch mit dieser 
Konstellation funktioniert. Ich habe dW dann nur abgebrochen (so wie es 
sich gehört, mit Umstellung von DebugWire auf Normalbetrieb unter 
AVR-Dragon debug options), weil ich am Programm noch was verändern 
wollte.
Beim zweiten mal kam dann eben die Fehlermeldung und SPIEN wird seitdem 
als disabled angezeigt

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael schrieb:
> Also egnau genommen, hat die debugWire Funktion auch mit dieser
> Konstellation funktioniert.

OK, deshalb muss sie natürlich nicht zuverlässig funktionieren.

Hast du /RESET komplett unbeschaltet gelassen (also direkt zum
ISP-Stecker nur), oder hängt da noch was dran?

Manchmal hilft es noch, an /RESET einen Pullup von 4,7 kΩ oder 10 kΩ
zu klemmen, aber auf keinen Fall dürfen da größere Kapazitäten dran
sein.

> Beim zweiten mal kam dann eben die Fehlermeldung und SPIEN wird seitdem
> als disabled angezeigt

Wobei das eben nur eine glorreiche Fehlinterpretation der Tatsache
ist, dass man im debugWIRE-Modus die Fuse gar nicht erst gelesen
bekommt.  Guck dir doch die Fuses mal als Hexcode an statt auf die
blöden Checkboxes zu sehen, da steht bestimmt 3 x 0xFF drin.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich habe dW dann nur abgebrochen (so wie es
>sich gehört, mit Umstellung von DebugWire auf Normalbetrieb unter
>AVR-Dragon debug options), weil ich am Programm noch was verändern
>wollte.

Es ist wichtig beim Zurückstellen die Meldung:'Platform has been 
disconnected...' abzuwarten.

Zum Ändern des Programms brauchst du nur das Debuggen zu beenden. 
Rückstellen auf ISP ist nicht notwendig. Das neue Programm wird über DW 
geladen.

MfG Spess

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Hast du /RESET komplett unbeschaltet gelassen (also direkt zum
> ISP-Stecker nur), oder hängt da noch was dran?

Oh Mann, an der Reset Leitung hing noch eine I2C-Device dran. Also jetzt 
lässt er sich wieder ansprechen !
Danke für eure Hilfe.

Mit dem Programm AVR-Brenner (eine Ausführung von AVRDUDE mit grafischer 
Bedienoberfläche) habe ich auch die fuses ausgelesen, und natürlich ist 
dort SPIEN gesetzt.

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

ich habe das gleiche Problem wie Michael, nur kann ich mit AVRDUDE 
arbeiten und habe ein ATMega88PA.
Wenn ich die Commandozeile:

avrdude -p m88 -c dragon_isp -P usb -U hfuse:w:0xdf:m
eingebe, erhalte ich folgende Meldung:
: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
: jtagmkII_getsync(): ISP activation failed, trying debugWire
: Target prepared for ISP, signed off.
: Please restart  without power-cycling the target.

Wenn ich im DW Modus versuche zu schreiben kommt folgendes heraus.

C:\WinAVR-20100110\avrdude-5.10>avrdude -p m88 -c dragon_dw -P usb -U 
hfuse:w:0xdf:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.02s

avrdude: Device signature = 0x1e930f
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):

Writing |                                                    | 0% 0.00s 
***failed;
Writing | ################################################## | 100% 
0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading |                                                    | 0% 
0.00savr_read(): error reading address 0x0000
    read operation not supported for memory "hfuse"
avrdude: failed to read all of hfuse memory, rc=-2

avrdude done.  Thank you.

Wie komme ich hier weiter?

Am Reset sind nur 10k, sonst nichts. Debuggen geht auch einwandfrei.

VG Stefan

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun die Problemlösung gefunden.

Es hängt mit dem neuen Update auf den Dragon zusammen.

Wenn es hat funktioniert die DWEN zu deaktivieren, nachdem ich auf eine 
externe Spannungsversorgung umgestellt habe.

There's a bug either in AVRS5 or in the new Dragon firmware which it 
bundles and requires. It manifests while you try to use debugWire with a 
target circuit powered by a Dragon's Vout connector. The problem is, the 
Dragon is cycling its power output after leaving debugWire session 
("Disable debugWire and close") which undoes the temporary disarm of the 
DWEN fuse which, in turn, makes re-enabling the SPI functionality 
virtually impossible without resorting to the not yet supported in AVRS5 
parallel programming (well, to me at least). The problem disappeared 
after I connected an external power source to my target board. Now after 
leaving the dW session, SPI is properly restored automatically


VG Stefan

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Rau schrieb:
> Hallo Jörg,

Sorry, lese ich jetzt erst.


> Wenn ich die Commandozeile:
>
> avrdude -p m88 -c dragon_isp -P usb -U hfuse:w:0xdf:m
> eingebe, erhalte ich folgende Meldung:
> : jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
> : jtagmkII_getsync(): ISP activation failed, trying debugWire
> : Target prepared for ISP, signed off.
> : Please restart  without power-cycling the target.

Ist doch OK.  Hast du die letzte Zeile beherzigt?

"Please restart without power-cycling the target."

Du sollst also bitteschön das exakt gleiche Kommando nochmal
absetzen.  <Cursor nach oben>, <Enter>, fertisch.

> Wenn ich im DW Modus versuche zu schreiben kommt folgendes heraus.

Mist, logisch.  Stell dir den debugWIRE-Modus vor wie ein Stück
fest eingebrannte Firmware: mehr als das, was du aus einer Firmware
zugreifen kannst, kann auch der debugWIRE-Modus nicht.  Breakpoints
macht der, indem die ganze Flash-Page neu geschrieben wird (bzw.
organisiert das JTAG ICE dieses) und dabei ein BREAK-Befehl
eingetragen wird.  Was man von Firmware aus nicht erreichen kann,
kann auch debugWIRE nicht, und insbesondere gehört dazu, dass man
keine Fuses schreiben kann.

Eigentlich ist debugWIRE weiter nichts als ein sogenanntes Monitor-
Programm, wie es früher auf Microcomputern gang und gäbe war.  Daher
hieß das Teil ursprünglich auch "MonCon", den letzten Rest davon
siehst du in der Appnote AVR067 im Kommando "Reset w/ MonCon
disabled", das ist nämlich genau das, was man hier braucht, um aus
debugWIRE zurück zu kommen: einen MCU-Reset, nachdem debugWIRE nicht
mehr aktiv ist, sodass das /RESET-Pin danach für den ISP-Algorithmus
wieder frei ist.

Dummerweise ist das von Seiten des JTAG ICE so organisiert, dass man
sich nach diesem Kommando zwingend vom ICE abmelden und neu dort
anmelden muss.  Das ist der wesentliche Grund, warum ich das in
AVRDUDE so implementiert habe, dass sich dieses normal beendet und
du es von der Kommandozeile neu aufrufen musst.  Das war deutlich
einfacher zu realisieren, als die Mimik zum Ab- und Wiederanmelden
da noch nachträglich ins AVRDUDE zu zimmern (das meldet sich ansonsten
immer genau einmal an und einmal am Ende ab).

Autor: Stefan Rau (stefanrau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

vielen Dank für Deine späte Nachricht. Ich hatte schon befürchtet Du 
ignorierst mich...:-(

Ich habe das Problem gelöst siehe Beitrag vor Deinem..

Danke

Stefan

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr hilfreich! Hätte ich auch selbst drauf kommen können. Dafür weiß 
ich nun, dass doch nichts mit dem Adapter ist.

Andere Sache:
Mit dem ATTiny13A komme ich nicht wieder in den ISP Modus (Atmel Studio 
6). Hab das mit meinen beiden Drachen und mehreren Tinys probiert.
Am Speicher kann es meines Erachtens auch nicht liegen, da ich nur 
diesen übliche "Blinkdings" (allerdings auf dem ganzen PortB) laufen 
ließ.

Für mich nicht schlimm und wer nen Drachen hat, für den kein Problem. 
Dann kommt halt der HVSP Modus zum Einsatz, wenn man das wieder 
umstellen möchte.

Nur so als Hinweis für diejenigen, die auch mal darüber stolpern.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.