Resolving nRF9160 Zephyr app build error "offsets.c.obj not found"

[tedhavelka]

Hello Devzone Community,

I am trying to incorporate Nordic's version of Segger Embedded Studio, SES v5.60 in Zephyr based firmware development for the nRF9160.  I've cloned a small project "[email protected]:tedhavelka/kionix-driver-demo.git", which depends upon Nordic sdf-nrf v1.6.1.  At the command line using `west` I am able to build and to flash this project to a sparkfun_thing_plus_nrf9160 board.

In SES I am able to create a "Segger Solution" from this freshly cloned Zephyr application.  I do so by navigating from the top bar menu "File > Open nRF Connect SDK Project...".  The dialog for opening Connect SDK Projects makes it simple to locate and open nRF SDK sample projects.  It also has a standard file and directory navigation button [...] which allows a user to select an arbitrary project, one that's anywhere on a locally mounted file system.

When I open this project that's not a sample of the SDK, Segger works for ten to fifteen seconds creating among other things a couple of .emProject files in a newly created build directory.  In fact it creates all of the following files, before I start a build of the project:

ted@localhost:~/projects/zephyr-based/z4/00-driver-demo-copy-3/build_sparkfun_thing_plus_nrf9160$ ls -l
total 2380
-rw-rw-r-- 1 ted ted 170407 Sep 24 14:43 00-driver-demo-copy-3.emProject
-rw-rw-r-- 1 ted ted 1598 Sep 24 16:11 00-driver-demo-copy-3.emSession
drwxrwxr-x 2 ted ted 4096 Sep 24 14:43 app
-rw-rw-r-- 1 ted ted 1049076 Sep 24 14:43 build.emProject
-rw-rw-r-- 1 ted ted 1142169 Sep 24 14:43 build.ninja
-rw-rw-r-- 1 ted ted 23932 Sep 24 14:43 CMakeCache.txt
drwxrwxr-x 5 ted ted 4096 Sep 24 14:43 CMakeFiles
-rw-rw-r-- 1 ted ted 1914 Sep 24 14:43 cmake_install.cmake
drwxrwxr-x 2 ted ted 4096 Sep 24 14:43 Kconfig
drwxrwxr-x 32 ted ted 4096 Sep 24 14:43 modules
drwxrwxr-x 3 ted ted 4096 Sep 24 14:43 Output
drwxrwxr-x 14 ted ted 4096 Sep 24 14:43 zephyr
-rw-rw-r-- 1 ted ted 4797 Sep 24 14:43 zephyr_modules.txt
-rw-rw-r-- 1 ted ted 308 Sep 24 14:43 zephyr_settings.txt

When I attempt to build this project however, I keep blocking on the error of a file named 'offsets.c.obj' not found.  Here is the tail end of a couple hundred lines of build messages:

1> Checking 'zephyr/include/generated/kobj-types-enum.h'
1> 'zephyr/include/generated/kobj-types-enum.h' is up to date
Building 'zephyr/include/generated/otype-to-str.h' from solution 'build' in configuration 'Common'
Building 'zephyr/CMakeFiles/kobj_types_h_target' from solution 'build' in configuration 'Common'
Building 'zephyr/include/generated/otype-to-size.h' from solution 'build' in configuration 'Common'
Building 'zephyr/kobj_types_h_target' from solution 'build' in configuration 'Common'
Building 'zephyr/include/generated/syscall_list.h' from solution 'build' in configuration 'Common'
1> Checking 'zephyr/include/generated/syscall_list.h'
1> 'zephyr/include/generated/syscall_dispatch.c' is up to date
Building 'zephyr/CMakeFiles/syscall_list_h_target' from solution 'build' in configuration 'Common'
Building 'zephyr/include/generated/syscall_dispatch.c' from solution 'build' in configuration 'Common'
Building 'zephyr/syscall_list_h_target' from solution 'build' in configuration 'Common'
Building 'cmake_object_order_depends_target_offsets' from solution 'build' in configuration 'Common'
Building 'zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj' from solution 'build' in configuration 'Common'
2> Checking 'offsets.c'
2> zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj does not exist.
2> Compiling 'offsets.c'
2> /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/arm-none-eabi-gcc -DAPP_VERSION=v1.6.1 -DBUILD_VERSION=v2.6.0-rc1-ncs1 -DEXT_API_MAGIC=0x281ee6de,0xb845acea,23298 -DFIRMWARE_INFO_MAGIC=0x281ee6de,0x8fcebb4c,23298 -DKERNEL -DNRF9160_XXAA -DNRF_TRUSTZONE_NONSECURE -DUSE_PARTITION_MANAGER=1 -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/kernel/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/arch/arm/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include -I/home/ted/projects/zephyr-based/z10/hardware-Stage1-firmware-aws-iot-stand-alone/build_thingy91_nrf9160ns/zephyr/include/generated -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/soc/arm/nordic_nrf/nrf91 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/lib/libc/newlib/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/subsys/net/lib/sockets/. -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/lib/at_notif/. -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/lib/at_cmd_parser/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/subsys/net/lib/aws_fota/./include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-drivers/drivers -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-drivers/drivers/kionix/kx132-1211 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/lib/cjson -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/modules/cjson/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/cmsis/CMSIS/Core/Include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx/drivers/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx/mdk -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/modules/hal_nordic/nrfx/. -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrfxlib/nrf_modem/include -I/home/ted/projects/zephyr-based/z10/hardware-Stage1-firmware-aws-iot-stand-alone/src -Os -imacros /home/ted/projects/zephyr-based/z10/hardware-Stage1-firmware-aws-iot-stand-alone/build_thingy91_nrf9160ns/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -imacros /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/ted/projects/zephyr-based/z10/hardware-Stage1-firmware-aws-iot-stand-alone=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/ted/projects/zephyr-based/z4-sandbox-kionix-work=WEST_TOPDIR -ffunction-sections -fdata-sections -specs=nano.specs -std=c99 -MD -MF /home/ted/projects/zephyr-based/z10/hardware-Stage1-firmware-aws-iot-stand-alone/build_thingy91_nrf9160ns/zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj.d -fno-diagnostics-show-caret -o zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj -c /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/arch/arm/core/offsets/offsets.c
Build failed

When I build this project using `west` at the command line, the build succeeds.  When I build an nRF sample app out of the SDK v1.6.1, that build succeeds.  When I attempt to build a project which depends on the same Nordic nrfconnect repository, I get caught at this error on file offsets.c.obj not found.

There was another post on this specific error, but that post is dated cerca 2018, and the release of Zephyr has moved forward a few releases since then.  Is this a known bug in any use cases of Nordic SDK v1.6.1?  Or in use of Zephyr 2.6.x?

If not a known bug, what would be one or a couple of sensible starting steps to take in order to debug this issue?

Frustrating also given that offsets.c contains only a couple of #includes and a symbol definition:

File ${HOME}/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/arch/arm/core/offsets/offsets.c:

1 /*
2 * Copyright (c) 2019 Carlo Caione <[email protected]>
3 *
4 * SPDX-License-Identifier: Apache-2.0
5 */
6
7 #include <gen_offset.h>
8
9 #include "offsets_aarch32.c"
10
11 GEN_ABS_SYM_END

- Ted

[tedhavelka]

2021-09-26 - Sunday update to this post regarding "2> zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj does not exist."

In further experimentation I find that this build error is actually occurring in every nRF sample Zephyr based app from nrf SDK version 1.6.1.  This error is reproducible, when opening Segger SES 5.60, and selecting "File > Open nRF SDK Connect Project...".

The one Devzone ticket I could find involving this error is from 2018.  The circumstances described in that ticket don't appear to closely match my situation, but per that post I have tried switching released version of nrf SDK.  When pointing Segger to nrf SDK 1.5.1 the project fails to create due to an error encountered by a called Python script `create_nordic_project.py`.  There's no specific fault or error message given.  I reach the same project creation failure when trying nrf SDK 1.7.0 and 1.7.0-rc2:

I am able to locate the script `create_nordic_project.py` among the content of my recently installed Segger IDE:

ted@localhost:/opt/ses-nordic/arm_segger_embedded_studio_v560_linux_x64_nordic/html$ ls -l *.py
-rw-rw-r-- 1 10006 10006 11398 Aug 11 16:14 configure_nordic_project_menuconfig.py
-rw-rw-r-- 1 10006 10006 20907 Aug 11 16:14 create_nordic_project.py

But I don't know much about Python scripting, and reading through this script there does not appear to be a supported '--verbose' type option.  Is there a configuration in Segger to obtain more verbose error messaging back from this nRF project creation script?

Given that no nRF sample compile from the nrf SDK 1.6.1, and given that other releases of the SDK don't even allow Segger to create a new project from them, is my best bet to purge the two instances of the SDK I've downloaded, and purge Segger, and reinstall Nordic's SDK and then Nordic version Segger?

Seriously blocked on this toolchain issue.

- Ted

[Simon]

We just added support for NCS development in vscode, nRF Connect for Visual Studio Code. Which is an extension that you can install from vscode. Check out the blog nRF Connect for VS Code.

If you prefer to use SES instead, please tell me and I will set it up on Ubuntu on my machine and look into your issue.

Best regards,

Simon

[tedhavelka]

Hello Simon,

If VSCode offers the same or comparable debugging features as are found in Segger Embedded Studio, Nordic Version, then I can work with VSCode.  Right now I prefer Segger as I'm more familiar with the debugging utilities there.

It will be very helpful to me to resolve this Segger project build issue.  Feels like things are very close to working.  "Project open" occurs without warning or error per Segger, but something is different for `cmake` when Segger calls it to build the project, versus when `west` calls cmake on the command line.

Granted, Segger creates the build directory `build_sparkfun_thing_plus_nrf9160` or similar per targeted dev board, and there's a newly created project CMakeLists.txt file in there.  So technically Segger is buidling a different project, though desired code and dependencies are supposed to be the same as those called by `west`.

What further information need you from me to configure SES, and import my Zephyr project mentioned above?  I followed Nordic's toolchain installation steps, and SDK installation for the nrf SDK version 1.6.1.  Those are the top level code bodies I am working with.

- Ted

[tedhavelka]

Good morning Simon,

Regarding my post on "offsets.c.obj does not exist" build error, I have found a solution though not a detailed explanation.  Please do not take any new time looking into this matter.

On a careful review of my toolchain settings I found that I had Segger calling `crosstool-NG 10.2.0` instead of the latest stable GNU ARM cross-compiler, available at [GNU ARM downloads page](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads).

Here is a tabular summary of compilers and build success/failure project conditions:

                                           command line and `west`     Segger Nordic v5.60
arm-zephyr-eabi-gcc (crosstool-NG) 10.2.0           yes                         no
arm-none-eabi-gcc (GNU Arm) 10.3.1                  yes                        yes


I apologize for the mistake and for wasting your time.  I still suspect that the root cause may be in the manner that
 `create_nordic_project.py` captures project settings upon first opening an nRF Connect SDK application.  This so because
 both compilers succeed in building working projects when called via `west` at the command line.

Is it possible for a normal community member like myself to mark one of my own posts "resolved"?  Or must your team do so?

-Ted

[Simon]

I'm happy you found a solution and thanks for sharing it. I've marked your last reply as 'resolved'.