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?

[Ø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. 

[Øyvind]

Hello gterrell , please open a new ticket for your issue. 

Kind regards,
Øyvind

[gterrell]

This is now resolved. I recreated the board files for our device and now debugging works.