wtywtykk

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • in reply to: Remote debugging with custom GDB stub #33164
    wtywtykk
    Participant

    Hi,

    My problem can be solved by using port 22.

    The following is my environment.

    Visual GDB version is 5.6R8

    I’m using Embedded project, with a custom BSP. But the problem can be reproduced from regular STM32 BSP.

    QEMU is the latest source code built with

    ../configure –enable-debug –disable-werror –target-list=”arm-softmmu” –without-default-features –enable-user

    The config for remote gdb stub is in the first floor.

    And here’s a video of the steps to reproduce the issue.

    https://1drv.ms/v/s!AkqxTizATCPayyqgHT9qXiSJ8gyr?e=3T4Sjb

    in reply to: Remote debugging with custom GDB stub #33145
    wtywtykk
    Participant

    Seems that in full-custom mode I have to launch QEMU by myself or by some script since it only runs gdbstub on local computer.

    But anyway, I’ve solved the problem by changing the SSH port to 22, so I can connect without the port in host name.

    in reply to: Remote debugging with custom GDB stub #33133
    wtywtykk
    Participant

    Hi,

    The public key is caused by ssh server config. And it’s working now.

    For the target selection command, I’m still having trouble with “full-custom mode”. The target is always “local computer”. If I change it to SSH, it reverts to local computer when I click “Apply”.

    Thanks

    Attachments:
    You must be logged in to view attached files.
    wtywtykk
    Participant

    Great! It works!

    wtywtykk
    Participant

    Hi,

    I added

    <PropertyGroup>
    <ExecutablePath>$(CommonExecutablePath)</ExecutablePath>
    </PropertyGroup>

    to my vcxproj and it works. And would you add this by default in later updates? Not having PATH in custom steps is just surprising.

    wtywtykk
    Participant

    Hi,

    By clearing the VC++ Directories -> Executable Directories in regular VC projects, the problem can be reproduced.

    And the description for Executable Directories:

    Executable Directories
    Directories in which to search for executable files. Corresponds to the PATH environment variable.

    So I believe the problem is VisualGDB setting this property blank. Setting this to $(CommonExecutablePath) would solve the problem.

    in reply to: Problem with text color under Visual Studio 2019 #26241
    wtywtykk
    Participant

    Hi,
    It works, thank you!

    in reply to: Problem with text color under Visual Studio 2019 #26236
    wtywtykk
    Participant

    Hello,

    I encountered the color problem too. After installing the fix above, the colors were corrected. However, I can’t build the project now, and I got following messages:

    1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\external.targets(6,3): error MSB4018: The “LaunchVisualGDB” task failed unexpectedly.
    1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\external.targets(6,3): error MSB4018: System.TypeLoadException: Could not load type ‘VisualGDB.Builder.ISimpleFormattedBuildLogLineSink’ from assembly ‘VisualGDBCore, Version=5.5.1.1, Culture=neutral, PublicKeyToken=8f764369eb712693’.
    1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\external.targets(6,3): error MSB4018: at Sysprogs.build.tasks.shared.LaunchVisualGDB.Execute()
    1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\external.targets(6,3): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
    1>C:\Program Files (x86)\Sysprogs\VisualGDB\MSBuild\Targets\external.targets(6,3): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

    And following messages show up when I open the project:

    error : Designtime build failed for project ‘C:\Users\163wt\Desktop\EmbeddedProject1\EmbeddedProject1\EmbeddedProject1.vcxproj’ configuration ‘Debug|VisualGDB’. IntelliSense might be unavailable.
    Set environment variable TRACEDESIGNTIME = true and restart Visual Studio to investigate.

    Regards

    in reply to: VisualGDB windows not working in VS2019 #25282
    wtywtykk
    Participant

    Hi,

    The workaround just works fine for me. My environment is: ARM toolchain 7.2.0/8.0.1/r3; STM32BSP 2019.06; OpenOCD 20190625-0.10.0

    in reply to: BIN file size ecxeeds flash size with no error #24312
    wtywtykk
    Participant

    Hi,

    Bad news. The new syntax has some new problem. The “_sidata” symbol points to a wrong address when the “Ignore standard libraries (-nostdlib)” option is turned on in the project properties. I do find an solution to this (using LOADADDR() ), but I’m not confident about it. I’ll test my modification with my previous projects and some special cases.

    However I suspect whether it’s worth taking the risk to change a stable code. May be the linker script should remain untouched.

    in reply to: BIN file size ecxeeds flash size with no error #24244
    wtywtykk
    Participant

    Hi,

    I’m sorry. I just forgot the fact that I can just put the code here…. The code is based on the LEDBlink project for stm32f030f4.

    #include <stm32f0xx_hal.h>
    #include <stm32_hal_legacy.h>
    
    const uint8_t Large_Const_Array[1024 * 13 + 256] = { 0 };
    uint8_t Large_Nonconst_Array[2000] = { 0x00,0x01,0x03,0x04,0x05 };
    
    #ifdef __cplusplus
    extern "C"
    #endif
    void SysTick_Handler(void)
    {
    HAL_IncTick();
    HAL_SYSTICK_IRQHandler();
    }
    
    int main(void)
    {
    HAL_Init();
    
    __GPIOC_CLK_ENABLE();
    GPIO_InitTypeDef GPIO_InitStructure;
    
    GPIO_InitStructure.Pin = GPIO_PIN_12;
    
    GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
    GPIO_InitStructure.Speed = GPIO_SPEED_HIGH;
    GPIO_InitStructure.Pull = GPIO_NOPULL;
    HAL_GPIO_Init(GPIOC, &GPIO_InitStructure);
    
    uint32_t i = 0;
    for (;;)
    {
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_12, GPIO_PIN_SET);
    HAL_Delay(500);
    HAL_Delay(Large_Const_Array[(i++) % sizeof(Large_Const_Array)]);//Just prevent the array from being optimized out
    HAL_GPIO_WritePin(GPIOC, GPIO_PIN_12, GPIO_PIN_RESET);
    HAL_Delay(500);
    HAL_Delay(Large_Nonconst_Array[i % sizeof(Large_Nonconst_Array)]);//Just prevent the array from being optimized out
    }
    }

     

    • This reply was modified 5 years ago by support. Reason: formatting
    in reply to: BIN file size ecxeeds flash size with no error #24217
    wtywtykk
    Participant

    Hi,

    The variables aren’t optimized away or placed into a different section. Normally they are placed after the code and copied to sram by a for loop in the Reset_Handler. But in this case, they are simply placed outside the flash because there are no room left.

    It turns out that the original linker script makes the linker unware of the size needed for the initial value area. From the report by objdump, no section is assigned for them, and the linker simply put all the data after the address that symbol “_sidata” points to.

    The solution I found is changing the data section description in the linker script to

    .data :
    {
    . = ALIGN(4);
    _sdata = .;

    PROVIDE(__data_start__ = _sdata);
    *(.data)
    *(.data*)
    . = ALIGN(4);
    _edata = .;

    PROVIDE(__data_end__ = _edata);
    } > SRAM AT > FLASH

    Note that the “AT” at the first line is removed and the “AT > FLASH” at the last line is added.

    PS: I doesn’t have a board to test this fix for now. But I checked the symbols and sections with objdump, and it seems to work. The linker also shows an error message if the flash isn’t large enough.

    PPS: May be the there are still some problems with the ALIGN statements. It’s not fully tested.

    wtywtykk
    Participant

    Also, “config.h” can no longer generated automatically. VisualGDB adds a reference into the project, but the file itself is not generated.

    in reply to: Poor performance with MSP430F5529 launch pad #12522
    wtywtykk
    Participant

    Hi,

    I’m quite surprised. The “-break-insert -f main” command causes the problem. If I run it before “load”, gdb will break the program into really small pieces and then download them one by one. And if I run “load” before “-break-insert -f main”, there’s no problem.

    So I tried to add “-break-delete 1” in the “Additional GDB Commands” tab to remove this break point before download. It works,but is there any side effect?

    in reply to: Poor performance with MSP430F5529 launch pad #12516
    wtywtykk
    Participant

    The debugger on the launchpad is eZ-FET lite. I’m not sure whether it’s related.

Viewing 15 posts - 1 through 15 (of 15 total)