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.

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>

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 news:(E-Mail Removed)...
> 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" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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.
>>
>
>

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=e...ic.windowsce.*

Paul T.

"Mike Scott" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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 news:(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> 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.
>>>
>>
>>
>
>

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.

--
<ctacke/>
www.OpenNETCF.org
Your CF searches start and end here


"Mike Scott" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>

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]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:(E-Mail Removed)...
> 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=e...ic.windowsce.*
>
> Paul T.
>
> "Mike Scott" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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 news:(E-Mail Removed)...
> >> 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" <(E-Mail Removed)> wrote in message
> >> news:(E-Mail Removed)...
> >>> 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.
> >>>
> >>
> >>
> >
> >
>
>

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.

"ORC" <(E-Mail Removed)> wrote in message
news:eSMY4$(E-Mail Removed)...
> 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]" <ptobey no spam AT no instrument no spam DOT com>
> wrote in message news:(E-Mail Removed)...
>> 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=e...ic.windowsce.*
>>
>> Paul T.
>>
>> "Mike Scott" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > 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 news:(E-Mail Removed)...
>> >> 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" <(E-Mail Removed)> wrote in message
>> >> news:(E-Mail Removed)...
>> >>> 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.
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

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.

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.

"Dick Grier" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
>

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.

"Chris Tacke, eMVP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> --
> <ctacke/>
> www.OpenNETCF.org
> Your CF searches start and end here
>
>
> "Mike Scott" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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.
>>
>
>