Forum Replies Created
-
Posts
-
Hi,
Not sure why the double dash did not work for you, but it should be double. Here is a screenshot:
Together with unchecking the “provide default implementations” field (that sets –specs=nosys.specs), this results in the following build command line:
F:\SysGCC\arm-eabi/bin/arm-eabi-g++.exe -o Debug/stm32f4test.elf -Wl,-gc-sections --specs=rdimon.specs ... -lcompactcpp -Wl,--end-group
If the GUI does not work, you can try manually modifying LDFLAGS in debug.mak.
Regarding live variables. As a quick fix, if you are using OpenOCD, you can try connecting to port 4444 and sending OpenOCD commands (e.g. mdw <address> to read a DWORD), however you cannot do this if you are using live variables, as VisualGDB uses the same interface.
As a long-term solution, we are actually planning to add support for running tests with VisualGDB, so we could make a much higher-level interface. We would rather provide a framework for defining test functions with test asserts in your code (that will be normally ignored) and then add a special mode where VisualGDB will build a binary with the tests enabled and run the given subset of tests. Would that be more useful than just live variables API?
Hi,
Looks like the forum engine converted the dash incorrectly. Here is the correct option:
--specs=rdimon.specs
Please also ensure that the “provide default implementations for syscalls” checkbox is not checked.
Not 100% sure what you meant about fixed-length buffer API. Could you perhaps provide an example of a task you want to accomplish with it?
Hi,
Looks like the fix was incomplete. We have updated the R3 distro to include a hotfix resolving this. Let us know if it works.
Hi,
Normally the standard C library only flushes the printf() output when a newline is encountered, i.e. printf(“test”) will not print anything, but printf(“test\n”) will.
You can override this by either calling fflush(stdout) after printf() or adding the following call before printf():
setvbuf(stdout, NULL, _IONBF, 0);
If you are using newlib-nano, please add “–specs=rdimon.specs” to LDFLAGS to enable newlib-nano semihosting implementation.
If you want to do the formatting on the computer instead of the device, you would need to make a custom semihosting call handler plugin for VisualGDB. If you believe it is worth the effort, please let us know so that we could extend our SDK with API for implementing such plugins.
Could you attach a screenshot of the directory list? What exactly happens when you press the “remove” button?
Hi,
Not fully sure what you meant. Could you provide a simple example showing file contents and expected/observed IntelliSense suggestions?
Hi,
Normally “continue” should work. If it does not, please try clicking the “signals” tool button in the GDB Session window. This will open a GDB-specific dialog with GDB signals allowing you to change their handling. If this does not help, please let us know a specific signal that is not working and send us a full GDB log (obtained by enabling debug logging on the GDB Settings page of VisualGDB Project Properties).
Hi,
You can find the linker workaround option on the Debug Settings page as shown on the screenshot below:
If the test always keeps on failing, could you please run the extended tests via Android->Device Compatibility Center and send us the logs? Perhaps we could find a different workaround.
Based on what you have described, most likely normal debugging will work for you, but if you load libraries dynamically, GDB won’t be able to see them until you run “sharedlibrary” manually.
Hi,
There might be differences in the MCU initialization code and the external oscillator frequency. Please download the STM32F3 firmware package from ST and check the “Projects” folder for USB projects for your board/device. Then copy the SystemClock_Config() function and usb_conf/usb_desc files from a matching sample project.
Yes, that should work. Normally if the toolchain is built correctly, it should pick up the sysroot directory from the standard location automatically. If not, specifying –sysroot=xxx (a.k.a. CMAKE_SYSROOT in Cmake) is the way to go.
Hi,
Thanks for reporting this, we have fixed the problem with the relative paths in VisualGDB 5.0R2. You can download it here: http://visualgdb.com/download/
We have also added an option (currently unsupported via GUI) to disable the use of toolchain files. Please change any setting in VisualGDB Project Propreties, save the settings, open the .vgdbsettings file in a text editor and modify the DisableToolchainFile field.
Is it the toolchain that came with VisualGDB (http://gnutoolchains.com/arm-eabi/) or have you installed it separately? Could you attach your stm32.xml file that shows the current toolchain configuration?
