I notice that the usb1_funct core that the wValue of a SET_CONFIGURATION device request is not tested. Simply receiving a set_configuration request sets the device into the configured state. I believe this should be tested against the value hardcoded in the configuration descriptor (0x01). It should also be tested to see if it zero. When zero the function should revert to the "Address state" (see usb_20.pdf section 9.4.7). When in this state the endpoints should be reset the data toggle sync to DATA0. This doesn't appear to be done in the usb1_pe module.

Also, perhaps more importantly, the configured state does not seem to be used anywhere. So the core would respond to non-control endpoint transactions in the addressed state. Is this a spec violation? What should happen if this occurs?

I would appreciate any feedback from anyone familiar with this core.

Regards

Darrin

See the link below for the code that handles the descriptor decoding...

http://opencores.org/websvn,filedetails?repname=usb1_funct&path=%2Fusb1_funct%2Ftrunk%2Frtl%2Fverilog%2Fusb1_ctrl.v

I am not familiar with this core, but I believe that most of what you describe it not a violation of the USB specifications.

Primarily, a USB Device circuit should not draw more than 100 mA until configured, and then it must not draw more than the current specified in the selected configuration (up to 500 mA, but possibly less, depending upon the descriptors).

Part of the problem with a generic USB solution like this is that it must be incomplete, by definition. Only after the designer of the USB Device has finalized the Descriptors, the number of Configurations and their various specific details can the core be completed.

I do agree with your comments that setConfiguration to 0 should alter a few global state variables, pending review of the USB specification to confirm. However, my point above is that setConfiguration to non-zero cannot be checked until the core in integrated with a completed solution. Hopefully there are copious comments in this core on how to complete a design, but I would not be surprised if such details were missing.

(continuing with further details)

If this core is used on a board that never draws more than 100 mA, then perhaps nothing needs to be done with the setConfiguration value. However, if the board does draw more than 100 mA then it must have some sort of soft switch that can be used to turn off the circuits which draw more than 100 mA, and this switch must be controlled by an output pin of the FPGA that is under control of the setConfiguration logic. This is what I mean by "incomplete by design" - it's not possible to know whether the final USB Device circuit draws more than 100 mA or where the power control lines are attached, so these sorts of design elements must be factored in by the designer using the USB1 core.

Further, if the final USB Device offers more than one Configuration, each having a different amount of current between 100 mA and 500 mA, then the design becomes even more complex. Hopefully, the core has hooks or otherwise allows such complexities to be added as needed.

Thanks for prompt reply. I hadn't thought about the configuration state controlling power to the function. Fortunately this is a single config, single unit load (100mA) bus-powered design, so the configuration won't need to mange the downstream power consumption.

So my concern is what to do if the host set the config value to 0 or > 1? From the spec (9.4.7) the host should only set the config to 0 or a value from a config descriptor. So in the >1 case I assume I can just silently ignore the SET_CONFIGURATION. But what about a config value of 0? It appears this is a mechanism for initializing the endpoint data toggle state. The get configuration request should return the config value of zero when it is in this address state. So it appears I need to add a bit of logic to handle setting the config to zero.

However, will a host ever set the config to 0? I would imagine not, especially in a single config function. Perhaps this is why the code was simplified. It assumes once the config it set it won't get touched again.

At the very least, the core should maintain one bit of state so that getConfiguration will return 0 or 1 depending upon the most recent successful setConfiguration.

For >1, you can simply reject all setConfiguration requests except for 0 and 1. So, you do not silently ignore them, but you must STALL the endpoint to signal to the Host that it's basically working outside the Descriptors. However, you'll probably never receive a setConfiguration:=2 if your Descriptors only mention one Configuration, but it doesn't hurt to stall on bad requests.

As for initialization of endpoint data toggle states, I must admit that I use USB firmware libraries that handle this sort of thing for me, so you're on your own with regard to interpreting the USB Specifications on that one. What you describe sounds very much like something that the USB guys would require, so I recommend that you thoroughly look into the specs.

Will the Host ever set the Configuration to 0? Probably. In fact, a Hub might do that, too, if it changes from self-powered to bus-powered. While 99% of situations may result in the Configuration going from 0 to 1 and never back to 0, there are many situations where connecting another Device or otherwise affecting a Hub could result in all Devices being re-Configured.

I have tweaked the code to support config=0x00 and to ignore requests when config>1 and to generate a stall as described in USB20 section 8.5.3.4.

Thanks for your help.

Darrin

Sounds good.

I'm just being pedantic here, but if you generate a STALL then you're not completely ignoring the config>1 request. But, I guess from the point of view of the configuration state, you are "ignoring" it if you do not modify your state. On that note, it might be worth scanning the USB Specifications to see whether stalling a Set Configuration message should revert to config=0 or just maintain the previously selected configuration. Man, this stuff can be complicated!

Couldn't find any reference to reverting the config to zero if a bad config is set. I believe ignoring it and sending a request error (STALL) is the right thing to do.