UART arbeitet bei Codeänderung nicht mehr, ATmega16

[Albert .. (albert-k)]

Hallo zusammen
Ich habe derzeit ein komisches Verhalten beim ATmega16. Folgende 
Konfiguration:
- ATmega16 @4MHz internen Oszillator
- Kommunikation über RS232 @ 19200Baud

Nun zu meinem Problem:
Ich versuche derzeit die FAT32 Lib von hier zu verwenden:
http://www.mikrocontroller.net/articles/AVR_FAT32
Es tritt jetzt jedoch ein Fehlverhalten des Controllers auf das ich 
nicht nachvollziehen kann.

Wenn ich folgenden Code verwende

int main(void){
  u8Flag = 0;
  //Datei die auf SD Karte angelegt werden soll
  unsigned char file_name [] = "test.txt";
  //String der in die Datei geschrieben werden soll
  unsigned char str [] = "Hallo Datei!";

  unsigned long int seek;

  _delay_ms(200);  //dummy delay
  gvUsartConfig(&tdsUsartConfig);
  MAKRO_USART_ENABLE_CHANNELS(USART_TX);

  timer0_init();
  vPortInit();

  gvUsartPutStringPolling("Startup\n");
  gvUsartPutCharPolling(TERM_CARRIAGE_RETURN);

  if( FALSE == mmc_init() ){
      gvUsartPutStringPolling("No SD Card!\n");
      //gvUsartPutCharPolling(TERM_CARRIAGE_RETURN);
      return 1;
    }
        /*
          Ab hier alles gleich
        */

Hier einmal kurz die Funktionen für das senden:

void gvUsartPutCharPolling(const uint8_t u8Char){
  while(!(UCSRA & (1<<UDRE)));  //wait until transmission possible
  UDR = u8Char;          //write char into transmit buffer
}

void gvUsartPutStringPolling(const char* u8String){
  while(*u8String != '\0'){
    gvUsartPutCharPolling((uint8_t)*u8String);
    u8String++;
  }
}

Wenn ich keine SD-Karte anschließe habe ich das gewünschte Verhalten=> 
Das Programm startet immer wieder neu da mmc_init einen Fehler 
zurückliefert.

Nun aber zu meinem seltsammen verhalten:
Wenn ich die Codezeile

gvUsartPutCharPolling(TERM_CARRIAGE_RETURN);

herausnehme wird gar nichts mehr über RS232 herausgesendet, nicht einmal 
irgendwelcher Unsinn.
Dieser Fehler tritt auch bei noch minimalistischeren Code auf (Nur 
initialisierung und dann senden). Manchmal nimmt er alles an, dann beim 
hinzufügen eines weiteren sendebefehls geht wieder gar nichts usw.

Ich kann mir nicht erklären woher dieser Fehler nun kommt. Das einzige 
das ich mir erklären kann ist das der Controller in irgendeinen Reset 
wegen eines Fehler reinspringt. Leider habe ich keinen Debugger um der 
Vermutung nachzugehen.
Hatte mal jmd. ein ähnliches Problem und hat eine Lösung gefunden?

[Peter D. (pdiener)]

Der interne Oszillator ist zu ungenau. Ohne Kalibrierung ist er 
ungeeignet zum Takten einer UART. Die Kalibrierung sollte der Controller 
regelmäßig selbst gegen eine Taktreferenz vornehmen. Die Alternative ist 
das Verwenden eines Quarzes.

Grüße,

Peter

[A.N. (Gast)]

Salut ..

 gvUsartConfig(&tdsUsartConfig);
 MAKRO_USART_ENABLE_CHANNELS(USART_TX);

ist vielleicht schuld? Dummerweise hat meine Glaskugel gerade just in
dem Moment die Batterien leer gehabt ^^

[Albert .. (albert-k)]

Peter Diener schrieb:
> Der interne Oszillator ist zu ungenau. Ohne Kalibrierung ist er
> ungeeignet zum Takten einer UART. Die Kalibrierung sollte der Controller
> regelmäßig selbst gegen eine Taktreferenz vornehmen. Die Alternative ist
> das Verwenden eines Quarzes.
Die Übertragung funktioniert aber einwandfrei, wenn ich das Carriage 
Return drinnen lasse kann ich Stundenlang senden ohne Probleme. Aber 
sobald diese Codezeile herausgenommen wird geht gar nichts mehr.

A.N. schrieb:
> gvUsartConfig(&tdsUsartConfig);
>  MAKRO_USART_ENABLE_CHANNELS(USART_TX);
>
> ist vielleicht schuld? Dummerweise hat meine Glaskugel gerade just in
> dem Moment die Batterien leer gehabt ^^
Das kann ich mir nicht denken, denn dann dürfte es ja nie funktionieren. 
Es funktioniert aber solange ich ein Carriage return versende. Sobald 
keines mehr versendet wird gibt es Probleme.

Als weiterer Hinweis:
Die Funktionen zur Intialisierung und aktivieren des Uart funktionieren 
in anderen programmen auf anderen ATmegas einwandfrei. Nur dieser ATmega 
macht derzeit Probleme.

[Peter D. (pdiener)]

Bei Timingfehlern an einer UART sind Fehlerbilder wie dieses nicht 
ungewöhnich. Meine Meinung ist unverändert, dass es mit großer 
Wahrscheinlichkeit am Oszillator liegt.

Grüße,

Peter

[Albert .. (albert-k)]

Ich habe den Controller nun auf externen Quarz umgestellt. Das 
Fehlerbild ist Haargenau das gleiche.

[Stefan E. (sternst)]

Albert ... schrieb:
> Wenn ich keine SD-Karte anschließe habe ich das gewünschte Verhalten=>
> Das Programm startet immer wieder neu da mmc_init einen Fehler
> zurückliefert.

Welche Toolchain verwendest du? Bei avr-gcc/AVRLibc wäre ein Neustart 
bei return aus main ein Fehlverhalten.

Dein Controller hat bloß 1k RAM. Eine FAT32-Lib zusammen mit der 
Tatsache, dass du dir über RAM-Verbrauch wohl keine allzu großen 
Gedanken machst (wenn ich die ganzen Strings im RAM sehe), ich schätze 
dir wird einfach das RAM ausgegangen sein. Und wenn der Stack in die 
Variablen läuft, gibt das dann alle möglichen Effekte.

[Albert .. (albert-k)]

Stefan Ernst schrieb:
> Dein Controller hat bloß 1k RAM. Eine FAT32-Lib zusammen mit der
> Tatsache, dass du dir über RAM-Verbrauch wohl keine allzu großen
> Gedanken machst (wenn ich die ganzen Strings im RAM sehe), ich schätze
> dir wird einfach das RAM ausgegangen sein. Und wenn der Stack in die
> Variablen läuft, gibt das dann alle möglichen Effekte.
Der RAM-Verbrauch liegt bei 703 Bytes (68.7%). Da glaube ich nicht das 
es zu einem Stack-Überlauf kommt. Oder doch?

[Peter D. (pdiener)]

Es kommt darauf an, was alles dynamisch allokiert wird.

Ich finde es trotzdem komisch, dass beim Senden eines \n nach
gvUsartPutStringPolling("Startup\n");
das "Startup" nicht mehr angezeigt wird. Das deutet auf einen 
Timingfehler hin, den der PC ab einer bestimmten Anzahl kontinuiertlich 
übertragenen Zeichen erkennen kann und den ganzen Puffer verwirft.

Mich würde mal die Implementierung der UART Initialisierung 
interessieren.

Grüße,

Peter

[Albert .. (albert-k)]

Hier die Uart initialisierung:

//-----------------------------------------------------------------------
//  USART Configuration struct inside Flash
//-----------------------------------------------------------------------
typedef struct {
  uint8_t u8Baudrate;  //use preprocessor calculated UBRR_VAL
  uint8_t u8Mode;
  uint8_t u8Parity;
  uint8_t u8StopBits;
  uint8_t u8BitSize;
  uint8_t u8ClockPolarity;
}const tdsUSART_CONFIG;

void gvUsartConfig(const tdsUSART_CONFIG* ptdsUsartConfig){

  PGM_P pgm_pData     = (PGM_P)ptdsUsartConfig;
  uint8_t u8BitSize    = pgm_read_word(&(ptdsUsartConfig->u8BitSize));
  uint8_t u8ClockPolarity  = pgm_read_word(&(ptdsUsartConfig->u8ClockPolarity));

  //Pin Configuration
  DDRD |= (1<<PD1);  //set Tx Pin PIND.1 to output
  DDRD &= ~(1<<PD0);  //set Rx Pin PIND.0 to Input
  PORTD |= (1<<PD0);  //set Pullup

  //Configure Baudrate
  UBRRH = pgm_read_word(pgm_pData) >> 8;  //set higher baudrate value first
  UBRRL = pgm_read_word(pgm_pData) & 0xFF;  //set second baudrate value
  pgm_pData++;

  //set Mode
  UCSRC |= (1<<URSEL) | (pgm_read_word(pgm_pData)<<6);
  pgm_pData++;

  //set parity
  UCSRC |= (pgm_read_word(pgm_pData)<<4) | (1<<URSEL);
  pgm_pData++;

  //set Stop bits
  UCSRC |= (1<<URSEL) | (pgm_read_word(pgm_pData)<<3);
  pgm_pData++;

  //Configure number of bits. Check if UCSZ2 bit must be set
  if(u8BitSize & 0x04){
    UCSRB |= (1<<UCSZ2);
  }
  //set Bitsize
  UCSRC |= (1<<URSEL) | ((u8BitSize & 0x03)<<1);

  //set clock polarity
  UCSRC |= u8ClockPolarity;
}

[Peter D. (pdiener)]

>uint8_t u8Baudrate

>PGM_P pgm_pData     = (PGM_P)ptdsUsartConfig;

>UBRRH = pgm_read_word(pgm_pData) >> 8;  //set higher baudrate value first
>UBRRL = pgm_read_word(pgm_pData) & 0xFF;  //set second baudrate value
>pgm_pData++;

pgm_pData wird als Pointer auf das erste Element in dem Struct 
initialisiert, das ist u8Baudrate. Das Ziel ist also ist 8 Bit groß. 
Dann wird versucht, ein 16 Bit breites Wort an dieser Stelle zu lesen. 
Und danach der Pointer um 1 Byte hochgestellt. Das passt doch alles 
nicht zusammen.

Grüße,

Peter

[Stefan E. (sternst)]

Da wird einfach alles per pgm_read_word gelesen, obwohl alles nur 
uint8_t ist.

Die ganze Vorgehensweise, die einzelnen Elemente der Struct über einen 
fortlaufenden Pointer zu lesen, ist äußerst fragwürdig. Und zudem auch 
völlig überflüssig, und auch noch komplizierter und unübersichtlicher, 
als der normale Weg.

PS: Und was ist eigentlich mit der Frage nach der Toolchain und den 
Neustarts?

[Albert .. (albert-k)]

Peter Diener schrieb:
> pgm_pData wird als Pointer auf das erste Element in dem Struct
> initialisiert, das ist u8Baudrate. Das Ziel ist also ist 8 Bit groß.
> Dann wird versucht, ein 16 Bit breites Wort an dieser Stelle zu lesen.
> Und danach der Pointer um 1 Byte hochgestellt. Das passt doch alles
> nicht zusammen.

Da hast du natürlich recht, habe nun Baudrate auf 16 Bit geändert und 
die Initialisierung angepasst.
Mich wundert es nur das es bei anderen Projekten geklappt hatte.

[Peter D. (pdiener)]

Und genau das führt dazu, dass in UBRR nicht das steht, was dort 
hingehört, sondern etwas anderes, das sich zum Teil auch aus u8Mode 
zusammensetzt.

Daher kommt der Timingfehler, die UART läuft also mit der falschen 
Baudrate. Auch die anderen vorgenommenen Konfigurationen sind von diesem 
Grundlegenden Fehler betroffen.

Grüße,

Peter

[Albert .. (albert-k)]

Stefan Ernst schrieb:
> PS: Und was ist eigentlich mit der Frage nach der Toolchain und den
> Neustarts?
Als Toolchain verwende ich Eclipse+WinAVR. Das mit dem return hatte ich 
aus dem Beispiel zur FAT32 Lib herausgenommen und nicht weiter 
hinterfragt.

[Stefan E. (sternst)]

UCSRC |= (1<<URSEL) | (pgm_read_word(pgm_pData)<<6);
...
  UCSRC |= (pgm_read_word(pgm_pData)<<4) | (1<<URSEL);

Und auch das ist Unsinn. Du kannst bei UCSRC nicht mit "|=" arbeiten, 
weil dabei der Inhalt aus UBRRH genommen und verodert wird.

Sorry, aber die ganze Funktion ist ziemlicher Murks.