[support]

Hi,

Sorry, the remote source cache location is fixed and cannot be changed.

One quick workaround would be to try using the Advanced CMake Subsystem with the direct SSH file access. It will perfectly support long paths, duplicate case-sensitive names and other scenarios that don’t work on Windows.

Another option would be to indeed copy the toolchain directory somewhere locally and then use the header discovery mechanism to quickly locate the missing headers.

[support]

Hi,

We are sorry that it’s not working out. We are planning to add Arduino support in the upcoming VisualGDB 5.4, however we still don’t have a specific deadline for it set (we are currently finishing a major VisualKernel update and will make more specific VisualGDB plans once it is released).

Until we officially support it, we can answer general questions (e.g. help you resolve the Wire.h problem), but we cannot guarantee that it will fully work, as there might be non-trivial Arduino-specific changes. We could also help you convert the project to VisualGDB as a part of our paid consulting services, however if you are OK waiting a few months until Arduino is fully supported, you will get this functionality as a part of your regular VisualGDB license.

[support]

Hi,

The code analysis results are normally shown in the regular Errors pane (and are also highlighted in the code). They don’t interfere with the build and can be distinguished by the “[Clang IntelliSense]” prefix:

If they don’t appear for your project, please try creating a new project from scratch and see if this works. If yes, please try comparing project properties between the 2 projects.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, we have released a toolchain update including SDK 2.1.0. You can update it via VisualGDB Package Manager.

[support]

Hi,

This looks like a VS bug that was present in a few preview builds of VS2017, but got fixed later. Could you please attach a screenshot of your About Visual Studio window (not about VisualGDB), so that we could double-check that the build number matches the one in our test environment?

[support]

Hi,

Sorry, this would not work. VisualGDB activation system is designed to be a non-intrusive as possible and to avoid frequent reactivations, so reverting to trial won’t deactivate VisualGDB (the feature is intended for checking out the features of higher editions when considering an upgrade).

Please note that we do offer an experimental floating license (that counts simultaneous sessions, but requires continuous Internet connection) in some cases. Please contact our sales with a description of your setup so that we could help you find a suitable licensing model.

[support]

Hi,

Thanks for attaching the project. The new STM32CubeMX importer actually does exactly what you are describing – it explicitly removes references to the STM32 HAL installed by VisualGDB so that the project can use the version from STM32CubeMX.

The project you attached doesn’t build because you have both the regular and the advanced semihosting enabled at the same time. Please disable the regular semihosting as shown below:

• This reply was modified 7 years, 6 months ago by support.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This looks like a project created with an old version of the STM32 BSP. Newly created projects with the latest BSP should not have it. Either way, the warning is harmless and can be ignored.

[support]

Hi,

That would be normal if the imported code provides its own I/O functions. The linker usually mentions both source files defining the conflicting function in the error message, so you can simply locate the one coming from CubeMX and remove it from the project.

[support]

Hi,

If the device shows the correct “Hello, World” page, but the gdb stub doesn’t work, the problem is likely related to UART settings. Please try replacing user_init() with this:

int user_init()
{
    gdbstub_init();
    
    for (;;)
    {
        os_printf("%c", 0x55);
    }
}

Then program the firmware, open the COM port in a terminal and restart your board. Normally you should see something similar to this:

load 0x40100000, len 31360, room 4 
tail 12
chksum 0x41
csum 0x41
s?stem param error, use last saved param!
rf cal sector: 120
rf[112] : 03
rf[113] : 00
rf[114] : 01

SDK ver: 2.0.0(656edbf) compiled @ Jul 19 2016 17:58:40
phy ver: 1055, pp ver: 10.2

$T05#b9

The “$T05#b9” message is generated by the gdb stub (it’s actually a gdb packet reporting a stop). If you don’t see the message, please comment the call to gdbstub_init() and use a logic analyzer to check the output of the UART pins. 0x55 corresponds to 01010101 in binary form, so observing the output in a logic analyzer and measuring the signal period should help find the baud rate the board is using.

 

[support]

Hi,

The conflicts between files would likely be caused by VisualGDB referencing its own frameworks (e.g. STM32 HAL). If you are using the latest VisualGDB 5.3 with the new automatic STM32CubeMX importer as described here, it should not happen. If it does, could you please upload the project generated by STM32CubeMX and the project imported by VisualGDB and post a link here so that we could see what is going on?

You can also just remove the references to the VisualGDB version of the HAL via VisualGDB Project Properties -> Embedded Frameworks.

[support]

Hi,

If you would like to use fast semihosting, you would need to remove other implementations of the low-level I/O functions from the project. The default implementations from the toolchain shipped with VisualGDB are marked as weak, so they will be automatically replaced by the fast semihosting ones (when enabled), however if your project provides different implementations (in syscalls.c?) please try excluding them from the project (if you are using the GNU ARM toolchain, please disable regular semihosting on the first page of VisualGDB Project Properties).

[support]

Hi,

Yes, it could have been something caused by the project path. If you encounter this again, please try switching GDB Session to “All GDB interaction” and check the gdb messages about loading symbols.

[support]

Hi,

Looks like the project has not been built. Please ensure you build it before starting debugging.

• This reply was modified 7 years, 6 months ago by support.

[support]

Hi,

No problem, we will explain how the “Step into specific” functionality works.

First of all, VisualGDB doesn’t support “blacklisting” functions for automatic stepping through them yet (we will try to add this in one of the next releases), however it supports the “Step into specific” command as shown below:

Normally it should work out-of-the-box, however if it doesn’t, you can fine-tune it by editing the StepIntoSpecific.xml file in the VisualGDB directory. The Step Into Specific feature works by disassembling the instructions corresponding to the active line in code and searching for the patterns defined in StepIntoSpecific.xml. Once a pattern is found, the corresponding label will be shown in the “Step into specific” menu and once you select it, VisualGDB will set a breakpoint at that instruction and then do a single “step in” step.

If it doesn’t work as expected and you are not sure how to adjust it, please let us know the details (i.e. your code and the output from the GDB Session window showing VisualGDB disassembling the current line) and we will help you get it to work.

Attachments:

You must be logged in to view attached files.

[Author]

Posts