[support]

Hi,

VisualGDB does not change the way gcc handles the calling convention, so this problem may be caused by different optimization settings or inaccurate debug information generation. We would advise adding some clearly traceable lines to your code like this:

static volatile int var;
var = arg_1;

Then try switching to the Disassembly view to understand where exactly does the compiler take the value that is stored into ‘var’.

[support]

Hi,

Sorry about that. Based on your description this looks like a potential problem with the board or the USB driver, so trying a different board or a different machine might easily solve this.

If this is not possible, please do the following to diagnose this:

• Start debugging as usual
• Press “break all” to cause the “Command aborted” error
• Switch the GDB Session window to “All GDB Interaction”
• Copy all contents of the GDB Session window and the OpenOCD window and post it here

This should help us understand what could be causing this and give you further advice.

[support]

Hi,

VisualGDB does not use the VC_IncludePath and other directories when compiling the Android code. Which version of VisualGDB are you using?

[support]

Hi,

Please try the Debug->Break All command and see what code is running. Perhaps you have missed one of the interrupt handlers and the program is stuck in DefaultHandler()?

If no other interrupt occurs, please try stepping through the ADC interrupt handler provided by HAL and check that it clears the ‘conversion complete’ flag in the ADC peripheral so that the interrupt is not raised immediately after.

Another reason for this could be that the ADC is configured to fire the interrupts too fast and the main loop never gets a chance to run. In this case lowering the ADC frequency or raising the CPU clock frequency should help.

[support]

Hi,

You could run the “mon cortex_m maskisr on” command in the GDB Session window to automatically disable interrupts during stepping.

However this would only work for low-level JTAG adapters (i.e. won’t work with ST-Link). If you are using ST-Link, we would recommend setting the PRIMASK register to disable the interrupts manually while you are stepping through the critical parts of code.

[support]

Hi,

Sorry, we do not directly support this yet. It is on our radar, so feel free to follow us on twitter to get notified once we release a tutorial.

[support]

Hi,

Looks like your toolchain sysroot may have the incorrect linker configuration file. Please try updating to VisualGDB 5.2 and then resynchronize the sysroot. This should repair the config file automatically.

[support]

Hi,

Please update to VisualGDB 5.2 and convert your project to the MSBuild subsystem. This will allow specifying various build settings for each file independently via the regular Visual Studio file properties.

[support]

Hi,

OK, this looks like gdb 7.12 was either not compatible with your board, or built incorrectly. Hence the easiest way to get this to work would be using gdb directly on the board.

If you are not using the Custom edition, this would involve cloning the current configuration and changing the new configuration properties as follows:

1. Computer used for building and debugging: (your Wandboard)
2. Debugged executable: (full path to the deployed executable on Wandboard)
3. Additional startup commands: set follow-fork-mode child

Then you could build the project using the regular configuration and debug it using the second configuration.

If you were using the Custom edition, you could override the machine where gdb is launched (by default it is the same machine that compiles the code) and not need the second configuration.

[support]

Hi,

If you just want to combine 2 .bin files into one, it should be as easy as padding the first one with 0xFFs and appending the second one to it.

If you want to get an ELF file that contains data from 2 binary files at given addresses, you would need to convert .bin files to .o files and link them with a special linker script that will place each file contents at a given address.

Let us know if you need more details.

[support]

Hi,

OK, we did a quick research and it looks like the proprietary ARM compiler indeed uses the clang as a front-end.

However, it does not look like anyone has released official binaries for the regular clang/llvm for ARM. If we have overlooked anything, please let us know.

[support]

Hi,

First of all, we have to apologize that due to many customizations of the Android kernel compared to the regular Linux kernel, VisualKernel we do not officially support it. That said, if you encounter any problems, please let us know and we will do our best to suggest a workaround, but we cannot guarantee that it will work.

Regarding the differences between VisualGDB and VisualKernel: VisualGDB allows developing user-mode applications, Android tools and C/C++ libraries used in Android apps; the kernel-mode development is the case for VisualKernel.

Our arm cross-compiler only works for barebone embedded devices and does not support ARM64.

IntelliSense is designed to run in a separate background process and automatically restart in case of crashes. If you get the “IntelliSense crashed” message with the dump file, we encourage you to share the dump file with us via the support form. As our IntelliSense is using the 3rd-party Clang compiler, it does sometimes crash due to Clang bugs, but we normally fix those issues very quickly.

As the normal Linux kernel cannot be reliably build on Windows, VisualKernel does not support it. You can try configure VisualGDB to build it via the “Import Linux Project” option in the Linux wizard, but it will not recognize it as a Linux Kernel and won’t do any automatic setup steps.

The problem with building the Linux kernel on Windows is that the Makefiles actually rely on building various auxiliary tools that rely on Linux-specific API and won’t work on Windows. Hence VisualKernel always requires a Linux machine to build the kernel.

[support]

Hi,

Looks like your gdb log does not contain the “set follow-fork-mode” line.

Please double-check that you are setting it correctly.

[support]

Hi,

The restriction for the amount of simultaneous breakpoints in FLASH is a limitation of the microcontroller. However it should clearly show a message like “too many hardware breakpoints” and not hang.

Could you please try stopping the program at a breakpoint, adding more breakpoints to exceed the limit and pressing F5 to continue? Does it hang as well? Do you get the same behavior on all devices?

[support]

Hi,

Sorry for the confusion. The ‘VisualGDB’ platform corresponds to the new MSBuild backend introduced in v5.2. The regular ‘Win32’ platform corresponds to the old-style projects that use GNU Make or CMake.

Since v5.2, we recommend using the new MSBuild backend (‘VisualGDB’ platform) for all new projects, so normally the old ‘Win32’ platform should not appear for the VisualGDB projects. If it does despite selecting MSBuild, please let us know the steps to reproduce it and we will fix it.

[Author]

Posts