VF50 and Serial communication problem: RTS/CTS, DSR/DTR


I am trying to develop a simple Serial Port self test application for a VF50 with WINCE6 - BSP 1.4B1 that runs on a Evabaord Rev 2.1.
I have tested the same applicationon the same hardware with a PXA processor and everything works as expected.
With VF50’s the application does not work.

A rough description of the application

First of all, it uses TransmitCommChar to send some data over serial … then reads/compares it.
All ok so far (just with BSP1.4B1 - TransmitCommChar )

Now the issues, for COM1

Then CTS/RTS and DTR/DSR signals are checked. Here the problems appear.
First of all when the SetCommState() method is called for com1/2 the pins for RTS are changed from SCIx_RTS to GPIO output. Same happens when the EscapeCommFunction() is called.

Question1: Is this the correct behavior for these 2 methods?

Next step is, after setting the RTS to read the CTS (SCIx_CTS).
This signal is read with GetCommModemStatus(). The value returned for CTS is allways 1. This is not correct, I can see that the voltage on the PIN has changed.
If I change the CTS pin Altfn form SCIx_CTS to GPIO_Input then the GetCommModemStatus() return the correct level.

Question2: Is this a good fix for reading the CTS signal level?

Question3: Why is the GetCommModemStatus() function not working with SCIx_CTS altfn?

Then the DSR/DTR, it is already GPIO_I/O by default, and setting/getting it fails because when DTR is true DSR is false and vice-versa.

Question4: Any idea why this is happening?

For COM2, the EscapeCommFunction does not successfully change the level of the RTS.
SetCommState() and GetCommModemStatus() behave in as described above, for COM1.

Question5: Why is EscapeCommFunction () failing to change the PIN level?

WriteFile() Issue

An other issue is concerning WriteFile() method;
So I open a comm channel then send some data using WriteFile(). Everithing is ok if the baud/parity of the send and receiver match.

But if the sender has for example 19200 baud and receiver has 115200 baud (or different parity) then the WriteFile() method never return (the entire system is frozen until a manual reboot).

PurgeComm() issue

Also when I read the data with ReadFile() method, I can see all the data that was read/written in previous steps. To fix this I call PurgeComm(com, (TX,RX)) ; Themethod returns success but in the rx buffer I can still find all the old data

The main question is am I missing some configuration in the WINCE regs, or some com port initialisation value that causes this bad behavior or is there a problem with the above methods (SetCommState(), GetCommModemStatus(), EscapeCommFunction (), PurgeComm(), WriteFile()) in BSP1.4B1?

Any help is greatly appreciated!

Thank you and I will be waiting for your input,


Com init values:

tDcbData.DCBlength = 28
tDcbData.BaudRate = 9600
tDcbData.fBinary = 1
tDcbData.fParity = 0
tDcbData.fOutxCtsFlow = 0
tDcbData.fOutxDsrFlow = 0
tDcbData.fDtrControl = 0
tDcbData.fDsrSensitivity = 0
tDcbData.fTXContinueOnXoff = 0
tDcbData.fOutX = 0
tDcbData.fInX = 0
tDcbData.fErrorChar = 0
tDcbData.fNull = 0
tDcbData.fRtsControl = 0
tDcbData.fAbortOnError = 0
tDcbData.fDummy2 = 0
tDcbData.wReserved = 0
tDcbData.XonLim = 0
tDcbData.XoffLim = 0
tDcbData.ByteSize = 8
tDcbData.Parity = 2
tDcbData.StopBits = 0
tDcbData.XonChar = 0
tDcbData.XoffChar = 0
tDcbData.ErrorChar = 0
tDcbData.EofChar = 0
tDcbData.EvtChar = 0
tDcbData.wReserved1 = 0

Reg. Settings:

HI, I will look into this, but it will take me few days. I will get back to you with update in the middle of next week.

Sehr geehrter Herr Luka,
wir bräuchten dringend eine Lösung.
Mit freundlichen Grüßen,
Alex Babych

We are working on this today. Please note that community is in English and we would like to keep it this way so all our customers can understand it.

I have some answers and questions for you.

  • Answer 1: Yes this has to behave this
    way. Its configured as GPIO because
    of software emulation
  • Answer 2: If you set fOutxCtsFlow to
    TRUE, you will be able to read this
  • Answer 3: This 2 signals are emulated
    in software. I do not exactly
    understand your issue. Could you
    provide sample code? Thanks
  • Answer 4 and 5: Inside registry under
    HKLM\Drivers\BuiltIn\UARTB change
    RTSToggleAlwaysOn to 0
  • Answer 6: I do not see WriteFile
    issue. Can you provide sample please
  • Answer 7: This was issue in 1 beta.
    It was fixed.

After you give me all the samples and answers I will be able to debug this and create temporary driver for you to test changes.

Thank you very much. We will send the detailed test descriptions and source codes per email to support asap.