Fuse-Bits der Megas und Tinys (Übersicht und Erklärung)

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Hallo zusammen,

es wird mal Zeit eine kleine Sammlung der Fuse-Bits zu machen damit man
weiß welches Bit welche Funktion hat und wo man besser die Finger von
lassen sollte.

Als erstes werde ich mal einfach eine Liste aufführen von den Bits, die ich
in den Datenblättern der Megas und Tinys gefunden habe. Ich habe die Bits
ein wenig in Gruppen zusammengefaßt damit sie ihrer Funktion entsprechend
schneller zu finden sind.

Aber nun erst mal die Liste der gesammelten Bits mit Name, Defaultwert und
englischer Kurzinfo aus den Datenblättern ...

=== Reset, Watchdog und BrownOut ===

RSTDISBL Select if PC6 is I/O pin or RESET pin
1 (unprogrammed, PC6 is RESET-pin)

BODEN Brown out detector enable
1 (unprogrammed, BOD disabled)

BODLEVEL Brown out detector trigger level
1 (unprogrammed)

BODLEVEL2 Brown-out Detector trigger level
1 (unprogrammed)

BODLEVEL1 Brown-out Detector trigger level
1 (unprogrammed)

BODLEVEL0 Brown-out Detector trigger level
1 (unprogrammed)

WDTON WDT always on
1 (unprogrammed, WDT enabled by WDTCR)


=== Startup-Time ===

SUT1 Select start-up time
1 (unprogrammed)

SUT0 Select start-up time
0 (programmed)


=== Systemtakt ===

CKOPT Oscillator options
1 (unprogrammed)

CKSEL3 Select Clock source
0 (programmed)

CKSEL2 Select Clock source
0 (programmed)

CKSEL1 Select Clock source
0 (programmed)
1 (unprogrammed) (bei vorhandenem CKDIV8-Bit)

CKSEL0 Select Clock source
1 (unprogrammed)
0 (programmed) (bei vorhandenem CKDIV8-Bit)

CKDIV8 Divide clock by 8
0 (programmed)

CKOUT Clock output
1 (unprogrammed)


=== Systemschnittstellen ===

SPIEN Enable Serial Program and Data Downloading
0 (programmed, SPI prog. enabled)

OCDEN Enable OCD
1 (unprogrammed, OCD disabled)

JTAGEN Enable JTAG
0 (programmed, JTAG enabled)

DWEN debugWIRE Enable
1 (unprogrammed)


=== Bootloader ===

BOOTSZ1 Select Boot Size (see Table 82 for details)
0 (programmed)

BOOTSZ0 Select Boot Size (see Table 82 for details)
0 (programmed)

BOOTRST Select Reset Vector
1 (unprogrammed)

SPMEN Self Programming Enable
SELFPRGEN Self Programming Enable
1 (unprogrammed)


=== Speicherschutz ===

EESAVE EEPROM memory is preserved through the Chip Erase
1 (unprogrammed, EEPROM not preserved)

NVLB2 Non-Volatile Lock Bit
1 (unprogrammed)

NVLB1 Non-Volatile Lock Bit
1 (unprogrammed)

LB1 Lock bit
1 (unprogrammed)

LB2 Lock bit
1 (unprogrammed)

BLB01 Boot Lock bit
1 (unprogrammed)

BLB02 Boot Lock bit
1 (unprogrammed)

BLB11 Boot Lock bit
1 (unprogrammed)

BLB12 Boot Lock bit
1 (unprogrammed)


=== Kompatibilität ===

M103C ATmega103 compatibility mode
0 (programmed)

M161C ATmega161 compatibility mode
1 (unprogrammed)

S8515C AT90S4414/8515 compatibility mode
1 (unprogrammed)

S8535C Select AT90S8535 compatibility mode
1 (unprogrammed)


Das sind soweit alle Fuse-Bits die ich aus meiner Datenblatt-Sammlung
rausholen konnte. Für den ersten Überblick reicht es schon mal. Die genaue
Erklärung der einzelnen Bits kommt dann später :D

Nach dem, was ich so gefunden habe sind die Default-Werte in allen Atmels
identisch. Wenn man sich also mal total verrant hat kann man kontrollieren
wo es denn haken könnte ;)

Wer es selber nachlesen will ... in den vollständigen Datenblättern unter
"Memory Programming" und dann "Programm and Data Memory Lock Bits"
bzw "Fuse Bits" ist alles gesammelt zu finden.

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Einen Link hab ich schon einmal vorweg ...
rn-wissen - AVR (Abschnitt: Die_Fusebits)
da kann man schon ein wenig nachlesen.

Nun zu den Bits von denen man besser die Finger läßt ...
RSTDISBL und SPIEN
wenn man die verstellt kommt man nur noch über die HV-Programmierung an
den Atmel dran. Das wird aber bei eingelöteten (vor allem bei SMD) Chips recht
schwierig werden. Wenn man Pech hat geht es in Richtung Elektronikschrott.

Wenn man sich aus versehen die Taktquelle verstellt, dann kann man über
eine Zwangsversorgung mit einem externen Oszillator den Atmel wiederbeleben.
Das passiert vor allem, wenn man auf externen Oszillator oder externes RC-Glied
umstellt. Alles andere ist über einen extern angeschlossenen Quarz schnell
wieder in Ordnung zu bringen.

Das erst einmal als grobe Anhaltspunkte. wie gesagt ... genauere Infos
folgen noch.

Ich habe mittlerweile erfahren das man auch von der DWEN-Fuse die Finger
lassen sollte ... mikrocontroller.net - DebugWIRE
Die Aktivierung des debugWIRE-Modus erfolgt durch das Setzen (also Programmieren auf den Bitwert 0) der DWEN-Fuse, die normalerweise im high fuse byte zu finden ist. Ab diesem Moment steht der /RESET-Pin nicht mehr für seine normale Reset-Funktion zur Verfügung, daher lässt sich dann auch das ISP-Protokoll nicht mehr nutzen.
Gruß
Dino
 

Darkstar

Mitglied
15 Okt 2009
91
0
6
Sprachen
Hallo Dino,

ich glaub ich drucke mir das gleich mal aus und kleb's mir an die Wand
in der Bastelecke :D .

Wie oft hab ich schon (unnötig) rumgegrübelt, wenn's mal wieder nicht so
wollte wie ich :confused:
Dabei wars meist nur die eigne Dussligkeit, weil man eins der Fusebits ver-
murkst hat.
Klasse, diese Aufstellung :wavey:
für gelegentliche Programmierer wie mich so wichtig wie ne R-Farbcodetabelle
für Gelegenheits-Elektroniker :D

Grüssle
Wolfgang
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Grundlegende Sachen über die Fuse- und Lock-Bits

Dann wolln wir mal ...

zuerst eine wichtige Info: Wenn man nicht genau weiß woran man da schraubt
dann sollte man die Finger davon lassen. Wenn man hier etwas falsch macht
dann erzeugt man im schlimmsten Fall Elektroschrott. Das ist besonder bitter
wenn es sich um einen aufgelöteten Atmel im 100pin-TQFP-Gehäuse handelt
der auf einer Platine eines Roboters sitzt. Dann heißt es entweder zum Hersteller
einschicken oder aber in die Tonne mit dem teuern Stück. Also lieber dreimal
kontrollieren und erst dann auf OK drücken!

Außerdem sollte man die Bits zuerst einlesen, dann ändern und erst dann
schreiben wenn man wirklich sicher ist das alles paßt. Auf keinen Fall einfach
den Brenndialog aufmachen, ändern und dann schreiben. IMMER !! IMMER !!
zuerst die Bits einlesen.


Manche der Bits werden sofort aktiv wenn sie übertragen werden und manche
erst nach einem Reset. Da aber beim Verlassen des Schreibvorganges der
Atmel zwangsweise einen Reset auslößt werde auch diese Bits beim Click auf
Write für den Anwender eigentlich auch sofort aktiv. Wenn der Schreibvorgang
zum Atmel verlassen wird, geht der Reset-Pin wieder auf High und damit läuft
der Atmel auch los und übernimmt alle Fuse- und Lock-Bits.
Das kann man
auch nicht unterbinden. Man kann die Fuses oder Lock-Bits nicht "ein bischen
schreiben". Das wär so wie "ein bischen schwanger" entweder man hat sie
geschrieben oder nicht. Also vorher denken!

Hier einmal die Fenster beim AVR-Studio wenn man an einen ATmega32 hat ...
AVR-Studio_Fuses_M32.png AVR-Studio_LockBits_M32.png
das sind die aktuellen Einstellungen eines bereits programmierten Mega32.

BASCOM_Fuses-LockBits_M32.png PonyProg_Fuses-LockBits_M32.png
und das sind die Dialoge von BASCOM und PonyProg um an den Fuses und
Lock-Bits rumzuschrauben. Es wurde immer der selbe ATmega32 benutzt.
Dadurch kann man gut die unterschiedliche Darstellung der Bits erkennen und
vergleichen.

Wenn die Bits irgendeine ungewöhnliche Kombination aufweisen (zB alle auf
Null oder alle auf Eins) dann sollte man unbedingt die Verbindung vom PC zum
Progger und von dem zum Atmel untersuchen. Erst den Kopf einschalten und
dann erst auf Write klicken! Und wie schon im zweiten Beitrag erzählt ... Die
Finger weg von RSTDISBL und SPIEN ! Sonst schießt man sich selber ins Knie.

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Fuse-Bits für Systemschnittstellen

Jetzt erst einmal zu den Bits, an denen wohl die meißten nix rumschrauben
werden (eher abschalten ;) ). Es geht um folgende Bits ...

SPIEN (Serial Program and Data Downloading Enable)
Dieses Bit sollte immer auf Null (programmiert) stehen damit man sich nicht
den Ast absägt auf dem man sitzt. Wenn man dieses Bit löscht (auf Eins
setzt), dann kommt man nicht mehr über einen normalen ISP-Programmer an
den Atmel heran. Dann geht nur noch die HV-Programmierung zB mit dem
STK500 oder die Programmierung über JTAG wenn es denn freigegeben ist.
Also Finger weg !

OCDEN (On Chip Debugging Enable)
Das geht nur in Verbindung mit freigegebenem JTAG und wenn alle Lockbits
gelöscht sind. Es darf also kein Speicherbereich geschützt sein. Die genaue
Funktion sollte man sich im Datenblatt nachlesen wenn man es denn mal
benötigt. Das wird aber wohl eher unwahrscheinlich sein ;) Per default ist es
deaktiviert und stört damit auch nicht.

JTAGEN (JTAG Enable)
Joint Test Action Group (kurz JTAG) ist eine Schnittstelle mit der man direkt
in den Chips arbeiten kann. Man kann sie über diese Schnittstelle programmieren
aber auch einen sogenannten Booundary-Scan durchführen. Über diesen
Scan kann man die Ein-/Ausgabepins schalten und einlesen und damit dann
die angeschlossene Hardware testen, Platinen auf Fehler untersuchen oder
bestimmte Situationen in einer Schaltung simulieren. In den meißten Fällen
stört uns diese Schnittstelle aber leider bei der Arbeit. Also wenn man sie
nicht wirklich benötigt, dann sollte man sie abschalten (Bit auf 1 = gelöscht).
Andernfalls werden die Pins dieser Schnittstelle nicht für den normalen Betrieb
freigegeben. Das sind zB beim Mega16/32 TDI/PC5 , TDO/PC4 , TMS/PC3 ,
TCK/PC2. Wenn die Hardware an diesen Pins also nicht so arbeitet wie man
es erwartet dann sollte man an diese Fuse denken und sie abschalten.


DWEN (debugWIRE Enable)
Das ist eine Schnittstelle für einen Emulator der über den Reset-Pin arbeitet.
Wer es benötigt (wird wohl eher sehr selten sein) sollte es sich genau im
Datenblatt nachlesen. Ich hab es noch nie gebraucht oder damit gearbeitet
und kann darum auch nichts weiter drüber schreiben. Da es aber per default
deaktiviert ist stört es auch nicht weiter. Es sollte auch deaktiviert bleiben!
Wie weiter oben beschrieben steht sonst die normale Reset-Funktion und
damit auch die ISP-Schnittstelle nicht mehr zur Verfügung
.

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Fuse-Bits für Reset, BrownOut und WatchDog

hier kommt noch was ...

RSTDISBL (Reset Disable)
Dieses Bit sollte immer auf Eins (nicht programmiert) stehen. Wenn man dieses
Bit aktiviert dann kann der Reset-Pin als zusätzlicher IO-Pin verwendet werden.
Das wär bei 28poligen Atmels (Mega8,48,88,168,328,..) zB PC6, bei 8poligen
(Tiny11,12,13,..) PB5 , bei 14poligen (Tiny24,44,84,..) PB3 und beim 20poligen
Tiny2313 PA2. Danach ist der Chip aber über ISP NICHT mehr zu programmieren.
Man sollte eher einen größeren Chip einsetzen als diese Spielerei zu machen.
Bei einer Serienfertigung würde ich das noch verstehen aber beim Hobby
ist das meiner Meinung nach totaler Blödsinn.

BODEN (Brown Out Detection Enable)
Das sollte nach meiner Meinung nach immer eingeschaltet werden um einen
sauberen Reset zu gewährleisten. Also auf Null (programmiert) setzen. Damit
erkennt der Prozessor dann selber wenn die Betriebsspannung unter einen
eingestellten Wert absackt und stoppt alle Arbeiten. Das ist auch wichtig für
sichere Daten im EEPROM. Man verhindert das ein Amok laufender Atmel die
Daten im EEPROM vernichtet.

BODLEVEL / BODLEVEL0..2 (Brown Out Ddetection Level)
Über diese Bits kann man den Schwellwert der Brown-Out-Detection auf
eine bestimmte Spannung einstellen. Je nach Prozessor sind ein oder mehrere
Bits vorhanden und damit 2 oder mehrere Schwellwerte. Beim Mega8 ist das
zB mit einem Bit nur zwischen 2,6V und 4,0V umzustellen. Beim Mega48,88,..
läßt es sich zB zwischen 1,8V, 2,7V und 4,3V umstellen. Hier lohnt ein Blick
ins Datenblatt um Gewissheit zu haben.

WDTON (Watchdog Timer always on)
Damit schaltet man den Wachhund schon beim Start ein. Meiner Meinung
sollte man das beim Testen und Lernen per Software machen. Sonst kann
es einem passieren das der Prozessor andauernd neu startet weil man den
Watchdog-Timer nicht richtig oder zu spät anspricht. Also erst mal langsam
rantasten.

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Fuse-Bits für Systemtakt und Startup-Time

SUT0, SUT1 (Start-Up Time)
Mit diesen beiden Fuses wird eingestellt wie lange nach einem Reset, Power
Down oder Power Save der Prozessor noch angehalten bleibt um erst einmal
stabile Verhältnissse einkehren zu lassen. Für die genauen Werte sollte man
das Datenblatt lesen da sie teilweise zwischen den verschiedenen Typen
etwas unterschiedlich sein können.

CKSEL0..3 (Clock Select)
Mit diesen Bits stellt man den Arbeitsmodus des Oszillators ein. Also womit
er den Takt erzeugt und wo er den Takt herhohlt. Dabei gelten folgende
Begriffe ...
  • External Ceramic Resonator - Ein extern angeschlossener Keramikresonator
    günstig aber nicht sehr frequenz- und temperaturstabil
  • External Crystal Resonator - Ein extern angeschlossener Quarz
    etwas teurer aber dafür relativ frequenz- und temperaturstabil
  • Calibrated Internal RC Oscillator - man benötigt keine externe Beschaltung.
    Die Frequenz läßt sich ein wenig kalibrieren. Stabilität? Naja. Schwingt ;)
  • External RC Oscillator - Einfach ein Widerstand und ein Kondensator an
    den Oszillatorpins. Stabilität? Egal! Es schwingt ;)
  • External Clock - Eine externe Taktquelle (Quarzoszillator, anderes IC, ...)
Je nachdem was man also an den Pins des Oszillators anschließt muß man an
diesen Fuses drehen. Wenn man hier was falsches einstellt steht die CPU im
schlimmsten Fall und der Atmel läßt sich nicht programmieren. Das kann man
aber durch den Anschluß einer externen Taktquelle am Pin XTAL1 beheben.
Damit zwingt man dem Atmel einen Takt auf und man kommt wieder an ihn
heran. Für genaue Infos gilt auch hier ... Datenblatt lesen ;)
Clock-Rescue.JPG
Hier ist mal mit dem grünen Draht ein externer Quarzoszillator für so eine
Widerbelebung am XTAL1 angeschlossen und zwingt dem Atmel den externen
Takt auf.
Die volle Beschreibung mit Schaltungen für Taktquellen ist
hier => Taktversorgung und Wiederbelebung - Der Herzschrittmacher


CKDIV8 (Clock Divided by 8)
Mit dieser Fuse wird der Oszillatortakt erst einmal durch 8 geteilt und dann
erst für den Prozessor verwendet. Das heißt also bei 16MHz, das der Atmel
nur mit 2MHz läuft wenn diese Fuse programmiert (auf 0 gesetzt) ist. Ein
gern gesehener Fehler wenn der Timer oder UART mal wieder nicht so will
wie man es ausgerechnet hat
:D

CKOPT (Clock Option)
Durch diese Fuse wird zwischen zwei verschiedenen Verstärkungsmodis des
Oszillator umgeschaltet. Wenn sie programmiert ist (auf 0) dann wechselt
der Ausgang des Oszillators zwischen beiden Betriebsspannungsgrenzen
(GND und Vcc - das nennt man Rail-to-Rail). Dieser Modus ist für Umgebungen
mit starken Störeinstrahlungen oder wenn man den Ausgang des Oszillators
an ein weiteres IC anschließen will. Zum Beispiel für eine Versorgung eines
andern ICs mit einem Takt. In diesem Modus steht auch ein weiter Bereich
in der Taktfrequenz zur Verfügung. Wenn man die Fuse dagegen auf 1 setzt
(unprogrammiert) dann wird der Ausgangsspannungsbereich begrenzt. Dabei
spart man zwar Strom ein aber man kann keine anderen ICs mehr mit dem
Ausgang des Oszillators versorgen und der nutzbare Frequenzbereich wird
auch kleiner.

CKOUT (Clock Output)
Mit dieser Fuse kann man bei manchen Prozessoren den CPU-Takt auf einen
Ausgangspin legen. Damit geht natürlich die normale IO-Funktion dieses
Pins verloren. Es wird dabei am Pin CLKO genau der Takt ausgegeben der
auch dem Prozessor zur Verfügung steht. Also mit allen Einstellungen von
CKDIV8 usw.

Hier noch einmal ein paar Bildchen vom Oszillator und der externen und
internen Beschaltung.
AVR_HW-Basics.png

Eine Fuse möchte ich im Moment etwas vorziehen. Und zwar ...
M103C (ATmega103 compatibility mode)
Diese Fuse ist beim Mega128 per default programmiert und spuckt einem in
die Suppe. Als erstes sollte man also bei einem neuen Mega128 diese Fuse
auf 1 setzen (löschen).


Die restlichen Bits kommen irgendwann später dran. Die wichtigsten Fuses
sind jetzt beschrieben und der Rest muß nur in besonderen Fällen verändert
werden. Zum Beisppiel bei einem Bootloader oder wenn man das geladene
Programm gegen Auslesen oder Überschreiben schützen will. Also erst einmal
im Datenblatt nachlesen wenn man genaueres wissen will. ;)

Ich hoffe mal, die Infos sind soweit verständlich und kurzweilig rübergekommen :D

Hier noch ein Beitrag in einem anderen Forum über die Fuse-Bits ...
mikrocontroller.net - AVR Fuses

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Ein HV-Programmer ohne Prozessor

Hallo,

jetzt hab ich ja genug über die Fuses geredet. Für diejenigen, die sich den
Atmel so verdreht haben das man nur noch über die HV-Programmierung
drankommt hab ich zufällig was gefunden :D

Aufbau eines high-voltage Programmers für Atmel MCs
Für den Fall das die Seite mal verschwindet habe ich alles runtergezogen ;)

Und hier noch die Original-Seite ...
http://elm-chan.org/works/avrx/report_e.html

Die Seite elm-chan.org lohnt sich sowieso ;) Schaut mal hier ...
Home Built Laser Projector
Ich habs vor über nem Jahr mal per Zufall gefunden. Total Irre !! :D

Gruß
Dino
 

hemmerling

Neues Mitglied
5 Okt 2011
1
0
1
58
Hannover, Germany
Sprachen
Hallo,
ich habe seit kurzem als Atmel-Neueinsteiger zur Verfügungg

a)
Hardware
Board
“Atmel AVR XMEGA-A3BU Xplained kit”

JTAGICE3 Hardware-Debugger
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=17213&category_id=163&family_id=682&subfamily_id=2138

b)
Software
Atmel Studio 5
http://www.atmel.com/avrstudio

FLIP
http://atmel.com/dyn/products/tools_card.asp?tool_id=3886

c)
Software
mit dem mitgelieferten ( umgelabelten) WinAVR GNU-CCC Compiler,
sowie ASF
http://asf.atmel.com/

und habe die Fuse-Bits noch nie gesehen, als Option.

Bei Website-Screenshots über ( andere Compiler in deren ) Programmier-Tools aber schon.
Beispiel:
http://www.mikrocontroller.net/topic/93632
http://www.mikrocontroller.net/attachment/32445/checksum.png

Fragen
1.
a) KANN ich mir das Board durch Setzen/Löschen von FUSE-Bits so verderben, daß es selbst mit JTAGICE3 Debugger nicht mehr ansprechbar und damit nicht neuprogrammierbar ist ?
b) Also DURCH den JTAGICE3 Debugger ?
c)wenn ja in welchem Options-Menü bei Atmel Studio 5 ( oder gar bei Flip, das ja nicht über JTAGICE3 funkt sondern über USB ) ?
d) Durch ein weiteres Programmiertool ?

2.
oder durch normalen Programmiercode den ich flashe ?!

Was DARF ich also NICHT machen ( insbesondere sobald ich mal C/C++ ohne AVR oder gar Assembler selber den Initialisierungs-Code schreibe ) ?
.. ein Ratschlag, hier gelesen und natürlich bekannt "erstmal die Bits als Bytes lesen und dann nur maskieren",
aber natürlich kann auch das schiefgehen..

3.
Tja warum ist bei beiden Tools AFAIK das Thema Fuse ausgeklammert ?
Warum funktionieren sie aber offensichtlich trotzdem ausreichend gut für kommerzielle Projekte ( Atmel Studio5 + JTAGICE3 sind ja "Flagschiff-Produkte" und kein Kleinkram für Atmel ) ?
Was geht mir als Nutzer (trotzdem) verloren im Vergleich zu dem

Viele Grüße
Rolf
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Hi Rolf,

Hardware
Board “Atmel AVR XMEGA-A3BU Xplained kit”
den XMega kenne ich allerdings überhaupt noch nicht. Da müßte dann mal ein anderer seine Erfahrungen zu schreiben.

1.
KANN ich mir das Board durch Setzen/Löschen von FUSE-Bits so verderben, daß es selbst mit JTAGICE3 Debugger nicht mehr ansprechbar und damit nicht neuprogrammierbar ist ?
Also DURCH den JTAGICE3 Debugger,
wenn ja in welchem Options-Menü bei Atmel Studio 5 ( oder gar bei Flip ) ?
Mit JTAG hab ich hier noch nichts gemacht. Allerdings schalte ich wegen den benötigten Pins das JTAG beim Mega32 immer ab. Damit ist er dann auch nicht mehr mit JTAG programmierbar. Nur noch mit ISP und HV-Parallel.

2.
oder durch normalen Programmiercode den ich flashe ?!
eigentlich nicht. Man kann ein paar Fuse-Einstellungen im Betrieb "überschreiben". Also sozusagen die Voreinstellung die beim starten aus den Fuses geladen wird nachträglich ändern. Ich wüßte aber nicht das man durch Flashen des Programmcodes in das Flash die Fuses ändern könnte. Manche Programmer schieben aber je nach Einstellung beim Programmiervorgang automatisch neben dem Programmcode auch die EEPROM-Daten und die Fuses mit rüber. Das sind aber im Controller verschiedene Bereiche. Man muß also aufpassen was man für den Programmiervorgang aktiviert hat um nicht aus versehen doch die Fuses mit zu ändern.

Was DARF ich also NICHT machen ( insbesondere sobald ich mal C/C++ ohne AVR oder gar Assembler selber den Initialisierungs-Code schreibe ) ?
.. ein Ratschlag, hier gelesen und natürlich bekannt "erstmal die Bits als Bytes lesen und dann nur maskieren",
aber natürlich kann auch das schiefgehen..
Durch das Programm selber kannst du dir die Fuses nicht zerschießen. Wenn der Compiler allerdings Direktiven aus dem geschriebenen Programm interpretiert und dann deinen "Wunsch" der Fuse-Einstellungen für dich automatisch mit zum Controller schiebt, dann kannst du sie sozusagen durch die Hintertür ändern. Das geht zB auch in Bascom das man im Programmtext angibt wie die Fuses des Controllers für dieses Programm eingestellt werden sollen.

3.
Tja warum ist bei beiden Tools AFAIK das Thema Fuse ausgeklammert ?
Warum funktionieren sie aber offensichtlich trotzdem ausreichend gut für kommerzielle Projekte ( Atmel Studio5 + JTAGICE3 sind ja "Flagschiff-Produkte2 und kein Kleinkram für Atmel ) ?
Was geht mir als Nutzer (trotzdem) verloren im Vergleich zu dem
AtmelStudio5 hab ich bei mir noch nicht installiert (aber schon auf Platte). Beim Studio4 und bei Bascom stellst du die Fuses ja über einen eigenen Reiter im Programmierdialog ein. Normalerweise sind die Fuses ja auch nur für die Vorbereitung des Controllers und die Anpassung an die umliegende Hardware einmalig einzustellen. Also zB für die Oszillatoreinstellung für den angeschlossenen Quarz, die Spannungsschwelle für den Reset, usw. Danach ändert man bei der Programmentwicklung und der Fehlersuche eigentlich nur noch den Flash-Inhalt und den EEPROM-Inhalt.

Gruß
Dino
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Hallo,

ich hab grad ne Anfrage bekommen und da es mit Sicherheit auch andere interessiert und man in den PNs keine Anhänge dranpacken kann schreib ich es mal in den passenden Bereich ;)

Es geht um folgendes Projekt ... Neosoft Funktionsgenerator

Laut Schaltplan sind beide Atmels über einen Quarzoszillator versorgt.

Also was ist mit den folgenden Fuse-Bits los ...

TINY2313: -U lfuse:w:0xc0:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
MEGA8515: -U lfuse:w:0xc0:m -U hfuse:w:0x59:m

Auf der Seite gibts auch einen Link zu Engbedded Atmel AVR® Fuse Calculator

Zuerst mal zum Tiny2313. Füttert man die Hex-Zahlen C0 , DF , FF rein dann bekommt man folgendes raus ...
Tiny2313_fuses.jpg

Nun zum Mega8515. Dort sind die Hex-Zahlen C0 , 59 angegeben ...
Mega8515_fuses.jpg

Es fällt auf das wegen dem Quarzoszillator natürlich beide Atmels auf External Clock gesetzt sind. Wenn man also keinen externen Takt anlegt, dann stellen sich die beiden Atmels nach der Programmierung tot. Es ist also zwingend notwendig den QuarzOSZILLATOR (kein! normales Quarz) an die Atmels an den entsprechenden Pin XTAL1 (siehe Schaltplan) anzulegen. Dann leben die Atmels auch wieder.

Es ist genau das Phänomen was in diesem Thread bei der Wiederbelebung durch eine externe Taktquelle beschrieben ist.

Gruß
Dino
 

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
*ausbuddel*

Wenn man sich aus versehen die Taktquelle verstellt, dann kann man über
eine Zwangsversorgung mit einem externen Oszillator den Atmel wiederbeleben.
Das passiert vor allem, wenn man auf externen Oszillator oder externes RC-Glied
umstellt. Alles andere ist über einen extern angeschlossenen Quarz schnell
wieder in Ordnung zu bringen.
Wenn du / ihr jetzt eine non+ultra Lösung zum Reanimieren machen wollen würdet (ohne HV), bräuchte es doch einen Quarz und einen Oszillator (wahlweise), oder?


p.S.: Kleine Addition zum Ursprungsthread: Sollte jemand DebugWire nutzen, niemals im PRR Register das SPI deaktivieren. Sonst ist auslöten angesagt ;)
 

dino03

Aktives Mitglied
27 Okt 2008
6.716
16
38
Sprachen
BascomAVR, Assembler
Hi,

Wenn du / ihr jetzt eine non+ultra Lösung zum Reanimieren machen wollen würdet (ohne HV), bräuchte es doch einen Quarz und einen Oszillator (wahlweise), oder?
nein. Muß man nicht. Ob man nun aus versehen RC oder Quarz oder Resonator oder externe Taktquelle eingestellt hat ist total egal.
Einfach den internen Oszillatoreingang X1 mit einem externen Takt von der externen Blechkiste (Quarzoszillator) versorgen und gut ist.
Geht immer.

Gruß
Dino
 
  • Like
Wertungen: TommyB

TommyB

Team Bitschubse
Premium Benutzer
17 Mai 2010
2.151
80
48
36
127.0.0.1 ;)
Sprachen
C#, VB.Net, LunaAVR, Assembler, Python
Ah, ok, gut zu wissen, danke :)
 

Hicki

Mitglied
25 Feb 2009
44
2
8
54
Sangerhausen/OT Grillenberg
Sprachen
BascomAVR
Hallo,

ich habe ein Mega2560 board. Ich möchte die Fusebit´s mit Bascom AVR ändern. Speziell die Fusebit High I (von 1 auf 0)der Eeprom soll nicht immer mit gelöscht werden.
Es ist aber so, dass die Fusebit immer wieder in den Originalzustand (auf 1) gestellt werden.
Was mache ich falsch?

Gruß Hicki
 

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.344
61
48
Marwitz
Sprachen
BascomAVR, Assembler
Ähem... Das sind Fusebytes also mit je 8 Bit...
Beim Mega2560 sind die Bits 7..0 des HighBytes:
OCDEN | JTAGEN | SPIEN | WDTON | EESAVE | BOOTSZ1 | BOOTSZ0 | BOOTRST

Hast Du mal versucht, das mit dem AVR-Studio (oder ATMEL-Studio) nachzuvollziehen?
 
  • Like
Wertungen: Hicki

LotadaC

Sehr aktives Mitglied
22 Jan 2009
3.344
61
48
Marwitz
Sprachen
BascomAVR, Assembler
ISP heißt In System Programming. Du meinst SPI, also daß über das Serielle Periphäre Interface (quasi 'ne Kommunikationsschnittstelle) programmiert wird.

ISP sagt ja eher was über Deine Schaltung aus, daß der Controller nicht zum programmieren aus dieser entfernt werden muß. Prinzipiell könnte man das ja auch bei HVPP (parallele Programmierung mit 12V-Reset) umsetzen - auch wenn das wegen den vielen genutzten I/Os und den 12V auf Reset eher wenig Sinn macht/kompliziert wird.

Grundsätzlich können Flash und EEPROM der meisten(*) AVR sowohl zur Laufzeit durch den Controller selbst, als auch während eines ... ähm ... "Programmierzustandes" beschrieben werden. Dieser Zustand wird durch einen bestimmten Reset (LV- oder HV-Reset usw) ausgelöst, und dann durch eine bestimmte Kommandosequenz auf der entsprechenden Kommunikationsschnittstelle initiiert.

Das EEPROM kann der AVR zur Laufzeit über bestimmte I/O-Register beschreiben (wenn die nicht via Fuses geschützt sind), für Schreibzugriffe auf den Program Flash gibts in den meisten(*) Controllern die SPM-Instruktion.

Die Fusebytes (und auch die Lockbytes) hingegen können nur "von außen" über einen der "Programmierzustände" beschrieben werden.
(Meine nächste Frage an Dich wäre übrigens genau deswegen gewesen, über welche Programmierschnittstelle Du gehst - auch wegen "board", ich kenn ja nur das Datenblatt vom Controller selbst - aber Du hast es ja selbst herausbekommen).
Allerdings legen einige(!) Fusebits nur bestimmte Initialisierungszustände für entsprechende I/O-Register fest. Zur Laufzeit kann das Programm diese I/O-Register aber umschreiben (die CKDIV8-Fuse zB bewirkt, daß der System Clock Prescaler (Clock Prescaler Select Bits (CLKPS) im Clock Prescale Register (CLKPR)) mit dem Teiler 8 initialisiert wird - da kann das Programm zur Laufzeit auch diverse andere diskrete Teiler reinschreiben - zB 1 oder 256. Es gibt auch Controller, bei denen so sogar das Umschalten der Clock Source möglich ist.)

Mir persönlich ist kein AVR bekannt, der USB direkt als Programmierschnittstelle nutzt. (Allerdings hab ich mich mit den USB-AVR noch nicht auseinandergesetzt). Dein Mega2560 selbst besitzt auch keine USB-Schnittstelle. Also muß die Schnittstelle entweder komplett in Software realisiert sein (="von innen"), oder über einen externen Wandler von USB auf eine andere Schnittstelle. Diese "andere Schnittstelle" könnte AVR-seitig jetzt auch wieder in Software realisiert sein (="von innen"), oder ein Hardware-Interface nutzen.
Genutzte Hardware-Interfaces könnten zB der (TTL-)UART oder das TWI sein (="von innen"), denkbar wäre aber auch ein Wandler von USB auf SPI, womit man "von außen" Zugriff hätte (benötigt auch Reset-Zugriff) - also auch auf die Fuses/Locks.

Es gibt Wandler-ICs, die quasi mehrere USB-Endpunkte darstellen, und diese (Endpunkte) dann auf irgendwas Wandeln. "Was" kann USB-seitig vorgegeben und umgeschaltet werden; möglich ist dann neben UART oder Bitbanging (8Bit pro Endpunkt) auch SPI, TWI und JTAG
(siehe FT2232H, FT4232H, MPSSE).

(*) Nicht alle Controller unterstützen SPM, und sind somit zur Programmierung "von innen" über einen Bootloader fähig. Bei vielen (aber nicht allen) SPM-fähigen AVR arbeitet SPM auch nur aus einem bestimmten Flash-Bereich heraus (wo dann logischerweise der Code des Loaders stehen muß).

Auf JTAG, dWire usw geh ich jetzt nicht weiter ein, dWire kann AFAIK nur die eigene dWire-Enable-Fuse zurücksetzen (korrekt, Thomas?).
Bei XMEGAs gibts PDI, bei einigen Tinies TPI statt SPI als Programmierschnittstelle "von außen".

Am Rande: Der Tiny11 (Urvater des Tiny13) ist nicht über SPI programmierbar und kennt SPM nicht. Der kann nur HVSP. Ursprünglich war sogar ein Tiny10 (der nichts mit dem Tiny4/5/9/10 zu tun hat) geplant (taucht nur in der A und B-Revision des Datenblattes auf, und hat keinen Ordering-Code), der nur einmal via HVSP beschreibbar gewesen wäre.

Ich hoffe jetzt mal, daß das nicht zusehr vom Thema abgewichen ist...
LotadaC
 
  • Like
Wertungen: Hicki

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)