[support]

Hi,

Currently this is a bit not straight-forward with Segger. Please edit the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\edp.xml file by removing the “load” command from GDBStartupCommands. We will add a configurable option to disable it in one of the next releases of the debugger package.

[support]

Hi,

Does it happen when you hit Ctrl-F5, or when you launch it manually on Raspberry Pi via SSH? Do you have any special environment/command-line arguments set? Does the deployment directory path contain any special characters?

[support]

Hi,

This can be just some random ESP8266 glitch. Normally unplugging everything and replugging it back solves the problem.

[support]

Your understanding of the startup sequence is correct. You can actually explore it visually it using Code Map if you are using the Clang IntelliSense:

First, the Reset_Handler from startup.c gets invoked. Startup.c files is actually generated from the .s files and should be 100% compatible with them (i.e. use same vector names). We use the .c files instead of the original .s ones to support advanced features like DEBUG_DEFAULT_INTERRUPT_HANDLERS and also to make things more uniform across different architectures.

The startup.c code does indeed copy the data section and erase the bss section. Then it calls device-specific initialization from the system_xxx.c file that is copied to your project folder and can be modified separately from other projects. If you just want to change HSI_VALUE/HSE_VALUE, you can edit the stm32fxxx_hal_conf.h for HAL projects or define HSE_VALUE via Preprocessor Macros in VisualGDB Project Properties for StdPeriph projects. For more complex changes, you would need to edit the system file. We would normally recommend switching to the STM32 HAL and then using the STM32CubeMX generator to generate the startup code automatically. If this is not an option, please replace your system file with a file from STM32 StdPeriph examples that matches your board configuration the best.

 

[support]

Hi,

Looks like the absolute Windows-style path got hardcoded into your application. Please try specifying the library name/directory separately in your linker arguments, i.e.:

-LC:\SysGCC\raspberry\arm-linux-gnueabihf\sysroot\opt\Iddk2000_3.3.0_ERelease_C++_Raspbian\sdk -lEIddk2000

[support]

Which board are you using? What happens if you then unplug the board and plug it back? Does the new program start normally, the old program start normally, or does nothing happen at all?

[support]

Hi,

No problem. Please contact our sales to get a trial extension voucher.

[support]

Hi,

Sorry for the late reply. We have published a detailed tutorial on importing CooCox projects into Visual Studio: http://visualgdb.com/tutorials/arm/coocox/

[support]

The exact answer depends on the debug method you are using. Generally each method provides a setting that allows selecting whether you want to program the firmware or assume it’s already programmed.

If you are not sure, let us know which debug method you are using so that we could help you locate the settings.

[support]

Hi,

Normally the extra initialization code should be placed into a separate Embedded Framework, not into the sample.

If you absolutely need to make it a part of the sample, you can add the following element to the EmbeddedProjectSample element in the sample.xml file:

<DoNotUpgradeCToCpp>true</DoNotUpgradeCToCpp>

[support]

No problem. If you encounter further problems, feel free to post them on the forum.

[support]

Hi,

The BSP cannot override those settings, however the BSP can define embedded frameworks that can be referenced by the project and the frameworks may in turn define extra files and flags.

In fact, our BSP-related code is open-source, so you may find some useful examples here: https://github.com/sysprogs/BSPTools/

[support]

Hi,

The dongle does not seem to be very popular, so we won’t be adding a special plugin for it in the near future. However if there is a gdb server that supports it, you can configure VisualGDB to use it by selecting the “Custom GDB Stub” in the debug method selector. If that does not work, feel free to post the problem description here and we will try to help you get it to work.

[support]

Hi,

This looks like a connection problem. Please double-check that all the JTAG connections (TDI, TDO, TMS, TCK) match the layout used with the EVB board. Also try resetting the board manually, but ensure that the reset is disconnected from the JTAG reset (xt-ocd has a bug with the reset on FT2232-based programmers). Finally try lowering the JTAG rate to 1 MHz or even lower.

[support]

Hi,

The easiest way to do both would be to remove all files from solution explorer and re-import them via right-click->Add->Import Folder Recursively. There you can also enable an option to bypass the Source Files/Header Files folders.

[Author]

Posts