project transfer

[szohar]

Hi,

I am currently evaluating VisualGDB to be used in our project.

I was trying today to transfer the project to another user to see how easy is to transfer the source code and getting an error “No Tool chain was found“. The visual GDB was installed on his computer.

What is the way to transfer a project, in VS I just downloaded the directory from the GitHub and all was OK. Not sure why this is not working in VisualGDB. Any help will be greatly appreciated.

Thanks

Sharon

 

[support]

Hi,

The easiest way to download the necessary toolchains would be to try creating another project of the same type on the new machine. The VisualGDB project wizard will then automatically download the necessary packages.

You can also configure VisualGDB to automatically deploy certain versions of toolchains, BSPs and debug packages to all machines in your organization using Team Settings as shown in this tutorial.

Let us know if you have any further questions and we will be happy to help.

[szohar]

Hi,

I was able to compile and run an example but when I tried to transfer again a project from one location to another looks as the PATH is different, I tried to fix in multiple locations in the VisualGDB properties but still the builder can find some files.

The proposed tutorial doesn’t help since it is under Linux and we are using Windows-10.

What is the best way to transfer a project, it is very easy to do under VS.

Thanks
Sharon

[support]

No problem, we can help you with this, however we would need to know more about your setup.

Please let us know your project type (Embedded/Linux/MinGW/Android/Arduino/ESP32), where is it built (remote machine, local cross-toolchain), the toolchain you are using and the exact errors you encounter and we will walk you through the necessary setup.

[szohar]

Hi,

The project is Embedded STM32H7, The machines are both Windows-10, the file that can’t be found on the machine the project is copied to is all the shared resources. I can see the path that it is trying to search is wrong. How do I change the Shared resources path, how do I transfer a project easily since this project will need to be shared between multiple users on a daily basis for years.

If it is easier I can give you private access to my computer to show me how to do that.

Thanks
Sharon

[support]

Hi,

Sorry, due to the timing constraints, we have to charge an hourly fee for the screen sharing sessions (please contact our sales if you would like to schedule it), however we are happy to help you either here or via the support form (in case you don’t want to share your setup details publicly).

We also have a detailed tutorial about manually sharing the BSPs between multiple users here: https://visualgdb.com/tutorials/arm/multiuser/

[szohar]

Thanks for the info.

The toolchain relocation can help but how do I do it on an existing project (I don’t want to restart the project as mentioned in the link)?

Thanks

Sharon

[support]

No problem. We have reviewed the tutorial and updated it to reflect the automatic toolchain lookup and installation supported by VisualGDB 5.4.

Please have a look through the updated tutorial and let us know if you have any questions:  https://visualgdb.com/tutorials/arm/multiuser/

If you encounter further problems, please use the 3-step format to describe the issue so that we could suggest the best way to fix it.

[szohar]

Thanks for the update to support VisualGDB 5.4.

I will test it tomorrow and let you know.

Thanks

Sharon

[szohar]

Hi,

I tried to followed all the instruction but still see the same issue.

After more debugging I see that in the original project under the External Dependencies in the project browser I can see all the STM____.h files and when I copy the project to another computer they don’t show up there. I just see there the stdinXX.h files as well as stm32xx_nucleo_144.h.

When following the pointer under the Embedded project setup the shared files pointing to the correct directory.

Will prompt help will be appreciated.

Thanks
Sharon

[support]

The external dependencies are computed by Visual Studio automatically and may take some time to be refreshed, or may not load until you open some files in an editor. The easiest way to check that the new project is operational is to try building and debugging it. If it doesn’t work, please share the error message(s) you get and we will help you resolve them.

[szohar]

I did a search and pointed them to the correct location. Of course I am trying to build it how would I will get all those erros.

Now I am getting the following:
Error C:/Users/Avi/Documents/G3/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32H7xxxx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_gpio.c: No such file or directory SDC_DMA_Test1_FromAT C:\Users\Avi\Documents\G3\Tests\SDC_DMA_Test1_FromAT_2\SDC_DMA_Test1_FromAT\SDC_DMA_Test1_FromAT\arm-eabi-gcc.exe 1

When I am trying to double click on this file I am getting: —————————
Microsoft Visual Studio
—————————
C:\Users\Avi\Documents\G3\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32H7xxxx\STM32H7xx_HAL_Driver\Src\stm32h7xx_hal_gpio.c
Cannot open file.
—————————
OK
—————————

[support]

Thanks for the update. It looks like the STM32 BSP might be missing or incomplete on the second machine.

Have you tried creating a new project for the same device on your second machine using the VisualGDB Project Wizard, as we suggested earlier?

If this didn’t help, the STM32 BSP on the machine might be corrupt/incomplete. Please try removing it via Tools->VisualGDB->Manage VisualGDB Packages and then try creating another STM32H7 project from scratch. Please ensure that the download and installation of the BSP completes without any errors and you should be able to use build STM32-based projects on that machine.

 

[szohar]

Yes, I used an example on the second machine was able to compile and debug, work as expected.

All the BSP files are perfectly OK, the problem is the path that is searching the is wrong.

For example the file that it is compiling exist in C:\Users\Avi\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32\STM32H7xxxx\STM32H7xx_HAL_Driver\Src and not in  C:/Users/Avi/Documents/G3/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32/STM32H7xxxx/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_gpio.c I am not sure where the C:/Users/Avi/Documents/G3/ is taken from.

 

[support]

Thanks for the clarification, it explained what is going on.

It looks like you have created the project using the “Clone STM32CubeMX sample” option and not using one of the regular VisualGDB project templates.

The cloned STM32CubeMX projects do not use the regular system of VisualGDB’s embedded frameworks and hence will only work with a specific version of the STM32 BSP. We normally advise using them to quickly explore the STM32 examples, and then create a regular project using one of the normal samples. We will try to update our documentation to make this more clear.

Either way, we have updated the logic for generating the projects so that the absolute paths won’t get hardcoded for new projects (even when cloning the STM32Cube project samples) in this build: VisualGDB-5.4.105.3127.msi

In order to fix a project that was created earlier, please try opening the .vcxproj file in a text editor and replace all instances of C:/Users/Avi/Documents/G3/AppData/Local/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32 with  $(BSP_ROOT). Please also search the .vcxproj file for “c:” to ensure that no other absolute paths are hardcoded.

[Author]

Posts