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.
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?
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
Erste Aktion ist immer: Signatur lesen. Wenn die nicht stimmt, ist jede andere Aktion zwecklos. Peter
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
>Also ich denke Du hast eine schlechte Verbindung zwischen Programmer und >µC. Oder ne wacklige Spannungsversorgung.
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
hallo peter, sorry my fault: ich meinte clock, nicht oszillator.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.