1. Home
  2. Electronics (German)
  3. 8031 sendet nicht auf Uart

8031 sendet nicht auf Uart

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

Reply to
Stefan Bröring
Loading thread data ...

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

Reply to
Bernd Laengerich

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

Reply to
Stefan Bröring

Stefan Bröring schrieb:

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.

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ß.
Reply to
Tilmann Reh

Ich habs noch nicht ausprobiert, weil das Gerät zur Zeit montiert ist, aber das klingt plausibel.

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

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

Reply to
Stefan Broering

"Stefan Bröring" schrieb

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

Reply to
Hans-Georg Lehnard

Stefan Broering schrieb:

Du hast bedacht, daß der Quasi-bidirektionale Port des 89C51 ein "high" nicht richtig treiben kann (ca. 40 kOhm interner Quellwiderstand)?

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ß.
Reply to
Tilmann Reh

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

Reply to
Stefan Bröring

Stefan Bröring schrieb:

Hast du schon mal den Prozessor ausgetauscht?

Fragt Jens

Reply to
Jens Carstens

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

Reply to
Stefan Broering

Stefan Broering schrieb:

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

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

"Tilmann Reh" schrieb im Newsbeitrag news:dr1vr2$s5l$ snipped-for-privacy@online.de...

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

Reply to
Stefan Bröring

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

Reply to
Stefan Bröring

Stefan Bröring schrieb:

...und daß zwei Baugruppen sich gleich verhalten. (Könnte natürlich trotzdem ein EMV-Problem sein.)

Wie Du selbst schon feststelltest: nein.

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ß.
Reply to
Tilmann Reh

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

Reply to
Stefan Bröring

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.