Fuse Einstellung Attiny3216

Sind diese Werte korrekt?

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

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

BODCFG 0x05

BODLEVEL0 entspr. 1.8 V

SYSCFG0 0x46

BOOT entspr. CRC of the boot section EEPROM erased during chip erase

Damit wir eine gemeinsame Basis haben ...

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

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.

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

Nein, tut mir leid, ich verstehe Sie nicht.

Hier meine Überlegung:

1

SYSCFG0:

2

  7 6       5        4        3 2          1     0

3

CRCSRC[1:0] xxx    TOUTDIS RSTPINCFG[1:0] xxx EESAVE

4

 0x3                 1        0x1                1

5

 11          1       1        01           1     1

6

7

->  0xF7

8

9

10

BODCFG:

11

 7 6 5     4       3 2          1 0

12

LVL[2:0] SAMPFREQ ACTIVE[1:0] SLEEP[1:0]

13

 0x2       0x0     0x1          0x0

14

 010        0       01           00

15

16

-> 0x44

17

18

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

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

Achim S. schrieb:

Noch mal gerechnet:

Beitrag "Re: Timing-Problem"

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

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,

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.

OK. Danke für die Info und deine Hilfe

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

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.

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.

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.