www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MSP430 und UART: Manchmal Datenmüll


Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nutze die Onboard RS232-Schnittstelle meines MSP430FG4618 Board für 
Debugausgaben Richtung PC.

Klappt soweit auch gut. Allerdings habe ich als erstes Zeichen oft 
(nicht immer) Datenmüll:

yHallo oder ähnliches.

Die Initialisierung erfolgt so:
// Configure UCA0 for RS232
  
  P2SEL |= 0x30;  //                        // P2.4 + P2.5 = USCI_A0 RXD/TXD
  UCA0CTL1 |= UCSSEL_2;                     // SMCLK
  UCA0BR0 = 0x09;                           // 1MHz 115200
  UCA0BR1 = 0x00;                           // 1MHz 115200
  UCA0MCTL = 0x02;                          // Modulation
  UCA0TXBUF = 0;
  UCA0CTL1 &= ~UCSWRST;                     // Start UART

Geschrieben wird so:
void uart_putstring(char *str) {
  while (*str!=0) uart_putchar(*str++);
}

void uart_putchar(char c) {
  while(!(IFG2&UCA0TXIFG));
  UCA0TXBUF = c;  
}

Muß ich vorher vlt. den Puffer irgendwie noch löschen?

Bei den ATmegas konnte ich immer sowas machen:
static FILE uart_stdout =
        FDEV_SETUP_STREAM(uart_putchar,0,_FDEV_SETUP_WRITE);

int uart_putchar(char c, FILE* stream) {
  while (!(UCSRA & (1<<UDRE))); // Wait until buffer is ready to be filled
  UDR = c; // Fill buffer with content
  return 0;
}

und konnte dann immer transparent mittels printf auf die RS232 
Schnittstelle schreiben. Das scheint aber bei dem MSP430 (Compiler) 
nicht zu gehen?
Muß ich dort anders vorgehen? Wenn ja, wie?

Danke!

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das erste Zeichen kann daher kommen, dass die Pegeländerung beim 
Einschalten der Spannungsversorgung als Zeichen interpretiert wird (UART 
Txd ist im Leerlauf high). Das sollte also nicht passieren, wenn man nur 
Reset auslöst, die Spannung aber eingeschaltet bleibt.

Beim mspgcc kann es sein, dass das genauso wie beim avr-gcc funktioniert 
mit den Streams. Das hab ich noch nicht probiert. Was auf jeden Fall 
geht, ist dass man printf einfach verwendet, dann gibt es eine Warnung, 
dass man ein putc implementieren muss. Das macht man dann einfach. Das 
habe ich so schon verwendet, nur den Quellcode gerade nicht hier.

Wie das mit anderen Compilern geht, weiß ich nicht. Ich hab (bis auf ein 
kleines Projekt) immer den mspgcc verwendet, der ist dem avr-gcc sehr 
ähnlich, deswegen ging das von Anfang an recht gut.

Grüße,

Peter

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> Das erste Zeichen kann daher kommen, dass die Pegeländerung beim
> Einschalten der Spannungsversorgung als Zeichen interpretiert wird (UART
> Txd ist im Leerlauf high). Das sollte also nicht passieren, wenn man nur
> Reset auslöst, die Spannung aber eingeschaltet bleibt.
>
> Beim mspgcc kann es sein, dass das genauso wie beim avr-gcc funktioniert
> mit den Streams. Das hab ich noch nicht probiert. Was auf jeden Fall
> geht, ist dass man printf einfach verwendet, dann gibt es eine Warnung,
> dass man ein putc implementieren muss. Das macht man dann einfach. Das
> habe ich so schon verwendet, nur den Quellcode gerade nicht hier.
>
> Wie das mit anderen Compilern geht, weiß ich nicht. Ich hab (bis auf ein
> kleines Projekt) immer den mspgcc verwendet, der ist dem avr-gcc sehr
> ähnlich, deswegen ging das von Anfang an recht gut.
>
> Grüße,
>
> Peter

Hallo Peter,

bzgl. "Reset und Spannung": Heißt das ich kann es gar nicht verhindern, 
dass da ein Zeichen Müll kommt, oder meinst Du mit "Reset" dieses Flag 
an dem UART Bausteil des MSP430, dass ich ändern könnte?

Compiler: Also ich verwende das TI CCS. Kan ich da einfach den mspgcc 
auch verwenden? Ich verstehe das so, dass sowohl im CCS als auch im IAR 
native Compiler der Hersteller enthalten sind und die verhalten sich 
wohl alle ein kleines bisschen anders?

Danke!

Markus

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt das Fehlzeichen denn wenn du die Schaltung einschaltest, oder erst 
später wenn das erste mal was übertragen wird?

Wenn es bei Reset passiert solltest du das mit entsprechender Schaltung 
und Software verhindern können.
Beim anlegen der Spannung hingegen lässt es sich nicht so leicht 
verhindern. Kommt dann darauf an wie deine Schaltung aufgebaut ist.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt wenn ich das erste Mal was via uart_putstring() konkret 
ausgebe. Das Evalboard des µC hat dann natürlich schon Strom. Zuvor 
erfolgt dann ja noch die Initialisierung des UART Bausteins (siehe 
oben). Ich hab auch schon mal explizit das TX Register vor dem 
Aktivieren des UART gelöscht, aber das hat nichts verändert.
Es ist mir ja nur aufgefallen, weil ich das bei einem Atmel STK 500 z.B. 
noch nie beobachtet habe.

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann bei UART manchmal auch einfach daran liegen, dass beide Teilnehmer 
noch nicht synchronisiert sind und erstmal korrekt ein Start-Bit erkannt 
werden muss.

Ist bei Verbindung über Draht zwar nicht oft der Fall, aber nur mal als 
Beispiel: Bei HART wird ja auch der UART zum Senden verwendet - hier 
wird aber das digitale Signal analog auf eine Leitung aufmoduliert.

Auf jeden Fall kannst du hier ohne Synchrnonisation erstmal alles 
vergessen - da kann man beispielsweise nicht direkt mit dem eigentlichen 
Datenstrom loslegen, sondern sendet zuvor einige 0xFF - da dies nur aus 
Einsen besteht, wird ein Start-Bit spätenstens nach dem zweiten Byte 
definitiv erkannt und beide Teilnehmer sind synchronisiert...aber nur 
als Beispiel halt.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Zuvor erfolgt dann ja noch die Initialisierung des UART Bausteins
Wenn es genau bei der Initialisierung auftaucht, würde ich den P2SEL 
Teil mal an das Ende der Initialisierung verschieben.

>Kann bei UART manchmal auch einfach daran liegen, dass beide Teilnehmer
>noch nicht synchronisiert sind...
Kann ich irgendwie nicht glauben. Der UART ist ja vollkommen in Hardware 
aufgebaut. Was soll sich da synchronisieren? Sobalt eine High-Low Flanke 
kommt legt er los...

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg S. schrieb:
>>Zuvor erfolgt dann ja noch die Initialisierung des UART Bausteins
> Wenn es genau bei der Initialisierung auftaucht, würde ich den P2SEL
> Teil mal an das Ende der Initialisierung verschieben.
>

Verhalten hat sich leider nicht verändert

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es passiert also exakt zum Zeitpunkt der Initialisierung?

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Öhm, nein, es geschieht beim allerersten Mal wenn ich etwas mittels 
uart_putstring() ausgebe, also wirklich in den UART schreibe, wie es 
aussieht. Ich habe aber, wie Du vorgeschlagen hast, das P2SEL mal nach 
den ganzen UART-Initialisierungsanweisungen geschrieben, das hat aber 
auch nichts geändert.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weißt es nicht 100%, da ich es nicht selbst definiert habe, aber 
wenn ich mir die Kommentare zu dem Codeschnippsel ansehe, dass ich zum 
Initialisieren des i2c Busses aus den TI Examples genommen habe würde 
ich sagen die normalen ca. 100 kHz (siehe UCB0BR0 = 0x0b Anweisung)
P3SEL |= 0x06; // P3.1 + P3.2 USBI_B0 option select  
UCB0CTL1 |= UCSWRST;                      // Enable SW reset
UCB0CTL0 = UCMST + UCMODE_3 + UCSYNC;     // I2C Master, synchronous mode
UCB0CTL1 = UCSSEL_2 + UCSWRST;            // Use SMCLK, keep SW reset
UCB0BR0 = 0x0b;                             // fSCL = SMCLK/11 = 95.3kHz  
UCB0BR1 = 0;
UCB0I2CSA = 0x1d;             // Set slave address (translates to 0x3a for write and 0x3b for a read
UCB0CTL1 &= ~UCSWRST;  
Ich habe mit diesem Prescaler auch schon gespielt (/63 usw.) Die Takte 
wurden entsprechend länger, aber am Verhalten hat sich nichts 
geändert...

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht solltest du bei der initialisierung auch noch IFG2 bzw. 
UCA0TXIFG zurücksetzen.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm.. ich sehe gerade, dass ich mich bei dem letzten Post vertan habe... 
der gehört da ja gar nicht rein ;-)

Habe nun noch das TX Flag gelöscht, ist aber unverändert so.
Und, ich habe mich leider gleich nochmal vertan, das "falsche" Zeichen 
kommt nicht erst beim uart_putstring()-Aufruf sondern doch schon 
tatsächlich bei der Initialisierung, sobald ich den UART loslaufen lasse 
mit UCB0CTL1 &= ~UCSWRST.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum schreibst du eine Null in den Sendepuffer, bevor der UART 
eingeschaltet wird?

UCA0TXBUF = 0;

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lange dauert es eigentlich, vom Einschalten bis zum Initialisieren 
des UART?  Kann es sein, dass der Oszillator da noch nicht stabil läuft?

Das ungewollte Zeichen kommt also auch, wenn man danach garnichts 
sendet? Also nur durch das Initialisieren?

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> Warum schreibst du eine Null in den Sendepuffer, bevor der UART
> eingeschaltet wird?
>
> UCA0TXBUF = 0;

Das hatte ich testweise rein, um den Buffer zu leeren. Wobei mir 
inzwischen auch klar ist, dass "leeren!=0"

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> Wie lange dauert es eigentlich, vom Einschalten bis zum Initialisieren
> des UART?  Kann es sein, dass der Oszillator da noch nicht stabil läuft?
>

Keien Ahnung, wie lange das dauert. Beim Programmanfang sind aber noch 
Warteschleifen, bis der Quarz sich sauber eingeschwungen hat (TI Std. 
Sample Code)

> Das ungewollte Zeichen kommt also auch, wenn man danach garnichts
> sendet? Also nur durch das Initialisieren?

Ja, offenbar.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du die Wartezeit zwischen Einschalten und UART-Initialisierung 
viel größer machen, so etwa 5 Sekunden und dann prüfen, wann das Zeichen 
kommt?

Als nächstes wäre es interessant, ob es wirklich gesendet wird, oder nur 
vom Umkonfigurieren des Ports kommt. Dazu würde ich testweise gleich 
beim Einschalten, also noch vor der Wartezeit, den Txd Pin manuell auf 
Ausgang und high konfigurieren, das ist der Leerlaufzustand vom UART. So 
dürfte sich beim Einschalten des UART der Pegel nicht mehr ändern.

Wenn der Fehler dann direkt beim Start kommt und nicht erst bei der 
UART-Initialisierung, ist es einfach durch den Pegelwechsel beim 
Einschalten bedingt.

Wenn es dagegen immer noch erst bei der UART-Initialisierung kommt, 
passiert da etwas seltsames.

Grüße,

Peter

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, probiere ich aus. Gibt es denn beim MSP430 auch sowas wie 
_delay_ms() wie bei den ATmegas? Habe das jetzt immer mit einer banalen 
for-Schleife gelöst...

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

durch ein explizities Low-Setzen der beiden UART-Pins (TX hätte 
vermutlich gereicht), ist das gewünschte Ziel erreicht und es erscheint 
kein "Müll" mehr beim Konfigurieren des UARTs:

Also wie folgt:
P2OUT &= ~((1<<4)|(1<<5));                // Clear P2.4 and P2.5

UCA0CTL1 |= UCSSEL_2;                     // SMCLK
UCA0BR0 = 0x09;                           // 1MHz 115200
UCA0BR1 = 0x00;                           // 1MHz 115200
UCA0MCTL = 0x02;                          // Modulation
UCA0CTL1 &= ~UCSWRST;                     // Start UART
P2SEL |= 0x30;  

uart_putstring("Let's go...");

Das P2OUT ist ausschlaggebend. Wartezeiten sind nicht notwendig.
Vielen Dank and Peter und Jörg für Ihre Hilfe bei der Klärung dieses 
Problems.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, das war es doch noch nicht 100%...
Zwar erreiche ich damit, dass es auch mal vorkommt, dass kein 
Sonderzeichen als erstes Zeichen erscheint, ABER das scheint vom Zufall 
abzuhängen.

Ich habe gerade alle Varianten durchpermutiert: Nur RX, nur TX, beide 
Pins, TXBUF auf 0 gesetzt, Flag gelöscht oder nicht und tatsächlich 
kommt bei der Version oben ziemlich häufig kein Zeichen beim 
Konfigurieren des Pins, aber manchmal eben doch.

Es scheint auch nicht von der Wartezeit abhängig zu sein, da ich auch 
unterschiedlich lange gewartet habe, bevor ich die entsprechenden 
Aktionen ausgeführt habe (via Singlestep im Debugger allerdings!). Das 
es also am Quarz oder so liegt, glaube ich jedenfalls nicht, der müsste 
ja auch einschwingen, wenn die CPU gestoppt ist, oder?

Add: Auch "echte" Warteschleifen vor dem Ausführen der Kommandos ändern 
daran nichts...

Add2: Und auch Stromversorgung über JTAG-FET oder Batterie führt zum 
gleichen Ergebnis...

Lassen wir's gut sein, oder?

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Im Datenblatt deines MSPs steht:

The required USART initialization/reconfiguration process is:
1) Set SWRST (BIS.B #SWRST,&UxCTL)
....

Irgendwie vermisse ich diesen Schritt bei dir.

MfG Spess

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, der Code ist 1:1 aus dem TI Beispiel 
msp430xG46x_uscia0_uart_115k.c
übernommen...

Hab's aber gerne ausprobiert, gleiches Ergebnis...
Aktueller Code:
  // Configure UCA0 for RS232
  P2OUT &= ~((1<<4)|(1<<5));
  UCA0CTL1 |= UCSWRST;  
  UCA0CTL1 |= UCSSEL_2+UCSWRST;             // SMCLK
  UCA0BR0 = 0x09;                           // 1MHz 115200
  UCA0BR1 = 0x00;                           // 1MHz 115200
  UCA0MCTL = 0x02;                          // Modulation
  UCA0TXBUF = 0;
  IFG2 &= ~UCA0TXIFG;
  
  UCA0CTL1 &= ~UCSWRST;                     // Start UART
  P2SEL |= 0x30;  //                        // P2.4 + P2.5 = USCI_A0 RXD/TXD, P2.1 & P2.2 stay GPIO 

bzgl. des erneuten Zuweisens von UCSWRST im 3. Befehl, habe ich gelesen 
(Buch: "MSP430 Microcontroller Basics"), dass das so notwendig ist, weil 
der UART ansonsten wohl auch losläuft, wenn man nur UCSSEL_2 setzt.

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sollte den Tx-Pin ja auch HIGH setzen und nicht low. Das wäre der 
richtige Leerlaufpegel vom UART. Außerdem auf Ausgang schalten.

Aber nur für Txd, wenn das P2.4 ist, dann

P2OUT |= (1<<4);
P2DIR |= (1<<4);

Grüße,

Peter

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> Man sollte den Tx-Pin ja auch HIGH setzen und nicht low. Das wäre der
> richtige Leerlaufpegel vom UART. Außerdem auf Ausgang schalten.
>
> Aber nur für Txd, wenn das P2.4 ist, dann
>
> P2OUT |= (1<<4);
> P2DIR |= (1<<4);
>
> Grüße,
>
> Peter

Verhalten hat sich nicht verändert...
do {
    IFG1 &= ~OFIFG;                           // Clear OSCFault flag
    for (i = 0x47FF; i > 0; i--);             // Time for flag to set
  }
  while ((IFG1 & OFIFG));                   // OSCFault flag still set?
  for(i = 0xFFFF; i > 0; i--);
  for(i = 0xFFFF; i > 0; i--);
  for(i = 0xFFFF; i > 0; i--);
  for(i = 0xFFFF; i > 0; i--);
  // Configure UCA0 for RS232
  P2OUT |= ((1<<4)|(1<<5));
  P2DIR |= ((1<<4)|(1<<5));  
  UCA0CTL1 |= UCSWRST;  
  UCA0CTL1 |= UCSSEL_2+UCSWRST;                     // SMCLK
  UCA0BR0 = 0x09;                           // 1MHz 115200
  UCA0BR1 = 0x00;                           // 1MHz 115200
  UCA0MCTL = 0x02;                          // Modulation
  UCA0TXBUF = 0;
  IFG2 &= ~UCA0TXIFG;
  
  UCA0CTL1 &= ~UCSWRST;                     // Start UART
  P2SEL |= 0x30;  //                        // P2.4 + P2.5 = USCI_A0 RXD/TXD, P2.1 & P2.2 stay GPIO 

"Müll" kommt nach dem Ausführen von P2DIR |= ((1<<4)|(1<<5)) (auch mit 
nur 1<<4 bzw. nur 1<<5 getestet)

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marcus ,

schon mal mit einer sehr niedrigen Baudrate probiert ?
sendest du daten an das "HyperTerminal "? zum daten anschauen
dann das "hyper Terminal" erst öffnen wenn der Controller bereit ist .

so ein Problem hat ich auch mal (Msp430F149) und Assembler .
aber wie ich das gelöst hatte ???


mfg Erik

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Erik,

hmm.. nein, ich möchte ja vielmehr eine möglichst hohe Baudrate, da die 
Debugmeldungen ja ggf. sehr schnell kommen.
Ich benutze nicht Hyperterminal sondern Putty im COM mode, da es mir 
alles bietet, was ich brauche.

Es ist ja auch keine Riesensache, es wundert mich nur, dass "es" 
passiert, und ich hätte gerne gewußt warum, bzw. ich wollte mir sicher 
sein, dass ich nicht irgendwas falsch gemacht habe.

Was ich halt seltsam finde, ist dass wir hier ja wirklich kleine 
Wundermaschinen vor uns haben, die man haarklein konfigurieren kann, 
aber es scheint nicht möglich zu sein, eine ganz saubere Ausgabe zu 
bekommen?
Allerdings: an einem Atmel STK 500 hatte ich sowas noch nie, und das 
setzen wir auch ziemlich intensiv bei uns ein. MSP430 ist für mich noch 
Neuland.

Grüße,
Markus

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus D. schrieb:
> aber es scheint nicht möglich zu sein, eine ganz saubere Ausgabe zu
> bekommen?
Doch, das ist möglich.
Hast du ein Speicheroszi zur Hand? Dann schau dir mal den TX-Pin in den 
verschiedenen Zuständen an.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich habe ein Oszi da. Was genau meinst Du mit "in den verschiedenen 
Zuständen" bzw. was soll ich da sehen? Ich werde vermutlich den Pegel 
von 0 auf 3 Volt wechseln sehen oder erwartest Du etwas anderes?

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>P2DIR |= ((1<<4)|(1<<5));

Du solltest P2.5 nicht auf Ausgang setzten, das gibt einen Kurzschluss 
zwischen dem Prozessor und dem Pegelwandler.

Jörg S. meint vermutlich, dass du am Oszi genau anschaust, welche 
Zeichen gesendet werden und wie der Unsinn zustande kommt, bzw. was in 
dieser Zeit genau passiert.

Grüße,

Peter

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

in diesem Zusammenhang mal noch eine Frage, die ich schon in einem 
anderen Thread auch gestellt hatte, aber noch keine Antwort bekommen 
habe.

Kurzfassung: Wo bekomme ich GND für das Oszi-Probe her?

Ich nutze das MSP430FG4618/2013 Evaluation Board. Dort sind (fast alle) 
Pins der MCs auf Pins herausgeführt. Es sind JTAG Buchsen dran und auch 
ein paar Jumper wo man zwischen JTAG-Powered, Batterie und External 
umschalten kann. ("External" wären dann zwei Zuleitungen die man auch 
direkt auf zwei Steckleisten führen müsste, das nutze ich aber nicht, 
schon allein weil ich kein passendes Netzteil habe).
Es gibt keine ausgewiesenen Pins wo man VCC oder GND abgreifen kann, wie 
es bei anderen Evalboards häufig der Fall ist, um Add-on Komponenten zu 
versorgen.
Ich speise das Board über den JTAG-FET via USB.
Wo würde ich denn in dieser Konstellation die GND Klemme des Probes 
befestigen?
Wäre das möglich einfach einen Pin explizit auf low zu schalten und das 
dann als GND zu verwenden? Oder ist das technisch gesehen nochmal was 
anderes als GND? Und/Oder ist das für diese Tests egal?

Danke!

Autor: Tobias Korrmann (kurzschluss81)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meines Wissens ist die Obere Reihe des Spredboard 3,3v
und die untere GND
Schau mal in der Anleitung nach

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie scheon gesagt wurde gibt es zu den Boards ja eigentlich immer die 
Schaltpläne. Ansonsten ist auf dem JTAG Stecker garantiert irgendwo 
Masse. Am RS232 Stecker gibt es auch Masse. Sieht man ja i.d.R. auch an 
Verbindungen zur GND-Plane.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. ja, gut, aber am JTAG Stecker steckt ja eben auch dieser.
Euren Antworten entnehme ich aber, dass es eben nicht geht, einfach 
einen Pin auf Low zu schalten?

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hmm. ja, gut, aber am JTAG Stecker steckt ja eben auch dieser.
Kein Lötkolben und ein Stück Draht da?

>Euren Antworten entnehme ich aber, dass es eben nicht geht, einfach
>einen Pin auf Low zu schalten?
Geht schon, nur keine schöne Lösung. Masse direkt ist besser.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ja, eigentlich möchte ich es vermeiden, bei so einem (für mich) 
teuren Board irgendwas rumzulöten...
Das Ganze stellt sich aber auch nicht nur wegen der Masse problematisch 
dar: Der RX/TX Ausgang wird vom Chip aus direkt auf den RS232 Stecker 
geführt (ggf. noch durch einen MAX232 o.ä.). Ich habe hier aber also 
auch keinen Angreifpunkt für die eigentliche Mess-Spitze, denn an der 
RS232 Buchse steckt ja auch wieder das RS232 Kabel...

Vielleicht noch mal zum Sinn des Ganzen: Erwartet ihr, dass vor der 
Initialisierung der Wert am Pin nicht sauber 0 oder 3.3V ist, sondern 
irgendwas dazwischen oder erwartet ihr irgendwelche Spitzen beim Wechsel 
zu sehen oder was genau versprecht Ihr Euch in diesem Fall davon, das am 
Oszi mitzulesen?

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Erwartet ihr, dass vor der Initialisierung der Wert am Pin nicht sauber 0
>oder 3.3V ist, sondern irgendwas dazwischen oder erwartet ihr
>irgendwelche Spitzen beim Wechsel zu sehen
Genau das ist die Frage. Wann liegt was am Pin an...

>Na ja, eigentlich möchte ich es vermeiden, bei so einem (für mich)
>teuren Board irgendwas rumzulöten...
Was soll passieren? Du willst doch nur ein einzelnes Kabel an eine 
einzelne dicke fette Lötstelle anlöten. Das bekommst du (wenn du keine 2 
linke Hände hast) absolut sauber ran und wieder ab.

>ggf. noch durch einen MAX232 o.ä.). Ich habe hier aber also auch keinen
>Angreifpunkt für die eigentliche Mess-Spitze,
Doch, am RS232/MAX232 Baustein und am RS232 Stecker (Lötpunkte vom 
Stecker). Vielleicht gibt es auch Durchkontaktierungen wo das Signal 
rüber läuft, da kommt man mit der Messpitze dann auch an das Signal 
dran.

Löten und messen ist das A&O bei der Entwicklung :)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Schaltplan auf der letzten Seite des
MSP430FG4618/F2013 Experimenter’s Board Users Guide
http://focus.ti.com/lit/ug/slau213a/slau213a.pdf
ist die RS232 Schnittstelle über Optokoppler vom Rest des Boards 
elektrisch isoliert. GND vom Board und Signal von Schnittstelle oder 
umgekehrt funktioniert also nicht.

GND kann man z.B. an Pin 9 des MSP430F2013 Programmieranschlusses JTAG2 
abgreifen und das serielle Ausgangssignal UCA0TXD an Pin 5 von Anschluss 
H4.

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das probiere ich mal, dankeschön!

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also: Ich habe die von Stefan vorgeschlagenen Pins benutzt und mein 
Programm im Debugger Schritt für Schritt ablaufen lassen. Allerdings war 
auch ohne Singlestep das Signalverhalten klar erkennbar:

Sobald das Programm bei der ersten Anweisung initial "breaked", geht der 
Pegel auf saubere 0V zurück. In dem Moment wo die Anweisung "P2DIR |= 
(1<<4);" ausführt springt das Signal von 0 auf 3V und bleibt dort 
stabil, bis die ersten Ausgaben über uart_putstring() erscheinen. Dort 
wechselt das Signal dann entsprechend der Codierung mehrmals von Low auf 
High. Das "Müllzeichen" erscheint allerdings bereits in dem Moment, wo 
der Pegel auf High springt, also bei der P2DIR-Anweisung.

Ich habe mit 100µs/div und 9k Samples mit meinem Picoscope 2204 
gesampled und auf 1V, steigende Flanke getriggert. Der Flankenanstieg 
ist praktisch vertikal.

Sieht für mich als Laie also alles prima aus.

Andere Frage: Könnte es denn vielleicht auch an der seriellen 
Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell 
PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell 
Adapter (auch Pollin) oft BSODs bekam...

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Andere Frage: Könnte es denn vielleicht auch an der seriellen
>Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell
>PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell
>Adapter (auch Pollin) oft BSODs bekam...

Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in 
irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn 
es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart 
sind) wechselt, lässt sich nicht vermeiden.

Es sollte dann die Aufgabe vom Übertragungsprotokoll sein, auf so eine 
Störung nicht zu reagieren.

Grüße,

Peter

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in
>irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn
>es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart
>sind) wechselt, lässt sich nicht vermeiden.
Ich würde einfach einen Pull-Up dran bauen, dann hat man es vermieden :)

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
>>Andere Frage: Könnte es denn vielleicht auch an der seriellen
>>Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell
>>PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell
>>Adapter (auch Pollin) oft BSODs bekam...
>
> Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in
> irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn
> es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart
> sind) wechselt, lässt sich nicht vermeiden.
>
> Es sollte dann die Aufgabe vom Übertragungsprotokoll sein, auf so eine
> Störung nicht zu reagieren.
>
> Grüße,
>
> Peter

Aber das muss sich doch irgendwie eingrenzen lassen? "Muss an der 
seriellen Schnittstelle liegen" ist doch etwas zu pauschal?
Liegt es denn dann vielleicht an den konkreten Verbindungsparametern 
8N1, keine Flußkontrolle? Würde man durch Aktivierung der Flußkontroller 
sowas verhindern können?

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg S. schrieb:
>>Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in
>>irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn
>>es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart
>>sind) wechselt, lässt sich nicht vermeiden.
> Ich würde einfach einen Pull-Up dran bauen, dann hat man es vermieden :)

Ist das eine ernstgemeinte Antwort gewesen? Vermutlich nicht, oder?

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach stellt ein einfacher Pegelwechsel von low nach high 
keinen gültigen UART-Frame dar. Die Karte müsste einen Frame-Error 
ausgeben, aber nicht irgendein Zeichen, das nicht gesendet worden ist.

Das ist offenbar einfach schlecht implementiert und alle Karten von mir 
haben dieses Verhalten auch nicht, demnach gehe ich davon aus, dass man 
das durchaus konstruktiv in der Schnittstellenkarte verhindern kann.

Trotzdem ist es ein Fehler der Karte und liegt nicht an den 
Einstellungen.
Möglicherweise erkennt die Karte einen Frame-Fehler richtig, wenn die 
Paritätsprüfung eingeschaltet wird. Sicher ist das aber nicht, denn den 
Fehler müsste sie auch ohne diese Prüfung erkennen.

@Jörg S.
Was soll denn ein Pullup gegen eine ausgeschaltete Versorgung nützen? 
Der Pegel ist in diesem Fall trotzdem low und beim Einschalten gibt es 
trotzdem den Übergang von low nach high.

Grüße,

Peter

Autor: Erik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo Markus,

hast du schon mal  die zeile
  P2OUT |= ((1<<4)|(1<<5));
  P2DIR |= ((1<<4)|(1<<5));
hinten drangestellt bei der initialisierung ?
bzw P2Out ganz weggelassen ? ist brauch mann die Zeile überhaupt ?

ich kann leider kein C
bei einen alten Projekt von mir (Msp430F149)sieht in Assembler so aus

;SetupUART0
            mov.b     #CHAR,&UCTL0            ; 8-bit characters
            mov.b     #SSEL0,&UTCTL0          ; UCLK = ACLK
            mov.b     #00Dh,&UBR00            ; 32k/2400 - 13.65
            mov.b     #000h,&UBR10            ; 32k 2400
            mov.b     #06Bh,&UMCTL0           ; 32k 2400 modulation
            bis.b     #UTXE0+URXE0,&ME1       ; Enable USART0 TXD/RXD
            bis.b     #URXIE0,&IE1            ; Enable USART0 RX 
interrupt
;SetupP3
            bis.b     #030h,&P3SEL            ; P3.4,5 = USART0 TXD/RXD
            bis.b     #010h,&P3DIR            ; P3.4 = output direction

Ich hoffe das hilft weiter
mfg Erik

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erik schrieb:
> hallo Markus,
>
> hast du schon mal  die zeile
>   P2OUT |= ((1<<4)|(1<<5));
>   P2DIR |= ((1<<4)|(1<<5));
> hinten drangestellt bei der initialisierung ?
> bzw P2Out ganz weggelassen ? ist brauch mann die Zeile überhaupt ?
>
>

Hallo Erik,

ja, ich glaube ich hatte inzwischen schon alle Varianten durch ;-) 
(siehe Anfang des Threads). Habe inzwischen auch nur den 4er alleine 
versucht.

Wenn das Problem tatsächlich an der Empfängerseite liegt, wird man auf 
MSP Seite ja nichts ändern können. Zumal würde ja auch bei einer völlig 
korrekten Initialisierung irgendwann dieser Pegelwechsel von 0 auf VCC 
beim UART passieren, und dann würde ja wieder das Müllzeichen 
ausgegeben...

Ich probier's aber einfach mal weiter, bzw. schaue auch mal ob man vlt. 
auf Empfängerseite irgendwas konfigurieren kann.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener schrieb:
> @Jörg S.
> Was soll denn ein Pullup gegen eine ausgeschaltete Versorgung nützen?
> Der Pegel ist in diesem Fall trotzdem low und beim Einschalten gibt es
> trotzdem den Übergang von low nach high.

Gegen den Pegelwechsel beim Einschalten hilft ein Pullup natürlich 
nichts, wenn die Versorgungsspannung dauerhaft anliegt und nur ein Reset 
ausgeführt wird aber schon. Wenn das Programm wiederholt per Debugger 
gestartet wird sollte mit Pullup nur beim ersetn Programmstart ein 
störendes Zeichen auftreten können.

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.