Hallo,
Controller: AT TNY 416 Sprache C Compiler IAR
ich möchte mit NVMCTRL auf die "USER ROW" zugreifen und dort ein paar
Werte schreiben und auch lesen. Das Datenblatt des Controllers "sagt"
das dies möglich sei. Leider habe ich keinen Beispielcode dazu gefunden.
Ich kapiere auch die Angaben im Datenblatt nicht so richtig.
Kann mir jemnad helfen?
Ciao Jürgen
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
intmain(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)
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
> 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.
> 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
Hallo,
ist nicht von der DB Serie, sondern auch vom ATtiny. ;-) Egal.
Ich kenne auch mehr BOD Möglichkeiten der megaAVR Serie.
Allen gemein ist das diese vielfältigeren BOD Möglichkeiten nur in den
alten (ersten?) Datenblättern der Controller stehen. In nachfolgenden
sind diese reduziert. Funktionieren tun die BOD Einstellungen alle noch,
hatte ich mal mit ATmega4809 getestet.
Zu deinem EEprom Problem. Wenn du die höchste BOD Stufe konfiguriert
hast, was 4,2V sind, und du korrupte Daten feststellst, kann es sein das
deine Spannungsversorgung instabil ist? Ist der Controller ordentlich
mit allen beschalten? Alle Cs an? Ich würde einfach mit der Seriellen
debuggen. Vorm EEprom beackern ein S für Start senden und am Ende ein E
für Ende. Und am Anfang des Programmstarts ein R für Reset. Wenn
irgendwann im Terminal nach S ein R kommt hat sich der Controller
mittendrin resetet. Damit würde ich anfangen. Danach würde ich den Takt
auf unter 10MHz senken und die BOD auf 2.7V setzen oder ganz ausschalten
und den Test wiederholen. Danach meine Schlüsse daraus ziehen. Irgendwie
so in der Art würde ich meinen Test gestalten und mich dann ggf. weiter
vortasten. Oder parallel mit Oszi die Spannung triggern.
Hallo nochmal,
wegen geänderten BOD Level der megaAVR0 Serie. Findet man nur noch in
alten Header Versionen. Hier aus dem ATmega Device Pack. Falls wer damit
rumspielen möchte. In den ersten DA/DB Headerfiles habe ich keine
gefunden die zu viel sind.
> ... 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).
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:
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.
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
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
Jürgen schrieb:> Ich kann allerdings Atmel nicht verstehen
Wahrscheinlich meinst du Microchip, der Attin416 wurde doch schon unter
Microchip eingeführt. Ich hatte in der Vergangenheit immer wieder den
Eindruck, dass die Datasheets von Microchip doch schon, ich sag mal,
sparsamer gehalten waren als die von Atmel. Das war einer der Gründe,
warum ich mich seinerzeit für die AVRs und gegen die PICs entschied.
Ich habe verschiedene Codes am ATtiny402 erfolglos getestet.
Es ist kinderleicht mit dem EEPROM bzw. User Row, aber der Flash bleibt
unbezwingbar.
Eigentlich brauche ich das nicht, aber es wäre schon interessant zu
wissen, woran es liegt.
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.
Tatsächlich. Im Microchip Studio kann ich das Gewünschte im Flash nicht
finden, aber indirekt, wenn ich den Speicherinhalt prüfe, dann ist alles
in Ordnung:
1
data=*(uint8_t*)0x8F00;
2
if(data==0x77)
3
{
4
data=0;
5
<LEDblink>
6
}
Habe ich immer gesagt: Hauptsache - die LED blinkt!
Anders als Microchip Studio versteckt MPLAB X IDE die in der
APPDATA-Section gespeicherten Daten nicht.
Oder ich mache etwas falsch. Bisher war ich mit dem Studio immer
zufrieden.
Thread beobachten
Seitenaufteilung abschalten