USB VCP code locked in interrupt context.

[Clifford1]

Posted on March 18, 2011 at 19:34

USB VCP code locked in interrupt context.

[Fleck]

Posted on May 17, 2011 at 14:28

Hi Clifford,

can you explain what was fixed by ST support? We have a similar problem to what you describe in part (1) : The IN Endpoint Interrupt firing continually blocking everything else. The same problem has been discussed in the forum before, but no universal solution has been given.

Thanks!

Jens

[Clifford1]

Posted on May 17, 2011 at 14:28

Further... Part (1) - getting stick in the interrupt context was resolved by an update from ST support.

The original code did not correctly clear the Tx FIFO empty interrupt.

[Clifford1]

Posted on May 17, 2011 at 14:28

After some research and assistance from ST Support (thanks Jiri), I have determined a solution to part (2) - detecting whether the host port is open.

Conventionally, when a port is opened the DTR modem control line is asserted. This information is passed to a CDC class device, so I can use this to achieve my aim. It is possible for an application to change the behaviour of DTR, but this should not happen in any of the client applications that are likely to connect to this device in this case. However there is a back-up plan that implicitly assumes the port to be open if the line-coding (baud, framing) are set. In this case there is no means of detecting closure but at least it will not prevent an unconventional application from working with my device, even if it then causes it to crash when it disconnects.

Regarding ST's VCP example code specifically I have made the following changes to usb_prop.c:

1) Added the following function:

#include <stdbool.h>
static bool host_port_open = false ;
bool Virtual_Com_Port_IsHostPortOpen()
{
 return bDeviceState == CONFIGURED && host_port_open ;
}

2) Modified Virtual_Com_Port_NoData_Setup() handling of SET_CONTROL_LINE_STATE thus:

else if (RequestNo == SET_CONTROL_LINE_STATE)
{
 // Test DTR state to determine if host port is open
 host_port_open = (pInformation->USBwValues.bw.bb0 & 0x01) != 0 ;
 return USB_SUCCESS;
}

3) To allow use with applications that do not operate DTR conventionally I have also modified Virtual_Com_Port_Data_Setup() handling of SET_LINE_CODING thus:

 else if (RequestNo == SET_LINE_CODING)
 {
 if (Type_Recipient == (CLASS_REQUEST | INTERFACE_RECIPIENT))
 {
 CopyRoutine = Virtual_Com_Port_SetLineCoding;
 // If line coding is set the port is implicitly open 
 // regardless of host's DTR control. Note: if this is 
 // the only indicator of port open, there will be no indication 
 // of closure, but this will at least allow applications that 
 // do not assert DTR to connect.
 host_port_open = true ;
 }
 Request = SET_LINE_CODING;
 }

[schneeblau1]

Posted on May 17, 2011 at 14:28

Hello,

I am also interested in a solution.

At which time will ST update the libs?

[Fleck]

Posted on May 17, 2011 at 14:28

Hi AniST,

I hadn't notice the new library version yet. I'm testing it now, will reply with the results.

The issue we're facing with 3.2.1 is that every once in a while during transfer of IN data (we are continuously sending small amounts of data from the STM32 to the PC, about 30 byte packets with approx. 20 Hz rate) the STM32 software locks up. JTAG debugging showed that the IN EP interrupt fired continuously.

Switching on a soldering iron on the desk increased the frequency the problem occurred from ''once every few days'' to ''once every few hours''...

Thanks!

Jens

[tsuneo]

Posted on May 17, 2011 at 14:28

AniST,

Thanks, the version number on the web page has been updated to v3.3.0, too.

Tsuneo

[tsuneo]

Posted on May 17, 2011 at 14:28

AniST,

Surely, the downloaded library is updated to v3.3.0, but..

Please update the version number on the ''Design support'' web page of www.st.com, like,

http://www.st.com/internet/mcu/product/221026.jsp

http://www.st.com/internet/mcu/product/164487.jsp

It still tells 

ARM-based 32-bit MCU STM32F10xxx USB Device Full Speed Library  3.2.0

The version number on the web page was not updated when the library went from v3.2.0 to v3.2.1

Ask to your webmaster, to integrate easy system which tracks the version number automatically on update.

Tsuneo