AVR selbst-Reset, flüchtiger flash.

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

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...

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?

Ok, humorfreie Zone^^

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

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

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

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 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