Forum: Mikrocontroller und Digitale Elektronik AVR-ISP mkII programmierung: Fusebits


von Fusebitnoob (Gast)


Lesenswert?

Hallo zusammen,
ich habe vor einigen wochen den wohlbekannten Fehler mit den Fusebits 
gemacht: Bei Versuch den µC auf externen quarz zu stellen habe ich 
ausversehen externen oszillator gewählt... beim versuch danach alles 
wieder hinzubiegen wahrscheinlich noch einigen anderen mist verzapft... 
meine frage nun:

Ich programmiere mit AVR Studio und dem AVR ISP mkII - wie setze ich die 
einstellungen zurück (damit ich nicht noch mehr µCs "schrotte") oder: 
Wie müssen die lock-/fusebits konfiguriert sein, wenn man einen tiny13 
oder mega16 (beide habe ich hier in verwendung) "standard"flashen will 
(also mit internem oszi und auf "werkseinstellungen"?

Vielen Dank für jede Hilfe!

von Fusebitnoob (Gast)


Lesenswert?

... was mir auch sorgen bereitet, ist, dass beim auslesen der bits vom 
µC im informationsfenster auch "leaving program code" steht (obwohl ich 
nur "read"e)... und danach die bits schon wieder konfiguriert sind?

von Oliver (Gast)


Lesenswert?

???

Solange man die Fuses nicht verstellen will, verstellen die sich auch 
nicht. Wenn das neue Prozessoren sind, lass die einfach, wie sie sind.

Oliver

von Fusebitnoob (Gast)


Lesenswert?

das ist das merkwürdige, ich dachte auch ich müsste für jeden µC die 
fusebits (wenn ich sie denn ändern will) neukonfigurieren, habe jetzt 
aber den eindruck die konfiguration ist im ISP adapter eingestellt und 
wird beim ersten mal fusebits auslesen eines neuen µCs auch 
draufgeschrieben - und schon hat auch der die einstellung auf externen 
oszillator zu takten...
so ist es zumindest gerade wieder mit einem attiny13 passiert, den ich 
lediglich angeschlossen habe und dessen fbits ich per "read" überprüfen 
wollte..

von Fusebitnoob (Gast)


Lesenswert?

ich programmiere über ein elf file- und habe fuses- und lockbits-häkchen 
deaktiviert. trotzdem werden die, sobald ich zum  µC neuconnecte wieder 
als aktiviert angezeigt (auch wenn ich das elf file vorher 
neuspeichere). genauso wie eben auch IMMER das fusebit für externen 
clock gesetzt ist, egal wie ich es verstelle oder eben fusewriting 
deaktiviere... und der nächste µC lässt sich nicht mehr programmieren.

Hilfe.

von Fusebitnoob (Gast)


Angehängte Dateien:

Lesenswert?

und so siehts aus..

von Fusebitnoob (Gast)


Lesenswert?

keine antworten weil
1. die frage so doof ist
2. niemand weiß wie man es löst
3. ich mein problem zu ungenau geschildert habe?

von Oliver (Gast)


Lesenswert?

4. keiner die Frage versteht?

Was passiert bei dir wann mit den Fuses?

Eigentlich funktioniert das alles wie folgt:

Wenn du ein Programm flashen willst, flash das mit dem program-Button im 
Abschnitt "Flash".

Wenn du ein EEprom flashen willst, flash das mit dem  program-Button im 
Abschnitt "EEPROM".

Wenn du die Fuses auslesen willst, lies die mit dem Read-Button auf dem 
Tab "Fuses".

In all diesen Fällen passiert nur genau das, was da steht. An den Fuses 
ändert das alles überhaupt nichts.

Wenn du die Fuses flashen willst, flash die mit dem program-Button auf 
dem Tab "Fuses".

Wenn du ein elf-Production-File hast, das Flash, EEPROM, und Fuses in 
einem enthält, dann flash das mit dem dem program-Button im Abschnitt 
"Elf production file format". Allerdings würde mich dann interessieren, 
wie du das .elf-File dafür erstellt hast :-)
Die Häkchen dort betreffen nur das auslesen, nicht das programieren.

Oliver

von Fusebitnoob (Gast)


Lesenswert?

hallo oliver, danke für die antwort!
ich verstehe ja leider selbst nicht was passiert, tatsache ist:
ich platziere den tiny 13
stecke den isp adapter an
versuche ihn zu flashen und bekomme einen "ISP Mode Error", den ich von 
meinem fusebitmalheur gewohnt bin, nachdem der atmega16 damals nur noch 
auf externen clock gewartet hat.
Den ISP takt habe ich auf 2MHz.

warum ich dachte, dass alles miteinander zusammenhängt, ist mein 
unwissen über das "how to fusebit setzen" - ich dachte nach meinen 
missgeschicken ich würde lieber sichergehen wollen und die fusebits 
überprüfen. daher also bei allen µCs die ich danach angeschlossen habe 
einmal "read" und jedes mal als SUT_CKSEL "Ext. Clock; Start-up time: 
14CK+0ms" bekommen - obwohl der tiny ja werksmäßig auf internem oszi 
laufen sollte...

:(

von Fusebitnoob (Gast)


Lesenswert?

zum ELF: auch hier scheint mein unwissen durch - ich habe damals einfach 
angefangen immer das ELF zum µC programmieren zu nehmen, weil ich nicht 
wusste, wann eeprom und wann flash beschrieben wird.  das elf wird bei 
mir beim compilen mit avrstudio wie das hex automatisch erzeugt.

von Micha B. (mbcontrol)


Lesenswert?

Fusebitnoob schrieb
> Den ISP takt habe ich auf 2MHz.

Ich kann Dein Problem auch nicht nachvollziehen. Machs doch einfach mal 
so wie Oliver es beschrieben hat. Frisch vom Werk sind die µC's normal 
auf Intern 1MHZ eingestellt (zumindest die Atmegas mit denen ich bisher 
gearbeitet habe 8/16/32). Dabei ist zu beachten, dass der ISP-Takt nur 
1/4 vom CPU-Takt haben darf, also max. 250 kHz. Wenn Du also einen neuen 
µC nimmst und unter Main die ISP-Frequenz auf 250 kHz einstellst, dann 
im Bereich Flash das hex-File abschickst, dürfte das von Dir 
beschriebene Problem eigentlich nicht auftreten. Probier mal das und geh 
auf keinen Fall vorher zu den Fuses ;-) Auch nicht zum Auslesen. Erst 
nachher wenn Du das Ding zum ersten mal geflasht hast. Schaun wir mal 
was dann passiert ...
Also lass das mal mit dem ELF.


Gruß MB

von Oliver (Gast)


Lesenswert?

Fusebitnoob schrieb:
> das elf wird bei
> mir beim compilen mit avrstudio wie das hex automatisch erzeugt.

Da wird zwar ein .elf erzeugt, das ist aber kein vollständiges "elf 
production file".

Egal, solange das auslesen der Fuses nicht fehlerfrei funktioniert, 
kannst du alles andere vergessen. Bei einer fehelrhaften Verbindung 
zwischen Programmer und Target oder falschen parametern es kein Wunder, 
wenn da ungewollt Fuses übershcrieben werden.

Fusebitnoob schrieb:
> Den ISP takt habe ich auf 2MHz.

Das ist für einen fabrikneuen AVR, der in Werkseinstellung mit 1MHz 
läuft, viel zu viel.

Oliver

von Fusebitnoob (Gast)


Lesenswert?

in ordnung ich drehe heute den takt noch einmal auf 250kHz runter und 
probiere es nochmal - wenn ich nun den tiny auf 9,6MHz laufen lassen 
will, muss ich doch "nur" bei den fuses unter clock select genau diese 
auswählen und alles andere in ruhe lassen, dann fuses programmieren 
oder?

Grüße

von Peter D. (peda)


Lesenswert?

Erste Aktion ist immer: Signatur lesen.

Wenn die nicht stimmt, ist jede andere Aktion zwecklos.


Peter

von Micha B. (mbcontrol)


Lesenswert?

Fusebitnoob schrieb:
> in ordnung ich drehe heute den takt noch einmal auf 250kHz runter und
> probiere es nochmal - wenn ich nun den tiny auf 9,6MHz laufen lassen
> will, muss ich doch "nur" bei den fuses unter clock select genau diese
> auswählen und alles andere in ruhe lassen, dann fuses programmieren
> oder?
>
> Grüße

Du bist schon wieder bei den Fuses, bevor Du überhaupt sicher sein 
kannst, ob Du eine funktioniernede Verbindung zum µC hast. Vergiss das 
doch erstmal. Lass den Tiny mit seinen Int. 1MHz arbeiten - so wie er 
vom Werk kommt. Wenn dann alles prima funktioniert mit dem Flashen, dann 
kannst Du dich um die externe Taktung kümmern. Das ist doch jetzt 
erstmal garnicht wichtig.

Und wie Peter es gesagt hat:
1.) ISP-Frequenz auf 250 kHz
2.) Read Signature

Wenn das funktioniert, dann gehts weiter. Vorher nicht!

Gruß MB

von Fusebitnoob (Gast)


Lesenswert?

ok, also das hex file flashen mit dem ISP auf 250kHz funktioniert, das 
war also dann schon einmal ein fehler, der behoben ist.

"Read Signature" ergibt eine Warnung: "Signature does not match selected 
device.
Ich habe als device oben drüber aber den ATtiny13 angegeben. Ein problem 
könnte darstellen, dass ich ihn auf einem modifizierten pollin "Atmel 
Evaluationboard" v2.01 auf dem platz für tiny12/15 stecken habe (13 wird 
dort nicht aufgeführt) -  nachdem ich die pinbelegung überprüft hatte 
und der meinung war sie sei dieselbe dachte ich aber das sein 
unerheblich.. ist es offensichtlich aber nicht?

von Micha B. (mbcontrol)


Lesenswert?

Fusebitnoob schrieb
> ok, also das hex file flashen mit dem ISP auf 250kHz funktioniert, das
> war also dann schon einmal ein fehler, der behoben ist.

juhu. Mach mal "Verify" um zu vergleichen, ob das was er geflasht hat 
auch richtig angekommen ist und mit Deinem Programm auf dem Rechner noch 
übereinstimmt.

> "Read Signature" ergibt eine Warnung: "Signature does not match selected
> device.

Bedeutet, dass der gesteckte µC nicht der ist, den Du angegeben hast. Es 
gibt doch den ATtiny13 und ATiny13A. Probier mal beide aus.

> Ich habe als device oben drüber aber den ATtiny13 angegeben. Ein problem
> könnte darstellen, dass ich ihn auf einem modifizierten pollin "Atmel
> Evaluationboard" v2.01 auf dem platz für tiny12/15 stecken habe (13 wird
> dort nicht aufgeführt)

Wenn die PINs gleich sind, dürfte das meiner Meinung nach nichts machen.

Gruß MB

von Fusebitnoob (Gast)


Lesenswert?

ARGH
jetzt habe ich exakt das selbe gemacht wie eben (hex file flashen) und 
bekomme wieder den error.
dann von AtTiny13 auf AtTiny13A gestellt, immernoch error.

Dann einen anderen reingesetzt - flashen klappt.
Verify -> ERROR
Erneut flashen -> ERROR...

das verhalten hatte mich ja dahin verleitet zu denken es würde 
automatisch bockmist mit den fuses gemacht...

ich verstehe das nicht... :(

von Micha B. (mbcontrol)


Lesenswert?

Fusebitnoob schrieb:
> ARGH

Also ich denke Du hast eine schlechte Verbindung zwischen Programmer und 
µC.

Du schreibst weiter oben:
> Ein problem könnte darstellen, dass ich ihn auf einem modifizierten pollin > 
"Atmel Evaluationboard" v2.01 ...

Was bedeutet denn modifiziert? Was wurde an dem Board modifiziert?

Ich würde an Deiner Stelle mal das ganze ohne dem Pollin-Board testen. 
Also den ATtiny mit dem Programmer frei oder auf einem Steckbrett 
vedrahten.

MB

von holger (Gast)


Lesenswert?

>Also ich denke Du hast eine schlechte Verbindung zwischen Programmer und
>µC.

Oder ne wacklige Spannungsversorgung.

von Fusebitnoob (Gast)


Lesenswert?

modifiziert heißt nur, dass ich auf die isp buchse des boards einen 
adapter gebaut habe, weil die 10 pins (in einer anderen belegung) hat 
als der 6 pin ISP Adapter... das passt aber, habe vorher damit ja auch 
schon erfolgreich geflasht und gerade noch einmal alles auf 
wackelkontakte durchgepiept.

der isp connected ja auch mit dem controller.. das ist das merkwürdige 
und zeigt über die led keinerlei probleme an..

ich glaube deshalb nicht, dass es mit dem verdrahten zu tun hat, grad 
weil es ja den anschein macht, dass es mit neien controllern immer das 
erste mal klappt. ich habe blos langsam keine lust mehr die dinger zu 
"himmeln", irgendwann gehts aufs geld..

um das zu überprüfen werde ich jetzt noch genau einen neuen reinstecken 
- und von allem anderen die finger lassen...dann sollte das ja 
ausgeschlossen sein, wenn es auf anhieb funktioniert..

von Peter D. (peda)


Lesenswert?

Fusebitnoob schrieb:
> Bei Versuch den µC auf externen quarz zu stellen habe ich
> ausversehen externen oszillator gewählt...

Das war kein Versehen.
Schau mal ins Datenblatt, beim ATtiny13 kann man keinen Quarz auswählen!


Peter

von Fusebitnoob (Gast)


Lesenswert?

so mit dem neuen (baugleichen attiny13)
kann ich
- flashen
- signature lesen (match)
- verifyen

und zwar mehrmals.
ich habe diesmal einen test gemacht, und zwar einen anderen code (leere 
main funktion) geflasht, weil ich den verdacht hatte, es könnte daran 
liegen.
Sollte das so sein, hätte ich seeehr starkes interesse daran, zu 
erfahren WIESO?!

ich habe versucht ein programm zu flashen, das mir jörg wunsch vor 
einiger zeit gepostet hatte (der große codebeitrag):

Beitrag "Knobelei: Zufallsgenerator"

kann da irgendeine eigenart des codes (auf 9,6MHz ausgelegt) in 
verbindung mit den 1Mhz werkseinstellungen zu diesem problem führen? Oo

von Micha B. (mbcontrol)


Lesenswert?

Na wegen dem sind Deine µC ja nicht gehimmelt. Wenn Dein Problem mal 
gelöst ist, kannst Du die ja wieder verwenden.

Hast Du nicht die Möglichkeit das mal ohne dem Pollin-Board aufzubauen? 
Wenn Du jetzt nochmal einen reinsteckst, wird sich vermutlich nichts 
ändern. Also solltest Du das Problem ja mal eingrenzen. Ich würde jetzt 
einfach mal das Board weglassen.

MB

von Fusebitnoob (Gast)


Lesenswert?

hallo peter, sorry my fault: ich meinte clock, nicht oszillator.

von Fusebitnoob (Gast)


Lesenswert?

ok, ich denke ich habe das problem gefunden... wenn der code einmal 
drauf ist, läuft der prozessor im "sleep"(?) auf "einigen 10khz"... für 
die sind dann ja auch die 250kHz (die beim ersten mal flashen un 1Mhz 
passen) viel zu viel...
habe jetzt einmal mit 6,25 KHz geflasht... und zwar erfolgreich einen 
der alten controller, die nicht mehr reagiert haben...
NICHTS MIT FUSEBITS, alles die programmiergeschwindigkeit.. meine güte, 
das kommt davon, wenn man keine ahnung hat.

ersteinmal herzlichen dank an alle, die mir soweit geholfen haben! ich 
wär esonst nicht drauf gekommen.

dann wäre es jetzt noch enorm interessant für mich, wie das mit den 
fusebits ein für alle mal funktioniert. wenn ich den attiny13, der mit 
1mhz kommt, auf internen 9,6 MHz laufen lassen will - was genau tun? nur 
den bei den fusebits den "int rc osz 9,6Mhz" auswählen (sonst nichts 
verändern) und fusebits schreiben?

Bitte 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
Noch kein Account? Hier anmelden.