Nabend zusammen, ich bin derzeit einen neuen 3D-Drucker am bauen und habe dies zum Anlass genommen, um mal das Rumba-Board auszuprobieren. Link zum Wiki gibts hier: http://reprap.org/wiki/RUMBA Mein Board ist scheinbar eine neuere Version, dazu gibts leider noch keinen aktuellen Schaltplan, jedoch ist das Board zu 95% identisch. Nun habe ich folgendes Problem: Ich habe das Rumba-Board im Betrieb genommen und Marlin (Firmware auf Arduino Basis) aufgespielt. Lief bis dahin ohne Probleme. Seit gestern bekomme ich aber leider keine USB-Verbindung mehr hin. Windows (7/Vista/10) erkennt das Board nicht mehr. Interessanter Weise wurde auf dieses Problem bereits im Wiki hingewiesen und eine Problemlösung vorgestellt. Jedoch habe ich es nicht geschafft, das Board in den DFU-Modus zu bringen. Ich vermute, dass die vom Hersteller aufgespielte (neuere?!) Firmware für den Atmega16u2 den DFU-Modus nicht unterstützt hat. Ich habe daher ein wenig Google bemüht und raus gefunden, dass keiner dafür eine Lösung hat :(. Für den Atmega16u2 wird aber der ISP-Header rausgeführt, ich habe deshalb verschiedene Firmwares (Aus dem Wiki, von Arduino etc. ...) aufgespielt und geschaut ob es irgendwas ändert. Leider hat keine der Firmwares Windows dazu gebracht das Rumba-Board zu erkennen :(. Mein nächster Schritt war zu schauen ob der Atmega16u2 im Allgemeinen überhaupt noch funktioniert und nicht defekt ist, dazu habe ich ein einfaches Programm geschrieben, welches die RX/TX Leds im 1s-Takt toggelt. Funktioniert tadellos. Ich würde gerne im nächsten Schritt prüfen ob am Atmega16u2 der USB-Teil überhaupt funktionstüchtig ist. Dazu wollte ich eigentlich irgend ein garantiert funktionstüchtiges Programm aufspielen, welches Windoof dazu zwingt das Board zu erkennen bzw. um den USB-Teil zu testen. Leider finde ich dazu nichts passendes. Die LUFA (http://www.fourwalledcubicle.com/LUFA.php) Beispiele bekomme ich leider nicht zum laufen. Ich wollte daher fragen, ob jemand ein .hex-File zur Verfügung stellen kann, welche ich testweise via ISP auf den Atmega16u2 aufspielen kann. Falls jemand noch andere Ideen hat, immer her damit. Inzwischen würde ich alles ausprobieren. Gruß, Rumba Reparierer
Angehängte Dateien:
-
RRD-RUMBA_SCHEMATICS.png
980 KB
Rumba Reparierer schrieb: > Windows > (7/Vista/10) erkennt das Board nicht mehr. Wenn beim Anstecken des Gerätes gar nix passiert, ist USB D+ nicht verbunden oder wird nicht mit 1,5K nach 3V3 gezogen. Ansonsten: Fehlercode angeben...
Jim M. schrieb: > Wenn beim Anstecken des Gerätes gar nix passiert, ist USB D+ nicht > verbunden oder wird nicht mit 1,5K nach 3V3 gezogen. Laut Schaltplan ist kein 1.5K vorhanden ... Ich habe die Verbindung durchgepiepst, scheint alles okay zu sein. > Ansonsten: Fehlercode angeben... Soweit kommt es nicht, Windows erkennt nichts.
USB Shield würde ich nicht mit der Masse Verbinden. Hast Du den Bootloader überschrieben? Hier findest Du passenden Bootloader: http://re.reworld.eu/en/products/u2dil/index_bl.htm
Bülent C. schrieb: > Z1 und Z2 haben da nichts zu suchen. Bülent C. schrieb: > USB Shield würde ich nicht mit der Masse Verbinden. > Hast Du den Bootloader überschrieben? Das Shield scheint nicht mit Masse verbunden zu sein, die USB-Buchse hat 5 Kontakte, einer davon ist nicht gelötet. Ja nachdem ich den Atmega16u2 nicht in den DFU-Modus bringen konnte habe ich die Firmware (http://reprap.org/wiki/RUMBA#16U2_LUFA.2FArduino_based_USB2Serial_Firmware) direkt via ISP auf den µC geschrieben. Ich vermute inzwischen, dass diese Firmware in einem anderen Bereich im Speicher muss, da ich ja den DFU-Modus nicht benutzt habe?! > Hier findest Du passenden Bootloader: > http://re.reworld.eu/en/products/u2dil/index_bl.htm Sind die Firmwares zum Atmega16u2 kompatibel? Die auf der Seite angebotenen sind für einen Atmega32u2. Immerhin scheint es auf der Seite etwas zum Testen des USB-Ports zu geben, werde ich direkt mal ausprobieren. Danke auf jeden Fall! Ich werde mich zurück melden.
Rumba Reparierer schrieb: > Danke auf jeden Fall! Ich werde mich zurück melden. So habe die Firmware für den AT90USB162 aufgespielt und die High Fuses wie empfohlen auf 0xD9 gesetzt. Leider tut sich im Windoof immer noch nichts :( Was ich bis jetzt immer noch nicht verstehe ist: Wie kann das sein, dass die Firmware auf einmal nicht mehr funktionieren kann. Die Bits leiern doch nicht aus oder wird da irgendwas in den Eeprom geschrieben?! Bei meiner Recherche habe ich auch oft gelesen, dass dieses Problem bei einigen Arduino-Boards bekannt ist. (Dort kann man die Boards in der Regel noch per DFU erreichen.)
Bülent C. schrieb: > Z1 und Z2 haben da nichts zu suchen. Alter du bist zu geil! Ich habe nun die Induktivität L1 auf einer Seite angehoben, sodass Z1 und Z2 wirkungslos sind. Siehe da der Atmega16u2 wird auf jeden Fall wieder vom Windows erkannt :) :) :) Jetzt kommt im Gerätemanager nur noch "Unbekanntes USB-Gerät (Fehler beim Anfordern einer Gerätebeschreibung.)". Ich denke das Problem bekomme ich auch noch gelöst. Kann evtl. noch jemand erklären, warum die beiden Varistoren den USB-Betrieb verhindern? Ich würde die Lösung gerne verbreiten und das Problem mit den Varistoren erläutern. Vielen dank auf jeden Fall!!!
Kommando nochmal zurück, in meiner Freude habe ich nicht weiter getestet ... Sobald ich das Board an den USB-Anschluss meiner Tastatur stecke, blinkt die Power LED 5mal und das Board wird im Windows als Unbekannt erkannt. Nutze ich einen anderen USB-Anschluss tut sich wieder nichts. Sobald ich die USB Spannung auf dem Board messe, fällt mir auf das diese nur ~1.5V beträgt. Stecke ich jedoch die einzelnen USB-Leiter auf den extra vorgesehene Stiftleiste (Sitzt direkt hinter der USB-Buchse) ist die Spannung komplett da, aber das Board wird ebenfalls nicht erkannt. Auch nicht unter dem USB-Anschluss der Tastatur.
So ein kleines Update: Habe bis jetzt rum geforscht und nochmals einiges versucht. Ich habe rausgefunden, dass das der Atmega16u2 des Rumba-Boards die gleiche Beschaltung wie ein Arduino Uno Rev3 hat (Schaltplan im Anhang). Ich hatte ebenfalls noch einen Mega2560-Clon rumliegen gehabt, welcher genau diese Schaltung des Atmega16u2 nutzt. Bei diesem kann ich sofort den DFU-Modus starten und z.B. via Atmel Flip den Chip neu flashen. Anschließend habe ich via ISP den Flash ausgelesen und das .hex-File in meinen nicht funktionierenden Atmega16u2 des Rumba-Boards geflasht. Leider keine Änderung. Ich habe langsam die starke Vermutung das der Chip den Geist aufgegeben hat. Bzw. der USB-Teil des Chips. Hat da jemand noch eine Idee? Sonst würde ich einfach mal die Chips auslöten und tauschen, wobei das bei TQFP32 richtig lustig wird. Immerhin kann ich mit einem CP2102-Breakoutboard den Mega2560 noch direkt beschreiben, aber ich möchte ungerne das Breakoutboard da rumhängen haben :/
So letztes Update: Hatte die beiden Atmega16u2 ausgelötet und getauscht. Das Rumba-Board hat gleiche Probleme wie vorher gezeigt. Das Mega2560 lief tadellos... Ich vermute, dass die Beschaltung auf der Platine fehlerhaft ist, nur leider ohne korrekten Schaltplan der aktuellen Variante kann man den Fehler nicht finden :( Naja ich habe nun das Problem anders gelöst, alte Atmega16u2 Schaltung komplett runtergelötet und auf die Rückseite ein CP2102 Breakoutboard angebaut und mit dem Rumba-Board verlötet. Board lässt sich tadellos mittels Arduino programmieren und auch per Repetier-Host ansteuern.
Hallo ich habe scheinbar an meinem Rumba board den usb eingang zerschossen,würde gerne die verdrahtung wissen um ein CP2102 für die übertragung der firmware ein zu binden gruss sven
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.