Forum Replies Created
-
Posts
-
Hi,
You might need to adjust the memory size for your softdevice configuration. Please follow this tutorial for details.
Hi,
This happens because OpenOCD does not know how to program the EEPROM memory. You can try tagging the new section with the NOLOAD attribute to prevent it from being loaded, or try developing a custom FLASH programming plugin to load EEPROM automatically.
Hi,
The STM32 SystemWorkbench uses a customized build of OpenOCD that supports more devices than the regular build. You can try manually copying the OpenOCD.exe and the related DLLs from STM32 System Workbench to %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\<…>openocd\bin. This should get OpenOCD to support the same devices as the ST SystemWorkbench does.
Regarding compilation, if this is a separate issue, please let us know the errors you get and we will try to help you resolve them.
No problem, please follow the instructions in this thread: https://sysprogs.com/w/forums/topic/stm32-failed-to-connect-to-debug-stub/
Hi,
Thanks, this could potentially be our bug. We will try to reproduce it and add a workaround or at least an informative warning.
Hi,
Please let us know the board you are using and we could suggest a relevant sample if there is one.
For VisualGDB projects you can setup heap/stack size via VisualGDB Project Properties -> Embedded Frameworks -> Fixed-size stack/heap.
Hi,
Thanks for the idea. This looks a bit too complicated for an immediate hotfix, however we will try to fit this into the final v5.3. We will update this post once we have progress.
Hi,
Thanks for confirming this. Could you please try adding the reference to the VisualGDB directory to msbuild command line explicitly as described here?
Hi,
Sorry about the confusion. In order to troubleshoot this please open Device Manager, locate the Olimex device and locate its Hardware ID (via Properties window). Then please check the USB VID and PID shown in the Hardware ID against the IDs specified in the .cfg file. Can you confirm that the IDs match?
If yes, which driver is installed for the Olimex interface?
In order to use automatic connection testing, please update to VisualGDB 5.3 and install the latest ESP8266 toolchain. It includes an updated debug mechanism that detects and fixes most of the driver problems automatically.
Hi,
Looks like you might be using a deprecated version of the script. Please try using interface/ftdi/olimex-arm-usb-ocd.cfg.
Hi,
Thanks, we have rechecked this and can confirm that despite VisualGDB only querying the values for the children physically shown on the screen, gdb takes considerable time to evaluate the first batch.
We have added a workaround to the following build: http://sysprogs.com/files/tmp/VisualGDB-5.3.8.1792.msi
Hi,
No problem. If the same gdb works with command line, we would recommend double-checking the following:
- The exact command lines when launching gdb and gdbserver
- Environment (e.g. LD_LIBRARY_PATH)
Please also try switching gdb start mode to ‘custom’ and explicitly specify the ‘target remote ….’ command. Then launch gdbserver manually and let VisualGDB launch gdb. If the problem persists, it is caused by gdb configuration, if not – it’s caused by gdbserver launch configuration.
You can use the View->Other Windows->VisualGDB Diagnostics Console command to see the internal VisualGDB output showing the commands it runs.
Hi,
The ARM-USB-OCD and ARM-USB-OCD-H devices have different USB IDs. Please try enabling the manual script selection and select the olimex-arm-usb-ocd.cfg script explicitly.
Hi,
Good to know it works. Normally reinstalling VS2017 and ensuring you can create regular VC++ Win32 projects should help as well (the regular VS wizard uses the same mechanism).
