[wtywtykk]

Hi,

I want to use different config for the applications. So I use multiple find_bsp with different ALIAS. Is this the preferred way?

Also could you point out where “VS properties for the BSP item in Solution Explorer” is? I can’t find it in the property window(Right click->properties).

Regards,

Tianyi

[wtywtykk]

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

[wtywtykk]

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.

[wtywtykk]

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]

Great! It works!

[wtywtykk]

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]

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.

[wtywtykk]

Hi,
It works, thank you!

[wtywtykk]

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

[wtywtykk]

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

[wtywtykk]

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.

[wtywtykk]

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, 9 months ago by support. Reason: formatting

[wtywtykk]

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]

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

[wtywtykk]

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?

[Author]

Posts