[support]

Hi,

Unfortunately, the ESP32 tools are considerably more fragile than ARM-based tools, hence it is possible to break them by installing incompatible versions of different components or by accidentally patching some open-source components.

Our best advice to resolve it would be:

1. Delete the ESP32 toolchain and the ESP32 OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.
2. Try creating a new ‘ledblink’ project from scratch. Make sure you use the ESP-IDF version that is shipped with the toolchain.
3. Ensure the ledblink project works and can be debugged.
4. Once you get the ledblink project to work, try opening the previously broken project and check if it behaves differently. If it still doesn’t work, please try comparing the configuration files for the 2 projects (or simply move the code from the broken project to the working ledblink project).

[support]

Hi,

We would be happy to help you, however it looks like your support period has expired. Please renew it via this page and we will help you resolve this issue.

[support]

Sorry, we do not support Solaris 10.

[support]

Hi,

No problem, we have released an updated BSP based on msp432_driverlib_3_21_00_05. You can update it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

No worries and good to know it works. The advanced target-specific settings indeed only appear once the project has been created (and VisualGDB got a chance to query them from the Arduino tools).

If you encounter further issues, feel free to start another thread and we will be happy to help.

[support]

Sorry, it looks like the file did not get uploaded properly. Would you mind compressing it and trying again?

Also please double-check that you have selected the same upload method via VisualGDB Project Properties -> Project Settings (please attach a screenshot if you are not sure).

[support]

Hi,

It looks like some issue with the drivers or Arduino tools. Please try checking if you can program the board using Arduino IDE. If yes, we can help you achieve the same results with VisualGDB. If not, please try posting on Arduino forums.

[support]

No problem, please find the explanation below:

1. When NOT using fixed heap/stack, VisualGDB projects will use the default gcc/newlib logic for placing stack/heap:
   • The stack begins just before the _estack symbol (typically, end of RAM) and grows downward (i.e. address decreases with each push).
   • The heap begins after the end symbol (per linker script) and grows upward.
   • There are no hard stack/heap size limits. Each time the heap is extended, the heap logic checks whether the new end-of-heap would be beyond the current stack pointer. There is no check for stack pointer overrunning into the heap later.
2. When using fixed stack/heap, VisualGDB does the following:
   • It adds the ReservedForStack and FixedSizeHeap symbols into the built executable (see the StackAndHeap.c file).
   • The heap is located inside the FixedSizeHeap variable and will never grow beyond it.
   • The stack is still located _estack (growing downwards). It gets to use the space allocated for ReservedForStack and all the space after it (before the end of RAM). The ReservedForStack variable ensures that you get a link-time error if there is not enough space to place the requested stack size.

You can see this by reviewing the .map file produced by VisualGDB (use the VisualGDB Project Properties or VS Project Properties -> Linker to enable map files) or by using the Embedded Memory Explorer.

Currently, VisualGDB does not offer any special tools for analyzing hardfaults, sorry.

[support]

Sorry, this is way too project-specific and is not covered by our regular product support. We can help you understand specific settings of VisualGDB, but we are not able to troubleshoot project-specific issues without charging consulting fees.

[support]

Sorry, this looks like a project-specific issue (e.g. stack/heap overflow somewhere in the code), so we can provide limited help on this topic.

Our best advice would be to use the Embedded Memory Explorer to compare the memory layout of the 2 builds (https://visualgdb.com/tutorials/arm/comparebuilds/) and try making something in between to narrow down the problem (e.g. manually fill the same area of the FLASH memory with 0xFFs).

[support]

Hi,

Indeed, Dynamic Analysis is only available starting from the Custom edition.

[support]

Hi,

VisualGDB supports the imxrt devices by importing the SDKs generated by the MCUXpresso tool. Hence, as long as you have an SDK for imxrt106, you should be able to import it into VisualGDB.

Please see this tutorial for details and let us know if you have any further questions.

[support]

Thanks for clarifying this. The scenario you described could be accomplished using a custom MSBuild task, however it would require some additional scripting.

Please try creating a custom MSBuild task class as shown on this page and ensure it has a “GeneratedMakefile” parameter. In your .vcxproj file, add the following target:

<Target Name="PatchMakefile">
    <MyTaskName GeneratedMakefile="$(RemoteBuildMakefile)"/>
</Target>

Make sure you reference your custom task assembly using the <UsingTask> tag. Finally, edit the <VisualGDB Directory>\MSBuild\MSBuild\Targets\remote.targets file as shown below:

<Target Name="CommitRemoteBuild" Condition="('$(IsRemoteBuild)' == 'true') and ('$(DesignTimeBuild)' != 'true')" DependsOnTargets="PatchMakefile">

This will invoke the custom Makefile patching task after VisualGDB writes most of the targets there (the lines before the “.PHONY: $(PREPARE_TARGETS) …” line) but before it starts Make.

Let us know if this works and we will update the remote.targets file shipped with VisualGDB to use a project-level variable so that you won’t need to patch it.

If you would like to patch the Makefile after VisualGDB writes the final lines to it, please try inserting your task between the FinalizeRemoteBuildMakefile and LaunchVisualGDB tasks in remote.targets. If this works, we can update the file on our side to allow plugging custom tasks at this point as well.

[support]

Hi,

Sorry, it looks like the issue it not caused by VisualGDB, but instead some STM32-specific clock settings might be incorrect. Please consider posting on the STM32 forums to get help specific to STM32 devices.

[support]

Hi,

Good to know it works. The OpenOCD scripts for STM32 devices are normally maintained by ST, so they should just work out-of-the-box as long as you are using an OpenOCD version that matches them.

In case of any further strange errors, please consider deleting the OpenOCD directory entirely and re-installing it via VisualGDB Package Manager.

[Author]

Posts