[parsec67Participant]

Hi,

Linker script and startup files appears okay now.

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

Thanks

[parsec67Participant]

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.

 

[parsec67Participant]

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

[parsec67Participant]

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:

C++

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 ....

1 2 3 4 5 6

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):

C++

Middlewares\Third_Party\FatFs\src

1	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 9 months ago by  parsec67.
• This reply was modified 9 months ago by  parsec67.

[parsec67Participant]

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…” .

[parsec67Participant]

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.

[parsec67Participant]

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?

[parsec67Participant]

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.

[parsec67Participant]

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

[parsec67Participant]

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.

[parsec67Participant]

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.

[parsec67Participant]

Thanks, yes I looked at the OTA example but it helps me only halfway as in my application I update by polling a web server periodically. Unfortunately I have not been able to get this to work, always getting “please check the bin file” after upgrade download has started and downloaded some bytes.

I did use the ESPImageTool.exe to generate .bin files and they are correctly identified as App1 and App2. Also tried with esptool.py 2.1 using elf2image and –version=2 option but same problem with both methods. I believe this is not a VisualGDB related issue but can’t be sure, the resources I have found online are not very clear on how to identify the problem.

I noticed that when switching configurations as per tutorial example, if the Embedded Project->Default linker script is changed from App1 to App2 it will also change for all configurations. It doesn’t seem to impact the binaries and the MSBuild linker script setting is unchanged.

[parsec67Participant]

Hi again,

Does the updated R14 toolchain in some circumstances automatically flash blank.bin in addition to esp_init_data_default.bin?

I’ve now moved over to an Adafruit Huzzah (4MB) and noticed that WiFi credentials that are saved at memory address 0x3FE000 will sometimes get erased after flashing. I have not been able to discern any pattern, sometimes this sector is left untouched after flashing while other times it will be modified.

[parsec67Participant]

Thanks for checking, I will give R14 toolchain a spin.

> You can program the FLASH memory without debugging via Debug->Program Firmware without Debugging.

Of course, it was there right in front of me all this time…

[parsec67Participant]

I had something similar happen to me a while back, in my case me it was improper line endings that caused Clang Intellisense to see  bomb out. See this thread:

Clang Intellisense out of whack

I’ve also noticed it happen sometimes when there is a syntactical error somewhere in the code, such as a missing closing brace, but it is very rare.

[Author]

Posts