support

Forum Replies Created

Viewing 15 posts - 2,266 through 2,280 (of 7,873 total)
  • Author
    Posts
  • in reply to: Working from home #27777
    support
    Keymaster

    Generally, network configuration is outside of VisualGDB’s control and hence the help we can provide here is very limited.

    If you are comfortable configuring the VPN, we would advise setting up OpenVPN on one of the machines, and joining the other one to it. If not, please consider using one of the cloud-based VPN services, and connecting both computers to that VPN. This would have the same effect as physically putting them on the same network.

    in reply to: Semihosting in both bootloader and application #27776
    support
    Keymaster

    It might theoretically work, however this is not something we have explicitly tested (or can officially support). When the control passes from the bootloader to the main application, the variable would get rewritten by the initialization code, and that may trigger weird bugs.

    Either way, it could be worth trying. The variable name is s_FastSemihostingState in FastSemihosting.cpp. If it doesn’t work, making some sort of a syscall mechanism between the bootloader and the main application could be a better option.

    in reply to: Working from home #27770
    support
    Keymaster

    Hi,

    No problem, we have published a detailed tutorial here: https://visualgdb.com/tutorials/arm/remote/

    in reply to: Why Does VGDB Expand arrays when put in regions? #27769
    support
    Keymaster

    According to our records, your support period has expired. Hence, we are not able to offer any further technical support, sorry.

    in reply to: Flach code + error in brakpoint, VGDB 5.5, VS 2017 #27767
    support
    Keymaster

    Thanks for sending the logs to our support email. It looks like you are trying to debug a static library:

    C:\Program Files (x86)\Sysprogs\VisualGDB\Keil\arm-eabi-gdb.exe --interpreter mi "C:\Users\amali\Documents\VS_prosject\VisualDGB_5\Test_VGDB_5_IAR_nr2\VisualGDB\Debug\Test_VGDB_5_IAR_nr2.a"​

    Please note that static libraries cannot be debugged directly. They must be linked with the executable projects, that can be actually debugged. Please double-check that the project you are importing is an executable project, not a static library.

    You can check the project type for a VisualGDB project via Configuration Properties -> General page of VS Project Properties (see this page).

    in reply to: Unable to decode i2c @ 350kHz #27766
    support
    Keymaster

    No worries. BTW, we have officially released Analyzer2Go 2.1 that includes this fix, adds support for 5 more STM32 boards, and introduces a few more features.

    You can read more about it here: https://sysprogs.com/w/analyzer2go-2-1-is-out/

    in reply to: How many computers per license #27760
    support
    Keymaster

    You can find an overview of various VisualGDB editions and their features at the following page: https://visualgdb.com/buy/

    in reply to: How many computers per license #27754
    support
    Keymaster

    VisualGDB is licensed per seat i.e. computer/user combination. As a special exception to this rule, we allow the usage of two seats for personal i.e. non-company licenses.

    in reply to: Unable to decode i2c @ 350kHz #27753
    support
    Keymaster

    No problem. We have fixed the issue in the following build: Analyzer2Go-2.1.0.28.msi

    in reply to: Flach code + error in brakpoint, VGDB 5.5, VS 2017 #27747
    support
    Keymaster

    Hi,

    It looks like your project might not be generating debug symbols. Please first try creating a new project from scratch for the same device (using the same compiler) and verify that you can debug it. You can use the following dummy main() function to try out breakpoints/stepping:

    int main()
    {
        asm("nop");
        asm("nop");
        asm("nop");
        return 0;
    }

    If it doesn’t help locate the problem, please describe what happens when you try the dummy project, and also share the .vcxproj file and the gdb log file  for the broken project and we will help you get it to work.

    in reply to: Unable to decode i2c @ 350kHz #27746
    support
    Keymaster

    Sorry, trying to assume the new value instead of verifying a stable value would break the current I2C parsing logic. We might be able to add an option for this in one of the future releases, but we wouldn’t promise it currently.

    As a quick-and-dirty workaround, please try selecting a several clock cycles in the SCL signal and clicking the clock pulse icon. This will print the stable values of the SDA signal, making it easier to read.

    in reply to: Tab indenting not working #27745
    support
    Keymaster

    Thanks for the detailed explanation. Unfortunately, it still doesn’t make full sense. Pressing backspace in the context of the “tab-not-working-1.png” screenshot would delete the ‘/’ character at the end of the /* USER CODE END Includes */ comment. This should not be affected by the tabs settings.

    Generally, if you have generated a .c/.cpp file using STM32CubeMX, it will contain the tabs or spaces depending on the STM32CubeMX settings, not VisualGDB settings.

    The VisualGDB settings for tabs and spaces will apply when adding new lines to the files, but it will not automatically replace them in existing files, to avoid unnecessary changes.

    You can somewhat override it by removing all indentation (Ctrl-A to select the entire file, then press Shift-Tab several times) and reformatting the document using VisualGDB (Ctrl-K, Ctrl-D).

    in reply to: Programming the Application erases the Bootloader #27740
    support
    Keymaster

    Hi,

    If the load command erases the bootloader, the file you are programming might contain some data in the bootloader regions. You can double-check it via the Embedded Memory Explorer, and also by looking at the output from the “load” command.

    If you can confirm that the ELF file does not have any data there, but the ‘load’ command still erases it, please indeed check with Segger, as their gdb stub is handling the low-level FLASH programming behavior.

    The FLASH protection bits are specific to each device family and are usually described in your device’s datasheet. Please refer to the device documentation/datasheets for more details on them.

    If nothing helps, please check if you can program just the correct part of the memory using some command-line tools (e.g. Segger or ST-Link). If this is the case, you can disable the memory programming via VisualGDB Project Properties -> Debug Settings and then run the custom command-line tool before debugging via VisualGDB Project Properties -> Custom Debug Steps.

    in reply to: ST-LINK V3 #27731
    support
    Keymaster

    Hi,

    VisualGDB supports all debug interfaces supported by the OpenOCD tool, including ST-Link v3. If it doesn’t work, please make sure you use the latest VisualGDB 5.5 Preview 4 and install the latest OpenOCD package via Tools-VisualGDB->Manage VisualGDB Packages.

    in reply to: Unable to decode i2c @ 350kHz #27723
    support
    Keymaster

    OK, we have investigated the problem. It looks like the I2C peripheral you are using is doing the clock stretching and it releases the SCL clock at the same time as pulling SDA down to acknowledge the transmission:

    At least, at the current sampling frequency, it looks like SDA changes exactly at the rising edge of SCL (when it should be stable), so Analyzer2Go aborts the I2C parsing.

    Our best advice here would be to try using a faster board (e.g. CYUSB3KIT) that will be able to tell the difference between the times when SDA and SCL change.

    P.S. Although it doesn’t fix this issue, we have improved our I2C parser in the following build: Analyzer2Go-2.1.0.21.msi . It now supports 10-bit addressing mode and works better for zoomed-out signals.

    Attachments:
    You must be logged in to view attached files.
Viewing 15 posts - 2,266 through 2,280 (of 7,873 total)