mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Komisches Problem: ein Controller geht der andere nicht (gleiches Programm)


Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fuse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was kann hier das Problem sein?
Bei den Fusebits vielleicht?

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die sind bei beiden gleich.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hardwareproblem.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>die sind bei beiden gleich.

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

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen R. (josch90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jochen R. (josch90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Flo S. (tuxianer)
Datum:

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

Autor: Jochen R. (josch90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lass uns mal wissen, ob und wann Du das Problem geloest hast ;)

Autor: Michael K. (mmike)
Datum:

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

Autor: Mikes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mglw. unterschiedliche Daten im EEPROM!?!?

Spreche aus Erfahrung ;)

Gruß

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sicher dass es nicht 99,9967% sind ?

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

Autor: Flo S. (tuxianer)
Datum:

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

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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();
  }

    
}

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B e r n d W. (smiley46)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach 2 Sekunden? Könnte das der Watchdog sein?

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist im makefile

F_CPU = 7372800

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Flo S. (tuxianer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> UCSR0B müsste für UART 2 zuständig sein.

Sollte natürlich UART 0 heissen

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.