Irrfahrt nach Neustart- was resettet der Reset alles?

Stephan schrieb:
> nach dem Brennen beginnt er artig seinen Programablauf

nach dem Brennen wird aber auch nur "Reset" losgelassen, die 
Versorgungsspannung bleibt ja auch erhalten. Dieser Reset ist genau das 
gleiche wie der Reset den du machst.

Gerade bemerkt: sein unkoscheres Verhalten hat er nur, wenn ein 
bestimmter Programmteil mitcompiliert wird?!

Die Versorgungsspannung wird, denke ich, da STK600, i.O. sein.

Peter Dannegger schrieb:
> Du solltest nach einem Reset mindestens eine Bytezeit (10/Baudrate)
> warten, ehe Du sendest, sonst kann der Empfänger sich falsch
> synchronisieren.

Er sendet nicht nur Kauderwelsch, er sendet es auch noch völlig stur und 
massenweise. Ununterbrochen halt. Werde den Vorschlag aber mal 
einpflegen.

Die Register und der RAM Inhalt bleiben bei einem Reset erhalten. Müßte 
ich aber im Datenblatt nachgucken.

An den im Kernbereich liegenden Registern bzw. RAM wird auf jeden Fall, 
beim Reset, rumgefummelt. Viele der im unteren Bereich liegenden 
Register haben sogar spezielle Initialwerte.
Wenn ich raten sollte, werden die normalen Speicherzellen in Ruhe 
gelassen. Nicht weil die Entwickler so nett sind, sondern weil unnötige 
Initialisierungen unnötig Zeit kosten.

Hi

>An den im Kernbereich liegenden Registern bzw. RAM wird auf jeden Fall,
>beim Reset, rumgefummelt.

Steht doch in den Datenbättern:

Resetting the AVR
   During reset, all I/O Registers are set to their initial values,...

Alles andere wird nicht verändert.

MfG Spess

Jörg Wunsch schrieb:
> Und in diesem Programmteil wird nicht zufällig der Watchdog aktiviert,

Nein, da findet nur ein bissel Rumgerechne statt.


Karl Heinz Buchegger schrieb:
> Das Problem ist der Empfänger.

Der Empfänger ist HTerm. Kann HTerm aus 20 unsynchronisierten Zeichen 
etwa 20 ZEILEN Müll produzieren? Ich probier es aus.

Jörg Wunsch schrieb:
> Geht's denn ohne Neuprogrammierung mit einem simplen Power-On wieder?

Nein, Kauderwelsch.

Jetzt wirds kurios.

Mein RESET-Knopf hat nun folgende (unfreiwillige) Funktion:

Drücken: Programm läuft an
Drücken: Programm läuft an und bleibt sofort stehen
Drücken: Programm läuft an
Drücken: Programm läuft an und bleibt sofort stehen
usw.usw.

In welche Tonne kommen Leiterplatten? Grau? Gelb?

Stephan schrieb:
>> Geht's denn ohne Neuprogrammierung mit einem simplen Power-On wieder?
>
> Nein, Kauderwelsch.

Power-Down Reset aktiviert und Fuses auf einen sinnvollen Wert gesetzt?

Klingt so langsam wirklich nach einer unvollständigen bzw. fehlerhaften 
Initialisierung durch Spannungseinbruch - bitte Spannungsversorgung 
nochmals penibelst kontrollieren (d. h. auch mal Spannungseinbruch bei 
"Loslassen" des Reset oszilloskopieren).

Die Register werden beim Reset auf einen Defaultwert (s. Datenblatt) 
gesetzt - so auch der Stackpointer. Der RAM wird nicht explizit durch 
eine Routine "geleert" - wozu auch? Das ist Aufgabe des Programms, d. h. 
irgendwo bei Programmadresse [Einsprungadresse + 0] muss das Programm 
die von ihm benötigten Variablen auf dem Stack "anlegen" bzw. 
initialisieren.

Welcher Compiler, welche Settings?

Patrick schrieb:
> Power-Down Reset aktiviert

= BrownOut Detection? Aktiviert, 2,7V (bei 3,3V Boardspannung)

Eigenartig: der Effekt tritt nur auf, wenn folgender Code mitcompiliert 
wird: er erzeugt aus einer Zeit in Sekunden eine n String, der diese 
Zeit als d,h,m,s darstellt.

1

void convertclock(unsigned long s)

2

{

3

  char buff[10];

4

  char buff2[10];

5

  unsigned int s2;

6

7

  s2=s/day;

8

  itoa(s2,buff2,10);

9

  strcat(buff,buff2);

10

  strcat(buff,"d,");

11

  s=s-(s2*day);

12

13

  if (s>hour)

14

  {

15

    s2=s/hour;

16

    itoa(s2,buff2,10);

17

    strcat(buff,buff2);

18

    strcat(buff,"h,");  

19

    s=s-(s2*hour);

20

  }  

21

  if(s>min)

22

  {

23

    s2=s/min;

24

    itoa(s2,buff2,10);

25

    strcat(buff,buff2);

26

    strcat(buff,"m,");  

27

    s=s-(s2*min);

28

  }  

29

  if(s>1)

30

  {  

31

    s2=s;

32

    itoa(s2,buff2,10);

33

    strcat(buff,buff2);

34

    strcat(buff,"s");

35

  }  

36

37

  strcpy(time_ascii,buff);

38

}

(Bevor Lektürehinweise auf mich einrpasseln: Habe mir ein C Buch 
gekauft: Softwareentwicklung in C für Mikroprozessoren und 
Mikrocontroller: C-Programmierung für Embedded-Systeme, aber leider 
lernt man da kaum C.)

Heiliger Bimbam.
Ok, Array ausreichend dimensioniert und LÄUFT.
Aber... ist das auch logisch?

Jörg Wunsch schrieb:
> Ja, ist ein typischer Fall von „undefiniertem Verhalten“.

Jetzt mal ernsthaft:
kann ein zu klein dimensioniertes Array dazu führen, dass eine Variable 
WÄHREND DES FLASHENS ihren Wert beibehalten? Genau das ist hier 
passiert: eine Zählvariable tickte im Sekundentakt hoch, verstummte 
während des Flashens und anschließend zählte sie weiter!

Ich verzichte auf die Analyse und pass besser auf. Erschreckend ist das! 
Vielen Dank an alle!

Stephan schrieb:
> Ich verzichte auf die Analyse und pass besser auf.

Das ist eine Möglichkeit, sowas gehört zum normalen Lernprozess. Eine 
andere Möglichkeit, defensiv zu programmieren (ich weiss nicht, ob das 
mit dem verwendeten Compiler geht):

1. Arraylänge für Zeitstring als Konstante definieren, z.B. TimeLen

2. strlcat(buff,"m,",TimeLen);  verwenden

Gruss Reinhard

Wobei da eventuell noch ein weiterer "Bock" drin ist:

 char buff[10];
 ...
 strcat(buff,buff2);

"buff" wird hier verwendet ohne das zuvor sichergestellt ist, dass das 
erste Zeichen in diesem Null ist (nicht jeder Compiler initialisiert 
"char buff[10];" automatisch mit Nullen). Somit kann der strcat wild im 
Speicher rumlaufen bis er irgendwo mal eine Null findet und ab da dann 
"buff2" hinkopiert.

Besser/Sicherer wäre hier für den ersten Kopie "strcpy" zu verwenden 
(oder am Anfang wenigstens ein "buff[0]=0;")