Debug existing project – not created with File – New Embedded Project Wizard?

Sysprogs forums Forums VisualGDB Debug existing project – not created with File – New Embedded Project Wizard?

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #10146
    gojimmypi
    Participant

    Is it possible to add/modify debugging on an existing project in Visual Studio 2015?

    For example, I have a project created for VisualMicro debugging; can I modify the debug method to instead use the VisualGDB debugger, or do I need to start an entirely new project with the wizard and copy all the source code from the existing project?

    If a new is needed project, can both project & solution files for each of the respective debuggers live in the same directory, each sharing the same source files?

    Thanks

    #10147
    support
    Keymaster

    Hi,

    The easiest way to do that would be to use the Quick Debug feature. Alternatively you can add the ‘VisualGDB’ platform to an existing project via VS Configuration Manager and manually set properties like ‘Toolchain’ and ‘VisualGDB Settings’ file via VS project properties. You can copy the .vgdbsettings file from an existing VisualGDB project as well as the other settings.

    #10149
    gojimmypi
    Participant

    that’s a cool feature! the link is to a Linux debug, however I am trying to quick debug an embedded ESP8266 app using a Segger J-Link. Is that possible?

    I’m really close, as shown in the pics for setup & test:

    https://twitter.com/gojimmypi/status/822808553895247873

    However when debugging, I end up with a “Frame not in module, The current stack frame was not found in a loaded module”.  Is any additional software needed for ESP8266 quick debugging?

     

     

    #10152
    support
    Keymaster

    Hi,

    Thanks for the screenshot. The setup looks correct, but the “JTAG scan chain interrogation failed” error suggests something is wrong with the wiring.

    As mentioned in the previous posts, ESP8266 devices could be tough from the reliability point of view, so we would recommend starting with a board that we have successfully tested and then moving back to NodeMCU once you can confirm that the rest of the setup works. Otherwise it’s hard to diagnose what’s going on as ESP8266 does not report the internal errors in a very understandable way.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.