ATmega32 läuft nicht richtig an

Gast #2300249
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....
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.
Gast
>Nimm High Frequency.
>Dann noch die Brownout Fuses aktivieren und gut.

Habe ich gemacht. Keine Besserung.

>Versuch mal 18pF.

Leider nicht greifbar. :-(
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. ???
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 ?
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.
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
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;)
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.
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?
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;)
Gast
Ich nutze die LCD lib von Fleury. Ich kann mir nicht vorstellen wo der 
controller hängen bleibt.
1
int main(void)
2
{
3
  
4
  
5
  //Ausgänge definieren
6
  DDRC = (1<<CELL_PHONE_DD)|(1<<MOTOR_POWER_DD)|(1<<MOTOR_DIRECTION_DD)|(1<<LCD_BACKLIGHT_DD);
7
  DDRD = (1<<L1L2_POWER_DD);
8
  //Pullups aktivieren
9
  PORTD |= (1<<ENCODER_BUTTON_PIN)|(1<<ENCODER_A_PIN)|(1<<ENCODER_B_PIN)|(1<<RX_PIN);
10
  PORTC |= (1<<MOTOR_CLOSE_SWITCH_PIN)|(1<<MOTOR_OPEN_SWITCH_PIN)|(1<<L1_PIN)|(1<<L2_PIN); 
11
  PORTA |= (1<<DAWN_PIN);
12
  PORTB |= (1<<MAN_DOOR_BUTTON_PIN);
13

14
  lcd_init(LCD_DISP_ON);
15

16

17
  timer1_init();
18
  timer0_init();
19

20
 while(1)
21
 {
22
....

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.
Gast
>Benutzt du den Busy Check vom LCD?

So wie es aussieht wird Busy Flag nicht gelesen (LCD-4Bit-Modus):
1
void lcd_init(uint8_t dispAttr)
2
{
3
#if LCD_IO_MODE
4
    /*
5
     *  Initialize LCD to 4 bit I/O mode
6
     */
7
     
8
    if ( ( &LCD_DATA0_PORT == &LCD_DATA1_PORT) && ( &LCD_DATA1_PORT == &LCD_DATA2_PORT ) && ( &LCD_DATA2_PORT == &LCD_DATA3_PORT )
9
      && ( &LCD_RS_PORT == &LCD_DATA0_PORT) && ( &LCD_RW_PORT == &LCD_DATA0_PORT) && (&LCD_E_PORT == &LCD_DATA0_PORT)
10
      && (LCD_DATA0_PIN == 0 ) && (LCD_DATA1_PIN == 1) && (LCD_DATA2_PIN == 2) && (LCD_DATA3_PIN == 3) 
11
      && (LCD_RS_PIN == 4 ) && (LCD_RW_PIN == 5) && (LCD_E_PIN == 6 ) )
12
    {
13
        /* configure all port bits as output (all LCD lines on same port) */
14
        DDR(LCD_DATA0_PORT) |= 0x7F;
15
    }
16
    else if ( ( &LCD_DATA0_PORT == &LCD_DATA1_PORT) && ( &LCD_DATA1_PORT == &LCD_DATA2_PORT ) && ( &LCD_DATA2_PORT == &LCD_DATA3_PORT )
17
           && (LCD_DATA0_PIN == 0 ) && (LCD_DATA1_PIN == 1) && (LCD_DATA2_PIN == 2) && (LCD_DATA3_PIN == 3) )
18
    {
19
        /* configure all port bits as output (all LCD data lines on same port, but control lines on different ports) */
20
        DDR(LCD_DATA0_PORT) |= 0x0F;
21
        DDR(LCD_RS_PORT)    |= _BV(LCD_RS_PIN);
22
        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);
23
        DDR(LCD_E_PORT)     |= _BV(LCD_E_PIN);
24
    }
25
    else
26
    {
27
        /* configure all port bits as output (LCD data and control lines on different ports */
28
        DDR(LCD_RS_PORT)    |= _BV(LCD_RS_PIN);
29
        DDR(LCD_RW_PORT)    |= _BV(LCD_RW_PIN);
30
        DDR(LCD_E_PORT)     |= _BV(LCD_E_PIN);
31
        DDR(LCD_DATA0_PORT) |= _BV(LCD_DATA0_PIN);
32
        DDR(LCD_DATA1_PORT) |= _BV(LCD_DATA1_PIN);
33
        DDR(LCD_DATA2_PORT) |= _BV(LCD_DATA2_PIN);
34
        DDR(LCD_DATA3_PORT) |= _BV(LCD_DATA3_PIN);
35
    }
36
    delay(16000);        /* wait 16ms or more after power-on       */
37
    
38
    /* initial write to lcd is 8bit */
39
    LCD_DATA1_PORT |= _BV(LCD_DATA1_PIN);  // _BV(LCD_FUNCTION)>>4;
40
    LCD_DATA0_PORT |= _BV(LCD_DATA0_PIN);  // _BV(LCD_FUNCTION_8BIT)>>4;
41
    lcd_e_toggle();
42
    delay(4992);         /* delay, busy flag can't be checked here */
43
   
44
    /* repeat last command */ 
45
    lcd_e_toggle();      
46
    delay(64);           /* delay, busy flag can't be checked here */
47
    
48
    /* repeat last command a third time */
49
    lcd_e_toggle();      
50
    delay(64);           /* delay, busy flag can't be checked here */
51

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

66
    /* reset LCD */
67
    delay(16000);                           /* wait 16ms after power-on     */
68
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                   
69
    delay(4992);                            /* wait 5ms                     */
70
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                 
71
    delay(64);                              /* wait 64us                    */
72
    lcd_write(LCD_FUNCTION_8BIT_1LINE,0);   /* function set: 8bit interface */                
73
    delay(64);                              /* wait 64us                    */
74
#endif
75

76
#if KS0073_4LINES_MODE
77
    /* Display with KS0073 controller requires special commands for enabling 4 line mode */
78
  lcd_command(KS0073_EXTENDED_FUNCTION_REGISTER_ON);
79
  lcd_command(KS0073_4LINES_MODE);
80
  lcd_command(KS0073_EXTENDED_FUNCTION_REGISTER_OFF);
81
#else
82
    lcd_command(LCD_FUNCTION_DEFAULT);      /* function set: display lines  */
83
#endif
84
    lcd_command(LCD_DISP_OFF);              /* display off                  */
85
    lcd_clrscr();                           /* display clear                */ 
86
    lcd_command(LCD_MODE_DEFAULT);          /* set entry mode               */
87
    lcd_command(dispAttr);                  /* display/cursor control       */
88

89
}/* lcd_init */
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.
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.
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.
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!
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.
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.
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.
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 :-(
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

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 15 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.