VUSB - Device wird nicht erkannt.

Gern.
Der Schaltplan ist in der PNG-Datei zu sehen.

Hi

Studentle schrieb:
> Versuch mal die Z-Dioden auf 3,6V zu erhöhen.

Bei der Gelegenheit sollte auch der USB-Shield auf GND "gebandpasst" 
werden.
1MOhm und 4.7nF sind wohl dafuer empfohlen.

Ist zwar fuer XMega Serie - aber man kann bestimmt etwas daraus 
verwenden: http://www.atmel.com/Images/doc8388.pdf

MfG

Du könntest deine Versorgungsspannung auch auf 3.3V reduzieren, dann 
benötigst du keine Z-Dioden mehr und R9 darf dann nur noch 1k Ohm groß 
sein.

Zusaetzliche Anmerkung:

Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht 
fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden 
Rechner booten?
Dann den Stick reinstecken und uns das Log posten?

MfG

Mal ne Frage von nem USB-Unwissenden.
Sollten die Z-Dioden nicht hinter R4/5 liegen?

Birgit Pie schrieb:
> Mein Problem ist aber, dass das Teil nicht vom PC erkannt wird, wenn es
> am PC angeschlosen ist, wenn dieser Hochfährt. Nehme ich ihn dann wieder
> ab und stecke ihn neu ein, läuft wieder alles.

Hast du mal ausprobiert, nur den ATtiny45 anzuschließen und alle 
anderen USB-Geräte abzustöpseln? Manchmal behindern die sich 
gegenseitig.

Hi

Teo Derix schrieb:
> Mal ne Frage von nem USB-Unwissenden.
> Sollten die Z-Dioden nicht hinter R4/5 liegen?

Nein - denn die Dioden sollen das 5V Potential aus dem Mikrocontroller 
auf 3.3V reduzieren. Ohne Widerstand wuerden da theoretisch "unendliche" 
Stroeme fliessen - praktisch geht vermutlich der PIN am AVR kaputt.

Vom USB her kommen bereits 3.3V Kommunikationsspannung, welche durch die 
hohe Eingangstoleranz im AVR als korrekte Logikpegel erkannt werden.

MfG

Teo Derix schrieb:
> Sollten die Z-Dioden nicht hinter R4/5 liegen?

Weil die 5V ja von AVR kommen und die USB-Datenleitungen mit 3.3V 
arbeiten.
Die Widerstände begrenzen den Strom auf (5-3.3)/68 = 25mA.

Stephan B. schrieb:
> Ohne Widerstand wuerden da theoretisch "unendliche" Stroeme fliessen -
> praktisch geht vermutlich der PIN am AVR kaputt.
Der geht praktisch lange nicht kaputt. So einen (einzelnen) AVR Pin 
kannst du problemlos sogar an Vcc legen und gegen Masse schalten oder 
andersrum...

Hallo

Lothar Miller schrieb:
> Der geht praktisch lange nicht kaputt. So einen (einzelnen) AVR Pin
> kannst du problemlos sogar an Vcc legen und gegen Masse schalten oder
> andersrum...

Okay, gut zu wissen das die Dinger so robust sind.

Bei der Versorgung ueber USB fuhert das dann aber vermutlich dazu, das 
die Vcc absinkt und der BrownOut den AVR abschaltet.
Richtig funktionieren tut's USB dann auch nicht.

MfG

Hans Jelt schrieb:
> Weil die 5V ja von AVR kommen und die USB-Datenleitungen mit 3.3V
> arbeiten.

Danke!
(Hatte die 5V dem USB zu geschrieben, wie peinlich :-} )

Hallo.

Zunächst danke für die vielen Antworten und sorry für meine späte 
Antwort, die Grippe hat mich erwischt...aber jetzt kann es weiter gehen.

So, dann zu euren zahlreichen Ideen:

1. Versuch mal die Z-Dioden auf 3,6V zu erhöhen.

-> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe, 
nur 4,7V und das ist dann wohl etwas zu hoch, oder?
Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid.

2. Bei der Gelegenheit sollte auch der USB-Shield auf GND "gebandpasst"
werden. 1MOhm und 4.7nF sind wohl dafuer empfohlen.

-> Das brachte bei dem aktuellen Problem keine Besserung, war aber wohl 
auch eher "allgemein" gemeint.

3. Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du 
vielleicht
fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden
Rechner booten?
Dann den Stick reinstecken und uns das Log posten?

-> Dazu muss ich sagen, dass ich mit Linux bisher noch nicht so viel 
gemacht habe...die Live-CD kann ich mir vermutlich downloaden...aber wie 
komme ich dann zu dem Log?
Ich habe in einer VM Linux (Ubuntu) installiert. Das sollte doch auch 
als Test funktionieren, oder? Wenn ja, kann mir jmd. sagen, wie ich zu 
dem Log komme?


4. Hast du mal ausprobiert, nur den ATtiny45 anzuschließen und alle
anderen USB-Geräte abzustöpseln? Manchmal behindern die sich
gegenseitig.

-> Ja. Sowohl an dem ersten Testrechner (Laptop) als auch an dem zweiten 
(normaler PC auch mit Windows XP) waren nur der ATMEGA angeschlossen, 
mit dem gleichen Ergebnis, dass er nicht gefunden wurde.

5. Was passiert, wenn du im BIOS den "USB legacy support" abschaltest?
(Sofern das bei deinem BIOS/UEFI überhaupt noch möglich ist)

-> Beim Laptop gibt es diese Einstellung im BIOS nicht. Beim PC war es 
bereits abgeschaltet. Habe es versuchsweise mal angeschaltet, brachte 
aber auch nichts.

Ich bin echt ratlos, hoffe, dass die 3,6V Z-Dioden helfen…

Birgit Pie schrieb:
> -> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe,
> nur 4,7V und das ist dann wohl etwas zu hoch, oder?
> Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid.

Falls du auch "normale" Dioden da hast, könntest du jeweils eine Z-Diode 
und eine normale in Reihe schalten (entgegengesetzte Polung natürlich). 
Damit kommst du auf ca. 3,9 Volt, was wahrscheinlich auch ok ist.

Markus Weber schrieb:
> Birgit Pie schrieb:
>> -> Das dauert leider noch etwas, da ich diese Z-Dioden nicht da habe,
>> nur 4,7V und das ist dann wohl etwas zu hoch, oder?
>> Sobald der Test mit den 3,6V gelaufen ist, gebe ich Bescheid.
>
> Falls du auch "normale" Dioden da hast, könntest du jeweils eine Z-Diode
> und eine normale in Reihe schalten (entgegengesetzte Polung natürlich).
> Damit kommst du auf ca. 3,9 Volt, was wahrscheinlich auch ok ist.

Da waere ich vorsichtig! Fuer Details lese bitte: 
http://forums.obdev.at/viewtopic.php?f=8&t=8751&sid=6a19b063a258fd8271fe62f46af5f646

MfG

Stephan B. schrieb:
> Da waere ich vorsichtig! Fuer Details lese bitte:
> 
http://forums.obdev.at/viewtopic.php?f=8&t=8751&sid=6a19b063a258fd8271fe62f46af5f646

Halt, das war wohl ein Missverständnis. :-)
Die "normalen" Dioden jeweils in Reihe zu den Z-Dioden und natürlich 
nicht so, wie in deinem Link gezeigt.

So, die Z-Diode ist da, getauscht...das gleiche Ergebnis, Problem also 
nicht behoben.

Ich habe das ganze mal noch an einem anderen Rechner probiert, auf dem 
Windows7 installiert ist. Da hat es erstaunlicherweise funktioniert. 
Allerdings muss ich dazu sagen, dass alle 3 Rechner unterschiedliche 
Hardware haben.


>Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht
>fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden
>Rechner booten?
>Dann den Stick reinstecken und uns das Log posten?

Wenn mir hierzu jemand sagen kann, wie ich an das Log komme und ob das 
ganze auch mit Linux in der VR-Umgebung funktioniert (denke schon), 
würde ich auch diese Infos gern noch bereit stellen.

Danke.

Birgit Pie schrieb:
> So, die Z-Diode ist da, getauscht...das gleiche Ergebnis, Problem also
> nicht behoben.

:-(

> Allerdings muss ich dazu sagen, dass alle 3 Rechner unterschiedliche
> Hardware haben.

100 µF an USB zu hängen, hab ich mich bisher nicht getraut, aber das 
sollte eigentlich trotzdem gehen.

> Wenn mir hierzu jemand sagen kann, wie ich an das Log komme und ob das
> ganze auch mit Linux in der VR-Umgebung funktioniert (denke schon),
> würde ich auch diese Infos gern noch bereit stellen.

Aus einer VR-Umgebung ist der Zugriff auf die Hardware immer nicht so 
einfach – oder er wird gar umgeleitet, und man nutzt dann die Treiber 
des Wirts-Systems, was dir dann natürlich nicht viel nützt.

Warum erzeugst du dir nicht einfach eine Linux-DVD (Ubuntu oder Knoppix 
oder Debian) und bootest den Windows-PC von dieser?
Linux ist sehr flexibel, man muss es gar nicht installieren, man kann es 
auch von einer DVD aus oder von einem USB-Stick aus verwenden. Dann 
läuft es natürlich langsamer, aber in diesem Fall stört das sicher 
nicht.

Und vielleicht gefällt es dir am Schluss doch so gut, dass du umsteigst. 
;-)

Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät 
mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub 
dazwischen.
Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal.

Was ich auch noch machen würde:
Versorgungsspannung auf 3.3V reduzieren (Z-Dioden entfernen)
-> R9 von 1.5k Ohm auf 1k Ohm verkleinern

Hans Jelt schrieb:
> Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät
> mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub
> dazwischen.
> Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal.

Gute Idee, finde ich.

> Was ich auch noch machen würde:
> Versorgungsspannung auf 3.3V reduzieren (Z-Dioden entfernen)
> -> R9 von 1.5k Ohm auf 1k Ohm verkleinern

Hmmm... aber prüfen, ob der ATtiny45 dann noch läuft. Für V-USB ohne 
eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet 
(interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein. 
Muss man probieren.

Hallo.

Nach längerer Pause "muss" ich mich nun wieder mit diesem Problem 
beschäftigen. ;-)
Das heißt, es ist leider noch nicht erledigt.

> Es gibt da noch etwas an das es liegen könnte ... hänge das V-USB-Gerät
> mal nicht direkt an den USB-Port des Rechners sondern hänge einen Hub
> dazwischen.
> Wenn du noch einen USB 1.1 Hub hast wäre das natürlich ideal.

Das habe ich getestet, leider nur mit einem 2.0 Hub. Der Fehler ist 
genau der gleiche.


>Wenn Hardwareanmerkungen bisher nichts bringen, koenntest du vielleicht
>fuer uns einmal kurz Linux (Knoppix?) per LIVE-CD auf dem betreffenden
>Rechner booten?
>Dann den Stick reinstecken und uns das Log posten?

Ich habe das mit einer Ubuntu (12.04) Live CD probiert. Nun ist es so, 
dass an dem einen Laptop prinzipiell das gleiche Verhalten zu sehen war, 
wie bisher. Davon habe ich die 2 LogFiles bei getan. Eins nach dem 
Hochfahren, wo es nicht funktioniert hat.
Das zweite nachdem ich das Gerät nochmal abgezogen und wieder angesteckt 
habe und es dann funktionierte.

An einem anderen Laptop funktioniert es im Ubuntu auch direkt nach dem 
Hochfahren.
Aber bei beiden Laptops funktioniert es nicht im Windows.

Von der Windows-Variante habe ich gestern mal noch ein paar Screenshots 
der Datensignale gemacht. Vielleicht sagt das jemandem etwas.

USB-Gerät wird NACH dem Hochfahren angeschlossen:
VUSB_3.PNG: ständige Signalwechsel

USB-Gerät wird VOR dem Hochfahren angeschlossen:
VUSB_1.PNG: zu Beginn noch ein paar korrekte(?) Signalwechsel
VUSB_2.PNG: Dauersignal, Gerät wird nicht erkannt

Danke an alle, die drüber nachdenken.

Gruß.
bpie

Markus Weber schrieb:
> Hmmm... aber prüfen, ob der ATtiny45 dann noch läuft. Für V-USB ohne
> eigenem Quarz wird meist eine Taktfrequenz von 16,5 MHz verwendet
> (interner RC-Oszillator). Dafür könnten 3,3 Volt dann zu wenig sein.
> Muss man probieren.

@ Birgit Pie (bpie)
Vielleicht könntest du den ATTiny45 mal mit einem 12MHz Quarz bestücken 
und probieren ob es so besser läuft.

Lass mal die Z-Dioden weg! Ich arbeite schon mehreren Jahren mit dieser 
Schaltung und die Funktioniert ohne Probleme. Es gibt 3 Arten der 
Beschaltung . Hatte das gleiche Problem mit einem ATMega 8. Außerdem 
sollte man einen ATMega verwenden der eine eigenen Quartz benutzt. Dann 
ist man auf der sicheren Seite. Habe so mehrere usbisp aufgebaut und 
eine Schaltung
mit der man einen Atmega 32 als Schnittstelle für den i2c Bus verwenden 
kann.

Chris schrieb:
> Ich könnte mir vorstellen, dass V-USB den vom Host ausgelösten
> Device-Reset nicht korrekt implementiert hat (ich kenne V-USB zwar
> nicht, aber das USB-Protokoll dafür etwas mehr). Beim Starten eines
> kompletten PCs ist es durchaus wahrscheinlich, dass der USB-Bus mehrfach
> neu enummeriert wird, obwohl die USB-Versorgungsspannung die ganz Zeit
> eingeschaltet bleibt. Das ist aus Sicht des USB-Devices eine vollkommen
> andere Situation als das anstecken an den Bus.

Der erste Beitrag, der ein tatsächliches Problem anspricht! Die ganzen 
Vermutungen zur Beschaltung passen nicht zur Reproduzierbarkeit des 
Problems.

Meine Vermutung wäre auch, dass der Reset nicht erkannt wird. Bisher 
wurde noch nichts über die Software gesagt? In V-USB wird der Reset 
"manuell" über usbpoll() gepollt. Wenn diese Funktion nicht häufig genug 
aufgerufen wurden, wird ein Reset nicht erkannt und die Enumeration 
funktioniert nur direkt nach dem Kaltstart des Controllers.

Kannst Du die Hauptschleife Deines Codes posten?

Sven Schwiecker schrieb:
> Lass mal die Z-Dioden weg! Ich arbeite schon mehreren Jahren mit dieser
> Schaltung und die Funktioniert ohne Probleme. Es gibt 3 Arten der

Ja toll. Es enstpricht aber trotzdem nicht der Spezifikation und kann, 
je nach Bauart des Host-Controllers, diesen zerstören.

So sieht ein Reset mit Enumeration auf dem Bus auf. Das sollte 
irgendwann auftauchen und dann auch korrekt interpretiert werden.

Hallo.


Der Code der Hauptschleife ist folgender:

1

int main(void)

2

{

3

uchar   i;

4

uchar   calibrationValue;

5

6

    calibrationValue = eeprom_read_byte(0); /* calibration value from last time */

7

    if(calibrationValue != 0xff){

8

        OSCCAL = calibrationValue;

9

    }

10

    odDebugInit();

11

    usbDeviceDisconnect();

12

    for(i=0;i<20;i++){  /* 300 ms disconnect */

13

        _delay_ms(10); 

14

    }

15

    usbDeviceConnect();

16

    DDRB |= 1 << BIT_LED;   /* output for LED */

17

    PORTB |= 1 << BIT_KEY;  /* pull-up on key input */

18

    PORTB |= 1 << BIT_ENC_DIR;  /* pull-up on "key" input */

19

    wdt_enable(WDTO_1S);

20

    timerInit();

21

  init_encInt(); //Initialisierung Encoder

22

    usbInit();

23

    sei();

24

    for(;;){    /* main event loop */

25

        wdt_reset();

26

        usbPoll();

27

28

        if(usbInterruptIsReady() && nextDigit != NULL){ /* we can send another key */

29

            buildReport();

30

            usbSetInterrupt(reportBuffer, sizeof(reportBuffer));

31

            if(*++nextDigit == 0xff)    /* this was terminator character */

32

                nextDigit = NULL;

33

        }

34

        timerPoll();//Drucktaster des Encoders abfragen

35

  if(enc_changed) { evaluateENC(); enc_changed=0; }//oo

36

37

    }

38

    return 0;

39

}

Ich habe testweise nach "odDebugInit();" ein "_delay_ms()" mit 
verschiedenen Zeiten eingefügt. So, dass am Oszi ca. 10ms zu sehen 
waren, leider hat auch dann das Erkennen nicht funktioniert.

Noch ein Test mit der for-Schleife wie folgt:

1

for(;;){    /* main event loop */

2

        wdt_reset();

3

        usbPoll();

4

5

        }

6

    }

Also nichts weiter drin als das usbPoll() führte zu dem gleichen 
Problem...

Auch mit der Wartezeit vor usbDeviceDisconnect().

Birgit Pie schrieb:
> Der Code der Hauptschleife ist folgender:

Sieht soweit eigentlich ok aus, so lange nicht einer der 
Funktionsaufrufe hängen bleibt. Ich würde das Problem jetzt weiter 
angehen, in dem ich mir einen Debugausgang schaffe, z.B. ein pin mit 
soft-UART, und mir anzeigen lasse, wann ein Reset erkannt wird. Den Bus 
mit dem Oszi zu beobachten ist schwierig, da ist ein Logikanalyzer 
besser geeignet.

Bla schrieb:
> Eventuell läuft ja auch deine Oszillatorkalibrierung Amok, wenn der PC

Könnte man auch gleich über den Debugausgang ausgeben.

Chris schrieb:
> usbDeviceDisconnect() und usbDeviceConnect() vor dem usbInit() kommt mir
> persönlich seltsam vor, steht allerdings auch so in diesem Wiki:
> http://vusb.wikidot.com/driver-api  Man könnte mal im V-USB sourcecode
> nachschauen, ob das ernst gemeint oder ein Versehen ist.

Die Reihenfolge ist ziemlich egal, da die Macros fast nichts machen :)

Chris schrieb:
> Was soll das Programm bei einem Bus-Reset machen? Die Neukalibrierung
> wie bei http://vusb.wikidot.com/examples unter "Clocking the AVR from
> the RC oscillator with auto-calibration" beschrieben? Dann würde ich mal
> in der USB-Spec und mit dem Scope schauen, ob die Annahme mit dem
> Frame-Clock auch wirklich stimmt, oder ob das nur beim ersten mal
> anstecken passiert.

Wenn am Bus ein Reset ohne anschließendes Keepalive/Framsignal ausgelost 
wird, wird calibrateosc den RC-Oscillator komplett dekalibrieren, da die 
Routine keinen Sanity-Check hat.

Edit: Es ist sogar noch schlimmer: Die mitgelieferte Routine hat einen 
Timeout, verabeitet diesen aber nicht. Evtl. funktioniert meine 
Alternative in Assembler besser - die hängt einfach so lange, bis wieder 
ein Keepalive kommt:

https://github.com/micronucleus/micronucleus/blob/master/firmware/osccalASM.S

Buchhalter schrieb:
> Ändere dein Design auf 3,3V mit Quartz und dann taste dich an dein
> Zieldesign ran.

Du kannst ja PB3 als externen Takteingang nehmen, entweder du nimmst 
12MHz einen Oszillator oder einen 12MHz Quarz mit Verstärkerschaltung.
http://elektroniktutor.de/signalkunde/quarzosz.html
http://www.rn-wissen.de/index.php/Quarzoszillator

Bla schrieb:
> Wie verhält sich denn ein anderes VUSB-Bastelgerät am Rechner? Zum
> Beispiel ein USBASP?

Kann ich leider nichts zu sagen, habe kein anderes Gerät mit VUSB.

Ich habe mal nach "usbDeviceDisconnect();" und vor "for(i=0;i<20;i++)" 
ein LED_TOGGLE eingefügt. Wenn man diese dann mit dem Osci beobachtet, 
sieht man das der Pin ständig toggelt. Also wird anscheinend ständig ein 
Reset ausgeführt...aber warum?
Der Watchdog? Ganz am Anfang der Routine habe ich anschließend ein 
"wdt_disable()" eingefügt...ohne Erfolg. Willkürlich gesetzte 
"wdt_reset()" brachten auch keinen Erfolg.
Wenn ich die Datenleitung D- aus dem USB-Kabel raus nehme erfolgt zwar 
logischerweise keine Kommunikation, aber die LED toggelt auch nicht. 
Kann es sein, das der Reset vom PC ausgeführt wird?

Dein Gerät bekommt keinen richtigen Kontakt zum PC.

Wie sieht denn die Resetbeschaltung bei dir aus?
Im Schaltplan ist das scheinbar eine LED, ist nicht wirklich passend.
Ein 10k bis 100k Ohm Widerstand nach Vcc und ein 100nF Kondensator nach 
Masse sind die Standardbeschaltung.
Wenn alles okay ist liegt während des Betriebs am Reset-Pin die 
Versorgungsspannung an.

Es könnte auch an der Methode "buildReport()" liegen, aber an deiner 
Stelle würde ich erst mal nicht bei der Software suchen, sondern bei der 
Hardware.

Kopiere dein Projekt, schreibe die Software so um dass zwei oder ein Pin 
frei sind und nutze den 12MHz Takt.
Da das bei 3.3V läuft könntest du vielleicht auch die Spannung auf 3.3V 
stellen.

Du versuchst weiter bei der Software obwohl der Fehler woanders liegt.

Birgit Pie schrieb:
> Ich habe mal nach "usbDeviceDisconnect();" und vor "for(i=0;i<20;i++)"
> ein LED_TOGGLE eingefügt. Wenn man diese dann mit dem Osci beobachtet,
> sieht man das der Pin ständig toggelt. Also wird anscheinend ständig ein
> Reset ausgeführt...aber warum?

Auf welchem Pegel liegt denn der Reset-Pin? Ist die Spannungsversorung 
stabil, oder cycled der PC diese beim hochfahren? Kannst Du den Watchdog 
auch einfach ausbauen?