Hallo, ich habe mit vb. net 2010 Express ein kleines Programm geschrieben, womit ich den EEprom eines Atmega32 auslesen kann, also per Button 1024 Bytes. Das funktioniert alles super, nur wenn ich das ganze öfters hintereinader mache bekomme ich von vb einen Laufzeitfehler: Die Laufzeit hat einen schwerwiegenden Fehler entdeckt. Fehleradresse: "0x67e97b84" in Thread "0x8a0". Fehlercode: 0xc0000005. Bei diesem Fehler könnte es sich um ein Problem in der CLR oder in den unsicheren oder nicht verifizierbaren Teilen des Benutzercodes handeln. Übliche Ursachen dieses Bugs sind Marshallerfehler für COM-Interop oder PInvoke, die den Stapel beschädigen können. Das ganze ist reproduzierbar, allerdings kommt die Fehlermeldung manchmal ab dem 4. mal, manchmal auch erst nach dem 5. bis 8. mal. Ich habe nicht besonders viel Ahnung von vb, und weiß zur Zeit nicht einmal wo ich anfangen soll zu suchen. Ich benutze die ftd2xx.dll. Würde mich über jeden Tipp freuen, Grüße Saxosun
:
Verschoben durch Moderator
> Würde mich über jeden Tipp freuen,
Der erste Tipp wäre mal das Programm anzuhängen, plus ne Beschreibung ob
du die .NET-DLL (also den Wrapper) oder die native DLL von FTDI
verwendest, etc.
Dann wissen wir wenigstens, was der IST-Zustand ist.
Ralf
Nachtrag: Was spricht dagegen auf die DLL zu verzichten und alles über den normalen COM-Port abzuwickeln? Alternativ nur den FTDI-COM-Port über die DLL holen und den Rest über normale COM-Port-Kommunikation abwickeln. Ralf
ich bin dabei das Programm soweit runter zu kürzen, dass es übersichtlich wird, werde es dann anhängen. Ich benutze die DLL von FTDI: C:\Windows\System32\FTD2XX.DLL grüße Saxosun
bitte verbessere mich, aber soweit ich weiß muss man den COM Port wenn man den FT232 über den VCP benutzt immer manuell einstellen, die Möglichkeit sich den COM Port über die DLL zu holen und dann über den VCP zu arbeiten kenne ich nicht, gibt es da Beispiele zu? Gibt es des öffteren Probleme mit der DLL, oder worauf beruht dein Vorschlag? Grüße Saxosun
Michael K. schrieb: > Gibt es des öffteren Probleme mit der DLL, oder worauf beruht dein > Vorschlag? Nein. Dein Problem liegt in .NET. Man kann den FTDI-Chip wiederfinden, wenn man sich die Finger dreckig macht und in der Windows-Registry Bezeichner für die vorhandenen COM-Anschlüsse ausliest.
...und Linux lässt grüßen. Benutze auch FTDI-Chips. Mit der freien Library, unter Debian. Funzt wunderbar.
> Gibt es des öffteren Probleme mit der DLL, oder worauf beruht dein > Vorschlag? Nein, aber da du keine näheren Infos zur Schaltung bzw. Software gepostet hast, hab ich die Antwort allgemein gehalten. Und "allgemein" bedeutet, dass in 99% der Fälle der FT232 einfach als UART verwendet wird. Ergo folgt, dass die SerialPort-Klasse aus .NET reichen würde und die DLL nicht nötig ist - es sein denn, der User möchte nicht zuerst alle vorhandenen COM-Ports abklappern ob sein Gerät dranhängt. Und in diesem Fall nimmt man die DLL, lässt sie nach FTDI-Chips suchen, holt sich die entsprechende COM-Port-Nummer und arbeitet ab da mit einem ganz normalen (virtuellen) UART. Vorteil ist, dass du wie gesagt nicht "abklappern" musst und nicht das gesamte Programm von der DLL "durchsetzt" ist, sondern hauptsächlich mit einem COM-Port arbeitet - das wiederum wird dann zum Vorteil, wenn du irgendwann mal einen USB-Microcontroller mit nem CDC-Treiber fütterst. Ralf
danke zunächst mal für die Vorschläge, ich bin noch dabei das Programm zu kürzen, vielleicht finde ich den Fehler auf diesem Weg, ansonsten lade ich es hier hoch. @ Ralf Mit deinem 99er Verdacht liegst du zu 99% richtig, ich benutze den FTDI als UART, FT_Status = FT_SetBaudRate(FT_Handle, 9600) FT_Status = FT_SetDataCharacteristics(FT_Handle, FT_DATA_BITS_8, FT_STOP_BITS_1, FT_PARITY_NONE) FT_Status = FT_SetFlowControl(FT_Handle, FT_FLOW_XON_XOFF, 17, 19) lediglich den DTR Out habe ich missbraucht, und den auf einen Input vom µC gelegt, um diesen in den Zustand "Connect" zu versetzen. Alles ist über Optokoppler getrennt, Übertargungsfehler hatte ich bisher keine. Grüße Saxosun
> ich bin noch dabei das Programm zu kürzen, vielleicht finde ich den Fehler > auf diesem Weg, ansonsten lade ich es hier hoch. Okay... > Mit deinem 99er Verdacht liegst du zu 99% richtig, ich benutze den FTDI > als UART,... Ich weiss :) > FT_Status = FT_SetBaudRate(FT_Handle, 9600) > FT_Status = FT_SetDataCharacteristics(FT_Handle, FT_DATA_BITS_8, > FT_STOP_BITS_1, FT_PARITY_NONE) > FT_Status = FT_SetFlowControl(FT_Handle, FT_FLOW_XON_XOFF, 17, 19) Zu wenig. Daraus lässt sich nur ableiten, welche Einstellungen der COM-Port hat. Ob du ihn richtig bedienst und ob du den Wrapper oder die native DLL verwendest sieht man daran nicht. Such wie oben angegeben den Fehler, und wenn du ihn nicht findest, dann den ganzen Sourcecode posten. > lediglich den DTR Out habe ich missbraucht, und den auf einen Input vom > µC gelegt, um diesen in den Zustand "Connect" zu versetzen. Alles ist > über Optokoppler getrennt, Übertargungsfehler hatte ich bisher keine. Daher die Notwendigkeit der DLL? Hm... Lässt sich evtl. auch anders lösen: Wenn du Hardware-Handshake aktivierst sollte die xTS-Leitung beim Öffnen des Ports kippen. Vielleicht hilft dir das weiter, du bräuchtest dann die DLL nicht. Ralf
Hallo,
ich habe das Programm zum laufen bekommen (ich hoffe es bleibt auch so)
"Merkwürdigerweise" befand sich das Problem in der Funktion:
FT_Status = FT_EE_ReadEx(FT_Handle, FT_EEPROM_DataBuffer,
TempManufacturer, TempManufacturerID, TempDescription, TempSerialNumber)
If FT_Status <> FT_OK Then
Exit Function
End If,
wenn ich das richtig interpretiert habe lag es an der Struktur:
Public FT_EEPROM_DataBuffer As FT_PROGRAM_DATA
Public Structure FT_PROGRAM_DATA
...
...
End Structure
ganz verstanden habe ich das Problem nicht, zumal ich mich streng an die
Beispiele von FTDI gehalten habe. Noch merkwürdiger finde ich, dass
dieser Programmteil nur 1x durchlaufen wurde, und der Laufzeitfehler
nach dem 4.- 10. mal Daten übertragen passierte, also an einer ganz
anderen Stelle des Programms. Vielleicht hat jemand noch eine Idee zu
diesem Phänomen.
@Ralf
deinen Vorschlag werde ich definitiv auch noch ausprobieren.
Danke für die konstruktiven Vorschläge.
Grüße
Saxosun
Moin Michael, > ganz verstanden habe ich das Problem nicht, zumal ich mich streng an die > Beispiele von FTDI gehalten habe. Dann müsstest du wie gesagt den fehlerbehafteten und auch den -bereinigten Code posten, vielleicht finden wir was. > deinen Vorschlag werde ich definitiv auch noch ausprobieren. Mit der xTS-Leitung? Aber schau dir vorher an, wie RTS/CTS etc. bei Hardware-Handshake zusammenspielen, sonst kippt dir die Leitung evtl. im laufenden Betrieb wieder weg. Ralf
Hallo, ich habe nun den Code weiter gekürzt und folgendes festgestellt: Das Beispiel von FTDI beinhaltet das Modul D2XX_Unit.vb. Beim ersten öffnen des Beispiels muss das Programm in meine vb .net 2010 Express Version konvertiert werden. Beim kürzen des Codes habe ich mir die benötigten Elemente aus dem Modul in meine Form kopiert, und dabei bekomme ich schon Fehlermeldungen bei der Funktion: FT_EE_ReadEx ..... Warum bekomme ich diese Fehlermeldungen nicht wenn die Funktion im Modul D2XX_Unit.vb bleibt ??, hängt das mit dem automatischem Konvertieren zusammen? Verzichte ich auf den Aufruf der Funktion läuft das Programm problemlos. Bestimmt ist es ein "blöder" Fehler, ich komme eigentlich aus der Elektronik Ecke, und habe mir alles über vb selbst zusammen gereimt..... viele Grüße Saxosun
> und dabei bekomme ich schon Fehlermeldungen bei der Funktion: > FT_EE_ReadEx ..... Und die Meldungen lauten wie? Nicht alles aus der Nase ziehen lassen :) > Warum bekomme ich diese Fehlermeldungen nicht wenn die Funktion im Modul > D2XX_Unit.vb bleibt ?? Weil dort vielleicht ein Verweis auf etwas drin, was in deinem Modul fehlt? Oder weil du ne Vorwärtsreferenz auf FT_PROGRAM_DATA hast, ich weiss leider nicht ob das in VB erlaubt ist (ich vermute aber schon). > hängt das mit dem automatischem Konvertieren zusammen? Glaube ich nicht, aber ohne konkrete Fehlermeldungen fehlt denke ich auch n brauchbarer Ansatzpunkt... > Verzichte ich auf den Aufruf der Funktion läuft das Programm problemlos. Ist es wirklich der Verzicht auf den Aufruf, oder der Verzicht auf's DECLARE, oder ist es nur ein falscher Parameter? > Bestimmt ist es ein "blöder" Fehler, ich komme eigentlich aus der > Elektronik Ecke, und habe mir alles über vb selbst zusammen gereimt.... Bin auch Elektroniker, bringe es mir auch selbst bei (in meinem Fall C#). Ralf
Hallo, hat etwas gedauert, aber nun: > Und die Meldungen lauten wie? Nicht alles aus der Nase ziehen lassen :) Es ist keine Quelle verfügbar. Es sind keine Symbole für Auruflistenrahmen geladen. Der Quellcode kann nicht angezeigt werden. Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist. Ich habe auch die Extensions für die Structure nochmal auf FT232R angepasst, aber leider erfolgt keine Veränderung. > Oder weil du ne Vorwärtsreferenz auf FT_PROGRAM_DATA hast, ich weiss > leider nicht ob das in VB erlaubt ist (ich vermute aber schon). Das funktioniert. > Ist es wirklich der Verzicht auf den Aufruf, oder der Verzicht auf's > DECLARE, oder ist es nur ein falscher Parameter? Es reicht wenn ich auf den Aufruf verzichte, die Declaration allein macht erstmal keinen Ärger. Leider finde ich im Netz kein Beispiel wie die Funktion mit vb .net richtig angewendet wird. Ich denke, dass an der Structure etwas nicht stimmt, oder die Argumente falsch sind. Ich weiß aber auch nicht, wie man prüfen kann, was die dll bei einem Funktionsaufruf erwartet. viele Grüße Saxosun
> Leider finde ich im Netz kein Beispiel wie die Funktion mit vb .net > richtig angewendet wird Auf der Herstellerseite solltest du VB-Beispiele finden. Ralf
Ralf schrieb: > Auf der Herstellerseite solltest du VB-Beispiele finden. na, dass wäre ja zu einfach ;-) Die Teile aus meinem Quellcode stammen aus den Beispielen von FTDI, aber leider nur mit dem oben beschriebenen "Erfolg" :-( Die Funktion FT_EE_ReadEX (Function Read_FT232_FT245_EEPROM() As Integer) und die zugehörige Struktur ist zwar in den Beispielen deklariert, wird aber nicht benutzt. Grüße Saxosun
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.