support

Forum Replies Created

Viewing 15 posts - 6,796 through 6,810 (of 7,824 total)
  • Author
    Posts
  • in reply to: __libc_init_array problems #6918
    support
    Keymaster

    Hi,

    We have just rechecked the latest toolchain with another Cortex M3 MCU (STM32F100VB) and could not reproduce the problem, so the fault is not caused by ARM vs Thumb problem.

    In order to pinpoint the problem, please use the call stack window together with the disassembly view to find a specific instruction that causes the fault. If this is not helpful, open the Disassembly view before stepping into __libc_init_array() and then step into it, doing one instruction at a time until the fault occurs. If the fault happens on a memory accessing instruction, please check the address used in that instruction. If it is outside the FLASH/RAM ranges, something got wrong with the memory map (e.g. a bug in the linker script or a wrong address somewhere).

    in reply to: Compiling disabled #6917
    support
    Keymaster

    Hi,

    Unfortunately, compiling individual files is not yet supported. VisualGDB uses GNU Make as the build system and in this mode Visual Studio can only pass “build project”, “rebuild project” and “clean project” commands, but not individual file commands.

    in reply to: VisualGDB doesn't link libraries #6912
    support
    Keymaster

    Hi,

    Please try locating the file that defines the UtilInit() function. If it is a C file, ensure that the declaration in the .h file (or the #include<> directive including the .h file) is wrapped with extern “C” {}.

    in reply to: Problems with STM32CubeMX and VisualGDB #6911
    support
    Keymaster

    Hi,

    VisualGDB 4.3 does not support the latest STM32 BSP that is required to use STM32CubeMX.

    After you upgraded to 5.0 please upgrade your STM32 BSP via Tools->Embedded Tools Manager and then try following the tutorial from the beginning. This should get all paths to work.

    in reply to: STM32L151 Problem #6910
    support
    Keymaster

    Hi,

    Texane ST-Link is separate from OpenOCD, however it’s also buggier. You can try using it, however you may need to unplug and replug your ST-Link if it starts behaving strangely.

    Can you verify the lost variables problem with the following program?

    int g_Global = 123;
    int main()
    {
        if (g_Global != 123)
            asm("bkpt 255"); 
    }

    Does it trigger the breakpoint? What is the address of g_Global?

    in reply to: Problems with STM32CubeMX and VisualGDB #6906
    support
    Keymaster

    Hi,

    Are you using the latest VisualGDB 5.0 and the latest STM32 BSP? Does the normal LEDBlink (HAL) project build correctly?

    in reply to: STM32L151 Problem #6904
    support
    Keymaster

    Hi,

    OpenOCD usually takes a few months to support the latest ST devices. Once it supports it, we will update our package.

    Regarding the problem with the variables, could you please provide an example? Could you also verify that the variable address is within the RAM region according to the datasheet and that the value is actually lost, not just seems to be lost via the debugger (e.g. output it to a COM port from your firmware).

    in reply to: Moving a VisualGDB license to another computer/VM #6903
    support
    Keymaster

    Hi,

    Yes, simply contact our support with your license key and they will reset your activation.

    in reply to: ESP8266 and XT-OCD Settings #6902
    support
    Keymaster

    Hi,

    Good to know you got it to work. Let us know if you encounter further problems.

    in reply to: preprocessor define with content of a build variable #6901
    support
    Keymaster

    Hi,

    The “propagate to the environment” flag is only supported for the per-user variables, not for variables set from commands. In the case you mentioned, specifying GitRevision=$(GitRevision) explicitly is the recommended way to go.

    in reply to: preprocessor define with content of a build variable #6894
    support
    Keymaster

    Please double-check that your custom variable has the “propagate to the environment” flag. This can be also caused by a bug in the .Net framework that changes all environment variables to lowercase. You can try $(git_revision) instead. If this does not help, you can explicitly specify it in GNU Make arguments: GIT_REVISION=$(GIT_REVISION). Then VisualGDB will expand $(GIT_REVISION) and pass the actual value to the Make command line.

    in reply to: JLinkGDBServerCL #6893
    support
    Keymaster

    Hi,

    You could select the “custom mode” as the debug method and specify “gdb –interpreter mi $(TargetPath)” as your command and “target remote :<port>” as the target selection command.

    Then VisualGDB won’t take any extra steps like trying to run a GDB stub.

    in reply to: Command-line action failed when build via SSH. #6892
    support
    Keymaster

    Hi,

    Please open VisualGDB Project Properties and check the build command there. If you are not sure, please send us your .vgdbsettings file so that we could help you locate the command.

    in reply to: STM32F7 Disco LED Blink #6884
    support
    Keymaster

    Hi,

    No problem. If you encounter further problems, feel free to contact us.

    in reply to: JLinkGDBServerCL #6881
    support
    Keymaster

    Hi,

    Good to know you got it to work. If you encounter further problems, feel free to let us know.

Viewing 15 posts - 6,796 through 6,810 (of 7,824 total)