0

I have to port a C++ Win32 console application to WEC7. After I fixed some build and link errors I was able to create an executable that runs on the target. But I could not debug that application with Visual Studio, because the breakpoints were not hit, although the corresponding lines were definitly executed.

To further investigate my problem I created 2 new projects:

  1. Win32 project

  2. Win32 Smart Device project

Both include the following code:

#include "stdio.h"
void main(void)
{
    int i=0;
    while(1)
    {
        printf("i=%d\n",i);
        i++;
    }
}

At this point I can debug both projects, one running on my notebook at Windows 7 and one running at my target on WEC7. Now I have changed the platform solution from project 1 (Win32 project) to my target:

  • copied settings from Win32 platform

  • set Debug Information Format from 4 to /Zi (no idea where the 4 came from)

  • added some WEC7 Preprocessor Definitions

  • deployed the programm to the target and it works fine (the counter is printed in the console), no difference to project 2

  • tried to debug the program, but the breakpoints at the counter and the printf were not hit

I checked the following settings:

  • Solution Configuration set to Debug

  • Optimization is Disabled

  • Generate Debug Info set to Yes

  • compared the command line of the linker between project 1 (my "converted" version) and project 2 (Win32 Smart Device project), but they are identical -> Update: Actually they were not identical at all. Don't know what I compared the first time, but after I updated the settings it worked fine.

I have installed the following Visual Studio Updates:

Do I need to change a specific setting? Or do I need to change my approach?

I have mostly done model based software design (Mathworks Embedded Coder, dSPACE Targetlink), so I not familiar with Visual Studio and WEC7 specific characteristics. I would very much appreciate any help.

Christian Rießland
  • 21
  • 3
  • *"After some build and link errors I was able to create an executable..."* That doesn't sound right to me. If you're getting build and link errors, you aren't going to generate an executable. Do you mean that you *fixed* the errors? – Cody Gray - on strike Aug 08 '14 at 14:34
  • At any rate, if you have an endless loop with the breakpoint *outside* of that loop, then no—the breakpoint will never be hit. That should be obvious, since the loop never terminates! The code there never runs, either. It isn't just the breakpoints that are broken. What, exactly, are you trying to accomplish? – Cody Gray - on strike Aug 08 '14 at 14:35
  • I would create new project (using template) for WCE platform and check if debugging works on it. Then check which options should be used in your actual project. The easiest way is to look into 'Commmand Line' for Compiler and Linker in project properties. Maybe its a problem with path to pdb file? – marcinj Aug 08 '14 at 15:01
  • @CodyGray Sorry for my bad english, of course i meant "..after I fixed some..". Furthermore the counter and the printf are inside the loop and the code is being executed, but the breakpoint will not be hit. – Christian Rießland Aug 11 '14 at 14:35
  • @marcin_j I created an new project for WCE and the debugging works fine, but the "command line" for compiler and linker is identical to the "converted" version. – Christian Rießland Aug 11 '14 at 14:39

2 Answers2

0

This solved my Problem:

  1. I created a new project (using template) for WCE platform and checked if debugging works.
  2. Then I checked which options should be used in my actual project by comparing 'Commmand Line' for Compiler and Linker in project properties.

There were several differences and after I cleaned them up, my project worked fine.

Thx @brightstar

Christian Rießland
  • 21
  • 3
-1

There are several Updates for VS2008 to make it Debug on Windows Embedded Compact 7. Did you install them?

For example there is http://www.microsoft.com/en-us/download/details.aspx?id=11935

Fabian
  • 16
  • 2
  • It provides an answer to the question in a way that it points out there is a known bug with the specific debugger (VS2008) on the specific system (Windows Embedded Compact 7) doing exactly what is described as the error (not hitting breakpoints) even providing a downloadlink. So why do you want to deleat it? And I do not have enough reputation to post it as a commend under the main post. – Fabian Aug 12 '14 at 10:07
  • @Fabian I have already installed this particular update you have linked, but I could not find any others relating to my problem. – Christian Rießland Aug 12 '14 at 10:45
  • @ChristianRießland Are you shure, you are running the right exe? If the two assemblys do have the same name maybe the wrong one gets executed, doing the right output but without hitting the breakpoints. – Fabian Aug 12 '14 at 11:22
  • Where does the answer say anything about a known bug? It just says "oh, there are some updates; here is a link". Not only are link-only answers *strongly* discouraged, this answer **does not answer the question**. It only provides a *potential* answer. Possibly helpful advice, but not an answer. Those should be posted as comments instead. – Cody Gray - on strike Aug 13 '14 at 03:59
  • @CodyGray Ok. So tell me, what is the protocoll when trying to post a potential anser or possibly hepful advice, but beeing to new at stackoverflow to be allowed to post comments? – Fabian Aug 13 '14 at 07:13
  • The protocol is to post a comment. If you don't have sufficient reputation to post a comment, then you can't post one. It's that simple. The point of this site, as pointed out in the [About] page, is to *get answers*. Not to get potentially useful advice. It is not a web forum, it is a Q&A site. If you cannot answer the question, or the question contains insufficient information to be answered, then you cannot answer it. You just have to move along, answering other questions until you get commenting privileges. It doesn't take that long; a score of 50 is only 5 upvotes on answers. – Cody Gray - on strike Aug 13 '14 at 07:52