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
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.
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.
