Nordic NRF52840 Compilation Oddities (C & C++ Projects)

[grindstaffp]

I am working on a project using the Nordic NRF52840 and BSP 15.2 (modified a little to add the Thread and Zigbee SDK) and have run into an issue that I believe has something to do with the compiled output. I have opened a support case with Nordic here but thought I might also open a case here as after testing the same code in both Segger Embedded Studio and VisualGDB I am left with a working result produced by SES and an almost but not quite working result from VisualGDB.

Originally I had a C++ based embedded project created with VisualGDB that successfully joins a Zigbee network. I later added functionality to cause the NRF to sleep when possible and this is where issues began to surface. In order to remove any potential issues introduced by using C++ with the Zigbee library I created a new C embedded project for further testing. This project is a replica of a Nordic provided example with the Zigbee SDK which runs without issue when compiled with SES.

The issues I am running across are:

1. Compiled firmware under VisualGDB causes the device to seemingly hang upon connecting and handling the “ZB_COMMON_SIGNAL_CAN_SLEEP” event. This event does not seem to be called at all prior to a network connection. Debugging continues as if the device is still responding however no further output is logged to the console and a device reset is necessary.
   1. The SES output firmware continually handles the “ZB_COMMON_SIGNAL_CAN_SLEEP” event before and after the device joins a Zigbee network.
2. If I select “Compile as: Plain C” in the project properties then build the project I get the following errors, which the compiler does not warn about when using C++ and SES does not have a problem either.
   1. Severity Code Description Project File Line Suppression State
      Error stray ‘\’ in program EmbeddedProject3 H:\Development\Tools\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\15.2\15.2\nRF5x\modules\nrfx\mdk\gcc_startup_nrf52840.S 363
      Error stray ‘\’ in program EmbeddedProject3 H:\Development\Tools\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\15.2\15.2\nRF5x\modules\nrfx\mdk\gcc_startup_nrf52840.S 362
      Error stray ‘#’ in program EmbeddedProject3 H:\Development\Tools\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\15.2\15.2\nRF5x\modules\nrfx\mdk\gcc_startup_nrf52840.S 237
      Error expected identifier or ‘(‘ before ‘.’ token EmbeddedProject3 H:\Development\Tools\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.nordic.nrf5x\15.2\15.2\nRF5x\modules\nrfx\mdk\gcc_startup_nrf52840.S 23
3. If I leave “Compile as:” in its default, unselected state and compile, I am able to build the project however the same behavior seen in point 1 and in my other project using C++ is seen.

I know I am straying a little out of the bounds of the supported Nordic BSP but I am leaning towards this being more of a toolchain issue than it is a SDK issue. My VisualGDB based project can be found here and the Nordic light switch example can be found here if you would like them for reference.

Thanks for your help.

[support]

Hi,

Unfortunately the specific connectivity issues you described are indeed beyond the bounds of the regular VisualGDB support, however we can explain what is going on from the VisualGDB’s point of view and suggest some ideas to diagnose it:

• The “stray ‘\'” error happens because VisualGDB tries to compile an assembly file (.S) as Plain C file (following your settings). You can fix this by resetting the “compile as” setting for the .S files (either to default or specifically to preprocessed assembler). The per-file settings will override the per-project setting.
• Normally, you don’t need the “Compile as” option at all, unless you specifically want a file with the .cpp extension to be compiled as a plain C file (in that case, simply changing its extension to .c would have the same effect and a much lower chance of causing confusion in the future).
• As long as you are using C++ without exceptions/RTTI, it should not affect the behavior of other code in the project.

If we understood you correctly, you currently have a project that works and a project that reliably fails (both don’t have any C++ files). We would advise trying to understand the differences between the 2 projects and eliminating them one-by-one, doing a check at each step. Most likely, the difference comes from a slightly different preprocessor macro, different linker script, or even a different order of inputs (unlikely, but sometimes happens).

You can find the command lines used by VisualGDB in the .rsp files inside <project directory>\VisualGDB\Debug. Running arm-eabi-gcc @<path to the rsp file> will result in GCC executing the command line stored in the .rsp file. Please try running those command lines manually (via a bat file) and confirm that the 2 project outputs still behave differently. Then try combining the linker command line from 1 projects with the object files produced by another project. This will show whether the problem happens during linking or compilation. If the problem is due to compilation settings, try pinpointing a specific file by replacing half the files at a time. Once you get to a specific command line, you can repeat the same approach (eliminate half the differences at a time) to quickly identify the exact command line argument that triggers the problem.

Hope this helps. Let us know if you need more details and we will be happy to help.

 

[grindstaffp]

Hello,

You understand correctly. I have two projects, one provided by Nordic that works when compiled in SES (and now tested using GCC via command line) and one that I have put together in VGDB that uses the exact same code from the Nordic example that compiles but does not function the same.

I have spent the day making the following changes in an attempt to get things working:

1. Compared compiler and linker settings between SES and VGDB. Any compiler and linker flags found in SES were added to the VGDB project settings. –> Project compiles as before. Program runs but hangs.
2. Went through the VGDB project and pruned all unnecessary source files that had been included by VGDB. I did not expect this to help much but worth a try.
3. Nordic example project has a Makefile that I used to further test different compiler and linker flags in VGDB. –> Project compiles as before. Program runs but hangs.
4. Compiled Nordic example with aforementioned Makefile. Program functions as expected.
5. Copied Makefile into VGDB project directory and made minor modifications to Makefile for file paths. –> Program compiles fine, hangs during runtime.
   1. Renamed project EmbeddedProject3.c to main.c and recompiled (from command line). Same result as above.
   2. Makefile can be seen here.

I find it very strange that using the Makefile from the Nordic example on the VGDB files has the same result as compiling directly from within Visual Studio. I did not add or subtract anything from the SRC_FILES or INC_FOLDERS sections. I simply updated the SDK, PROJ_DIR, and LINKER_SCRIPT paths. According to the output, there were no problems during compilation or linking.

I attempted to use the .rsp files as mentioned in your response however amr-eabi-gcc did not particularly care for the “EmbeddedProject3.link.rsp” that I gave it.

arm-eabi-gcc .\EmbeddedProject3.link.rsp
h:/development/tools/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe:.\EmbeddedProject3.link.rsp: file format not recognized; treating as linker script
h:/development/tools/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/7.2.0/../../../../arm-eabi/bin/ld.exe:.\EmbeddedProject3.link.rsp:1: syntax error
collect2.exe: error: ld returned 1 exit status

I also copied the contents of the .rsp file to the console and was met with a wall of errors of files not being found and unrecognized flags. I spent a while going down this path and eventually gave up and I was unsuccessful at ever getting anything but errors.

<hr />

During the writing of this post I modified the SDK_ROOT path in the aforementioned Makefile to point to the untouched Nordic SDK and recompiled. Now the program is working as expected. Following this revelation, I have compared the Nordic Thread/Zigbee SDK folder with the VisualGDB BSP and moved a few more folders over. Unfortunately whatever I am missing was not fixed by simply adding a few more files to the BSP directory. I have updated the project on github and added the Makefile used that resulted in a successful compile. Is there any way someone can take a look and help me find the missing piece? I feel like I am getting close but I am missing the last piece of the puzzle.

Thanks for the support.

[grindstaffp]

Don’t see an edit button here but I’d like to clarify that prior to changing the SDK_ROOT path to the Nordic sdk I had that path set to the 15.2 BSP directory.

Adding the Nordic SDK directory as an additional path in the project properties did not appear to have any positive effect when building the project.

[support]

Thanks for the detailed update. Looks like you forgot the ‘@’ symbol before the path to the response file. I.e.

arm-eabi-gcc @.\EmbeddedProject3.link.rsp

instead of:

arm-eabi-gcc .\EmbeddedProject3.link.rsp

Without the ‘@’ symbol, gcc will try to treat the .rsp file as a regular C/C++ source, leading to weird errors. Also normally, you would want to run it from the project directory (some paths in the .rsp file can be relative to it), so the command line will most likely look like this:

arm-eabi-gcc @VisualGDB\Debug\EmbeddedProject3.link.rsp

It could be also something as subtle as a bug in a specific softdevice version, so please ensure that both projects use exactly the same SDK sources/headers (i.e. physically the same files) and the same softdevice binary.

[grindstaffp]

Thank you for the clarification, I will give that a try later today. I had included the “@” but got errors when running in powershell. I’ll use a standard command prompt for further testing.

My next step after that is probably going to be to replace the files within the BSP with those from the SDK rather than trying to pick and choose just what I needed out of the Zigbee SDK. I am not using a softdevice so that should simplify things but I did notice that the rsp file includes a softdevice directory. Must just be something extra that was included as I have the project set to not include a softdevice.

[support]

The ‘@’ syntax definitely works from the regular command prompt. We use it all the time when running pre-release tests on new BSPs and creating custom project templates via our consulting track, so it usually takes less than 10 iterations to find the root cause even for massive projects with very complex settings.

[grindstaffp]

Good to know. I think Powershell handles the @ differently and I was being too lazy to move to a command prompt.

There must be some subtle differences in some of files that I didn’t copy that allow me to still compile but cause problems during runtime. If my total copy of the nordic sdk files into the BSP does not resolve my issue I will continue down the path of manually running the command as you have suggested.

[grindstaffp]

Updating to say that whatever issue I was encountering has been resolved by copying the entire nordic thread and zigbee sdk into the BSP directory. Thank you for providing insight and suggestions on how I might pinpoint a solution.

[support]

No problem. BTW, feel free to let us know if you pinpoint a specific file (e.g. a linker script) that is causing the issue. As long as it doesn’t break backward compatibility with existing projects, we can easily update our BSP so that you won’t need to replace any files manually.

[Author]

Posts