stdio via USB virtual COM port

[lanchon]

Posted on April 04, 2009 at 17:08

stdio via USB virtual COM port

[mvi]

Posted on May 17, 2011 at 12:28

As far as I know the pullup is needed so that the Host knows a new device is plugged in and can start an enumeration. On the other hand, the host runs occasional enumerations to update the device list. So i cant really confirm anything.

On my design I included a pullup that can be turned on and off via a couple of transistors.

With lanchons help I managed to get the USB VCOM running 100%. The VCOM lib from ST enables you to send only one byte at a time, which wasnt good enough for my design.

[niksa]

Posted on May 17, 2011 at 12:28

lanchon, mvi,

thanks for your replies - they were very helpful. It seems that USB controllers that we worked with in the past had pullup resistor and logic integrated and there was no need for external pullup control.

Thanks,

Niksa

[mvi]

Posted on May 17, 2011 at 12:28

Also the USB spec is specific about a 1.5k pullup. The STM32 has ''weak'' pullups so you might need to double check this.

The pullup needs to be connected to the D+ line.

http://www.beyondlogic.org/usbnutshell/usb2.htm

[lanchon]

Posted on May 17, 2011 at 12:28

hi trevor,

> With jumper J1 inserted so that the USB 1k5 pull up is always enabled the code gets stuck at

>

> --------------

> while (((volatile DEVICE_INFO*) pInformation)->Current_Configuration == 0);

> --------------

I strongly suspect that's a bug in the USB lib, but it could also be a bug in the way ST's VCOM sample uses the lib (read the previous posts). I use this lib only for debugging and works fine for me, I've no intention of fixing the usb lib bugs.

a ''fix'' (right!) might be to just delete that line. that line simply makes the USB init routing wait until the peripheral is enumerated by the host. (that non-optional waiting is bad library design anyway.) concerned parties might give this a try.

the correct way is to handle initialization in a proper thread safe manner. this could be as simple as delaying the enabling of USB macrocell reception and interrupts until the usb lib and macrocell are correctly initialized (and doing this with a little bit of care, such as by clearing pending interrupts before enabling reception if necessary, etc).

> If the jumper is set so that PD9 is in control of the pull up then the code gets stuck at

>

> --------------

> void HardFaultException(void)

> {

> DEFAULT_EXCEPTION_HANDLER(HardFaultException, ''Hard Fault'', 3, 0x0C);

> }

> --------------

that might be an issue with rowley. I invite you to install codesourcery arm-none-eabi, make with cs-make, and try the code. I'm afraid I can't help you with Rowley CrossWorks since it's proprietary or proprietarized code.

however I see that in your port to rowley you've included stm32exceptions.c, a file from my build environment that's not part of the app. I guess the simplest way to distinguish between what makes the app and what doesn't is to compare it with a virgin build environment that you can download from here:

http://www.st.com/mcu/forums-cat-6445-23.html

best,

lanchon

[trevor1]

Posted on May 17, 2011 at 12:28

Firstly, thanks to Lanchon for making the code available.

I can't get it to work so I hope someone can help.

Setup

ST dev board (STM32F10x-EVAL)

Rowley CrossWorks for ARM compiler (GCC based)

Windows XP

Changes To Original VCOM code (V0.9.1):

Changed USB pull up control to use PD9

Changed the following code in Set_USBInterrupt (main.c)

--------------

extern void (* const __cs3_interrupt_vector[])(void);

SCB->VTOR = (u32) __cs3_interrupt_vector;

--------------

To be this (I don't have a __cs3_interrupt_vector defined in Rowley)

--------------

#ifdef VECT_TAB_RAM

/* Set the Vector Table base location at 0x20000000 */

NVIC_SetVectorTable(NVIC_VectTab_RAM, 0x0);

#else /* VECT_TAB_FLASH */

/* Set the Vector Table base location at 0x08000000 */

NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);

#endif

--------------

With jumper J1 inserted so that the USB 1k5 pull up is always enabled the code gets stuck at

--------------

while (((volatile DEVICE_INFO*) pInformation)->Current_Configuration == 0);

--------------

If the jumper is set so that PD9 is in control of the pull up then the code gets stuck at

--------------

void HardFaultException(void)

{

DEFAULT_EXCEPTION_HANDLER(HardFaultException, ''Hard Fault'', 3, 0x0C);

}

--------------

Any ideas?

Regards

Trevor

[ This message was edited by: trevor on 17-05-2008 01:54 ]

[lanchon]

Posted on May 17, 2011 at 12:28

> not have to wait at start-up for USB to connect

start by removing this line

while (((volatile DEVICE_INFO*) pInformation)->Current_Configuration == 0);

and tell us.

[trevor1]

Posted on May 17, 2011 at 12:28

Thanks for you response Lanchon.

After much hair pulling the problem was the stack size. In the Rowley project settings I changed the stack size from 128 (default) to 512 and it sprang to life........ahhhhhhhh....should have spotted this before now. The EVAL board jumper (J1) is set to its default position (2,3) so that PD9 controls the USB pull up.

Now to figure out how to make it so I can plug in and out the USB cable when ever I like and also not have to wait at start-up for USB to connect. What I'm trying to achieve is to provide access to a command line. I already have the command line working on serial ports so I just need to make my USB interface look like a serial port -- with circular buffers etc. (I'm running an OS).

I'll report back anything that might be useful to others. All suggestions welcome.

Regards

Trevor

[trevor1]

Posted on May 17, 2011 at 12:28

Yes, I did this last night and it works. I added this check at the top of Virtual_Com_Port_Receive_Non_Blocking and Virtual_Com_Port_Transmit_Non_Blocking.

e.g.

Code:

u32 Virtual_Com_Port_Receive_Non_Blocking(u8* data, u32 length)

{

u32 l;

if (((volatile DEVICE_INFO*) pInformation)->Current_Configuration == 0)

return 0;

.

.

Not sure if I need this -- just trying to prevent running code that assumes the interface is configured.

In terms of re-connecting:-

If I disconnect and then re-connect the USB cable and then close and open again the virtual com port on the PC then it works again (most of the time :( ). The problem then is how does the PC end ''know'' that it needs to re-connect the virtual com port when the USB cable is removed?

Regards

Trevor

[trevor1]

Posted on May 17, 2011 at 12:28

The problem with adding ''dead state'' detection is we are going away from an interface that looks like a serial port to the PC e.g. what about existing PC apps that work with a serial port and cannot be changed?

I wonder if there is some provision in CDC for this. There must be provision for signalling DSR, DCD, RI etc back to the PC. Maybe something like DSR going inactive could signal this ''dead state'' -- doesn't solve for existing apps that don't monitor DSR but would be a solution for new apps. I guess I'll have to dig into the CDC spec to find out.

Lanchon,

Are you saying that this isn't a problem on non Windows OS? I have to make my product work with Windows in any case.

Regards

Trevor

[lanchon]

Posted on May 17, 2011 at 12:28

> The problem then is how does the PC end

this is a windows issue. if a virtual COM is disconnected by unplugging the USB, the windows virtual COM interface to the virtual COM remains in a emulated ''valid but dead'' state until the terminal closes it. if it doesn't and you reconnect, windows will not rehook the COM interface to the COM.

either make your own terminal to detect and rehook or use a better OS.