AVR selbst-Reset, flüchtiger flash.

[Enrico. J. (ejoerns)]

Hey Leute,
ich bin langsam mit meinem Latein am Ende. Mich beschäftigen zwei 
Probleme:
1. Von Zeit zu Zeit kommt es vor, dass der Inhalt des Flash-Speichers 
verloren geht. Abends schalte ich ihn ein, läuft. Nächsten morgen 
schalte ich ihn ein, keine Regung mehr bzw. nichts erkennbares.
Hat da irgendwer schon ähnliche Phänomene erlebt oder Erklärungen dafür?
Reset-Pin ist mit Pullup gegen Vcc.

2. Mein AVR restarted sich lustig und ich finde nicht raus woran das 
liegt. WDT is aus. Ne normale Endlosschleife irgendwo im code sollte 
dafür dann ja nicht verantwortlich sein können. Vllt. auch dafür Ideen?

Achja, den Code Poste ich übrigens nicht, da ich bezweifle, dass sich 
jemand sich die Mühe meine 4k5 Zeilen hier durchzuschauen ;).

Danke!
Lg, Enrico

[Εrnst B. (ernst)]

Die Üblichen Verdächtigen zuerst:
Abblockkondensatoren an jedem VCC/GND Paar?

[holger (Gast)]

>1. Von Zeit zu Zeit kommt es vor, dass der Inhalt des Flash-Speichers
>verloren geht. Abends schalte ich ihn ein, läuft. Nächsten morgen
>schalte ich ihn ein, keine Regung mehr bzw. nichts erkennbares.

Hatte ich mal mit nem ATiny22. Vom schlecht entstörten
Netzteil kamen beim einschalten mehr als 7V Peaks auf
VCC. Der hat seine Programmierung auch immer über Nacht
vergessen.

[Enrico. J. (ejoerns)]

Ernst Bachmann wrote:
> Die Üblichen Verdächtigen zuerst:
> Abblockkondensatoren an jedem VCC/GND Paar?

mhh nicht an jedem, hab nur einen, aber der ist in relativer Nähe zu 
allen Anschlüssen platziert.

holger wrote:
> Hatte ich mal mit nem ATiny22. Vom schlecht entstörten
> Netzteil kamen beim einschalten mehr als 7V Peaks auf
> VCC. Der hat seine Programmierung auch immer über Nacht
> vergessen.

Bei mir sitzt nen Spannungswandler davor (ja, auch mit kondensatoren), 
sollte daher eig. net sein...

[Enrico. J. (ejoerns)]

Kann das Problem mit den Resets auch mit einem überfüllten RAM 
zusammenhängen? Schaffts der controller da im Zweifelsfall in 
irgendwelche NoGo-Areas zu schreiben?

[Gast (Gast)]

Was soll eine NoGo Area sein??? Benutz doch sinnvolle Worte und nicht 
irgendeinen Müll der gerade öfter im Fernsehen gesagt wird. Wenn der RAM 
voll ist, dürfte er normalerweise nicht mehr reagieren oder sowas in der 
Art. Ist wie beim PC.

[holger (Gast)]

>Kann das Problem mit den Resets auch mit einem überfüllten RAM
>zusammenhängen? Schaffts der controller da im Zweifelsfall in
>irgendwelche NoGo-Areas zu schreiben?

Nicht nur im Zweifelsfall. Wenn du das RAM überforderst
dann gibt es keine NoGo-Areas. Da wird gnadenlos alles platt
gemacht.

[Enrico. J. (ejoerns)]

Ok, humorfreie Zone^^

Also nen Restart wäre auch ne mögliche folge!?

[holger (Gast)]

>Also nen Restart wäre auch ne mögliche folge!?

Ja.

[Otto (Gast)]

Hast Du die "Brown-Out-Detection" eingeschaltet ?

Otto

[Peter D. (peda)]

Enrico J. wrote:
> 1. Von Zeit zu Zeit kommt es vor, dass der Inhalt des Flash-Speichers
> verloren geht. Abends schalte ich ihn ein, läuft. Nächsten morgen
> schalte ich ihn ein, keine Regung mehr bzw. nichts erkennbares.
> Hat da irgendwer schon ähnliche Phänomene erlebt oder Erklärungen dafür?
> Reset-Pin ist mit Pullup gegen Vcc.

Schalte mal das Brownout-Reset ein und die längste Resetzeit.
Wenns dann immer noch passiert, noch nen Pullup (4,7k) an SCK.


> 2. Mein AVR restarted sich lustig und ich finde nicht raus woran das
> liegt. WDT is aus.

Wenn die Applikation den Stack zerschießt oder ein Interrupt ohne 
Handler ist oder ein wilder Pointer, dann siehts aus wie ein Reset.
Ist aber keiner, der Programmcounter läuft einfach über Null.

Man kann sich den Stack mit nem Byte füllen (z.B. 0x77) und dann ab und 
zu abzählen, wieviel davon noch übrig ist.

Man sollte auch nen Bad-ISR Handler aufsetzen (GCC).


Peter

[Reinhard R. (reirawb)]

Hallo,

hast du mal den Programmspeicher des nicht mehr funktionierenden AVR 
ausgelesen und mit dem Programmiercode verglichen?

Ich hatte mal folgenden Fall:
AVR programmiert, Programm läuft, auch nach Reset. Nachdem ich die 
Betriebsspannung aus- und wieder eingeschaltet hatte, ging manchmal 
nichts mehr. Rücklesen des Flashs ergab eine Änderung des ersten und 
manchmal auch des zweiten Bytes und damit keinen Programmanlauf. Mit 
Hilfe der Newsgroup de.sci.electronics konnte das Problem gelöst werden. 
Die Ursache war ein zu langes Kabel zwischen Programmieradapter und AVR, 
das im Fehlerfall noch angestöpselt war. Der ganze Vorgang unter:

http://groups.google.de/group/de.sci.electronics/browse_thread/thread/9bcaafab08399b1c/4a77cd7967095274?hl=de&lnk=st&q=reinhard+Richter#4a77cd7967095274

Vielleicht hilfts ja.

Gruß Reinhard

[Enrico. J. (ejoerns)]

Hey, danke schonmal für die verschiedenen Tips, bin gerade noch n 
bisschen am Experimentieren.. ;)

Noch eine interessante Sache:

Wenn ich meine for-schleife 10 mal durchlaufen lasse, alles super.

Bei 100 durchläufen:

  for (uint16_t x=0; x<100;x++) {
    control_registers[x] = 0xCC;
  }

lässt sich danach mein lcd_display nicht mehr beschreiben (via i2c).
Habe bis jetzt auch da irgendwelche Speicherfehler in Verdacht gehabt.

http://www.roboternetz.de/wissen/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch

sagt allerdings, dass bis dahin noch 867Bytes frei sind...

[Marcus Woletz (Gast)]

Hallo,

wie sieht die Zeile mit der Definition von "control_registers" aus. Wäre 
schon interessant, um hier weiterzukommen ;-)

ciao

Marcus

[Enrico. J. (ejoerns)]

Marcus Woletz wrote:
> Hallo,
>
> wie sieht die Zeile mit der Definition von "control_registers" aus. Wäre
> schon interessant, um hier weiterzukommen ;-)
>
> ciao
>
> Marcus

Der letzte Fehler hat sich schon geklärt, Unfähigkeit des 
Programmierers.. ;) Naja, bei so viel zeilen und zahnschmerzen kann ichs 
mir vllt. noch verzeihen.
Aber der vollständigkeit halber liefer ich sie trotzdem nach:

volatile uint8_t control_registers[CONTROL_REGISTER_QUANTITY] \
  _attribute_ ((section (".beregister")));

Ist natürlich so noch nicht allzusehr interessant, also das auch dazu:

  .data    : AT (ADDR (.text) + SIZEOF (.text))
  {
     PROVIDE (__data_start = .) ;
    *(.beregister)
    *(.data)
    *(.data*)
    *(.rodata)  /* We need to include .rodata here if gcc is used */
    *(.rodata*) /* with -fdata-sections.  */
    *(.gnu.linkonce.d*)
    . = ALIGN(2);
     _edata = . ;
     PROVIDE (__data_end = .) ;
  }  > data

Bei weiteren experimenten mit dem linker skript avr5.x musste ich jedoch 
auch die erfahrung machen, dass man das Teil nicht zu ernst nehmen 
sollte...

Die Resets bin ich durch Array-Reduzierung auch erstmal los, werd das 
Problem wohl nur vor mir her schieben können.

Grüße
Enrico