Hi!
I can't get connection to AVR-USB-162 with LUFA (090605) CDC or Olimex demo program. Looks like AVR hangs after "USB handshaking". I don't have debugger, but I have a task registered which blinks led and it stops blinking.
Does someone have 100% working CDC source for testing or any ideas why it doesn't work?
Looks like it hangs to
Endpoint_SelectEndpoint(CDC_RX_EPNUM);
Try the latest SVN version of LUFA, or this alpha version:
http://myusb-support-list.google...
Which should clear up any problems you have. Don't forget to change the makefile settings to build for the right device.
- Dean :twisted:
It didn't help.. with this version Windows can't open USB virtual serial port.
Ah! Looks like "lowlevel" version works - "ClassDriver" still fails.
Did you make sure to recompile and test the ClassDriver demo? You might just have a COM port conflict. I've just done my own sanity test and the ClassDriver CDC demo works fine on my at90usb162 based board running at 8MHz.
- Dean :twisted:
Yes, I made clean build. It can't be com port conflict because lowlevel demo works with same port?
Found also that CDC_putchar doesn't work in lowlevel demo. Endpoint_IsReadWriteAllowed() returns false for minute or so and serial port can't be opened in windows (hang in AVR?).
Could you post more about your environment please? The code works on my Vista and Ubuntu systems -- in fact, it works using standard streams in the ClassDriver CDC example.
I need the following information:
1) OS
2) Exact code tested (if changed from the standard examples in any way)
3) Any changes to the makefile you have made
I don't doubt you're having problems, I just can't replicate them (yet).
- Dean :twisted:
Here is lowlevel version which works fine until I enable CDC_putchar call in main().
And tested in Windows XP.
Looks like windows can't open serial port before AVR has sen't at least one byte?
Windows should be able to open the port up just fine, when nothing has been sent -- the port open request is entirely separate to the Tx/Rx logic. I've not seen this issue myself yet, but I'll do some more tests on Wednesday when I have the day off to see if I can get the same symptoms on my XP SP3 machine.
In the meantime, could you re-test with the Beta 2 release please:
http://myusb-support-list.google...
As many core code changes have been made since the 21st of last month.
- Dean :twisted:
Beta 2 didn't solve the problem..
Problem must have something to do with USB handshaking. If I don't send any bytes, AVR doesn't hang and Windows is able to open serial port.
btw, What timers does LUFA use?
Problem must have something to do with USB handshaking. If I don't send any bytes, AVR doesn't hang and Windows is able to open serial port.
Ah, so it hangs only if you DO send bytes before the port is fully open? I was confused by this:
Looks like windows can't open serial port before AVR has sen't at least one byte?
Which seemed to indicate that you HAD to send at least one byte for the port to open. I'll try this tonight, making a minimal test case which just spams the endpoint to see if I can get it to fail. Never fear, I'll have this sorted out in no time.
btw, What timers does LUFA use?
None, other than any in each individual demo. Rather, the user needs to call the USB service task themselves by their own mechanism periodically (within 100ms or so) to service any waiting USB control transactions. Asynchronous events such as device disconnects are handled by the general USB ISR which only fires in response to a hardware change.
- Dean :twisted:
Uh.. AVR is acting little bit odd. :)
I had another program which had input capture enabled and interrupt service routine for it and for overflow. In that application CDC serial port windows coulnd't open before one byte was sent. Also if I didn't enable interrupts, everything did work fine? Sometimes serial port also wake up after one input capture event..?
Attached source for that application (it is your lowlevel demo + my input capture routine).
Try the latest SVN revision, I've just synched up a corrected revision. It turns out that the host doesn't like the device sending *anything* until it has set the line encoding explicitly for the first time. The solution is then simple - just discard all data to send until the Line Encoding parameters are set by the host.
Just tried it on my Vista machine with a program that just continuously tried to send data to the host. Before, I was unable to open the port but after applying the latest patch I can receive the data with no problems.
- Dean :twisted:
Hmm... What am I missing... I can't compile DualCDC or CDC demos:
make: *** No rule to make target `DualCDC.elf', needed by `elf'. Stop.
I can't see any error in makefile?
Found another bug with latest svn. If I open serial port in windows, for example with putty, and I reset AVR (putty has port reserved), I can't reopen serial port without closing putty first and then resetting AVR.
Found another bug with latest svn. If I open serial port in windows, for example with putty, and I reset AVR (putty has port reserved), I can't reopen serial port without closing putty first and then resetting AVR.
I don't think that's a bug with LUFA, but rather Windows, since it's COM port system was never really designed to support hot-pluggable ports. It doesn't like ports to disappear with references to them still active.
Your shouldn't get any compile errors with the latest SVN revision (R719) - I just checked. That error indicates that a file referenced in the makefile can't be found, which usually means using an old LUFA makefile with a newer LUFA version where an internal file has moved.
- Dean :twisted:
Found also, that if I close serial port AVR will hang..
Found also, that if I close serial port AVR will hang..
Thanks for sticking with me while I try to fix all these problems -- I haven't run into them before because I haven't been trying to continuously stream CDC data to a host.
Try the latest SVN revision, which should fix the lockup issue when closing active ports.
- Dean :twisted:
Tested latest LUFA (091122) DualCDC demos. For some reason it doesnt work. Not lowlevel or classdevice. Windows reports problems with driver (code 10).
Last event is EVENT_USB_Device_Disconnect() so PC seems to be disconnecting LUFA?
