At90usb162 nicht erkannt

Florian Schuller schrieb:
> wenn ich den AT90usb162 an den USB-Port meines PCs anstecke,
> meldet er, dass das angesteckte USB-Gerät nicht erkannt werden konnte.

Dann ist Dein AT90USB162 ok. Denn zu diesem Zeitpunkt hat der PC ihn 
bereits als USB Gerät erkannt, kann aber mit der ID des USB Gerät nichts 
anfangen
(Merke: Die ID wurde bereits vom uP gesendet, d.h. der uP hat die 
Enumeration schon mal "überlebt". Glückwunsch, der Bootloader lebt noch 
:-)

Oder mit anderen Worten: Es ist kein passender Gerätetreiber auf dem PC 
installiert.

Schau mal im Gerätemanager nach. Da sollte jetzt irgendwo ein USB Gerät 
mit einem Fragezeichen (oder wars ein Blitz ? Weiss nicht mehr genau) 
auftauchen.
Bei Dem schaust Du mal nach der ID und vergleichst sie mit der des 
Atmels. Sollte die Gleiche sein ;-)

(Sry, für die Ungenauigkeiten. Aber ich kanns hier gerade nicht 
nachvollziehen. Wenn Du da nicht weiterkommst, dann poste noch mal. Dann 
kann ich das heute abend Zuhause vor dem Rechner checken, wo die ganzen 
uP dran sind)

Grüße
Andreas

Danke für die Antworten, jedoch kann ich die ID nicht auslesen. Es steht 
nur Device_Description_Falure. (Siehe Foto)

>Dann ist Dein AT90USB162 ok. Denn zu diesem Zeitpunkt hat der PC ihn
>bereits als USB Gerät erkannt, kann aber mit der ID des USB Gerät nichts
>anfangen
>(Merke: Die ID wurde bereits vom uP gesendet, d.h. der uP hat die
>Enumeration schon mal "überlebt". Glückwunsch, der Bootloader lebt noch

Wird das USB-Gerät nicht schon erkannt wenn ein Pullup an einer der 
Datenleitungen liegt?

Florian Schuller schrieb:
> Wird das USB-Gerät nicht schon erkannt wenn ein Pullup an einer der
>
> Datenleitungen liegt?

Ja. Daran erkennt der PC typischerweise, dass da was dran ist. Beim 
At90USB162 wird über interne Config-Rs D+ nach high gepullt --> 
FullSpeed mode.

Dann hat doch Dein controller noch Probleme. Da fallen einem natürlich 
erst mal die üblichen Verdächtigen ein:

- Kurzschlüsse zwischen den Pins ?
- Versorgungsspannung an allen benötigten Pins ? (Das ist hier besonders 
wichtig). GND das Gleiche
- Fehlende C's (hatte oben schon jemand geschrieben)
- Ungünstiges Layout, insbesondere Oszillator und USB sind da kritisch.
- Oszillator schwingt nicht an

Wenn das alles gecheckt und ok ist, dann besorg Dir einen USB Logger. 
Mit so einem Programm kannst Du den USB Traffic am PC mitlesen und 
schauen, ob der AT90USB162 überhaupt mit dem PC redet.

Wenn nicht würde ich versuchen, ein Minitestprogramm über das normale 
Programmierinterface einzuspielen und zu sehen, ob das normal arbeitet.

Versuch diese Sachen mal. Ich vermute, es ist einer der ersten fünf 
Punkte. Wenn Du Hilfe brauchst, einfach posten :-)

Grüße
Andreas

P.S: Unbedingt Kapitel 19 im Datenblatt lesen ;-)

Danke für die Hilfe. Ich habe mal einen USB Logger verwendet, jedoch 
kann ich nicht viel herauslesen. Vielleicht kann mir jemand das 
erklären. Im Anhang ist der Log.

Andreas H. schrieb:
> Dann hat doch Dein controller noch Probleme. Da fallen einem natürlich
> erst mal die üblichen Verdächtigen ein:

Es fehlt noch die Reset-Beschaltung (Pullup nach VCC).

Und die Abblockkondensatoren an der Versorgungsspannung.

Ich bin mir gerade nicht sicher, ob der Bootloader mit einem 16MHz-Quarz 
ordentlich tut. Ich meine bei mir hätte das mal funktioniert, würde aber 
meine Hand nicht ins Feuer legen. Mit 8MHz bist Du auf der sicheren 
Seite (eigentlich muss für 16MHz das Bit PLLP0 in PLLCSR gesetzt werden, 
mir ist gerade unklar was der Bootloader da macht)

Viele Grüße,
        Simon

So ich habe jetzt die Schaltung nach euren Angaben abgeändert, doch es 
meldet sich immer noch nichts. Ich habe auch den Quarz mit dem Oszi 
gemessen und er schwingt an. Versteht irgendwer den Log den ich vorher 
gepostet habe?

>Ich bin mir gerade nicht sicher, ob der Bootloader mit einem 16MHz-Quarz
>ordentlich tut. Ich meine bei mir hätte das mal funktioniert, würde aber
>meine Hand nicht ins Feuer legen.

Ich hatte die Schaltung auch mal mit 16MHz aufgebaut und sie 
funktionierte, außerdem hab ich es auch schon mit 8MHz probiert, und das 
selbe Problem entstand.

Florian Schuller schrieb:
> Versteht irgendwer den Log den ich vorher gepostet habe?

Ich leider nicht.

Aber ich habe noch eine dumme Idee: Check doch bitte mal, ob D+ und D- 
wirklich an die richtigen Leitungen gehen. Nicht dass da irgendein 
dorschenanner bei dem Steckeranschluss ist.

Viele Grüße,
        Simon

>Check doch bitte mal, ob D+ und D-
>wirklich an die richtigen Leitungen gehen.

Ja ist sicher richtig. Außerdem hab ich sie auch vertauscht probiert.

Simon Budig schrieb:
> Ich bin mir gerade nicht sicher, ob der Bootloader mit einem 16MHz-Quarz
> ordentlich tut

Bei mir läuft der AT90USB162 mit 16MHz und USB problemlos.

@Florian: Wir reden hier aber schon von einem Bootloader, wie er von 
Hause aus (also ATMEL) drin ist, oder ?

Welche Debugmöglichkeiten hast Du denn ? Scope, ISP Programmer (MK II) ?

Kannst Du mal Fotos vom Board posten ? Da kann man ja auch oft den einen 
oder anderen "Glitch" erkennen.

Mir gehen sonst langsam die Ideen aus fürchte ich :/

Viele Grüße
Andreas

Andreas H. schrieb:
> Bei mir läuft der AT90USB162 mit 16MHz und USB problemlos.

Ok, mit 8MHz bei mir auch. Wie könnte denn der Bootloader entscheiden, 
ob er dieses PLL-Bit nun setzen muss oder nicht? Ausprobieren?

Grüße,
        Simon

>@Florian: Wir reden hier aber schon von einem Bootloader, wie er von
>Hause aus (also ATMEL) drin ist, oder ?

Ja exakt.

>Welche Debugmöglichkeiten hast Du denn ? Scope, ISP Programmer (MK II) ?

Ja die beiden auf jeden Fall.

>Kannst Du mal Fotos vom Board posten ? Da kann man ja auch oft den einen
>oder anderen "Glitch" erkennen.

Fotos kann ich erst morgen posten, aber ich werde am Wochenende, falls 
keiner mehr eine Idee hat, einen anderen AT90usb162 drauflöten. 
vielleicht geht es dann.

Florian Schuller schrieb:
> otos kann ich erst morgen posten, aber ich werde am Wochenende, falls
> keiner mehr eine Idee hat, einen anderen AT90usb162 drauflöten.
> vielleicht geht es dann.

Bevor Du das machst, programmier doch mal einen Blinktest mit dem MKII 
direkt rein. Dann siehst Du erst mal, ob der Chip überhaupt vernünftig 
läuft. Bei der Gelegenheit kannst Du mal die fuses kontrollieren, ob da 
(woher auch immer) etwas falsch gesetzt ist.

Danach kannst Du z.B. mal (auch mit MKII Prg) die USB Schnittstelle 
konfigurieren und kontrollieren, ob sie dann Enumeriert wird.

Alles weniger "Neufehler"-anfällig als den Chip tauschen, oder ?

Grüße
Andreas

Ich habe mal ein LED-Blinkprogramm auf meinen AT90USB162 draufgespielt:

1

#include <avr/io.h>

2

#include <util/delay.h>

3

#define F_CPU 16000000UL

4

5

int main(void)

6

{

7

DDRB = 0xFF;  

8

    while(1)

9

    {

10

        PORTB = 0xFF;

11

  _delay_ms(10000);

12

  PORTB = 0x00;

13

  _delay_ms(10000);

14

    }

15

}

Die LED sollte also alle 10sek. zwischen hell und dunkel wechseld. Dies 
geschieht aber alle 5sek. Hat jemand eine Idee woran das liegen kann?

>Bei der Gelegenheit kannst Du mal die fuses kontrollieren, ob da
>(woher auch immer) etwas falsch gesetzt ist.

Meine Fuses sind: LFUSE:0x5E,HFUSE:0xD9,EFUSE:0xF4. Müsste also passen.

Florian Schuller schrieb:
>   _delay_ms(10000);

_delay_ms() hat eine maximale Wartezeit von ein paar Millisekunden. Da 
musst Du für längere Delays besser noch eine Schleife drumrumpacken.

Viele Grüße,
        Simon

Ich habs jetzt so:

1

#include <avr/io.h>

2

#include <util/delay.h>

3

#define F_CPU 16000000UL

4

5

int main(void)

6

{

7

  int i;

8

  DDRB = 0xFF;  

9

    while(1)

10

    {

11

        PORTB = 0xFF;

12

    for(i=0; i<10000;i++)

13

    {

14

      _delay_ms(1);

15

    }

16

    PORTB = 0x00;

17

    for(i=0; i<10000;i++)

18

    {

19

      _delay_ms(1);

20

    }

21

22

    }

23

}

Sind aber genauso 5sek.

Florian Schuller schrieb:
> #include <avr/io.h>
> #include <util/delay.h>
> #define F_CPU 16000000UL
[...]
> Sind aber genauso 5sek.

Oh. pack das #define F_CPU mal vor das include von util/delay.h

Grüße,
         Simon

Simon Budig schrieb:
> Oh. pack das #define F_CPU mal vor das include von util/delay.h

Ja, da hat Simon recht. Das define musst Du unbedingt vor dem include 
haben. Sonst wird in delay.h ein Default benutzt, der nur für 8 MHz 
korrekt ist.
Und defines werden vom Präprozessor umgewandelt, der Compiler sieht hier 
nur noch die Zahl.

Grüße
Andreas

Simon Budig schrieb:
> _delay_ms() hat eine maximale Wartezeit von ein paar Millisekunden.

Bist Du da sicher ? Oder meinst Du _delay_us() ?

Eigentlich haben beide einen uint16 als parameter, können also 65535 us, 
bzw. ms. verzögern.

Grüße
Andreas

Andreas H. schrieb:
> Simon Budig schrieb:
>> _delay_ms() hat eine maximale Wartezeit von ein paar Millisekunden.
>
> Bist Du da sicher ?

Das gilt schon lange nicht mehr.
War früher mal so.

Hast Du einen PC greifbar, auf dem kein Windows 8 installiert ist?
Und besser auch keine 64-Bit Version. Unterstützt FLIP offiziell Win8??

Bernhard Spitzer schrieb:
> Hast Du einen PC greifbar, auf dem kein Windows 8 installiert ist?
> Und besser auch keine 64-Bit Version. Unterstützt FLIP offiziell Win8??

Hilft ihm das ? Die Device wird ja noch nicht mal Enumeriert.

Und ja, laut Atmel Website läuft Flip auch unter Win8.

Grüße
Andreas

>Hast Du einen PC greifbar, auf dem kein Windows 8 installiert ist?
>Und besser auch keine 64-Bit Version. Unterstützt FLIP offiziell Win8??

Es funktionierte ja unter Windows8 64bit schon.