Objective Development Forums

The fastest possible delay is 10 ms since this is the minimum poll interval for low speed USB devices on interrupt endpoints.

ad (1): I don't know AVR-Studio very well, but it might scan only to a maximum port number. Auto-detection takes some time to complete for each port and it may be unacceptable to scan for more than 6 ports. ad (2): These SHOULD be ground. However, since the signal rate allows a lower number of groun...

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

OK, this is a bug in all versions from 2007-12-01 to 2008-02-05. It will be fixed in all future versions. This bug affects the 16.5 MHz module only.

In reality, usbSofCount increments on every interrupt which can't be interpreted as the start of a valid USB message. If you wire the interrupt to USB D+, this is roughly every Start Of Frame. Otherwise it's just garbage.

It's not declared in the header, but you can access it if you declare it yourself as

extern uchar usbDeviceAddr;

First try various hosts. If it works on other hosts, you should add the zener diodes. You can probably do this yourself, it's not hard.

Since you say the device did work previously, the fuse values must be OK.

There was a restructuring between these versions where common parts of the assembler module were moved to a single file. I have overlooked that one register was different in the 16.5 MHz module. Can you contact me by e-mail (AVR-USB support address) so that I can send you a fixed version for testing?

It's hard to compare these versions because a lot of re-structuring occurred between them. But as far as I can see, none of the changes should affect the 16.5 MHz module. I currently don't have my EasyLogger board available, so I can't run my own tests. Can you please try the other releases between ...

Hmm... When enumeration succeeds, the host assigns an non-zero usbDeviceAddress. This is a global variable.

With usbSofCount you should be able to calibrate more efficiently, though.

Which version works and which does not? Maybe we have introduced a bug in one of the last changes...

"Unknown Device" usually means that you have no USB communication at all. Did you flash the fuse values correctly?

Can you try avrdude in verbose mode? It might give more information about what's going wrong.

There is a known problem with CDC mode on some machines. If there are communication errors, Windows may stall the endpoint and thus stop polling the device.

USB is a host driven serial bus. Real interrupts are therefore not possible, all interrupt-like semantics are implemented with polling. I don't understand why this change should break anything. There is no difference between interrupt- and bulk-endpoints in AVR-USB. Only the timing of the API calls ...

Just because it works with 12 MHz does not mean that the code does what it's intended to do. Many problems depend on tiny deviations in the timing.

BTW: 1400000 is an integer constant, it would be 1400000L otherwise. Do you get a compiler warning for this?