[support]

Hi,

Most likely your library was compiled without debugging symbols. You need to rebuild it yourself with debugging mode enabled (-ggdb) in order to be able to step into it.

If you want to use Plain C, simply use files with .c extension, they will be compiled as C, not C++.

[support]

Hi,

We are currently working on a new IntelliSense engine that will solve the type of problems you are experiencing. As a workaround, you can update the definition of __MINGW_NOTHROW in _mingw.h:

#ifdef _MSC_VER
#define __MINGW_NOTHROW
#else

//Original definition
#if  __MINGW_GNUC_PREREQ (3, 3)
#define __MINGW_NOTHROW __attribute__ ((__nothrow__))
#else
#define __MINGW_NOTHROW
#endif /* GNUC >= 3.3 */



#endif

[support]

Hi,

We’ve added support for running gdb via sudo a few versions ago. See the “run debugger as root with sudo” checkbox on the Debug Settings page.

[support]

Hi,

Please try this build: http://visualgdb.com/tmp/VisualGDB-4.3.1.180.msi

[support]

Hi,

This looks like either your project file got damaged, or the VS installation got damaged. Does re-creating the project with VIsualGDB wizard help? Note that the VisualGDB settings are stored in the .vgdbsettings files that are separate from VS projects and can be copied back after you re-create the project.

[support]

Hi,

We tried copy-pasting the XML fragment you posted into a .vgdbsettings file, but it did not cause any exceptions. If you could reproduce it and share a repro file, we should be able to fix it easily.

[support]

Hi,

We have added support for ‘detaching’ projects from BSPs to the upcoming VisualGDB 4.3.
Please switch to a newer version of GNU Make. The one that comes with our toolchains supports the c:/xxx path syntax in .dep files properly.
Running make.exe without cmd used to cause some random crashes in some cases. We did not investigate this further, as it looks like a bug specific to some versions of GNU Make for Windows and using cmd fixes it.

[support]

Hi,

We could not reproduce this on our side. Could you please share the entire .vgdbsettings file?

[support]

Hi,

We don’t provide any officially supported tools for generating the BSP packages. However, you can generate one by modifying the existing package XML files in other BSPs. The BSP XML files are produced by the .Net serializer from objects inside the BSPEngine assembly, so you can make a new C# application, reference BSPEngine.dll and manipulate the XML files programmatically:

using BSPEngine;
...
BoardSupportPackage bsp = XmlTools.LoadObject(@"c:xxxBSP.xml");

bsp.SupportedMCUs = ...;

XmlTools.SaveObject(bsp, @"c:yyyBSP.xml");

We do have an internal tool that parses the STM32 headers and generates peripheral register definitions, but it’s highly specific to STM32, as it needs to extract the information from the comments and internal file layout. You can try extracting the register layouts from the Atmel Studio IDE if their license permits doing that.

[support]

Hi,

That is very strange. What happens if you start Command Prompt and manually run the following commands:

cd /d C:UsersKelsARCommLinuxHelloWorldLinuxHelloWorld
"C:SysGCCraspberrybinmake.exe" CONFIG=Debug
type Makefile

Does Make still complain about a missing Makefile? Does your source directory have some non-typical access rights? What happens if you try setting the access to the current user to ‘full control’?

[support]

Hi,

It looks like the C:UsersKelsARCommLinuxHelloWorldLinuxHelloWorld directory is missing the ‘Makefile’ file that is required to build your project. Normally it is generated by the wizard. Can you try creating another project? Is Makefile generated then?

[support]

Hi,

Cleaning the solution is not sufficient. You need to delete some ant-specific cache files outside the binary directory. You can read more by following the link in the previous post.

[support]

Hi,

This looks like a known Android bug. Please try suggestions here: https://code.google.com/p/android/issues/detail?id=60496

[support]

OK, that rules out SSH communication problems. So it looks like GDB cannot receive signals from your program (are they handled by some Docker component instead?). Does it only happen in the “–interpreter MI” mode or in the normal command-line GDB mode as well? If you can make a repro case consisting of just a “hello, world” program and a GDB failing to stop at a breakpoint, the Docker support might be able to provide more help as they know Docker internals.

[support]

Hi,

First of all, VisualGDB uses the mspgcc compiler to build code for msp430, so many tricks that work for gcc/mspgcc will work with VisualGDB.
Regarding the initialization code, you need to make a separate function and put it to one of the .initX sections:

	;; .init0 (_reset_vector__: Start here after reset)
;; .init1 (User definable)
;; .init2 (__init_stack: Initialize stack)
;; .init3 (__low_level_init: Initialize hardware; user definable)
;; .init4 (__do_copy_data; __do_clear_bss: Copy data to .data, clear bss)
;; .init5 (User definable)
;; .init6 (__do_global_ctors: C++ constructors)
;; .init7 (User definable)
;; .init8 (User definable)
;; .init9 (main)
;; .fini9 (__stop_progExec__: Falls into here after main(). User definable)
;; .fini8 (User definable)
;; .fini7 (User definable)
;; .fini6 (C++ destructors)
;; .fini5 (User definable)
;; .fini4 (User definable)
;; .fini3 (User definable)
;; .fini2 (User definable)
;; .fini1 (User definable)
;; .fini0 (_endless_loop__: Infinite loop after program termination)

E.g. the following function will be placed to .init5 and hence will be executed after copying data from FLASH to RAM but before invoking C++ constructors :

void __attribute__((naked, section(".init5"))) MyInitializationCode()
{
asm("nop");
}

Note that the function body will be “copy-pasted” into the initialization sequence, hence the function should not contain any prologue/epilogue and must be declared as ‘naked’ (it may call other functions though).

[Author]

Posts