PDA

View Full Version : No Wake From LAN when teensy 2.0 (usb midi mode) is plugged in



yeahtuna
06-04-2013, 09:03 AM
My Wake From LAN does not function when my Teensy 2.0 is connected before I shutdown my computer. If I disconnect the Teensy before shutting down, everything works fine. Any idea what might be causing this?

Rob.

Windows 7 x64

PaulStoffregen
06-04-2013, 03:48 PM
I've never heard of this problem before.

What type of device did you program the Teensy 2.0 to become (eg, the Tools > USB Type menu)?

Is the LAN wakeup done from a USB network adaptor, or a normal Ethernet port that's not at all related to USB?

yeahtuna
06-04-2013, 04:05 PM
I've never heard of this problem before.

What type of device did you program the Teensy 2.0 to become (eg, the Tools > USB Type menu)?

Is the LAN wakeup done from a USB network adaptor, or a normal Ethernet port that's not at all related to USB?

I've programmed it to be a USB MIDI Device. I'll try some other types to see if that makes a deference. It's done via a normal Ethernet port. I tried disabling 'Allow windows to turn off the device to save power' for the Root USB Hub but that made no difference.

Rob

yeahtuna
06-05-2013, 05:42 AM
I changed the type to Raw HID and had the same results, namely the system could not be started using WOL. As another test, I shut down the system with my BCR2000 (USB MIDI Device) plugged in and the system was able to start via WOL without problem.

Regards,
Rob

yeahtuna
06-05-2013, 02:26 PM
I've tried different USB ports, disabing the device and uninstalling the driver all to no avail. If the teensy is plugged in when I shutdown my system , it is unable to be started using Wake On Lan. Any suggestions as to what I might try next? Is the issue with the loader program?

Rob

PaulStoffregen
06-05-2013, 09:05 PM
Could you try changing the "bmAttributes" in the config descriptor in usb.c?

Currently it's this:



0xC0, // bmAttributes


Here's the USB spec's documentation for bmAttributes:



Configuration characteristics
D7: Reserved (set to one)
D6: Self-powered
D5: Remote Wakeup
D4...0: Reserved (reset to zero)
D7 is reserved and must be set to one for
historical reasons.
A device configuration that uses power from
the bus and a local source reports a non-zero
value in bMaxPower to indicate the amount of
bus power required and sets D6. The actual
power source at runtime may be determined
using the GetStatus(DEVICE) request (see
Section 9.4.5).
If a device configuration supports remote
wakeup, D5 is set to one.


To be honest, this is really just a blind guess. Turning the "self powered" bit off would be the first thing to try. If you set the remote wakeup, I believe some other stuff is supposed to be implemented (which isn't anywhere in the code). But it might be worth a shot to just try the other 3 combinations of those 2 bits and see if it makes any difference?

PaulStoffregen
06-05-2013, 09:13 PM
Windows caches USB descriptors in the Windows Registry. Each time you make a change, increase the bcdDevice number in the device descriptor. That tells Windows it's a new version of the product and the old descriptors do not necessarily apply.

yeahtuna
06-06-2013, 12:35 AM
I tried switching those bits but no glory. I also noticed that the BCR2000 is using a Berhinger supplied driver. I also tested using a UC33 using the windows driver and sure enough, like the Teensy, when the UC33 was plugged in, the sytstem could not be started using WOL. I suspect the issue is with the windows driver. Would there be anyway to use that Berhinger driver for the teensy?

My motherboard supplies power to USB devices after shutdown and there doesn't appear to be anyway to change that. Another sollution might try to get a USB add-on board to get around that.

Regards,
Rob

yeahtuna
06-06-2013, 09:24 AM
Some more interesting results. I switched over the BCR2000 to the Windows MIDI driver and it WOL worked! So I'm hopeful for a resolution to this issue. Where might I poke around in Windows to determine the difference in how the BCR and teensy are interfacing with Windows?

PaulStoffregen
06-06-2013, 10:12 AM
Is there some way you can capture the USB descriptor data from that device?

Usually I use a Beagle protocol analyzer from Total Phase, but that's an expensive hardware device almost nobody has. On the Mac, Apple's X-code development tools (free download but registration req'd) has a utility called USB Prober which does an excellent job of capturing all this info.

I really don't use Windows much, and when I troubleshoot USB problems on any operating system I always use the Beagle analyzer with a separate computer showing the results, so I'm just not familiar with what USB diagnostic utilities might be available. Maybe someone here will have a suggestion?

On Linux, you can use "lsusb -v" to get a lot of info, but not a full dump of the raw descriptor data. I don't even know if there's a way on Linux... I pretty much depend on that Beagle analyzer for these types of things.

yeahtuna
06-06-2013, 01:08 PM
I dual boot with a hackintosh and already have the development tools, so I'll give it a go on the weekend.

PaulStoffregen
06-06-2013, 06:59 PM
Great. Hopefully there will be some info or clue in BDR2000's descriptors?

yeahtuna
06-07-2013, 12:50 AM
Not as difficult as I thought. In Windows I used 30 day free app called USBlyzer. I started the capture and I restarted the BCR2000. I've attached what I got. It's actually an html file renamed to play friendly with your upload handler.

Regards,
Rob

yeahtuna
06-07-2013, 05:12 AM
I did one more test. I had another unused Teensy 2.0, so I plugged it in and it did it's blinking thing. I shutdown and was able to start the the system using WOL, so I'd say that's some more promising news.

yeahtuna
06-10-2013, 03:20 AM
No glory? I doubt it's a descriptor issue. I did hours of reading about descriptors and I can't see that being the issue. I suspect you would need a system with working 'wake on lan' and use that fancy hardware analyzer of yours to see how the operating system interacts with devices when it shuts down.

Regards,
Rob