Komisches Problem: ein Controller geht der andere nicht (gleiches Programm)

[Flo S. (tuxianer)]

Hallo,
ich habe ein seltsames Problem ich habe 2 Platinen. Darauf ist erstmal 
nur die AVR Grundkonfiguration. Mit 7805 und Abblock Kondi, ISP. Nun 
habe ich 2 Mega162 einen älteren und einen neueren. Ich betreibe die 
Platine mit nem 7,3728 MHz Baudratenquarz. Dieser hat 2 26pF 
Lastkondensatoren. Das Programm benutzt den USART. Ich stlle damit die 
Verbindung zwischen meinem Taschenrechner und dem Mega her.
Nun das Problem ich habe auf beide Megas das gleiche Programm und die 
gleichen Fuses geschrieben. Der Programmer meint auch Equal bei den 
Programmen. Der eine Mega kommuniziert wunderbar auf beiden Platinen. 
Der andere auf gar keiner. Da kommt auf dem Rechner ein Com Error.
Wenn ich jedoch ein kleines Programm auf den Mega schreibe, wo die 
Kommunikation nicht klappt also nur Port setzen. Dann Funktioniert 
dieses Programm. Die UART Pins Funktionieren auch ich kann RX und TX auf 
High stellen.
Was kann hier das Problem sein?


Viele Grüße Florentin

[Fuse (Gast)]

> Was kann hier das Problem sein?
Bei den Fusebits vielleicht?

[Flo S. (tuxianer)]

die sind bei beiden gleich.

[Knut B. (Firma: TravelRec.) (travelrec)]

Hardwareproblem.

[holger (Gast)]

>die sind bei beiden gleich.

Sind sie wahrscheinlich nicht. Sonst würde dein
Proggi funktionieren.

[Flo S. (tuxianer)]

die Fuses sind definitiv gleich. Ich habe jetzt mal 2 22p 
Lastkondensatoren genommen, da wird der Controller gar nicht mehr 
erkannt. An der Platine kanns nicht liegen. Der eine Controller funtzt 
ja auf beiden.

[Jochen R. (josch90)]

Schmeiss den einen einfach weg un bestell dir nen neuen ;) Vlt hat der 
doch ma n schlag gekrigt und hardwareseitig ist was am Uart 
durchgebrannt...

[Flo S. (tuxianer)]

hmm...sieht echt danach aus. also mit nem Externen Oszi geht das 
Programm auch nicht. na dann werde ich mir wohl einen neuen bestellen 
müssen. Aber der war ganz neu.

[Jochen R. (josch90)]

Wie stehts bei dir mit ESD Schutz? eigendlich sind ja die Megas nicht 
soo empfindlich, aber ein paar grundlegende sachen dazu sollte man 
meiner meinung nach schon einhalten...

[Flo S. (tuxianer)]

naja ich hab den Controller eigentlich nur auf den Sockel gesteckt. Für 
mich sieht das einfach nach nem Produktionsfehler aus.

[Jochen R. (josch90)]

Also ich versuche immerhin den controller nicht an den Kontakten zu 
berühren und mich, wenn möglich, zuvor zu Erden. Kann natürlich sein 
dass der controller in der PRoduktion einen fehler hatte, ich weis nicht 
in wie weit die geprüft werden.

[Knut B. (Firma: TravelRec.) (travelrec)]

>Für mich sieht das einfach nach nem Produktionsfehler aus.

Vorsicht mit solchen Aussagen, in 99,9957% der Fälle hat der Anwender 
das Problem verursacht!

[Flo S. (tuxianer)]

naja ich werde in Zukunft auch mehr auf ESD Schutz achten. Aber ich 
hatte eigentlich nicht nie Probleme dadurch. Aber es schadet ja auch 
nicht sich mal zu entladen an der Heizung.

[Michael G. (linuxgeek)]

Lass uns mal wissen, ob und wann Du das Problem geloest hast ;)

[Michael K. (mmike)]

@Travel Rec.: Sicher dass es nicht 99,9967% sind ?

[Mikes (Gast)]

mglw. unterschiedliche Daten im EEPROM!?!?

Spreche aus Erfahrung ;)

Gruß

[Knut B. (Firma: TravelRec.) (travelrec)]

>Sicher dass es nicht 99,9967% sind ?

Das kommt auf die Anwender und auf das Wetter an ;-)

[Flo S. (tuxianer)]

also den EEprom habe ich nie beschrieben bei beiden Controllern. Ich 
werds aber mal probieren.

[Flo S. (tuxianer)]

ich habe jetzt nochmal auf den Funktionierenden Controller ein Programm 
geschrieben, was permanent was sendet über den USART. Direkt nach dem 
Programmieren kann ich das Signal am USART messen. Nachdem ich 
allerdings den Strom trenne und wieder verbinde kommt kein Signal mehr. 
Wenn ich den Resetpin manuell auf Low ziehe kommt wieder ein Signal.
Den Resetpin habe ich mittel 10k Widerstand auf VCC gezogen. Ich habe 
auch mal einen 100nF kondensator von Reset gegen GND geschalten. Das 
brachte allerdings auch nichts. Manchmal kommt kurz ein Signal, wenn ich 
wieder Strom anschließe.
Anscheinend mache ich irgendwas falsch. Nur was?Das andere Porgramm 
funktioniert ja genau auf dem Controller und läuft über den gleichen 
USART.

Hier der Quelltext:

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

#define BAUD 9600L                // Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!

#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-1000) // Fehler in Promille



#define AKTIV   1
#define INAKTIV 0




// Variablen für USART Senden
volatile uint8_t irq_send_num0;
volatile uint8_t irq_send_num1;
uint8_t irq_send_cnt0;
uint8_t irq_send_cnt1;
uint8_t irq_send_buf0[50];
uint8_t irq_send_buf1[50];



/**********************************************************
          USART-UDRE-Interrupthandler (SENDEN)
***********************************************************/

#define USART0_UDRE_ANSCHALTEN()  ( UCSR0B |=  (1<<UDRIE0) )
#define USART0_UDRE_ABSCHALTEN()  ( UCSR0B &= ~(1<<UDRIE0) )

// UART0 UDR EMPTY Interrupt --> jetzt Senden wenn was da ist
ISR(USART0_UDRE_vect)
{
  if (irq_send_num0) 
  {
    UDR0 = irq_send_buf0[irq_send_cnt0++];
    irq_send_num0--; 
  } 

  if (!irq_send_num0)
  {
    USART0_UDRE_ABSCHALTEN();
    irq_send_cnt0 = 0;
  }
}



void Transmit0(char Senden) 
{

  while(irq_send_num0);

  irq_send_buf0[0] = Senden;
  irq_send_num0 = 1;
  USART0_UDRE_ANSCHALTEN();
}



int main(void)
{
  uint8_t c;
  
  // Baudrate 9k6 UART0
  UBRR0H = UBRR_VAL >> 8;
  UBRR0L = UBRR_VAL & 0xFF;
  

  // Uebertragungsart 
  UCSR0C |= (1<<URSEL0)|(1<<USBS0)|(1<<UCSZ01)|(1<<UCSZ00);

  //Interrupts, Senden und Empfangen aktivieren
  UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0); // UDRIE0 wird erst beim Senden aktiviert
  

  // Interrupts global aktivieren
  sei();
  while(1) 
  {
    irq_send_buf0[0] = 0x06;
    irq_send_num0 = 1;
    USART0_UDRE_ANSCHALTEN();
  }

    
}

[Flo S. (tuxianer)]

ich habe nochmal den Controller auf der anderen Platine probiert, die 
hat nen Oszillator und da habe ich das gleiche Problem auch mit nem 
anderen Programm. Nach dem Manuellen Reset geht alles 1a. Nach dem Strom 
neu anlegen funktioniert der UART ca. 2 Sekunden danach geht nichts 
mehr. Ich weis nicht was ich falsch gemacht habe. Ich habe alle 
Lötstellen nochmal erhitzt, das hat auch nichts gebracht.


Gruß Florentin

[holger (Gast)]

>  while(1)
>  {
>    irq_send_buf0[0] = 0x06;
>    irq_send_num0 = 1;
>    USART0_UDRE_ANSCHALTEN();
>  }

Das wird natürlich gar nichts senden.
Von alleine springt das Programm nicht in den
Interrupt um dort dann in UDR0 zu schreiben.

[holger (Gast)]

Vergiss meinen letzten Post :(

>Nachdem ich allerdings den Strom trenne und wieder
>verbinde kommt kein Signal mehr.

Da würde ich mal die Brown Out Fuse programmieren.
Level so weit wie möglich an dein VCC ran.

[B e r n d W. (smiley46)]

Nach 2 Sekunden? Könnte das der Watchdog sein?

[Flo S. (tuxianer)]

hat ich eigentlich alles schon probiert. Also Watchdog ist in den Fuses 
aus und ich hats auch mal im Programm dissabled. Die Brown Out habe ich 
schon deaktiviert bzw. den höchstmöglichen wert genommen.

[Dennis (Gast)]

In dem Quelltext von oben finde ich irgendwie nirgendwo eine 
Quarzdefinition. Also keine Angabe, wie schnell Dein Quarz eigentlich 
ist. Vielleicht ist das Dein Problem. Bei der Baudratenberechnung steht 
F_CPU drin, aber definiert wird die nirgends.

[Flo S. (tuxianer)]

das ist im makefile

F_CPU = 7372800

[Dennis (Gast)]

Okay, dann passt das. Hab auch erst jetzt gelesen, daß auf Deiner 
Platine ein Abblockkondensator drauf ist. Frage: Wenn Du den Strom 
länger trennst, eine Minute zum Beispiel, läuft das Programm dann nach 
dem Wiedereinschalten korrekt an, oder hakt's dann trotzdem? Hatte 
nämlich auch mal so ein Problem, der Abblock-C hat sich erst entladen 
müssen. Wenn ich den Strom zu schnell wieder eingeschaltet hab, hat sich 
jedesmal der µC aufgehängt.

[Flo S. (tuxianer)]

so ich habe jetzt mal den Fehler lokalisiert. Hier mal das wichtigste 
aus dem code:

volatile unsigned char ucUDR1 = 0;        
volatile unsigned char ucUDR_valid1 = 0;  
volatile unsigned int  uiVerloreneZeichen1;

ISR(USART1_RXC_vect) 
{  
  //UART1 Interrupt Routine
  if (ucUDR_valid1)
    uiVerloreneZeichen1++;

  //Empfangenes Byte in ucUDR1 einlesen
  ucUDR1 = UDR1;
  
  //ucUDR_valid1 setzen
  ucUDR_valid1 = 1;
}

int main (void) {
  UBRR0H = UBRR_VAL >> 8;
  UBRR0L = UBRR_VAL & 0xFF;
  

  UBRR1H = UBRR_VAL >> 8;
  UBRR1L = UBRR_VAL & 0xFF;

  UCSR1C |= (1<<URSEL1)|(1<<USBS1)|(1<<UCSZ11)|(1<<UCSZ10);
  UCSR0C |= (1<<URSEL0)|(1<<USBS0)|(1<<UCSZ01)|(1<<UCSZ00);

  UCSR1B |= (1<<RXCIE1)|(1<<RXEN1)|(1<<TXEN1);
  UCSR0B |= (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0);
}

wenn ich das lösche:

ISR(USART1_RXC_vect) 
{  
  //UART1 Interrupt Routine
  if (ucUDR_valid1)
    uiVerloreneZeichen1++;

  //Empfangenes Byte in ucUDR1 einlesen
  ucUDR1 = UDR1;
  
  //ucUDR_valid1 setzen
  ucUDR_valid1 = 1;
}

tritt der Fehler auf.

[Gast (Gast)]

Natürlich passiert das wenn Du den Interrupt im Main-Code aktivierst, es 
aber
keine Interrupt Service-Routine im gesamten Code dann zu dem 
entsprechenden
Interrupt gibt.

Wenn Du die oben genannte Routine löscht würde ich mal über

UCSR1B |= (1<<RXCIE1)|(1<<RXEN1)|(1<<TXEN1);

nachdenken das ebenso zu entfernen oder den Int. abzustellen.

[Flo S. (tuxianer)]

ja genau das habe ich mir auch grade gedacht. Naja also ich brauch am 
UART0 kein Receive. Da dürfte doch:

UCSR1B |= (1<<TXEN1);

gehen.

Es war eben nur merkwürdig, das nach einem manuellen Reset der Code 
geht, nach einem automatischen aber nicht.

[Gast (Gast)]

Ach so vergessen: in Deinem Post weiter oben hört es sich so an als ob
Du 100nF oder 10k am Reset angeklemmt hast.

Dort sind wie im Tutorial beschrieben aber beide notwendig,
der 10k Pullup zieht den Reset pin nach VCC, wo bei der
100nF Kondensator definitiv einen kurzen definierten GND Pegel am
Reset Pin bewirkt.

Gruß und g. n8

[Flo S. (tuxianer)]

also ich habe einen 100nF zwischen VCC und GND, einen 100k vom Rest 
gegen VCC und vom Resetpin einen 100nF gegen Ground.

Also danke für eure Hilfe!


Viele Grüße Florentin

[Gast (Gast)]

Also lese bitte mal das Datenblatt,
ich habe es gerade nicht zur Hand aber:

UCSR1B müsste für UART 1

UCSR0B müsste für UART 2 zuständig sein.

In Deienem letzten main schaltest Du also beide UART ein und auch die 
Interrupts, aber Du wertest nicht beide in einer Interrupt routine aus;
das führt zu unerklärlichen Fehlern.

[Gast (Gast)]

>> UCSR0B müsste für UART 2 zuständig sein.

Sollte natürlich UART 0 heissen

[Jörg W. (dl8dtl) (Moderator)]

Florentin S. wrote:

> also ich habe einen 100nF zwischen VCC und GND, einen 100k vom Rest
> gegen VCC und vom Resetpin einen 100nF gegen Ground.

Eigentlich musst du am RESET-Pin gar nichts zwingend anschalten.
Ansonsten sind wohl (in der Appnote AVR040) 10 kΩ, überbrückt mit
einer Diode, und 4,7 nF empfohlen.

Mit deinem recht großen Kondensator triggerst du u. U. wirklich
bereits einen externen Reset (normalerweise genügt aber der power-on
reset), und hast noch dazu eine recht lange Anstiegszeit der Flanke.
Die sollte eigentlich aber nicht stören, da intern ein Schmitt-Trigger
drin ist.

Du darfst davon ausgehen, dass jeder AVR einzeln geprüft wird, bevor
er ausgeliefert wird.  Die Prüfung verursacht einen nicht unwesentlichen
Teil der Kosten für den Chip, außerdem wird während dieser Prüfung der
Flash-ROM in Betrieb genommen.  Den kann man nicht einfach nach der
Fertigung benutzen, der muss irgendwie formiert werden.

[Jörg W. (dl8dtl) (Moderator)]

holger wrote:

>>  while(1)
>>  {
>>    irq_send_buf0[0] = 0x06;
>>    irq_send_num0 = 1;
>>    USART0_UDRE_ANSCHALTEN();
>>  }
>
> Das wird natürlich gar nichts senden.
> Von alleine springt das Programm nicht in den
> Interrupt um dort dann in UDR0 zu schreiben.

Ach?  Du weißt aber, wie ein UART data register empty Interrupt
funktioniert, ja?