[support]

Hi,

As most of our users rely on GCC, we indeed do not directly support the IAR compiler. It is possible however to modify a VisualGDB project to use any 3rd-party compiler.

We do have a detailed tutorial showing how to use the Keil ARM compiler with VisualGDB here: http://visualgdb.com/tutorials/arm/keil/; adding support for IAR should be very similar.
The steps described there only work for Make projects; MSBuild would require slightly different steps, but we could guide you through them.

As Visual Studio itself does not support per-folder options, VisualGDB can’t do that out-of-the-box. You can achieve this by adding a few custom targets to your MSBuild project, but it won’t be easily configurable via GUI. Let us know if you want to go that way and we could give you a basic example.

P.S. If the only reason you are not using GCC is the lack of support for multiple memory regions, we could provide you with a custom tool that will re-link an existing ELF file to spread one data section across multiple regions using the relocation records generated by the compiler. If you are interested, please contact our sales and we will give you a quote for making this tool.

We currently don’t have any plans for supporting IAR compiler directly as it is not very popular among our users. We could add it as a paid customization if you believe this could save time, or we could just help you support it on your side by customizing VisualGDB projects.

[support]

Hi,

Thanks for clarifying this. When we made the tutorial, we could not get any errors with the original extern “C” block.

Please feel free to post the errors you got so that we could check what could be causing this.

[support]

Hi,

This looks like a driver problem. Please try pressing the ‘Test OpenOCD Settings’ button so that VisualGDB can check for known driver issues.

[support]

Hi,

VisualGDB usually preserves the comment indentation when reformatting the code. If it actually breaks them in your case, please let us know the exact repro steps (i.e. how the code looks before/after formatting what would you expect) and we will fix this.

Most of the settings can be controlled via Tools->Options->Text Editor->C/C++ (e.g. Indentation -> Indent namespace contents). Formatting settings that are specific to VisualGDB can be controlled via Tools->Options->Text Editor->C/C++ (VisualGDB).

Regarding Resharper, the problem is that Resharper does not know how to import VisualGDB-specific settings from VisualGDB projects and hence does not work correctly. The only solution we could offer is add features you miss to our Clang IntelliSense engine so that you can still have them for VisualGDB projects.

[support]

Hi,

Please open the VisualGDB Project Properties and either click “regenerate BSP-specific files” or change the MCU to a different one and back. This should regenerate the file references in a multiuser-safe way. If this still does not help, please let us know what exact error you are getting so that we could advise you further.

[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.

[Author]

Posts