Forum Replies Created
-
Posts
-
The suggestions are automatically derived from scanning the code and cannot be adjusted. If you believe they are not working as expected and can reproduce it on a project that otherwise builds successfully, please share the repro steps and we will investigate.
Hi,
It is hard to pinpoint the exact reason for the code that was generated by the external tool, however we can provide you with instructions for troubleshooting this.
Please try creating a regular “LEDBlink” project with the VisualGDB project wizard, set a breakpoint in HAL_IncTick() and run the program so that it hits. Then check the call stack.
You should normally see the following stack:
- HAL_IncTick() itself
- The interrupt handler that calls HAL_IntTick().
Running the “find all references” command on the handler should show that it’s referenced from the interrupt vector table (typically called g_pfnVectors). In turn, checking the map file for g_pfnVectors should show that it’s placed exactly at the beginning of the FLASH memory (where the CPU would expect the interrupt handler table to be).
Once you can confirm it, please follow those steps backwards for the LL project (i.e. interrupt vector table -> specific interrupt handler -> call to HAL_IncTick()). If the system ticks are not working, one of those components is likely missing. If you are not sure, please let us know your findings and we will help you find a way to restore it.
Generally, ESP32 devices are indeed less straight-forward than the ARM-based ones like CC32xx. The main reason for this is that instead of relying on the mature ecosystem of the ARM tools, Espressif is using a much less popular Xtensa core and had to create ports for many development tools that would support it. They also introduce new features and versions of the SDKs very fast, doing much less testing compared to the traditional ARM-based device vendors, that often results in strange errors that need to be reported to them. Given the price of their devices compared to the main ARM-based competitors, the extra initial setup and occasional troubleshooting with the new IDF releases might pay off on the long run.
This specific error means that VisualGDB failed to connect to the OpenOCD (the tool for interfacing with JTAG hardware). Please try checking the connection test window for more specific error messages; if there are none – the connection might be blocked by your firewall. If disabling the firewall doesn’t help, please try ignoring the error, starting the debug session and checking the OpenOCD window in Visual Studio – it should contain more details.
If nothing helps, please let us know and we will provide more detailed instructions on diagnosing this.
The “while trying to download” message suggests that you are trying to download a remote file, not upload it. Please double-check your custom action. If you believe it is a bug, please share a screenshot of your setting, or the .vgdbsettings file.
No problem. We have rechecked it and indeed the custom shortcut output pane was not properly shown for some project types due to a recent switch to on-demand initialization of the VisualGDB extension.
We have fixed it in this build: VisualGDB-5.4.103.3009.msi
Good to know it work. We were just going to suggest that. VisualGDB does automatically find the installed Keil packs, however it won’t install/update them automatically. Hence we always advise first creating/opening a project with the Keil IDE to ensure all necessary components are present.
Sorry about that, our bug. Please try this build: VisualGDB-5.4.103.3008.msi
OK, we have tried reproducing this issue with the default linker script file for STM32F030F4 (unfortunately, the project link you shared does not work without a login and generally we are not able to review the code/projects that does not come from us unless it triggers bugs in VisualGDB itself), using several variations of the attributes. Generally, unless you declare the variable as volatile, gcc optimizes it away (you can verify it with the offline disassembly). If you do declare it as volatile, you do get a linker error as expected.
We have used the following definition (tried data/rodata and also with/without const):
volatile __attribute__((section(".rodata"))) const char g_LargeVar[32 * 1024] = {1, 2, 3}; int main() { volatile int test = g_LargeVar[0]; }Please double-check if you can reproduce the problem with the default linker script coming from our STM32 BSP and with minimal modifications to the default LEDBlink source (i.e. just adding one global variable and the line accessing it). If not, the problem is likely caused by some other setting specific to your project.
Thanks for the update. The .vgdbcmake file you attached looks very similar to the one we tested, so the crash is likely caused by some plugin, or Visual Studio component that is present on your machine, but not in our test environments.
The easiest way to narrow it down would be to try reproducing the problem on a different machine (or a different user account) and if it doesn’t crash, comparing the other VS extensions and VS versions. Please also consider installing VS2019 Preview, as it will also start with a clean environment and VisualGDB now fully supports it.
Alternatively, please try re-creating your project using the “Store files on Windows and upload them via SSH” mode. It will completely eliminate the “vgdb://” file paths used by VisualGDB, so the problem might stop triggering.
BTW, sorry for the hiccups with the file attachment system. It is on our list, although we are currently prioritizing a few product updates over it.
Thanks for sharing the details of your setup. Indeed the Advanced CMake Project System expects that the debugged executable would be a part of the CMake project, so that you could easily select it as a startup target via the Solution Explorer.
To support your configuration better, we have added a new command for the top-level CMake project: Add->Add a Debug-only Target. This will allow importing an arbitrary executable on the target machine into the project, as if it was one of the regular CMake targets. Please try this build: VisualGDB-5.4.103.3006.msi
Then the setup for the scenario you described will be much easier:
- Add the mono executable as a debug-only target.
- Set it as a startup target (also set the VisualGDB’s CMake project as a startup project).
- Specify the command-line arguments via VS project properties for that target (not VisualGDB Project Properties for the entire project).
You would still need the custom actions to deploy the managed binaries (long-term we are planning to add a special Solution Explorer folder for deployed artifacts, but it has currently a relatively low priority compared to other scheduled features). If you would like to reuse the custom actions between multiple projects and don’t want to create them from scratch each time, please consider using the reusable action list files (you can create them from the regular custom action GUI).
Based on the output log from your first message in the thread, the project fails to build. Hence, the problem is likely not related to IntelliSense at all. Please double-check your code and your settings and ensure the project can be built successfully. If the IntelliSense errors are still shown even after the projects builds successfully, please try reopening the solution so that VisualGDB resets the temporary caches.
Thanks for the update. The easiest way to change the project to Make would be to re-import it via the VisualGDB IDF Project Wizard as a Make project.
However, this will only work if your project directory has the build scripts for GNU Make (e.g. project.mk). If not, please try creating a new project and adding the source files to it via Add->Existing Items so that VisualGDB automatically updates the build scripts.
Sorry about that. We have tried reproducing this, however could not get it to crash (please the attached screenshot and let us know if you spot some critical differences from your setup).
We will also try to suggest a few things to try that might help, but that’s a fairly wild guess:
- First of all, please update to VisualGDB 5.4R3. It uses a different initialization mechanism that might no longer trigger the bug.
- Please try disabling Tools->Options->VisualGDB->General->Debug->Hook ‘Start Debugging (F5)’. This is not needed for advanced CMake projects and is one of the few parts of VisualGDB that is using native code. You will need to restart VS after that.
- Please try completely uninstalling Visual Assist, not just disabling it.
- Please try creating a CMake-based Windows project instead of the Linux one. If it helps, try creating a Windows project and store the sources on the Windows side. The ssh:// paths used by VisualGDB for projects with direct file access might confuse some C#-related logic.
Also please try attaching to the crashing VS using both native and managed debug engines and try to get the full (native + managed) stack trace of the crash. You will need to load the symbols for native DLLs by right-clicking at them in Call Stack in order to get a meaningful trace. Feel free to post it here even if it doesn’t contain any VisualGDB frames and we might be able to suggest something.
Finally, as we could not reproduce it on our side, completely resetting your VS environment (i.e. removing all plugins, %LOCALAPPDATA% folders, etc) might solve this completely. It could be faster than trying to pinpoint the problem (you can quickly check it by installing VisualGDB on another machine).
