Forum Replies Created
-
Posts
-
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?
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.
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.
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.
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?
Hi,
Yes, you can try debugging with a cross-gdb that will run on the Windows machine and connect to your Linux one via gdbserver. Then the symbol handling will be done on the Windows side and the Windows/Linux latencies won’t affect those commands.
Hi,
It looks like an obvious bug in our device definitions, so there is no action needed on your side, we’ll simply release a BSP update fixing this within the next 24 hours.
Yes, simply use the File->Export VisualGDB Project Template command. We will publish a tutorial on that soon.
Wow, strange. It did not crash on our side. If anyone else can confirm the crash, please send us dump file and we’ll gladly fix it.
Hi,
OK, strange. According to your log file, the breakpoint gets set correctly. Please try modifying your code as follows:
- Add a function “void test() {asm(“nop”);}
- Change the stringFromJNI() function to return the address of the test() function instead of the counter: sprintf(sz, “test=0x%x”, &test);
- Set a breakpoint in ‘test’ by name (Ctrl-B).
Does the address of ‘test’ reported in the GDB log match the address returned by the stringFromJNI() function? Does the breakpoint still not hit?
