[support]

Hi,

Please try enabling the verbose mode via Tools->Options->VisualGDB->General and try building again using the TAR mode. The log should should which files failed to transfer. Most likely this is related to some sort of a file permission problem.

[support]

Hi,

The easiest way to fix that is to use the VisualGDB header discovery feature to quickly locate the stm32f0xx_hal_conf.h file (should be somewhere in the project folder) and adjust the build settings automatically.

[support]

Hi,

Yes, please check the Output window (View->Output). It should contain the detailed build log listing all errors printed by the compiler, linker and other tools. If you are not sure, please post the log contents here and we will help.

[support]

Hi,

Thanks for your suggestions. You can actually view a list of your threads and comments by clicking on your username (or via this link). Regarding emails, we had it enabled previously, but unfortunately many mail servers treat such notifications as spam, so we started getting many “invalid email address” notifications and had to disable this.

We will consider adding support for attaching images, but currently it’s disabled to improve forum responsiveness.

[support]

Hi,

The “GDBServer Console” command will only be available during debugging, so you can view it after pressing F5.

Based on the other details you provided, it looks like OpenOCD may have troubles programming sections that are not properly aligned. Please try modifying your linker script to place the new section inside the .text section:

.text :
{
*(.text)
...
. = <end of FLASH> - <expected size>;
*(.eeprom)
. = ALIGN(4);
} > FLASH

 

[support]

Hi,

The testing only checks the JTAG connectivity and does not try to load the FLASH. In order to see FLASH-related errors, please select Debug->Windows->GDBServer Console.

[support]

Hi,

You can add “-static” to via VS Project Properties -> Linker -> Command Line -> Additional Options.

[support]

Hi,

Please check the contents of the OpenOCD window for more specific error messages. This should explain why FLASH programming fails.

[support]

Hi,

Looks like the address sanitizer is not supported your platform. Please note that it does not work on barebone embedded targets.

[support]

Hi,

The final release would be this summer. Currently we are focusing on updating support for devices and frameworks and we will be introducing another product for embedded software developers in the next few weeks. You can get a feed of our updates on our Twitter page: https://twitter.com/Sysprogs/

[support]

Hi,

Do you mean a static library? You can do that by selecting “static library” in the wizard or changing the output type to “static library” via Visual Studio Project Properties.

[support]

Hi,

Thanks for the screenshot. The behavior you are describing happens because the library files like stm32f0xx.h are located outside the project directory and are shared between all of your projects. Visual Studio’s ‘show all files’ view is based on the physical location of the files and hence shows them flat.

One workaround would be to convert the project to a stand-alone one via the first page of VisualGDB Project Properties. This will copy all the STM32-specific files to a subdirectory inside the project directory and the ‘show all files’ should show them accordingly.

[support]

Hi,

Yes, please check that the HAL_SAI_MODULE_ENABLED macro is defined in the stm32f7xx_hal_conf file.

[support]

Hi,

We don’t fully support nRF5x mbed targets as they require some extra steps and don’t build out-of-the-box. As a workaround please consider using the regular non-mbed SDK for nRF5x for now.

[support]

Hi,

No problem. Based on your description, this could be caused by one of the following:

• The functions are not instrumented properly
• The call time information is not properly received by VisualGDB
• Your chip does not support tracing instruction times

You can do a quick check whether the instruction cycle counter works by running the following code from main():

#define DWT_CYCCNT (*((unsigned *)0xE0001004))
#define DWT_CTRL (*((unsigned *)0xE0001000))
#define COREDEBUG_DEMCR (*((unsigned *)0xe000edfc))

COREDEBUG_DEMCR |= 0x01000000;
DWT_CTRL = 1;
DWT_CYCCNT = 0;
asm(“nop”);
int result = DWT_CYCCNT;

If result is 0, your CPU does not support the instruction cycle counter and the profiler framework will need a minor adjustment to run on that CPU (we can provide details).

If it works, please check if the custom real-time watch events work. If yes, the problem is related to function instrumentation.

Please let us know your findings so that we can help you further.

[Author]

Posts