SAMD21 / USB MSD / Verbindung mit PC erkennen

[Oliver R. (oli1982)]

Hallo zusammen

Ich habe eine Applikation mit einem ATSAMD21G18 als GPS Datenlogger. Die 
Dateien werden mittels FatFS auf einer SD Karte gespeichert. Der uC kann 
auch als USB Mass Storage Device gebraucht werden, womit ich die Daten 
direkt auf den PC kopieren kann. Nun ist es aber so dass ich möchte dass 
die beiden Modi (Logger / MSD) nicht gleichzeitig laufen, dafür müsste 
ich erkennen ob der uC eine Verbindung mit dem PC hat. Pseudo Code:

while(1)
{
    if (PCUSBConnection)
    {
        HandleUSB();
    }
    else
    {
        logData();
    }
}

VBus kann nicht brauchen, da der Logger Akku-Betrieben ist und beim 
Aufladen an einem USB Charger oder Power Bank keine USB Verbindung 
erkennen soll. Es gibt die Callback Funktionen UDI_MSC_ENABLE_EXT und 
UDI_MSC_DISABLE_EXT welche für solche Zwecke sein sollten, leider wird 
die Disable Funktion auch schon beim Einstecken aufgerufen weil 
irgendwann ein USB Bus Reset passiert welcher diese Funktion triggert.

Vielleicht kennt sich ja jemand mit diesem uC und ASF aus und kann mir 
helfen und mir sagen ob es irgendwo noch ein verstecktes Statusbit oder 
etwas anderes gibt was mir weiterhelfen könnte.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

ASF habe ich nicht benutzt, war mir zu grässlich.  Habe für die Firma 
mal selbst einen mass-storage class driver geschrieben, zwar für SAM4 
und nicht SAMD, aber aus USB-Sicht ist das an dieser Stelle egal, die 
Hardware wird ja an anderen Stellen abstrahiert.

Anfangs hatten wir das Device einfach read-only deklariert, damit nur 
die Firmware was am Dateisystem ändern kann und der Host nicht.  Später 
haben wir aber auch noch read/write eingebaut, damit man vom Host aus 
neue Dateien auf die SD-Karte im Gerät übertragen konnte (insbesondere 
ein neues Firmware-Image, welches der Bootloader dann nutzen kann).

So grob: die Enumeration durch den Host bekommst du in der USB-Firmware 
immer mit, da kannst du ein Flag setzen.  Erst danach kann der Host ja 
zugreifen.  Ein Gegenstück dazu gibt es nicht so recht, aber vielleicht 
helfen dir an dieser Stelle die Interrupts, die du schon gefunden hast.

Bei mass storage bekommst du ja außerdem die diversen SCSI-Kommandos zur 
Verarbeitung vorgelegt.  Da kannst du sicher auch was damit machen, so 
nach dem Prinzip "READ CAPACITY kommt auf jeden Fall am Anfang, ab da 
hat der Host das Sagen", "SYNCHRONIZE CACHE kommt beim Aushängen". UNIT 
ATTENTION ist eine nette Methode, um den Host ggf. zu zwingen, seinen 
derzeitigen Status zu verwerfen und neu anzufangen (falls bspw. der Host 
einen Zugriff versucht, obwohl die Firmware gerade gar nicht der Meinung 
ist, dass er aktiv wäre).  Wenn du das Gerät als Wechseldatenträger 
deklarierst, ist es ja jederzeit legitim, eine UNIT ATTENTION mit 
"Medium may have changed" zu werfen.  Wir benutzen diese Variante, wenn 
die Firmware von read/only auf read/write umschaltet.

Sorry, unsere Firmware ist closed-source, wir müssen damit Geld 
verdienen. Fragen kann ich aber gern beantworten.

[Oliver R. (oli1982)]

Hallo Jörg

Vielen Dank für deine Antwort. ASF müsste von mir aus auch nicht sein, 
aber wenigstens die Anbindung von FatFS mittels SPI an die SdCard hat 
problemlos geklappt und ich scheute den Aufwand dies von Hand zu tun.

Die Erkennung des Verbindungsaufbaus zum PC klappt mittels der Callback 
Funktion eigentlich gut, problematisch ist mehr das beenden. Aber da es 
absolut zeitunkritisch ist kann ich vielleicht etwas pollen oder eine 
deiner vorgeschlagenen Varianten versuchen. Ich werde mich da mal 
einlesen.

Viele Grüsse
Olive

[Jörg W. (dl8dtl) (Moderator)]

Den SD/MMC-Treiber haben wir auch als Atmel-Code übernommen, FatFS ist 
sowieso die übliche Version von ElmChan.

[Oliver R. (oli1982)]

Ich gebs auf und mach es wohl mit einem mechanischen Schalter. Ich habe 
keine Möglichkeit gefunden wie ich erkennen könnte ob der PC noch 
angesteckt ist. Ich habe etliche Statusregister (FSMSTATE, EPSTATUS der 
Endpoints, ...) angeschaut und das Problem ist einen Zustand zu finden 
der nicht dazwischen (bei einem USB Bus Reset) auch vorkommt. Ich habe 
noch nichts gefunden dass sich irgendwo zwischen einem echten Abstecken 
und dem Bus Reset unterscheiden würde.

[Jörg W. (dl8dtl) (Moderator)]

Oliver R. schrieb:
> Ich habe etliche Statusregister (FSMSTATE, EPSTATUS der Endpoints, ...)
> angeschaut und alle das Problem ist einen Zustand zu finden der nicht
> dazwischen (bei einem USB Bus Reset) auch vorkommt.

Daher schrieb ich ja, dass du das besser auf höheren Protokollebenen und 
nicht auf der Hardwareebene lösen solltest.

Irgendwo in deinem Code (der von ASF reingezogen worden ist) muss die 
Behandlung all der SCSI-Kommandos drin sein, dort kannst du ansetzen.

Habe gerade mal das MSC-Beispielprojekt zusammenfädeln lassen.  Ist eine 
ältere Version von Atmel Studio 7, aber das wird keine große Rolle 
spielen. Das, was ich meine, findest du in der Funktion 
udi_msc_cbw_received() in 
src/ASF/common/services/usb/class/msc/device/udi_msc.c.  Versuch doch 
einfach mal, ob du dort ansetzen kannst.  PREVENT ALLOW MEDIUM REMOVAL 
oder START STOP UNIT sehe ich auch noch als mögliche Ansatzpunkte.

Falls du irgendeine Kommunikationsschnittstelle dran hast (UART oder 
so), kannst du ja mal Ausschriften machen lassen, durch welche der 
genannten Methoden du so durchflitzt, wenn der Host darauf zugreift bzw. 
das Gerät wieder loslässt.

[Oliver R. (oli1982)]

Vielen Dank, jetzt weiss ich was du meinst. Ich habe mir gleich die SCSI 
Kommandos ausgeben lassen und so wie es aussieht kommen 
SBC_START_STOP_UNIT und SPC_PREVENT_ALLOW_MEDIUM_REMOVAL tatsächlich nur 
wenn ich am PC das Device entferne. Damit kann ich etwas anfangen! 
Einfach ausstecken geht damit zwar immer noch nicht, aber damit kann ich 
leben, sollte man ja wohl sowieso nicht tun :-)

[Jörg W. (dl8dtl) (Moderator)]

Oliver R. schrieb:
> Einfach ausstecken geht damit zwar immer noch nicht, aber damit kann ich
> leben, sollte man ja wohl sowieso nicht tun :-)

Erstens das, zweitens kannst du den Fall ja vielleicht tatsächlich über 
die Hardware-Events abfangen.