Problems debugging MIPSII_FP with CE 6.0 - "Step into" and remote tools are broken

F11 (step into function) is broken in MIPSII_FP builds under Wince 6.0. This
is reproduced on the NEC Rockhopper Vr5500 standard reference platform as
well as on our own BSP.

All other run-to-breakpoint operations (i.e. step out of, run to cursor, set
a break point and hit 'Run') work as expected.

Additionally, we have had no success getting any of the remote tools to
connect to a Rockhopper BSP built with MIPSII_FP architecture.

F11 and the Remote Tools work as expected with MIPSIV_FP builds (our
platform and the Rockhopper). We have not investigated MIPSII (non FP)
builds - that work is in progress.

It would be valuable if these faults were corrected in any future SP
releases. The remote tools are an essential piece of the development suite.
--
-Richard Lee eMVP

Sue
Tue Nov 28 15:04:04 CST 2006

I am guessing this is not really broken on all MIPSII_FP devices, but just
your setup. Our test team should be testing things like this on all CPUs.

I would like to get to the point where whenever someone hits problems like
this, they can easily a detailed doc about how to troubleshoot the problems.
I am doing my best to get us there, but I don't have the expertise yet to
contribute information on my own. I have no clue whatsoever about the
debugger functionality; I'll ask someone else to come comment on it. For
the remote tools, I'm just starting to learn my way around. Here is my
current "dumping ground" of information. I make no claims about how useful
or correct it is!! :-)
SYSGEN variables required by CoreCon:

SYSGEN_CORELOC=1
SYSGEN_CORESTRA=1
SYSGEN_STDIOA=1
SYSGEN_CPP_EH_AND_RTTI=1

a.. If you are having trouble with perf tools like Kernel Tracker or
CECAP, first double check that simpler tools like File Viewer or RegEdit
connect. To eliminate CeLog or other tool helpers as the problem.
b.. The Visual Studio corecon tools (Start -> Programs -> Microsoft Visual
Studio 2005 -> Visual Studio Remote Tools) are using a slightly different
version of CoreCon than Platform Builder (Target menu inside VS). Be clear
on which one you are using.
c.. Check the dates of VS corecon files, by looking at the timestamps
under c:\Program Files\CE Remote Tools\. 4/11/2005 is the date for VS2005
RTM files.
d.. Try deleting and recreating your device settings under Target ->
Connection Settings.
e.. Try deleting ALL device settings by deleting or renaming the
c:\Documents and Settings\(user)\Local Settings\Application
Data\Microsoft\CoreCon\1.0 directory. (Warning I believe that when I did
this, I caused myself to run into the problem in the next bullet point.)
f.. Some connection failures are caused by looking for files of the wrong
version or under the wrong path. Correlate your device settings against the
files that actually exist on your PC. Compare the paths inside c:\Documents
and Settings\(user)\Local Settings\Application
Data\Microsoft\CoreCon\1.0\conman_ds_package.xsl to those on your disk.
If you are trying to connect Visual Studio corecon to a device that's
connected to PB, this may work:

1.. Copy c:\Program Files\Common Files\Microsoft
Shared\corecon\1.0\Target\wce400\%_TGTCPU%\* to the release dir
2.. Copy c:\Program Files\Windows CE Platform
Builder\5.00\CORECON\TARGET\%_TGTCPU%\tlkitlc.dll to the release dir (Or, in
CE6, c:\Program Files\Microsoft Platform
Builder\6.00\CORECON\TARGET\%_TGTCPU%\tlkitlc.dll)
3.. Boot the CEPC image (or whatever your device is) inside PB
4.. Open a VS remote tool through Start Menu -> VS2005 -> Remote Tools and
connect.
I will blog (and document) this stuff when I feel it's complete enough to be
more useful. Right now I feel like I haven't hit enough scenarios, that
there must be more issues lurking. Plus I don't understand what's going on
behind the scenes yet. So it's still a dumping ground.

Sue
sloh@microsoft.com (remove "online" from reply-to address)
http://blogs.msdn.com/ce_base/
_____________________________________________________________
This posting is provided "AS IS" with no warranties, and confers no rights.
_____________________________________________________________

Richard
Tue Nov 28 21:35:12 CST 2006

>I am guessing this is not really broken on all MIPSII_FP devices, but just
>your setup. Our test team should be testing things like this on all CPUs.

Nice thought. But not the case.

From a reliable source within the Redmond puzzle palace:
"We historically test the debugger against MIPS2 and MIPS4FP to try to cover
the most ground and we have not seen any issues in those platforms."

In short, MIPSII_FP and MIPSIV builds are _not_ tested by the debugger and
remote tools folks.


--
-Richard Lee eMVP

Gary
Wed Nov 29 10:55:51 CST 2006

Hi Richard,
Do you know where I can buy a NEC Rockhopper?
In addition to CEPC, I'd like to find a platform where I can test my flash
driver.
There's not many platforms supported in the box where I can plug in flash
devices, but the PCI bus on NEC Rockhopper would let me do that...

Thanks,
Gary
garret.swalling@spansion.com.nospam

"Richard Lee eMVP" <Richardl_at_ati_dot_com> wrote in message
news:udwdld2EHHA.4024@TK2MSFTNGP04.phx.gbl...
> >I am guessing this is not really broken on all MIPSII_FP devices, but
> >just your setup. Our test team should be testing things like this on all
> >CPUs.
>
> Nice thought. But not the case.
>
> From a reliable source within the Redmond puzzle palace:
> "We historically test the debugger against MIPS2 and MIPS4FP to try to
> cover the most ground and we have not seen any issues in those platforms."
>
> In short, MIPSII_FP and MIPSIV builds are _not_ tested by the debugger and
> remote tools folks.
>
>
> --
> -Richard Lee eMVP
>
>