Attiny25 fuses SUT_CKSEL hängen uC von IDE ab

[Wulf D. (holler)]

Bin gerade am verzweifeln bei einer eigentlich recht trivialen Sache: 
möchte an einem Atmel Attiny25 auf den langsamen, internen 128 kHz Takt 
umschalten.
Sollte mit fuse SUT_CKSEL = 0100 nach Datenblatt zu setzten sein. Nutze 
für das Miniprojekt noch das uralte AVR Studio mit einem JTAGICE mkII. 
Darin sind die Fusebit verklausuliert über eine Dropbox auszuwählen.
Eigentlich bequem, aber jetzt habe ich mit der Einstellung „WD. Osc 
128khz ...“ schon den zweiten Chip abgehängt: was mache ich nur falsch?
Den zweiten AVR habe ich nur noch nackt über SPI, Power und Reset 
angebunden, ohne Schaltung drumrum.
Der Verify nach dem Fuse Schreiben geht noch durch, anschließend ist der 
Chip nicht mehr erreichbar. Bin ratlos.
Einstellung siehe Attachment.
Ist doch kein externer Takt, oder?

[Peter D. (peda)]

128kHz / 8 / 4 = 4kHz.
D.h. mit einem ISP-Takt <4kHz kommst Du wieder dran.

[Wulf D. (holler)]

Hey super, vielen Dank!
Klappt.

[Wulf D. (holler)]

Beim Laden eines kleinen Programms bzw schon beim Umschalten auf 
Debug-Wire habe ich den uC nochmals abgehängt:

- Mini-Program assembliert.
- Laden-Knopf in der Atmel Studio 4 IDE gedrückt
- Popup, ob Umschalten auf debug wire, ok
- hat umgeschaltet. Hinweis Target Power down / up.
- Betriebsspannung ab/angeklemmt, jetzt geht nichts mehr :-(

IDE neu gestartet und und USB ab/an bringt auch nichts.
Siehe Bild. Habe mir die Reset-Leitung angesehen, da sieht man nur einen 
ca 78ms langen Puls. Mehr nicht.
Der SPI_Mode geht natürlich auch nicht mehr. Was könnte das sein?

[Stefan F. (Gast)]

Die Debug Wire Fuse bleibt permanent aktiv.

Du kannst den Debugger starten (egal mit welchem Quelltext) und darin 
nach dem Verbindungsaufbau den Debug Modus beenden. Folgendes passiert 
dabei:

Der Debugger kann ein Kommando absetzen, dass den Debug Modus temporär 
beendet. Würdest du jetzt die Stromversorgung aus und wieder an machen, 
wärst du schon wieder im Debug Modus.

In diesem temporär beendeten Debug Modus ist der Mikrocontroller wieder 
per ISP ansprechbar. Und darüber kannst du dann die DWEN Fuse wieder aus 
schalten.

Irgendwo habe ich mal gelesen, dass avrdude diese Prozedur ggf. 
automatisch durchgeht. Du musst dafür aber auf jeden Fall einen 
Programmieradapter verwenden, die das DebugWire Protokoll sprechen kann 
(hast du ja) und du darfst keinen Kondensator am Reset Pin haben.

[Wulf D. (holler)]

Ich möchte ja in den Debug Modus, habe es aber aus einem mir unbekannten 
Grund nicht geschafft und hänge jetzt irgendwie zwischen den Stühlen: 
weder debugwire noch SPI gehen jetzt.
Versuche ich den Debuger zu starten, kommt das Fenster im Bild:
„Retry debugWIRE Connection“ oder „Use SPI ...“.
Beides führt zum Fehler.
Hatte zuvor nur den Takt via SPI auf 128k intern umgestellt.
Dann wollte ich per debugwire weitermachen.
Ach ja, hatte erst einen 2n2 am Reset dran, ist jetzt entfernt. Pullup 
ist keiner dran.
Ob der 2n2 beim Umschalten auf Debug Wire einen irreversiblen Zustand 
verursacht hat?

[Stefan F. (Gast)]

Wulf D. schrieb:
> Ob der 2n2 beim Umschalten auf Debug Wire einen irreversiblen Zustand
> verursacht hat?

Kann ich mir nicht vorstellen.

[Wulf D. (holler)]

Ist es wohl auch nicht: habe einen neuen tiny25 quasi nackt nur mit Akku 
und Abblock-C an die Debugger gepackt. Wieder Fuses für internen Takt 
gesetzt, ging. Dann mal direkt im JTAGICE mkII Fuse Menü die DWEN Fuse 
gesetzt: schreiben inclusive verify fehlerfrei, anschließend war der 
Chip wieder unerreichbar. Debugwire geht einfach nicht.
Weiß jemand wie der Signalverlauf am Resetpin grob aussehen müsste?
Nehme an, der 78ms low-Puls kommt vom Debugger und anschließend sollte 
sich der Chip melden ?!

[Wulf D. (holler)]

Nochmal einen neuen Chip in den nackten Adapter gepackt und diesmal den 
Takt auf 8 MHz intern (default) belassen und direkt in den debugwire 
Mode geschaltet: hat funktioniert!
Wieder zurückgeschaltet in SPI Mode, ging auch.
Takt via Fuse Bits auf 128khz, ok.
Wieder debugwire aktiviert, Chip ist tot.
Mist, so langsam lohnt ein High-Voltage-Adapter.

Habe aber absolut keine Idee was hier schief geht. Denke eigentlich, 
dass ich früher schon erfolgreich Tinys mit  128 kHz und debugwire 
erfolgreich in genau der Konfiguration betrieben habe.

[Wulf D. (holler)]

Sorry, sollte heißen internen 128khz-Takt. Default sind 8 MHz.
Das Teil sollte doch auch mit 128 kHz im debugwire Mode laufen?!

[Stefan F. (Gast)]

Vielleicht musst du irgendwo in der IDE die 
Kommunikationsgeschwindigkeit einstellen. DebugWire scheint mit FCPU/128 
getaktet zu sein. Also in deinem Fall extrem langsame 1 kHz.

Probiere avrdude mit -B200

[Georg M. (g_m)]

Bei der Umstellung auf 128kHz: CLKDIV8 entfernen.

[Stefan F. (Gast)]

Ach ja, dann also avrdude mit -B1600

Wie weit kann man da eigentlich gehen?

[Wulf D. (holler)]

Herzlichen Dank, es war die CKDIV8 Fuse in Verbindung mit 128kHz 
internen Takt und debugwire. Das sollte man unbedingt vermeiden, hängt 
den Chip vom Debugger ab.
Ohne CKDIV8 funktioniert es!
Ob das irgendwo in der Doku steht?
Hat mein Bastelprojekt gerade so gerettet, war der vorletzte Chip in der 
Stange.
Mit dem letzten baue ich mal den improvisierten HV-Fuse Resetter nach, 
vielleicht rette ich damit meine fünf verfuseten Tinys:
https://www.hackster.io/sbinder/attiny85-powered-high-voltage-avr-programmer-3324e1

[S. Landolt (Gast)]

> ... vielleicht rette ich ...

Ist das 'High-voltage Serial Programming' wirklich nötig? Ich hätte 
gedacht, man kommt mit dem normalen 'Serial Downloading' weiter, wenn 
nur der Takt langsam genug ist.

[Peter D. (peda)]

Wulf D. schrieb:
> Ohne CKDIV8 funktioniert es!

Man kann den Teiler auch später im Programm einschalten. Wenn man das 
nach 60s macht, hat man genug Zeit, vorher den Programmer zu starten.

[Wulf D. (holler)]

S. Landolt schrieb:
>
> Ist das 'High-voltage Serial Programming' wirklich nötig? Ich hätte
> gedacht, man kommt mit dem normalen 'Serial Downloading' weiter, wenn
> nur der Takt langsam genug ist.

Ehrlich gesagt, weiß ich nicht genau was passiert ist. Ich denke die 
DebugWIRE Fuse wurde erfolgreich vom Debuger via SPI gesetzt, aber der 
dann zu niedrige interne Takt im uC verletzt das Protokoll. Ist aber nur 
spekuliert.
Man kommt definitiv nicht mehr an den Chip ran, weder per SPI noch 
Debugwire.

Klar, könnte auch die CKDIV8 per SW setzen. Oder ich passe den Code so 
an, dass der Vorteiler unnötig wird.

Habe gerade gesehen, der verlinkte Resetter ist Arduino-Code. Schade, 
habe keine Umgebung dafür.

[Wulf D. (holler)]

Vielleicht noch in dem Zusammenhang interessant, ein erfolgreicher Start 
des Debuggers über debugWIRE. Am Reset-Pin aufgezeichnet. Wie im 
Fehlerfall, fängt es mit einem 78ms langen low-Puls an. Anschließend 
geht's dann aber höherfrequent weiter.

[Stefan F. (Gast)]

Ich hatte auch mal einen ISP Programmieradapter der an 128 kHz / 8 
scheiterte. Doch zum Glück bot mir der Hersteller wenige Wochen nach der 
Problem-Meldung ein passendes Firmware-Upgrade an.

[S. Landolt (Gast)]

Das ist wohl nicht das Problem, sondern die DebugWIRE-Fuse schaltet den 
Reset-Pin für das normale 'Serial Downloading' ab (wie ich eben auch 
erst feststellen musste).

[Stefan F. (Gast)]

S. Landolt schrieb:
> Das ist wohl nicht das Problem, sondern die DebugWIRE-Fuse
> schaltet den Reset-Pin für das normale 'Serial Downloading'
> ab (wie ich eben auch erst feststellen musste).

Darum ging es in meinem Beitrag 
Beitrag "Re: Attiny25 fuses SUT_CKSEL hängen uC von IDE ab"

[Wulf D. (holler)]

Na, ich glaube nicht das ein anderer „Programmieradapter“ hilft: man 
sieht doch, dass auf den die Debug-Session einleitenden 78ms Puls im 
Fehlerfall keine weitere Reaktion folgt: der uC macht einfach nichts 
mehr.

[S. Landolt (Gast)]

"If the system clock is changed by software (e.g. by writing CLKPS bits) 
communication via debugWIRE may fail. Also, clock frequencies below 
100kHz may cause communication problems."

[Wulf D. (holler)]

Ok, Fuse CKDIV8 setzt den CLKPR, den system clock Vorteiler, auf Teiler 
8.
Das war's dann wohl, 16 kHz sind zu wenig.

[Peter D. (peda)]

Kannst Du mal erklären, warum Du 16kHz brauchst und nicht mit 128kHz 
arbeiten kannst?

[Wulf D. (holler)]

Ich kann auch mit 128 kHz arbeiten, habe das Programm minimal angepasst.
Mir war nur die Problematik mit dem CKDIV8 und debugwire nicht bewusst 
und bin in diese Falle gelaufen.
Das Debugger-Fuse-Menü hat alle Optionen bereitgehalten - und mich dem 
Setzen ausgesperrt.