485Bus zerstört UART bei Kollision

[wurm]

Hallo,

ich habe folgende Schaltung:
Atmega128 verbunden mit MAX485 (RXD über 1k an RO, TXD über 1k an DI, PD4 direkt an RE und DE)
BUS A und BUS B gehen dann an einen nächsten MAX 485.
Dieser ist dann direkt (also ohne Widerstände) an einen Pic16f873a angeschlossen (RXD an RO, TXD an DI).
Die Beschaltung mit den 120 Ohm zwischen Bus A und Bus B sowie jeweils die 560 Ohm-Widerstände an +5V und GND sind auch vorhanden.

Habe dann ein wenig an der Kommunikationssoftware gebastelt und einige Einstellung bzgl. des Timings getestet. Dabei kam es mehrmals vor, dass beide MAX 485 auf RE und DE auf High war und so beide auf Senden standen. Nach kurzer Zeit war dann die UART am Atmega hin.

Kann man dieses Problem hardwaremäßig unterbinden (vielleicht mit den beiden 47 Ohm Widerständen jeweils in Bus A und Bus B?
Werde natürlich die Software so ändern, das das kein Problem mehr ist, aber man weiß ja nie. Würde das gerne von der Hardware-Seite aus abgestellt haben.

Mfg,
Wurm

[theborg]

Schutzdioden an den ports ?

[wurm]

Nein, habe keine Schutzdioden an den Ports. Sollte nicht eigentlich der 485 den Pegel passend erzeugen. Dieser liegt doch auf 5V.
Oder läßt der 485 bei Kollision mehr als die 5Volt durch?

[theborg]

naja wen ne positive und ne negative(b.z.w. 0v) flanke aufeinander treffen was entsteht den na .... genau richtig nen kurtzschluss.

[wurm]

Ok,mit dem Kurzschluss habe ich verstanden. Trotzdem verstehe ich noch nicht, warum die UART kaputt geht.
Nehmen wir den Kurzschlußfall an. Dann würde die TXD-Leitung vom Controller einen sehr hohen Strom liefern müssen. Dafür ist aber doch der 1k Widerstand vorhanden. Der begrenzt den Strom.

Wo sollen die Schutzdioden denn angeschlossen werden?

Mfg,
Thorsten Wurm

[theborg]

Poste doch mal nen auschnit deiner schaltung des macht es etwas einfacher

[wurm]

So, im Anhang sind dann mal die Schaltpläne.

Mfg,
Thorsten Wurm

[wurm]

Hi,

habe jetzt in die Bus A und Bus B Leitung jeweils einen 47 Ohm Widerstand eingebaut. Hat leider auch nix gebracht.
Zusätzlich habe ich auch noch an den beiden Enden des Busses eine SM05-Schutzdiode an den Bus angebunden, also zwischen Bus A und Bus B und GND. Leider auch ohne Erfolg. Die UART des Atmega ging nach ca. 1 Minute wieder kaputt.

Mfg,
Thorsten Wurm

[shaun]

Wenn Du den RxD-Anschluss nicht irgendwo aus Versehen als Ausgang konfigurierst, klingt das Ganze etwas unwahrscheinlich. Die 1k-Widerstände sollten selbst wenn die 24V irgendwie ihren Weg auf den xx485 schaffen den AVR verschonen. Da ist was anderes faul!

[wurm]

Hallo,

der RXD wird im kompletten Programm nicht als Ausgang konfiguriert.
Hatte auch Kontakt mit MCSELEC, die haben das Programm geprüft.
Es sieht so aus, als wenn der R67 in der Schaltung falsch ist. Das meinte auch der Support von Maxim.
Ich konnte das nur noch nicht 100% testen, da ich nicht mehr die benötigte Hardware habe und erst auf Platinen mit getauschten Atmega´s warten muss.
Meine Tests bis dahin waren aber erfolgreich. Normalerweise ging der Atmega nach spätestens einer Minute kaputt und ohne den Widerstand habe ich die Schaltung 15 Minuten in Betrieb gehabt.

Mfg,
Thorsten Wurm

[Vitis]

welchen 485 busbaustein verwendest Du?
Hab schon was mit 485 gebastelt, aber das
der Baustein durchschlägt auf den µC hab ich noch
nie erlebt.

[wurm]

Hallo,

ich benutze an dem Atmega einen 485 von Sipex (SP485).
So wie es aussieht ist das Problem der 10k Widerstand, der von Vcc (+5V) nach RXD am Atmega geht. Sollte eigentlich nur in Pullup sein, der im Einschaltmoment ein definiertes Signal liefert.
Wird am Dienstag ausgiebig getestet, da ich dann beim Elektronik-Fertiger bin und da bei Bedarf die Atmegas getauscht werden können.

Mfg,
Thorsten Wurm

[shaun]

Welche Ursache soll der Defekt denn haben?
Es ist kein Szenario erklärbar, ausser dass im SP485 ein kleines Männchen sitzt, dass bei vorgefundenem Pullup einen EMP Richtung Controller schickt ;)
Im Ernst: ob der Hersteller (in diesem Fall nicht mal der des Chips) den Widerling für notwendig erachtet oder nicht, zu einer Zerstörung des Controller kann er nicht führen. Wenn doch, liegt die Ursache ganz wo anders.