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?
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?
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.
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?
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 ?!
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.
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
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
> ... 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.
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.
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.
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.
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.
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).
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.
"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."
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.
SUT_CKSEL.PNG
(65 KB)
