[support]

Hi,

We do run series of automated tests on all released packages, so it should not normally be the problem. However we have recently released an update to the Segger package that requires VisualGDB 5.3 Preview 5 (it will only be shown/installed if you are already using v5.3 Preview). Please check if you are using an older preview build of VisualGDB and update it if this is the case.

[support]

Hi,

nRF5x projects store board configuration in pcaXXXX.h files included from boards.h. Hence to port your project to a custom board, you would need to copy one of those files, adjust its contents to reflect the differences between your board and the original board and modify boards.h so that it will include your modified file instead (e.g. by adding a new BOARD_xxxx macro and checking for it in boards.h).

[support]

Hi,

This generally could indicate some error during the debugging setup phase. Please check the entire GDB log and also the output from the J-Link stub for more clues. If you are not sure, please post both of them here and we will help you understand them.

[support]

Hi,

Yes, please run the esp-idf tool, generate a new partitions.bin file and specify a path to it on the first page of VisualGDB Project Properties.

[support]

Hi,

We posted on the mbed forum about this (https://developer.mbed.org/forum/mbed/topic/27899/), but did not get any response from the mbed maintainers. Unless they can confirm that they would be interested in accepting the merge request with this feature, it does not make any sense to move on as mbed is rapidly changing and any stand-alone exporter will quickly become incompatible with the mbed build system.

[support]

Hi,

Thanks for your feedback. Currently it looks like Mono is going to get deprecated in favor of .Net Core (and Microsoft might support remote .Net Core debugging natively), so we won’t be targeting Mono on the near future. Hence the only way to support Mono would be via writing a plugin using our high-level frame extension API.

[support]

Hi,

Normally the log will be displayed once you click “details”. Most likely this happened because some files from the old toolchain (e.g. the debug plugin) were in use by VisualGDB.

Please try closing all Visual Studio instances and installing the toolchain manually: http://gnutoolchains.com/esp32/

Please also note that the latest toolchain requires VisualGDB 5.3 Preview 5 as it relies on the new mechanism for embedded debug packages.

[support]

Hi,

It’s not particularly hard, although the process it not documented and not officially supported. The embedded frameworks come from 2 sources:

• BSP.XML files under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs define frameworks that come with the BSP
• EFP.XML under %LOCALAPPDATA%\VisualGDB\EmbeddedEFPs define frameworks that can be used for all embedded devices regardless of the BSP

All our code responsible for generating BSPs (including the frameworks) is actually open-source and is available here: https://github.com/sysprogs/BSPTools/, hence you can try modifying some of the existing BSP generators to generate custom framework packages.

Regarding ChibiOS, it currently looks much less popular than other RTOSes like FreeRTOS, so we don’t have any plans of supporting it directly. If it becomes more popular, we will reconsider this. However currently you would need to create the framework manually in order to support this OS out-of-the-box.

[support]

Hi,

Yes, the problem happened because the fine-grained indentation of the function arguments happened on the different level than the coarse-grained indentation of the statements.

We have fixed this in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.3.5.1708.msi

[support]

Hi,

Sure, we have just released it: http://visualgdb.com/download/ (use the “try preview” button).

After installing we recommend updating the debug packages via Tools->VisualGDB->Manage VisualGDB Packages. This will install updates that significantly improve the OpenOCD and Segger J-Link debug experience.

[support]

Hi,

Looks like there is a confusion about the “stm32f2x” vs “plugin” driver. The “stm32f3x” driver is a built-in OpenOCD driver that is only capable of programming the regular on-chip FLASH memory. Hence if you specify “stm32f2x” in your command, OpenOCD will try to use that driver and fail.

The “plugin” driver is a special driver only supported by our OpenOCD fork that will load your ELF file (that must include certain symbols) into the device and call functions from it to program the memory. The error message in one of your previous posts actually contained a clipped line “Invalid FLASH plugin”. Please switch back to using “plugin”, get that message to appear and check the rest of that message. It should provide a clue on why the ELF plugin could not be loaded and resolve the errors mentioned there in order to get it working.

[support]

Hi,

Good to know it works. If you encounter further errors, feel free to contact us again.

[support]

Hi,

Thanks for the detailed description. We have rechecked this and can confirm that it is a bug in the latest VisualGDB version. The behavior we got was different, although the error you observed could be caused by the same problem. Some samples from the Nordic SDK like SAADC can only be compiled with the softdevice disabled and VisualGDB did not properly override the softdevice setting manually selected on the MCU selection page. We have fixed this in the upcoming v5.3 Preview 5. As a workaround please try disabling the softdevice manually via VisualGDB Project Properties.

Please also update your nRF5x BSP to the latest version (13.0r3) as previous BSP versions might handle this incorrectly.

[support]

Hi,

Yes, please refer to the instructions in this post: https://sysprogs.com/w/forums/topic/using-the-quadspi-on-stm32f7-discovery/

[support]

Hi,

No problem. According to our records, you already have the Custom edition, so you should be able to use the post-build commands. Please refer to the screenshot below:

Please select VisualGDB Project Properties -> Custom Build Steps -> Actions after building -> Edit -> Add -> Run a custom command line.

Then locate the objcopy binary from your toolchain and enter the arguments with the adjusted input and output file paths. We recommend using variables like $(TargetPath) and $(ProjectDir) to avoid hardcoding the paths. The objcopy command will read the input ELF file (first argument after –only-section), locate the .textqspi section inside it and dump it into a .bin file (second argument after –only-section). Please ensure that the input file path matches the path of the ELF file built by your project so that objcopy can process it correctly.

Attachments:

You must be logged in to view attached files.

[Author]

Posts