[support]

Hi,

It looks like the file still defines the STM32F030CC macro. Could you let us know what exactly is broken with the project? Do you get some build error or is some functionality broken?

[support]

Hi,

Sorry, we only provide support for users of VisualGDB. Please direct your questions regarding Qt creator to Qt forums.

[support]

Hi,

Normally the BSP_ROOT should be automatically set once you relocate the toolchain via VisualGDB Project Properties. It’s only supported in the Custom and Ultimate editions though, so if you are using a one below them, you would need to adjust the IntelliSense settings manually if you want to use non-standard BSP locations.

[support]

Hi,

You can try setting a memory breakpoint via the Breakpoints window. It will trigger once any code writes to that variable.

[support]

Hi,

Yes, the HAL update indeed overwrites the HAL sources and headers with the newest versions, however the stm32f7xx_hal_conf.h file should be located in your project directory and hence not be affected by the update.

If there is a bug in some of our templates that results in referencing hal_conf from the HAL directory instead of copying it, please let us know.

[support]

Hi,

Yes, this looks like a bug in our example.

Please try defining the handler as follows:

extern "C" void USB_LP_CAN1_RX0_IRQHandler(void)
{
  HAL_PCD_IRQHandler(&hpcd);
}

[support]

Hi,

The macros that VisualGDB sets for different devices are defined in %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\BSP.XML .

We have just checked the one for STM32F030CC and it seems to be defined correctly (see stm32.mak):

PREPROCESSOR_MACROS += ARM_MATH_CM0 STM32F030CC stm32_flash_layout STM32F030xC

Could you double-check that you are using the latest BSP v3.5? Does the same problem happen when you create a new project? If yes, could you share the PREPROCESSOR_MACROS line from your stm32.mak?

[support]

OK, we’ve added it to the v5.2 roadmap.

[support]

Hi,

Can you reproduce it with the latest v5.1r3? Does it show TOOLCHAIN_ROOT under VisualGDB Project Properties -> Show VisualGDB Build Variables?

If yes, please update the build command on the Makefile Settings page to use $(TOOLCHAIN_ROOT) as well.

[support]

Hi,

Which version of VisualGDB are you using?

[support]

Hi,

The default implementation of malloc()/free() that comes with GCC starts the heap immediately after the end of the data segment and extends it dynamically until it intersects with the stack pointer at the moment of the extension.

If you want to set the explicit heap limit, you can do this by providing your own implementation to the _sbrk() function that will stop growing the heap once it reaches the given address. Let us know if you need more details.

[support]

Hi,

The J-Link uses its own implementation of semihosting that can be enabled with the “monitor semihosting enable” command as described here.

If you want to use the VisualGDB implementation of it, please try using OpenOCD instead.

[support]

Hi,

Good to know it worked. Let us know if you run into any problems.

[support]

Hi,

Sure, we could add a command like that. Do you mean the equivalent of the “Program and Start Without Debugging” command in the Debug menu?

[support]

Good to know it worked. Let us know if you encounter further problems.

[Author]

Posts