Hibernate - Problem

[Nucor (Gast)]

Hi,

bei einem C# - Programm, das mit einem Atmega64 über die serielle
Schnittstelle kommuniziert, tritt beim Powerdown des Laptops ein
vollständiges Blockieren des Programmes auf. Powerdown  wird
eingeleitet durch Zuklappen des Laptops oder nach Ablauf der
eingestellten Zeit. Danach verriegelt sich das C# - Programm total.
Graues Fenster, keine Annahme von Maus oder Tastatur, selbst
mit dem Task-Manager lässt es sich nicht entfernen.

Die verwendeten Komponenten sind:
Visual Studio 2010, Net 4, C#, SafeSerialPort.

Die Fehlersuche wird erschwert durch die Tatsache, daß beim
"Schlafengehen" (Hibernate) des Laptops auch kein Debuggen
mehr möglich ist.

Um den Fehler einzugrenzen habe ich 5 Eventhandler eingebaut:

SystemEvents.EventsThreadShutdown
SystemEvents.PowerModeChanged
SystemEvents.SessionSwitch
SystemEvents.SessionEnding
SystemEvents.SessionEnded

und Text in eine Datei ausgeben lassen. Beim Zuklappen wird
OnPowerModeChanged ausgelöst mit PowerModeChangedEventArgs =
PowerModes.Suspend.

Mit diesem Ereignis versuche ich mit

serialPort.Close();

serialPort.Dispose();

Application.Exit();

das Hängen des Programms durch Beenden desselben zu verhindern.
Leider ohne Erfolg.

Anzumerken ist noch, daß der Laptop keine echte Com - Schnittstelle
mehr hat. Das V24 - Kabel hängt an einen V24/USB - Adapter.

Bin für jede Anregung dankbar.

mfg

Nucor

[doofi (Gast)]

> V24/USB - Adapter

Die Macke haben wohl alle Prolific-Adapter.

Vielleicht mal nen anderen nehmen?

[Michael U. (michaeluray)]

Hmm. Klingt irgendwie nach einem Treiber Problem des USB Konverters.

Passiert dies nur, wenn die Verbindung geöffnet ist?

Passiert dies auch bei einem anderen Konverter (anderer USB/RS232 Chip 
Hersteller) oder bei einer fest eingebauten COM Schnittstelle?

Kann das Programm eigentlich generell (also wenn es manuell gestart 
wird) nachdem der Laptop aufgeweckt wurde, auf die Schnittstelle 
zugreifen?

Wie reagiert das Programm eigentlich, wenn im Betrieb der USB Konverter 
entfernt wird?

Du könntest auch noch versuchen, im Gerätemanager beim entsprechenden 
USB-Root-Hub im Bereich Energieverwaltung den Punkt "Computer kann das 
Gerät ausschalten, um Energie zu sparen" zu deaktivieren. Eventuell 
zeigt das auch eine Auswirkung auf das Verhalten.

lg.
Michi

[Purzel H. (hacky)]

Ja. diesen Fehler habe ich auch schon festgestellt. Diesmal mit einem 
FTDI Chip, dem passenden Treiber, einem anderen Communication package, 
einer anderen Sprache. Das einzig Moegliche ist ein sauberer Reboot. Ist 
leider so.

[Michael U. (michaeluray)]

Ich hatte auch schon einmal Probleme mit virtuellen COM Ports, wo danach 
nur noch ein Neustart des Rechners half. Vielleicht kommt das Problem 
irgendwo aus dieser Richtung.

Falls es ein FDTI Chip ist, könnte es eventuell helfen, die 
Kommunikation über D2XX und nicht über den Virtual COM Port (VCP) 
aufzubauen.
Auf der FDTI Homepage sind auch einige Beispiele für C# verfügbar:
http://www.ftdichip.com/Projects/CodeExamples/CSharp.htm

[Läubi .. (laeubi)]

Hibernate != Hibernation

Hibernate: http://www.hibernate.org/
Hibernation: http://de.wikipedia.org/wiki/Hibernation

[TestX .. (xaos)]

Läubi .. schrieb:
> Hibernate != Hibernation
>
> Hibernate: http://www.hibernate.org/
> Hibernation: http://de.wikipedia.org/wiki/Hibernation

das debian package "hibernate" haste noch vergessen ;)

@topic
habe atm das gleiche problem mit dem vcp driver..werde es mal mit dem 
d2xx java wrapper probieren. wahrscheinlich muss ich die verbindung vorm 
ruhezustand jedoch trennen

[Nucor (Gast)]

Hi,

vielen Dank für die vielen Hinweise.

Das Problem ist der Treiber des FTDI - USB-Adapters.

Mit einem Prolific - USB-Adapter gehts problemlos.
Klappe des Läppis schliessen, der Läppi stellt die Arbeit ein,
das Programm beendet die Kommunikation mit dem ATMEG64,
Klappe auf, der Läppi startet wieder, das Programm tauscht
wieder Daten aus. Auch den USB-Adapter entfernen und wieder
verbinden geht. Das Programm stellt ordnungsgemäß die Aktivität
mit dem ATMEGA ein und setzt bei Wiederanschluss
problemlos auf.

Die naheliegende Vermutung, daß der Treiber für FTDI nicht
aktuell ist, bin ich nachgegangen. Mit CDM20602 (=Version 206.02)
ist er auf dem neuesten Stand.

Der Prolific - Treiber hat die Version 3.20. Beide Treiber
waren schon in Vista vorhanden.

Den anderen Vorschlägen werde ich noch nachgehen. Jedenfalls
bin ich froh, daß es jetzt geht. Als Programmierer ich bin es
gewohnt den Fehler erst mal in den eigenen Sachen zu suchen. Dort
liegt ja auch zumeist zu 99,9% die Ursache. Mit der Zeit wird man
allerdings betriebsblind. Mit ein paar Denkanstößen von euch kommt
leichter ans Ziel.


mfg

Nucor