Usart verursacht Reset bei Rücksprung

[Bruno I. (bjnas)]

Schönen Abend,

Der einfach Code unten macht mich Wahnsinnig, die USART0_Senden() 
Funktion geht einwandfrei. Warum er mit USART_Str("Hallo") die Hallo 
zwar ausgibt, aber dann einen Reset verursacht begreife ich nicht. Als 
könnte das Programm nicht aus der USART_Str() zurückspringen?

Nutze einen Atmega128A mit einem USB-Serial Kontroller.

Irgendwo muss der Hund sein.

#include <avr/io.h>
#include <util/delay.h>

#ifndef F_CPU
#define F_CPU 8000000UL  // Systemtakt in Hz - Definition als unsigned long beachten 
#endif
 
#define BAUD 9600UL      // Baudrate, muss in Hterm gleich eingestellt sein.
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)      // Fehler in Promille, 1000 = kein Fehler.
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif

void USART0_Init( void );
void USART0_Senden( unsigned char z);
void USART_Str(const char *s);
unsigned char USART0_Receive( void );

int main(void){
     unsigned char tmp=0;

   DDRB = 0xff;
   PORTB = 0x00;
   _delay_ms(100);
         USART0_Init(); 
     
    USART0_Senden('B');
   USART0_Senden('J');
   USART0_Senden('N');
   USART0_Senden('\n');  
   _delay_ms(1000);     
   USART_Str("Hallo");
   while(1){
     PORTB = 0xff;
       if(UCSR0A & (1<<RXC0)) 
       {
         tmp=USART0_Receive();
         USART0_Senden(tmp);
       } 
         }
   return 0;
}

void USART0_Init(){                              
     UCSR0B = (1<<RXEN0)|(1<<TXEN0);
     UCSR0C = (1<<UCSZ00)|(1<<UCSZ01);
     UBRR0H = UBRR_VAL >> 8; 
     UBRR0L = UBRR_VAL & 0x0FF;
}


unsigned char USART0_Receive(){    
     while ( !(UCSR0A & (1<<RXC0)) );
    
     return UDR0;
} 


void USART_Str (const char *s){ 
   while ( !(UCSR0A & (1<<UDRE0)));   //Warten bis UDR leer ist für Senden

   while (*s){ 
      USART0_Senden(*s);         //Zeichen senden 
      s++;                    //Adresse erhöhen 
   }    
} 

void USART0_Senden( unsigned char z ){
    
     while ( !( UCSR0A & (1<<UDRE0)) );
    
     UDR0 = z;
}

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

Müssen in C die Unterprogramme immer noch mit "return" beendet werden ?

[Bruno I. (bjnas)]

Könnte ich mal versuchen, auf dem Atmega8 läuft das trotzdem fehlerfrei.

[Jim M. (turboj)]

> Müssen in C die Unterprogramme immer noch mit "return" beendet werden ?

Nicht wenn sie als "void" deklariert sind.

[Thomas B. (nichtessbar)]

_delay_ms(1000);

Dir ist klar dass das nicht hinhaut? Die Delayfunktionen funktionieren 
nur bis zu bestimmten Werten, siehe 
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

Glaub aber eher nicht dass dein Problem damit zusammenhängt. Was 
passiert, wenn du das const beim Parameter für USART_Str weglässt?

[Karl H. (kbuchegg)]

Strohhalm

> Nutze einen Atmega128A

Hast du die M103 Fuse abgeschaltet?

[Peter II (Gast)]

Thomas Bergmüller schrieb:
> _delay_ms(1000);
> Dir ist klar dass das nicht hinhaut? Die Delayfunktionen funktionieren
> nur bis zu bestimmten Werten, siehe
> http://www.nongnu.org/avr-libc/user-manual/group__...
hast du dir überhaupt mal durchgelese was dort steht, wenn du schon die 
quelle angibst?

> When the user request delay which exceed the maximum possible one,
> _delay_ms() provides a decreased resolution functionality. In this
> mode _delay_ms() will work with a resolution of 1/10 ms, providing
> delays up to 6.5535 seconds (independent from CPU frequency). The
> user will not be informed about decreased resolution.


@Bruno In.
das delay ist ok.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Der Fehler ist revht einfach du hast den String nicht terminiert.

USART_Str("Hallo");
machste zu:
USART_Str("Hallo\0");

Dadurch Terminiert dein while(*s) nicht da ein Nullzeichen fehlt.

[Peter II (Gast)]

Martin Wende schrieb:
> Der Fehler ist revht einfach du hast den String nicht terminiert.

was soll denn das hier? Es geht um C - da ist jeder Sting der mit "" 
geschrieben wird terminiert.

[Oliver J. (skriptkiddy)]

Martin Wende schrieb:
> Dadurch Terminiert dein while(*s) nicht da ein Nullzeichen fehlt.

Dääd - falsch.

"" terminiert automatisch

Gruß Oliver

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch 
immer weggelassen und da stand dann aufm LCD der gesamte 
Speicherinhalt...

[Peter II (Gast)]

Martin Wende schrieb:
> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch
> immer weggelassen und da stand dann aufm LCD der gesamte
> Speicherinhalt...
dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler 
gemacht.

[Thomas E. (thomase)]

Peter II schrieb:
> dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler
> gemacht.
Doch.
Das ist der hundertmillionste Compiler. Der hat diesen Fehler. Den kann 
man gegen einen Goldbarren und einen funktionierenden eintauschen.

mfg.

[Oliver J. (skriptkiddy)]

Martin Wende schrieb:
> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch
> immer weggelassen und da stand dann aufm LCD der gesamte
> Speicherinhalt...

Du meinst nicht zufällig diese Art der Deklaration?

char str[]={'H','A','L','L','O','\0'};

oder sogar sowas?

str[0] = 'H';
str[1] = 'A';
str[2] = 'L';
str[3] = 'L';
str[4] = 'O';
str[5] = '\0';

Gruß Oliver

[Oliver J. (skriptkiddy)]

Thomas Eckmann schrieb:
> Doch.
> Das ist der hundertmillionste Compiler. Der hat diesen Fehler. Den kann
> man gegen einen Goldbarren und einen funktionierenden eintauschen.
>
> mfg.

Hoffe das war ironisch gemeint?

Gruß Oliver

[Thomas E. (thomase)]

Oliver J. schrieb:
> Hoffe das war ironisch gemeint?
Nee. Ich bin sowas von humorlos.

mfg.

[Oliver J. (skriptkiddy)]

Thomas Eckmann schrieb:
> Oliver J. schrieb:
>> Hoffe das war ironisch gemeint?
> Nee.

Doch. :)

[Johann L. (gjlayde)]

Peter II schrieb:
> Martin Wende schrieb:
>> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch
>> immer weggelassen und da stand dann aufm LCD der gesamte
>> Speicherinhalt...
> dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler
> gemacht.

Jedenfalls wurde solch ein Fehler nie berichtet, und ich hab die avr-gcc 
Fehler ziemlich genau im Blick.

Also Martin, her mit dem Testfall, der Compilerversion und den Optionen 
:-)

[Thomas E. (thomase)]

Johann L. schrieb:
> Also Martin, her mit dem Testfall, der Compilerversion und den Optionen
Dann müsste er sich ja selber hochladen.

mfg.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Is schon lange her, machte im Hirn nur klick und ich habs getippt, 
also lasst meine Eingeweide da wo sie hingehören.

[Weingut P. (weinbauer)]

ist das wirklich so, dass bei

while (*s){

und Inhalt = 0 die Schleife verlassen wird?

Davon abgesehen, das Programm hängt dann ewig in der schnarchlangsamen 
UART-Routine fest bei der Programmausführung.
Es wär evtl. sinnvoll mal über den TXC Flag zum Einen und den 
TXC-Interrupt im Besonderen nachzudenken.

[Peter II (Gast)]

Fhutdhb Ufzjjuz schrieb:
> ist das wirklich so, dass bei
>
> while (*s){
>
> und Inhalt = 0 die Schleife verlassen wird?

ja

[Thomas B. (nichtessbar)]

Peter II schrieb:
>> http://www.nongnu.org/avr-libc/user-manual/group__...
> hast du dir überhaupt mal durchgelese was dort steht, wenn du schon die
> quelle angibst?

Ich glaub ich muss mich entschuldigen, sehr peinlich... (wobei ich 
solche langen Delays üblicherweise mit einem Timer lösen würde, dann 
kann der Prozessor inzwischen was anderes tun (auch wenns hier im 
Beispiel wenig Sinn machen wird))

[Bruno I. (bjnas)]

Sorry, war den ganzen Tag auf dem Bau. Habe ja eine Flut von Antworten 
erhalten. Super, Werde es sofort durchchecken.


Karl Heinz Buchegger schrieb:
> Hast du die M103 Fuse abgeschaltet?

Nein. Werde ich sofort mal machen.

>_delay_ms(1000);

Die waren zum Testen, sonst resetet der so schnell.

>USART_Str("Hallo\0");

Auch schon versucht, gleiches Resultat.

>while (*s)

Hier habe ich schon getestet mit einem Aufruf ohne Pointer, genau 
dasselbe.


Danke für die vielen Hinweise.

bjn

[Bruno I. (bjnas)]

Das gibt's ja nicht, Du bist Super Karl Heinz.

> Karl Heinz Buchegger schrieb:
>> Hast du die M103 Fuse abgeschaltet?

Das war's schon, die M103 Fuse. Habe das mal nachgeschlagen im 
Datenblatt. Der wird ja mit dem Watchdog zusammen beschrieben. Steig 
leider nicht ganz durch, mein Englisch ist schwach ;-{ .

Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf 
zuntun.

Die Tiefen der Mikrokontroller.

[Peter II (Gast)]

Bruno In. schrieb:
> Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf
> zuntun.

überhaupt nichts.

> an ATmega103 compatibility mode can be selected by programming
> the fuse M103C
damit hat er andere Register und Upcodes - der µC hat also eine eine 
Sprache verstanden.

[Stefan E. (sternst)]

Bruno In. schrieb:
> Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf
> zuntun.

Der Compiler ist von einem Mega128 ausgegangen, und hat Code erzeugt, 
der den Stack-Pointer auf das Ende des RAM des Mega128 initialisiert. 
Der Controller ist aber in Wirklichkeit ein Mega103 (wegen der Fuse). 
Bei dem endet das RAM eher (weil er weniger Register hat und daher das 
RAM auch eher anfängt). Somit zeigt der Stack-Pointer auf eine Adresse, 
an der gar kein RAM ist, und damit geht das erste ret mit ziemlicher 
Sicherheit in die Hose.

[Bruno I. (bjnas)]

Ja ,das wars wohl.

Danke für die Erklärung

Schönen Abend noch