ATmega32 läuft nicht richtig an

[bizy (Gast)]

Hallo,

ich habe ein sehr merkwürdiges Problem. Mein ATmeaga32 läuft nicht immer 
an! Ich habe ein display und einen Drehencoder dran hängen. Schalte ich 
die Spannungsversorgung ein, so bekomme ich nur schwarze Balken auf dem 
Display und der Controller reagiert nicht auf den Drehencoder. Das 
heißt, der ATmega hängt oder startet nicht. ???

-Ich habe Reset mit 10k gegen 5V und 47n gegen GND geschaltet.
-Beide GND-Pins liegen auf Masse.
-AVCC ist gegen 5V geschaltet (ADC wird nicht verwendet).
-8MHz Quartz mit 27pF Kondensatoren.
-Fuse steht auf   Ext.Crystal Medium Frequency 16K CK + 64ms
-100nF zwischen dem GND und VCC Pin.

Das komische ist, der Fehler tritt nicht immer auf. wenn ich die 
Spannungsversorgung lange getrennt lasse, und dann wieder zuschalte 
läuft er normal an (LCD initalisiert und Reaktion auf Drehencoder). ???

Ich bin am verzweifeln....

[Olli (Gast)]

Hast du auch ein Programm geflasht???
Sonst scheint mir das recht normal...

[Olli (Gast)]

Aaargh letzten Satz iwie überlesen. Sorry. Bitte den hier und den 
letzten Post löschen...

[holger (Gast)]

>-8MHz Quartz mit 27pF Kondensatoren.

Versuch mal 18pF.

>-Fuse steht auf   Ext.Crystal Medium Frequency 16K CK + 64ms

Nimm High Frequency.
Dann noch die Brownout Fuses aktivieren und gut.

[bizy (Gast)]

>Nimm High Frequency.
>Dann noch die Brownout Fuses aktivieren und gut.

Habe ich gemacht. Keine Besserung.

>Versuch mal 18pF.

Leider nicht greifbar. :-(

[Uwe S. (de0508)]

Ich würde die 47nF auslöten.

[bizy (Gast)]

Er reagiert auch nicht auf den Reset, d.h. wenn ich den Reset-Pin mal 
kurz auf Masse schalte bringt auch keinen Anlauf.
Wenn der Controller mal läuft und ich den Reset betätige, bleibt er 
einfach hängen. ???

[bizy (Gast)]

>Ich würde die 47nF auslöten.

Ich hatte den 47nF schon mal probehalber draußen, hat nichts gebracht.

[Uwe S. (de0508)]

Gibts denn ein Bild und einen Schaltplan, evtl. auch ein Video.

Denn so eine verhalten kann ich mir aus der Ferne leider nicht erklären.

Wie wird der atmega32 programmiert ?

PER ISP ? über welchen Programmer und welche Prog. Sprache wird 
verwendet ?

[holger (Gast)]

>Er reagiert auch nicht auf den Reset, d.h. wenn ich den Reset-Pin mal
>kurz auf Masse schalte bringt auch keinen Anlauf.
>Wenn der Controller mal läuft und ich den Reset betätige, bleibt er
>einfach hängen. ???

Dann schwingt der Quarz nicht an. Das bedeutet zu kleine
oder zu große Lastkapazitäten für den Quarz. Nimm die
27p doch einfach mal raus oder schalte, wenn du da hast,
zweimal 27pF in Reihe.

[bizy (Gast)]

Hallo Uwe,

ich habe die 27p gegen 22p getauscht und den 47n auch nochmal entfernt. 
Nichts gebracht...

Ich verwende den USBprog (ISP mode) mit AVR Studio 4.18 und dem GCC.

Video und Schaltplan sind nicht vorhanden. sry

[Uwe S. (de0508)]

Hallo bizy,

Ich denke holger hat nicht unrecht:
es ist der Quarz, vielleicht ist der schon mal hingefallen ?

[Daniel S. (ds1982)]

Uwe S. schrieb:

> Ich denke holger hat nicht unrecht:
> es ist der Quarz, vielleicht ist der schon mal hingefallen ?

Ist möglich. Um das zu checken schalte doch mal auf den internen Takt um 
und beobachte ob das Problem damit auch auftritt, wenn nicht ists 
tatsächlich der Quarz.

[holger (Gast)]

>Ist möglich. Um das zu checken schalte doch mal auf den internen Takt um
>und beobachte ob das Problem damit auch auftritt, wenn nicht ists
>tatsächlich der Quarz.

Oder die Kondensatoren sind nicht an GND angeschlossen.
Alles schon mal da gewesen;)

[bizy (Gast)]

>Ist möglich. Um das zu checken schalte doch mal auf den internen Takt um
>und beobachte ob das Problem damit auch auftritt, wenn nicht ists
>tatsächlich der Quarz.

Habs geprüft, funktioniert auch mit internem 8MHz Oszillator nicht. :-(

>Oder die Kondensatoren sind nicht an GND angeschlossen.
>Alles schon mal da gewesen;)

Sie sind es.

[holger (Gast)]

>Habs geprüft, funktioniert auch mit internem 8MHz Oszillator nicht. :-(

Tja, dann hängt halt dein Programm irgendwo.
Benutzt du den Busy Check vom LCD?

[holger (Gast)]

Nachtrag: Wenn der AVR per ISP programmierbar ist dann läuft
der Quarz ja auch. Also völlig falsche Fährte zur Fehlersuche.
Zu lange schon nichts mehr mit den Dingern gemacht;)

[Charly B. (charly)]

Diode parallel zum reset Widerstand, Kathode an plus
(L103 o. BAT46 o. 1N4148....)

vlG
Charly

[bizy (Gast)]

Ich nutze die LCD lib von Fleury. Ich kann mir nicht vorstellen wo der 
controller hängen bleibt.

int main(void)
{
  
  
  //Ausgänge definieren
  DDRC = (1<<CELL_PHONE_DD)|(1<<MOTOR_POWER_DD)|(1<<MOTOR_DIRECTION_DD)|(1<<LCD_BACKLIGHT_DD);
  DDRD = (1<<L1L2_POWER_DD);
  //Pullups aktivieren
  PORTD |= (1<<ENCODER_BUTTON_PIN)|(1<<ENCODER_A_PIN)|(1<<ENCODER_B_PIN)|(1<<RX_PIN);
  PORTC |= (1<<MOTOR_CLOSE_SWITCH_PIN)|(1<<MOTOR_OPEN_SWITCH_PIN)|(1<<L1_PIN)|(1<<L2_PIN); 
  PORTA |= (1<<DAWN_PIN);
  PORTB |= (1<<MAN_DOOR_BUTTON_PIN);

  lcd_init(LCD_DISP_ON);


  timer1_init();
  timer0_init();

 while(1)
 {
....

Nach der lcd_init(...) sollten die schwarzen Balken weg sein. Sobald die 
Timer initialisiert sind, läuft eine ISR die den Drehencoder abfragt.
Beides geht aber nicht immer (wie oben beschrieben).

Ich habe auch schon die lcd_init unter die timer_inits geschoben. Macht 
keinen Unterschied.

[bizy (Gast)]

>Diode parallel zum reset Widerstand, Kathode an plus

Schon dran gelötet.

[bizy (Gast)]

>Benutzt du den Busy Check vom LCD?

So wie es aussieht wird Busy Flag nicht gelesen (LCD-4Bit-Modus):

void lcd_init(uint8_t dispAttr)
{
#if LCD_IO_MODE
    /*
     *  Initialize LCD to 4 bit I/O mode
     */
     
    if ( ( &LCD_DATA0_PORT == &LCD_DATA1_PORT) && ( &LCD_DATA1_PORT == &LCD_DATA2_PORT ) && ( &LCD_DATA2_PORT == &LCD_DATA3_PORT )
      && ( &LCD_RS_PORT == &LCD_DATA0_PORT) && ( &LCD_RW_PORT == &LCD_DATA0_PORT) && (&LCD_E_PORT == &LCD_DATA0_PORT)
      && (LCD_DATA0_PIN == 0 ) && (LCD_DATA1_PIN == 1) && (LCD_DATA2_PIN == 2) && (LCD_DATA3_PIN == 3) 
      && (LCD_RS_PIN == 4 ) && (LCD_RW_PIN == 5) && (LCD_E_PIN == 6 ) )
    {
        /* configure all port bits as output (all LCD lines on same port) */
        DDR(LCD_DATA0_PORT) |= 0x7F;
    }
    else if ( ( &LCD_DATA0_PORT == &LCD_DATA1_PORT) && ( &LCD_DATA1_PORT == &LCD_DATA2_PORT ) && ( &LCD_DATA2_PORT == &LCD_DATA3_PORT )
           && (LCD_DATA0_PIN == 0 ) && (LCD_DATA1_PIN == 1) && (LCD_DATA2_PIN == 2) && (LCD_DATA3_PIN == 3) )
    {
        /* configure all port bits as output (all LCD data lines on same port, but control lines on different ports) */
        DDR(LCD_DATA0_PORT) |= 0x0F;
        DDR(LCD_RS_PORT)    |= _BV(LCD_RS_PIN);
        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);
        DDR(LCD_E_PORT)     |= _BV(LCD_E_PIN);
    }
    else
    {
        /* configure all port bits as output (LCD data and control lines on different ports */
        DDR(LCD_RS_PORT)    |= _BV(LCD_RS_PIN);
        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);
        DDR(LCD_E_PORT)     |= _BV(LCD_E_PIN);
        DDR(LCD_DATA0_PORT) |= _BV(LCD_DATA0_PIN);
        DDR(LCD_DATA1_PORT) |= _BV(LCD_DATA1_PIN);
        DDR(LCD_DATA2_PORT) |= _BV(LCD_DATA2_PIN);
        DDR(LCD_DATA3_PORT) |= _BV(LCD_DATA3_PIN);
    }
    delay(16000);        /* wait 16ms or more after power-on       */
    
    /* initial write to lcd is 8bit */
    LCD_DATA1_PORT |= _BV(LCD_DATA1_PIN);  // _BV(LCD_FUNCTION)>>4;
    LCD_DATA0_PORT |= _BV(LCD_DATA0_PIN);  // _BV(LCD_FUNCTION_8BIT)>>4;
    lcd_e_toggle();
    delay(4992);         /* delay, busy flag can't be checked here */
   
    /* repeat last command */ 
    lcd_e_toggle();      
    delay(64);           /* delay, busy flag can't be checked here */
    
    /* repeat last command a third time */
    lcd_e_toggle();      
    delay(64);           /* delay, busy flag can't be checked here */

    /* now configure for 4bit mode */
    LCD_DATA0_PORT &= ~_BV(LCD_DATA0_PIN);   // LCD_FUNCTION_4BIT_1LINE>>4
    lcd_e_toggle();
    delay(64);           /* some displays need this additional delay */
    
    /* from now the LCD only accepts 4 bit I/O, we can use lcd_command() */    
#else
    /*
     * Initialize LCD to 8 bit memory mapped mode
     */
    
    /* enable external SRAM (memory mapped lcd) and one wait state */        
    MCUCR = _BV(SRE) | _BV(SRW);

    /* reset LCD */
    delay(16000);                           /* wait 16ms after power-on     */
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                   
    delay(4992);                            /* wait 5ms                     */
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                 
    delay(64);                              /* wait 64us                    */
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                
    delay(64);                              /* wait 64us                    */
#endif

#if KS0073_4LINES_MODE
    /* Display with KS0073 controller requires special commands for enabling 4 line mode */
  lcd_command(KS0073_EXTENDED_FUNCTION_REGISTER_ON);
  lcd_command(KS0073_4LINES_MODE);
  lcd_command(KS0073_EXTENDED_FUNCTION_REGISTER_OFF);
#else
    lcd_command(LCD_FUNCTION_DEFAULT);      /* function set: display lines  */
#endif
    lcd_command(LCD_DISP_OFF);              /* display off                  */
    lcd_clrscr();                           /* display clear                */ 
    lcd_command(LCD_MODE_DEFAULT);          /* set entry mode               */
    lcd_command(dispAttr);                  /* display/cursor control       */

}/* lcd_init */

[holger (Gast)]

>Nach der lcd_init(...) sollten die schwarzen Balken weg sein.

Sollte, könnte, müsste, bla bla. Schreib dir mal ein
Miniprogramm nur mit lcd_init und schau mal ob du da
überhaupt wieder raus kommst. Den Rest deines Programmes
vergisst du erstmal.

[holger (Gast)]

>>Benutzt du den Busy Check vom LCD?
>
>So wie es aussieht wird Busy Flag nicht gelesen (LCD-4Bit-Modus):

Wozu soll das dann gut sein?

        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);

Es spricht alles dafür das vom Display auch gelesen wird.
Vermutlich hängt dein Programm da.

[Klaus D. (kolisson)]

holger schrieb:
> Nachtrag: Wenn der AVR per ISP programmierbar ist dann läuft
> der Quarz ja auch. Also völlig falsche Fährte zur Fehlersuche.
> Zu lange schon nichts mehr mit den Dingern gemacht;)

Daist der Holger mit "der falschen Fährte" ja auf der richtigen Fährte,
zudem ja auch der interne 8Mhz die gleichen Sorgen zu machen scheint.

Nun hilft dann nur noch die Software zur analyse.
Vielleicht ein Dauerinterrupt .. ?

Aber eigentlich solltest du (Fragesteller) das selber ermitteln können.
Du musst doch nur ein Print"Ich bin hier" an geeigneten Stellen deines
Programmes einfügen und kannst am Terminal dann alles ablesen.

@bizy  .. nun stell dich nicht so an

Gruss k.

[bizy (Gast)]

So wie es aussieht lag es tatsächlich am Programm. ABer nicht wie 
vermutet in der lcd_init(), sondern wegen eines Makros was das USART 
nutzt, welches aber nicht initalisiert war. Oh man, so ein dummer 
Fehler! XD

Danke an euch alle für die Unterstützung!

[bizy (Gast)]

>@bizy  .. nun stell dich nicht so an

???

[holger (Gast)]

>sondern wegen eines Makros was das USART
>nutzt, welches aber nicht initalisiert war. Oh man, so ein dummer
>Fehler! XD

Wieder mal ein schönes Beispiel das man zu Fragen
ohne kompletten Quellcode am besten gar keine Antwort gibt.
Fragesteller einfach verhungern lassen.

[bizy (Gast)]

holger schrieb:
> Wieder mal ein schönes Beispiel das man zu Fragen
> ohne kompletten Quellcode am besten gar keine Antwort gibt.
> Fragesteller einfach verhungern lassen.

Wo liegt dein Problem, der Fehler wurde nach und nach eingekreist und 
dann gefunden.

[Klaus D. (kolisson)]

holger schrieb:
>>sondern wegen eines Makros was das USART
>>nutzt, welches aber nicht initalisiert war. Oh man, so ein dummer
>>Fehler! XD
>
> Wieder mal ein schönes Beispiel das man zu Fragen
> ohne kompletten Quellcode am besten gar keine Antwort gibt.
> Fragesteller einfach verhungern lassen.

YES Holger,
vielleicht einfach so antworten wie die Computer in 
Sciencefichtionfilmen
"PIEP ! .. eine Beantwortung der Frage ist aufgrund fehlender 
Informationen
nicht möglich ... PIEP! .. Bitte präzisieren Sie Ihre Frage .. PIEP !!"

Es gibt ja Leute, die wundern sich über ein Schmatzgeräusch wenn diese
so durch die Welt laufen. Fast automatisch schauen sie dann alle paar
Meter unter ihre Schuhe, da sie annehmen, dass sie in Hundekot getreten
wären. Interessanterweise wiederholt sich das Verhalten alle 10 
schritte,
obwohl ja schon die erste visuelle Kontrolle der Schuhsohle gezeigt 
hatte,
dass dort kein Hundekot hängt.

Die haben kein Vertrauen auf ihre Sinne und gehn dann zum Doctor.
Dann stellt sich raus, dass zuviel Schmalz in den Ohren war.


Gruss k.

[bizy (Gast)]

@Klaus De lisson

Ohje, bei so viel Arroganz ist es besser zu gehen. Das Forum scheint 
immer schlimmer zu werden...schade.
Mag sein dass ich ein schlechtes Beispiel für die Fehlersuche geliefert 
habe, beispiellos ist aber auch dein Auftreten :-(

[Klaus D. (kolisson)]

@
Autor: bizy (Gast)
Datum: 10.08.2011 23:53


ich meinte dich nicht persönlich...
es war so "allgemein gemeint "

k.

[Sepp (Gast)]

vielleicht nochmals zurück zum ausgangsthema:

KS066 LCD-Kontroller haben ein Problem damit, wenn man während des 
Betriebs mehrer "lcd-inits" durchführt. Das Display zeigt dann - wie 
beschrieben - in der obersten Zeile einen schwarzen Balken. (Bei 
vierzeiligen Displays 1. und. 3 Zeile - sind ja aus 2 zweizieligen 
aufgebaut).

Wenn die Betriebsspannung des Displays abgeschaltet wird, kann wieder 
eine neue Initialisierung durchgeführt werden.

Bei einem Controllerreset bleibt die Spannung am LCD erhalten und es 
werden im Zuge der Initialisierungsroutine am µC ein "lcd-init" 
ausgeführt was dann den Fehler mit dem schwarzen Balken auslöst.

Dauerhaft gelöst werden kann das Problem indem man das Display über 
einen Controllerpin versorgt, so wird bei einem µC Reset auch das 
Display geresetet (Anglizismen leben hoch...)

lg
Sepp