Ich habe mal wieder ein Problem: Controller: STM32F108C8 Den Testaufbau kann ich flashen mit einem ST-Link /V2 (original und China Clone) Jetzt möchte ich den Chip mittels Bootloader flashen: USB2RS232 Adapter, Chip = FTDI - funktioniert mit Windows ST Demonstrator Loader - funktioniert mit Linux stm32flash USB2RS232 Adapter, Chip = CH340G - funktioniert mit Windows ST Demostrator Loader und (wurgs): - mit Linux nicht !!!! Im Netz finde ich ein paar wenige Aussagen, dass das am Linux-Kernel Treiber liegen soll ! Verwende ich den CH340 Adapter an einem LPC1114 und dem Programm lpc21isp, so lässt sich der LPC auch ueber den CH340 Adapter und Bootloader flashen. Die Kombination CH340G und STM32 will jedoch einfach nicht. Jetzt habe ich mir den Quellcode von stm32flash angesehen um vielleicht dahinter zu kommen, wo ich (ohne Linux-Kernel) eventuell ansetzen kann, aber ich komme leider nicht dahinter ! Hat das hier eventuell schon einmal jemand ans laufen gebracht ? : - ) eine Aussage in der Art: dann verwende den FTDI Chip nutzt mir relativ wenig, weil ich für die "Entwicklung" eh den ST-Link verwende. Ein STM32 Programm kann natürlich ueber den CH340 eine serielle Verbindung aus einem Programm heraus zu Linux aufbauen so dass ich Ausgaben die ein STM32 auf der seriellen Schnittstelle macht über diesen Adapter auf einem Linux Terminal sehe. Wie gesagt, hat das schon jemand ans Laufen gebracht und evtl. den Originalcode des stm32flash gefixt (vllt. ist auch eine stty - Einstellung die Lösung ??? )
PS: Fehlermeldung von stm32flash ist fuer Device-Information lesen ist: Interface serial_posix: 57600 8E1 Failed to read ACK byte Unexpected reply from device on command 0x01
Als erstes könntest Du mal die Systemaufrufe des stm32flash bei Verwendung des FTDIs und des CH340 mit strace vergleichen und schauen an welcher Stelle da die ersten Unterschiede entstehen. Dann würde ich mir die Übertragung zwischen Adapter und µC mit dem Logic Analyzer anschauen und auch dort FTDI und CH340 vergleichen. Dann weißt Du genauer wo das Problem herkommt und kannst Dir überlegen wie Du das angehst.
Gast
#4684291
Ralph S. schrieb: > wo ich (ohne Linux-Kernel) eventuell ansetzen kann, Moin, da es ein bekanntes Treiberproblem mit der Parität ist, kann es auch nur durch den Treiber gelöst werden. Solange es in deinem Kernel nicht korrigiert ist: http://www.wch.c*n/download/CH341SER_LINUX_ZIP.html * bitte entfernen. In das entpackte Verzeichnis wechseln, dann # sudo make und #sudo make load sollte das Problem lösen.
... vielen Dank für den Link, hat aber leider nicht funktioniert !
Gast
#4684386
Ralph S. schrieb: > hat aber leider nicht funktioniert Was hat nicht funktioniert? Hast Du den alten Treiber vorher entladen?
Gast
#4684471
https://github.com/fraopess/CH341_driver_parity_patch hier noch eine andere Version. In der README steht wie es geht.
Ralph S. schrieb: > USB2RS232 Adapter, Chip = CH340G > > - funktioniert mit Windows ST Demostrator Loader > > und (wurgs): > > - mit Linux nicht !!!! > > Im Netz finde ich ein paar wenige Aussagen, dass das am Linux-Kernel > Treiber liegen soll ! > > Verwende ich den CH340 Adapter an einem LPC1114 und dem Programm > lpc21isp, so lässt sich der LPC auch ueber den CH340 Adapter und > Bootloader flashen. Scheinbar benötigt der LPC keine Parity-Bits für das Protokoll, siehe unten. > Die Kombination CH340G und STM32 will jedoch einfach nicht. > > Jetzt habe ich mir den Quellcode von stm32flash angesehen um vielleicht > dahinter zu kommen, wo ich (ohne Linux-Kernel) eventuell ansetzen kann, > aber ich komme leider nicht dahinter ! Es liegt tatsächlich am CH340 Treiber, da der keine Parity-Bits unterstützt. > Hat das hier eventuell schon einmal jemand ans laufen gebracht ? Ja, hatte selber vor ein paar Tagen das gleiche Problem. Im folgenden die Anleitung wie man den Open-Source Treiber für den CH340 unter *buntu 14.04 patcht:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Fertig :)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.