Forum Replies Created
-
Posts
-
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
This is only with C++ style comments (//). C style comments (/**/) at the end of a line do no exhibit the issue.
Unfortunately that does not work. I set the Build Results Window Stickiness to 0 and the build window still steals focus.
I selected a few functions in Dynamic Analysis -> Instrumented Functions that I know get called on every pass through main, but the Real-time watch window remains empty. I see the problem with both release and debug builds.
I partially figured out the issue. I needed to select “Instrument functions to record their time” in the “New Profiling Session”.
Now I have a new problem. I can’t profile the application with the bootloader in place. The bootloader calculates a CRC32 over the entire application image and compares it with a pre-calculated CRC32. The pre-calculated CRC is generated during the build process and is automatically flashed to the target hardware before the application runs.
It appears the profiler is changing the firmware after the build process, so the CRCs don’t match and the bootloader does not launch the application.
