Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
10 years, 7 months ago.
Virtual COM port in MBED debugger
Hi All
The MBED debugger has a USB-CDC connection to a UART on the board which saves having to wire up an RS232 device to a UART. However this connection has a problem when using XON/XOFF protocol. When the embedded device sends XOFF it is expected that the PC stops sending data until XON is received (when the COM port is set up in this mode).
Whilst this works correctly when connecting to a PC's COM port directly and also via various USB-UART adapters it doesn't work using the MBED USB-CDC and the PC doesn't stop sending the data.
The same problem exists with P&E's OpenSDA version but P&E don't seem to be interested in correcting/improving it.
Is this problem known and would it be an idea to improve the operation to avoid it being a cause of difficulty in applications requiring this flow control?
Regards
Mark
1 Answer
10 years, 7 months ago.
Hi Mark - XON/XOFF seems to be an ASCII only extension. It may be worth rephrasing the question to the community to see how they are using the CDC port as 0x13 and 0x11 would not behave as expected if sending / receiving non-ASCII formatted data.
Sam
XON/XOFF is described here: http://en.wikipedia.org/wiki/Serial_port
When the serial interface is configured at the PC, the mode of operation (no-flow control, HW flow control or XON/XOFF) flow control is configured accordingly and so 0x13 and 0x11 are only treated as flow control when set to this and don't generally disturb. The Wiki-link also explains how character escaping is used together with XON/XOFF when needed (eg. the HDLC protocol in PPP escapes data when working with XON/XOFF flow control).
However the first problem is that the PC doesn't inform the USB device which mode it is in, whereby when I check commerical USB-UART converters these supply their own drivers and the setting is passed Although using vendor requests.
It may be that this is an option in the Abstract Control Model which is only performed when the device also informs that it supports it during class enummeration. The Wiki link does state that also Virtual COM ports support flow control and so I expect that this is more the case, but i didn't manage to locate specific detail.
I did see that the MBED CDC interface doesn't support the SET_COMM_FEATURE which I thought could be the reason but I also didn't see that this command set contains any flow control information, so I still don't know exactly what needs to be done at the USB level.
What however does look to be the case is that the device needs to manage the flow control (for the PC) and I suppose needs to scan Rx data for flow control characters and actively stop accepting more IN frames data until the flow has been enabled again.
Presumably the USB programmers will have more knowledge than me in this field. In industrial applications XON/XOFF flow control is used a lot and so the lack of it in the interface makes its use limited, especially since there is also no HW flow control support since the RTS/CTS lines are not used. For reference - the mode is explained a little in FTDI's implementation: http://www.ftdichip.com/Support/Documents/AppNotes/AN232B-09_Modem_Emulation_Mode.pdf
Regards
Mark
posted by 09 May 2014