NVMCTRL - ATTINY 416

Ich kann leider nur Assembler auf einem ATmega4809 anbieten, aber solange sich kein anderer meldet ... uC sollte kein Problem sein, die Datenblätter der beiden Controller sehen sehr ähnlich aus, und bei Assembler müssten Sie etwas Phantasie&Intelligenz einsetzen; vielleicht hilft es ja trotzdem:

1

    ldiw    Z,$1302                 ; Testwerte in USERROW (ab $1300) schreiben

2

    ldi     tmp0,$45

3

    st      z+,tmp0

4

    ldi     tmp0,$AB

5

    st      z+,tmp0

6

    ldi     tmp0,$CD

7

    st      z+,tmp0

8

    ldi     tmp0,$EF

9

    st      z+,tmp0

10

11

    put     NVMCTRL_ADDR+0,ZL       ; USERROW-Page-Adresse dem NVMCTRL bekanntgeben

12

    put     NVMCTRL_ADDR+1,ZH

13

14

    puti    CPU_CCP,CPU_CCP_SPM_gc

15

    puti    NVMCTRL_CTRLA,$03       ; ERWP Erase and write page (NVMCTRL.ADDR selects which memory)

Das hier läuft bei mir (auf einem ATmega4809) - aber meine C-Kenntnisse sind bestenfalls rudimentär, also bitte nur als ganz grobe Richtungsangabe betrachten:

1

#include "avr/io.h"

2

3

int main (void)

4

{

5

 USERROW.USERROW2 = 0x34;

6

 USERROW.USERROW5 = 0x56;

7

 USERROW.USERROW7 = 0x78;

8

 NVMCTRL.ADDR = 4864;   // USERROW-Page-Adresse dem NVMCTRL bekanntgeben

9

 CPU_CCP = CCP_SPM_gc;

10

 NVMCTRL.CTRLA = 0x03; // ERWP Erase and write page (NVMCTRL.ADDR selects which memory)

11

12

    while(1)

13

    {

14

    }

15

}

Hallo,

das klappt schon mal, Danke.

1

   USERROW.USERROW2 = 0x34;

2

   USERROW.USERROW5 = 0x56;

3

   USERROW.USERROW7 = 0x78;

4

   NVMCTRL.ADDR = USER_SIGNATURES_START;   // USERROW-Page-Adresse dem NVMCTRL bekanntgeben

5

   CPU_CCP = CCP_SPM_gc;

6

   NVMCTRL.CTRLA = 0x03; // ERWP Erase and write page (NVMCTRL.ADDR selects which memory)

Dann habe ich USERROW7 in eine uint8_t gelesen.

1

 i = USERROW.USERROW7;

Super im Debugger ist die 0x56 zu sehen. Funktioniert!

Hast Du das auch schon mal mit dem Flash probiert? Wäre natürlich auch eine Möglichkeit meine Cal Daten ins Fash zu schreiben. Dass EEprom ist ja ziemlich wackelig.

Ciao Jürgen - und danke schonmal

"Dass EEprom ist ja ziemlich wackelig."

Was meinst du mit wackelig?

USERROW.USERROW5 = 0x56; USERROW.USERROW7 = 0x78; i = USERROW.USERROW7; Super im Debugger ist die 0x56 zu sehen. Funktioniert!

Das verstehe ich zwar nicht, aber solange Sie zufrieden sind ...

Hast Du das auch schon mal mit dem Flash probiert?

Bislang habe ich Flash nur per UPDI beschrieben, denke aber, dass das für den Teilbereich 'APPLICATION DATA' ebenfalls kein Hexenwerk ist.

MCUA schrieb im Beitrag #7351273: MCUA

Was meinst du mit wackelig?

Ich habe nachmal/völlig sporadisch korrupte EEprom Daten obwohl ich BOD auf 4,0 bzw. 4,3 V gesetzt habe VCC ist 5.0 Volt.

S. Landolt schrieb:

Das verstehe ich zwar nicht, aber solange Sie zufrieden sind ...

S. Landolt schrieb:

Das verstehe ich zwar nicht, aber solange Sie zufrieden sind ...

Tippfehler von mir: richtig ist "i = USERROW.USERROW5; wo die 0x56 reingeschrieben wurden.

Georg M. schrieb:

EEPROM: https://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

Flash: https://www.nongnu.org/avr-libc/user-manual/pgmspace.html https://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html

User signature bytes: https://microchip.my.site.com/s/article/AVR-0-1-Series--Different-ways-of-writing-User-signature-bytes-and-creating--usersignature-file

Die Dokumente keen ich, mein Problem ist aber dass ist die Daten nicht vom Programmer mit UPDI sondern vom Controller selbst zur Laufzeit ins Fllash schreben will.

Ciao Jürgen

vom Controller selbst zur Laufzeit ins Fllash schreben

Ohne Georg M. vorgreifen zu wollen (der wird's in C können) - Sie müssen erstmal per Fuse einen 'Application Data'-Bereich einrichten, danach sollte es ähnlich wie beim EEPROM gehen. Ich gebe aber zu bedenken, dass Sie mindestens 256 Bytes Flash dafür opfern müssen, und Sie haben insgesamt nur 4 KiB.

Ich habe nachmal/völlig sporadisch korrupte EEprom Daten obwohl ich BOD auf 4,0 bzw. 4,3 V gesetzt habe VCC ist 5.0 Volt.

Beim ATtiny416? Da lese ich im Datenblatt für den BOD nur die Werte 1.8, 2.6 und 4.2 V.

Hallo,

S. Landolt schrieb:

Beim ATtiny416? Da lese ich im Datenblatt für den BOD nur die Werte 1.8, 2.6 und 4.2 V.

Datenblatt Seite 129 0x6 BODLEVEL7 4.0V - 0x7 BODLEVEL7 4.30V usw.

S. Landolt schrieb:

Ich gebe aber zu bedenken, dass Sie mindestens 256 Bytes Flash dafür opfern müssen, und Sie haben insgesamt nur 4 KiB.

Der Platz im Flash ist nicht das Problem, wenn kann ich auf den 816 Umsteigen, das Problem ist dass die Cal Daten sicher sein müssen.

S. Landolt schrieb:

Ohne Georg M. vorgreifen zu wollen (der wird's in C können) - Sie müssen erstmal per Fuse einen 'Application Data'-Bereich einrichten, danach sollte es ähnlich wie beim EEPROM gehen.

S. Landolt schrieb:

Ohne Georg M. vorgreifen zu wollen (der wird's in C können) - Sie müssen erstmal per Fuse einen 'Application Data'-Bereich einrichten, danach sollte es ähnlich wie beim EEPROM gehen.

Das habe ich mir auch schon angeschaut, was mir aber dabei nicht ganz klar ist ob das NCMCTRL Register eine gemappte Adresse "will". Aber Versuch macht klug ich werde das heute ausbrobieren.

Ciao Jürgen - danke allen bisherigen Teilnehmern

ich werde das heute ausbrobieren

Okay.

Datenblatt Seite 129 0x6 BODLEVEL7 4.0V - 0x7 BODLEVEL7 4.30V usw.

Spielt jetzt vielleicht keine Rolle, aber: siehe Anlage (extra eben nochmals von Microchip heruntergeladen).

Ich habe nachmal/völlig sporadisch korrupte EEprom Daten obwohl ich BOD auf 4,0 bzw. 4,3 V gesetzt habe VCC ist 5.0 Volt.

Also die Errata-Liste ist durchaus beeindruckend ("alter Flohsack!"), aber EEPROM ist nicht dabei - merkwürdig.

Hallo,

S. Landolt schrieb:

Spielt jetzt vielleicht keine Rolle, aber: siehe Anlage (extra eben nochmals von Microchip heruntergeladen).

Die spinnen die Römer. Anbei Screenshot der DB-Seite

Mit der Flash NVMCTRL Programmierung bin ich noch nicht weiter gekommen (war ziemlich stressig heute). Über die Fuse Programmierung habe ich eine APPLICATION DATA Section eingerichtet.

Was mich verwirrt: Atmel selbst macht das im NVMCTRL Example völlig anders und benutzt weder im EEprom noch im Flash Beispiel den NVMCTRL(?) sondern hantiert da ziemlich mit Zeigern umher - wo es doch ein NVMCTRL Controller Modul gibt!

Auf AVRFREAKS habe ich auch etwas gefunden das bezieht sich allerdings alles auf den SAMD21. Werde mir das trotzdem mal anschauen - vielleicht funktioniert das ähnlich.

Aber jetzt ist zunächst mal Schluss für heute.

Ciao und danke allen die helfen das Mysterium zu klären. Jürgen

... weder im EEprom noch im Flash Beispiel den NVMCTRL(?) ...

Den nicht-flüchtigen Speicher ohne den non-volatile Memory-Controller bearbeiten? Da kommt auch von mir ein Fragezeichen.

Bei mir funktioniert es (auf dem ATmega4809) für den Application-Data-Bereich wie für das EEPROM; allerdings: das Setzen von NVMCTRL.ADDR muss an den Anfang, also noch vor das Schreiben der eigentlichen Werte, sonst gibt es einen Schreibfehler (NVMCTRL.STATUS=WRERROR).

PS: Falls mehrere Seiten geschrieben werden, muss natürlich nach dem Setzen von ERWP entweder stur ca. 10 ms gewartet werden, oder man fragt FBUSY ab.

Uwe D. schrieb:

Die AppNote ist keine Hilfe? https://www.microchip.com/content/dam/mchp/documents/OTH/ApplicationNotes/ApplicationNotes/AN1983WritingtoFlashandEEPROMonthetinyAVR1-series40001983A.pdf

Nein ist keine grosse Hilfe. Das läuft auf eine grosse Zeiger Operation hinaus, dem Linker muss eine neu Section übergeben werden. Das ganze ist alles ein wenig diffus, ich frage mich wareum bei allen Appnotes diese Zeiger Linker Konstrukt aufgezeigt wird und es keine Appnote für den NCMCTRL existiert dass sich auf das FLAsH bezieht.

Was ich bisher gemacht habe ich habe in den Fuse Bits die Sections definiert wie in DB beschrieben (9.2 Setting up Flash sections) dass Bootend == Append ist. Mein enstprechnedr C-Code ist jetzt:

1

#define TEST_ADRESS 0x8FD0 // Ich will ganz oben etwas reinschreiben

2

3

   NVMCTRL.DATA = 0xAA55;

4

   NVMCTRL.ADDR = TEST_ADRESS;   // Page-Adresse dem NVMCTRL bekanntgeben

5

   CPU_CCP = CCP_SPM_gc;

6

   NVMCTRL.CTRLA = 0x03;

Das einzigte was passiert ist der Emulator abstrzt und ich ihn ein paarmal Ein- und Ausschalten muss das er wieder funktioniert. Wenn ich dann ins MAPPED_PROGMEN reinschaue (Flash) ist das Pattern 0xAA55 nirgends zu finden.

Bin ziemlich Ratlos jetzt. Das einzige was ich nicht verstehe ist dies:

1

   CPU_CCP = CCP_SPM_gc;

Habt ihr irgendwelche Ideen?

Ciao Jürgen - einen schönes Sonntag noch

NVMCTRL.DATA = 0xAA55;

? "This register is used by the UPDI for fuse write operations"

Das einzige was ich nicht verstehe ist dies: CPU_CCP = CCP_SPM_gc;

" Name: CTRLA ... Property: Configuration Change Protection" oder unter 'Table 9-3. NVMCTRL - Registers under Configuration Change Protection' nachlesen.

bei mir läuft:

1

#include "avr/io.h"

2

3

uint8_t appdata_0 __attribute__((address (0x8F00)));

4

uint8_t appdata_3 __attribute__((address (0x8F03)));

5

uint8_t appdata_7 __attribute__((address (0x8F07)));

6

7

int main (void)

8

{

9

 NVMCTRL.ADDR = 0x8F00;   // flash-APPDATA-Page-Adresse dem NVMCTRL bekanntgeben

10

 appdata_0 = 0x12;

11

 appdata_3 = 0x33;

12

 appdata_7 = 0xCD;

13

 CPU_CCP = CCP_SPM_gc;

14

 NVMCTRL.CTRLA = 0x03; // ERWP Erase and write page (NVMCTRL.ADDR selects which memory)

15

16

    while(1)

17

    {

18

    }

19

}

Hallo,

S. Landolt schrieb:

bei mir läuft:

ok.

Kannst Du mir bitte mitteilen wie Du die Fuses (9.2 Setting up Flash Sections) gesetzt hast?

Ich ziehe jetzt schon den Hut vor Dir. Du hast mir bisher sehr geholfen. Ich habe bemerkt das trotz der vielen "Abstürze" mein Eeprom gelöscht aber die "User Row" Daten immer noch richtig gesetzt sind.

Ciao Jürgen

Ich arbeite mit dem ATmega4809.

Sie müssen mindestens eine 256-Byte-Seite als Appdata-Bereich definieren, das müsste auf dem ATtiny416 z.B. APPEND=BOOTEND= 0x0F sein. Dann sollte mein Programm bei Ihnen laufen.

mein Eeprom gelöscht

Liegt das nicht eher daran, dass SYSCFG0.EESAVE nicht gesetzt ist?

Hallo,

S. Landolt schrieb:

Liegt das nicht eher daran, dass SYSCFG0.EESAVE nicht gesetzt ist?

ich kann das Flag nicht setzen weil ab und an während des Betriebs die Cal-Daten geändert werden müssen. Oder lässt sich das Flag "On the Fly" Ein- und Ausschalten?

Ciao

Das gilt nur für den Programmiervorgang:

"SYSCFG0.EESAVE: EEPROM Save During Chip Erase: value 1 EEPROM not erased under chip erase"

Im Programm selbst kann das EEPROM natürlich trotzdem beschrieben werden.

Hallo,

S. Landolt schrieb:

Du bist der grösste. Ich habe den NVMCTRL komplett falsch verstanden. Jetzt läuft es bei mir auch ich musste die attribute

uint8_t appdata_0 attribute((address (0x8F00)));

an den IAR C-Compiler anpassen.

Wie würde ein Schwabe im Vally sagen "s'goht Bill". (lach)

Danke Du hast mir sehr geholfen. Und wenn wir uns einmal treffen sollten (Embedded 2023) gebe ich dir gerne ein Bier aus.

Ciao Jürgen

Die Teile werden immer komplexer, und als reiner Autodidakt muss man nicht nur viel Zeit mitbringen, sondern auch eine ausgesprochen hohe Frustrationsschwelle haben.

Gruß aus dem Schwarzwald

NVMCTRL komplett falsch verstanden

Na, ich lerne auch noch - vergessen Sie NVMCTRL.ADDR.

Hallo,

das teil bringt mich noch ins Irrenhaus.

uint8_t appdata_0 attribute((address (0x8F00))); uint8_t appdata_1 attribute((address (0x8F01))); uint8_t appdata_2 attribute((address (0x8F02)));

Das sieht beim IAR Compiler so aus:

_noinit uint8_t appdata_0 @ 0x8F00; usw, usw.

Statisch, also mit Konstanten funktioniert das super, wie ich ja gestern geschrieben hatte.

aber wenn ich jetzt sage wobei testvar eine "normale" uint8_t Variable ist:

appdata_0 = testvar; CPU_CCP = CCP_SPM_gc; NVMCTRL.CTRLA = 0x03; // ERWP Erase and write page (NVMCTRL.ADDR selects which memory)

ist absolut keine Änderung im Flash zu sehen.

Ein weiteres Problem. Durch die Änderung von APPEND=BOOTEND=0x0F konnte keinen Interrupt Einsprung feststellen d.h. ein Breakpoint auf den Interrupt wurde nie angesprungen. Ich habe dann das "IVSEL: Interrupt Vector Select" auf "1 Interrupt vectors are placed at the start of the BOOT section of the Flash" geändert, jetzt kann ich zwar manchmal Interrupts "sehen" aber alles ist völlig instabil d.h. selbst das neu flashen funktioniert manchmal, manchmal nicht. Das Program(teile) macht überhaupt nicht was es soll sprich stürzt ab, obwohl es noch sehr rudimentär ist. Es kann aber nicht am C-Code liegen weil das alles auf Eeprom Basis funktioniert.

Was habe ich wieder einmal übersehen, was mache ich nicht richtig.

Ciao Jürgen

generell: wie anfangs gesagt, programmiere ich normalerweise in Assembler, und ich habe zum Testen nur einen ATmega4809. Wenn hier ein C-Programmierer, gar mit einem ATtiny461, mitliest, würde ich gerne an ihn übergeben.

Zu Teil 1: die Festadressen sind ja nur eine Hilfskonstruktion, um nicht bei C-Compiler/Linker mit den diversen Speicherbereichen arbeiten zu müssen. Korrekterweise sollte man die Adresszuordnung eben dem Compiler/Linker überlassen. Zum IAR-Compiler kann ich rein gar nichts sagen; hier mit dem avr-gcc funktioniert (natürlich) angehängtes Programm, d.h. in USER-ROW steht anschließend das 0x45 auf Adresse 0x1303, ebenso im Flash auf Adresse 0x8F02.

Zu Teil 2: wieder IAR-Compiler - kenne ich nicht. Wenn Ihr Programm wirklich "sehr rudimentär" ist, könnte man versuchen, das erzeugte Assembler-Listing zu analysieren.

PS: Mag unbefriedigend sein, aber: warum vergessen Sie nicht diese APPDATA-Alternative (d.h. wieder APPEND=BOOTEND=0) und kehren zurück zu USER-ROW oder EEPROM?

Hallo Herr Landolt,

S. Landolt schrieb:

Mag unbefriedigend sein, aber: warum vergessen Sie nicht diese APPDATA-Alternative (d.h. wieder APPEND=BOOTEND=0) und kehren zurück zu USER-ROW oder EEPROM?

Sie haben im Prinzip schon recht. Aber das ist halt der "Forscherdrang" in mir. Da das Projekz nächste Woche fertig sein sollte wird mir wohl nichts anderes übrig bleiben.

Ich kann allerdings Atmel nicht verstehen das der NVMCTRL so schlecht beschrieben wird. Es scheint mir ein unausgegorenes Feature zu sein. Ganz getreu dem alten IBM-Spruch "Its not a Bug its a Feature".

Ciao und danke zunächst mal sollte ich neue Erkenntnisse haben melde ich mit.

Jürgen

Georg M. schrieb:

verschiedene Codes

Verschiedene C-Programme unter avr-gcc, nehme ich an?

Flash ... unbezwingbar ... schon interessant ...

Ja, würde mich auch interessieren; könnten Sie etwas (möglichst einfaches) zeigen, was nicht funktionierte? Vielleicht könnte man auf diesem Umweg dann auch /Jürgen/ weiterhelfen.

Tja - funktioniert auf dem ATmega4809: anschließend steht in 0x8F00 (flash gemapped in DATA) sowie in 0x4F00 (nur ATmega4809, original flash) das 0x77.

Ja, ich werde auch das Gefühl nicht los, dass bei /Jürgen/ etwas mit seiner IDE in Verbindung mit dem ATtiny416 nicht stimmt.