[support]

One of the possible workarounds is to rename the gdbserver to libgdbserver.so by patching the Android.mk file. VisualGDB will recognize libgdbserver.so as the alternative name for gdbserver and will launch it automatically.

[support]

Hi,

We normally recommend using Segger J-Link with the NXP devices, as it has much better support for them.
If you prefer using OpenOCD with the Olimex JTAG, you would need to locate a target script that matches your chip and select it manually in the ‘Target’ field. Normally if you click the ‘find’ button there, you should be able to quickly locate a matching script. For LPC1763 it should be lpc17xx.cfg.

If this does not help, please let us know the error message you get when trying to use the lpc17xx script.

[support]

Hi,

Yes, the manual override should do. You can also upgrade to Custom at any time. Simply contact our sales to get a quote.

[support]

Hi,

Thanks for letting us know. We will consider adding a feature to monitor the stack pointer validity to VisualGDB 5.2.

[support]

Hi,

Please try clicking the “Regenerate MCU files” button on the Embedded Project page of VisualGDB Project Properties. This should update the preprocessor macros to the ones defined in the latest BSP.

[support]

Hi,

Yes. Please check that the interrupt handler gets invoked if not, check your USB configuration to see whether it’s initialized properly.

If Windows does not report the device at all (not even as “Unknown device”), the firmware is not enabling the USB functionality correctly. If it’s reported as “Unknown device”, the USB logic is enabled, but cannot handle requests from the PC, indicating either a clocking error or a crash due to something else.

You can also check where the code is running if you stop the application via Debug->Break All.

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

[Author]

Posts