USB device keyboard example not working

Hello Cobsonchel,

1. You don't need primus_platform.h for your development purpose because  it is already built & linked with the library.

2.  I will get back to you on this later.

The method to test sample application (DEV HID) is to press scroll lock key on keyboard & then you will get some text message on a notepad.

When you get such error messages, Try removing this device entries from registry of Windows on your PC.

Also, restart your board everytime, if you are switching between different device sample applications.

I suggest you to check other sample applications (DEV MSC) also.      

Regards

Prasad V Joshi

i understand how the keyboard project is supposed to work, my problem is that it won't work if windows doesn't load drivers for it.

I am weary of trying to delete things from the registry.  where do i go to delete them? is it absolutely necessary to do this?

why is it so important to reboot the board every time? does windows think it is the same device when the VBUS line is in use? does issuing a reset/restart not do this?

i tried the other example this morning, same results.

in the call to dsp_bios_entry in the keyboard dev example the code returns from that function to hit the while(1) loop.  is that supposed to happen? would the return value of dsp_bios_entry help identify the error? i have no idea because of the HORRIBLE documentation and comments this package has.

Yeah, BIOSUSB is pretty grim at times.

You should not have to mess with the registry directly. Usually uninstalling the it from the Device Manager is enough. You have to plug it in first. A "malfunctioning" device should still should still show up in the Device Manager. If it doesn't, you are stuck with registry hacking. When it is working, you should see two devices in the Device Manager. One under "Mice and other pointing devices" and the other under "Human Interface Devices".

To check how far the USB device got in installation, you can look at the the USB descriptors. Microsoft used to offer UVCView as a separate download. It's now bundled up in the DDK/WDK. Or try "Thesycon USB Descriptor Dumper" at:

http://www.thesycon.de/eng/usb_descriptordumper.shtml

I was wondering if something like that existed

here is the dump:

Information for device USB\Vendor_0000_Product_0000:

Connection Information:
------------------------------

Connection status: Device failed enumeration
Device actual bus speed: Low
Device is hub: No
Device adress: 0x0000
Current configuration value: 0x00
Number of open pipes: 0

Whole unknown Descriptor as hex dump:

Connectionpath for device:

Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller - 27CC
RootHub
USB\Vendor_0000_Product_0000

That doesn't look good...I seen that only when Windows utterly gives up loading the driver. I assume that you do not have anything in the Device Manager or have one of those big yellow question marks under "USB controllers".

I'm a FW guy. At this point, I'd be hassling the HW guys to look at the USB HW (clocks, voltages, etc).

You could also try a different port on your PC. Some PCs have more than one root hub. Windows might load the proper driver. It might also "poison" the registry for that port if the HW is at fault.

i didn't think it looked good either. i probed the USB_data+ and USB_data- lines coming out of the DSP

the green one is USB_data- and the purple is the Math subtraction

i took an AC coupled capture and a DC coupled capture just to be sure.

if these lines are differential it doesn't look like they are acting that way to me. any reason why the negative data line is basically spewing noise and that's it?

here is the DC capture

and lastly here is what we have for a schematic for the USB hardware. i thought one of us had it checked by TI but i can't be positive on that.

Hi Cobsonchael,

As you are facing device enumaration issue, checking only D+ and D- signals wont give you a full picture. Form outside, sample applications itself not working indicate there has to he some basic issue. As Norman Wong mentioned, did you try connecting to a different PC or different port in the PC? 

I am sure it is a basic issue.  i did try different USB ports, even a USB hub.  i get the same thing every time.  i don't suppose someone could tell me if the schematic is at least right.

Sure, Let me try to get it reviewed by a HW expert.

My experience is with the OMAP-L137 EVM (Spectrum Digital). Your schematic looks much the same as theirs. They don't seem to bother with the inductors to VBUS and the data lines are swapped on the TPDE002 (shouldn't matter?). Hawkboard is another implementation that you can compare against. Maybe you should post in the OMAPL1x subforum to get some HW eyes on your scope captures. The up side of the scope caps is that it shows the D+ is doing something which implies something in the processor is driving it. No question of MUX on that pin.

Last ditch on the software side, you can force full-speed mode in the HID example. I don't remember where in the code exactly and I not at my workstation to check. Easy enough to find.

I agree with Norman that the inductors don't need to be on the VBUS/GND connectors.

Also - the TPD2E001 has a few different packages to choose from, each with a slightly different pinout. I've made the mistake of using the wrong pinout in a board I did because I referred to the pinout for a different package that I was actually using. Not saying that you did the same, but its an easy mistake the make and a quick sanity check. Which package are you using?

the package we are using is

SOT-533

Thanks for the help BTW

I've been doing some reading on USB. This site dumbs it down enough for me to understand some of it.
 http://www.usbmadesimple.co.uk/ums_6.htm
At idle:
 Low speed: D+=0V, D-=3.3V, high=3.3V
 Full Speed: D+=3.3V, D-=0V, high=3.3V
 High Speed: D+=0V, D-=0V, high=0.4V
My guess at what is happening
- Host brings down D+ from 3V to 0V indicate a reset.
- Host releases D+ back to 3V
- Negotiation chirps at 0.8V not visible on capture.
- High speed traffic at 0.4V on D+ and D-
- Reset or suspend from high speed(0.4V) to full speed (3V) idle. This must be where the PC gave up talking to the device
The purple difference line doesn't look good when at high speed. There should be a 0.4V high fuzzy rectangle. Maybe the scopes sampling rate is too low?

It might give us a little more information if you could get a zoom of the D+/D- lines such that we could see if device is asserting the High Speed Chirp as Norman as suggested. It also might give us a clue as to what's actually happening.  Even if you could confirm that the D+/D- Lines are toggling at the 400 mV level or if they are toggling at a different voltage level would give us some more insight into the actual activity on the bus.