[support]

The Go language currently looks more like a research project than a mature industrial tool, hence we would probably not find enough users to justify any heavy modifications to VisualGDB to support it.
However if GDB can already debug it, you should be able to use the Quick Debug feature or create a custom project to use VisualGDB as a high-level wrapper around GDB.

[support]

Yes, VisualKernel is focusing on seamless debugging experience, so configuring debugging is a mandatory step. If you just need to build your module, you can simply use the command line.

[support]

Hi,

The Raspberry Pi distro does not include kernel debug packages, so if you want to develop/debug kernel modules for it, you need to build the kernel from source code. Follow this tutorial for more details: http://sysprogs.com/VisualKernel/tutorials/raspberry/basicmodule/

[support]

Hi,

This looks like a corrupt MSI file. Please try downloading it again.

[support]

Hi,

Thanks, this looks like a bug. We’ll add a fix for it to the next maintenance release. As a workaround you can select the manual GDB mode and specify the target selection command manually.

[support]

Hi,

This can be related to the implementation of initialize_monitor_handles() in newlib 2.1.0:

void
initialise_monitor_handles (void)
{
int i;

#ifdef ARM_RDI_MONITOR
int volatile block[3];

block[0] = (int) ":tt";
block[2] = 3;     /* length of filename */
block[1] = 0;     /* mode "r" */
monitor_stdin = do_AngelSWI (AngelSWI_Reason_Open, (void *) block);

block[0] = (int) ":tt";
block[2] = 3;     /* length of filename */
block[1] = 4;     /* mode "w" */
monitor_stdout = monitor_stderr = do_AngelSWI (AngelSWI_Reason_Open, (void *) block);
#else
int fh;
const char * name;

name = ":tt";
asm ("mov r0,%2; mov r1, #0; swi %a1; mov %0, r0"
: "=r"(fh)
: "i" (SWI_Open),"r"(name)
: "r0","r1");
monitor_stdin = fh;

name = ":tt";
asm ("mov r0,%2; mov r1, #4; swi %a1; mov %0, r0"
: "=r"(fh)
: "i" (SWI_Open),"r"(name)
: "r0","r1");
monitor_stdout = monitor_stderr = fh;
#endif

for (i = 0; i < MAX_OPEN_FILES; i ++)
openfiles.handle = -1;



openfiles[0].handle = monitor_stdin;

openfiles[0].pos = 0;

openfiles[1].handle = monitor_stdout;

openfiles[1].pos = 0;

}

Our toolchain includes a patch that declares this function as __attribute__((weak)), so you can simply get the newlib source code and add this one file to your project, setting ARM_RDI_MONITOR if you need it and modifying anything else you need. You won’t need to rebuild the libc or anything else, the functions from your manually added file will simply replace the default ones.

[support]

Hi,

You can change the toolchain shown in the GUI by editing mcu.xml ( field). Again, the reason why we are extremely conservative about allowing the user to change the toolchain for an existing project is the amount of “strange” bugs it can cause. A few examples:

• Different toolchains can be configured with different –with-fpu, –with-arch and –with-abi flags. If you change the toolchain to a one that was configured differently and forget to rebuild your project, trying to call arbitrary functions can just randomly crash your firmware.
• If you do rebuild your project, but link against a static library built with another incompatible toolchain, you’ll hit the same problem.
• Different toolchains can have different multilib configurations (combinations of flags for which separate versions of libc/libgcc are built). Even given that you’ve specified all flags correctly, this could easily link incompatible code together.

Yes, you know, what you are doing when hacking the toolchains (and that’s why we allow changing it by editing XML/MAK files), but if we support any sort of toolchain swapping feature, we’ll immediately get lots of feedback from people less familiar with GCC guts that their project is suddenly broken for no apparent reason.

Can you compare the full GDB logs for normal and custom projects to see what is different and hence why “sim” is not working? Normally it should not be affected by the project type.

The duplication of the toolchain prefix comes from the internal format VisualGDB uses to represent toolchains that does not support variables. We also try to minimize the complexity of the Makefile parsing hence limiting it to querying basic things only and not expanding variables. Yes, we could design a more solid way of storing that information internally, but it would probably affect less than 1% of the users, while potentially introducing bugs that could break more widely used functionality. As a workaround, you can edit the XML files programmatically (example at the end of the message).

Regarding the ability to control the “10K” format, this sounds reasonable. Would a selection between bytes, kilobytes and automatic modes be reasonable for you?
As for the Makefile replacement, our main concern is that it could be incompatible with older versions of GNU Make or have strange problems if paths have spaces or some other rare scenarios, so we would like to give it some testing before shipping it. We are currently focusing on the new IntelliSense engine, so we will probably look at the Makefile improvements after it’s done.

Regarding missing toolchains for custom projects, this sounds like a bug. We’ll look into it more. Normally the toolchains are filtered by the field in Toolchain.xml.
There is currently no way of synchronizing the VS output directory and the Makefile build directory. Normally when you create a new configuration both should match the configuration name, but if you want to change them, you have to edit them both.

Finally, here’s an example of a C# tool that can generate a basic BSP including register definitions. Simply add BSPEngine.dll to the project references and build it:

using System;
using System.Collections.Generic;
using System.Text;
using BSPEngine;

namespace BspGenerator
{
class Program
{
static void Main(string[] args)
{
MCUFamily[] familyList = new MCUFamily[]
{
new MCUFamily
{
ID = "Family1",
CompilationFlags = new ToolFlags{COMMONFLAGS = "-mcpu=cortex_m3"},
}
};

MCU[] mcus = new MCU[]
{
new MCU
{
FamilyID = "Family1",
ID = "Device1",
FLASHBase = 0x1000,
FLASHSize = 1024,
MCUDefinitionFile = "mcu1.xml"
}
};

BoardSupportPackage bsp = new BoardSupportPackage
{
PackageID = "com.sysprogs.demo",
PackageDescription = "TestDevices",
GNUTargetID = "arm-eabi",
GeneratedMakFileName = "test.mak",
MCUFamilies = familyList,
SupportedMCUs = mcus
};

XmlTools.SaveObject(bsp, "BSP.XML");

string regDefinition = "REG1=0x1234,REG2=0x5678";   //Replace this by a real definition extracted from somewhere
List registers= new List();

foreach(var def in regDefinition.Split(','))

{

int idx = def.IndexOf('=');

registers.Add(new HardwareRegister { Name = def.Substring(0, idx), Address = def.Substring(idx + 1) });

}



MCUDefinition mcuDef = new MCUDefinition

{

MCUName = "MCU Subtype 1",

RegisterSets = new HardwareRegisterSet[] { new HardwareRegisterSet { Registers = registers.ToArray() } }

};



XmlTools.SaveObject(mcuDef, "mcu1.xml");

}

}

}

[support]

Hi,

Just FYI: our new GCC 4.9.1-based toolchain comes with standard syscall definitions declared as weak, so you can simply override the relevant ones with the STM32-specific implementations without having to modify the library.

[support]

Hi,

Thanks for letting us know. Good to know there is a workaround.

[support]

Hi,

The rebuild error is a known issue and can be safely ignored. Simply build the project afterwards and it will build properly.
The TICK_INT_PRIORITY issue can be solved by regenerating the Device-Specific files folder (change the MCU type and restore it back in VisualGDB Project Properties).

[support]

Thanks for the kind words. Making a product that is powerful and easy to use at the same time is our main intent.
If you like VisualGDB, you can help it find new users by spreading the word. And if you have suggestions on improving it further, do not hesitate to post them here.

[support]

Hi,

This looks like a hardware bug or the STM32 driver bug. Have you tried contacting the ST support regarding it?

[support]

Hi,

Chroot can be a problem here. Public key authentication setup requires access to /.ssh and if it becomes unavailable as a result of the chroot call, VisualGDB cannot physically do the setup.
You can do the setup manually by running VisualGDB.exe /dumpsshkey:file.txt and then appending the contents of file.txt to /.ssh/authorized_keys on the remote machine.

[support]

Hi,

Sorry for the delayed reply. We have made a detailed tutorial on targeting unsupported devices here: http://visualgdb.com/tutorials/arm/legacy/
Let me know if you have any questions.

[support]

Hi,

We’ve released an updated toolchain based on gcc 4.9.1 that resolves some issues and includes a newer newlib. Does your problem still happen with that version?

[Author]

Posts