Habe mir das Datenblatt vorgenommen und diese Einstellungen gefunden:
Fuse Wert (hex) Bedeutung
BODCFG 0x05 Brown-Out Detection aktiv bei 2,7 V, im aktiven Modus (ACTIVE), bei voller Frequenz sicher
SYSCFG0 0x46 UPDI aktiv (nicht Reset), EESAVE=1 (EEPROM bleibt
erhalten), CRCSRC=00 (kein CRC), Reserved = 110
SYSCFG1 0x06 SUT = 16 ms → sichere Startzeit nach Reset oder Power-On
APPEND 0x00 Keine App-Schutz-Sektion (Standard, wenn kein Bootloader genutzt wird)
BOOTEND 0x00 oder 0x02 Kein Bootloader → beide Werte sind akzeptabel. 0x00 = ganzes Flash ist App-Bereich. 0x02 reserviert 512 Bytes, aber ungenutzt.
TCDCFG 0x00 TCD0 Clock Config: Standard, unbenutzt, keine besondere Konfiguration notwendig
WDTCFG 0x00 Watchdog Timer deaktiviert
Habe versucht es als Tabelle darzustellen. Mal sehen ob es klappt.
Sind diese Werte korrekt?
Habe die entsprechenden Seiten noch mal durchgearbeitet und kontrolliert. Du hast vollkommen Recht. Bin wohl mit der Reservierten Teilen durcheinander gekommen. Jedenfalls stimmen (hoffentlich) die Werte jetzt.
BODCFG 0x44 Brown-Out Detection aktiv bei 2,7 V, im aktiven Modus
(ACTIVE), bei voller Frequenz sicher
OSCCFG 0x02 20 MHz interner Oszillator, keine Frequenzteilung
SYSCFG0 0xF7 UPDI aktiv (nicht Reset), EESAVE=1 (EEPROM bleibt
erhalten), CRCSRC=00 (kein CRC), Reserved = 110
SYSCFG1 0x06 SUT = 16 ms → sichere Startzeit nach Reset oder Power-On
APPEND 0x00 Keine App-Schutz-Sektion (Standard, wenn kein Bootloader
genutzt wird)
BOOTEND 0x00 Kein Bootloader → beide Werte sind akzeptabel. 0x00 =
ganzes Flash ist App-Bereich. 0x02 reserviert 512 Bytes, aber ungenutzt.
TCDCFG 0x00 TCD0 Clock Config: Standard, unbenutzt, keine besondere
Konfiguration notwendig
WDTCFG 0x00 Watchdog Timer deaktiviert
warum schreibst du nicht womit du wie die Fuses liest und schreibst?
Jetzt muss man raten. Du verwendest doch Microchip Studio? Dort gehst du unter Device Programming und kannst an den Einstellungen rumspielen. Dort wird alles angezeigt.
Ja ich verwende Microchip Studio. Bin aber mit den Einstellungen sehr
vorsichtig geworden weil ich mich bei anderen Prozessoren ausgesperrt
habe
Das Umrechnen von eingebetteten Bits in einem Byte mit Offset sollte man können und wenn man darin nicht versiert ist, kann man das üben, bis man es kann, denn das ist auch beim Codeschreiben ziemlich wichtig und wird einem immer begegnen, auch das Hexadezimalsystem ist erlernbar, dieses Üben sollte man aber am besten nicht mit Fuses in echt machen, denn genau dann droht ein Szenario des Ausperrens, insbesondere dann, wenn man blind mit irgendwelchem „Werkzeug” ausgerechnete Bytewerte in den µC schiebt, was man leider oft unter den Jüngern des sogenannten Mainstreams beobachten kann. Wenn man allerdings mit dem richtigen Werkzeug wie beispielsweise Atmel-Studio-7 und MK2- oder Snap-Programmer arbeitet, sind solche Umrechnereien und Experimente gar nicht nötig, denn dort wird alles aufgeschlüsselt und beschrieben dargestellt – alle Änderungen werden auch unten zusätzlich automatisch als Bytezahlen dargestellt, d.h. jede Häkchenänderung wird unten sofort sichtbar, weil sich die Bytewerte ändern. Das passiert schon vor der Programmierung der Fuses, d.h. man kann vieles durchprobieren ohne dass es real in den µC schieben zu müssen. Das Ausperren wird dadurch nicht unmöglich, aber insgesamt dann doch extrem unwahrscheinlich – ist mir persönlich in all den Jahren mit diversen AVRs noch nicht versehentlich passiert. Absichtlich habe ich es schon herbeigeführt, um (a) zu schauen, wie man sich dabei so fühlt und (b) ob man mit undokumentierten Tricks noch etwas machen kann, um es rückgängig machen zu können.
ja korrekt, vorsichtig bzw. umsichtig sollte man sein.
Solange man nicht unüberlegt am Bit RSTPINCFG und den Lockbits rumfummelt, passiert nichts Schlimmes. Was ich meinte war, du kannst mittels Device Programming in Microchip Studio deine eigenen Überlegungen gegenprüfen.
Was man außerhalb von Microchip Studio beachten sollte ist die Note im Kapitel 6.10.
1
Note: When writing the fuses, all reserved bits must be written to ‘1’.
Im Manual vom AVRxDB steht wiederum drin to ‘0’.
Sollte man µC abhängig beachten. Sicher ist sicher.
