repllog failing

I'm having trouble with repllog on a semi-headless unit. It sends out
"CLIENT" on the proper COM port @ 19200 as it's supposed to, but I
don't get a response for an ActiveSync client.

Am I missing something based on the error messages?

Thanks,
Joel


0x8ff39400: RLOG: [0x2FD73ECA] Started with cmdline:
0x8ff39400: AddToProcessInputLocaleTable: Added process to
ProcessInputLocale table, hProcess = 0x2FD7376A0
x8ff39400: RLOG: [0x2FD73ECA] Using '`Desktop @ 19200`' connection
0x8ff39400: RLOG: [0x2FD73ECA] Welcome to repllog. Port in use:
Dccman: 5679; RRA: 5678
0x8ff39400: RLOG: [0x2FD73ECA] WM_WINDOWREADY
0x8ff39400: RLOG: [0x2FD73ECA] About to run rapisrv.exe
0x8fd73c94: AddToProcessInputLocaleTable: Added process to
ProcessInputLocale table, hProcess = 0x2FE29DC2
0x8fd73c94: +OEMIoControl(0x1010004, 0x1203fb54, 4, 0x1203fbe4, 520,
0x1203fb34)
0x8fd73c94: +OALIoCtlHalGetDeviceInfo(...)
0x8fd73c94: -OALIoCtlHalGetDeviceInfo(rc = 1)
0x8fd73c94: -OEMIoControl(rc = 1)
RpcSrv: Rapi Server running on DeviceType: 2
0x8ff39400: RLOG: [0x2FD73ECA] Using '`Desktop @ 19200`' connection
0x8ff39400: RLOG: [0x2FD73ECA] About to run rnaapp.exe -n -m -
e"`Desktop @ 19200`"
RpcSrv: Winsock Started version 1.1
RpcSrv: Fail to create IPv6 socket. Error=10047
0x8fdada34: <RPC:RESLIST> 0x8fdada34: CResList::CResList()
0x8fd2c424: AddToProcessInputLocaleTable: Added process to
ProcessInputLocale table, hProcess = 0x8FDB6CFE
0x8fedd000: AUTORAS:: Dialer notifies: [1] [Dialer Start]
0x8fee08d4: WaitCommEvent - Mask was cleared
0x8fee08d4: COM_Close: (1 handles) total RX 0, total TX 6, dropped
(mdd, pdd) 0,0
0x8fee08d4: COM_Close: (0 handles) total RX 0, total TX 6, dropped
(mdd, pdd) 0,0
0x8fd2c424: RASCS_Disconnected: Ecode=619
0x8fd2c424: DESTROY
0x8fd2c424: Posting WM_NETCONNECT(FALSE) message, ErrorCode =
619(0x26B)
0x8fd2c424: DeleteFromProcessInputLocaleTable: Deleted process from
ProcessInputLocale table, hProcess: 0x8FDB6CFE
0x8ff39400: RLOG: [0x2FD73ECA] Received WM_NET
CONNECT - 0, for '`Desktop @ 19200`'; fRnaAdrefed: 0
0x8ff39400: RLOG: [0x2FD73ECA] Received WM_NETCONNECT(FALSE) - haven't
yet seen WM_NETCONNECT(TRUE).
0x8ff39400: RLOG: [0x2FD73ECA] Received 'silent' Rnaapp error 619
0x8ff39400: _REPLLOG: IDM_STOP_REPLICATION. wParam: 1, lParam: 0
0x8ff39400: RLOG: [0x2FD73ECA] Quiting replication. 0 0 0 0 1
0x8fedd000: AUTORAS:: Dialer notifies: [2] [Dialer Terminate]
RpcSrv: Rapi Server received WM_STOP_RPC
RpcSrv: Rapi Server received WM_DESTROY
RpcSrv: Error from accept=10038
RpcSrv: select() failed, error 10038
0x8fdada34: <RPC:RESLIST> 0x8fdada34: CResList::~CResList()
0x8fd73c94: DeleteFromProcessInputLocaleTable: Deleted process from
ProcessInputLocale table, hProcess: 0x2FE29DC2
0x8ff39400: RLOG: [0x2FD73ECA] Done quiting replication. 0 0 0 0
0x8ff39400: RLOG: [0x2FD73ECA] Quiting replication. 0 0 0 0 1
0x8ff39400: RLOG: [0x2FD73ECA] Done quiting replication. 0 0 0 0
0x8ff39400: RLOG: [0x2FD73ECA] ========== WinMain ends here.
0===========
0x8ff39400: WARNING: Leaked registry key HKEY_CURRENT_USER\
\ControlPanel\Comm
0x8ff39400: WARNING: Leaked registry key HKEY_CURRENT_USER\
\ControlPanel\Comm
0x8ff39400: WARNING: Cleaned up 2 leaked registry handles for process
0x2FD7376A
0x8ff39400: DeleteFromProcessInputLocaleTable: Deleted process from
ProcessInputLocale table, hProcess: 0x2FD7376A

Chris
Mon May 19 20:00:01 PDT 2008

The port has handshaking lines (not just data)? ActiveSync requires them.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:8d1a7799-e7e1-4ddd-8422-99dcbf850d67@j33g2000pri.googlegroups.com...
> I'm having trouble with repllog on a semi-headless unit. It sends out
> "CLIENT" on the proper COM port @ 19200 as it's supposed to, but I
> don't get a response for an ActiveSync client.
>
> Am I missing something based on the error messages?
>
> Thanks,
> Joel
>
>
> 0x8ff39400: RLOG: [0x2FD73ECA] Started with cmdline:
> 0x8ff39400: AddToProcessInputLocaleTable: Added process to
> ProcessInputLocale table, hProcess = 0x2FD7376A0
> x8ff39400: RLOG: [0x2FD73ECA] Using '`Desktop @ 19200`' connection
> 0x8ff39400: RLOG: [0x2FD73ECA] Welcome to repllog. Port in use:
> Dccman: 5679; RRA: 5678
> 0x8ff39400: RLOG: [0x2FD73ECA] WM_WINDOWREADY
> 0x8ff39400: RLOG: [0x2FD73ECA] About to run rapisrv.exe
> 0x8fd73c94: AddToProcessInputLocaleTable: Added process to
> ProcessInputLocale table, hProcess = 0x2FE29DC2
> 0x8fd73c94: +OEMIoControl(0x1010004, 0x1203fb54, 4, 0x1203fbe4, 520,
> 0x1203fb34)
> 0x8fd73c94: +OALIoCtlHalGetDeviceInfo(...)
> 0x8fd73c94: -OALIoCtlHalGetDeviceInfo(rc = 1)
> 0x8fd73c94: -OEMIoControl(rc = 1)
> RpcSrv: Rapi Server running on DeviceType: 2
> 0x8ff39400: RLOG: [0x2FD73ECA] Using '`Desktop @ 19200`' connection
> 0x8ff39400: RLOG: [0x2FD73ECA] About to run rnaapp.exe -n -m -
> e"`Desktop @ 19200`"
> RpcSrv: Winsock Started version 1.1
> RpcSrv: Fail to create IPv6 socket. Error=10047
> 0x8fdada34: <RPC:RESLIST> 0x8fdada34: CResList::CResList()
> 0x8fd2c424: AddToProcessInputLocaleTable: Added process to
> ProcessInputLocale table, hProcess = 0x8FDB6CFE
> 0x8fedd000: AUTORAS:: Dialer notifies: [1] [Dialer Start]
> 0x8fee08d4: WaitCommEvent - Mask was cleared
> 0x8fee08d4: COM_Close: (1 handles) total RX 0, total TX 6, dropped
> (mdd, pdd) 0,0
> 0x8fee08d4: COM_Close: (0 handles) total RX 0, total TX 6, dropped
> (mdd, pdd) 0,0
> 0x8fd2c424: RASCS_Disconnected: Ecode=619
> 0x8fd2c424: DESTROY
> 0x8fd2c424: Posting WM_NETCONNECT(FALSE) message, ErrorCode =
> 619(0x26B)
> 0x8fd2c424: DeleteFromProcessInputLocaleTable: Deleted process from
> ProcessInputLocale table, hProcess: 0x8FDB6CFE
> 0x8ff39400: RLOG: [0x2FD73ECA] Received WM_NET
> CONNECT - 0, for '`Desktop @ 19200`'; fRnaAdrefed: 0
> 0x8ff39400: RLOG: [0x2FD73ECA] Received WM_NETCONNECT(FALSE) - haven't
> yet seen WM_NETCONNECT(TRUE).
> 0x8ff39400: RLOG: [0x2FD73ECA] Received 'silent' Rnaapp error 619
> 0x8ff39400: _REPLLOG: IDM_STOP_REPLICATION. wParam: 1, lParam: 0
> 0x8ff39400: RLOG: [0x2FD73ECA] Quiting replication. 0 0 0 0 1
> 0x8fedd000: AUTORAS:: Dialer notifies: [2] [Dialer Terminate]
> RpcSrv: Rapi Server received WM_STOP_RPC
> RpcSrv: Rapi Server received WM_DESTROY
> RpcSrv: Error from accept=10038
> RpcSrv: select() failed, error 10038
> 0x8fdada34: <RPC:RESLIST> 0x8fdada34: CResList::~CResList()
> 0x8fd73c94: DeleteFromProcessInputLocaleTable: Deleted process from
> ProcessInputLocale table, hProcess: 0x2FE29DC2
> 0x8ff39400: RLOG: [0x2FD73ECA] Done quiting replication. 0 0 0 0
> 0x8ff39400: RLOG: [0x2FD73ECA] Quiting replication. 0 0 0 0 1
> 0x8ff39400: RLOG: [0x2FD73ECA] Done quiting replication. 0 0 0 0
> 0x8ff39400: RLOG: [0x2FD73ECA] ========== WinMain ends here.
> 0===========
> 0x8ff39400: WARNING: Leaked registry key HKEY_CURRENT_USER\
> \ControlPanel\Comm
> 0x8ff39400: WARNING: Leaked registry key HKEY_CURRENT_USER\
> \ControlPanel\Comm
> 0x8ff39400: WARNING: Cleaned up 2 leaked registry handles for process
> 0x2FD7376A
> 0x8ff39400: DeleteFromProcessInputLocaleTable: Deleted process from
> ProcessInputLocale table, hProcess: 0x2FD7376A

Joel
Mon May 19 22:46:38 PDT 2008

The port I'm using has RTS and CTS signals. I was doing some testing
to see what signals ActiveSync was looking for. It ignores RTS
changing state, but reacts when DTR becomes active.

What exactly is the ActiveSync Serial port handshake other than the
"CLIENT"/"SERVER" exchange?


Joel

Chris
Tue May 20 07:45:32 PDT 2008

I think it's simply looking at the DTR (I didn't recall exactly which line,
which is why I doidn't say in the first reply) state change to react and
nothing more after that. You checked and you're getting CLIENT and SERVER
both (one from each end)?


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:c4bc8014-ad6a-4c6c-ad9b-aaefc705e22d@y18g2000pre.googlegroups.com...
> The port I'm using has RTS and CTS signals. I was doing some testing
> to see what signals ActiveSync was looking for. It ignores RTS
> changing state, but reacts when DTR becomes active.
>
> What exactly is the ActiveSync Serial port handshake other than the
> "CLIENT"/"SERVER" exchange?
>
>
> Joel

Bruce
Tue May 20 08:39:43 PDT 2008

The first thing that I do when I see this problem is get a known good
working cable. That means know to work with ActiveSync. For this I use a
Belkin F3B207-10.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:eTsAzgouIHA.552@TK2MSFTNGP06.phx.gbl...
>I think it's simply looking at the DTR (I didn't recall exactly which line,
>which is why I doidn't say in the first reply) state change to react and
>nothing more after that. You checked and you're getting CLIENT and SERVER
>both (one from each end)?
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
>
> "Joel Winarske" <joel.winarske@gmail.com> wrote in message
> news:c4bc8014-ad6a-4c6c-ad9b-aaefc705e22d@y18g2000pre.googlegroups.com...
>> The port I'm using has RTS and CTS signals. I was doing some testing
>> to see what signals ActiveSync was looking for. It ignores RTS
>> changing state, but reacts when DTR becomes active.
>>
>> What exactly is the ActiveSync Serial port handshake other than the
>> "CLIENT"/"SERVER" exchange?
>>
>>
>> Joel
>
>

Chris
Tue May 20 08:51:02 PDT 2008

Agreed - it sounds suspiciously like a cable problem. I use the one in my
drawer marked "ActiveSync" with a Sharpie - not quite as reproducible as
Bruce's model, but the point is it's a cable *known* to work with AS.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"Bruce Eitman [eMVP]" <bruce.eitman.nospam@EuroTech.com.nospam> wrote in
message news:%23vol6%23ouIHA.4376@TK2MSFTNGP06.phx.gbl...
> The first thing that I do when I see this problem is get a known good
> working cable. That means know to work with ActiveSync. For this I use a
> Belkin F3B207-10.
>
> --
> Bruce Eitman (eMVP)
> Senior Engineer
> Bruce.Eitman AT EuroTech DOT com
> My BLOG http://geekswithblogs.net/bruceeitman
>
> EuroTech Inc.
> www.EuroTech.com
>
> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
> news:eTsAzgouIHA.552@TK2MSFTNGP06.phx.gbl...
>>I think it's simply looking at the DTR (I didn't recall exactly which
>>line, which is why I doidn't say in the first reply) state change to react
>>and nothing more after that. You checked and you're getting CLIENT and
>>SERVER both (one from each end)?
>>
>>
>> --
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Giving back to the embedded community
>> http://community.OpenNETCF.com
>>
>>
>>
>> "Joel Winarske" <joel.winarske@gmail.com> wrote in message
>> news:c4bc8014-ad6a-4c6c-ad9b-aaefc705e22d@y18g2000pre.googlegroups.com...
>>> The port I'm using has RTS and CTS signals. I was doing some testing
>>> to see what signals ActiveSync was looking for. It ignores RTS
>>> changing state, but reacts when DTR becomes active.
>>>
>>> What exactly is the ActiveSync Serial port handshake other than the
>>> "CLIENT"/"SERVER" exchange?
>>>
>>>
>>> Joel
>>
>>
>
>

Bruce
Tue May 20 10:07:57 PDT 2008

I just checked my drawer, I don't have one marked "ActiveSync". I will keep
looking.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
news:udmhfFpuIHA.4772@TK2MSFTNGP03.phx.gbl...
> Agreed - it sounds suspiciously like a cable problem. I use the one in my
> drawer marked "ActiveSync" with a Sharpie - not quite as reproducible as
> Bruce's model, but the point is it's a cable *known* to work with AS.
>
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded community
> http://community.OpenNETCF.com
>
>
> "Bruce Eitman [eMVP]" <bruce.eitman.nospam@EuroTech.com.nospam> wrote in
> message news:%23vol6%23ouIHA.4376@TK2MSFTNGP06.phx.gbl...
>> The first thing that I do when I see this problem is get a known good
>> working cable. That means know to work with ActiveSync. For this I use
>> a Belkin F3B207-10.
>>
>> --
>> Bruce Eitman (eMVP)
>> Senior Engineer
>> Bruce.Eitman AT EuroTech DOT com
>> My BLOG http://geekswithblogs.net/bruceeitman
>>
>> EuroTech Inc.
>> www.EuroTech.com
>>
>> "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com> wrote in message
>> news:eTsAzgouIHA.552@TK2MSFTNGP06.phx.gbl...
>>>I think it's simply looking at the DTR (I didn't recall exactly which
>>>line, which is why I doidn't say in the first reply) state change to
>>>react and nothing more after that. You checked and you're getting CLIENT
>>>and SERVER both (one from each end)?
>>>
>>>
>>> --
>>>
>>> Chris Tacke, Embedded MVP
>>> OpenNETCF Consulting
>>> Giving back to the embedded community
>>> http://community.OpenNETCF.com
>>>
>>>
>>>
>>> "Joel Winarske" <joel.winarske@gmail.com> wrote in message
>>> news:c4bc8014-ad6a-4c6c-ad9b-aaefc705e22d@y18g2000pre.googlegroups.com...
>>>> The port I'm using has RTS and CTS signals. I was doing some testing
>>>> to see what signals ActiveSync was looking for. It ignores RTS
>>>> changing state, but reacts when DTR becomes active.
>>>>
>>>> What exactly is the ActiveSync Serial port handshake other than the
>>>> "CLIENT"/"SERVER" exchange?
>>>>
>>>>
>>>> Joel
>>>
>>>
>>
>>
>
>

Joel
Tue May 20 11:38:55 PDT 2008

The target sends out "CLIENT" as expected. ActiveSync does not
respond. This particular target does not support DTR/DSR.

The same cables have worked with ActiveSync/Serial on different
targets. So the cable is no problem. One is actually from a Graphics
Master development board.


I have noticed the application ActiveSync changes state to
"connecting" when DTR goes active. It does not respond to RTS being
asserted. I have validated RTS wiggling with a serial monitoring
tool.

This worked without a hitch on my old CEPC.

Joel
Tue May 20 11:50:26 PDT 2008

I think I need to fake out the ActiveSync client by jumpering some
pins.

I will try multing:
DCD
DTR
DSR
RI

Paul
Tue May 20 11:48:19 PDT 2008

If the device doesn't support the handshake signals, AS will not work. It
requires that those signals make it all the way from the CE device to the PC
and back. That's why the cable is so critical. If it's just an ordinary
null-modem cable without handshaking signals, it's useless.

Paul T.

"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:549d130b-504d-48f0-bf8a-742134b63183@a9g2000prl.googlegroups.com...
> The target sends out "CLIENT" as expected. ActiveSync does not
> respond. This particular target does not support DTR/DSR.
>
> The same cables have worked with ActiveSync/Serial on different
> targets. So the cable is no problem. One is actually from a Graphics
> Master development board.
>
>
> I have noticed the application ActiveSync changes state to
> "connecting" when DTR goes active. It does not respond to RTS being
> asserted. I have validated RTS wiggling with a serial monitoring
> tool.
>
> This worked without a hitch on my old CEPC.

Paul
Tue May 20 12:11:39 PDT 2008

The problem is that the serial driver needs to know that, when AS tells it
to change the state of DSR, say, that something happens that ends up
changing the state of that signal at the other end of the cable. Ditto
incoming handshaking signals: they have to be detected by the serial port as
the right signals. I don't think that you can fake this without at least
modifying the serial driver.

Paul T.

"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:bf73dfd2-e380-4937-9f44-4b4548a53707@l17g2000pri.googlegroups.com...
>I think I need to fake out the ActiveSync client by jumpering some
> pins.
>
> I will try multing:
> DCD
> DTR
> DSR
> RI

Bruce
Tue May 20 12:11:37 PDT 2008

Joel:

Right, the cable is good, but as far as ActiveSync goes you need the
handshaking. Luckily, you can loop the handshaking back to the PC and it
will work. I don't recall what needs to be looped back, but I think you are
on the right track.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:bf73dfd2-e380-4937-9f44-4b4548a53707@l17g2000pri.googlegroups.com...
>I think I need to fake out the ActiveSync client by jumpering some
> pins.
>
> I will try multing:
> DCD
> DTR
> DSR
> RI

Joel
Tue May 20 12:27:55 PDT 2008

On May 20, 11:48=A0am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
> If the device doesn't support the handshake signals, AS will not work. =A0=
It
> requires that those signals make it all the way from the CE device to the =
PC
> and back. =A0That's why the cable is so critical. =A0If it's just an ordin=
ary
> null-modem cable without handshaking signals, it's useless.
>

It's a real null modem cable the target only implements
TxD,RxD,Gnd,RTS,CTS.


When I jumper DTR/DSR on the target side, ActiveSync sends
"CLIENTSERVER", followed by a 73 byte packet.

After which GetStatus() on my serial driver is called twice,SetDTR()
is called once, then the port closes with the following error:

0x8fdb7850: AM: SetCommMask failed, error=3D6
0x8feb55c8: RASCS_Disconnected: Ecode=3D619


As a test I will generate a DSR event whenever SetDTR() is called.


The end goal here is to get SmartDevice debugging going on a headless
system with limited hardware handshaking. Plan B is to implement USB
Function via bed of nails, or rework board for DSR/DTR via some spare
GPIO pins. Either of which is not a happy solution for my customer.

Chris
Tue May 20 12:42:58 PDT 2008

IIRC this is exactly how I did it on the old Graphics Master - the other
option is to use one of the UARTS on the device that fully supports the
handshaking lines.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"Joel Winarske" <joel.winarske@gmail.com> wrote in message
news:bf73dfd2-e380-4937-9f44-4b4548a53707@l17g2000pri.googlegroups.com...
>I think I need to fake out the ActiveSync client by jumpering some
> pins.
>
> I will try multing:
> DCD
> DTR
> DSR
> RI

Joel
Tue May 20 13:03:28 PDT 2008

Unfotunately emulating a simple DSR event whenever Set DTR is called
is not enough.

I think it is possible to do by implementing by implementing a state
machine in the serial driver, using the Set DTR function count etc.

I don't have a working reference available till next week, so my plan
B is to implement DTR/DSR with an external converter scheme and two
spare GPIO. Once this works of course the customer will complain it's
too slow.


So word to the wise - have your hardware person implement DTR/DSR/RTS/
CTS on any port to be used with serial ActiveSync.

Thankfully I'm just the messenger on this one.


Joel



On May 20, 12:27=A0pm, Joel Winarske <joel.winar...@gmail.com> wrote:
> On May 20, 11:48=A0am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
> no instrument no spam DOT com> wrote:
>
> > If the device doesn't support the handshake signals, AS will not work. =
=A0It
> > requires that those signals make it all the way from the CE device to th=
e PC
> > and back. =A0That's why the cable is so critical. =A0If it's just an ord=
inary
> > null-modem cable without handshaking signals, it's useless.
>
> It's a real null modem cable the target only implements
> TxD,RxD,Gnd,RTS,CTS.
>
> When I jumper DTR/DSR on the target side, ActiveSync sends
> "CLIENTSERVER", followed by a 73 byte packet.
>
> After which GetStatus() on my serial driver is called twice,SetDTR()
> is called once, then the port closes with the following error:
>
> 0x8fdb7850: AM: SetCommMask failed, error=3D6
> 0x8feb55c8: RASCS_Disconnected: Ecode=3D619
>
> As a test I will generate a DSR event whenever SetDTR() is called.
>
> The end goal here is to get SmartDevice debugging going on a headless
> system with limited hardware handshaking. =A0Plan B is to implement USB
> Function via bed of nails, or rework board for DSR/DTR via some spare
> GPIO pins. =A0Either of which is not a happy solution for my customer.

Joel
Tue May 20 13:36:32 PDT 2008

I believe the Graphics Master development kit I purchased was prior to
you starting at ADS. It had 3.0 on it. I also had purchased a Bitsy
development kit with the 4.0 BSP. Both of which I still have.

When I have nothing better to do and the proper resources, I'll
determine exactly what DTR/DSR is doing with ActiveSync.

Thanks for the input guys,
Joel


On May 20, 12:42=A0pm, "Chris Tacke, eMVP" <ctacke.at.opennetcf.dot.com>
wrote:
> IIRC this is exactly how I did it on the old Graphics Master - the other
> option is to use one of the UARTS on the device that fully supports the
> handshaking lines.