[support]

Hi,

Sorry about that. Looks like our BSP is missing a reference to the library that provides those functions.

Please add the <SysGCC>\esp32\esp32-bsp\esp-idf\components\bt\lib\libbtdm_app.a file to your project manually and the Bluetooth functions should get linked properly.

[support]

Hi,

Sorry, we still could not reproduce this. Looks like it is caused by the directory layout on your Linux machine. We have added some extra logging to the latest VisualGDB 5.2R4.

Please try downloading it, then open View->Other Windows->VisualGDB Diagnostics Console and reproduce the problem. Once the problem is reproduced, please attach the diagnostic log contents here so that we could pinpoint this.

[support]

Hi,

Sorry for the delayed reply. When you are using a cross-toolchain, VisualGDB builds the code on the Windows side and then deploys the file to the Linux machine and runs gdb on Windows (same machine that builds the code).

In order to follow the steps above, please copy the current configuration via the VisualGDB Project Properties and change the build machine for that configuration to be your deployment machine. Then follow the steps described earlier to configure debugging.

For your convenience we have made screenshots of the relevant settings:

The /tmp/path-to-executable should match the location on the Linux machine where your executable is deployed.

Note that this configuration should not be used to build the project, it’s just a workaround to start debugging with gdb on a different machine without using the features of the Custom edition.

[support]

Hi,

Please try following the instructions from the this page on referencing prebuilt libraries from other modules.

[support]

Hi,

Sorry about that. Could you try switching OpenOCD to manual mode, disabling the interface/target scripts and specifying the board/ek-tm4c1294xl.cfg board script?

If this does not help, please try it on a different computer. Perhaps some other software or driver is interfering with OpenOCD.

[support]

Hi,

Sorry about that. Please send the dump file created by the IntelliSense engine via our support form and we will send you a hotfix (or a diagnostic build to pinpoint it better) within 48 hours.

The temporary build links automatically expire when their functionality is moved to the normal releases. If the same problem occurs with build 1297, it is probably caused by something else and we would need a dump file to pinpoint/fix it.

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

[Author]

Posts