COM port goes to sleep and doesn't wake up

[Mike Scott]

I've got an app that reads data from the COM port on a PocketPC 2003 device.
When the device goes to sleep (either by inactivity timeout or by pressing
the on/off button) and is then woken up by pressing the on/off button, the
COM port stays asleep and doesn't receive any more data.

The file handle remains open but all calls to Win32's ReadFile return zero
bytes.

If I close the file handle and open another one to the COM port, everything
works again.

Is there some way to "kick" the COM port back into life after the device
goes into sleep mode?

Cheers,

MikeS.

 

[Paul G. Tobey [eMVP]]

What sort of COM port is it (it's not really a DB-9 serial port, is it?),
and what device, specifically? What value does ReadFile return (it returns
a Boolean, remember)? If it returns FALSE, I'm betting that you're wrong
and the handle is *not* valid. If it *does* return FALSE, call
GetLastError() and see what the error code is.

Paul T.

 

[Mike Scott]

Hi Paul

Already thought of that. The code checks the bool return and it's always
true - it throws an exception if false, and this never occurs.

The device is an O2 XDA II (made by HTC). It's also known as an MDA II and
various other vendor-specific names. It has a connector similar to an IPAQ I
believe, though the pinouts differ.

Cheers,

Mike.

 

[Paul G. Tobey [eMVP]]

In that case, I'd contact the OEM technical support and tell them what
you're doing and that it seems to be working improperly. I'd also prepare a
C program that shows the problem, as that's easier for the OEM to
understand.

Here's a thread in the eVC newsgroup that might show the same problem as you
are seeing. Read all the responses and see if any help...

http://groups.google.com/groups?hl=...lem&meta=group%3Dmicrosoft.public.windowsce.*

Paul T.

 

[Chris Tacke, eMVP]

This is actually not unusual. The handle is still valid, but when the
processor went to sleep the UART was reset. The OEM didn't reinitialize the
UART on wake. Often simply resetting the DCB settings on wake for the port
will cause your reads to start working again.

 

[ORC]

It's not only the device that Mike uses - it applies to all PDA's no matter
what development software one uses. It must be a bug somewhere in the
definition of the serial port of Pocket PC's. The 'power save' function and
the power off doesn't clean up everything when closing, so users that uses
the serial port or bluetooth ports will have to disable power save. All
this is just my experience - I don't know why it is so.

Ole

 

[Paul G. Tobey [eMVP]]

Well, that's one way to address it. If the driver resets the port and
restores the configuration when coming out of sleep, there's no reason why
it has to be reset and *certainly* no reason why power off has to be
disabled! Probably, since all of the 2003 devices are using the same
processor, they're mostly using the same serial port drivers which suffer
from this problem...

Paul T.

It's not only the device that Mike uses - it applies to all PDA's no
matter
what development software one uses. It must be a bug somewhere in the
definition of the serial port of Pocket PC's. The 'power save' function
and
the power off doesn't clean up everything when closing, so users that uses
the serial port or bluetooth ports will have to disable power save. All
this is just my experience - I don't know why it is so.

Ole

In that case, I'd contact the OEM technical support and tell them what
you're doing and that it seems to be working improperly. I'd also
prepare a
C program that shows the problem, as that's easier for the OEM to
understand.

Here's a thread in the eVC newsgroup that might show the same problem as you
are seeing. Read all the responses and see if any help...

http://groups.google.com/groups?hl=...lem&meta=group%3Dmicrosoft.public.windowsce.*

Paul T.

Hi Paul

Already thought of that. The code checks the bool return and it's
always
true - it throws an exception if false, and this never occurs.

The device is an O2 XDA II (made by HTC). It's also known as an MDA II and
various other vendor-specific names. It has a connector similar to an IPAQ
I believe, though the pinouts differ.

Cheers,

Mike.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com>
wrote in message What sort of COM port is it (it's not really a DB-9 serial port, is it?),
and what device, specifically? What value does ReadFile return (it
returns a Boolean, remember)? If it returns FALSE, I'm betting that
you're wrong and the handle is *not* valid. If it *does* return
FALSE,
call GetLastError() and see what the error code is.

Paul T.

I've got an app that reads data from the COM port on a PocketPC 2003
device. When the device goes to sleep (either by inactivity timeout
or
by pressing the on/off button) and is then woken up by pressing the
on/off button, the COM port stays asleep and doesn't receive any more
data.

The file handle remains open but all calls to Win32's ReadFile return
zero bytes.

If I close the file handle and open another one to the COM port,
everything works again.

Is there some way to "kick" the COM port back into life after the device
goes into sleep mode?

Cheers,

MikeS.

 

[Dick Grier]

Hi Mike,

Are you saying that closing the port, then reopening it does not restore
operation?

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Mike Scott]

Hi Dick

No, closing and reopening works, but it's only a workaround and has caused
us to have to rewrite part of our app. The port stops providing the input
even though the file handle seems valid - ReadFile still returns true but no
bytes are read.

Cheers,

MikeS.

 

[Mike Scott]

Hi Chris

I tried giving the port a "kick" by calling GetCommState then SetCommState
but it makes no difference. Is this what you mean by "resetting the DCB
settings?"

Indeed, I was hoping there was some call I was missing that would wake up or
reset the hardware and bring it back to life. Obviously opening the port
does it, but I hoped to find a way to do it having to close the port.

Cheers,

MikeS.

 

[Mike Scott]

Thanks Paul, that does indeed describe the problem I'm seeing. However, the
discussion speaks of the port stopping passing data when in low power state,
but hints that it should work again on resume. It doesn't work on resume for
me.

Cheers,

MikeS.

 

[Paul G. Tobey [eMVP]]

That wasn't the reading that I got from it. My interpretation was that the
port is probably reset by the resume process, but the driver doesn't handle
restoring its state to allow the existing handles to be used. So, you might
imagine that the port, on resume, is now set for 1200 baud, etc., rather
than the 9600 baud that you requested. Although data is received, the baud
rate mismatch (probably), causes it to be ignored...

Paul T.

Thanks Paul, that does indeed describe the problem I'm seeing. However,
the discussion speaks of the port stopping passing data when in low power
state, but hints that it should work again on resume. It doesn't work on
resume for me.

Cheers,

MikeS.

In that case, I'd contact the OEM technical support and tell them what
you're doing and that it seems to be working improperly. I'd also
prepare a C program that shows the problem, as that's easier for the OEM
to understand.

Here's a thread in the eVC newsgroup that might show the same problem as
you are seeing. Read all the responses and see if any help...

http://groups.google.com/groups?hl=...lem&meta=group%3Dmicrosoft.public.windowsce.*

Paul T.

Hi Paul

Already thought of that. The code checks the bool return and it's always
true - it throws an exception if false, and this never occurs.

The device is an O2 XDA II (made by HTC). It's also known as an MDA II
and various other vendor-specific names. It has a connector similar to
an IPAQ I believe, though the pinouts differ.

Cheers,

Mike.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message What sort of COM port is it (it's not really a DB-9 serial port, is
it?), and what device, specifically? What value does ReadFile return
(it returns a Boolean, remember)? If it returns FALSE, I'm betting
that you're wrong and the handle is *not* valid. If it *does* return
FALSE, call GetLastError() and see what the error code is.

Paul T.

I've got an app that reads data from the COM port on a PocketPC 2003
device. When the device goes to sleep (either by inactivity timeout or
by pressing the on/off button) and is then woken up by pressing the
on/off button, the COM port stays asleep and doesn't receive any more
data.

The file handle remains open but all calls to Win32's ReadFile return
zero bytes.

If I close the file handle and open another one to the COM port,
everything works again.

Is there some way to "kick" the COM port back into life after the
device goes into sleep mode?

Cheers,

MikeS.

 

[Chris Tacke, eMVP]

Yep, if calling SetCommState doesn't fix it, close and reopen is your only
option. The UART's in an undefined state on wake, and it sounds like the
PPC OAL doesn't persist the settings across the sleep.

 

[Mike Scott]

Hi Chris

Where should one report such a bug?

Cheers,

MikeS.

 

[Mike Scott]

Hi Paul

If that were the case, calling SetCommDCB should fix it, but it doesn't.
Secondly, an incorrect baud rate still results in data received, albeit
"scrambled" - I've tried it.

Chris Tacke's explanation seems the most likely.

Cheers,

Mike.

That wasn't the reading that I got from it. My interpretation was that
the port is probably reset by the resume process, but the driver doesn't
handle restoring its state to allow the existing handles to be used. So,
you might imagine that the port, on resume, is now set for 1200 baud,
etc., rather than the 9600 baud that you requested. Although data is
received, the baud rate mismatch (probably), causes it to be ignored...

Paul T.

Thanks Paul, that does indeed describe the problem I'm seeing. However,
the discussion speaks of the port stopping passing data when in low power
state, but hints that it should work again on resume. It doesn't work on
resume for me.

Cheers,

MikeS.

In that case, I'd contact the OEM technical support and tell them what
you're doing and that it seems to be working improperly. I'd also
prepare a C program that shows the problem, as that's easier for the OEM
to understand.

Here's a thread in the eVC newsgroup that might show the same problem as
you are seeing. Read all the responses and see if any help...

http://groups.google.com/groups?hl=...lem&meta=group%3Dmicrosoft.public.windowsce.*

Paul T.

Hi Paul

Already thought of that. The code checks the bool return and it's
always true - it throws an exception if false, and this never occurs.

The device is an O2 XDA II (made by HTC). It's also known as an MDA II
and various other vendor-specific names. It has a connector similar to
an IPAQ I believe, though the pinouts differ.

Cheers,

Mike.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com> wrote in message What sort of COM port is it (it's not really a DB-9 serial port, is
it?), and what device, specifically? What value does ReadFile return
(it returns a Boolean, remember)? If it returns FALSE, I'm betting
that you're wrong and the handle is *not* valid. If it *does* return
FALSE, call GetLastError() and see what the error code is.

Paul T.

I've got an app that reads data from the COM port on a PocketPC 2003
device. When the device goes to sleep (either by inactivity timeout
or by pressing the on/off button) and is then woken up by pressing
the on/off button, the COM port stays asleep and doesn't receive any
more data.

The file handle remains open but all calls to Win32's ReadFile return
zero bytes.

If I close the file handle and open another one to the COM port,
everything works again.

Is there some way to "kick" the COM port back into life after the
device goes into sleep mode?

Cheers,

MikeS.

 

[Guest]

Hi Mike!!!!

I have never tried the task that you want to do, but I'm daring to
suggest to see the posibility of changing your serial port flow control (or
"hardware protocol") to "none" and test this same scenario. Let me explain
some more: When using "hardware" protocol (and probably "software" protocol
as well), certain serial pins must have a signal present before sending
information. An example of these pins are "Request to Send" (RTS) and "Clear
to Send" (CTS). I'm suspecting that when your PDA goes to sleep, the voltage
present in RTS drops in such a way that your PC might think that the PDA is
gone, and therefore it clears the singal present in CTS. This same scenario
might apply to other pins like Data Terminal Ready (DTR) and Data Set Ready
(DTS). Later on, when your PDA wakes up, the UART does not put the RTS signal
back to its voltage, and therefore no comunication can be established.

By changing the hardware protocol to "none", no other signal but the
Receive Data and Transimtted Data pins are used.

I must mention that if you change your serial port flow control setting
to "none" you *might not* be able to use this port with ActiveSync since this
application relies on the extra pines to identify that a PDA is present.

I hope this helps!!!

Tarh ik
PS: This post has been posted "AS IS".
PS2: I agree with you, this is a bug.

 

[Mike Scott]

Hi Tarh ik

Interesting idea, thanks. I've already got control of the handshaking lines,
so I'll give that try. I can also check it with my RS-232 tester.

Cheers,

MikeS.

 

[Dick Grier]

Hi,
Where should one report such a bug?
<<

This is the device manufacturer's responsibility.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.

 

[Mike Scott]

Hi

Even if the bug is in ALL devices running PocketPC (as was suggested by
someone in this thread)? Sounds like it's a bug in WinCE not a
device-specific driver.

Cheers,

MikeS.

 

[Paul G. Tobey [eMVP]]

It *is* a specific driver; it just happens to be the easiest one for the PPC
manufacturers to use. You have to report it to the device makers. If they
feel like it's a problem with MS code, *they* will then report it to MS and,
probably, fix it themselves for their devices. Even if MS claimed it and
fixed the driver, that wouldn't do you any good. The device vendor is the
only one who can give you a new OS for your device; MS can't give you an
update.

Paul T.