What exactly is the purpose of the SOFTCONN bit?

Anguel,

Setting the SOFTCONN bit will enable the USB0DP/USB0DM pins whereas clearing this bit will tristate them.  Setting this bit will allow communication to the USB controller.  Clearing it will disconnect the USB controller from the bus so communication cannot occur.

USBDCDCInit() will make a call to USBDevConnect() (located in driverlib/usb.c) which will set the SOFTCONN bit (USBDevDisconnect() clears the SOFTCONN bit).  Technically, the USB controller should be initialized and ready to enumerate before setting the SOFTCONN bit.  This means that VBUS should be present and at a valid voltage level.  For the setup Stellaris has with all the different devices and settings, USBDCDCInit() is assuming that VBUS is valid and present so it sets this bit after it is finished with the initialization.  This may create some power consumption because the pull-ups on the DP and DM lines are enabled, but does not drastically affect the functionality of the USB controller and the enumeration process.  For your case, regardless of whether the USB is self-powered or bus-powered, power to the USB should be monitored.  When it is at a valid voltage level, the SOFTCONN bit should then be set to allow enumeration and communication. 

-Rebecca

 Hi Anguel

In the USB practice, SOFTCONN (or SoftConnect) means the function which enables/disables D+ (or D-) pull-up resistor under VBUS monitoring.

Here is SoftConnect description from NXP LPC24xx data sheet. It describes this function clearly.

CON bit
The Connect bit indicates the current connect status of the device. It controls the CONNECT output pin (*1), used for SoftConnect. Reading the connect bit returns the current connect status. This bit is cleared by hardware when the VBUS status input is LOW for more than 3 ms. The 3 ms delay filters out temporary dips in the VBUS voltage.
0: Writing a 0 will make the CONNECT pin go HIGH.
1: Writing a 1 will make the CONNECT pin go LOW..

(*1) On LPC24xx, an external D+ pull-up resistor is controlled by CONNECT output pin.

I believe Stellaris USB SIE has exactly same function at SOFTCONN bit. But the data sheet doesn't clearly mention on this function, just suggestion. Here is SOFTCONN description on LM3S3748.pdf (the same description on all other parts)

19.3.1.9 Connect/Disconnect
The USB controller connection to the USB bus is handled by software. The USB PHY can be switched between normal mode and non-driving mode by setting or clearing the SOFTCONN bit of the USBPOWER register. When the SOFTCONN bit is set, the PHY is placed in its normal mode, and the USB0DP/USB0DM lines of the USB bus are enabled. At the same time, the USB controller is placed into a state, in which it does not respond to any USB signaling except a USB RESET.

When the SOFTCONN bit is cleared, the PHY is put into non-driving mode, USB0DP and USB0DM are tristated, and the USB controller appears to other devices on the USB bus as if it has been disconnected. The non-driving mode is the default so the USB controller appears disconnected until the SOFTCONN bit has been set. The application software can then choose when to set the PHY into its normal mode. Systems with a lengthy initialization procedure may use this to ensure that initialization is complete, and the system is ready to perform enumeration before connecting to the USB bus. Once the SOFTCONN bit has been set, the USB controller can be disconnected by clearing this bit.

Register 2: USB Power
- SOFTCONN: Soft Connect/Disconnect
1 The USB D+/D- lines are enabled.
0 The USB D+/D- lines are tri-stated

In USB device context, "Connection/Disconnection" means "enable/disable" of D+ (D-) pull-up resistor. And then, this bra-bra seems to suggest pull-up resistor control. But nowhere on this description, "pull-up" appears. In the first place, the output of D+/D- transceiver is usually kept in "tristated" in normal operation. It is enabled just at the output phase of transactions, or while the device initiates remote wakeup. In this mean, 19.3.1.9 section is out of focus.

This section should be revised, like NXP's.

Tsuneo

Rebecca and Tsuneo,

Thank you very much for your replies. I really appreciate your help. Btw, I remember that Tsuneo has also helped many people on the Microchip forums, so now I am really happy that he is also active in this forum!

So back to my problem:

@Rebecca: I do not see any references to USBDevConnect() or USBDevDisconnect() in the Stellaris USB library guide. Are these functions supposed to be called directly from the application level and how should a developer become aware of them without reverse-engineering your drivers? I am concerned that setting the SOFTCONN bit manually may have negative side effects or may interfere with StellarisWare functions in the future.

Actually, I do not understand why USBDCDCInit() does not simply init the device with SOFTCONN = 0 when the user application has defined that the device is self-powered. The developer has already defined if the device is self-powered in the tUSBDCDCDevice instance anyway. As you can see in Tsuneos post the TI MCU datasheets also state that 0 is actually the default. Quote: The non-driving mode is the default so the USB controller appears disconnected until the SOFTCONN bit has been set.

StellarisWare ignores this and sets SOFTCONN = 1 at USB init which can lead to problems as far as I see. I am referring for example to page 3 the document "Common USB Development Mistakes" published by Cypress (http://www.cypress.com/?docID=9184) where I read the following:

Back-power
“Self-powered” USB devices can also have their own power problems. Since self-powered devices have their own
independent power supplies, they can be ON while the host is turned OFF. This causes a potential problem where the small
pull-up voltage applied to D+ to enable USB device detection slowly charges up the entire host system and interferes with
startup. Self-powered USB devices (including battery-powered devices) must either drive this pull-up directly from VBUS or
turn it off via software control using a VBUS sensor.

@ Tsuneo: You are correct about the pullup resistor. In section 19.3.1.9 Connect/Disconnect that you quote, further down I read:

When the USB controller is acting as a self-powered Device, a GPIO input or analog comparator
input must be connected to VBUS and configured to generate an interrupt when the VBUS level
drops. This interrupt is used to disable the pullup resistor on the USB0DP signal.

This is very probably referring exactly to the SOFTCONN bit. But StellarisWare does not handle it properly, so the device behavior does not comply with USB requirements.

Unfortunately, this attitude "we don't care if our libraries are working properly if they work somehow and everything is left to the developer" is a very common attitude in software-driven USB solutions. If companies like TI cannot manage to deliver properly working drivers and docs, how can a small developer deliver properly working devices that comply with common standards like USB? This leads to delivering devices that do not function properly to the customer. Sad but true...

Anguel