Hi, hat jemand mit dem ATSAMD51 und AtmelStudio schonmal USB (CDC) zu laufen gebracht ? Die ATSAMD51 ist zwar relativ neu, ist aber im Atmel Studio nicht in einem neuen Projekt auswählbar, weil ASF3 ihn nicht unterstützt. Es wird nur noch Atmel Start (und ASF4) unterstützt. Wenn ich dort eine USB CDC Komponente einbinde, das ganze in Atmel Studio exportiere, kompilieren und laufen lasse wird am angeschlossenen PC auch ein virtueller COM Port erkannt, aber der funktioniert nicht. Man kann den Port mit keinem Terminal-Programm öffnen. Putty beendet sich einfach, Termite friert ein. Ich denke die Clock habe ich richtig, 48MHz für USB ansonsten funktioniert überhaupt nichts. Leider gibts überhaupt keine Beispiele mit dem SAMD5x und auch kein EvalBoard. Bei Microchip haben die Atmel-ICs wohl die niedrigste Prio.
Angehängte Dateien:
-
Image2.jpg
160 KB -
Image1.jpg
100 KB
Kann man die 48MHz für USB (DFLL48M) auch aus dem HF Quarz generieren? Ich frage das, weil z.B. beim LPC176x die PLL laut Manual nicht für USB freigegeben ist wenn sie aus'm 32kHz Uhrenquarz gespeisst wird. Zuviel Jitter da zu selten nachjustiert werden kann. Das muss für den 10 Jahre jüngeren ATSAMD51 natürlich nicht gelten (Handbuch/Errata Sheet hab ich nämlich nicht gelesen), und ein simples Software Problem ist hier auch gar nicht unwahrscheinlich. Ich sehe gelegentlich USB CDC Implementierungen die mit simplen "serial Line state" Settings aus dem Tritt kommen - da diese nicht oder nicht korrekt implementiert sind.
Hi Jim,
das habe ich auch probiert. Der DFLL48 braucht aber max 33kHz am
Eingang. Ich habe den 12Mhz in einem Clock generator runtergeteilt auf
23kHz, dann in den DFLL48 auf 48MHz. -> Gleiches Ergebnis.
Dann hab ich noch probiert die 12MHz durch die DPLL0 auf 48Mhz zu
bringen und die in CPU und USB zu verwenden. -> Dann wird garkein USB
Device mehr im PC erkannt ("... hat nicht ordnungsgemäß
funktioniert...).
Ohne die DFLL48 scheint USB garnicht zu laufen.
Ich habe auch schon probiert die CPU mit dem gleichen Takt oder 24MHz
laufen zu lassen, weil ich dachte dass es ein problem mit der
Syncronisierung sein könnte. Immer das gleiche.
Direkt nach dem Reset läuft der D51/E51 doch schon mit 48MHz aus der DFLL48M los, also für einen ersten Test könnte man das Clock-System auch ignorieren. Das geht dann vielleicht nur bei Raumtemperatur, aber das reicht ja fürs erste. Mit einer der beiden FDPLL200M kommt man mit einem 12MHz Quarz auch direkt auf 48MHz indem man den Vor-Teiler der PLL benutzt um erstmal auf 2MHz runter zu gehen, mehr als 3,2MHz vertragen die PLLs nämlich nicht. Diesen Vor-Teiler kann man nur im START nicht verwenden, den gibt es dort schlichtweg nicht.
Hi, danke für Eure Antworten ! Das Clock-System ignorieren habe ich auch jetzt probiert. Hab alles auskommentiert, das in den init-Routinen mit den Oszillatoren zu tun hatte. Dann läuft er tatsächlich mit 48MHz, USB wird erkannz, hängt genauso. Drum glaube ich mittlerweile nicht mehr dass das ein Problem mit dem Takt ist. Eher ein Bug im CDC Stack. Ich habe noch etwas herausgefunden : Wenn ich den COM-Port der im Windows angezeigt wird öffne (z.B. mit Putty) und etwas hinschicke, dann hängt Putty (zumindest bis ich den USB rausziehe oder den Debuggger stoppe). Wenn ich in dem Zustand den Debugger anhalte, hängt das Programm immer in dieser Funktion fest :
1 | static inline void hri_port_set_OUT_reg(const void *const hw, uint8_t submodule_index, hri_port_out_reg_t mask) |
2 | {
|
3 | ((Port *)hw)->Group[submodule_index].OUTSET.reg = mask; |
4 | }
|
Aber warum wird die immer wieder endlos aufgerufen ?
USBTreeView sagt :
1 | =========================== USB Port1 =========================== |
2 | |
3 | Connection Status : 0x01 (Device is connected) |
4 | Port Chain : 1-1 |
5 | Properties : 0x01 |
6 | IsUserConnectable : yes |
7 | PortIsDebugCapable : no |
8 | PortHasMultiCompanions : no |
9 | PortConnectorIsTypeC : no |
10 | ConnectionIndex : 1 |
11 | CompanionIndex : 0 |
12 | CompanionHubSymLnk : USB#ROOT_HUB30#4&11118949&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
|
13 | CompanionPortNumber : 13 |
14 | |
15 | ======================== USB Device ======================== |
16 | |
17 | +++++++++++++++++ Device Information ++++++++++++++++++ |
18 | Friendly Name : Serielles USB-Gerät (COM33) |
19 | Device Description : Serielles USB-Gerät |
20 | Device Path : \\?\usb#vid_03eb&pid_07ee#5&20dbd6ce&0&1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
|
21 | Device ID : USB\VID_03EB&PID_07EE\5&20DBD6CE&0&1 |
22 | Hardware IDs : USB\VID_03EB&PID_07EE&REV_0100 USB\VID_03EB&PID_07EE |
23 | Driver KeyName : {4d36e978-e325-11ce-bfc1-08002be10318}\0027 (GUID_DEVCLASS_PORTS)
|
24 | Driver : \SystemRoot\System32\drivers\usbser.sys (Version: 10.0.17763.1 Date: 2018-09-15) |
25 | Driver Inf : C:\WINDOWS\inf\usbser.inf |
26 | Legacy BusType : PNPBus |
27 | Class : Ports |
28 | Class GUID : {4d36e978-e325-11ce-bfc1-08002be10318} (GUID_DEVCLASS_PORTS)
|
29 | Interface GUID : {a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
|
30 | Service : usbser |
31 | Enumerator : USB |
32 | Location Info : Port_#0001.Hub_#0001 |
33 | Location IDs : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(1), ACPI(_SB_)#ACPI(PCI0)#ACPI(XHC_)#ACPI(RHUB)#ACPI(HS01) |
34 | Container ID : {178a2601-f375-11e9-9376-f8633f62fba0}
|
35 | Manufacturer Info : Microsoft |
36 | Capabilities : 0x84 (Removable, SurpriseRemovalOK) |
37 | Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER) |
38 | Problem Code : 0 |
39 | Power State : D0 (supported: D0, D3, wake from D0) |
40 | COM-Port : COM33 (\Device\USBSER000) |
41 | |
42 | +++++++++++++++++ Registry USB Flags +++++++++++++++++ |
43 | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\03EB07EE0100 |
44 | osvc : REG_BINARY 00 00 |
45 | |
46 | ---------------- Connection Information --------------- |
47 | Connection Index : 0x01 (1) |
48 | Connection Status : 0x01 (DeviceConnected) |
49 | Current Config Value : 0x01 |
50 | Device Address : 0x06 (6) |
51 | Is Hub : 0x00 (no) |
52 | Device Bus Speed : 0x01 (Full-Speed) |
53 | Number Of Open Pipes : 0x03 (3 pipes to data endpoints) |
54 | Pipe[0] : EndpointID=2 Direction=IN ScheduleOffset=0 Type=Interrupt |
55 | Pipe[1] : EndpointID=1 Direction=OUT ScheduleOffset=0 Type=Bulk |
56 | Pipe[2] : EndpointID=1 Direction=IN ScheduleOffset=0 Type=Bulk |
57 | Data (HexDump) : 01 00 00 00 12 01 00 02 02 00 00 40 EB 03 EE 07 ...........@.... |
58 | 00 01 01 02 00 01 01 01 00 06 00 03 00 00 00 01 ................ |
59 | 00 00 00 07 05 82 03 40 00 0A 00 00 00 00 07 05 .......@........ |
60 | 01 02 40 00 00 00 00 00 00 07 05 81 02 40 00 00 ..@..........@.. |
61 | 00 00 00 00 .... |
62 | |
63 | --------------- Connection Information V2 ------------- |
64 | Connection Index : 0x01 (1) |
65 | Length : 0x10 (16 bytes) |
66 | SupportedUsbProtocols : 0x03 |
67 | Usb110 : 1 (yes) |
68 | Usb200 : 1 (yes) |
69 | Usb300 : 0 (no) |
70 | ReservedMBZ : 0x00 |
71 | Flags : 0x00 |
72 | DevIsOpAtSsOrHigher : 0 (Is not operating at SuperSpeed or higher) |
73 | DevIsSsCapOrHigher : 0 (Is not SuperSpeed capable or higher) |
74 | DevIsOpAtSsPlusOrHigher : 0 (Is not operating at SuperSpeedPlus or higher) |
75 | DevIsSsPlusCapOrHigher : 0 (Is not SuperSpeedPlus capable or higher) |
76 | ReservedMBZ : 0x00 |
77 | Data (HexDump) : 01 00 00 00 10 00 00 00 03 00 00 00 00 00 00 00 ................ |
78 | |
79 | ---------------------- Device Descriptor ---------------------- |
80 | bLength : 0x12 (18 bytes) |
81 | bDescriptorType : 0x01 (Device Descriptor) |
82 | bcdUSB : 0x200 (USB Version 2.00) |
83 | bDeviceClass : 0x02 (Communications and CDC Control) |
84 | bDeviceSubClass : 0x00 |
85 | bDeviceProtocol : 0x00 (No class specific protocol required) |
86 | bMaxPacketSize0 : 0x40 (64 bytes) |
87 | idVendor : 0x03EB |
88 | idProduct : 0x07EE |
89 | bcdDevice : 0x0100 |
90 | iManufacturer : 0x01 (String Descriptor 1) |
91 | *!*ERROR String descriptor not found |
92 | iProduct : 0x02 (String Descriptor 2) |
93 | *!*ERROR String descriptor not found |
94 | iSerialNumber : 0x00 (No String Descriptor) |
95 | bNumConfigurations : 0x01 (1 Configuration) |
96 | Data (HexDump) : 12 01 00 02 02 00 00 40 EB 03 EE 07 00 01 01 02 .......@........ |
97 | 00 01 .. |
98 | |
99 | ------------------ Configuration Descriptor ------------------- |
100 | bLength : 0x09 (9 bytes) |
101 | bDescriptorType : 0x02 (Configuration Descriptor) |
102 | wTotalLength : 0x0043 (67 bytes) |
103 | bNumInterfaces : 0x02 (2 Interfaces) |
104 | bConfigurationValue : 0x01 (Configuration 1) |
105 | iConfiguration : 0x00 (No String Descriptor) |
106 | bmAttributes : 0x80 |
107 | D7: Reserved, set 1 : 0x01 |
108 | D6: Self Powered : 0x00 (no) |
109 | D5: Remote Wakeup : 0x00 (no) |
110 | D4..0: Reserved, set 0 : 0x00 |
111 | MaxPower : 0x32 (100 mA) |
112 | Data (HexDump) : 09 02 43 00 02 01 00 80 32 09 04 00 00 01 02 02 ..C.....2....... |
113 | 00 00 05 24 00 01 10 05 24 01 01 00 04 24 02 02 ...$....$....$.. |
114 | 05 24 06 00 01 07 05 82 03 40 00 0A 09 04 01 00 .$.......@...... |
115 | 02 0A 00 00 00 07 05 01 02 40 00 00 07 05 81 02 .........@...... |
116 | 40 00 00 @.. |
117 | |
118 | ---------------- Interface Descriptor ----------------- |
119 | bLength : 0x09 (9 bytes) |
120 | bDescriptorType : 0x04 (Interface Descriptor) |
121 | bInterfaceNumber : 0x00 |
122 | bAlternateSetting : 0x00 |
123 | bNumEndpoints : 0x01 (1 Endpoint) |
124 | bInterfaceClass : 0x02 (Communications and CDC Control) |
125 | bInterfaceSubClass : 0x02 (Abstract Control Model) |
126 | bInterfaceProtocol : 0x00 (No class specific protocol required) |
127 | iInterface : 0x00 (No String Descriptor) |
128 | Data (HexDump) : 09 04 00 00 01 02 02 00 00 ......... |
129 | |
130 | -------------- CDC Interface Descriptor --------------- |
131 | bFunctionLength : 0x05 (5 bytes) |
132 | bDescriptorType : 0x24 (Interface) |
133 | bDescriptorSubType : 0x00 (Header Functional Descriptor) |
134 | bcdCDC : 0x1001 (CDC Version 10.01) |
135 | Data (HexDump) : 05 24 00 01 10 .$... |
136 | |
137 | -------------- CDC Interface Descriptor --------------- |
138 | bFunctionLength : 0x05 (5 bytes) |
139 | bDescriptorType : 0x24 (Interface) |
140 | bDescriptorSubType : 0x01 (Call Management Functional Descriptor) |
141 | bmCapabilities : 0x01 |
142 | D7..2: : 0x00 (Reserved) |
143 | D1 : : 0x00 (sends/receives call management information only over the Communication Class interface) |
144 | D0 : : 0x01 (handles call management itself) |
145 | bDataInterface : 0x00 |
146 | Data (HexDump) : 05 24 01 01 00 .$... |
147 | |
148 | -------------- CDC Interface Descriptor --------------- |
149 | bFunctionLength : 0x04 (4 bytes) |
150 | bDescriptorType : 0x24 (Interface) |
151 | bDescriptorSubType : 0x02 (Abstract Control Management Functional Descriptor) |
152 | bmCapabilities : 0x02 |
153 | D7..4: : 0x00 (Reserved) |
154 | D3 : : 0x00 (not supports the notification Network_Connection) |
155 | D2 : : 0x00 (not supports the request Send_Break) |
156 | D1 : : 0x01 (supports the request combination of Set_Line_Coding, Set_Control_Line_State, Get_Line_Coding, and the notification Serial_State) |
157 | D0 : : 0x00 (not supports the request combination of Set_Comm_Feature, Clear_Comm_Feature, and Get_Comm_Feature) |
158 | Data (HexDump) : 04 24 02 02 .$.. |
159 | |
160 | -------------- CDC Interface Descriptor --------------- |
161 | bFunctionLength : 0x05 (5 bytes) |
162 | bDescriptorType : 0x24 (Interface) |
163 | bDescriptorSubType : 0x06 (Union Functional Descriptor) |
164 | bControlInterface : 0x00 |
165 | bSubordinateInterface[0] : 0x01 |
166 | Data (HexDump) : 05 24 06 00 01 .$... |
167 | |
168 | ----------------- Endpoint Descriptor ----------------- |
169 | bLength : 0x07 (7 bytes) |
170 | bDescriptorType : 0x05 (Endpoint Descriptor) |
171 | bEndpointAddress : 0x82 (Direction=IN EndpointID=2) |
172 | bmAttributes : 0x03 (TransferType=Interrupt) |
173 | wMaxPacketSize : 0x0040 (64 bytes) |
174 | bInterval : 0x0A (10 ms) |
175 | Data (HexDump) : 07 05 82 03 40 00 0A ....@.. |
176 | |
177 | ---------------- Interface Descriptor ----------------- |
178 | bLength : 0x09 (9 bytes) |
179 | bDescriptorType : 0x04 (Interface Descriptor) |
180 | bInterfaceNumber : 0x01 |
181 | bAlternateSetting : 0x00 |
182 | bNumEndpoints : 0x02 (2 Endpoints) |
183 | bInterfaceClass : 0x0A (CDC-Data) |
184 | bInterfaceSubClass : 0x00 |
185 | bInterfaceProtocol : 0x00 |
186 | iInterface : 0x00 (No String Descriptor) |
187 | Data (HexDump) : 09 04 01 00 02 0A 00 00 00 ......... |
188 | |
189 | ----------------- Endpoint Descriptor ----------------- |
190 | bLength : 0x07 (7 bytes) |
191 | bDescriptorType : 0x05 (Endpoint Descriptor) |
192 | bEndpointAddress : 0x01 (Direction=OUT EndpointID=1) |
193 | bmAttributes : 0x02 (TransferType=Bulk) |
194 | wMaxPacketSize : 0x0040 (64 bytes) |
195 | bInterval : 0x00 (ignored) |
196 | Data (HexDump) : 07 05 01 02 40 00 00 ....@.. |
197 | |
198 | ----------------- Endpoint Descriptor ----------------- |
199 | bLength : 0x07 (7 bytes) |
200 | bDescriptorType : 0x05 (Endpoint Descriptor) |
201 | bEndpointAddress : 0x81 (Direction=IN EndpointID=1) |
202 | bmAttributes : 0x02 (TransferType=Bulk) |
203 | wMaxPacketSize : 0x0040 (64 bytes) |
204 | bInterval : 0x00 (ignored) |
205 | Data (HexDump) : 07 05 81 02 40 00 00 ....@.. |
206 | |
207 | ----------------- Device Qualifier Descriptor ----------------- |
208 | Error : ERROR_OPERATION_ABORTED |
209 | |
210 | -------------------- String Descriptors ------------------- |
211 | none |
Was soll bcdCDC = 10.01 sein? USB ist LSB First. Der Deskriptor ist falsch. Das soll wohl 1.10 sein. Bytes vertauscht. Wenn kein Strings Support vorhanden ist sollte die StrId auf 0 gesetzt werden. Thomas
Hi, Stimmt, das steht in der cdcdf_acm_desc.h, die Atmel Start exprtiert hat in Zeile 82 falsch drin. Ich habe dort USB_CDC_HDR_DESC_BYTES(0x1001) durch USB_CDC_HDR_DESC_BYTES(0x0110) ersetzt, jetzt stehts auch im USBTreeView :
1 | bcdCDC : 0x110 (CDC Version 1.10) |
Jetzt hab ich auch noch Strings eingestellt, ändert aber alles nichts am Verhalten.
Der D51 ist auch im ASF4 nicht voll unterstützt. Die höchste HAL Schicht fehlt komplett, zumindest Stand vor 6 Monaten. Laut den Microchip Leuten wird das auf MPLABX umgezogen. Ich bin dann zu STM gegangen. Die kack AtmelStart Website ist von allen vergleichbaren Tools (CubeMX etc.) die schlechteste. Vom Preis/Leistung scheint der SAMD5x aber unschlagbar. Es gibt übrigens von Adafruit praktische Evalboards mit dem D51.
Mike T. schrieb: > Jetzt hab ich auch noch Strings eingestellt, ändert aber alles nichts am > Verhalten Das habe ich auch nicht erwartet. Ist mehr ein formales Ding. Ich bin mir nicht 100% sicher aber ich glaube CDC fordert Compount Descriptoren. Zumindest steht es so in USB Complete von Jan Axelson. Ich würde deshalb bcdUSB auch auf 1.1 setzen. Dann sind die Compount Descriptoren auf jedenfall nicht notwendig. Da dein Chip vermutlich sowieso nur Fullspeed kann ist 2.0 nicht notwendig. Thomas
Jep, aber in MPlab (Harmony3) funktionierts auch nicht richtig. Das Adafruit-Teil hab ich schon gesehen. Leider nur für Arduino und µPhython und beides ist für meine Aufgabe nicht geeignet. Habe von denen aber z.B. den Bootloader bei mir Flashen können, daher weiß ich, dass meine USB zumindest hardwaremäßig ok sind.
Dein USB funktioniert sonst würdest du nichts in UsbView sehen. Der nächste Schritt wäre jetzt die Control requests näher anzuschauen. Du sagst ja dass SetLineCoding usw supported wird. Thomas
d511 schrieb: > Laut den Microchip Leuten wird das auf MPLABX umgezogen. Hmm, okay, dann werde ich mit dem E51 wohl eher kein USB machen.
Rudolph schrieb: > d511 schrieb: >> Laut den Microchip Leuten wird das auf MPLABX umgezogen. > > Hmm, okay, dann werde ich mit dem E51 wohl eher kein USB machen. Beim E51 müsste das eigentlich alles sehr ähnlich sein. Im MPLab hab ich aber schonmal das Problem, dass der Atmel-ICE zwar erkannt wird, aber als noch nicht richtig unterstützt nicht auswählbar anzeigt. Zudem stürzte das Harmony-Fenster mit irgendeiner Filenotfound-Meldung ab, als ich das Projekt öffnen wollte.
Mike T. schrieb: > Im MPLab hab ich aber schonmal das Problem, dass der Atmel-ICE zwar > erkannt wird, aber als noch nicht richtig unterstützt nicht auswählbar anzeigt. Und ich habe keinen Bock für MPLAB-X meine Projekte zu portieren, nur weil irgendeinen Witzbold bei Microchip auf die Idee gekommen ist die Includes komplett über den Haufen zu werfen - und zwar ohne erkennbaren Mehrwert. Wenn ich für USB mit dem E51 quasi zwangsläufig MPLAB-X benötige, dann eben kein USB, zumal ja nicht mal ansatzweise abzusehen ist, wann der ATSAM Support im MPLAB-X überhaupt halbwegs funktioniert. Andere Hersteller werden schon noch mit vergleichbaren Automotive Controllern auf den Markt kommen die CAN-FD unterstützen, wenn Microchip schon nichts besseres zu tun hat als die Kunden zu vergraulen. Und da graust es mir vor allem auch vor den XC Compilern die kostenlos kastriert sind und nicht gewerblich genutzt werden dürfen. Wer weiss schon, wie lange man die Atmel-Studio GCCs noch mit MPLAB-X benutzen kann...
Hey, gerade habe ich mehr durch Zufall noch etwas herausgefunden : Wenn ich das USB-Kabel an einen anderen Port am Rechner anstecke (der virtuelle COM-Port bekommt dann eine andere Nummer), dann funktioniert es. Das Echo-Beispiel schickt dann das gesendete zurück. Nach Reset oder an. und ausstecken am selben Port geht es wieder nicht mehr. Erst wenn man wieder in einen anderen Port geht es wieder ein mal. Die Platine wird vom USB versorgt, wird also genauso resettet egal ob es ein anderer oder gleiche USB-Port ist, also was ist dann der Unterschied ?
Das ist ganz einfach es funktioniert nur genau einmal wenn der Treiber neu installiert wird deine Requests sind am A... Bau ordentliche Funktionen für Set/GetLineCoding ein und es wird immer gehen. Nähere Infos findest du in der CDC Spec die übrigens bei 1.2 steht. Thomas
:
Bearbeitet durch User
Thomas Z. schrieb: > Das ist ganz einfach es funktioniert nur genau einmal wenn der Treiber > neu installiert wird deine Requests sind am A... Bau ordentliche > Funktionen für Set/GetLineCoding ein und es wird immer gehen. > Nähere Infos findest du in der CDC Spec die übrigens bei 1.2 steht. > > Thomas Genau um so etwas nicht machen zu müssen gibt es ASF.
Mike T. schrieb: > Genau um so etwas nicht machen zu müssen gibt es ASF. Gut hilft dem TO aber nicht da dieses ASF ja bei ihm nicht Out of the Box funktioniert. Ich kenn das Verhalten was der TO beschreibt, von unvollständigen CDC Implementierungen. Thomas
Thomas Z. schrieb: > Gut hilft dem TO aber nicht da dieses ASF ja bei ihm nicht Out of the > Box funktioniert. Ja, aber der Hinweis auf eine 120seitige Spec mit 12 Seiten Errata hilft ebenso wenig. Denn damit den Fehler in dem verschachtetel Atmel-Quellcode zu finden ist hoffnungslos.
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.