Fuse Einstellung Attiny3216

[Achim S. (achims)]

Nach dem ich mit einem Adapter die Fuse Einstellung aus dem Attiny 3216 
auslesen kann, habe diese Werte im ori IC:

APPEND - 0x00
BODCFG - 0x00
BOOTEND - 0x02
SYSFGO - 0xF6
SYSFG1 - 0x07
TCDCFG - 0x00
WTDCFG - 0x00

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?

[S. L. (sldt)]

> Sind diese Werte korrekt?

In meinem Datenblatt (von 2020) lese ich teilweise andere Werte.
  Vielleicht sollten Sie Ihre nochmals überprüfen ...

[Achim S. (achims)]

Könntest du mir sagen (schreiben) welche Werte anders sind?

[S. L. (sldt)]

> BODCFG  0x05
BODLEVEL0 entspr. 1.8 V

> SYSCFG0  0x46
BOOT entspr. CRC of the boot section
EEPROM erased during chip erase

[S. L. (sldt)]

Damit wir eine gemeinsame Basis haben ...

[Achim S. (achims)]

BODCFG 0x05 steht für 1,8V, hasst Recht, besser ist 0x0D steht für 2,7V.
Bei SYSFG0 sind das meine überlegungen:

Korrekte SYSCFG0, wenn:
•  Kein Bootloader
•  Kein CRC nötig
•  EEPROM soll erhalten bleiben
•  UPDI soll aktiv bleiben
Dann:
Bit    Wert
RSTPINCFG  00
CRCSRC  00
EESAVE  1
RESERVED  110

Binär: 0b01000110 → 0x46

[S. L. (sldt)]

Bei BODCFG = 0D ist LVL[2:0] doch nach wie vor 0, folglich 1.8 V!?

Und SYSCFG? Sie setzen RSTPINCFG korrekt auf 01, schreiben aber
> RSTPINCFG  00
setzen CRCSRC auf 01, schreiben aber
> CRCSRC  00
korrekt wäre 3 (no CRC), etc.

Ich kann Ihre Angaben beim besten Willen nicht nachvollziehen.

[Achim S. (achims)]

Noch mal gerechnet:
Da müsste
BODCFG - 0x0F
SYSFG0 - 0x06
sein. Da hab ich mich wohl verrechnet. Hoffe das es jetzt stimmt

[S. L. (sldt)]

Nein, tut mir leid, ich verstehe Sie nicht.

Hier meine Überlegung:

SYSCFG0:
  7 6       5        4        3 2          1     0
CRCSRC[1:0] xxx    TOUTDIS RSTPINCFG[1:0] xxx EESAVE
 0x3                 1        0x1                1
 11          1       1        01           1     1
 
->  0xF7


BODCFG:
 7 6 5     4       3 2          1 0
LVL[2:0] SAMPFREQ ACTIVE[1:0] SLEEP[1:0]
 0x2       0x0     0x1          0x0
 010        0       01           00
 
-> 0x44

"Note: When writing the fuses, all reserved bits must be written to ‘1’."

[Achim S. (achims)]

Da werde ich mich mal hinsetzen und alles lesen und rechnen. Danke für 
die Info

[Wastl (hartundweichware)]

Achim S. schrieb:
> Noch mal gerechnet:

Beitrag "Re: Timing-Problem"

[Achim S. (achims)]

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

[S. L. (sldt)]

Okay.

Noch eine Anmerkung:
> OSCCFG  0x02  20 MHz interner Oszillator, keine Frequenzteilung

Frequenzteilung kann hier in den Fuses nicht eingestellt werden, sie 
erfolgt zur Laufzeit per CLKCTRL_MCLKCTRLB,

[Veit D. (devil-elec)]

Hallo,

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.

[Achim S. (achims)]

OK. Danke für die Info und deine Hilfe

[Achim S. (achims)]

Ja ich verwende Microchip Studio. Bin aber mit den Einstellungen sehr 
vorsichtig geworden weil ich mich bei anderen Prozessoren ausgesperrt 
habe

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Achim S. schrieb:
> 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.

[Veit D. (devil-elec)]

Hallo Achim,

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.

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.