Hallo, ich habe einen STM32F070 und folgendes Problem USB-midi zum Laufen zu bringen: Solange ST-link verbunden ist und ich debugge, läuft alles wunderbar, Sowohl midi in, als auch output funktionieren problemlos. Ich kann das USB Kabel ab- und wieder anstecken, oder einen Software Reset machen: USB läuft und ich kann midi Daten empfangen und Senden. Sobald ich jedoch den ST-Link disconnecte (nicht physikalisch, sondern nur den Debugger beende) funktioniert das ganze nicht mehr so gut. zunächst läuft noch alles, ab- und anstecken des USB Kabels führt nun jedoch entweder dazu, dass das Gerät a)nicht b)fehlerhaft oder c)zwar erkannt wird, jedoch nur midi daten empfangen, aber nicht senden kann. Da es hier mit debuggen schwer wird, weiß ich leider nicht einmal wo ich anfangen soll. Freue mich über irgendwelche Ansätze. Es läuft ein USB-Midi stack basierend auf der CubeHAL library. Vielen Dank
Geht es um ein Programm, dass du selbst geschrieben hast? Wenn nicht, hast du wenigstens den Quelltext vorliegen? Hast du einen seriellen Ausgang-Pin frei? Besitzt du einen USB-UART Adapter? Bist du sicher, daß die Stromversorgung in Ordnung ist? Nur vermutet, oder nachgemessen? Wenn ja, wo hast du was gemessen? Beschreibe die Fehler a) und b) detaillierter.
Hallo, danke zunächst mal für die Anregungen. Wie man generell ohne Debugger debuggen kann ist mir klar, mir fehlt es jedoch an Verständnis von USB an sich um zu wissen, wo ich ansetzten könnte. a) Das Gerät wird als 'unbekanntes Audiogerät' erkannt b) Das Gerät kann nicht gestartet werden. (Code 10) Stromversorgung erfolgt nicht über USB und ist stabil
Sind da Debugausgaben über den ST-Link drin? Je nach dem wie man die realisiert blockieren die wenn kein Debugger da ist.
Johannes S. schrieb: > Sind da Debugausgaben über den ST-Link drin? Je nach dem wie man > die > realisiert blockieren die wenn kein Debugger da ist. Soweit ich weiß nicht. Das Problem tritt jedenfalls auch in der Release version genauso auf.
Die Debugausgaben die ohne Debugger blockieren sind die über 'semihosting'. Dazu wäre sowas wie specs=redimon.specs oder eine Semihosting Option in den linker settings zu sehen. Das könnte man auch in einer Release Version aktivieren, wäre aber natürlich wenig sinnvoll.
Könnte es vielleicht sein, dass es beim Verbinden durch den Debugger zu einem kleinen Delay kommt, welches sich positiv auswirkt?
Johannes S. schrieb: > Die Debugausgaben die ohne Debugger blockieren sind die über > 'semihosting'. Dazu wäre sowas wie specs=redimon.specs oder eine > Semihosting Option in den linker settings zu sehen. Das könnte man auch > in einer Release Version aktivieren, wäre aber natürlich wenig sinnvoll. Gerade nachgesehen. Semihosting ist sowohl in der Debug als auch in der Release version deaktiviert. Danke für den Einfall
Läuft Dein STM32 überhaupt los "ohne Debugger"? Wenn der Debugger nur USB-seitig, nicht aber am Target abgezogen wird, kann er die MCU im Reset-Zustand halten.
Walter T. schrieb: > Läuft Dein STM32 überhaupt los "ohne Debugger"? > > Wenn der Debugger nur USB-seitig, nicht aber am Target abgezogen wird, > kann er die MCU im Reset-Zustand halten. Ja, er läuft, restliches Programm und Peripherie läuft auch. Sogar USB funktioniert ja manchmal, nur dann nur in eine Richtung.
Welche Geräte-ID zeigt Windows an, wenn es nicht richtig erkannt wird? Welche Kernel Meldungen (dmesg) gibt Linux in diesen Fällen aus? Welche Hardware verwendest du (Schaltplan)?
Ich sitze hier die ganze Zeit am Testen und versuche ein nachvollziehbares Muster zu finden. Folgendes interessantes Verhalten konnte ich feststellen: 1) ich ziehe alles ab (USB, ST-LInk, Stromversorgung) 2) Schließe nun die Strombversorgung, dann USB an. Gerät wird manchmal erkannt, manchmal nicht, aber im Besten Fall kann ich nur Midi empfangen, nicht senden. 3) Schließe ich nun den ST-Link an, ändert sich nichts an diesem Verhalten 4) Wenn ich nun mit dem ST-Link Utility ein 'connect' und 'disconnect' mache, läuft USB Perfekt. Ein Software Reset scheint also den Fehler zu beheben.. hmm
Stefan U. schrieb: > Welche Geräte-ID zeigt Windows an, wenn es nicht richtig erkannt > wird? > Welche Kernel Meldungen (dmesg) gibt Linux in diesen Fällen aus? > Welche Hardware verwendest du (Schaltplan)? Geräte-IDs sind in jedem Fall die selben (korrekten) Werte. Linux müsste ich testen Hardware: Gibt es nicht viel zu sagen. USB_P und USB_N sind direkt mit der Buchse verbunden. Im Signalweg liegt nur ein USB-Zertifizierter ESD Schutzbaustein
Habe mir einen USB Paket Analyser heruntergeladen. Auch hier kann man sehen, dass im einen Fall (nach einem Software-Reset durch ST-Link) die Midi Pakete empfangen und gesendet werden. Ohne Debugger und nach einem erneuten Verbinden werden diese aber nur noch gesendet, nicht empfangen. sonst scheint es aber keinen Unterschied zu geben
ben schrieb: > Midi Pakete empfangen und gesendet werden. > Ohne Debugger und nach einem erneuten Verbinden werden diese aber nur > noch gesendet, nicht empfangen. Sind das Bulk- oder Isochrone Transaktionen? Bei Isochronen Transaktionen kommt IIRC kein ACK vom Geräte, d.h. er würde eine hängende CPU nichtmal mitbekommen. Bei dieser Art Bug braucht man LEDs oder andere Anzeigemöglichkeiten am Gerät, da man Fehler nicht so einfach mit dem Debugger finden kann. Ich habe z.B. im Hardfault_Handler() einen Blink Code drin. Hirnschmalz ist ebenfalls hilfreich. Mitunter beendet ein "make clean" solcherlei Spuk.
Ich rate Dir, Rückfragen umfangreich zu beantworten. Sie dienen dazu, Dir zu helfen, klare Gedanken zu fassen. Die Information, dass du seit Stunden herum fummelst, nützt jedoch gar nichts. Ich kann Dir weiter helfen, wenn du meine Fragen umfangreich beantwortest. Bisher hast du fast nur um den heissen Brei herum geschrieben und bist den Fragen ausgewichen. Die Antworten auf meine Fragen erfordern Tests, Zeichnungen und Messungen. Diese sollst du durchführen. Ohne Fleiss kannst du deine Situation gerne weiter bejammern, aber das nützt nichts. Du verschwendest deine und meine Zeit. Ich gebe Dir die nächste hilfreichr Antwort erst, wenn du alle meine Fragen ordentlich beantwortest hast. Ich denke, diesen Druck brauchst du.
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.