Probleme mit Optobus

Themen rund um die Hardware und Abgleich des Digitalvoltmeters DIV gehören hier rein.
Antworten
Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Probleme mit Optobus

Beitrag von Neuling » 25.09.2015, 17:13

Ich bin völlig ratlos: Ich habe das DIV aufgebaut und mit der cm-Software geflasht. Das DIV (noch ohne AC-Wandler) scheint zu funktionieren - auf dem PM8 zeigt es in allen DC-Bereichen Messwerte an. Soweit so gut. Aber: die Bedienung über den Optobus klappt nicht.

Ein Test mit COMtest.vi zeigt permanent Fehler (ca. 98% bis 99%; gelegentlich kommt der Teststring "hallo Testkanal" durch). Klemme ich DIV ab und ersetze es durch den Kurzschlussstecker, so entstehen keine keine Fehler. Auf den Adressen davor liegt 1 mal ADA I/O und 2 mal DCG.

Verfolgt man auf der DIV Platine das Signal, so sieht es (mit dem Scope) hinter dem 6N137 (Pin 6) genauso sauber aus wie an Pin 15 (TxD) des ATmega32. Die Versorgungsspannung beträgt 5.03V und der Quarz schwingt mit 16 MHz. Die ausgelesenen Fuses des ATmega32 sind wie in der Programmieranleitung beschrieben und beim Flashen von Programm und Daten mit dem mySmartUSB light (von myAVR.de) war das verify OK. Auch mehrmaliges Neuprogrammieren hat nichts verändert.

Also meine Fragen:
Hat Jemand eine Idee, wo ich noch weiter suchen kann?
Hat jemand gehört, dass es Probleme mit dem UART des ATmega gibt? Wo wäre ein Forum, wo so etwas diskutiert wird?
Weiß Jemand eine Hexfile, dass es erlaubt, nur die Optobus Daten vom Eingang auf den Ausgang zu senden, um sicherzustellen, dass der übrige Code keinen Einfluss auf die Kommunikation hat?
Laufen im DIV-Programm Interrupt-Routinen, die versehentlich evtl. durch einen Fehler in der Schaltung ständig ausgelöst werden und damit die Kommunikation stören?
Wie wahrscheinlich ist, dass der ATmega32 so subtil defekt ist, dass er mit dem Panel ordentlich zu laufen scheint?

Und noch etwas: wenn ich das .hex File auslese und mit HxD mit dem ursprünglichen .hex-File vergleich, so unterscheiden sich beide völlig, obwohl der Programmer verify OK gemeldet hat. Wo kann man sich kundig machen, was der Programmer verändert?

Benutzeravatar
lab-freund
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 94
Registriert: 23.01.2015, 20:27

Re: Probleme mit Optobus

Beitrag von lab-freund » 25.09.2015, 18:49

Bitte das DIV einmal mit einer Minimalkonfiguration ohne die anderen Geräte betreiben.
Wurden beide Anschlussvarianten mit Hyperterminal oder Linux-Äquivalent über USB und RS232 getestet?

Habe das DIV übrigens auch ohne AC-Modul aufgebaut. Noch, aber nicht mehr lange läuft die Originalfirmware von cm bei mir.

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 897
Registriert: 25.01.2008, 23:34

Re: Probleme mit Optobus

Beitrag von psclab38 » 25.09.2015, 20:16

Also prinzipiell muß der COMtest auch in der Kette mit mehreren Modulen brav funktionieren. Habe hier DDS, 2*DCG und DIV hintereinander, allerdings alle mit C-Firmware, versteht sich ;-) . Die Reihenfolge der Geräte ist in Bezug auf ihre Adresse vollkommen egal.
Was passiert, wenn Du im Teststring vom COMtest die Adresse des DIV angibst? Dann müßte die Frontplatten-LED des DIV aufleuchten, weil das Modul das Kommando nicht nur durchreichen sondern verarbeiten muß.

Wie lab-freund schon gesagt hat, mal das DIV einzeln austesten, nur am Terminalprogramm mit 38400 bps. Geht das "*:idn?" ?

Du kannst testhalber mal die C-Firmware verwenden, ob das einen Unterschied macht.

Wenn der Verify beim Programmieren gut geht, dann sollte das Programm korrekt laufen. An einen Defekt nur im UART mag ich nicht so recht glauben.

Was das Hexfile angeht: Du kennst das Format? https://de.wikipedia.org/wiki/Intel_HEX
Man kann die Daten vollkommen verschieden darin codieren und trotzdem wäre es das gleiche.

Benutzeravatar
Bart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 45
Registriert: 11.01.2014, 10:44

Re: Probleme mit Optobus

Beitrag von Bart » 26.09.2015, 07:37

Hast Du vielleicht die Moduladressen mehrfach vergeben?

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Re: Probleme mit Optobus

Beitrag von Neuling » 26.09.2015, 14:03

Erstmal vielen Dank für die schnelle Reaktion.

Die Moduladressen waren korrekt: ADA I/O=0, DCG(1)=1, DCG(2)=2, DIV=3. Die Hinweise, das DIV nur mit dem IFP zu betreiben waren ebenso hilfreich wie der, mit einem Terminalprogramm die Module anzusprechen. Das Ergebnis ist wie folgt:

IFP + DIV ist ok: COMtest.vi läuft durch und mit LKTerm antwortet DIV auf 3:val 0? korrekt. Das gleiche Ergebnis bei der Kette IFP + ADA I/O und IFP + ADA I/O + DCG(1). Bei der Kette IFP + ADA I/O + DCG(1) + DCG(2) zeigt sich wieder das alte Verhalten: COMtest.vi zeigt permanent Fehler und LKTerm zeigt permanent Aktivität auf dem Bus (was sich auch im Oszilloskop zeigt). Nachdem COMtest durchgelaufen war, sendete jemand permanent folgenden String:""E50:253? hallo T D A4 BQ50:253? hallo*1fa#3:255=33 [OVRNEG]", Nach dem Aus- und Wiedereinschalten änderte er sich in: ":254=3.10 [DIV by CM//c04$D@ @EIHA"6 AD16 IO32 LCD ]a" , um nach einigen Minuten sich in:"#3:255=5 [PARERR]" zu ändern, wobei das Display 0,0002V DC 25V angezeigt hat. Entfernt man das DCG(1) aus der Kette, bleibt der Fehler. Er scheint also auf dem DCG(2) zu liegen.

Daraus schließe ich, dass das DIV soweit i. O. ist, sondern der Fehler im DCG(2) liegt. Bei diesem Exemplar war mir der ATmega32 aus unerklärbaren Gründen abgeraucht (im wahrsten Sinne: erst Unsinn auf dem PM8 angezeigt, dann das Display verdunkelt und die Versorgungsspannung auf 4,05 V belastet. Ein Berühren des Gehäuses zeigte Übertemperatur kurz vor Brandblase.) und durch einen ATmega32A ersetzt. Nach Programmieren lief DCG(2) wieder einwandfrei.

Wegen des Optobus-Fehlers habe ich DCG(2) nochmal nach einem Erase programmiert, diesmal mit ponyprog, weil der mySmartUSB light dabei einen Fehler angezeigt hatte, was wohl an der zu niedrigen Spannung am USB-Adapter (4,7V) gelegen haben mag. Auch die Neuprogrammierung hat keinen Einfluss auf den Fehler gehabt. Kann es sein, dass der Unterschied zwischen ATmega32 und ATmega32A eine Rolle spielt? Ich hatte bei Atmel nachgesehen und in einer App-Note nur gefunden, dass die Stromaufnahme niedriger sei, ansonsten aber alles gleich sei, obwohl es ein eigenes datenblatt für den -A gibt.

Da ich mich mit der Software noch nicht auseinander gesetzt habe, weiß ich jetzt nicht weiter.

Vielleicht hat jemand noch eine Idee, möglicherweise mit einer Änderung in der Software, denn das Aus- und Wiedereinlöten des TQFP hat die Platine doch arg mitgenommen. Nochmal möchte ich das nicht versuchen.

@psclab38: danke für den Link.

Benutzeravatar
lab-freund
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 94
Registriert: 23.01.2015, 20:27

Re: Probleme mit Optobus

Beitrag von lab-freund » 26.09.2015, 16:41

Schön, dass Du weitergekommen bist!

Läuft denn das DCG Nr. 2 alleine fehlerfrei am IFP?

Bitte auch auf alle verwendeten Kabel achten!

Es war einmal ein Formel1-Team, dem ging beim Testen immer das Auto auf der Rennstrecke aus. Das Testteam ging abends frustriert zurück ins Hotel. Elektroingenieur und Elektrotechniker blieben. Um 4:00 morgens endlich fand der Techniker, dass bei dem Stecker eines Kabels der Motorsteuerung die Zugentlastung fehlte. Unter Fliehkraft wurde der Kontakt unterbrochen.

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Re: Probleme mit Optobus

Beitrag von Neuling » 26.09.2015, 19:05

Ja, es läuft sowohl am IFP alleine als auch in der Kette mit den anderen Baugruppen in einer Reihe fehlerfrei. Erst beim Anschalten des DIV geht der Zauber los.

Eine Frage an die Softwarespezialisten: Gibt es einen Schalter beim compilieren, der die A-Version von der Standardversion unterscheidet?

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 897
Registriert: 25.01.2008, 23:34

Re: Probleme mit Optobus

Beitrag von psclab38 » 26.09.2015, 20:21

Neuling hat geschrieben:Eine Frage an die Softwarespezialisten: Gibt es einen Schalter beim compilieren, der die A-Version von der Standardversion unterscheidet?
Nein, es gibt überhaupt keinen Unterschied aus Software-Sicht.
http://www.atmel.com/Images/Atmel-8155- ... asheet.pdf
http://www.atmel.com/Images/doc8162.pdf

Wo hast Du den 32A her? Aus verlässlicher Quelle?

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Re: Probleme mit Optobus

Beitrag von Neuling » 26.09.2015, 20:49

Das zweite Dokument hatte auch ich zugrunde gelegt.

Wenn also die beiden Prozessorvarianten softwaremäßig gleich sind, dann bleibt nach wie vor die Denksportaufgabe:

Das DIV, genauer: die Kommunikation auf dem Optobus, funktioniert mit einem DCG(1) und DIV. Beim Auswechseln gegen DCG(2) tritt der Fehler auf, während alles Andere gleich bleibt. Irgendwie wird dauernd ein String, dessen Inhalt sich je nach Anfangsbedingung ändert, gesendet, und diese Aktivität legt den Optobus praktisch lahm. Trotzdem funktioniert das DCG(2) ohne das DIV in allen Kombinationen einwandfrei und auf dem Bus laufen nur die gesendeten und angeforderten Daten.

Rätselhaft.

Quelle des ATmega32A: Reichelt, unauffällige Beschriftung, einzeln in antistatischem Pappschächtelchen verpackt

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 897
Registriert: 25.01.2008, 23:34

Re: Probleme mit Optobus

Beitrag von psclab38 » 26.09.2015, 21:38

Ja, klingt echt rätselhaft.

Also: wenn die das DCG(2) und das DIV hinterienanderhängen, dann sendet jemand, quasi unaufgefordert? Richtig?
Bei den Strings, die Du schon "zitiert" hast sind Zeichenfehler drin. Das heißt, das Timing stimmt nicht. Bei Puffer-Überlauf würden wohl nur Zeichen fehlen.

Kontrolliere mal, ob die Bits immer alle schön gleich breit sind, auch zwischen den Modulen.

Sind DIV und DCG(2) potentialgetrennt?

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Re: Probleme mit Optobus

Beitrag von Neuling » 27.09.2015, 13:50

@ Potentialtrennung: à la Radio Eriwan: Im Prinzip ja, aber wenn ich ausschließlich die beiden Module DCG(2) und DIV nur mit dem Optobus und ohne Stromversorgung auf dem Labortisch miteinander verbinde, messe ich mit meinem Multimeter 750kOhm zwischen den beiden Massebuchsen. Wenn ich die Abschlussjumper des DIV entferne, ist die Verbindung unterbrochen. Sorgfältige Reinigung der DCG(2) Platine mit Isopropanol hat nichts verändert. Bei der optischen kontrolle der Lötungen des eingewechselten ATmega32A kamen mir zwei Lötstellen etwas fragwürdig vor, aber ein Nachlöten hat keine Änderung bewirkt. Im Betrieb beider Module ist dann ein Widerstand von 43 Ohm zu messen, der bei Abschalten der Netzspannung auf 10-er MegOhm springt und dann langsam auf 1,6 Megohm fällt. Eine Wechselspannung zwischen den beiden Massebuchsen zeigt das Scope nicht an. Entfernen der Abschlussjumper zeigt wieder offenen Stromkreis am Multimeter. Was ich nicht verstehe, wieso überhaupt eine niederohmige Masseverbindung entstehen kann, selbst wenn eine Pin-Schutzbeschaltung defekt sein sollte.

Unter der Annahme, dass eine schlechte Lötstelle des ATmega32A die Ursache sein könnte, welche könnte es sein, die nur auf das Vorhandensein eines weiteren Moduls reagiert oder durch Kriechströme derart beeinflußt wird, denn TxD und RxD funktionieren ja ansonsten normal? Oder habe ich die Eingangsschuzbeschaltung nicht verstanden?

Die Impulse auf dem Bus sehen insoweit gleichlang aus, wenn man berücksichtigt, dass das Signal NRZ codiert ist. Die RS232 Darstellung auf meinem HMO1022 zeigt auch nur gelegentlich rot.

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Re: Probleme mit Optobus

Beitrag von Neuling » 27.09.2015, 16:52

Problem gelöst:

Allerdings muss ich mit roten Ohren beichten: ich hatte völlig vergessen, die Abschlussjumper des Optobus zu ziehen, als ich das DIV an die Kette angehängt hatte. Der Hinweis von psclab38, ob die beiden Module potentialgetrennt sind (und ein langer Spaziergang nach dem vorigen Post), hat mich schließlich auf die Fährte gebracht.

Also: wenn der Optobus Amok läuft: nach den Abschlussjumpern sehen.

Nochmal ganz herzlichen Dank für die prompte Hilfe, die geduldige Begleitung und mit der Bitte um Nachsicht

Günther

psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 897
Registriert: 25.01.2008, 23:34

Re: Probleme mit Optobus

Beitrag von psclab38 » 28.09.2015, 20:42

Neuling hat geschrieben:Problem gelöst:
Sehr gut!
Neuling hat geschrieben:Nochmal ganz herzlichen Dank für die prompte Hilfe, die geduldige Begleitung und mit der Bitte um Nachsicht.
Kein Problem, gerne geschehen. Manchmal findet man die Ursache indem man versucht, jemand anderem das Problem zu erklären. :D

Neuling
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 29
Registriert: 15.06.2013, 12:45

Geschlachteter Prozessor

Beitrag von Neuling » 17.11.2015, 16:29

Falls hier noch jemand daran interessiert ist, warum mein Prozessor abgeraucht war, hier ist die Erklärung:
http://www.thoralt.de/phpbb/viewtopic.php?f=12&t=838

Antworten