Running or Debugging in VSC

SSteveD0 · Nov 11, 2020

When I first opened a command prompt and ran both jlink.exe and jlinkgdbservercl.exe they were not recognized so I added to path to those executable to the path variable in the environmental variables.
Now when I run jlink.exe it finds it:
SEGGER J-Link Commander V6.86f (Compiled Oct 23 2020 18:01:48)
DLL version V6.86f, compiled Oct 23 2020 18:00:13 ……
Now when I run Jlinkgdbservercl.exe it finds it tells me the device is unspecified….

I decided to go back to the VCS debugger since the new Jlink path was added. The debugger launched however it stopped with some problems:
#include errors detected based on information provided by the configurationProvider setting. Squiggles are disabled for this translation unit (C:\ncs\zephyr\samples\basic\blinky\src\main.c).C/C++(1696)
cannot open source file “nrfx.h” (dependency of “zephyr.h”)C/C++(1696)

The debug console shows:
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:\ncs\zephyr\samples\basic\blinky/build/zephyr/zephyr.elf…
0×00001784 in ?? ()
Not implemented stop reason (assuming exception): undefined
Resetting target
Resetting target

The output shows:
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×00001784 (Data = 0xFE2AF002)
Read 2 bytes @ address 0×00001784 (Data = 0xF002)
Received monitor command: halt
Halting target CPU…
…Target halted (PC = 0×00001784)
Received monitor command: reset
Resetting target
Downloading 572 bytes @ address 0×0000C000
Downloading 15270 bytes @ address 0×0000C23C
Downloading 8 bytes @ address 0×0000FDE4
Downloading 80 bytes @ address 0×0000FDEC
Downloading 520 bytes @ address 0×0000FE3C
Downloading 500 bytes @ address 0×00010050
Downloading 36 bytes @ address 0×00010244
Downloading 64 bytes @ address 0×00010268
Downloading 20 bytes @ address 0×000102A8
Writing register (PC = 0x cf4c)
Received monitor command: reset
Resetting target
Read 4 bytes @ address 0×0000CF4C (Data = 0xFA36F002)
Read 2 bytes @ address 0×0000CF4C (Data = 0xF002)
Read 2 bytes @ address 0×0000CF4E (Data = 0xFA36)
Reading 64 bytes @ address 0×0000C500
Read 4 bytes @ address 0×0000C5A0 (Data = 0×00010088)
Read 2 bytes @ address 0×0000C570 (Data = 0xF084)
Reading register (MSP = 0×20000C30)
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)

Not sure what I should be doing now?

SSteveD0 · Nov 11, 2020

Here is the line of code that is bombing our:

#if defined(CONFIG_PLATFORM_SPECIFIC_INIT)
bl z_platform_init
#endif
And the folder is nfed>zephyr>arch>arm>core>aarch32>cortex_m> asm reset.S
_

SSteveD0 · Nov 11, 2020

Update from last post….
Started all over. Erased memory. Wrote bootloader. Recompiled blinky. Changed prj.conf , did a west build and west flash. Both successful. Squiggly lines are gone. The Debugger stopped in the same place and there are 3 of the same warnings: if(NOT (${OPTIMIZATION_FLAG} IN_LIST CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE_uppercase}))
message(WARNING "
The CMake build type was set to ‘${CMAKE_BUILD_TYPE}’, but the optimization flag was set to ‘${OPTIMIZATION_FLAG}’.
This may be intentional and the warning can be turned off by setting the CMake variable ‘NO_BUILD_TYPE_WARNING’"
)
endif()

The OUTPUT after reading the registers now has:
…
Reading register (d14 = 0x 0)
Reading register (d15 = 0x 0)
Setting breakpoint @ address 0×0001C77C, Size = 2, BPHandle = 0×0001
Performing single step…
…Target halted (Vector catch, PC = 0×000052E2)
Reading all registers
Read 4 bytes @ address 0×000052E2 (Data = 0xF7FDB508)
Read 2 bytes @ address 0×000052E2 (Data = 0xB508)
Read 4 bytes @ address 0×00002148 (Data = 0xF3802020)
Read 2 bytes @ address 0×00002148 (Data = 0×2020)
Read 2 bytes @ address 0×00002148 (Data = 0×2020)
Setting breakpoint @ address 0×00002148, Size = 2, BPHandle = 0×0002
Starting target CPU…
…Breakpoint reached @ address 0×00002148
Reading all registers
Read 4 bytes @ address 0×00002148 (Data = 0xF3802020)
Read 2 bytes @ address 0×00002148 (Data = 0×2020)
Removing breakpoint @ address 0×00002148, Size = 2
Read 4 bytes @ address 0×00002E1A (Data = 0×4B24BD08)
Read 2 bytes @ address 0×00002E1A (Data = 0xBD08)
Read 2 bytes @ address 0×00002E1A (Data = 0xBD08)
Setting breakpoint @ address 0×00002E1A, Size = 2, BPHandle = 0×0003
Starting target CPU…

Stopped and started again. Same issues except the output only got up through reading registers like the first time.

SSteveD0 · Nov 11, 2020

In the launch.json there may have been incompatibilities between linux / windows with folder nomenclature:

I changed the / to executable": "${workspaceRoot}\build\zephyr\zephyr.elf which looks okay in the error message but
still can’t find the .elf - the error is:
Reading symbols from C:\nfed\nrf9160-feather\samples\blinky\build\zephyr\zephyr.elf…
0×00002144 in ?? ()
Not implemented stop reason (assuming exception): undefined

Shouldn’t all the folder dividers be the other way? Just guessing at the issue.

SSteveD0 · Nov 11, 2020

I had changed it to the double bars. Without the quote it saw it as single bars in the last email. “executable”: “${workspaceRoot}\build\zephyr\zephyr.elf”

SSteveD0 · Nov 11, 2020

Whether I use single or double forward or backward slashed between folders I get the same messages.

SSteveD0 · Nov 12, 2020

I went back and changed the IntellisenseMode parameter to msvc-x64.

The actual zephyr.elf file is in this windows 10 directory: C:\nfed\nrf9160-feather\samples\blinky\build\zephyr and the Toolchain executable applications are in the directory: C:\Program Files (x86)\GNU Tools Arm Embedded\9 2019-q4-major\bin. To set this up in VSC with slashes in the correct direction I have to use the double slash, but then the debugger doesn’t know how to find the files - see debug console below.
From the 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”
}

This is the debug console message I get:
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…
0×00002144 in ?? ()
Not implemented stop reason (assuming exception): undefined
Resetting target
Resetting target

When I use the single slash the other way I get the mixed slash directory and the files are still not found. It seems to me as part of VSC is working like Windows 10 and the other part is working like linux/mac.

The VCS marketplace is suggesting extensions that help with the .s file. There was a whole list to choose from so I don’t know what I’m looking for nor which extension might fix the issue?

jaredwolff · Nov 12, 2020

SteveD0 do you have the bootloader disabled during this process? The debugger doesn’t work when the bootloader is enabled.

SSteveD0 · Nov 12, 2020

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=y

jaredwolff · Nov 12, 2020

Cool. 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?

SSteveD0 · Nov 12, 2020

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.

SSteveD0 · Nov 12, 2020

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)

jaredwolff · Nov 13, 2020

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.

SSteveD0 · Nov 13, 2020

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 target

Here 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?

SSteveD0 · Nov 13, 2020

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!

jaredwolff · Nov 13, 2020

SteveD0 woohoo! It’s a little tricky to get going at first but once you have it you’re golden!

jaredwolff · Nov 13, 2020

SteveD0 what did your final launch.json look like?

SSteveD0 · Nov 13, 2020

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!

SSteveD0 · Nov 13, 2020

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"

jaredwolff · Nov 15, 2020

SteveD0 Cool. Great for other folks that need to know.