8 MHz intern Fusebit & Progammer

[hage]

Hallo Forum,

ich habe das Fusebit für den internen Oszillator von 1 Mhz auf 8 Mhz umgestellt.
Sonst wurde nichts verändert und bis dato wurde der Chip auch immer erkannt.
Nach der Umstellung und einem Reset bekomme ich nun keine Verbindung mehr
Ich habe einen STK200/300 kompatiblen Programmer an der parallelen
Schnitstelle und nutze den Programmer unter Bascom.
Muß hier irgendeine Einstellung verändert werden?

Kann bitte mal jemand helfen
Gruß
hage

 

[dino03]

Hallo Hage,

ich habe das Fusebit für den internen Oszillator von 1 Mhz auf 8 Mhz umgestellt.

welches Fusebit ? "CKDIV8" ?
Ups ... der Mega8 hat anscheinend keine CKDIV8.

Sonst wurde nichts verändert und bis dato wurde der Chip auch immer erkannt.
Nach der Umstellung und einem Reset bekomme ich nun keine Verbindung mehr

Was hast du denn für nen ATmega ? ATmega8 ?
In nem anderen Thread (Timing 1Wire) hast du nen ATmega8 definiert.
Hast du wirklich nur auf 8MHz des INTERNEN Oszillators umgestellt ?

Ich habe einen STK200/300 kompatiblen Programmer an der parallelen
Schnitstelle und nutze den Programmer unter Bascom.
Muß hier irgendeine Einstellung verändert werden?

eigentlich nicht. Sollte so funktionieren wie vorher.

Ich hab mal beim anderen Rechner auf STK200/300 umgestellt und die Fuses für Mega8 angesehen.
Es sollte in etwa folgendes eingestellt sein ...
....Int. RC Osc. 8MHz; Start-up time:.....

Gruß
Dino

 

[hage]

Hallo Dino,

ja, ich setze einen Atmega8 ein.
Ich bin mir zu 99,99 % sicher das ich das
Fusebit KLA987 auf 100100:Int. RC 0sc 8Mhz..........
eingetellt habe.
Ich habe nun einen frischen Atmega eingesetzt und die Verbindung,
nun natürlich im jungfräulichen Mode, ist wieder da.
Würde ja ungern einen zweiten Opfern. Ich setze übrigens einen Nachbau des
Atmel ISP Dongle von RobotikHardware ein.

Noch eine Idee?

Gruß
hage

 

[Markus Eisenberg]

Hi Hage,

wirklich nur das eine Bit?
Ich war mal so dusselig, dass ich schnell mal ein Fusebit setzen wollte und vorher die Fusebits nicht geladen habe.
Ergebnis war dann halt, dass das Ding für die Tonne war.
Ich schreibe überigens mit Avr-OSP II. Wie es bei Bascom ist, weiß ich nicht.
Er verlangte einen externen Oszillator, der nicht dran war und hat sich aufgrunddessen geweigert, mit mir zu reden (was ansich ja schon 'ne Frechheit ist, die mit dem Tode bestraft gehört ).

Ist zwar auch wieder hinzubekommen, aber bei dem Preis hatte ich keine Lust, etwas auf dem Steckboard zu basteln.

Schönen Gruss
Markus

 

[dino03]

Würde ja ungern einen zweiten Opfern. Ich setze übrigens einen Nachbau des
Atmel ISP Dongle von RobotikHardware ein.

Noch eine Idee?

Ja ...
Hast du nen Quarz-Oszillator oder was anderes was dir mit 5V ein Taktsignal
liefern kann ? Dann einfach mal den Takt (250kHz sollten es schon sein) an
den XTAL1/PB6 (Pin 9) anschließen. Wenn es eine falsche Takteinstellung ist
dann sollte er damit wieder erreichbar sein. Man kann auch nen NE555 nehmen
oder was anderes. Irgendwas mit 5V und Takt (Funktionsgenerator, ...)

Hier => Taktversorgung und Wiederbelebung - Der Herzschrittmacher
hab ich die Wiederbelebung mit nem externen Oszillator beschrieben.

Gruß
Dino

 

[hage]

So nun verteh ich gar nichts mehr! Ob es an der Umstellung auf Winterzeit liegt?
Ich habe nun den neuen Atmega, nach einem Refresh, in dem Fusebit
KLA987 auf 100100:int RC Osc. 8Mhz eingestellt. Danach den Button Write FS
gedrückt. Anschliesen Refresh und es bleibt bei der Einstellung 8Mhz. Controllerboard von Spannung genommen, also Reset.
Im Quellcode auf 8 MHz umgestellt, compiliert und Programm übertragen.
Dann Fusebit ausgelesen und erstaunlicher Weise steht darin wieder 1Mhz intern!?
1. Sollt ich wirklich beim ersten, nun nicht mehr ansprechbaren, Atmega ein falsches Bit gesetzt haben?
2. Wieso übernimmt der µC die Einstellung nun nicht ?

@Dino das mit dem ext. Takt probiere ich bei Gelegenheit

Gruß
hage

 

[dino03]

Dann Fusebit ausgelesen und erstaunlicher Weise steht darin wieder 1Mhz intern!?
1. Sollt ich wirklich beim ersten, nun nicht mehr ansprechbaren, Atmega ein falsches Bit gesetzt haben?
2. Wieso übernimmt der µC die Einstellung nun nicht ?

könnte es sein das Bascom da aus irgendwelchen Menüs, ...
Einstellungen für die Fuses holt und beim Proggen schreibt ?
Sach mal einer was dazu ...
Ich nehm den AVRISPmk2 und schreib meine Fuses mit dem AVR-Studio
(oder früher mit PonyProg).

Gruß
Dino

 

[Darkstar]

@dino,
also nach meiner Erfahrung nicht. Aber im Programmierfenster, da
wo man bei BASCOM die Fusebits einlesen und ändern kann, da
hab ich mich auch schon schusseldusselig angestellt und zu hastig
die Writebuttons geklickt.
Als Ursache dafür würde ich die etwas unübersichtlich gestalteten Aufrollmenüs in den Zeilen zu den einzelnen
Bits sehen, die nach meinem Geschmack etwas zu hektisch auf Mouse-
moves reagiert, zB. wenn man nach korrekter Auswahl der Taktung den
Mauszeiger etwas ungeschickt über's Menü zurückschiebt .
Dann kann versehentlich eine falsche Einstellung "erwischt" werden .
Ansonsten geht eigentlich nur noch das Fusebit-Setzen mittels Zeile
im Programmcode, was (angeblich?) alle anderen Einstellungen überschrei-
ben soll. Hab ich aber noch nicht ausprobiert.
Grüssle
Wolfgang

 

[Darkstar]

Ergänzung:
für Takt-verfuselte AVR-Patienten hab ich in der Bastelkiste nen
Quarzoszillator im vierpoligen Blechgehäuse, so einer wie sie früher
auf Mainboards und diversen Netzwerkkarten verbaut waren. Der
schwingt mit 1 MHz und braucht nix ausser 5VDC an einem Pin, GND
an einem diagonal gegenüberliegenden und liefert nen astreinen Takt
an einem dritten Pin (Belegung siehe Datenblatt). Das Teil auf einer
kleinen Mini-Lochrasterplatine mit drei Strippen und ran
an den Patienten...
Ich glaub' die Dinger gibt's noch bei Reichelt.

Grüssle
Wolfgang

 

[hage]

Hallo,

ich hab die Ursache gefunden, das Problem steckt wie so oft zwischen den Ohren.

Die Einstellung der Fusebits wird definitv von den Einstellungen im Quellcode überschrieben.
Ich habe wohl irgendwann im Bascom, in dem Fenster 'Fuse-Einstellung', den Button 'Write Prg' gedrückt.
Damit fügt man eine Zeile mit Einstellung der Fuse Bit (als Hex-Zahl) in den Quellcode ein.
Die Zeile wird an die Stelle eingefügt, an dem der Cursor geade steht. Das war in meinem Fall
irgendwo mitten im Quellcode und somit nicht so auf dem ersten Blick zu erkennen.
In dieser Zeile wurde in meinem Fall wieder von 8 Mhz auf 1 Mhz umgestellt.
Im Prinzip finde ich diese Möglichkeit ganz sinnvoll. Ich werde mir angewöhnen
diese Einstellungen zukünftig am Programmanfang im 'define' mit festzulegen.

@Darkstar
Ja, ich mußte auch feststellen das die Einstellung im Fuse-Bit Menue
etwas 'hektisch' reagiert. Eine Scroll-Maus verstärkt dies zusätzlich.
Ich habe beim ersten Versuch wahrscheinlich dadurch eine nicht gewollte
Einstellung verursacht.
Ein Rettungsversuch mit externem Takt steht noch aus. Übrigens könnte dies bei Zeiten
wichtig werden, weil, wie bei vielen vielen anderen elektronischen Komponenten,
Lieferengpässe bestehen (DIL-Ausführung).

Vielen Dank für Eure Unterstützung
hage

 

[Markus Eisenberg]

Hi Hage,

Übrigens könnte dies bei Zeiten wichtig werden, weil, wie bei vielen vielen anderen elektronischen Komponenten, Lieferengpässe bestehen (DIL-Ausführung).

ist zwar OT, aber die Lieferengpässe scheinen langsam wieder rückläufig zu sein.
Mein Dealer hat Anfang letzten Monats noch von 1. Quartal '11 gesprochen, wurde aber kürzlich beliefert.

Schönen Gruss
Markus

 

[dino03]

Hi zusammen,

so ne Schnellrettung wegen falscher Takteinstellung ist ungeheuer sinnvoll.
Wenn kein Quarzoszillator vorhanden ist, einfach nen NE555 wie in meinem
Thread zusammenbasteln. Wenn man Rb noch zusätzlich mit nem Poti
erweitert (zB eins mit 10-100k in Reihe) dann kann man das kleine Ding
sehr schön als Taktquelle für allen möglichen Kram verwenden.

ist zwar OT, aber die Lieferengpässe scheinen langsam wieder rückläufig zu sein.

ich hab hier glaube ich noch genug Typen mit genug Stückzahlen für die
nächsten 80 Projekte liegen Alles was das Bastlerherz begehrt
Wenn ich genausoviel Zeit wie Atmels hätte wär das schon ne super
Angelegenheit

Gruß
Dino