Can't get C# app debugging working with WinCE 6.0

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

David K in San Jose - 23 Jul 2008 08:16 GMT

Sorry for the long post! I have seen other postings about this, but
haven't seen a solution to the problem, so I'm restating the problem
here. I wasn't able to get ActiveSync 4.2 to connect with my target
board via USB, so I'm now trying OpenNETCF's CeDbgSetup.exe tool to see
if I can debug via the known-good Ethernet connection to my target.

My Setup: I have successfully built, deployed to flash, and ran a WinCE
OS image for my Cogent CSB737 system-on-module target board (it uses an
ARM9 Atmel AT91SAM9263 CPU and also Adeneo's BSP for the CSB737). I
have written a C# application using VS2005 which I'm using to test
hardware features of the board, and I can deploy it to the target and
run it successfully. However, even though I have installed and run
CeDbgSetup.exe (available from OpenNETCF at
http://community.opennetcf.com/articles/cf/archive/2007/08/31/debugging-without-
activesync.aspx),
I am not able to get VS2005 to successfully deploy the application's
files and allow me to debug the application.

Here are the steps I'm following to debug my C# application:

1. I run one instance of VS2005 for my OS Design and click "Attach To
Device"; VS2005 waits to connect with my target board.

2. I power-up my target board. (I'm using KITL-over-ethernet, and can
see on VS2005's Output window all the usual WinCE start-up messages as
WinCE starts up.) The WinCE desktop appears normally on the target's
screen.

3. On the target, I run the CeDbgSetup.exe tool, which creates some
icons on the target's desktop, disables the CoreCon security by creating
a certain registry key, and launches CMAccept.exe and ConManClient2.exe.
So far, so good.

4. I run a 2nd instance of VS2005 for my C# project, which is targeted
at the SDK for my OS Design, and targets my WinCE device. When I click
the "Connect to Device" button in the VS2005 toolbar, it says
"Connection succeeded." (I had previously set the proper static IP
address of my target in the "Device Properties>Transport: TCP Connect
Transport>Configure" menu.) Again, so far, so good.

5. When I click "Start Debugging" in VS2005, it builds my C# project
successfully then attempts to Deploy it. It's communicates with the
target via TCP/IP and is able to successfully create a folder under
"Program Files" for the first DLL file of my application, and then it
creates a (zero-length) file for the DLL, and that's as far as it gets.
:-(

Here are the messages that appear in the Output window of VS2005:

------ Deploy started: Project: GPIODriver, Configuration: Debug Any CPU
------
Deploying 'I:\Software
Projects\Temp\CSB737_TestApp\WCEThreadInterface\bin\Debug\WCEThreadInterface.dll'
Deployment and/or registration failed with error: 0x8973190e. Error
writing file '%CSIDL_PROGRAM_FILES%\WCEThreadInterface.dll'. Error

0x8007274c: A connection attempt failed because the connected party did
not properly respond after a period of time, or established connection
failed because connected host has failed to respond.
------ Deploy started: Project: CSB737_TestApp1, Configuration: Debug
Any CPU ------
An existing connection was forcibly closed by the remote host.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 0 succeeded, 2 failed, 0 skipped ==========

So it seems like some kind of TCP/IP communication problem is occurring
when the first file is being sent to the target board. When I run
Ethereal to watch the net packets during the operation, I can't tell
exactly what I'm seeing, but it appears that some ACKs from the target
are not being received properly at my desktop, so VS2005 gives up after
a few seconds.

Note that I'm using an older Linksys unmanaged hub to connect my target
to my desktop, but I figure it's not causing a problem, since it has
been working fine (apparently, anyway) with KITL messages. And the same
hub is used to connect my desktop to the Internet for all my browsing
needs, and has never caused me any trouble.

This is getting to be quite frustrating, since I will definitely need
application debugging later on, so I want to figure this out as soon as
I can. Any ideas or help is greatly appreciated!

Regards,

David K in San Jose

Reply to this Message

Valter Minute - 23 Jul 2008 08:39 GMT

> Sorry for the long post! I have seen other postings about this,
> but haven't seen a solution to the problem, so I'm restating the
[quoted text clipped - 15 lines]
> application's
> files and allow me to debug the application.

Check that you don't have any firewall enabled on your PC and that
there is enough free space on the device object store.
If your OS image does not include the .NET compact framework you may
need to add support for CAB installer inside the image to allow Visual
Studio to deploy it.
Check also that the ConManClient2, CMAccept and other executables that
are installed on the device are for the same version of the .NET CF
and VS2005 service pack that you have on your PC.
You should find them under:
C:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target
\wce400\ARMV4I
Try to copy those files from your PC to the \Windows subdir of your
device and run ConnManClient2 and CMAccept manually and check if it
works.

Signature

Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Reply to this Message

Bradley Remedios - 23 Jul 2008 17:26 GMT

On Jul 23, 12:39 am, Valter Minute
<v_a_l_t_e_r.m_i_n_u_t_e@g_m_a_i_l.com> wrote:

> Check that you don't have any firewall enabled on your PC and that
> there is enough free space on the device object store.
[quoted text clipped - 10 lines]
> device and run ConnManClient2 and CMAccept manually and check if it
> works.

You may also want to try updating your version of ActiveSync. Mine
reports a version of 4.5 and we have seen issues debugging C# with our
devices if the ActiveSync version is really really old (I don't
remember if it was pre or post 4.2 for the one that didn't work.)

Hope this helps,

Reply to this Message

David K in San Jose - 23 Jul 2008 19:49 GMT

Thanks for the help, Valter. I do already have the .NET CF 2.0 and CAB
Installer components in my OS project.

As you suggested, I manually copied the connectivity files from the
C:\Program Files\...\ARMV41 folder of my workstation to the \Windows
folder on my target. Then I ran ConManClient2.exe and then CMAccept.exe
on the target, and then tried to start debugging my application in
VS2005, but I still get exactly the same result as before: When it
attempts to deploy the first DLL in my project, VS2005 reports,
"Deployment and/or registration failed with error: 0x8973190e. Error
writing file '%CSIDL_PROGRAM_FILES%\WCEThreadInterface.dll'. Error
0x8007274c: A connection attempt failed because the connected party did
not properly respond after a period of time, or established connection
failed because connected host has failed to respond."

Even though it did create my project's WCEThreadInterface.dll file in
the Program Files folder on my target, though it's zero bytes long.

Something screwy is going on here; I think I'll try to remove the old
Linksys hub from the equation by using a twist cable directly to my
development workstation. If that doesn't work, I'll try the other
posted suggestions I received.

Thanks again for the suggestions!

David K

Reply to this Message

MichaelH - 23 Jul 2008 17:08 GMT

Hello David...

I have used the following to connect to my ARM9 target, with good results.

1. Create a subproject called Connection_Manager.
2. In the *postlink.bat* file, create the following entries:
echo copying TcpConnectionA.dll
copy "c:\program files\common files\microsoft
shared\corecon\1.0\target\wce400\armv4i\TcpConnectionA.dll"
"%_PROJECTROOT%\cesysgen\oak\target\%_TGTCPU%\%WINCEDEBUG%"

Change this line to add the following
clientshutdown.exe
cmaccept.exe
ConmanClient2.exe
DeviceDMA.dll
eDbgTL.dll

* Although the above lines are for a debug compile, change the
"%_PROJECTROOT%\cesysgen\oak\target\%_TGTCPU%\%WINCEDEBUG%" to
"%_FLATRELEASEDIR%" for a release build.

3. Ensure that the CAB file installer is selected from the catalog.
4. Compile the image.
5. Start an instance of VS2005 and download the image to the target.
6. The VS2005 instance connecting the image to the target, use Target ->
Target Control (ALT - 1) and type *s conmanclient2* at the prompt. When the
prompt returns, type *s cmaccept* (do not use the * character). These
commands must be in the order that I describe.
7. Start a second VS2005 for your application, and verify that the IP
address to the target is correct for the TPC Connect Transport. Verify that
a connection can be made.
8. Start debugging your application.

I have not had to use the CeDbgSetup.exe tool when using this method.

Good luck.
Michael H

> Sorry for the long post! I have seen other postings about this, but
> haven't seen a solution to the problem, so I'm restating the problem
[quoted text clipped - 80 lines]
>
> David K in San Jose

Reply to this Message