Posted on May 17, 2011 at 12:53Hi There,
I think there is a serious issue with the Virtual Com port driver or example code. I think it is in the driver. Try this with the UM0424.zip example provided by ST. Build and load the um0424 VCP example in the ST32F10xB development tools using IAR. Open up a HyperTerminal application on the PC connected to the eval board via USB. Connect a Null modem to another computers com port and open up another HyperTerminal on this PC. Set the communication settings to the following on both Hyperterminal sessions. Baud Rate 9600, Stop bits 1, Flow Control None, Parity none. Now type in the Hyperterminal session communicating with the USB Virtual Com Port example. Try type ''g'' ''g'' ''g''. What you get on the Hyperterminal connected to the USART 1 on the second PC is, ''g''''g'' ''Extended ASCII Character'' ''g'', ''Extended ASCII Character'', ''g'' and so on. Now to fix, simply disconnect the Hyperterminal session connected to the USB virtual com port, change the setting of the parity to something else, reconnect, type ''g'' and then disconnect. Set the settings back to parity none and hey presto no more errors after that. What appears to be happening is that the USB part of the Virtual Com Port (I suspect the driver) mucks up the parity setting of none. So when you type ''g'' it sends correctly 0x67 but when you type ''g'' again it sends 0xE7 which basically appends the parity bit of the previous transmisson to the current one. As 0xE7 parity is even, the next time you type ''g'' it sends 0 for the parity bit so you receive 0x67 or ''g'' which is correct.
Has anybody out there noticed the same problem and if so can they recommend a work around.
Regards
Walt
🙂
