Yes. Here is my prj.conf:
CONFIG_GPIO=y
# Enable Zephyr application to be booted by MCUboot
CONFIG_BOOTLOADER_MCUBOOT=n
# Enable modem trace
#CONFIG_BSD_LIBRARY_TRACE_ENABLED=y
# AT host library
#CONFIG_UART_INTERRUPT_DRIVEN=y
#CONFIG_AT_HOST_LIBRARY=y
CONFIG_DEBUG=yCool. Can you describe how you’re loading the firmware to your nRF9160 Feather?
Have you placed a breakpoint in your code when you do start running your debug session?
Does your bottom bar go orange when you start debugging?
What shows up in the Output tab on the the bottom of the screen?
Yes. With the nrf9160 plugged into one usb port and the nrf5340 plugged into the other usb port I just went through the process again for you. Since I want to start clean I went into the nrf desktop connect programmer selected the nrf5340 device which was on 3 ports and pressed the read menu item. I then selected erase all. From there I went up to the Add Hex File menu item and loaded the feather bootloader. Then I did a Write and a Read to make sure the bootloader was on the nrf9160 and made sure the nrf9160 could go into DFU mode and back out. Once that was done I wanted to get a working version of blinky running so I unplugged both the nrf5340 nrf9160 usb ports. I replugged the nrf9160 into the usb port. Opened up VSC and then opened up the blinky folder. At that point I set the CONFIG_DEBUG=n and the CONFIG_BOOTLOADER_MCUBOOT=y.
I then opened up the terminal and entered the following:
west build -b circuitdojo_feather_nrf9160ns -p
And got: Generating zephyr/merged_domains.hex at the end
newtmgr conn add serial type=serial connstring=“dev=COM20,baud=1000000”
And got: Connection profile serial successfully added
Then entered DFU mode and ran: newtmgr -c serial image upload build/zephyr/app_update.bin
Once blinky was loaded I pressed reset on the nrf9160 and it started blinking.
Then I plugged the nrf5340 again (making sure the J-Link was connected securely)
Went back to the prj.conf and changed the CONFIG_DEBUG=y and the CONFIG_BOOTLOADER_MCUBOOT=n.
Saved those settings. The launch.json and the c_cpp_properties.json were already there so I didn’t need to add them.
I then did a west build and go:[131/131] Generating zephyr/merged.hex
And then a west flash and got: – runners.nrfjprog: Board with serial number 960147438 flashed successfully.
Went into main.c and set a break point with a red dot at the line of code led_is_on = !led_is_on; in the while loop.
Clicked on the debug icon and saw the Cortex Debug at the top. Closed the existing terminal and re-opened a new one.
Then I pressed the Start Debugging and the got the error mentioned before. The debugger stopped at the line of code: bl z_platform_init
in:
SECTION_SUBSEC_FUNC(TEXT,_reset_section,__start)
#if defined(CONFIG_PLATFORM_SPECIFIC_INIT)
bl z_platform_init
#endif
And that is where I am.
Here is the output tab:
SEGGER J-Link GDB Server V6.86f Command Line Version
JLinkARM.dll V6.86f (DLL compiled Oct 23 2020 18:00:13)
Command line: -if swd -port 50000 -swoport 50001 -telnetport 50002 -device nrf9160_xxAA
—–GDB Server start settings—–
GDBInit file: none
GDB Server Listening port: 50000
SWO raw output listening port: 50001
Terminal I/O port: 50002
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
——J-Link related settings——
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
——Target related settings——
Target device: nrf9160_xxAA
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link…
J-Link is connected.
Firmware: J-Link OB-K22-NordicSemi compiled Jan 21 2020 17:33:01
Hardware: V1.00
S/N: 960147438
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
Checking target voltage…
Target voltage: 3.30 V
Listening on TCP/IP port 50000
Connecting to target…
Connected to target
Waiting for GDB connection…Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0×00002D60 (Data = 0xF8C64001)
Read 2 bytes @ address 0×00002D60 (Data = 0×4001)
Received monitor command: halt
Halting target CPU…
…Target halted (PC = 0×00002D60)
Received monitor command: reset
Resetting target
Downloading 572 bytes @ address 0×0000C000
Downloading 13234 bytes @ address 0×0000C23C
Downloading 8 bytes @ address 0×0000F5F0
Downloading 80 bytes @ address 0×0000F5F8
Downloading 520 bytes @ address 0×0000F648
Downloading 448 bytes @ address 0×0000F850
Downloading 36 bytes @ address 0×0000FA10
Downloading 64 bytes @ address 0×0000FA34
Downloading 20 bytes @ address 0×0000FA74
Writing register (PC = 0x cbc4)
Received monitor command: reset
Resetting target
Read 4 bytes @ address 0×0000CBC4 (Data = 0xF83EF002)
Read 2 bytes @ address 0×0000CBC4 (Data = 0xF002)
Read 2 bytes @ address 0×0000CBC6 (Data = 0xF83E)
Reading 64 bytes @ address 0×0000C500
Read 4 bytes @ address 0×0000C5A0 (Data = 0×0000F888)
Read 2 bytes @ address 0×0000C540 (Data = 0xB368)
Read 4 bytes @ address 0×0000C5A0 (Data = 0×0000F888)
Read 2 bytes @ address 0×0000C570 (Data = 0xF084)
Reading register (MSP = 0×20000040)
Reading register (PSP = 0x 0)
Reading register (PRIMASK = 0x 0)
Reading register (BASEPRI = 0x 0)
Reading register (FAULTMASK = 0x 0)
Reading register (CONTROL = 0x 0)
Reading register (FPSCR = 0x 0)
Reading register (s0 = 0x 0)
Reading register (s1 = 0x 0)
Reading register (s2 = 0x 0)
Reading register (s3 = 0x 0)
Reading register (s4 = 0x 0)
Reading register (s5 = 0x 0)
Reading register (s6 = 0x 0)
Reading register (s7 = 0x 0)
Reading register (s8 = 0x 0)
Reading register (s9 = 0x 0)
Reading register (s10 = 0x 0)
Reading register (s11 = 0x 0)
Reading register (s12 = 0x 0)
Reading register (s13 = 0x 0)
Reading register (s14 = 0x 0)
Reading register (s15 = 0x 0)
Reading register (s16 = 0x 0)
Reading register (s17 = 0x 0)
Reading register (s18 = 0x 0)
Reading register (s19 = 0x 0)
Reading register (s20 = 0x 0)
Reading register (s21 = 0x 0)
Reading register (s22 = 0x 0)
Reading register (s23 = 0x 0)
Reading register (s24 = 0x 0)
Reading register (s25 = 0x 0)
Reading register (s26 = 0x 0)
Reading register (s27 = 0x 0)
Reading register (s28 = 0x 0)
Reading register (s29 = 0x 0)
Reading register (s30 = 0x 0)
Reading register (s31 = 0x 0)
Reading register (d0 = 0x 0)
Reading register (d1 = 0x 0)
Reading register (d2 = 0x 0)
Reading register (d3 = 0x 0)
Reading register (d4 = 0x 0)
Reading register (d5 = 0x 0)
Reading register (d6 = 0x 0)
Reading register (d7 = 0x 0)
Reading register (d8 = 0x 0)
Reading register (d9 = 0x 0)
Reading register (d10 = 0x 0)
Reading register (d11 = 0x 0)
Reading register (d12 = 0x 0)
Reading register (d13 = 0x 0)
Reading register (d14 = 0x 0)
Reading register (d15 = 0x 0)
SteveD0 newtmgr conn add serial type=serial connstring=“dev=COM20,baud=1000000”
You only have to do this once.
SteveD0 Then I pressed the Start Debugging and the got the error mentioned before. The debugger stopped at the line of code: bl z_platform_init
in:
SECTION_SUBSEC_FUNC(TEXT,_reset_section,__start)#if defined(CONFIG_PLATFORM_SPECIFIC_INIT)
bl z_platform_init
#endif
And that is where I am.
Sometimes it’s best to do a nrfjprog -e before debugging and then flash your application after it’s been erased. Also sometimes the debugger doesn’t start correctly the first time. Hit the stop button and then start it up again.
Hopefully that should fix it.
I tried that and it didn’t work. Went back to the “intelliSenseMode”: “gcc-arm” setting from using “msvc-x64” and it didn’t seem to make a difference.
Getting the same Debug Console information:
Please check OUTPUT tab (Adapter Output) for output from JLinkGDBServerCL.exe
Launching server: "JLinkGDBServerCL.exe" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "nrf9160_xxAA"
Launching GDB: "C:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin\arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2"
undefinedC:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
Reading symbols from C:\nfed\nrf9160-feather\samples\blinky\build\zephyr\zephyr.elf...
0xfffffffe in ?? ()
Not implemented stop reason (assuming exception): undefined
Resetting target
Resetting targetHere is what I’m using in my launch.json:
{
"name": "Cortex Debug",
"cwd": "${workspaceRoot}",
"executable": "${workspaceRoot}\\build\\zephyr\\zephyr.elf",
"request": "launch",
"type": "cortex-debug",
"servertype": "jlink",
"device": "nrf9160_xxAA",
"interface": "swd",
"armToolchainPath": "C:\\Program Files (x86)\\GNU Tools Arm Embedded\\9 2019-q4-major\\bin"
}Did that Debug Console look right to you?
Just got it working!!!!! Something about the way or timing of when I hit the the stop before starting up again. I’ll have to play around with it a bit. Thank you!
SteveD0 woohoo! It’s a little tricky to get going at first but once you have it you’re golden! 
SteveD0 what did your final launch.json look like?
Here is what the launch.json looked like:
{
“name”: “Cortex Debug”,
“cwd”: “${workspaceRoot}”,
“executable”: “${workspaceRoot}\build\zephyr\zephyr.elf”,
“request”: “launch”,
“type”: “cortex-debug”,
“servertype”: “jlink”,
“device”: “nrf9160_xxAA”,
“interface”: “swd”,
“armToolchainPath”: “C:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin”
}
And in the c_cpp_properties.json I used this parameter (although this may not have been needed):
“intelliSenseMode”: “gcc-arm”,
Thanks again for all the help!
the launch.json posted incorrectly. I used double slashes. The curly brackets caused the double slash to turn to a single slash.
"name": "Cortex Debug",
"cwd": "${workspaceRoot}",
"executable": "${workspaceRoot}\\build\\zephyr\\zephyr.elf",
"request": "launch",
"type": "cortex-debug",
"servertype": "jlink",
"device": "nrf9160_xxAA",
"interface": "swd",
"armToolchainPath": "C:\\Program Files (x86)\\GNU Tools Arm Embedded\\9 2019-q4-major\\bin" SteveD0 Cool. Great for other folks that need to know.