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!
... 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?
???
Solange man die Fuses nicht verstellen will, verstellen die sich auch
nicht. Wenn das neue Prozessoren sind, lass die einfach, wie sie sind.
Oliver
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..
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.
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
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...
:(
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.
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
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
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
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
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?
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
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... :(
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
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..
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
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
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
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?
