Atmels USBKey läuft nicht mit Atmels HID-Demo!

[Josef P. (ngc1232)]

Hallo Froum,

Nachdem ich mein neues Spielzeug, einen AVR USBKey (siehe 
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879) nun seit 
einigen Tagen in der Mache habe, bin ich etwas frustriert…
Ich habe ein Problem mit den HID Demos des USBKey und bin etwas ratlos, 
wie ich weiter machen soll.
Etwas konkreter: Ich habe von Atmel at90usb128-demo-hidgen-std herunter 
geladen und die SW läuft nicht…
Noch konkreter: Ich habe hid_gen.a90 mit Hilfe von Flip auf den USBKey 
geladen und UsbHidDemoCode.exe gestartet. Es gab zwar eine Verbindung 
zum USBKey, aber weder wurden beim Bewegen des Joysticks Daten empfangen 
noch konnte ich die LEDs ein bzw. ausschalten.
Als nächstes habe ich ein S65-Display an den USBKey angeschlossen (siehe 
http://www.superkranz.de/christian/S65_Display/DisplayIndex.html) und 
etwas Debug Code zu den at90usb128-demo-hidgen-std Sourcen hinzugefügt. 
Das Display arbeitet wunderbar und so bin ich letztlich drauf gekommen, 
dass die LEDs des USBKey nicht angehen, weil die Zeile 
if(Is_usb_receive_out()) in der Function void hid_task(void) nie true 
liefert.
Der nächste Schritt war, UsbHidDemoCode.exe mit VC++ zu debuggen. Das 
Ergebnis: Immer, wenn ich versuche, die LEDs mit der Applikation zu 
schalten, erzeugt AtUsbHID.dll folgende Trace-Ausgabe: Write failed but 
no IO pending, Error code is 1784

Als nächstes habe ich versucht, mit USBSpy 
(http://www.everstrike.com/usb-monitor/) der Sache auf den Grund zu 
gehen. Das Ergebnis: Der USBKey sendet beim Bewegen des Joystick 
korrekte Daten, sie kommen nur irgendwie nicht im aufrufenden Programm 
an. Ich habe versuchsweise mal die 8 Bytes, die den Joystick-Status 
zurück liefern, durch einen konstanten String ersetzt und konnte diesen 
String in USBSpy als Transfer-Paket empfangen.

Das letzte, was ich probiert habe, ist die Atmel AtUsbHID.dll durch SW 
zu ersetzen, die mir als Source vorlag (siehe 
http://www.lvr.com/hidpage.htm (http://www.lvr.com/files/HidTest.zip).
Das Ergebnis: wenn ich mittels WrieFile versuche, an den USBKey daten zu 
schicken, quittiert mir Windows das mit Error 1784 (0x06F8, “The 
supplied user buffer is not valid for the requested operation.”)

BTW: Der USBKey funktioniert wunderbar, wenn ich das Firmware-Original 
(FIRMWARE.HEX) flashe, bis auf eine Ausnahme: atmel_hid.exe (die blaue 
Hid-Demo) hängt. Ich kann aber irgendwie nicht glauben, dass die Hardwae 
defekt ist. Der „Memory-Stick-Modus“ und der „Maus-Modus“ der 
Original-Firmware funktionieren ganz wunderbar!!??

Da ich kein USB-Spezialist bin (das ist der Grund, warum ich die Atmel 
HID-Implementierung verwenden möchte) bin ich jetzt mit meiner Weisheit 
ziemlich am Ende.

Hat jemand von Euch ähnliche Erfahrung und kann mir irgendeinen Tipp 
geben, was faul ist?

Ein reichlich ratloser

Josef

[NGC1232 (Gast)]

Push! (Bei der Menge an posts in diesem Forum ist der BEitrag ja 
vergessen, noch bevor ihn einer gelesen hat...)

[Stefan B. (stefan)]

Das Demo at90usb128-demo-hidgen-std sieht mir mit der heissen Nadel 
gestrickt aus und eher danach, als ob es aktuell für die STK525 Hardware 
übersetzt ist und nicht für die USBKEY Hardware.

In der config.h Datei ist folgender Abschnitt

// ...
#include "conf/conf_scheduler.h" //!< Scheduler tasks declaration

#define  STK525   0
#define  USBKEY   1

//! Enable or not the ADC usage
#undef USE_ADC
//! To include proper target hardware definitions, select
//! target board (USBKEY or STK525)
#define TARGET_BOARD STK525
// ...

Die Definitionen sind IMHO etwas konfus.

#define  STK525   0
#define  USBKEY   1

Erscheint mir OK, um den Code für USBKEY zu produzieren. Aber dagegen 
spricht

#define TARGET_BOARD STK525

Ich würde an dieser Stelle nachhaken und die Sache mir

#define TARGET_BOARD USBKEY übersetzen.

Auch das aktuelle GCC Makefile enthält die Rules, um die hid_gen.a90 
Firmware für das STK525 Hardware zu machen.

Ich vermute, du hast die falsche Firmware hid_gen.a90 in dem USBKEY 
drin. Das passt zu deiner Beobachtung, dass eine anderere Firmware mit 
dem USBKEY funktioniert.

Blüd, dass in dem Demoarchiv keine fertige Firmware für beide 
Targetboards drin ist. Wie gesagt, IMHO heiss gestrickt.

[Sven Z. (Firma: ZEGO GmbH) (svencz)]

Hi,

ich hab ein recht ähnliches Problem in anderem Kontext:
meine Hardware ist ein AT91SAM7S256 auf dem die USB Schnittstelle per 
firmware unter Zuhilfenahme des AT91 USB Framework als USB HID Device 
programmiert ist. Auf dem selben Weg hab ich den Chip schon erfolgreich 
als MSD am laufen.

Auf der PC Seite habe ich als Ausgangspunkt ein C# Projekt verwendet 
(siehe http://www.codeproject.com/useritems/USB_HID.asp). Das daraus 
entstandenen Programm findet nun das HID Gerät problemlos und kann von 
diesem auch die caps (input report length, output report length, ...) 
korrekt erfragen.

Wenn ich dann allerdings versuche, auf das Gerät zu schreiben 
(FileStream.Write) wird das ebenfalls mit einer Exception quittiert, der 
zu folge ein Parameter falsch ist.

Soweit ähnelt die Situation bei mir also schon dem oben beschriebenen 
Problem.

Die Lösung scheint mir eher auf dem PC zu liegen als in der Firmware, 
weil die Fehlermeldung ja in beiden Fällen die übergebenen Puffer 
betrifft.

Eine Lösung hab ich noch nicht, aber ich experimentier grade mit der 
Puffer Länge. Bei einem Generic Data Transfer über HID muss - soweit ich 
weiß - die Pufferlänge exakt mir der Länge des out reports 
übereinstimmen ...

Ich melde mich, wenn ich weiter komme und würd mich über jeden neuen 
Ansatz freuen...

Sven

[Sven Z. (Firma: ZEGO GmbH) (svencz)]

Sorry Stefan, was auch immer ich falsch gemacht hab ... klär mich 
einfach auf, bin lernwillig :-)

Ich hab in der Zwischenzeit noch was interessantes gefunden:
http://www.lvr.com/hidpage.htm

Insbesondere die beiden Programm HidTest und SimpleHidWrite helfen 
weiter, die Kommunikation zwischen PC und Gerät in kleinen Schritten zu 
testen.

In meinem Fall legen die nahe, dass doch was mit der Firmware nicht 
stimmt ... die Anzahl Strings kommt mir spanisch vor und bei 
GetPhysicalDescriptor kracht es auch. Wobei ich dachte, das ein HID die 
gar nocht unbedingt zurückgeben muss ...

Stefan - was meinst Du mit kapern?

[Stefan B. (stefan)]

Du beziehst dich auf das Posting von mir, das ich (fast) direkt nach 
meiner Eingabe gelöscht habe. Leider war ich nicht schnell genug ;-)

Der Thread war gegenüber meinen letzten Besuch nämlich markiert, dass es 
eine neue Nachricht gibt. Also habe ich in den Thread reingeschaut, weil 
ich eine Antwort von Josef vermutete.

Dann sah ich nur dein Posting mit einem komplett anderen µC (ARM7 
Architektur statt AVR) und habe es als ein Kapern/Übernehmen/Entführen 
der Diskussion zu Gunsten deiner Problemstellung empfunden.

Beim zweiten Lesen war ich mir unschlüssig, ob ich 100% richtig liege 
und dann... im Zweifel für den "Angeklagten", d.h. laissez faire.

[Sven Z. (Firma: ZEGO GmbH) (svencz)]

Threads kapern halt ich für eine sehr kuriose idee ... lassen wir sowas.

Also Josef: was mich angeht, so ist das Problem gelöst:
Das erste Byte, das zum Gerät gesendet wird, muss die Report ID sein, in 
meinem Fall 0x00 weil ich nur einen InputReport habe.
Windows merkt sich wohl beim Aufruf von HidD_GetPreparsedData oder 
HidP_GetCaps die vom Gerät definierten Reports und parsed die via 
WriteFile gesendeten Daten. Wenn dort dann eine ungültige ReportID 
angegeben ist, kommt es zur Fehlermeldung "Falscher Parameter" (ich 
benutze C#).

Grüße,
Sven

[Jacob Schultz (Gast)]

Josef,

Excuse I answer in English, but I cannot write in German - though I can 
read and understand most of it.

I had the same problem and got the same fail code in VC++. I then 
changed the PID in the device and it went away. I think Windows may 
clutter the PIDs if it is once registered to a specific product.

Hope this helps

[wschrabi (Gast)]

Hi Leute,
also ich hätte da eine Frage:
Ich hab ein Device mit einem 3rd Prty driver entwicklet, das ich jetzt 
auf HID class driver umstellen will. Es wird nur vom Device gelesen . 
Keine Daten gehen an das Device. Ich habe mich schon ein bisserl 
eingelesen, doch meine Frage. Muss der Report ein bestimmtes Format 
sein, oder kann der wie bei einem Pipe meine 64 Byte Daten beinhalten? 
Woher bekomme ich die von AMTEL beschriebene DLL und wie binde ich sie 
in Delphi 7 ein? Besten DANK im vorraus. (Ich bin noch ein kompletter 
USB-Novice)
Walter