Hallo ich hab folgendes Problem: Ich verwendete die RTS und DTR Leitung vom FT232R, um einen MSP430 in den Bootloader-Modus zu versetzen. Dazu ist DTR am RESET und RTS am TCK von JTAG Port angeschlossen. Funktioniert auch soweit perfekt. Das Problem ist nur, dass der USB-Chip beim Power-Up/Initialisierung die beiden Leitungen toggelt, dadurch wird beim anstecken von USB immer mehrere RESETs ausgelöst. Weiß jemand ob es möglich ist die DTR/RTS Leitung beim Power-Up vom FT232 nicht toggeln zu lassen?
Hast Du die die verschiedenen EEPROM-programmierbaren Pull-Up Optionen durchdacht? Fehlt evt ein externer Pull-Up?
Bei der Programmierung kann ich nichts einstellen und der FT232 toggelt mehrmals definitiv die beiden Leitungen beim Anstecken. Ich hab gedacht, dass man das irgendwie abstellen kann....
Ich hatte das gleiche Problem. Hab dann einen Bootloader-Jumper zwischen RST und DTR gemacht. Damit war die Sache gegessen.
Das Datenblatt sagt zu den Pins der "UART Interface and CBUS Greoup: ** When used in Input Mode, these pins are pulled to VCCIO via internal 200kΩ resistors. These pins can be programmed to gently pull low during USB suspend ( PWREN# = “1” ) by setting an option in the internal EEPROM. Bist Du sicher, dass der Treiber keinen Unsinn macht? Toggeln die Pins auch, wenn du den FT232R nur an einen spannungsversorgten Hub ohne angeschlossenes USB betreibst?
Ja es liegt am Treiber. Weil wenn ich den FT232 zum ersten Mal mitn PC verbinde (also in dem Fall, wenn der Treiber noch nicht geladen ist) dann toggelt er die PINs nicht. Wurde aber einmal das Gerät erkannt und ein COM-Port zugewiesen, dann toggelt der Vogel die PINs bei jedem Anstecken. Ich benutz die VCP Treiber.
@Chris Blöd nur, dass die Platine in ein Gehäuse vergossen wird und nur noch der Mini-USB bzw. DC-Buchse rausguckt!
> Wurde aber einmal das Gerät erkannt und ein COM-Port zugewiesen, dann > toggelt der Vogel die PINs bei jedem Anstecken. Ich benutz die VCP > Treiber. Das könnte möglichweise an was ganz anderem liegen - Windows' Plug&Play-Erkennung untersucht serielle Anschlüsse auf angeschlossene Plug&Play-Hardware wie serielle Modems etc. - das Geklapper auf den Handshakeleitungen dürfte darauf zurückzuführen sein. Möglicherweise lässt sich das Verhalten mit einem Registry-Eintrag beeinflussen. Auf http://www.microsoft.com/whdc/system/CEC/serddvr.mspx wird ein solcher namens SkipEnumerations beschrieben: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\%Enumerator%\%Device_ID % \%Instance_ID%\Device Parameters\SkipEnumerations The use of SkipEnumerations in the Device Parameters key must be used on a per-port basis. There is no global option to change the behavior of all ports at once. The REG_DWORD value name, SkipEnumerations, can contain the following data: • Zero or non-existent: Default Serenum behavior; each port will be scanned during every system boot. For example: SkipEnumerations\REG_DWORD\0x00000000 (0) • 0xffffffff: Serenum will never scan the ports, either automatically or through user-initiated scans in Device Manager or Hardware Wizard. Any device attached to a port with this value in the registry will need to be installed manually. For example: SkipEnumerations\REG_DWORD\0xffffffff (4294967295) • If any other value is used, Serenum will skip that number of scans (boots or user-initiated). The successive scan will behave normally (similar to the setting of zero). Once the value goes to zero, it will stay at zero until Serenum.sys is unloaded and reloaded. At this point, it will be reset to the original registry value. For example: SkipEnumerations\REG_DWORD\0x00000003 (3) In this example, the data value is set to 3. Serenum will skip 3 scans. After the 3 scans, it will perform a normal scan. Also erscheint es mir untersuchenswert, diesen Parameter auf -1 zu setzen.
Notfalls kannst du ja auch das Programm auf dem MSP430 so abändern, dass es beim Starten den RST erst mal deaktiviert. Per Kommando (ich nehme mal an, man kann mit dem MSP430 irgendwie kommunizieren) schaltet man dann den RST wieder frei, oder springt gleich zum Bootloader. So wirds z.B. im TI-USB Debugger gemacht. Irgendwo in der SLAA096 oder 089 steht ja aber eigentlich dass Windows gerne auf den HS-Leitungen klappert, und man muss das in der MSP430 Software berücksichtigen ;)
Vielen Dank Leute. Rufus genau des wars. Hab dann herausgefunden, dass der FTDI-Treiber die Option bietet, die Enumeration nicht zu machen: Und zwar im Geräte-Manager -> COMx -> Port Settings -> Advanced -> Serial Enumaration deaktivieren.
Stefan wrote: > Vielen Dank Leute. Rufus genau des wars. > > Hab dann herausgefunden, dass der FTDI-Treiber die Option bietet, die > Enumeration nicht zu machen: > > Und zwar im Geräte-Manager -> COMx -> Port Settings -> Advanced -> > Serial Enumaration deaktivieren. Hi, genau das selbe Problem habe ich hier auch. Es hat bei mir aber nicht sehr viel gebracht die Serial Enumeration zu deaktivieren. DTR und RTS toggeln immer noch nach einstecken des USB-Kabels. Allerdings nur noch halb so lange wie wenn die Serial Enumeration aktiviert ist.
Hallo zusammen, ein altes Thema. Habe aber das selbe Problem. Mein kleines Gerät wird über PC USB betrieben. Verbaut ist ein STM32F103, sowie ein FTDI FT231X. Der FTDI hängt mit der RTS und DTR Leitung direkt an RESET und Boot0 des µCs. Mit dem Tool von ST kann ich den Bootloader anspringen und programmieren. Problem, weil die beiden Leitungen vom FTDI am Anfang wild toggeln, startet der µC nicht. Gibt es eine Möglichkeit dieses Toggeln am Anfang zu unterbinden, damit der µC auch sicher startet, wenn man nicht updaten will? Gerät ist in einem Gehäuse. Also mit Jumper ändern oder so, wäre ungünstig, genauso wird das Gerät an mehreren PC verwendet. Eine Änderung des Treibers macht bei mir also genauso wenig Sinn. Für Ratschläge wäre ich dankbar. Schöne Grüße Alex
Alex schrieb: > > Gibt es eine Möglichkeit dieses Toggeln am Anfang zu unterbinden, damit > der µC auch sicher startet, wenn man nicht updaten will? Diese bereits beschrieben: > Und zwar im Geräte-Manager -> COMx -> Port Settings -> Advanced -> > Serial Enumaration deaktivieren. > einem Gehäuse. Also mit Jumper ändern oder so, wäre ungünstig, genauso > wird das Gerät an mehreren PC verwendet. Eine Änderung des Treibers > macht bei mir also genauso wenig Sinn. > Wenn Du das dort nicht einstellen willst/möchtest, und auch dne "Bootloader-Jumper" nicht extern plazierst, dann gibt es wohl keine weitere Lösung.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.