stdio via USB virtual COM port

[lanchon]

Posted on April 04, 2009 at 17:08

stdio via USB virtual COM port

[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

> Maybe something like DSR going inactive could...

I guess there's nothing you can do on the stm32 side since the device is just not plugged in at the relevant time. not reconnecting the software API COM ''socket'' to the device on reconnection is a windows design decision or ''feature''. I don't know enough about USB or CDC to judge this as bad, but it sure smells like it. if I had to guess, if you don't want to modify the apps you'll have to make your own CDC windows driver (definitely not something I would recommend). > Are you saying that this isn't a problem on non Windows OS? no, I'm just saying this doesn't have to be a problem on non windows OSes, you'll have to check.

[pandoraems]

Posted on May 17, 2011 at 12:28

Tried lanchon's code

As far as i understood, inf file is the windows driver. What's the other file? Also i could not figure out where in the vcom code such things as baud speed is being set? So far, i get the XP to recognise the hardware as the virtual parallel port. But hyperterminal refuses to receive anything (even if i cut and paste stuff into it) I've also tried a simple serial port terminal program, it behaved rather strange - freezed up once i tried to type anything in it (anything to do with blocking?) I also tried to comment out the while(...) line that was discussed before, with no success. Is there anything else i can do/try to get further in this? Also, any linux driver to try this with? Thanks

[lanchon]

Posted on May 17, 2011 at 12:28

> What's the other file?

what other file? > Also i could not figure out where in the vcom code such things as baud speed is being set? vcom has USB-based flow control and has no baud speed. the baud settings are simply ''abstract'' flags that are set by the host (windows or whatever) and transferred to the USB device. if the device is a USB to RS232 bridge, then it's customary that device will use the received settings to program its hardware RS232 transceiver peripheral. (This means that windows controls baud rate of the RS232 transceiver in the device, just as if the RS232 port were local to windows.) In this case, there's no RS232 port and the settings are received and completely ignored. > But hyperterminal refuses to receive anything... install the ''termite'' terminal and test. if it still doesn't work, then post complete details of your hardware and software platform, as well as any relevant behavior details. > I also tried to comment out the while(...) line most likely this isn't necessary.

[pandoraems]

Posted on May 17, 2011 at 12:28

Thanks for the suggestions lanchon

>what other file? the other file is ''remove MOD cache sentry.reg'', i just added it to the reg (doubleclicked) hardware: i am using olimex's header/stamp board: stm32-h103, with nothing attached to it (so should be standard enough). NOTE that i power the unit over USB (i.e no separate power source) firmware: using lanchon's package verbatim except for the while(...) modification mentioned earlier termite: Are there any specific settings needed at all besides the com# ? (i am guessing no since you've said that it ignores all the serial settings) here is how termite behaves: when launched first (stm32 usb is attached and emulated com4 is visible in device manager), it ''allows'' to type 2 strings before it hangs (not responding) after entering the third string. If i press the reset button on the olimex board, i can type into termite again for however many ''enters'' i want. (i.e it doesn't freeze up anymore) I saw in main.c, it should respond with ''Hello ...'' , but i don't seem to receive anything from the device. I wonder what else i could try before diving an ear-deep into the vcom code EDIT: in addition, here is what dmesg looks like once i plug device with lanchon's vcom into my linux box (ubuntu 8.04) [64832.628018] usb 2-1: new full speed USB device using ohci_hcd and address 22 [64832.793237] usb 2-1: configuration #1 chosen from 1 choice [64832.795962] /build/buildd/linux-2.6.24/drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem. [64832.795979] cdc_acm 2-1:1.0: ttyACM0: USB ACM device so maybe there is a chance i'll make it work on linux. (using /dev/ttyACM0 as serial port?) Maybe some of my basic assumptions are incorrect: should i expect the default firmware setup to print something in the host's terminal? (i.e ''Please enter your name''), and shouldn't it respond to me typing in the terminal? Just making sure i am not missing something In regards to the macro configuration in he main.c (pullups for usb) Here is the schematic of my module, looks like pc11 is the disconnect function, so no change is needed there: http://www.optimal-microsystems.com/store/images/ARM/ST/STM32-H103-sch.gif this pc11 also gave me a hint, and i got the original st vcom firmware to also get recognized by windows, but still no response when typing in terminal. EDIT2: tried debugging (gdb), and it looks like it's getting stuck at USB_LP_CAN_RX0_IRQHandler. It seems someone had similar problem on the first page of this thread, but a solution hadn't been proposed. basically, i do 'continue' then ctrl-c to break the execution, it always stops somewhere following the scanf() call hierarchy (as it should as it kist loops scanf) but the problem is that as soon as i ''break'' then 'step' just once, it goes directly to the IRQHandler as opposed to continuing with the scanf chain of calls. EDIT3: Some more findings: here are the Isrs that it trips on while debugging: ISTR_SOF - if the usb is plugged in to the host (host is idle) ISTR_RESET - if the usb is disconnected (i rigged up auxiliary power for the board, so it wouldn't be feeding off the usb power) and whenever it's freezing up in the terminal, it appears to get stuck in the while(tx_in_progress) loop in usb_endp.c The interesting thing is that i can clearly see by examining buffers with gdb, that the firmware received the ''name'' (i.e whatever i type in the terminal) and had formed the reply string - it's just it cannot send it for whatever reason Cheers [ This message was edited by: pandoraems on 12-10-2008 20:19 ] [ This message was edited by: pandoraems on 12-10-2008 22:42 ]

[lanchon]

Posted on May 17, 2011 at 12:28

hi,

you still haven't described the software environment you're using so I'm afraid I can't help you. > the other file is ''remove MOD cache sentry.reg'' ignore that file. (or google Microsoft OS Descriptor and related bug in the STM32 USB lib.) > i am using olimex's header/stamp board: stm32-h103 the code works out of the box on that board, be sure not to change anything. > here is how termite behaves: when launched first (stm32 usb is attached and emulated com4 is visible in device manager), it ''allows'' to type 2 strings before it hangs (not responding) after entering the third string. this seems like reasonable behavior. USB CDC has flow control; when the device isn't accepting characters and the relevant buffers are full, it is to be expected that the host-side write function used by termite to transmit ''temporarily'' block until buffer space is available. (the stm32 code blocks on both directions, so you don't have to worry about flow control.) > If i press the reset button on the olimex board, i can type into termite again for however many ''enters'' i want. (i.e it doesn't freeze up anymore) also reasonable behavior. reset causes disconnection from the host's USB stack. windows behavior upon disconnection is to start sending transmitted chars to limbo. if you reconnect the device, the virtual com port remains hooked to limbo. you have to close the serial port on the PC side and reopen it for it to connect to the device again. (again, this is windows behavior.) (no reply to the rest of your post until I'm aware of your setup.)

[pandoraems]

Posted on May 17, 2011 at 12:28

Thanks lanchon, i will try and describe the software setup to the best of my ability:

usb host: - windows xp sp2 - your driver (from windows/ directory) (not sure what else i can list here) - termite development machine: - ubuntu 8.04 - openocd (most current, also tried r717)+wiggler(parport) - codesourcery arm-none-eabi toolchain binaries (tried both q1 and q3, q3 currently) - your source unaltered can't think of any other details on the setup, please let me know anything else you need to know to help Let me know if there are any methods/tricks to use to get better insight. (usb sniffer? register analysis?) I've tried looking at USB endpoint registers before and after transmission from the host. The only significant difference is that EP3 field STAT_RX goes from b11 to b10 (i.e from VALID(enabled for reception) to NAK(all receptions is NAK'ed) ). EP1 register doesn't change. I am suspecting hardware at this point. Contemplating using another module - this one is home-brewed and i don't have the ESD protection module to attach between usb socket and the MCU - is it really needed?

[lanchon]

Posted on May 17, 2011 at 12:28

ok, until now I had no idea what toolchain you were using. I'm thinking I can give you a binary image for the STM32-H103 for you to try, to identify whether the problem is build-time or run-time. how are you building? are you invoking cs-make in my dir and using my makefile?

> i don't have the ESD protection module to attach between usb socket and the MCU - is it really needed? I'm running without it. (but in a 90% relative humidity environment.)

[lanchon]

Posted on May 17, 2011 at 12:28

I built this image but *didn't test it*. try it on your H103; only if it doesn't work I'll test it here to confirm that it works. then we'd be sure it's a runtime issue.

[pandoraems]

Posted on May 17, 2011 at 12:28

Thanks a lot lanchon, it's a great idea to try your binary. I'll report as soon as i try it. (btw, i used your makefile)

I will also try building in windows (cygwin) using same toolchain as you did > I'm running without it. (but in a 90% relative humidity environment.) i found this line entertaining ;) [ This message was edited by: pandoraems on 14-10-2008 17:30 ]