msp430 HID API windows for USB

Hi Seb,

The Windows-based HID API was replaced by the Java-based one, out of a desire to support platforms besides Windows.  I don't think the Windows one is still available, but I've forwarded this thread to the software team. 

You say 'unknown device' -- I assume you're talking about how it appears in the Windows Device Manager.  What hardware are you using?  (for example, F5529 LaunchPad, Experimenter's Board, "TS430" FET target board, or your own custom board)

And, are you using one of our HID MSP430 code examples exactly, and if so, which one?  Or is this your own software? 

If the PC is responding at all (which includes identifying it as an 'unknown device', showing a bubble in the system tray, etc.), this suggests that F5529 got as far as pulling the PUR/D+ high to alert the PC to your board's presence, but when Windows tried to pull information from your device, it didn't respond.  I'd first double-check that the software configuration for crystal frequency matches your hardware, since a mismatch would kill any data communication with the PC host.  The examples have this configured correctly for all TI-generated hardware, so I'd only expect this to be a problem if you're using your own hardware or software.

If that doesn't solve it, then my next suggestion would depend on answers to the questions above about what hardware/software you're using. 

Keith

Ok thanks for the fast reply, here some answers to Your questions:

I am using the MSP430F5529 in my own costum board, waiting also for an launchpad to arrive so I will have some more debug hardware avaiable soon, but right now only working with my costum board.

My board almost uses every single PIN and periphery of the MSP like GPIOs, SPI, I2C external crystals etc etc, so perhaps there might be an issue with some wrong send init-code form the TI-code.

edit#1: ok i did switch up settings for CDC and MSC config: now i got my 25 MHz inthose too and I did switch power supply to external, now all 3 examples do at least show an reaction:

HID MSC - unknown device - PUR is 3,3V

CDC - did get recognized in the device manager but i am unable to find it, perhaps missing driver for windows, me and my colleugues still dont know, but we are on the right track i think.

#define USB_MCLK_FREQ 25000000                // MCLK frequency of MCU, in Hz

#define USB_XT_FREQ       USBPLL_SETCLK_25_6         I dont know what this does, adn if its important to me

#define USB_SUPPORT_SELF_POWERED 0xc0

I did try every descriptor example: HID CDC MSC, did change the crystal setting for XT2 to my used 25 MHz, although I do not know what to tell the USB oscillator, I did put it down to some 1 MHz I think, in the descriptor program.

Until now I only got one HID example with my 25 MHz setting to show me the unknown device bubble ( device manager).

MSC and CDC examples dont work with my PC.

I did measure the voltage level of the PUR for each example, and only in the "working" HID example it is pulled up to 3,3 V, I think it got something to do with it.

And i am now realizing another difference, I did only tell the descriptor program to use external Vcc in the "working" HID example, gonna change that up for the other examples now too and keep you informed about my results.

ok now i am quite sure the enumeration process is not working, but I do not know yet how I could fix that, I did give some new PIDs to my differenct CCS projects but the problem remains, everything is ok but enumeration just wont take place.

Do I miss a driver from Texas to achive it?

OK -- so I understand you to be using your own custom board, based on the F5529, with most of the I/Os connected to something -- with a 25MHz crystal on XT2.  It sounds like you did use the Descriptor Tool to create your descriptors (setting 25MHz), although I'm not sure exactly which software examples you ran. 

In the case of MSC, you won't get your volume to mount without proper application-level code.  But with properly-built descriptors, the devices will enumerate in the DevMan without application-level code (provided your application doesn't interfere with the USB API's ability to do so, like disabling interrupts). 

Clocks & Power

A 25.0MHz isn't a good option to use with the USB module -- it isn't a default freq, which usually means it'll result in too much error (although I haven't calculated it per the Family User's Guide).  Since it isn't a default option.  It looks like you chose 25.6MHz instead -- this won't work, and may explain the communication failure. 

And while you're choosing a new crystal... I get the feeling you're planning to use XT2 to drive MCLK... I'd discourage that.  Use the DCO/FLL.  (See the MSP430 USB API Prog. Guide, in the USB Dev Package -- there's a section on clocks that discusses all of this.)

You mention something about an 'external VCC' setting in the Desc Tool -- are you referring to "Drive VUSB from External Supply"?  Do you have an external power source driving into the VUSB pin? See the USB API Prog. Guide chapter on power. 

Re-configuring the Examples' I/O Settings

You're correct that if using custom hardware, you need to customize the I/O configuration code.  Generally speaking, the examples configure all I/Os as "driving out low" instead of inputs; because our intent is to minimize power consumption, and floating inputs draw excess power.  But if you've connected your I/Os to things that don't react well to being pulled to ground, it isn't impossible that this has somehow come back around to impact the MSP430 execution. And it may not be good for your other h/w. 

As a simple action to deal with the I/Os, it might be enough to simply comment out every call to GPIO_setAsOutputPin():

//GPIO_setAsOutputPin(GPIO_PORT_P1, GPIO_ALL);

This should cause the i/Os to be inputs, because the MSP430 defaults I/Os to inputs after a reset. 

Using the Examples with Custom Hardware

Generally speaking, this procedure works out-of-the-box:

1)  Use any of TI's MSP430 USB hardware
2)  Download any of the examples in the USB Dev Package into the MSP430
3)  Connect to the host

If you use custom hardware instead, the software examples should still work, with only a few changes, described below.  Note that we provide a *.dat file (for the Descriptor Tool) for every single example we provide, which shows you exactly how those descriptors were created.  I suggest you modify these settings, rather than starting from scratch, to make 100% sure you start from a working example.  Load this file into the Desc Tool, modify the settings as described, and then re-generate your output into the example project's \USB_config directory.  

Mods for custom hardware:
a)  If using a different crystal than TI's hardware (which is always 4MHz), modify this setting in the Tool
b)  If you're sourcing 3.3V into the VUSB pin on your hardware, select the 'Drive VUSB from Ext Supply" checkbox.  (However, the only reason you'd ever configure the h/w this way is to save a bit of power draw -- most people wouldn't need to do this, and doing so adds some trickiness to the design.)

For basic enumeration, those should be the only required mods.  Keep in mind that every time you enumerate, the host stores descriptor info and indexes it with the VID/PID; so if you change the descriptors, you should either delete the old device, or give your descriptors a new PID.  Otherwise the host may behave unpredictably toward the device. 

Finally -- hopefully you're aware of the Examples Guide, and also the Programmer's Guide, inside the USB Dev Package, which serve as a reference for what you're trying to do. 

Best of luck -
Keith

seb said:

#define USB_MCLK_FREQ 25000000                // MCLK frequency of MCU, in Hz

#define USB_XT_FREQ       USBPLL_SETCLK_25_6         I dont know what this does, adn if its important to me

Here is calculator for setting USB PLL ...

http://forum.43oh.com/topic/3904-usb-pll-configurator

Good point -- and it looks like 25.0MHz is indeed inside the USB +/-2500ppm limit.  You'll need to manually assign these values in your code, since the Tool only supports the values in the list.  But this is probably easier than changing your crystal.