[parsec67]

Hi,

I also encountered this exact issue after upgrading (MSBuild project) and clicking the Regenerate MCU files fixed the problem.

Having said that, this had me stumped for a good hour before I eventually found this post. I would like to put in a suggestion that, if possible, breaking changes such as this one are documented somewhere on your website for each public release so that this and similar problems can be more easily anticipated when updating VGDB. What I’m saying is, if I had read something like “Change: compactcpp lib removed: Fix: Rebuild MCU files” beforehand I would have already known the cause of the problem and saved a lot of time. Even a simple readme text file next to the download link is better than no information at all.

Thanks for an otherwise great product.

[parsec67]

Hi,

I am unable to reproduce the initial problem I described, this only happened once with the first project I loaded after upgrading to 5.3.  I even tried with an identical backup of that project and it, as well as every other 5.2 project that I tried, were all easily fixed by clicking repair.

Note the code analysis error is also gone after repairing.

The difference between loading the first and any successive project was a message dialog that was shown when loading the first project. It said something along the lines of “this project needs to be converted to 5.3. If you convert you will not be able to open this project with 5.2”. I have not seen this dialog since.

As things seems to work now it might not be worth pursuing this further. If I encounter the problem again I will revisit this post.

[parsec67]

Hi, attached.

EDIT: Couldn’t attach the .props file so here it is in its entirety:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup Condition="'$(RemoteBuildHost)' == ''">
        <ToolchainDir Condition="('$(ToolchainID)' == 'com.visualgdb.raspberry_pi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '4.9.2/7.7.1/r4'))">C:\SysGCC\Raspberry</ToolchainDir>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.raspberry_pi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '4.9.2/7.7.1/r4')) and Exists('C:\SysGCC\Raspberry\toolchain.props')">C:\SysGCC\Raspberry</ToolchainProfile>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.raspberry_pi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '4.9.2/7.7.1/r4')) and Exists('$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.raspberry_pi-4.9.2_7.7.1_r4\toolchain.props')">$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.raspberry_pi-4.9.2_7.7.1_r4</ToolchainProfile>
        <ToolchainDir Condition="('$(ToolchainID)' == 'com.visualgdb.xtensa-esp32-elf') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '5.2.0/7.10/r5'))">C:\SysGCC\esp32</ToolchainDir>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.xtensa-esp32-elf') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '5.2.0/7.10/r5')) and Exists('C:\SysGCC\esp32\toolchain.props')">C:\SysGCC\esp32</ToolchainProfile>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.xtensa-esp32-elf') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '5.2.0/7.10/r5')) and Exists('$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.xtensa-esp32-elf-5.2.0_7.10_r5\toolchain.props')">$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.xtensa-esp32-elf-5.2.0_7.10_r5</ToolchainProfile>
        <ToolchainDir Condition="('$(ToolchainID)' == 'com.visualgdb.arm-eabi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '6.2.0/7.12/r4'))">C:\SysGCC\arm-eabi</ToolchainDir>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.arm-eabi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '6.2.0/7.12/r4')) and Exists('C:\SysGCC\arm-eabi\toolchain.props')">C:\SysGCC\arm-eabi</ToolchainProfile>
        <ToolchainProfile Condition="('$(ToolchainID)' == 'com.visualgdb.arm-eabi') and (('$(ToolchainVersion)' == '') or ($(ToolchainVersion) == '6.2.0/7.12/r4')) and Exists('$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.arm-eabi-6.2.0_7.12_r4\toolchain.props')">$(LOCALAPPDATA)\VisualGDB\ToolchainProfiles\localhost\com.visualgdb.arm-eabi-6.2.0_7.12_r4</ToolchainProfile>
    </PropertyGroup>
</Project>

• This reply was modified 7 years, 1 month ago by parsec67.

Attachments:

You must be logged in to view attached files.

[parsec67]

Hi,

I did not edit anything manually, just closed VS2017, updated to 5.3 and then reopened the project. Only the first project that I opened failed in this strange way, the others are reporting “No toolchain found” but will build after applying the fix. Creating new projects = no issues.

My old .vgdbsettings have no ToolchainID element while converted projects look like this:

<ToolchainID>
      <ID>com.visualgdb.arm-eabi</ID>
      <Version>
        <GCC>6.2.0</GCC>
        <GDB>7.12</GDB>
        <Revision>4</Revision>
      </Version>
    </ToolchainID>

 

Old .vcxproj:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|VisualGDB'">
    <GNUConfigurationType>Debug</GNUConfigurationType>
    <Toolchain>C:\SysGCC\arm-eabi</Toolchain>
  </PropertyGroup>

 

Converted .vcxproj:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|VisualGDB'">
    <GNUConfigurationType>Debug</GNUConfigurationType>
    <Toolchain>C:\SysGCC\arm-eabi</Toolchain>
    <ToolchainID>com.visualgdb.arm-eabi</ToolchainID>
    <ToolchainVersion>6.2.0/7.12/r4</ToolchainVersion>
  </PropertyGroup>

 

[parsec67]

Hi, yes I have 5.2 installed. Will update to 5.3, thanks.

[parsec67]

Thanks, updating worked by renaming the old folder and then running the r4 installer. Although in VS2017/Manage VisualGDB Packages I now have “Update to version 5.2.0/7.10/r2 available!”.

[parsec67]

donvukovic: If your ESP32 is in fact on COM10, in ESP-IDF menuconfig->Serial flasher configuration->Default serial port try assigning COM10 instead of /dev/ttys9.

support: I too am getting “fatal: Not a git repository (or any of the parent directories): .git” and “EXEC : warning : Toolchain version is not supported: crosstool-NG crosstool-ng-1.22.0-61-gab8375a9” when building an imported project and curious what this signifies?

(My imported project is a modified blink with WiFi component added. Under VisualGDB it fails to link and reports a host of undefined references at step “LD blink.elf”. Running make under ESP-IDF/msys2 it will build without errors.)

[parsec67]

Thanks, yes with esptool.py it looks straightforward, first convert elf to bin, then flash

python esptool.py --chip esp32 elf2image myapp_esp32

python esptool.py --chip esp32 --port COM7 --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x10000 myapp_esp32.bin

This works directly under Windows Python 2.7 after installing pyserial so no dependence on the Espressif’s msys2 distribution.

I would have preferred a built-in automated way of flashing via USB directly after build, is this something that could be added in future releases?

[parsec67]

That did the trick, thanks!

For reference, APBPrescTable is in BSP4.2 defined in system_stm32f4xx.c whereas in BSP4.1 it is missing. Instead, in BSP4.1 the affected functions HAL_RCC_GetPCLK1Freq(), HAL_RCC_GetPCLK2Freq() and setting of global SystemCoreClock (all in stm32f4xx_hal_rcc.c) reference APBAHBPrescTable which is defined at the beginning of this file. So adding the below line to system_stm32f4xx.c fixed my problem:

const uint8_t APBPrescTable[8] = { 0, 0, 0, 0, 1, 2, 3, 4 };

I just read in the ST forums that someone using a different dev environment had been caught by this too.

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

[parsec67]

Good to know, thanks. No rush with this so I’ll wait.

[parsec67]

Thanks, looks much better now!

 

[parsec67]

Hi,

Thanks for looking into this and good to know the reason/fix. I have this warning disabled intentionally since vanilla VS2015 is able to cope with inconsistent line endings. The issue looks to be isolated to Clang, VS Intellisense does not throw a tantrum for this specific project. I’ll switch the warning back on to avoid future complications.

[parsec67]

Hi,

Just curious if you were able to replicate the issue? I emailed a project last Friday.

[parsec67]

Yes, I can reproduce on a very basic project with a few variable declarations and functions added in order to see the problem more clearly. I have a project zipped up and ready to send, which e-mail address do you want it sent to?

[parsec67]

Update: Found what caused Clang Intellisense to bomb out. This type of conditional define will screw up everything below it as described in my first post;

#ifdef CONDITION
    #define MYDEF 20
#else
    #define MYDEF 10
#endif

This causes no problems for VS native Intellisense. Was able to reproduce issue in several independent projects.

• This reply was modified 7 years, 9 months ago by parsec67.
• This reply was modified 7 years, 9 months ago by parsec67. Reason: clarification

[Author]

Posts