Forum: Mikrocontroller und Digitale Elektronik AT89C51ED2 programmieren geht nur noch über direkte UART/TTL Verbindung zum Controller


von Milo (Gast)


Lesenswert?

Hallo Spezialisten,

ich bin am verzweifeln und völlig ratlos.

Folgendes Szenario:

Ich habe mir vor langer Zeit mal ein Entwicklungsboard für einen 
AT89C51ED2 Controller gebaut. Auf diesem Board ist einerseits ein 
Steckverbinder um direkt an die RX/TX Pins des Controllers zu gehen 
sowie ein Schnittstellenwandler, der besagten UART über zwei 
MAX485+Optokoppler als RS/422 nach außen führt.

Über beide Verbindungen kann ich den Controller problemlos mit FLIP 
programmieren, wobei ich das über RS/422 nur mit max. 19200baud konnte.

Jetzt habe ich eine neue Version des Boards gebaut und anstelle der 
beiden MAX485+Optokoppler (isolierte Schnittstelle) einen TI ISO3080DW 
eingesetzt.

Im Betrieb arbeitet die Schnittstelle absolut sauber. Auch das 
Propagation Delay bzw. die Signallaufzeit ist bei dem ISO3080DW besser 
als bei der Kombination aus MAX485+Optkoppler.
Ich kann sogar eine Verbindung mit FLIP bei 115000baud herstellen, was 
früher immer zu einem Timeout geführt hat.

Was mich aber ratlos macht:
Ich kann den Controller nicht mehr über die RS422 Schnittstelle 
programmieren - nur noch direkt über den UART.
FLIP meldet mir: "Device Protection is set"... stimmt aber nicht und 
ergibt auch keinen Sinn, weil die ersten beiden Schritte - Erase + 
Blank-Check ja auch erfolgreich ausgeführt werden. Der Fehler tritt erst 
bei Schritt 3 (Programming) auf.

Wo könnte denn hier bitte das Problem zu suchen sein?

Ich verstehe es einfach nicht.

Hat jemand eine Idee, wo ich hier suchen könnte?
Der Datenverkehr sieht auf dem Board an allen Punkten ok aus...

Danke für jede Idee.

Milo

von Peter D. (peda)


Lesenswert?

Ohne Schaltplan beider Varianten hilft da nur noch die Glaskugel.

von Milo (Gast)


Angehängte Dateien:

Lesenswert?

Hallo Peter,

vielen Dank schonmal und sorry wegen des fehlenden Schaltplans.

Siehe Anhang.

Nicht eingezeichnet sind die Abblock-C's, die am Controller, am 74hct08D 
und am ISO3080DW mit 100nF natürlich vorhanden sind.
Ebenfalls nicht eingezeichnet ist die Spannungsquelle für die isolierte 
Seite des 3080DW, hier stattdessen einfach mit 0V (=ISO-GND) und +5V 
(=ISO-VCC) angedeutet.

Über den Steckverbinder J1 kann ich den Controller problemlos 
programmieren.

Über die RS422 kann ich lediglich ERASE und BLANK-CHECK erfolgreich 
machen, beim programmieren steigt Atmel Flip mit der Meldung "Device 
Protection is set" aus.

Wenn ich mit dem Oszi messe, sind alle Signale da. Man sieht auch an der 
RS/422 Schnittstelle, dass der Controller beim programmieren antwortet.

Ich bin ratlos...

von Pieter (Gast)


Lesenswert?

moin moin,

habe den Quelltext für meinen ED2-Programmer mal durchgesehen( ist ja 
LichtJahre her  ), eine Fehlermeldung "Device
Protection is set" kommt da nicht vor. Habe allerdings auch nur nach 
geht/geht nicht unterschieden.
Nach Erase sollte alles funktionieren.

Rückgabe nach Programmierung war:
'.'    ok
'X'    Fehler, kann nochmal
'P'    ?, könnte protect sein.
Es war eine Wartezeit von bis zu 2sec programmiert.

Warum RS422 wenns über RS232 geht?

von Milo (Gast)


Lesenswert?

Hi Pieter,

Pieter schrieb:
> Nach Erase sollte alles funktionieren.

ja - der Meinung bin ich eigentlich auch. Es sei denn, mit "Device 
Protection" ist hier noch was anderes gemeint, als bspw. die Security 
Levels, die man setzen kann. Aber nach einem Erase sollten sämtliche 
Schlösser definitv weg sein.
Zeigt ja auch die Tatsache, dass es über den TTL UART geht.

>
> Warum RS422 wenns über RS232 geht?

Naja, hier ist es ja nur ein Entwicklungsboard. Da spielt es erstmal 
keine große Rolle.
Aber ich möchte gerne nach dieser Vorlage dann auch eine Platine (ca. 30 
Stück) erstellen, die ihrerseits vergossen werden soll. Da möchte ich 
den TTL UART nicht nach außen führen sondern nur den RS-422.

Als Timeout habe ich in Flip auch schon bis 3 Sekunden eingestellt. Hat 
nix geändert...
Ich werde es mal mit dem BatchISP tool versuchen. Evtl. bekomme ich da 
noch ein paar Debugausgaben mehr.

:/

von Peter D. (peda)


Lesenswert?

Diese ISO-Chips sind recht mimosenhaft. Die beiden 100nF müssen wirklich 
so dicht wie möglich am Chip sein.
Ich hab allerdings mit TI schlechte Erfahrungen gemacht (ISO7241) und 
dann zu AD gewechselt (ADUM1401).

von Milo (Gast)


Lesenswert?

Hi Peter,

> Diese ISO-Chips sind recht mimosenhaft. Die beiden 100nF müssen wirklich
so dicht wie möglich am Chip sein.

Hmmm... also die beiden C's sitzen wirklich unmittelbar an den supply 
pins für VCC und ISO-VCC. Wenn ich noch näher dran will, müsste ich sie 
auf den Pin drauflöten.

Aber mir war nicht bekannt, dass die so empfindlich sind.

Ich werde mal versuchen, die Daten, die da übertragen werden, auf einer 
Zeitachse mitzuschneiden. Vielleicht ist das was erkennbar.
Ansonsten probiere ich es mal mit einem anderen Schnittstellenwandler.

Alles sehr merkwürdig...

Stromversorgung auf beiden Seiten ist stabil und glatt, die Signale auf 
der Schnittstelle sind sauber, niedrigere Signallaufzeit als mit 
MAX485... und trotzdem diese unplausible Fehlermeldung.

Vielleicht bestelle ich mir auch nochmal einen anderen RS/232 <=> RS/422 
Wandler für die Verbindung zum PC. Evtl. liegt da ja irgendwie der Hase 
im PFeffer.

Danke auf jeden Fall, dass ihr euch mit der Sache beschäftigt habt.

Milo

von Milo (Gast)


Lesenswert?

Hmmm... Teilerfolg, aber trotzdem nicht schlauer.

Wenn ich die TVS Dioden (P6SMB6.8CA), die sich direkt am RS-422 
Steckverbinder befinden, rauslöte, dann kann ich den Controller auch 
über die Schnittstelle programmieren. Zwar nur mit 19200 baud, aber 
immerhin.

Löte ich sie wieder ein, gehts nimmer.

Aber wie ist das zu erklären? Die tun doch eigentlich nix, es sei denn, 
die Spannung auf der Busseite wird zu hoch. Aber die Pegel sind +5V/-5V.

Ich habe ein bisschen die Befürchtung, dass sich meine 
Eingangsbeschaltung mit der internen Failsafe-Schaltung des ISO3080 
beisst.
Andererseits kommt ja jeweils hinten raus was vorne reingeht.

Es ist zum Mäuse melken...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.