M16C, UART0 und UARt1 gleichzietig

[Slim B. (dannyboy)]

Hallo ,

Ich bin anfänger mit der µC M16C/62P von Renesas und mache mein 
Studienarbeit. Ich arbeite an ein Gerät, das 2 Schnittstellen hat 
(UART0, UART1). Die UART1 ist da für Debuggen und Flaschen. Die UART0 um 
werte zu empfangen.
Beim Compilieren alles ist OK aber beim Debugen gibts Monitoring 
Probleme (bei der KD30).
Also bei der HEW und kompilieren gibt es keine fehler. Das problem liegt 
bei KD30.
Also am Anfang stand in der C code  nur UART1 zum debuggen und flaschen, 
da ist alles wunderbar gelaufen.
Danach habe Ich die UART0 in der C Code (c code 2 im Anhang) dazu gefügt 
um Werte zu empfangen und gab es keine Fehler beim kompilieren aber als 
Ich die kommunikation mit  Dem Gerät stellen wollte, gab es Probleme bei 
der KD30. Ich vermute bei der Definiren von UART0 hat irgendwas die 
Kommunikation mit der UART1 gestört.

Ich bedanke mich für die Hilfe.

[Stefan B. (stefan)]

Bitte kein DOC für C-Code benutzen.

[Martin (Gast)]

*.DOC Dateien werden nicht gerne gesehen. Damit dir jemand hilft hänge 
lieber die *.c Datei an.

Zum Problem:
-Interruptvektor richtig?
-Richtiges Monitorprogramm geflasht/gestartet
-Bei welchem Befehlt stoppt der Debugger?

[Stefan B. (stefan)]

Ich sehe in der Source nicht, wo uart0_init() aufgerufen wird und denke 
daher funktioniert UART0 in deinem Programm grundsätzlich nicht. Von 
UART1 ist in dem Programm auch nichts zu entdecken.

Bist du 100% sicher, welchen UART der KD30 braucht und welcher für dein 
Programm frei ist?

Denn unabhängig vom Nichtaufrufen von uart0_init() könnte die Störung 
der Kommunikation mit dem KD30 durch diese zeilen kommen:

#pragma INTERRUPT U0rec_ISR   // vector modified in
void U0rec_ISR(void) {
  LED_ON;
}

Wenn der KD30 voraussetzt, dass er UART0 fürs Debuggen haben kann, 
dann störst du den durch das Einklinken eines eigenen Interrupthandlers.

Du könntest die Zeilen mal weglassen und im Programm oder Debugger 
nachsehen, was an diesem Vektor im µC eingetragen ist.

Ich vermute, dass dort bereits ein Interrupthandler steht und zwar ein 
Sprung in den Teil des KD30 Debuggers, der auf dem µC für die 
Kommunikation mit dem PC-Teil des KD30 verantwortlich ist (sog. 
Monitorprogramm).