Page 1 of 2
Atmega16+32 not found with 16MHz crystal on some Hosts
Posted: Sat Dec 15, 2007 12:29 am
by andy
Hi,
first: Thank you for your work.
I have several devices with your software usb implementation and tried them on several hosts with windows, debian lenny and ubuntu.
Toshiba Laptop USB1.1 controller: Laptop1
Gericom Laptop(ohci) USB1.1 controller: Laptop2
Dell Laptop(ohci) USB2.0: Laptop3
HP Laptop(ohci) USB1.1: Laptop4
Siemens Desktop PC (uhci) USB2.0: PC1
PC with ASRock Board: PC2
Medion PC: PC3
Siemens Fujitsu: PC4
3 AVR devices:
ATMega48 with 12MHz crystal, bus powered: AT48
Atmega16, 16MHz crystal, bus powered: AT16
Atmega32, 16MHz crystal, self powered: AT32
If they fail, ohci or uhci returns error -62(timeout)
Laptop1: AT48 (OK), AT16(OK), AT32(OK)
Laptop2: AT48 (OK), AT16(FAIL), AT32(FAIL)
Laptop3: AT48 (OK), AT16(OK), AT32(OK)
Laptop4: AT48 (OK), AT16(OK), AT32(OK)
PC1: AT48 (OK), AT16(OK), AT32(OK)
PC2: AT48 (OK), AT16(OK), AT32(OK)
PC3: AT48 (OK), AT16(FAIL), AT32(FAIL)
PC4: AT48 (OK), AT16(OK), AT32(OK)
So, any hints?
I can get the USB controllers data on monday if needed. How can I track down the problem? Could it helpt if I sample the data lines with DSO on the non working devices?
Best regards, Andy
Posted: Sun Dec 16, 2007 1:39 pm
by andy
addendum:
the atmega32 runns with 12MHz crystal (and edited usbconfig.h) on those hosts which fails before with 16MHz.
Infos for PC2(works with 16MHz), PC3(fails with 16MHz) and Laptop2(fails with 16MHz)
=== PC2 ===
lspci -v:
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: ASRock Incorporation K7VT6
Flags: bus master, medium devsel, latency 32, IRQ 17
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI])
Subsystem: ASRock Incorporation K7VT6 motherboard
Flags: bus master, medium devsel, latency 32, IRQ 17
Memory at dfffbe00 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
lsusb -v
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 2
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0300 lowspeed power
Port 2: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
=== PC3 ===
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. A7N8X Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 16
Memory at d8087000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. A7N8X Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 18
Memory at d8083000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0303 lowspeed power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0103 power enable connect
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
=== Laptop 2 ===
00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) (prog-if 10 [OHCI])
Subsystem: Silicon Integrated Systems [SiS] USB 1.0 Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
Memory at dffd0000 (32-bit, non-prefetchable) [size=4K]
00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) (prog-if 10 [OHCI])
Subsystem: Silicon Integrated Systems [SiS] Onboard USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 11
Memory at dffe0000 (32-bit, non-prefetchable) [size=4K]
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0301 lowspeed power connect
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Posted: Thu Dec 20, 2007 7:45 am
by andy
addendum 2:
All AVR Boards runs with a 12MHz Crystal on all USB Host Controllers with fails with 16MHz before. So I think there are timing problems which were accepted by some host controllers but some don't.
So any hints how i can track down the problem with the 16MHz implementation?
Best regards, Andreas Weber
Posted: Sat Dec 22, 2007 11:06 am
by gert
Andy,
I don't expect a problem with the 16MHz code. Did you test the crystal oscillator's frequency stability of the device that doesn't work?
Hint: if you don't have a precision counter, try beat counting. Create a fixed frequency output signal from the device in question and compare it with one from a good device. Wired AND should do the job.
Cheers
Gert
Posted: Sat Dec 22, 2007 4:29 pm
by andy
gert wrote:Did you test the crystal oscillator's frequency stability of the device that doesn't work?
Hi Gerd, not yet. And I can't do that this year...
I want to clear the problem:
I have several devices (Atmega32, Atmega16, AttinyXX) with 12MHz which runs with ALL tested hosts.
If I replace the 12MHz crystal with a 16MHz on and change the code, these devices runs on 18 from 20 tested hosts.
I think it could be a timing problem and some hosts are tolerant, others not...
Best regards, Andy
Posted: Sat Dec 22, 2007 7:56 pm
by christian
Yes, this is very likely a timing problem in the code. Since I have not been able to reproduce the problem here, it's very hard to figure out what it is and how to fix it.
The 16 MHz timing is a bit critical since 16 is not a multiple of 1.5. We have to insert leap cycles every now and then.
To debug the issue, please enable debugging (compile with "DDEBUG_LEVEL=2" and attach a terminal to the serial line) and check whether all data is received and the data is received correctly. I would expect a timing problem in the receiver loop.
The transmitter loop, on the other hand, sends data slightly off the required bit rate. The deviation is within the specified tolerance of 1.5%, we send 0.4% too fast. This MUST be tolerated by the host controller.
If all data is received correctly, then it's better to look for a problem in the transmitter loop.
If you have any infromation, please contact me at the support e-mail address. I'd really like to fix this issue.
Posted: Sun Dec 23, 2007 3:21 pm
by andy
christian wrote:To debug the issue, please enable debugging (compile with "DDEBUG_LEVEL=2" and attach a terminal to the serial line) and check whether all data is received and the data is received correctly. I would expect a timing problem in the receiver loop.
Hi Christian,
I made to logs with 16MHz Crystal.
Plug in the device:
Code: Select all
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 80 06 00 01 00 00 40 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
20: c3 c0 16 dc 05 00 01 01 02 ca a8
20: 4b 00 01 3f 8f
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 00 05 1c 00 00 00 00 00
20: 4b 00 00
12: 80 06 00 01 00 00 12 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
20: c3 c0 16 dc 05 00 01 01 02 ca a8
20: 4b 00 01 3f 8f
12: 80 06 00 02 00 00 09 00
20: 4b 09 02 12 00 01 01 00 80 0e b0
20: c3 64 41 54
12: 80 06 00 02 00 00 12 00
20: 4b 09 02 12 00 01 01 00 80 0e b0
20: c3 64 09 04 00 00 00 00 00 20 ab
20: 4b 00 00 fe 4f
12: 80 06 00 03 00 00 ff 00
20: 4b 04 03 09 04 09 78
12: 80 06 02 03 09 04 ff 00
20: 4b 12 03 4d 00 4b 00 5f 00 2d e8
20: c3 42 00 6f 00 61 00 72 00 08 1e
20: 4b 64 00 d4 8f
12: 80 06 01 03 09 04 ff 00
20: 4b 1a 03 77 00 77 00 77 00 3b 44
20: c3 2e 00 6f 00 62 00 64 00 00 47
20: 4b 65 00 76 00 2e 00 61 00 52 0d
20: c3 74 00 d9 4f
12: 00 09 01 00 00 00 00 00
20: 4b 00 00
dmesg output: usb 2-2: new low speed USB device using uhci_hcd and address 29
usb 2-2: configuration #1 chosen from 1 choice
Plug the device to not working host 2:
Code: Select all
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 80 06 00 01 00 00 40 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
20: c3 c0 16 dc 05 00 01 01 02 ca a8
20: 4b 00 01 3f 8f
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 00 05 03 00 00 00 00 00
20: 4b 00 00
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 80 06 00 01 00 00 40 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
20: c3 c0 16 dc 05 00 01 01 02 ca a8
ff:
20: 4b 00 01 3f 8f
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 00 05 04 00 00 00 00 00
20: 4b 00 00
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 00 05 05 00 00 00 00 00
20: 4b 00 00
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 00 05 06 00 00 00 00 00
20: 4b 00 00
dmesg output:
Code: Select all
usb 1-1: new low speed USB device using ohci_hcd and address 3
usb 1-1: device not accepting address 3, error -62
usb 1-1: new low speed USB device using ohci_hcd and address 4
usb 1-1: device not accepting address 4, error -62
usb 1-1: new low speed USB device using ohci_hcd and address 5
usb 1-1: device not accepting address 5, error -62
usb 1-1: new low speed USB device using ohci_hcd and address 6
usb 1-1: device not accepting address 6, error -62
Posted: Sun Dec 23, 2007 5:42 pm
by christian
It looks as if the host does not understand the data sent by the device. I have re-arranged the instructions a bit to give a more evenly distribution of leap bits. I'll send you the modified driver to your e-mail address. Please check this one out...
Posted: Fri Dec 28, 2007 8:05 pm
by Guest
christian wrote:It looks as if the host does not understand the data sent by the device. I have re-arranged the instructions a bit to give a more evenly distribution of leap bits. I'll send you the modified driver to your e-mail address. Please check this one out...
Hi Christian!
I can confirm now, that 12MHz works with two (different) PC's where 16MHz variant did not work (I was wondering what is wrong all the time...). If You need some testing of some new code, please, send an email to butrus doot butrus aat gmail ddot com.
Posted: Fri Dec 28, 2007 8:13 pm
by christian
It looks as if the modified code does not change anything. If you have a storage scope or a logic analyzer to caputure the failing communication, I'd be very curious to analyze it.
Re: Atmega16+32 not found with 16MHz crystal on some Hosts
Posted: Wed Jan 02, 2008 5:46 pm
by Phoenix
andy wrote:Hi,
first: Thank you for your work.
I have several devices with your software usb implementation and tried them on several hosts with windows, debian lenny and ubuntu.
Toshiba Laptop USB1.1 controller: Laptop1
Gericom Laptop(ohci) USB1.1 controller: Laptop2
Dell Laptop(ohci) USB2.0: Laptop3
HP Laptop(ohci) USB1.1: Laptop4
Siemens Desktop PC (uhci) USB2.0: PC1
PC with ASRock Board: PC2
Medion PC: PC3
Siemens Fujitsu: PC4
3 AVR devices:
ATMega48 with 12MHz crystal, bus powered: AT48
Atmega16, 16MHz crystal, bus powered: AT16
Atmega32, 16MHz crystal, self powered: AT32
If they fail, ohci or uhci returns error -62(timeout)
Laptop1: AT48 (OK), AT16(OK), AT32(OK)
Laptop2: AT48 (OK), AT16(FAIL), AT32(FAIL)
Laptop3: AT48 (OK), AT16(OK), AT32(OK)
Laptop4: AT48 (OK), AT16(OK), AT32(OK)
PC1: AT48 (OK), AT16(OK), AT32(OK)
PC2: AT48 (OK), AT16(OK), AT32(OK)
PC3: AT48 (OK), AT16(FAIL), AT32(FAIL)
PC4: AT48 (OK), AT16(OK), AT32(OK)
So, any hints?
I can get the USB controllers data on monday if needed. How can I track down the problem? Could it helpt if I sample the data lines with DSO on the non working devices?
Best regards, Andy
Can you help me with my project? Because I don't really know how to ajust the settings.
Posted: Tue Feb 05, 2008 8:54 pm
by christian
It turned out that there was a copy/paste bug in the 15 and 16 MHz modules. This bug affected device enumeration depending on the USB timing.
Please get at least version 2008-02-05 of PowerSwitch for the latest release of AVR-USB which fixes this issue.
Posted: Sat Feb 16, 2008 8:01 pm
by MrRotzi
Hi and thanks a lot for this great projects!!
I downloaded latest version of powerswitch 2008-02-05
compiled it with debug_level 2 and receive also just this:
12: 80 06 00 01 00 00 40 00f:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 80 06 00 01 00 00 40 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
ff:
12: 80 06 00 01 00 00 40 00
20: 4b 12 01 10 01 ff 00 00 08 21 63
I have here an Atmega128 with 16MHz
Have you any ideas how to solve this problem?
best regards
Posted: Mon Feb 18, 2008 2:26 pm
by christian
This log means that:
(1) The host does a USB reset after connecting.
(2) The host requests the device descriptor.
(3) AVR-USB responds with the first 8 bytes
Then it starts over again. I can't see a reason why the host does not continue requesting the rest of the device descriptor. It does not even reach the critical "set address" phase.
Did you try this with a different clock rate, e.g. 12 MHz?
Posted: Mon Feb 18, 2008 2:37 pm
by Guest
Unfortunately I have no crystal with 12MHz clock rate ...
I orderd some today and as soon as they are in my hands
I can try it again!
I'll let you know!