Auf dem Kriegsfuss mit AVR

>Neulich musste ich feststellen, dass die Daten im internen EEPROM meines
>ATMEGA644 unsicher sind. Spannung aus, Spannung ein => und schon sind
>ein paar Bits anders... :-( Und das sind ja Kalibtationsdaten für
>Sensoren!

Passiert wenn irgendwann auf das Eeprom zugegriffen wurde 
(lesen/schreiben egal) und die Spannungsversorgung langsam 
zusammenbricht und kein Brownout-Detector eingeschaltet ist. Auch wenn 
zum zeitpunkt des Ausschaltens kein(!)
Zugriff erfolgt. Im Datenbatt wird die verwendung des Brownout-Detectors
empfohlen. Hatte seither keine Probleme mehr.

Hallo Lothar,

ja, tatsächlich ist es mir mehrmals mit dem Byte #0 passiert. Dann stand 
plötzlich wieder 0xFF drin. Es war aber schon so, dass zu diesem 
Zeitpunkt ausschliesslich READ-Befehle zum Einsatz kamen, keine 
WRITE-Operationen.

Es geht mir schon besser.

Ich danke allen, die mir den wertvollen Tipp über den Brown-Out gaben.

/Dmitri

>ja, tatsächlich ist es mir mehrmals mit dem Byte #0 passiert. Dann stand
>plötzlich wieder 0xFF drin. Es war aber schon so, dass zu diesem
>Zeitpunkt ausschliesslich READ-Befehle zum Einsatz kamen, keine
>WRITE-Operationen.

Ja, eine einzige Read operation (z.b. nach dem reset) reicht um
bei abfallender Spannung das Eeprom zu zerlegen.

>> Auch das Platzieren von Konstanten im Programmspeicher an einer
>> vorgegebenen Stelle geht mit C18 mit einer einfachen #pragma-Anweisung,
>> wo hingegen mit WinARV.... naja

> Und wozu braucht man das?

Ich möchte zum Beispiel einen Satz von Konstanten "auf ewig" speichern. 
ich habe einen #pragma-Block mit vordefinierten Platzhaltern im 
Programmspeicher

1

#define FLASH_DATA_ADDR 0x0040

2

#pragma romdata const_tbl = FLASH_DATA_ADDR

3

const rom unsigned int _Uexc[4] = {4095, 4095, 4095, 4095};

4

const rom unsigned int _TComp[4] = {2048, 2048, 2048, 2048};

5

const rom unsigned int _ZERO[4] = {2048, 2048, 2048, 2048};

6

const rom unsigned int _ROMSN_L;

7

const rom unsigned int _ROMSN_M;

8

const rom unsigned int _ROMSN_H;

9

const rom unsigned int FineZeroFlag; 

10

const rom unsigned char dummy[32];

11

#pragma romdata

und eine Struktur im RAM

1

struct _flashdata

2

{

3

  unsigned int Uexc[4];

4

  unsigned int TComp[4];

5

  unsigned int ZERO[4];

6

  unsigned int ROMSN_L;

7

  unsigned int ROMSN_M;

8

  unsigned int ROMSN_H;

9

  unsigned int FineZeroFlag; 

10

  unsigned char dummy[32];

11

};

12

13

struct _flashdata flash; // 64

14

unsigned char *pflashdata = &flash;

15

16

CODEwritePage(FLASH_DATA_ADDR, &flash);

CODEreadPage(...) ist gar nicht nötig, weil ich dann direkt auf 
Konstanten zugreifen.

Nun erfahre ich, dass so was mit AVR gar nicht möglich ist, weil die 
ISP-Routinen ausschliesslich aus dem Bootbereich agieren können. 
Richtig? Zum Nachteil für mich.

Ja, es gibt ja noch das EEPROM. Aber es gibt auch viele abgespeckten 
PIC-NibelKarossen, die keins haben.

ich weiß nicht, ob dich ganz verstanden habe, aber vllt hilft dir das:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Vereinfachung_f.C3.BCr_Zeichenketten_.28Strings.29_im_Flash
http://www.helicron.net/avr/avrgcc/flashdata.php

Bedingt durch die Architektur des AVR ist ein "direkter" ROM Zugriff
nicht möglich. Wenn du Strukturen aus dem ROM laden möchtest,
nimm memcyp_P. Beim Eeprom ist das nicht viel anders.

> ich weiß nicht, ob dich ganz verstanden habe, aber vllt hilft dir das:
> http://www.mikrocontroller.net/articles/AVR-GCC-Tu...
> http://www.helicron.net/avr/avrgcc/flashdata.php

Hallo Michael,

ja, so mache ich es, wenn ich meine Daten explizit im Programm ablege. 
Mir ging's darum, ob und wie ich diese Werte zu Runtime überschreiben 
kann. Denn es braucht kleine Korrekturen.

Danke trotzdem
/Dimitri

>
> 1. Du hast keinen Bootloader, dann kannst Du dem GCC-Linker sagen, daß
> die SPM-Routine im Bootsektor zu plazieren ist.
>

Hallo Peter,

ja, klar geht es irgendwie. Ich will ja hier auch nicht ewig rumjammern.

Meinst du etwa diese Anweisung:

1

--section-start=.ISPSTUFF=BOOTLOADERRANGE

wobei ISPSTUFF für ispstuff.c und BOOTLOADERRANGE für etwas ab 0xE000 
steht.

/Dimitri

> Man mag mich konservativ nennen.
> Aber genau das war ja der ganze Hintergedanke bei einer
> Harvard-Architektur: Die strikte Trennung zwischen Code und Daten, damit
> es eben für das Programm keine Möglichkeit gibt, sich selbst zu
> beschädigen. Benutzt man nun das Flash als eine Art 'Daten-Speicher',
> dann hebelt man diesen Gedankenansatz komplett aus.
> Ich kann noch verstehen, dass man Daten, die tatsächlich konstant sind
> im Flash platziert, weil woanders kein Platz dafür ist. Aber eine
> Flash-Benutzung im Sinne einer Variablen die verändert werden kann, geht
> mir gegen den Strich. Genau dafür gibt es das EEPROM.
>
> Flash-Beschreiben sollte in meinen Augen aussschliesslich einem
> Bootloader vorbehalten sein und auch in diesem Sinne verwendet werden.

Hallo Karl Heinz,

vielleicht sollte ich etwas ausführlicher werden, worum es mir geht.

Die EMV AKA die elektromagnetische Verträglichkeit ist so ein Ding. Wenn 
es dumm läuft, sind die Daten im RAM beschädigt. Natürlich kann man 
diese immer wieder checken. Das finde ich aber zu lästig.

Wenn die Daten aus dem fixen Speicher gelesen werden, sind sie genau so 
sicher wie das Programm selbst. Ein Reset per Watchdog, Brown-Out oder 
sonst kann ihnen nichts anhaben. Man muss diese nicht neu 
initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs, was 
bei einem EEPROM etwas anders aussieht. Man nimmt die Daten aus dem 
EEPROM und legt diese im RAM ab, wo sie EMV-mässig unsicher sind.

vielleich bin ich nur leich paranoid, was nach meiner Erfahrung mit dem 
kaputten EEPROM wohl verständlich ist.

Ja, bei mir besteht die Notwendigkeit, ein paar Werte nach der fertigen 
Kalibration unseres aus bis zu 36 Drucksensoren bestehenden Produkts 
nachzukorrigieren.

/Dmitri

EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn 
mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren 
und kann nach Hause gehen. Falls der interne Brownout nichts taugt, resp 
man dem nicht traut, sollte man einen externen verwenden. zB die MCP111 
Serie von microchip. Laeuft mit weniger als 1uA.

> Ja, bei mir besteht die Notwendigkeit, ein paar Werte nach der fertigen
> Kalibration unseres aus bis zu 36 Drucksensoren bestehenden Produkts
> nachzukorrigieren.

Aber wieso legst du die Daten dann nicht einfach im EEProm ab? Wie 
gesagt, mit Brownout detection gibt es da auch keine probleme mit 
"verschwundenen" Daten. Wenn du so extrem auf Nummer sicher gehen 
willst, dann ist das Flash sowieso nicht der richtige Punkt um solche 
Daten abzulegen.

Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu 
benutzen, dann kann es dir auch nicht passieren das während eines 
Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man 
muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS 
jetzt die aktuellen Daten sind.

>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>benutzen, dann kann es dir auch nicht passieren das während eines
>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>jetzt die aktuellen Daten sind.
Das ist Quatsch!

> EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn
> mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren
> und kann nach Hause gehen.

Ja klar. Wenn mir ein kleines EMV-Labor für die Zwischentests zur 
Verfügung stünde, würde ich die Sache auch viel entspannter betrachten.

/Dimitri

> Aber wieso legst du die Daten dann nicht einfach im EEProm ab? Wie
> gesagt, mit Brownout detection gibt es da auch keine probleme mit
> "verschwundenen" Daten.

Hallo Nico,

also, wenn ich das Projekt neu auflegen hätte können, dann würde ich 
sowieso nur mit PIC machen. Die Makefile von avr-gcc ist mir zu 
kryptisch. Da lobe ich mir mein MPLAB mit C18 nach dem 
LPT-Port-Dongle-Ärger mit einem uralten IAR-compiler, wegen dem ich auch 
auf eine 600MHz-Rechner angewiesen war (der einzige, wo diese Krücke 
lief)

Ich habe es vergessen zu erwähnen, dass ich dieses Projekt sozusagen 
geerbt habe. Das einzig wenige, was ich darin ändern konnte, war der 
Umstieg von ATMEGA8535 (auf den Kalender guck und sich totlach) auf 
ATMEGA644.

Ich denke, wenn der Tipp mit dem Brown-Out haut, bin ich ganz zufrieden.

/Dimitri

P.S. Ich will da keinen Glaubenskrieg vom Zaun brechen. Ich gebe mich 
nur widerwillig mit AVRs ab und fühle mich bei PICs viel besser 
aufgehoben.

>> initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs,

> Das du dich da mal nicht täuscht :-)

Wie meinen? Ich muss auf diese Konstanten keine Pointer spitzen und 
keine Functions aufrufen wie pgm_read_word(&Offset[idx]);. Für mich ist 
das ein Direktzugriff.

/Dimitri

> Aber er hat einen Vorteil: Man kann sich von AVRs über Microchips
> nächstgrössere Klassen (PIC30,PIC32) bis hin zu PCs und 64bit Boliden
> bewegen, ohne sich gross umgewöhnen zu müssen. Wird alles abgedeckt.

Das hat aber auch seinen Preis. Ich liess mir sagen, dass so ein System 
von einem "Namenhaften" schnell über 5000 Euro kostet. Oder waren das 
8000?

Sind sie dann nicht auch nur auf einen Lizenzplatz eingeschränkt?

>>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>>benutzen, dann kann es dir auch nicht passieren das während eines
>>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>>jetzt die aktuellen Daten sind.
>Das ist Quatsch!

Danke für deinen qualifizierten Beitrag. Möchtest Du den vielleicht auch 
noch weiter ausführen oder hast Du dich schonwieder in deiner Trollhütte 
versteckt?

> Es geht auch ohne Make, ich haben mir dafür eine Batch geschrieben.
> Man muß darin nur dem AVR-Typ festlegen, das geht leider nicht im
> C-File.
> Oder man läßt sich das Make vom AVRStudio erzeugen.
> Viele programmieren den AVR ohne von Make ne Ahnung zu haben.

das mit der batch-Datei hatte ich auch schon. Ob so oder mit dem 
Makefile, ist und bleibt es eine DOS-Welt. Ich will aber nur einen 
"Run"-Button wie in Delphi und den habe ich in MPLAB.

> Naja, man muß nicht immer gleich den größten Chip nehmen.
> Wenns auf dem ATmega8535 zu eng geworden ist, dann dürfte schon der
> ATmega16 wieder ne lange Zeit reichen.

Es war m.E. der einzige, der zum ATMEGA8535 pinkompatibel war. Wie 
gesagt, ich konnte das Layout nicht ändern. Hätte ich es können, dann 
hätte ich einen PIC reingepflanzt. :D

>Hätte ich es können, dann hätte ich einen PIC reingepflanzt. :D
Hätte ich eine Platine, die einen PIC erfordert vor mir, würde ich über 
eine AVR-Adapterkarte nachdenken...

A.K. schrieb:

> Das "Aber er hat einen Vorteil..." war auf GCC gemünzt. Wer bitteschön
> traut sich, 8000 für einen verwursteten und verdongelten GCC zu
> verlangen?

Verdongelt? Bei dem Wort kriege ich Hautausschlag. Ich hatte einen 
verdongelten IAR. Grrrrr

STK500-Besitzer schrieb:

> Hätte ich eine Platine, die einen PIC erfordert vor mir, würde ich über
> eine AVR-Adapterkarte nachdenken...

Danach dachte ich gestern, aber genau umgekehrt. :D

A.K. schrieb:

> Hätte gedacht, die Mega16,32,644 hätten alle das gleichen Pinout.

So ein Mist aber auch! :D So hätte ich mir den ganzen Migrationskack 
sparen können. Nun bin ich halt der stolze Anwender des grössten Chips 
aus dieser Pinout-Familie. :D

>Die EMV AKA die elektromagnetische Verträglichkeit ist so ein Ding. Wenn
>es dumm läuft, sind die Daten im RAM beschädigt. Natürlich kann man
>diese immer wieder checken.

Am liebsten sind mir die µCs, bei denen der komplette Stack EMV 
geschützt im ROM liegt. RAM ist ja zu unsicher :-)

Genau, wenn man sich auf's Ram nicht verlassen kann, dann wird wegen 
falscher Rücksprungadressen im Stack der wildeste Code ausgeführt. Auf's 
Ram muss man sich also hundertprozent verlassen können. Es sei denn, man 
programmiert keinerlei Calls.

>> EMV ist eine Frage des Layouts und der Beschaltung gegen aussen. Wenn
>> mit EMV daten im RAM oder EEPROM veloren gehen, hat man schon verloren
>> und kann nach Hause gehen.
>
>Ja klar. Wenn mir ein kleines EMV-Labor für die Zwischentests zur
>Verfügung stünde, würde ich die Sache auch viel entspannter betrachten.
>

Guter Mann,
wenn du die EMV Vertraeglichkeit nicht hinkriegst bringt nichts mehr 
was. Dann solltest du gar nichts mehr verkaufen, der Aerger ist 
vorprogrammiert. Ruecklaeufe... usw. Es ist nicht schwierig. Nimm dir 
die Zeit das zu lernen. Vielleicht ein Kurs, vielleicht eine Beratung 
beim EMV Labor, vielleicht kostet es was. Was solls. Wenn man glaubt es 
begriffen zu haben macht man einen Test mit dem naechsten Teil, und 
wenn's gut ist war's das solange man sich in der selben 
Produktekategorie aufhaelt.
Viele Leute denken die EMV Tests seien abgehobener Bullshit, laufen aber 
wie selbstverstaendlich mit dem Mobiltelephon im Sack (1Watt @ 1GHz) 
herum und sind sicher dass keine Elektronik durchdreht. Das ist eine 
pure Annahme. Denn ohne EMV Vorschriften und Tests ist das nicht so. 
Ueberlegt Euch mal was alles schiefgehen kann wenn Elektronik 
durchdreht...

> Guter Mann,
> wenn du die EMV Vertraeglichkeit nicht hinkriegst

mach dir keine Sorgen, ok?

Betreffs EEP-Vergesslichkeit:

Ich habe (bei älteren AVRs ohne BOD) festgestellt, dass immer nur die 
zuletzt adressierte Zelle betroffen war, also die Zelle, auf die das 
Adressregister (eearh:eearl) zeigt. Nachdem ich mir angewöhnt hatte, 
nach jedem Zugriff die Adresse auf eine unbenutzte Zelle zu setzen, 
hatte ich keine Ausfälle mehr. Das war allerdings in ASM.

...

>>>Die beste Vorgehensweise dabei ist das EEProm als eine Art Ringbuffer zu
>>>benutzen, dann kann es dir auch nicht passieren das während eines
>>>Updates der Daten ein Reset zuschlägt und dir alles zerschiesst. Man
>>>muss halt nur dafür sorgen das man bei einem Neustart erkennen kann WAS
>>>jetzt die aktuellen Daten sind.
>>Das ist Quatsch!

>Danke für deinen qualifizierten Beitrag. Möchtest Du den vielleicht auch
>noch weiter ausführen oder hast Du dich schonwieder in deiner Trollhütte
>versteckt?
Wenn du aufmerksam gelesen hättest, wüsstest du, dass bei einem 
Stromausfall nicht zwangsläufig das addressierte Byte korrupt werden 
muss. Welches Byte es erwischt, hängt (fast) ausschliesslich von der 
internen Gatterbschaltung ab!

Grober EMV Test, einfach ein 230V Relais als Wagnerschen Hammer 
beschaltet an die Zuleitung.

>Wenn du aufmerksam gelesen hättest, wüsstest du, dass bei einem
>Stromausfall nicht zwangsläufig das addressierte Byte korrupt werden
>muss. Welches Byte es erwischt, hängt (fast) ausschliesslich von der
>internen Gatterbschaltung ab!

Und deswegen schrieb ich vorher das er Brownout detection verwenden 
soll. Nicht aufmerksam genug gelesen, oder?
Der Ringbuffer dient eher als "transaktionsorientierte Datenbank" um 
dafür zu sorgen das man sich sicher sein kann das die letzte 
Modifikation der Daten komplett durchgeführt wurde. Halt, ganz oder 
garnicht.

Karl Hinz schrieb:

> Ähm reden wir vom selben?

Nö :-)

denn ich schrieb

1

Wenn die Daten aus dem fixen Speicher gelesen werden, sind sie genau so

2

sicher wie das Programm selbst. Ein Reset per Watchdog, Brown-Out oder

3

sonst kann ihnen nichts anhaben. Man muss diese nicht neu

4

initialisieren. Und ich habe die Möglichkeit eines Direktzugriffs, was

5

bei einem EEPROM etwas anders aussieht.

Beim Direktzugriff meinte ich ausschliesslich den Zugriff auf die Datem 
im Programmspeicher. :-)

> Wenn du aufs Flash zugreifst, musst du Spezialfunktionen dafür benutzen.
> Wo ist also der Komfortunterschied?

Nicht beim MPLAB C18 :-)

Siehe meinen Code bei 26.02.2009 14:47

Und um auch was Qualifiziertes & Philosophisches beizusteuern:

Es ist dem AVR so was von wurscht ob der Dimitri nun mit ihm klarkommt 
oder nicht.

Dieser ganze µC Kram basiert darauf, daß man irgendwelche Hürden 
überspringt, umgeht oder Probleme löst die ohne µC gar nicht da wären. 
Jeder hat da so seine Vorliebe.

Aber da dies hier ein nettes Forum, mit netten AVR Benutzern ist, 
bekommt auch jemand der Atmel nicht mag passende Hilfe.

Und da sich der OP das Project ans Bein hat binden lassen, bleibt ihm 
auch gar nix anderes übrig, als da sich mit den Eigenheiten der AVR's 
auseinanderzusetzen, da mag er soviel schimpfen, wie er will ;-)