8031 sendet nicht auf Uart

S

Stefan Bröring

Guest
Hallo,


ich beschäftige mich schon seit mehr als 15 Jahren mit der Programmierung
von 8031, 87C51 etc., habe aber momentan ein Problem auf dem Tisch liegen,
zu dem mir nichts mehr einfällt:

Ein Programm, in dem per Polling ständig die serielle Schnittstelle
abgefragt wird reagiert zwar korrekt auf die empfangenen Kommandos, sendet
aber keine Antwort mehr auf TXD.

Das Programm durchläuft eine Hauptschleife und wartet auf Daten auf RXD und
soll dann ein Echo machen.
Das Programm läuft manchmal tagelang durch, bis plötzlich kein Echo mehr
kommt. Die Kommandos (Relais Ein- und Ausschalten) werden nach wie vor
korrekt ausgeführt. Wenn ich ein Kommando sende, dass einen "LJMP 0"
auslöst, funktioniert alles wieder.

Hat jemand eine Idee, was dazu führen kann, dass sich beim UART nur der
Sender aufhängt?

Hier einige Codefragmente:

Gruß

Stefan


;*************************************************
;* Initialisierung der seriellen Schnittstelle *
;* Mode 1, 9600 Baud, 7 Datenbits, even Parity *
;* 1 Stopbit *
;*************************************************
INITS: CLR TR1
MOV P3,#%11101111 ;ausser SE-Leitung alles setzen
;8031 Timer 1 als Baudratengenerator und Timer 0 fr Timeout
ANL PCON,#$7F ;einfache Baudrate
;init SCON
mov SCON,#%01011100 ;8-bit uart, enable reception, init PCON
MOV TMOD,#%00100010 ;Timer 1 Mode 2, Timer 0 Mode 2
mov TH1,#0fdh ;auto-reload value fuer timer1

MOV TH0,#00 ;timer 0 macht nach 65ms einen
MOV TL0,#00 ;Timeout-INT
;***************************************************************************************
ANL IP,#%11000000
ORL IP,#%00000011 ;TIMER 0 UND INT0 HIGH PRIO
SETB TI0 ;SIO Flags l"schen
CLR RI0
CLR ES0 ;SIO-INT sperren
SETB TR1 ;Timer 1 aktivieren, fr serielle Schn.
CLR EAL
SETB TR0 ; Timer 0 einschalten
SETB ET0 ; Timer 0 int aktivieren
SETB EAL ; INT's freigeben
MOV P1,#$0FF ; Port 1 auf High schalten

;**********************************************************************

......
EINGANG:
_WTLOP: LCALL RECA ;Zeichen einlesen
LCALL SENDV24 ;Zeichen weitergeben
CJNE A,#'#',_WTLOP ; # ist das Blockanfangzeichen
LCALL RECA ;Komando einlesen
LCALL SENDV24 ;Echo
.....


;*************************************************
;* Routine zum Senden eines Bytes ber Ser. IO *
;* Einsprung : SENDA *
;*************************************************
SENDV24:
SENDA: CPL watchdog
JNB TI0,SENDA ;Test ob Sender bereit
CLR TI0
MOV S0BUF,A ;Senden
RET
;*************************************************
;* Routine zum Empf. eines Bytes ber Ser. IO *
;* Einsprung : RECA *
;*************************************************
GETV24:
RECA: CPL watchdog
JNB RI0,RECA ;TEST ob Zeichen bereit
CLR RI0 ;Flag l"schen
MOV A,S0BUF
CJNE A,#10,RECAR ;LF ignorieren
SJMP RECA
RECAR: RET
 
Stefan Bröring wrote:

Hat jemand eine Idee, was dazu führen kann, dass sich beim UART nur der
Sender aufhängt?
Click to expand...
Kommt nur nix mehr aus den Pins oder bleibt auch das Programm stehen,
weil das Senderegister nicht wieder leer wird? Weil in ersterem Falle
einfach ein Latchup stattgefunden haben kann, sowas hatten wir
seinerzeit mal bei sündhaft teuren Intel-Multibusprozessorplatinen (da
war es aber vermutlich der V24-Pegelwandler und nicht der UART selber).

Bernd
 
"Bernd Laengerich" <Bernd.Laengerich@web.de> schrieb im Newsbeitrag
news:436n8aF1madedU1@individual.net...
Stefan Bröring wrote:

Kommt nur nix mehr aus den Pins oder bleibt auch das Programm stehen, weil
das Senderegister nicht wieder leer wird? Weil in ersterem Falle einfach
ein Latchup stattgefunden haben kann, sowas hatten wir seinerzeit mal bei
sündhaft teuren Intel-Multibusprozessorplatinen (da war es aber vermutlich
der V24-Pegelwandler und nicht der UART selber).

Bernd
Click to expand...
Es kommt einfach nix mehr, das wundert mich ja. Obwohl ich direkt nach dem
Einlesen das Echo mache, kommt nichts mehr.
Das Programm funktioniert ansonsten einwandfrei. Ich kann Kommandos
absenden, die Relais Ein- und Ausschalten, was auch einwandfrei
funktioniert. Nur das Echo und die Daten kommen nicht mehr. Nach dem LJMP 0
ist dann alles wieder ok.
Kommunikation im Polling, kein INT vom UART, nur ein Timer-INT, der aber ok
sein müsste und der mit dem UART nichts zu tun hat.

Der entsprechende Pin des AT89C51 liegt dann auch dauerhaft auf 0V und nicht
wie normal auf 5V.

Ich frage mich gerade, ob es sein kann, dass der Port-Pin der TXD-Leitung
"umgekippt" sein kann. Überschreibt die UART den 0-Pegel, oder muss ich das
Beinchen vorher per Programm auf High setzen?

In diesem Fall ist übrigens kein Pegelwandler vorhanden. Das Signal geht
über einen 4K7 auf die Basis eines BC548 (TTY-Schnittstelle).

Gruß

Stefan
 
Stefan Bröring schrieb:

Der entsprechende Pin des AT89C51 liegt dann auch dauerhaft auf 0V und nicht
wie normal auf 5V.

Ich frage mich gerade, ob es sein kann, dass der Port-Pin der TXD-Leitung
"umgekippt" sein kann. Überschreibt die UART den 0-Pegel, oder muss ich das
Beinchen vorher per Programm auf High setzen?
Click to expand...
Ja. Nicht der UART überschreibt den Port, sondern umgekehrt. Sobald der
Port auf 0 gesetzt wird, ist der Ausgang low - egal was der UART macht.

In diesem Fall ist übrigens kein Pegelwandler vorhanden. Das Signal geht
über einen 4K7 auf die Basis eines BC548 (TTY-Schnittstelle).
Click to expand...
Das gibt aber relativ wenig Basisstrom für den Transistor --> ggf.
Pullup hinzufügen, damit Sättigung garantiert werden kann.

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
 
Ja. Nicht der UART überschreibt den Port, sondern umgekehrt. Sobald der
Port auf 0 gesetzt wird, ist der Ausgang low - egal was der UART macht.
Click to expand...
Ich habs noch nicht ausprobiert, weil das Gerät zur Zeit montiert ist, aber
das klingt plausibel.

In diesem Fall ist übrigens kein Pegelwandler vorhanden. Das Signal geht
über einen 4K7 auf die Basis eines BC548 (TTY-Schnittstelle).

Das gibt aber relativ wenig Basisstrom für den Transistor --> ggf.
Pullup hinzufügen, damit Sättigung garantiert werden kann.
Click to expand...
Der BC548 muss nur 20mA treiben, bei 4k7 ist der Basisstrom dann knapp 1mA,
sollte also reichen. Hat auch bisher immer funktioniert, bzw. ist hier ja
mit Sicherheit nicht das Problem

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
Click to expand...
Danke erstmal, ich werde das mal ausprobieren. Blöd ist nur, dass das
Problem manchmal tagelang nicht auftritt.

Was meinst du, es müsste doch egal sein, ob ich den Pin auf 1 setze, während
der TX noch sendet, oder sollte man abwarten, bis die Schnittstelle wieder
den Ruhezustand erreicht hat? Ich könnte dann jeweils unmittelbar vor dem
Senden den Pin auf 1 setzen.

gruß

Stefan
 
"Stefan Bröring" schrieb

Ich frage mich gerade, ob es sein kann, dass der Port-Pin der TXD-Leitung
"umgekippt" sein kann. Überschreibt die UART den 0-Pegel, oder muss ich
das Beinchen vorher per Programm auf High setzen?
Click to expand...
Hallo Stefan,

nimm mal lieber einen Editor und such in deinen Quelltexten, wo du überall
auf den
kompletten Port oder den einzelnen Pin schreibend zugreifst.
Einen Programmfehler, der sich selten bemerkbar macht halte ich da für
wahrscheinlicher
und den sollte man beseitigen und nicht an einer anderen Stelle überbügeln.
Das rächt sich spätestens bei der nächsten "copy and paste" Vererbung ;-)

Gruß

Hans-Georg
 
Stefan Broering schrieb:

In diesem Fall ist übrigens kein Pegelwandler vorhanden. Das Signal geht
über einen 4K7 auf die Basis eines BC548 (TTY-Schnittstelle).

Das gibt aber relativ wenig Basisstrom für den Transistor --> ggf.
Pullup hinzufügen, damit Sättigung garantiert werden kann.

Der BC548 muss nur 20mA treiben, bei 4k7 ist der Basisstrom dann knapp 1mA,
sollte also reichen. Hat auch bisher immer funktioniert, bzw. ist hier ja
mit Sicherheit nicht das Problem
Click to expand...
Du hast bedacht, daß der Quasi-bidirektionale Port des 89C51 ein "high"
nicht richtig treiben kann (ca. 40 kOhm interner Quellwiderstand)?

Danke erstmal, ich werde das mal ausprobieren. Blöd ist nur, dass das
Problem manchmal tagelang nicht auftritt.

Was meinst du, es müsste doch egal sein, ob ich den Pin auf 1 setze, während
der TX noch sendet, oder sollte man abwarten, bis die Schnittstelle wieder
den Ruhezustand erreicht hat? Ich könnte dann jeweils unmittelbar vor dem
Senden den Pin auf 1 setzen.
Click to expand...
Normalerweise setzt man den Port bei der Initialisierung einmal auf 1,
danach nie wieder. Ich stimme Hans-Georg zu, daß Du zunächst eher nach
sonstigen Zugriffen auf P3 suchen solltest, als hier an Symptomen zu
kurieren.

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
 
Hallo Stefan,

nimm mal lieber einen Editor und such in deinen Quelltexten, wo du überall
auf den
kompletten Port oder den einzelnen Pin schreibend zugreifst.
Einen Programmfehler, der sich selten bemerkbar macht halte ich da für
wahrscheinlicher
und den sollte man beseitigen und nicht an einer anderen Stelle
überbügeln.
Das rächt sich spätestens bei der nächsten "copy and paste" Vererbung ;-)

Gruß

Hans-Georg
Click to expand...
Klar, da hast du völlig recht. Dieses Programm ist praktisch eine 95%-ige
Vererbung aus einem älteren System mit ähnlicher Schaltung, von dem etwa 20
Stück in industrieller Umgebung seit mehr als 10 Jahren einwandfrei laufen.

Das mit dem Pull-Up im 8031 ist natürlich auch richtig, aber bei einer
Stromverstärkung von einigen hundert passt das immer noch. Der BC548 muss
auch nicht in die Sättigung getrieben werden... Könnte man bei 9k6 aber noch
machen

Gruß

Stefan
 
Hast du schon mal den Prozessor ausgetauscht?

Fragt
Jens
Click to expand...
Ja, ich habe 2 identische Karten, die beim Kunden das selbe Problem machen.
Bei mir in der Werkstatt tritt das Problem bisher nicht auf. Liegt aber
vieleicht an unterschiedlichen Testbedingungen.

Gruß

Stefan
 
Stefan Broering schrieb:

Ja, ich habe 2 identische Karten, die beim Kunden das selbe Problem machen.
Bei mir in der Werkstatt tritt das Problem bisher nicht auf. Liegt aber
vieleicht an unterschiedlichen Testbedingungen.
Click to expand...
Das klingt dann aber wirklich eher nach systematischer Fehler als nach
Defekt...

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
 
"Tilmann Reh" <tilmannreh@despammed.com> schrieb im Newsbeitrag
news:dr1vr2$s5l$1@online.de...
Stefan Broering schrieb:

Ja, ich habe 2 identische Karten, die beim Kunden das selbe Problem
machen.
Bei mir in der Werkstatt tritt das Problem bisher nicht auf. Liegt aber
vieleicht an unterschiedlichen Testbedingungen.

Das klingt dann aber wirklich eher nach systematischer Fehler als nach
Defekt...

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
Click to expand...
Das Problem tritt nur dann auf, wenn ein bestimmtes Relais geschaltet wird,
aber nicht immer. Ich tippe daher eigentlich auf ein EMV-Problem. Merkwürdig
ist nur, dass das System nicht vollständig ausrastet und weiterhin auf
Kommandos reagiert.

Ich habe außer dem Takt für den Watchdog MAX1232 (CPL P3.2) keine weiteren
Zugriffe auf Port 3. Ich überlege gerade aber, was passiert beim CPL P3.2.
Irgendwas war da doch, dass dazu zunächst der Port eingelesen wird, dann das
Bit umgeschaltet und das Ergebnis als Byte zurückgeschrieben wird, wenn das
so ist, könnte der CPL P3.2 zu einem Zeitpunkt, zu dem die TXD-Leitung Low
ist dazu führen, dass diese auf Low bleibt??

Wenn das so ist, müsste das Problem aber öfter auftreten, es sei denn, mein
CPL P3.2 passiert normalerweise nur, wenn die TXD-Leitung gerade auf 1 ist.
Das kann aber nicht sein, bzw. eventuell doch... muss ich mal kontrollieren.

Ich werde erstmal das Bit vor dem Senden grundsätzlich auf 1 setzen,
trotzdem interessiert mich natürlich die genaue Fehlerursache.



Gruß

Stefan
 
Hm, ich habe gerade mal im Datenblatt nachgesehen, dort steht, CPL liest
zunächs das Output-Latch und nicht den Pin, demnach dürfte das nicht die
Fehlerursache sein. Hab trotzdem mal hinter jedes "CPL watchdog" ein "orl
%00000011" geschrieben.

Gruß

Stefan
 
Stefan Bröring schrieb:

Das Problem tritt nur dann auf, wenn ein bestimmtes Relais geschaltet wird,
aber nicht immer. Ich tippe daher eigentlich auf ein EMV-Problem. Merkwürdig
ist nur, dass das System nicht vollständig ausrastet und weiterhin auf
Kommandos reagiert.
Click to expand...
....und daß zwei Baugruppen sich gleich verhalten. (Könnte natürlich
trotzdem ein EMV-Problem sein.)

Ich habe außer dem Takt für den Watchdog MAX1232 (CPL P3.2) keine weiteren
Zugriffe auf Port 3. Ich überlege gerade aber, was passiert beim CPL P3.2.
Irgendwas war da doch, dass dazu zunächst der Port eingelesen wird, dann das
Bit umgeschaltet und das Ergebnis als Byte zurückgeschrieben wird, wenn das
so ist, könnte der CPL P3.2 zu einem Zeitpunkt, zu dem die TXD-Leitung Low
ist dazu führen, dass diese auf Low bleibt??
Click to expand...
Wie Du selbst schon feststelltest: nein.

Ich werde erstmal das Bit vor dem Senden grundsätzlich auf 1 setzen,
trotzdem interessiert mich natürlich die genaue Fehlerursache.
Click to expand...
Wenn Du systematisch suchen willst, mußt Du zunächst mal die Ursache
weiter eingrenzen bzw. den Fehler reproduzierbar machen. Das Schalten
des "bestimmten" Relais ist doch schon einmal ein Anhaltspunkt. Kannst
Du die von diesem Relais verursachten Störungen bewußt verschärfen?
Steht Dir Ausrüstung zur Untersuchung der EMV-Störfestigkeit zur
Verfügung (Burst-Generator)? Kannst Du anstelle dieses Relais zum Test
ein "nicht-störendes" Bauteil verwenden (z.B. SSR)? Wie ist insgesamt
die Hardware gegen Störungen von außen geschützt?

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
 
Wenn Du systematisch suchen willst, mußt Du zunächst mal die Ursache
weiter eingrenzen bzw. den Fehler reproduzierbar machen. Das Schalten
des "bestimmten" Relais ist doch schon einmal ein Anhaltspunkt. Kannst
Du die von diesem Relais verursachten Störungen bewußt verschärfen?
Steht Dir Ausrüstung zur Untersuchung der EMV-Störfestigkeit zur
Verfügung (Burst-Generator)? Kannst Du anstelle dieses Relais zum Test
ein "nicht-störendes" Bauteil verwenden (z.B. SSR)? Wie ist insgesamt
die Hardware gegen Störungen von außen geschützt?

--
Dipl.-Ing. Tilmann Reh
http://www.autometer.de - Elektronik nach Maß.
Click to expand...

Es handelt sich um einen AT89C5, Taktfrequent 11,0592 MHz, TTY-Eingang
passiv über Optokoppler galvanisch getrennt, TTY-Ausgang aktiv und mit der
5V Versorgung galvanisch verbunden, Schnittstellenumsetzer zum PC über 3m
Kabel mit galvanischer Trennung auf beiden Seiten.

Alle Ein- und Ausgänge, die zu Relais o.ä gehen sind über Optokoppler
galvanisch getrennt, Isolationsabstände > 5mm.
Stromversorgung 24V, heruntergeregelt auf 5V mit Schaltregler LM2575.

Die Stromversorgung ist momentan wieder mit der Steuerspannung des
Schaltkastens verbunden, 2. Netzteil hat nichts gebracht, könnte aber
nochmal ausprobiert werden.

Die Anlage steht beim Kunden, da ist es momentan arschkalt, dehalb war ich
heute ganz froh, keinen Anruf zwecks Umbau erhalten zu haben :)

Glücklicherweise ist der Kunde nur einige hundert Meter von hier entfernt,
werde die Tage mal den Prozessor tauschen.

Trotzdem hast du natürlich recht, die Ursache wüsste ich schon gerne,
unabhängig davon, ob der Trick mit dem Bitsetzen was bringt oder nicht.


Gruß

Stefan
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top