UART Bridge des mySmartUSB MK2

[Stefan (Gast)]

Hallo,

ich möchte von dem mySmartUSB MK2 die UART Bridge benutzen um mit meinem 
ATMega 644 und dem PC Daten auszutauschen.


Dafür habe ich als PC-Programm die "USB Device - CDC - Basic Demo" von 
Microchip genommen. Das ist ein C# Demoprogramm welches beliebige Daten 
auf eine serielle Schnittstelle gibt und empfangene Daten anzeigt. 
Dieses Prog ist eigentlich für PIC µC der ein USB-Interface hat. Sollte 
jedoch das gleiche sein, wie ich es auch für den MK2 brauche.

Im Mikrocontroller habe ich den UART initialisert und empfange und sende 
2 mal Pro Sekunde ein Byte.

Den myAVR MK2 habe ich per DIP Schalter auf "Datenmodus erzwingen 
(UART-USB-Bridge)" gestellt.


Doch leider empfängt weder das Computerprogramm Daten vom µC noch 
andersrum.


Wenn ich im PC Programm die Daten lossende sieht man auf dem MK2, dass 
Daten ankommen (rote LED blinkt beim Senden der Daten). Leider habe ich 
kein Scope um die Kommunikation auf den RX und TX Leitungen zu 
überprüfen.


Hat jemand von Euch ne Idee wo der Fehler liegen könnte?


Vielen Dank!

Stefan

[raketenfred (Gast)]

Hi- du brauchst kein wirkliches Skope

nimm einfach eine LED(mit Vorwiderstand) und mess damit wie Spannungen 
anliegen etc- wenn du die Baudrate auf ca 4800 oder noch tiefer 
einstellst, dann kannst du problemlos sehen, ob da Datenfließen. Das LED 
fängt dann an zu Flackern.

Habe das gestern noch selber mit einem max232 ausprobiert

[Stefan (Gast)]

Hi raketenfred,

danke für deine Antwort! Bin um einiges weiter. Ich habe einfach die RX 
und TX Leitung der Brücke kurzgeschlossen und das PC Prog ausprobiert; 
Die versendeten Daten treffen wieder ein. :)


Auf der AVR Seite funktioniert das Empfangen. Leider funktioniert das 
Senden nicht.

In dem µC Programm habe ich einen zyklischen Interrupt (Uhr). Sobald ich 
jedoch das TX Enable Bit setzte bleibt die Uhr komischer Weise stehen. 
Auch das Empfangen auf der RX Leitung funktioniert dann nicht mehr. Der 
µC scheint sich aufzuhängen.


So funktionierts:

UCSR0B = (1<<RXEN0);


So nicht:

UCSR0B = (1<<RXEN0)|(1<<TXEN0);


Was kann das sein?

[Stefan (Gast)]

Das Empfangen auf der Controllerseite funktioniert einwandfrei, die 
Bridge funktioniert auch. Leider habe ich das Problem nicht beheben 
können, dass er sich aufhängt sobald das TXEN Bit gesetzt ist.

Das Problem gab es bereits 2005 
Beitrag "Wie heißt SIG_UART_DATA beim ATmega8?" und vor ein paar Tagen: 
Beitrag "AtMega88P - UART"


Leider jeweils ohne einer Lösung.


Würd mich wirklich sehr freuen, wenn jemand die Lösung des Problems 
kennt oder vermutet.


Vielen Dank nochmal!

Stefan

[holger (Gast)]

>Würd mich wirklich sehr freuen, wenn jemand die Lösung des Problems
>kennt oder vermutet.

Im zweiten Link habe ich eine Vermutung geäussert:
Das Projekt wird für den falschen Controller
übersetzt. Dann kann es Probleme mit einem falsch
gesetzten Stackpointer oder falschen Registerzugriffen
geben.

Oder das Problem liegt ganz woanders im Code.

[g457 (Gast)]

Zeig Hardware und Software, jeweils vollständig(!), alles andere ist nur 
Rätselraten.

[Stefan (Gast)]

Zu der Hardware gibts nicht viel zu sagen.

RX<->TX
TX<->RX

Es ist nichts weiteres an den Pins angeschlossen.


Das Problem habe ich in folgendem abgespecktem Programm weiterhin:

#include <avr/io.h>

#include "lcd-routines.h"

void USART_Init(void)
{
  /* Set baud rate: 9600 (20 Mhz OSC) */
  UBRR0 = 129;
  
  /* Enable receiver and transmitter */
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);
  
  lcd_string("Init ready");
  while(1);
  /* Set frame format: 8data, 2stop bit */
  UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2
  
}

int main(void)
{
  lcd_init();
  USART_Init();
}

Wenn ich dieses Programm starte bleibt das Display leer. Wenn ich 
"|(1<<TXEN0)" rausnehme gibt das Display "Init ready" aus. Der 
Controller hängt sich also tatsächlich in dieser Zeile auf.

Ich hab das display mal den Wert "TXEN0" anzeigen lassen per 
"lcd_data(TXEN0+48)". Es wird eine 3 angezeigt, die laut Datenblatt auch 
richtig ist.

Auch wenn ich es direkt schreibe:
UCSR0B = (1<<RXEN0)|(1<<3);

... bleibt das Problem vorhanden.

Wenn ich mir das Register UCSRnB im Datenblatt angucke, seh ich auch 
keine Möglichkeit den Controller durch irgend ein falsch gesetztes Bit 
zum Absturz zu bringen.

[holger (Gast)]

>Der Controller hängt sich also tatsächlich in dieser Zeile auf.

Also genau wie bei dem zweiten Link. Merkwürdig.
Eigentlich kann der sich da nicht aufhängen.

Was passiert beim aktivieren von TXEN0? Der Pin wird
zum Ausgang. Evtl. mal den Pin offen lassen.

[g457 (Gast)]

Entsorg das LCD, entsorg die (fragwürdige) Endlosschleife in der 
Initialisierung, mach in main() sowas wie

while (1) { uart_send_string("x"); _delay_ms(500); }

Wenn das noch nichts hilft häng eine LED an einen freien Pin und toggel 
die an aussagekräftigen Stellen etwas rum (insbesondere beim Start!). 
Und überprüf die Hardware nochmals :-)

HTH

[Stefan (Gast)]

Auch wenn ich die Brück abnehme und Spannung anschließe bleibt er bei 
der Zeile stehen. Hab vor der Zeile nochmal PORTD = 0x02; geschrieben... 
er bleibt weiterhin hängen. :(

void USART_Init(void)
{
  UBRR0 = 129;
  PORTD = 0x02;
  lcd_string("Start");
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);
  lcd_string("Ende");
  UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2
}

Das Display gibt "Start" aus.

Das LCD ist eine einfache möglichkeit um zu überprüfen in welcher Zeile 
er hängen bleibt. Die fragwürdige Endlosschleife entstand bei einem Test 
um das Programm dort erstmal anzuhalten. Habe sie rausgenommen, keine 
Besserung.

Da das Projekt in SMD gelötet ist, ist es nicht ganz so einfach mal eben 
eine LED ranzuhängen. Ich wüsste auch nicht wieso das LCD das Problem 
sein sollte.

[g457 (Gast)]

> Das LCD ist eine einfache möglichkeit um zu überprüfen in welcher Zeile
> er hängen bleibt.

Schon klar - nur was nicht reincompiliert wird kann auch keine Probleme 
verursachen :-)

> Da das Projekt in SMD gelötet ist, ist es nicht ganz so einfach mal eben
> eine LED ranzuhängen.

Ok, das ist ein Argument. Dann eben ein Mulimeter dranfrickeln :-)

> Ich wüsste auch nicht wieso das LCD das Problem sein sollte.

Isses vielleicht nicht (siehe oben). KISS halt. Und ich hab eine ganz 
andere Vermutung: Deine Kiste macht einen Reset beim TXEN - warum auch 
immer. Deswegen der Hinweise mit 'rumtoggeln beim Start'. Behelfsweise 
(bevor Du zum Mulimeter greifst) kannst noch sowas einbauen wie

lcd_init();
lcd_string("hallo welt");
_delay_ms(1000);
uart_init();
lcd_string("foo bar");

HTH

[holger (Gast)]

Mach das mal so

  _delay_ms(200);
  lcd_string("Start");
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);

flackert das Display dann?

>Auch wenn ich die Brück abnehme

Welche Brücke? Du hast doch nicht etwa Rx und Tx
am uC bei angeschlossenem MAX232 verbunden? Dann
hast du zwei Ausgänge kurzgeschlossen.

[Stefan (Gast)]

Es gibt keinen Neustart. Folgendes Programm lässt 800 ms "Hallo Welt" 
anzeigen, danach "Start", es gibt keinen Neustart.

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

#include "lcd-routines.h"



void print(char *string)
{
  lcd_clear();
  lcd_home();
  lcd_string(string);
}

void USART_Init(void)
{
  uint8_t temp;
  UBRR0 = 129;
  PORTD = 0x02;
  print("Start");
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);
  print("Ende");
  UCSR0C = (1 << UCSZ01)|(1 << UCSZ00)|(1 << USBS0); // Asynchron 8N2

}

int main(void)
{
  lcd_init();
  print("Hallo Welt!");
  _delay_ms(800);
  print("800 ms gewartet");
  USART_Init();
  print("Initialisiert");
  while(1);
}

Holgers Programm lässt das Display nicht flackern.

Holger: Mit Brücke mein ich die UART <=> USB Brücke. Der MK2 ist 
eigentlich ein Programmer der jedoch als Zusatz eine UART <=> USB Brücke 
beinhaltet. Mit Brücke abnehmen meinte ich, dass ich den Programmer 
nicht angeschlossen habe und eine externe Spannung als 
Versorungsspannung anlege. Die TX Leitungen sind und waren nie 
miteinander verbunden.

[holger (Gast)]

>Es gibt keinen Neustart.

Dann sind wir wohl wieder am Anfang;)

Irgendwas stimmt doch da mit dem TX Pin nicht.
Sicher das da kein Kurzschluss zu VCC, GND oder einem
Nachbarpin drauf ist?

[g457 (Gast)]

Schade, kein Reset :-(

Fuse mal auf den internen Oszillator um auszuschließen dass der TX den 
Takt 'abwürgt'.

[Stefan (Gast)]

Hi Leute,

danke für eure Geduld. Meine ist erstmal zu Ende und ich werd erstmal 
zum Sport gehen. ;)

Meld mich heut abend oder morgen wieder.

Vielen Dank nochmal!

Stefan

[Stefan (Gast)]

Auch wenn der interne Oszillator aktiviert ist, hängt sich der 
Controller auf.

Ich habe vom TX Pin zu seinen Nachbarn sowie zu V+ und GND gemessen: 
kein Kurzschluss.

Nun habe ich mal den PD1 Pin (= TX Pin) jede Sekunde toggeln lassen: 
Funktioniert. Muss mich also mit ner Software UART abfinden.


Nochmals vielen dank an Euch.