[parsec67]

Many thanks, that did the trick!

Any idea why my license activation was reset?

[parsec67]

Happy to report that this solution worked for me too, although I didn’t see any of the error messages that codefrog mentioned. In my case it was a previously uninstalled VS2017 environment that caused the VGDB setup wizard to error out.

Thanks!

[parsec67]

Hi,

Just installed VS2022 Community yesterday and today I tried installing VisualGDB 5.6 using the downloaded file VisualGDB-5.6-trial.msi. It did not go well.

In the setup wizard I select “Change”, then untick Visual Studio 2019 since I already have VGDB installed for this version. The setup begins, prompts if  I want to allow it to make changes etc. but then almost instantly quits with the message “ended prematurely”. Please see attached screenshots.

 

Attachments:

You must be logged in to view attached files.

[parsec67]

I’m interested in knowing how to reduce project folder size as well. My compressed backup files for one of my oldest STM32 projects are 0.5G each. The uncompressed project folder is near 1G, meanwhile a newer project weighs in at only 225 MB.

I’d like to know which project subfolders can be safely deleted (or excluded from backup) without affecting the ability to later restore the project from a backup.

[parsec67]

Hi,

Linker script and startup files appears okay now.

I have uploaded the problematic CubeIDE test project here: https://filebin.net/wjpfj52dull5gmcr

Thanks

[parsec67]

Update: Scratch my point #5, I got it to debug when importing as MSBuild. On my first attempt with VGDB build 5.5.6.3661 I accidentally had GNU Make set when importing.

The other 4 points remain and I was able to get the project in working condition by following and fixing each step as outlined above.

 

[parsec67]

PS. Sorry for formatting issues but this editor really blows and I was unable to edit more than twice.

[parsec67]

Hi,

Still hit a few snags:

1. CubeIDE project has a startup assembler code ‘startup_stm32f415rgtx.s’ which clashes with VGDB default startup C file:

 

C:/Users/..../VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32F4xxxx/StartupFiles/startup_stm32f415xx.c:955: multiple definition of `Default_Handler';</code>

 

Excluding startup_stm32f415rgtx.s from the project fixed this issue.

 

2. Existing CubeIDE linker script was not imported, instead the project defaulted to VisualGDB's linker script. This caused a linker error:

<code>ld.exe: C:\dev\stm32\VisualGDB\bootmx/../../CubeIDE/Core/Src/main.c:178: undefined reference to `_app_start'

Also it appears the source hyperlink in the error message evaluates incorrectly. Clicking on it caused an exception:

VisualGDB version: 5.5.6.3661
------------------ vz1 ------------------
vz1: Failed to open 'c:\sysgcc\arm-eabi\arm-none-eabi\CubeIDE\Core\Src\main.c:178'. ---> System.ArgumentNullException: Value cannot be null.
Parameter name: textBuffer
at Microsoft.Requires.NotNull[T](T value, String parameterName)
at ....

Creating a local copy of the linker script and modifyng it to match the original fixed this issue.

3. A few header files were not added to imported project subfolders (filters) where they were supposed to be. Notable here is that the CubeIDE project has .c and .h files bundled in some folders. For instance, FATFS\Target contains ffconf.h, user_diskio.h and user_diskio.c. VGDB splits FATFS\Target into two instances in Solution explorer, ‘Header files’ and ‘Source files’, but only imports user_diskio.c to ‘Source files\FATFS\Target’

4. One entire project subfolder was not imported (but was listed under Include directories):

Middlewares\Third_Party\FatFs\src

This caused a couple of undefined reference linker errors. After I added it manually in Solution Explorer the project finally built with no errors.

5. I am unable to start a debug session. The solution is not recognized as a VisualGDB project and I only have option Debug->x86 in the VS navigation bar. The project properties shows platform as VisualGDB. Right-clicking on project in Solution explorer and selecting “Debug->Start new session” gives me an error dialog: “Unable to start debugging. Check your debugger settings…”. Settings are good (ST-Link V2) and identical to what I use for other projects.

Since it may be difficult to follow exactly what is going on based on my explanations only I’d be happy to send you the entire CubeIDE project if you want to try to replicate on your end.

• This reply was modified 4 years, 6 months ago by parsec67.
• This reply was modified 4 years, 6 months ago by parsec67.

[parsec67]

I second this request.

As well, in the case of ESP8266, the option to hide the dialog “The programmed image does not contain the GDB stub. Do you want to open instructions…” .

[parsec67]

Hi,

As per Espressif documentation, the partition table should be generated automatically during build if configured in sdkconfig and the resulting binary saved in Debug/Release folders.

Below is just for future reference.

I created a new blank GNU make project based on hello-world sample, then in VisualGDB/ESP-IDF configuration/Partition table:

Partition table = Custom partition table CSV
Custom partition= part2.csv

part2.csv located in project root folder. This correctly builds part2.bin and puts the binary in the Debug project subfolder.

I then created a new blank CMake project based on hello-world sample with identical settings in ESP-IDF configuration and part2.csv located in project root directory. The partition table part2.bin is not built, there are no traces of any part2.bin file in the project directory and no references to it or the CSV file in the build output. I tried placing the CSV file in different locations in the file system, providing full path etc. etc. but nothing made a difference.

With the underlying toolchain being the same there is obviously a discrepancy between GNU make and CMake. Searching Interwebz or looking at Espressif’s GitHub issue tracker was fruitless. So I think I’ll just stick with the slower but working GNU make for now.

[parsec67]

Definite improvement, thanks. Been debugging the whole day and I see the break-in dialog only occasionally but it always succeeds after a few seconds. I also noticed in my settings that I had programmer set to ST-Link v2.1 which used to work fine but is now reported as deprecated. Perhaps this was related to my problem? At any rate I have switched to ST-Link v2 and it appears to be solid.

Another thing I noticed is that VStudio loads quickly now compared to before. Just curious if you made some changes to improve startup times?

[parsec67]

You have news about this issue, now I try use USART with LL driver but I have many error, I m wrote to ST but I haven’t any reply

I reported this back in December 2017 (https://bit.ly/2C56WG9). Rather quickly, only 11 months later in November 2018, an ST  employee replied that they would fix this issue in a future CubeMX update. I have not heard anything since so I’m guessing it is not a priority. Given the pace of things I think we can expect a fix in July 2021.

HAL is crap, it’s just for beginners.

HAL is what is states to be, hardware abstraction, and it does this job fairly well. I have effortlessly migrated portions of code between F0, F4 and F7 products which would not have been nearly as easy with code based on direct register manipulation. LL kind of improves on full manual low level coding but I found it poorly documented in some cases and it felt less mature at the time. Maybe things have changed now.

[parsec67]

I’m using ST-Link V2 and it works great with OpenOCD 0.10.0.

In the first line of your debug log there is a switch “-f C:/Users/mdric_000/AppData/Local/Temp/tmp62F7.tmp”

I don’t know if this is significant but comparing to my working setup I have “-f target/stm32f4x.cfg”

So maybe verify in VisualGDB Project properties/Debug settings window that “Debugged device” is set to your MCU type?

Also in the Debug settings options, try changing JTAG/SWD debugger option to ST-Link V2.1

HTH

[parsec67]

I don’t have an F7 but…. Did you change the interrupt vector table for your SRAM project? If not then interrupts will not work when booting from SRAM because interrupts — SysTick included — are offset by the start address of SRAM (0x20000000 on F4). The RM for your device should have more info about this.

[parsec67]

The “please check the bin file” problem mentioned above turned out to be FileZilla not transferring .bin files in binary mode with auto-detect on so that problem is solved, nothing to do with VGDB and my project is now working satisfactory.

[Author]

Posts