Forum Replies Created
-
Posts
-
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:
I’ve created a new project and it also has this issue. I did notice this only happens when Advanced Clang Intellisense is selected. This does not happen with the VC++ IntelliSense.
Unfortunately I cannot upload the project due to size limitation on the forum. The zipped project folder is 11MB. I created a new nRF52832 project with the S132 softdevice, and used the LED Blink example. The only setting I changed from default was to select the Advanced Clang Intellisense.
I changed the project setting to use the Clang-format (under VisualGDB Project Properties->IntelliSense Settings->Code formatting settings), and the issue went away. I set it back to Default (legacy), and the issue came back.
I reset all my settings in Visual Studio to C++, and the issue remained.
I also renamed the registry key, rebooted, and the issue remained.
I recently got a new computer, and this issue shows up on both systems. Both are running Windows 10, but the new computer is using VS 2019. The old computer is using VS 2017
