Atmega16+32 not found with 16MHz crystal on some Hosts

andy · Post by **andy** » Sat Dec 15, 2007 12:29 am

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

andy · Post by **andy** » Sun Dec 16, 2007 1:39 pm

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

andy · Post by **andy** » Thu Dec 20, 2007 7:45 am

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

gert · Post by **gert** » Sat Dec 22, 2007 11:06 am

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

andy · Post by **andy** » Sat Dec 22, 2007 4:29 pm

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

Post by **christian** » Sat Dec 22, 2007 7:56 pm

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.

andy · Post by **andy** » Sun Dec 23, 2007 3:21 pm

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

Post by **christian** » Sun Dec 23, 2007 5:42 pm

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...

Guest · Post by **Guest** » Fri Dec 28, 2007 8:05 pm

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.

Post by **christian** » Fri Dec 28, 2007 8:13 pm

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.

Phoenix · Post by **Phoenix** » Wed Jan 02, 2008 5:46 pm

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.

Post by **christian** » Tue Feb 05, 2008 8:54 pm

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.

MrRotzi · Post by **MrRotzi** » Sat Feb 16, 2008 8:01 pm

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

Post by **christian** » Mon Feb 18, 2008 2:26 pm

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?

Guest · Post by **Guest** » Mon Feb 18, 2008 2:37 pm

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!

Objective Development Forums

Atmega16+32 not found with 16MHz crystal on some Hosts

Atmega16+32 not found with 16MHz crystal on some Hosts

Re: Atmega16+32 not found with 16MHz crystal on some Hosts