Hi Dale,

I'm getting the same error after using my own generated SDK, so I think the problem is deeper than that. Using the ARMV4 processor seems to work, but not the ARMV4I.

Joe

From what I understand, generating your own SDK does not work due to a PB/eVC bug with ARMV4i. That is why logicpd has the SDK available for download, because they have to 'tweak' it to make it workaround the PB/eVC bug. Looks like they may have forgottent to do the 'tweak' with this new SDK.

Dale

That's interesting. Ihadn't heard that or seen it on the Web Site. Logic guys, is it true??

Joe

Ooops.

Found my problem, I was building ARMV4i Debug instead of ARMV4 Debug.

Dale

Dale and all,

I have seen the same problems as you and could only debug an app using embeddedVC4 if I used the ARMV4 debug, not the ARMV4i debug config.

This works fine for simple apps, but when including CEDDK.lib to access low level functions (here MmMapIoSpace) I get a compile error:

CEDDK.lib(CEDDK.dll) : fatal error LNK1112: module machine type 'THUMB' conflicts with target machine type 'ARM'

I am assuming we're supposed to use the ARMV4i tools and not ARMV4, but using ARMV4i gives me the 'Debugger Swap Error'.

could someone please clarify the situation with ARMV4 vs ARMV4i.

merry programming,

Andreas

The guys at Logic sent me a ceddk.lib for the ARMV4. I had to request it from them directly. They have confirmed there is a bug in the evc++ with the debugger for the 4i, so you have to use the 4. A side effect of this is you cannot currently build your own SDK from the Logic BSP cuz it only works for the 4i.

Hope this helps.

Hi,
So does that mean that if we want to target ARMv4i we can't use the LPD_ARMV4_SDK_002 in eVC++? Is the "bug" in the 4i debugger going to be fixed (and what timeline)?
Thx,
/michel

To the best of my knowledge and experience, that's what it means.

I spoke to Logic about this, apparently the debugger swap error is an eVC++ bug and Logic is eagerly awaiting MS to fix the problems. I got the ceddk.lib that works with ARMV4 from Logic and that works fine for building apps.

Andreas

Could you comment on this situation? Where are the things now? I've got the same problem with evc++ and activesync.
Neither installing the latest QFEs for Platform Bulder nor SP4 for EVC++ helped. No answer on forums either. Everybody says it's a compiler bug with ARMV4I, but I saw no solution yet.
What's the deal with ceddk.lib? May I use it with my SDK somehow to fix this problem, or it will be completely different SDK?

Shutov,

As yet Microsoft hasn't fixed the issue directly. Logic has a workaround for this but we are doing a bit more research into it to make sure that it's a safe and viable solution, once this completed the information will be posted in this thread.

Thank You,

Ok, how to debug programs on eVC++ now?

I switched to KITL, but it still the same message:

"eVC cannot locate a debugger able to debug the attached device.
The debugging session cannot begin."

The file is copied, so I can run the program from the device, but not debug.

Actually I use "Release" configuration of the Paltform, but I enabled "CE Target Control Support" and "Kernel Debugger" options. In addition, I only want to debug the program, not the kernel, so it shouldn't matter. And the program is compiled in "debug" configuration.

Added later:
OK, I found a very good answer on my question here http://www.logicpd.com/support/tdg/viewtopic.php?p=557#557.
Thank you.

A side effect of our using a "tweaked" A400V4 SDK rather than A400V4i SDK is that the machine type for new C++ projects defaults to ARM. However our BSP (including libraries like CEDDK.lib) is built with machine type set to THUMB, which is right for A400V4i.

The eVC++ compiler will refuse to link them so you have to tell eVC++ you want it to build thumb code for the application.

This is okay to do because Thumb is simply a subset of Arm architecture. Instructions are compressed into 16 bit wide operations codes and decompressed to 32 bit ARM instructions on execution. This makes the binaries a little bit smaller.

The solution for projects which need to link to A400V4i libraries is the following:

1. With your eVC++ project open, go to Project Settings.

2. Choose Release under the “Settings For” drop down menu

3. Under the Link tab, in the Project Options text box change /MACHINE:ARM to /MACHINE:THUMB

4. Choose Debug under the “Settings For” drop down menu

5. Repeat step 3.

Since each A400V4 project defaults the /MACHINE to ARM, this should be done once to each project which will link A400V4i libraries.

References:

http://msdn.microsoft.com...ml/cmrefLinking.asp)

http://msdn.microsoft.com...ml/ccrefARMGuide.asp

You can inspect the machine setting for a library using the dumpbin packaged with eVC++. For example:

D:\WINCE420\PLATFORM\LoCE_A400_rel_101\lib\ARMV4I\retail>dumpbin ceddk.lib /headers

<snip>

Version : 0

Machine : 1C2 (Thumb)

TimeDateStamp: 4084D20B Tue Apr 20 02:32:27 2004

SizeOfData : 00000020

DLL name : CEDDK.dll

Symbol name : WRITE_REGISTER_USHORT

Type : code

Name type : name

Hint : 35

Name : WRITE_REGISTER_USHORT



Summary

C0 .debug$S

14 .idata$2

14 .idata$3

4 .idata$4

4 .idata$5

A .idata$6

Hello,

The debugger swap error bug that was described in this thread has been fixed as of the release of lpd_kernel_a400_50_2_1_3_0 for WinCE 5.0. If you are interested in using Logic's LoCE Binary BSP Components please contact platformsupport@logicpd.com for more information on how to gain access to the BSP.

Thank you,