Forum Replies Created
-
Posts
-
Looks like everything was mostly fixed in 6.0.107.5295. I tried out the checkbox for relocating the project file and it worked on the project file. The solution file still wound up in a subfolder… I should have been more specific about that.
I did find something new. Doing Build->Rebuild with “Delete build folder” selected for “Clean mode” (under VisualGDB Project Properties) fails to build. The Build Output window shows
Rebuild started...
------ Rebuild All started: Project: TestProject, Configuration: Debug VisualGDB ------
Removing C:\Repos\TestProject/build/Debug...
note : Run "C:\PROGRA~1\CMake\bin\cmake.exe --build build/Debug" in directory "C:\Repos\TestProject" on local computer
C:\PROGRA~1\CMake\bin\cmake.exe --build build/Debug
Error: C:\Repos\TestProject\build\Debug is not a directoryIt’s missing the
cmake --preset=Debugstep. I saw this on 6.0r6 and on 6.0.107.5295.Thanks for that update. I’ll check out the new build of VisualGDB and get back to you.
To add a little more info for point 3, I think the problem somehow was related to choosing the “Specify compiler options manually” tab. I had to close and reopen Visual Studio to get a PAC5532 based project to correctly load the CMakePresets.json file. However, importing a CMake project for an nRF52833 worked great.
I figured out what the problem was by very carefully comparing the outputs of the good project and the problem project.
The problem was there were some CMake files left over from a previous attempt in my project root directory, rather than the /build/VisualGDB/Debug sub directory. Files like CMakeCache.txt, cmake_install.cmake, build.ninja, .ninja_log, and .ninja_deps.
When the project was loaded (I think), the Advanced VisualGDB Project Output was outputting
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Repos/<repo root>/right after the “Running CMake” long command.
Once I deleted everything that I knew was not needed from the repo root, that log became
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Repos/<repo root>/build/VisualGDB/debugAnd it appears to be working.
The nRF52833 project uses the nRF 5 SDK, not the nRF Connect SDK, and it’s working fine. The problem project is firmware for a PAC5532. Is there a way to manually set the CMake executable that VisualGDB will use when it loads a CMake project?
Also with the nRF52833 project, I did convert it to standalone under “Embedded Project” so it better mimicked the PAC5532 project.
That may not be it. On the good project, CMake will detect the tool chain (see good config.txt). However, on the bad project, CMake jumps straight to
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to <location>(see bad config.txt)
I can reproduce this and fix it on a command line. If I copy-paste the “Running CMake” command into a command line, same result. However, changing the cmake.exe to a non-VisualGDB version results in CMake correctly detecting the toolchain.I think I might be onto something. I created a new project with a different firmware project that uses the nRF52833. I was able to select the nRF52833 during project creation during the “Device Selection” step. I ran into some issues with the CMakePresets.json, but I switched the project config’s “Store build settings in” to “Project File” and got everything to work fine.
However, the problem project is based on the PAC5532, which does not show up in the “Device Selection”. I selected “Specify flags manually” and left everything as default, and then imported the CMakelists.txt and toolchain definition files.
I’ve been able to reproduce this twice. The project with the PAC5532 will always fail with
No reply via CMake file API. Restarting CMake in server mode...
CMake Error: CMake server mode has been removed in favor of the file-api.The project wit hthe nRF52833 will work (with a little fiddling).
Okay. The FindToolchain.props file was the missing piece. The build agent service account didn’t get the GCC12 location when the toolchain was installed on the build server.
However, I checked my user account’s %LOCALAPPDATA%\VisualGDB\FindToolchain.props file, and it also was not updated. I downloaded and installed the toolchain (with “install for all users” checked) from here: https://gnutoolchains.com/download/
Do I need to install the toolchain in a different way to get FindToolchain.props file to automatically update?
Looks like we finally got support renewed. I’m resuming work on this.
The build pipeline (Azure DevOps) is using the VSBuild@1 task, which uses a .proj file to build the firmware.
Azure Devops Pipeline:
- task: VSBuild@1
inputs:
solution: $(Build.Repository.LocalPath)Application.proj
configuration: 'Debug'- task: VSBuild@1
inputs:
solution: $(Build.Repository.LocalPath)Application.proj
configuration: 'Release'.proj file
<div>
<div><MSBuild Projects="$(MSBuildProjectDirectory)\BLE_MCU\Application\Application.vcxproj"</div>
<div>Properties=" Configuration=$(Configuration);</div>
<div>Platform=VisualGDB;"</div>
<div>ContinueOnError="ErrorAndContinue"/></div>
</div>
Everything works as expected if I build locally using the .proj file from a Developer Command Prompt for VS 2019 console. But running the build on the build server still compiles with GCC 9, even though the projects are configured to use GCC 12.
On my local machine, GCC 9 is installed at C:\sysgcc9 and GCC 12 is installed at C:\SysGCC.
On the build server, GCC 9 is installed at C:\SysGCC and GCC 12 is installed C:\SysGCC12.What’s really disconcerting about this is the only reason I caught this is because I added a new compiler flag as part of the GCC 12 migration that GCC 9 didn’t have, and that threw up errors. I would have expected VisualGDB to have an explicit “Could not locate compiler X” error.
I think I might have found a possible bug? I went with the recommended route of installing GCC12 along side GCC9. I installed GCC12 on my local machine and the build server. I updated all of the projects to use GCC12 in a work branch, pushed, but the build server is still using GCC9. The only reason I noticed is because the build is failing because I enabled the -fanalyze flag which isn’t present in GCC9.
The projects’ .vcxproj and .xml files both have the toolchain version set to 12.3.1/13.2/R1, but the build server is still using GCC9. It doesn’t matter if I trigger a build through the pipelines or manually try to build firmware from a Developer Command Prompt.
This example shows a function call to
IsRunningUnitTests, but I can’t seem to find it in the test library. I’m using CppUTest.Oh. Wait a minute. I think I know what’s happening: clicking on “run” in the test runner doesn’t run the pre-debug steps, which means the updated CRC and signature never gets flashed to the board, which means the bootloader refuses to launch the application (because the CRCs don’t match)
The project should be available here:
