DCG2 BUG?

Hier könnt ihr Diskussionen über die Software des Labornetzteiles des c't-Lab führen.
linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

DCG2 BUG?

Beitrag von linux-is-sexy » 13.02.2008, 14:15

Hi,
leider kann ich keine eeprom Werte bei meinem DCG mit der Firmware von amd-65 aendern.
2:opt6
#2:156=20.0000
2:opt6=30!
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
2:opt6
#2:156=20.0000
2:wen=1
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
opt6=30!
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
Ich habe sowohl mit DCP als auch ohne versucht. Wenn ich das DCP angeschlossen habe klackt noch ein Relais, des weiteren konnte ich nicht mehr mit dem Modul vorher komunizieren....


Gruesse
LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Re: DCG2 BUG?

Beitrag von amd-65 » 13.02.2008, 17:39

linux-is-sexy hat geschrieben:Hi,
leider kann ich keine eeprom Werte bei meinem DCG mit der Firmware von amd-65 aendern.
2:opt6
#2:156=20.0000
2:opt6=30!
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
2:opt6
#2:156=20.0000
2:wen=1
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
opt6=30!
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
Ich habe sowohl mit DCP als auch ohne versucht. Wenn ich das DCP angeschlossen habe klackt noch ein Relais, des weiteren konnte ich nicht mehr mit dem Modul vorher komunizieren....
Ich kann das nicht nachstellen. Bei mir lassen sich die Parameter alle ändern. Irgendwie sieht es so aus, als würde der µC nach einem 'WEN=1' einen Reset ausführen. Tritt sowas auch mit CM's Firmware auf? Kannst Du mit einem Oszi die 5V-Versorgung auf Einbrüche prüfen? Hängt am DCG auch ein Panel? Wenn ja (nein), tritt das Problem auch ohne (mit) Panel auf? Irgendwie habe ich den Verdacht, daß die 'Brown-out detection' zuschlägt. Du könntest probehalber die 'Brown-out detection' per Fuse auf 2.7V stellen.

Gruß
amd-65

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Re: DCG2 BUG?

Beitrag von amd-65 » 13.02.2008, 17:45

linux-is-sexy hat geschrieben: 2:opt6
#2:156=20.0000
2:opt6=30!
Es sieht so aus, als willst Du das DCG auf 16Bit umstellen. Wenn Du die 16Bit-Version haben willst, dann läßt Du das EEPROM leer bzw. löschst es. Der µC initialisiert sich und das EEPROM auf die 16Bit-Version, wenn der Initwert nicht stimmt. Das EEPROM-File wird nur für die 12Bit-Version benötigt.

Gruß
amd-65

Benutzeravatar
ompf
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 168
Registriert: 19.01.2008, 13:03
Wohnort: Dortmund

Re: DCG2 BUG?

Beitrag von ompf » 13.02.2008, 18:21

linux-is-sexy hat geschrieben: 2:wen=1
#2:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#2:255=9 [FAULT]
Du meinst natürlich "2:wen=1!".

"wen=1" wäre lesen, und da dürfte vermutlich gar nichts passieren.


Gruß
Patrick

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Re: DCG2 BUG?

Beitrag von amd-65 » 13.02.2008, 18:31

ompf hat geschrieben:
linux-is-sexy hat geschrieben: 2:wen=1
Du meinst natürlich "2:wen=1!".

"wen=1" wäre lesen, und da dürfte vermutlich gar nichts passieren.
Das ist schon schreiben. Das Ausrufezeichen liefert zusätzlich den Status zurück, aus dem man ableiten kann, ob die Schreibfreigabe gesetzt ist. WEN lesend ist in der C-Firmware nicht implementiert. Bei CM entspricht es dem STR Befehl.

Gruß
amd-65

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 13.02.2008, 19:30

Also, dass mit dem EEprom war ein guter tip...Jetzt funzt die anzeige richtig! Danke!

Ich habe mit avrdude [...] -t ein erase gemacht, dann die fuses neu gesetzt und die firmware ohne eep geschrieben.

Das Problem mit der schreibfreigabe bleibt!


Gruesse
LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 13.02.2008, 19:44

Also ich habe nochmal rumgespielt:
DCG2 Firmware
0:idn
1:idn
#1:254=0.1 [DCG2 by Hartmut Birr 11/2007]
2:idn
#2:254=3.63 [DDS by CM/c't 03/2007]
0:idn
CMs Firmware:
0:idn
#0:254=1.731 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 IO32
1:idn
#1:254=2.753 [DCG by CM/c't 03/2007]
2:idn
#2:254=3.63 [DDS by CM/c't 03/2007]
Kann sich einer Vorstellen, woran das liegt?

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 13.02.2008, 22:24

linux-is-sexy hat geschrieben:Also ich habe nochmal rumgespielt:
DCG2 Firmware
0:idn
1:idn
#1:254=0.1 [DCG2 by Hartmut Birr 11/2007]
2:idn
#2:254=3.63 [DDS by CM/c't 03/2007]
0:idn
CMs Firmware:
0:idn
#0:254=1.731 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 IO32
1:idn
#1:254=2.753 [DCG by CM/c't 03/2007]
2:idn
#2:254=3.63 [DDS by CM/c't 03/2007]
Kann sich einer Vorstellen, woran das liegt?
Ich habe keine Ahnung was da geschieht. Wie ist eigentlich die Reihenfolge der Module? Sieht das DCG die Antwort auf '0:idn' oder den eigentlichen Befehl?

Ich habe beide Firmware Versionen vom DCG und DDS mit einem eigenen Programm und mit dem COMtest.vi gequält. Die C-Versionen haben sich auch bei 1.5MB/s keine Fehler geleistet. CM's Versionen haben bereits bei 38.4KB/s Aussetzer gezeigt. Ich habe dann einen verstümmelten Befehl oder eine Fehlermeldung als Antwort gesehen. Ich habes das auch bei 38.4kB mit zwei Modulen in Reihe getestet (DCG + DCG oder DDS + DCG). Ich kann aber nicht mehr sagen, ob ich alle möglichen Firmwareversionen getestet habe. Ich weiß nur noch, daß es immer Fehler gab, wenn CM's Firmware mit dabei war.

Gruß
amd-65

Gruß
amd-65

Benutzeravatar
siegiathome
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 62
Registriert: 30.11.2007, 11:43

Beitrag von siegiathome » 13.02.2008, 23:01

Hallo LiS,

ist das von Dir beschriebene Verhalten auch so zu 100% reproduzierbar? Falls nein, dann prüfe bitte, ob die einzelnen Module bei einem nicht erwartenen Verhalten auch die eingestellten (gejumperten) Moduladressen haben? Bei z.B. einer doppelt vorhandenen Adresse geht die Meldung der ersten doppelt vorhandenen Adresse verloren.
Ich habe mittlerweile auf allen Baugruppen die drei Adressjumper mit PullUps versehen, da ich mich nicht immer auf die eingebauten PullUps zu 100% verlasse (hab da schon schlechte Erfahrungen gemacht).

MfG
Siegi.

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 13.02.2008, 23:58

Also, nachdem ich alles ausprobiert hatte: Display dran,ab, als einziges modul, mit/ohne DCP habe ich unter Windows die unter Linux kompilierte SW geflasht. Immer noch das selbe. Also habe ich unter Windows das AVR-Studio runtergeladen und winavr und den ganzen kram damit kompiliert. Und siehe da es ging!!! Ich habe keine Ahnung warum, aber die unter Windows kompilierte Software ging sofort.
Sorry, dass ihr soviel Aufstand hattet.

Eine Sache noch: Wenn ich das DCG hochfahre/anschalte dann leuchtet die Strombegrenzer LED, wenn ich dann den Eingang Kuryschliesse oder sonstwie einmal im Strombegrenzer war, dann wechselt die LED und alles ist wie es sein sollte. Das Problem, dass bis auf das idn beim 1. Modul alles funzt bleibt.

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 14.02.2008, 00:39

linux-is-sexy hat geschrieben: Eine Sache noch: Wenn ich das DCG hochfahre/anschalte dann leuchtet die Strombegrenzer LED, wenn ich dann den Eingang Kuryschliesse oder sonstwie einmal im Strombegrenzer war, dann wechselt die LED und alles ist wie es sein sollte.
Das ist ein Bug. Port D wird beim Hochfahren falach initalisiert. PD3 darf da nicht auf 1 gesetzt werden.
Das Problem, dass bis auf das idn beim 1. Modul alles funzt bleibt.
Ich sollte da die Anordnung Deiner Module kennen, damit ich das nachstellen kann.

Gruß
amd-65

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 14.02.2008, 01:12

Ich habe als erstes Modul ADA-IO mit IO DA und AD und der Adresse 0, als zweites DCG mit DCP und Adresse 1, als drittes DDS mit TRMSC und Adresse 2.

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 14.02.2008, 16:58

linux-is-sexy hat geschrieben:Also ich habe nochmal rumgespielt:
DCG2 Firmware
0:idn
1:idn
#1:254=0.1 [DCG2 by Hartmut Birr 11/2007]
2:idn
#2:254=3.63 [DDS by CM/c't 03/2007]
0:idn
Kann sich einer Vorstellen, woran das liegt?
Ich kann das nicht nachstellen. Ich bekomme folgende Antworten:
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: ]
1:idn
#1:254=0.1 [DCG2 by Hartmut Birr 11/2007]
2:idn
#2:254=3.642 [DDS by CM/c't 03/2007]
*:idn
*:idn
#2:254=3.642 [DDS by CM/c't 03/2007]
#1:254=0.1 [DCG2 by Hartmut Birr 11/2007]
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: ]
Dabei ist allerdings das erste Modul (ADA) nur ein ATMega auf einem Steck-Board und das dritte meine halbfertige EDL. Das sollte aber keinen Einfluß haben.

Gruß
amd-65

linux-is-sexy
kann c't-Lab-Module umbauen
kann c't-Lab-Module umbauen
Beiträge: 65
Registriert: 29.11.2007, 14:38
Wohnort: Aachen

Beitrag von linux-is-sexy » 14.02.2008, 22:30

Also ich habe selber nochwas gebastelt:
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 IO32 ]
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: AD16 IO32 ]
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 ]
Und wenn ich alle 3 drin habe, dann antwortet es nicht...

Gruesse LiS
“Intelligence is the ability to avoid doing work, yet getting the work done” Torvalds

amd-65
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 130
Registriert: 29.11.2007, 16:28

Beitrag von amd-65 » 15.02.2008, 00:31

linux-is-sexy hat geschrieben:Also ich habe selber nochwas gebastelt:
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 IO32 ]
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: AD16 IO32 ]
0:idn
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 ]
Und wenn ich alle 3 drin habe, dann antwortet es nicht...
Es hat was mit dem internen Puffer zu tun. Der ist 63 Zeichen groß. CM's Firmware benutzt nur die ersten 63 Zeichen, wenn das Kommando zu lang wird. Meine Firmware verwirft das Kommando, wenn es nicht mehr in den Puffer paßt.

Eigentlich ist beides, so wie es implementiert ist, falsch. CM's Firmware führt gegebenenfalls ein Kommando aus, bei dem ein Teil fehlt. Das wird vermutlich nicht vorkommen, da das Setzen irgend eines Wertes nicht >63 Zeichen benötigt. Meine Firmware verwirft das Kommando, wenn 63 (od. 64?) Zeichen eingetroffen sind. Der Rest wird dann als neuses Kommando interpretiert.

Alles was größer 63 Zeichen ist sollte verworfen werden. Es muß aber so erfolgen, daß der gesammte nicht in den Puffer passende String verworfen wird.

Gruß
amd-65

Antworten