[support]

Hi,

No problem. If you are using MSBuild, you can use the regular VS Project Properties as well. For other build systems like GNU Make the VisualGDB Project Properties will be the right place to go.

[support]

Hi,

It depends on what your goal is. The values in the XML file are copied from the default values for your MCU when you convert the project to a stand-alone one. They are propagated to the actual Makefile (or MSBuild property sheet file) once you change settings on the first page of VisualGDB Project Properties.

If you are not sure, we would recommend checking in the entire project to a source control system like git or SVN and then changing the parts that look suspicious and observing the outcome. You can also just change the FLASH/RAM Size/Base. Those settings are only used in GUI hints and the memory explorer and don’t directly affect compilation.

[support]

Hi,

Thanks for the updated log. The stack address now looks writable, so the problem must be caused by something else. It could be memory corruption somewhere in your code, or a hardware problem.

Can you reproduce the same behavior with the basic LEDBlink project or does it work as expected?

[support]

Hi,

According to your log, the program exits normally with code 1. This usually indicates an error, so please check the Program Output window for the error messages shown by the program.

[support]

Hi,

Sorry, there is not much documentation on this one. DEBUG_DEFAULT_INTERRUPT_HANDLERS is a preprocessor macro used in an #ifdef statement, so it should be specified in the place where other preprocessor macros are. It is different for different project types, but generally opening the Build Settings page of VisualGDB Project Properties, locating a similarly named field and adding the macro there should be sufficient to get it working.

[support]

Hi,

Looks like your STL might be using a slightly different internal representation than VisualGDB is used to.

Please try reproducing the “no member named _M_data” again and then evaluate the following expression in the Watch window:

*((std::__cxx11::list<UnidentifiedPod, std::allocator<UnidentifiedPod> >::_Node *)<<ADDRESS>>)

Note that the address and the type must match the one reported in the GDB session window (will change between debug sessions)

[support]

Hi,

Thanks for reporting this, looks like a bug on our side. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.15.1444.msi

[support]

Hi,

VisualGDB Project Properties does not support editing the FLASH/SRAM addresses as they are usually defined by us in the BSPs. Looks like your project is a stand-alone project, so you can modify the FLASH/RAM parameters directly in the stm32.xml file:

    <FamilyID>STM32F4</FamilyID>
    <FLASHSize>1048576</FLASHSize>
    <RAMSize>196608</RAMSize>
    <FLASHBase>134217728</FLASHBase>
    <RAMBase>536870912</RAMBase>

[support]

Hi,

Thanks for the detailed log. It looks like the _estack value in your image does not match the one in our linker script and it ends up pointing outside the RAM area on your chip, causing runtime errors. Please fix the value of _estack so that it points at the actual end of RAM.

VisualGDB should normally show a warning that the end of stack is not writable; if this does not happen, please let us know and we will investigate and fix.

[support]

Hi,

It is included in the latest BSP update the is currently undergoing tests. We would expect it to be released in the next 1-2 weeks.

[support]

Sorry about that, it’s a known limitation of ST-Link. This happens because one ST-Link tries to execute a single instruction when stepping over the code, an interrupt arrives and your board starts handling it.

As a workaround, please consider setting the $primask register to 1 via the Watch window during stepping.

This will temporarily disable interrupts. Please do not forget to set it back to 0 once you are done stepping, as otherwise the interrupts won’t be re-enabled.

[support]

Hi,

Sorry, the log you attached was the build log, not debug log. Please follow the instructions described here to capture a debug log.

[support]

Hi,

Just wanted to let you know that instead of hardcoding the library paths, we would recommend adding “=/opt/vc/lib” to the “library search path” field.

Regarding the project conversion, the easiest way to do that is to add another configuration and copy the settings there. As switching large projects between direct and cross-build looks like a relatively rare scenario, we don’t want to add a specific fully-automatic command for it. That said, if we get more requests for this feature, we will reconsider this.

[support]

Hi,

Normally the reference to the imported hardware register file should be saved to the <mcu>.xml file in your project directory (see the EmbeddedProfileFile element in the .vgdbsettings file).

Please ensure that this file exists and is writable.

[support]

Hi,

OpenOCD is the recommended debug method for embedded targets, so it should normally work.

Please try enabling GDB logging via VisualGDB Project Properties -> Advanced GDB Settings and post the full gdb log along with the OpenOCD output here. It should explain what is going on and why the target is not resumed.

[Author]

Posts