support

Forum Replies Created

Viewing 15 posts - 3,256 through 3,270 (of 7,817 total)
  • Author
    Posts
  • in reply to: feedback on mbed project (compared to embedded) #24296
    support
    Keymaster

    Thanks for the detailed feedback. It will take us a couple of days to properly process it, come up with hotfixes for easily resolved issues and give time estimates on bigger ones. Please expect an update on this around the middle of the next week.

    in reply to: Clang IntelliSense navigation bar #24295
    support
    Keymaster

    No problem. We have changed the logic that fetches the item names for the navigation bar to use exactly the syntax they are declared with. Please try this build: VisualGDB-5.4.103.3013.msi

    in reply to: Switch to Advanced View window problem #24294
    support
    Keymaster

    Thanks for the video. We have confirmed the issue and it looks like it is introduced by some recent changes in the latest Visual Studio 2019 update that we haven’t fully tested yet.

    We will investigate this and will try to publish a hotfix in the next 1-2 weeks.

    in reply to: Clean deletes all files on remote host cmake projekt #24293
    support
    Keymaster

    Sorry, the .vgdbcmake file did not get attached properly. We have just patched the forum engine on our side, so you should be able to upload it again.

    We have also rechecked this on a newly created project and it did get cleant correctly. VisualGDB does have an option to remove the entire remote source directory on clean, however it is hidden and ignored for projects that are using direct SSH file access.

    Please try attaching the .vgdbcmake file again and we will check what is going on.

    in reply to: Custom build steps after linking #24285
    support
    Keymaster

    Hi,

    As VisualGDB supports many different build systems, its custom action logic treats build as a single “black box” step, hence they will indeed run after the build regardless of the actual steps performed during the build. If you would like a finer-grain control over this, we would advise creating custom targets with the build system you are using (e.g. see this tutorial for custom MSBuild targets) or try searching CMake documentation if you are using CMake (stripping symbols is a fairly common task, so there might be ready-to-use snippets posted on StackOverflow or other forums).

    If you don’t want to modify the build system settings, please consider changing your file structure so that the custom actions won’t overwrite any files. E.g. copy $(TargetPath) to $(TargetPath).target, then move debug symbols to $(TargetPath).debug and finally strip $(TargetPath).target. You would need to update the debug and deployment settings to deploy/launch $(TargetPath).target instead of $(TargetPath), but as long as you do that, the building and debugging will work as expected and the symbols won’t get lost.

    in reply to: VisualGDB running as TFS remote build failure #24284
    support
    Keymaster

    This looks like you have updated the VisualGDB binaries, but might be still using the MSBuild targets files from the old version. Please double-check that the project builds with VisualGDB 5.4 from Visual Studio and that the SysprogsPlatform.targets and other MSBuild files on the TFS machine match the corresponding files on the machine where the build succeeds.

    in reply to: BIN file size ecxeeds flash size with no error #24267
    support
    Keymaster

    No problem. We have investigated this and confirm that the syntax used in the VisualGDB-supplied linker scripts indeed does not check for FLASH overflow when placing the initialization data for RAM sections.

    We have done several tests with the “> SRAM AT > FLASH” syntax and confirm that it solves the problem and is otherwise equivalent to the old one, so we have updated our linker script generation tool to use the new syntax and also changed the logic used by the “Additional Memories” page in VisualGDB.

    The next STM32 BSP update will include the linker scripts using the new syntax. As a workaround until then, please consider editing them manually, although the only difference in behavior would be the error message for FLASH overflows caused by the RAM initialization data (regular FLASH and RAM overflows are still reported correctly with both linker script versions).

    Thanks for providing detailed repro steps and sorry for the confusion – we have previously encountered many cases when the unexpected image layout was caused by optimization and have never received any reports on issues caused by the VisualGDB’s linker script format.

    in reply to: Switch to Advanced View window problem #24266
    support
    Keymaster

    Sorry, we tried reproducing it, but could not get the behavior you described. If you could upload a video demonstrating the problem and post it here, we should be able to see what is going on.

    in reply to: Clang IntelliSense auto complete not always showing up #24265
    support
    Keymaster

    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.

    support
    Keymaster

    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:

    1. HAL_IncTick() itself
    2. 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.

    in reply to: ESP32 DEVKITC cannot connect or program #24262
    support
    Keymaster

    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.

    support
    Keymaster

    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.

    in reply to: VisualGDB running as TFS remote build failure #24256
    support
    Keymaster

    Hi,

    This looks like a bug that was fixed in the latest v5.4 release. Please try updating to it.

    support
    Keymaster

    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

    support
    Keymaster

    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.

Viewing 15 posts - 3,256 through 3,270 (of 7,817 total)