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

[support]

Hi,

We are sorry about your experience. We have just retested this by creating a new project for Nordic nRF528232 with the SDK 13.0 and manually enabling the power module and could not get any error. The line mentioning NRF_POWER_THRESHOLD_V23 compile successfully and IntelliSense is able to find the definition correctly.

Perhaps you have imported the project in a way that lets a 3rd-party Makefile control the build and the Makefile itself contains errors? We would be happy to help you if you could let us know how exactly have you created the project so that we could reproduce this on our side.

[support]

Hi,

Yes, this Makefile saves the contents of the ExtFlashSection to extflash.bin. If you want to convert the project into a MSBuild-based VisualGDB project, you would need to add the objcopy command to the custom post-build actions to achieve the same result.

[support]

Hi,

If you want to generate a project with 2-way synchronization, we recommend using MSBuild (the first option). However please note that it will not automatically import all of the settings like preprocessor macros, so you would need to specify them manually after importing.

[support]

Hi,

It looks like the MSI file is corrupt. Please try re-downloading it and ensure that you have administrator permissions on that machine (and that your antivirus is not accidentally blocking access to the MSI file).

[support]

Hi,

Thanks for clarifying this. We have replied with further details to the support ticket you opened.

[support]

Hi,

No problem. If you encounter any issues, feel free to post here and we will help.

[support]

Hi,

Please try searching the header files in the Nordic SDK directory for the definitions of NRF_POWER_THRESHOLD_V25. E.g. in SDK 13.0 it is defined in nrf_soc.h, but only if SOFTDEVICE_PRESENT is defined as well. Hence you would need to ensure that the softdevice is enabled for your project.

[support]

Hi,

Are you installing the latest VisualGDB 5.2R9 (or 5.3)? The installer should normally create the “C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\VisualGDB” folder with 6 files inside it. Is the folder created? If not, please try running msiexec /l* visualgdb.log /i VisualGDB-<version>.msi and then submit the log file here so that we could check why the MSBuild platform is not installed.

[support]

Hi,

You can add it to the custom post-build commands in VisualGDB Project Properties (requires Custom Edition and higher).

[support]

Hi,

The “flash bank name ‘stm32f4x.flash’ already exists” error means that the FLASH name you specify is already used by the default FLASH memory bank. Simply change $_FLASHNAME to any arbitrary name (e.g. qspi). The bank name does not refer to a specific driver, instead it defines a unique name for the newly created bank.

The “Failed to connect to the debug stub” message means that GDB could not connect to OpenOCD (most likely because OpenOCD exited with an error). Please examine the OpenOCD window (or the GDBServer log in the VisualGDB error detail window) for details.

[Author]

Posts