TI RTOS USB Serial Device demo hangs after device disconnect

Hi Anguel,

A task using the USB reference modules generally should call the _waitForConnect() API to see if the USB is connected and block until it detected the USB. The task sending data really just writes data into the USBBuffer and pends when the buffer is full. The timeout argument is there so that you can use it to specify how long to pend.

If you compare the length argument with the return value, they should match and if they don't, then you know that a timeout has occurred allowing you to check _waitForConnect() again.

Did you try closing the virtual com port and reopening it after disconnecting the USB?

I don't think the problem is the Virtual Com Port as the receiving task continues to work ok as I said before.  I see in the ROV that the sending task is blocked after reconnecting the USB cable and waits forever. Unfortunately for some reason I don't see the name of the semaphore it blocks on in the ROV.

I noticed that both send and receive tasks call USBCDCD_waitForConnect() that pends on the semaphore but on USB_EVENT_CONNECTED the semaphore is posted only once... ???

BTW, the TI example code does NOT use any timeouts.

It looks like USB_EVENT_DISCONNECTED does not fire. The USBlib guide states that PB1 is used for VBUS detection but looking at the Stellaris Launchpad Schematics it looks like PD7 is used there. Might this be the problem and where can I change this pin in the software?

Hi Anguel,

I'm going to look into this today and try to reproduce the problem you're seeing.

Tom,

Thank you for coming back to this thread. Meanwhile I am pretty sure that the problem is that the USB disconnected event is not caught by StellarisWare on this board.

I have tried to clarify this in another thread in the Cortex M4F subforum:

http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/901/p/250587/877791.aspx

Unfortunately I have still not managed to find out which is the proper way to solve the problem with the missing VBUS monitoring on this MCU's USB controller.

Regards,

Anguel

Tom,

Thank you so much. I had a look at the code and I like your solution. As far as I see you have also done the GPIO interrupt the proper TI RTOS way :-)

As soon as I get back to my office these days I will test it in hardware.

BTW, what do you think about my proposal in the other thread about the SOFTCONN bit in the POWER register? I am just curious if this could also solve the problem so that a complete USBDCDC_Term() is not required.

Thank you once again for your professional help!

Regards,

Anguel

I am still concerned about the SOFTCONN bit. It seems to be always set by StellarisWare when a device is initialized. IMHO this is NOT ok for self-powered devices...

Hi Anguel,

I really can't comment if the SOFTCONN method would work with this application. Looking at the LM4F120 data sheet section 18.3.1.9, the SOFTCONN bit puts the D+/- pins in tri-state (probably just turns off the USB PHY) so it's unclear to me if clearing this bit would generate a disconnect interrupt to allow the USB stack to properly reflect USB controller state.

Tom, my idea was to clear the SOFTCONN bit when the VBUS falling edge interrupt occurs and set it back to 1 when the VBUS rising edge interrupt occurs. In your workaround when VBUS goes low you completely turn off the USB controller of the MCU and then immediately turn it back on to wait for a new reconnect. This looks ok but StellarisWare auto-sets the SOFTCONN to 1 as soon as you do USBDCDC_Init() at the end of the ISR. StellarisWare does this although SOFTCONN should be cleared by default according to the MCU datasheet...

Unfortunately, SOFTCONN=1 would mean for self-powered USB devices that they do not tristate D+/D- but leave them active. But as far as I understand they should get tristated when they are disconnected. I am not an USB expert but I think that this is really required by the USB standard, so that back-power does not occur. Please refer to page 3 of this document: http://www.cypress.com/?docID=9184

Looking at the MCU datasheet under SOFTCONN to me it looks that this bit is actually doing the tristate thing. I hope that you have some USB experts at TI who can really help to clarify how this has to be solved properly. TI is claiming that the devices are fully USB compliant. All this tweaking and experimenting with software-driven USB is something developers really hate, and additionally there are a lot of MCU errata. As a developer one gets frustrated and finally has to choose an external USB chip that at least does things properly in HW.

A thorough discussion on SOFTCONN can be found in my other thread:
http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/901/t/251938.aspx

Hi Anguel,

I check-in with one of our USB experts and he agrees that we should delay setting the SOFTCON until we detect a VBUS. Unfortunately, we don't have a workaround for this issue but we did file an internal bug (15615) for this.

Tom,

Thank you once again for your help.

I am happy that you are listening to customer feedback and hope that this bug will be fixed soon.

I think that the problem can be also worked around by monitoring VBUS rising and falling via ISR and setting SOFTCONN in the ISR appropriately, instead of doing Term() and Init().

Unfortunately, I am very busy now but it should not be that hard to implement the correct behavior.

Best regards,

Anguel

Any news on a fix for the USB issues?  We are running into problems with the disconnect as well.  I am working on implementing the Interrupt as stated above to try and solve the issue.