Forum Replies Created
-
Posts
-
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?
Hi,
Thanks for reporting this. Looks like the gdb error message changed in one of the recent versions. We have updated our knowledge base so it should now warn about the missing file.
Hi,
Please try following the Cocos2d-x VisualGDB tutorial here: http://visualgdb.com/tutorials/android/cocos2dx/simplegame/. It contains all necessary steps. If it does not work for you, please let us know.
