No Wake From LAN when teensy 2.0 (usb midi mode) is plugged in

Y

yeahtuna

Well-known member
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
 
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?
 
PaulStoffregen said:
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?
Click to expand...

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
 
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
 
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
 
Could you try changing the "bmAttributes" in the config descriptor in usb.c?

Currently it's this:

Code: 
        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.
Click to expand...

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?
 
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.
 
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
 
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?
 
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.
 
I dual boot with a hackintosh and already have the development tools, so I'll give it a go on the weekend.
 
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
 

Attachments

  • test.txt
    43.1 KB · Views: 554
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.
 
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
 
You must log in or register to reply here.
Back
Top