Hallo ich habe die Schaltung nach dem obigen Schaltplan aufgebaut, jedoch wenn ich den AT90usb162 an den USB-Port meines PCs anstecke, meldet er, dass das angesteckte USB-Gerät nicht erkannt werden konnte. Woran kann das liegen? Der Mikrocontroller sollte doch in den Bootloader starten und vom Computer erkannt werden. Bitte um eure Hilfe.
Angehängte Dateien:
-
at90usb.png
15 KB
Wird der µC mit Spannung Versorgt? Check ob alles da ist. An der Versorgungsspannung fehlt der 100nF Kondensator
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
Angehängte Dateien:
-
b.png
12 KB
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 ;-)
Angehängte Dateien:
-
log.jpg
300 KB
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
Angehängte Dateien:
-
schaltung.jpg
130 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.