nRF9160 VSCode examples don't run properly

[Collin Moore]

I am having a problem with all of my projects compiled with VSCode NCS 2.2.0:

I understand that one of the COM ports (I'm on Windows) should send output. When I flash the Asset Tracker sample to my Thingy:91, it works fine. There is terminal output, and I can send AT commands and see responses.

However, when I follow the instructions to import the AT_Client sample in VSCode, build for the thingy91_nRF9160_ns, and flash, there is no terminal output in LTE Link Monitor on any terminal. If I Debug, the debugger never gets to main(). If I pause it, it is usually here:

Does anyone know why this would happen? I have tried putting breakpoints in main(), but they are never hit.

I am debugging a Thingy91 with a SEGGER J-link Plus probe. The hello_world worked once, last week, before re-flashing with demo samples, and now no VSCode projects work properly.

I have erased with J-flash lite, nRF Connect Programmer, and VSCode, to no avail. There are no error messages in the build or debug session.

I can flash the .hex samples and they work fine.

The debugger runs and is running. It does not break at main(). If I click Pause, it is usually here:

It may be getting stuck in some sort of bootloader image validation. Sometimes if I pause, it is in checks in a function called main that is not my main:

This happens whether or not I have Debug Options checked in the build.

Any ideas?

[Øyvind]

Hello, 

Due to Christmas Holidays our team is lower staffed than normal and some delays in our answers must be expected.  We apologize for the inconvenience. 

---

However, when I follow the instructions to import the AT_Client sample in VSCode, build for the thingy91_nRF9160_ns, and flash, there is no terminal output in LTE Link Monitor on any terminal

What instructions are you referring to? Can you please provide me a link.

When I flash the Asset Tracker sample to my Thingy:91, it works fine. There is terminal output, and I can send AT commands and see responses.

Is this the precompiled filed or flashed from VS Code? Have you ensured that "SWD Select" is set to nRF91? If set to nRF52, have you tried to reprogram the connectivity brigde? This worked for me.

Kind regards,
Øyvind

[Collin Moore]

Instructions I am referring to are the standard instructions to build and flash with VSCode.

An example, I am trying to run this lesson exercise:

https://academy.nordicsemi.com/topic/lesson-2-exercise-1/

Which links to the instructions:

https://nrfconnect.github.io/vscode-nrf-connect/get_started/build_app_ncs.html

https://nrfconnect.github.io/vscode-nrf-connect/get_started/quick_debug.html

Those are the instructions I am following to build and flash, and the only instructions I am aware of.

The pre-compiled examples all work fine. I flash those with Connect for Desktop Programmer app, or J-flash lite, and they work great.

When I flash the nRF9160 from VSCode with compiled examples, I get to the debug output above, but nothing on the serial ports.

The Serial ports are still there, so the nRF52 Connectivity Bridge is fine, and yes, my switch is on nRF91.

Could you please find out what could cause the nrf91 code to not run to main, but the pre-comipled examples to work?

[Collin Moore]

Sorry, what I posted, with the beginning and end fragments, was from VSCode.

I forgot to post the command prompt build output, here is that:

I ran west clean, rmdir /s /q build, rmdir /s /q build_300534, then west build -b thingy91_nrf9160_ns -d build_300534 again:

C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>rmdir /s /q build

C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>rmdir /s /q build_300534

C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>west clean
usage: west [-h] [-z ZEPHYR_BASE] [-v] [-V] <command> ...
west: error: argument <command>: invalid choice: 'clean' (choose from 'init', 'update', 'list', 'manifest', 'diff', 'status', 'forall', 'help', 'config', 'topdir', 'selfupdate', 'ncs-loot', 'ncs-compare', 'ncs-upmerger', 'ncs-sbom', 'completion', 'boards', 'build', 'sign', 'flash', 'debug', 'debugserver', 'attach', 'zephyr-export', 'spdx', 'blobs')

C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>west build -b thingy91_nrf9160_ns -d build_300534
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base).
-- Application: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client
-- Using NCS Toolchain 2.2.0 for building. (C:/ncs/toolchains/v2.2.0/cmake)
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.2.0/zephyr/.cache
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr)
-- Found west (found suitable version "0.14.0", minimum required is "0.7.1")
-- Board: thingy91_nrf9160_ns
-- Found host-tools: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/v2.2.0/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/ncs/v2.2.0/nrf/boards/arm/thingy91_nrf9160/thingy91_nrf9160_ns.dts
-- Generated zephyr.dts: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/zephyr/dts.cmake
Parsing C:/ncs/v2.2.0/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.2.0/nrf/boards/arm/thingy91_nrf9160/thingy91_nrf9160_ns_defconfig'
Merged configuration 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/prj.conf'
Configuration saved to 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/zephyr/.config'
Kconfig header saved to 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found version "3.8.2") found components: Interpreter
Changed board to secure thingy91_nrf9160 (NOT NS)

=== child image mcuboot -  begin ===
loading initial cache file C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/child_image_preload.cmake
Loading Zephyr default modules (Zephyr base).
-- Application: C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr
-- Using NCS Toolchain 2.2.0 for building. (C:/ncs/toolchains/v2.2.0/cmake)
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.2.0/zephyr/.cache
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr)
-- Found west (found suitable version "0.14.0", minimum required is "0.7.1")
-- Board: thingy91_nrf9160
-- Found host-tools: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found toolchain: zephyr 0.15.1 (C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk)
-- Found Dtc: C:/ncs/toolchains/v2.2.0/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found BOARD.dts: C:/ncs/v2.2.0/nrf/boards/arm/thingy91_nrf9160/thingy91_nrf9160.dts
-- Found devicetree overlay: C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/dts.overlay
-- Generated zephyr.dts: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/zephyr.dts
-- Generated devicetree_generated.h: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/dts.cmake
Parsing C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/Kconfig
Loaded configuration 'C:/ncs/v2.2.0/nrf/boards/arm/thingy91_nrf9160/thingy91_nrf9160_defconfig'
Merged configuration 'C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/prj.conf'
Merged configuration 'C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/boards/thingy91_nrf9160.conf'
Merged configuration 'C:/ncs/v2.2.0/nrf/modules/mcuboot/tfm.conf'
Merged configuration 'C:/ncs/v2.2.0/nrf/subsys/partition_manager/partition_manager_enabled.conf'
Merged configuration 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/misc/generated/extra_kconfig_options.conf'
Configuration saved to 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/.config'
Kconfig header saved to 'C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 12.1.0
-- The CXX compiler identification is GNU 12.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
MCUBoot bootloader key file: C:/ncs/v2.2.0/bootloader/mcuboot/root-rsa-2048.pem
-- Configuring done
-- Generating done
-- Build files have been written to: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/mcuboot
=== child image mcuboot -  end ===

CMake Warning at C:/ncs/v2.2.0/nrf/modules/mcuboot/CMakeLists.txt:286 (message):


          ---------------------------------------------------------
          --- WARNING: Using default MCUBoot key, it should not ---
          --- be used for production.                           ---
          ---------------------------------------------------------




CMake Warning at C:/ncs/v2.2.0/zephyr/CMakeLists.txt:1833 (message):
  __ASSERT() statements are globally ENABLED


-- Found partition manager static configuration: C:/ncs/v2.2.0/nrf/boards/arm/thingy91_nrf9160/thingy91_pm_static.yml
Partition 'mcuboot' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_pad' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_primary_app' is not included in the dynamic resolving since it is statically defined.
Partition 'mcuboot_secondary' is not included in the dynamic resolving since it is statically defined.
Partition 'nonsecure_storage' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm_secure' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm_nonsecure' is not included in the dynamic resolving since it is statically defined.
Partition 'tfm' is not included in the dynamic resolving since it is statically defined.
Dropping partition 'nrf_modem_lib_trace' since its size is 0.
-- Configuring done
-- Generating done
-- Build files have been written to: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534
-- west build: building application
[4/273] Generating include/generated/version.h
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr), build: v3.2.99-ncs1
[54/273] Performing build step for 'mcuboot_subimage'
[1/278] Generating include/generated/version.h
-- Zephyr version: 3.2.99 (C:/ncs/v2.2.0/zephyr), build: v3.2.99-ncs1
[268/278] Linking C executable zephyr\zephyr_pre0.elf

[272/278] Linking C executable zephyr\zephyr_pre1.elf

[278/278] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       40410 B        48 KB     82.21%
             RAM:       28024 B     211736 B     13.24%
        IDT_LIST:          0 GB         2 KB      0.00%
[61/273] Generating ../../tfm/CMakeCache.txt
-- The C compiler identification is GNU 12.1.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/ncs/toolchains/v2.2.0/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found version "3.8.2") found components: Interpreter
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.2.0/zephyr/.cache
-- Configuring done
-- Generating done
-- Build files have been written to: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/tfm
[67/273] Performing build step for 'tfm'
[1/2] Re-running CMake...
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found version "3.8.2") found components: Interpreter
-- Found Python3: C:/ncs/toolchains/v2.2.0/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Cache files will be written to: C:/ncs/v2.2.0/zephyr/.cache
-- Configuring done
-- Generating done
-- Build files have been written to: C:/ncs/v2.2.0/nrf/samples/nrf9160/at_client/build_300534/tfm
[171/171] Generating ../bin/tfm_s.bin
[72/273] Performing install step for 'tfm'
-- Install configuration: "MinSizeRel"
[254/273] Linking C executable zephyr\zephyr_pre0.elf

[258/273] Linking C executable zephyr\zephyr_pre1.elf

[264/273] Linking C executable zephyr\zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       68508 B     380416 B     18.01%
             RAM:       32848 B     211736 B     15.51%
        IDT_LIST:          0 GB         2 KB      0.00%
[268/273] Generating ../../zephyr/app_update.bin
sign the payload
[269/273] Generating ../../zephyr/app_signed.hex
sign the payload
[271/273] Generating ../../zephyr/app_test_update.hex
sign the payload
[273/273] Generating zephyr/merged.hex

C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>

I took my output, changed the text ncs/ to NordicSemi/, diffed the two, and they are exactly the same except these lines:

I then ran C:\ncs\v2.2.0\nrf\samples\nrf9160\at_client>west flash -d build_300534

I don't get any interaction from the thingy91 in LTE Link Monitor, so I don't think it's working.

When I flash the precompiled .hex at_client2, I get responses and it works great.

Attached is my verbose log when re-installing toolchain v2.2.0 (what I have been using this whole time).

2023-02-09T19_58_22.761Z-log.txt

[Collin Moore]

Any progress on this?

I am still unable to run any custom projects on either computer. I was hoping to be using the Modem library and sending SMS by now, but I'm stuck on toolchain stuff, even though I followed all the default instructions.

[Øyvind]

Sorry, I was trying to follow up internally and see if I could find a solution. What version of the Connectivity Bridge are you running on the Thingy:91? Did you try to update this with the version found in the latest precompiled package? 

[Collin Moore]

Yes, if I understand correctly, the bridge should connect the nrf91 UART to the 52840, then use the 52840 as a USB to UART adapter.

If I erase it, no examples work. I flashed "...\thingy91_fw_2022_12_08_188a1603\img_app_bl\thingy91_nrf52_connectivity_bridge_2022-12-08_188a1603.hex"

Then the pre-compiled AT client sample works, and I can send and receive AT commands.

My problem is in Debugging the nrf9160 MCU in VSCode. I can't get any project to get to main().

So I can flash the pre-compiled examples, and the bridge works fine, still just the debugging issue.

Is there any chance we could do a video call or something, so that you could see what is going on in my computer? I would have blamed my setup, except that I get the exact same results on a fresh install of Win10 on another laptop!

I have been developing on nRF52832 with those SDKs and GCC since 2016, and have never had this many issues. I understand that this is much more compilicated, with the Zephyr RTOS and the Crypto stuff, (which I don't yet know if it's on or off), but I just want to read pin states and send SMS, and I can't get the example project to compile and debug, or run.

I don't need any of the crypto/security stuff for my code. If there is anything I can turn off to make it work, please let me know!

[gterrell]

Collin did you find a solution?

I have nearly identical symptoms with a nRF9151 test, one target is a nRF9151 DK and the other is a custom board of our (LooUQ) design. Both work fine on a very simple hello world like application (no _ns option in the build target). Then they fail almost exactly as you describe, they never reach a main() breakpoint. RTT seems to be connected however no boot messages appear.

The failures happen after a variable number of attempts. Doesn't appear to be a hardware issue or application software as both work without the _ns target option.

The workaround... seems to work (but a big pain) is using a non _ns build target, get the protected warning and then recover the board, debug twice and it is working again.

Something in the _ns build is setting a register in silicon that is preventing proper operations (MY GUESS). While a work around exists, this is really nasty.