Running or Debugging in VSC

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.

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.

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”

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

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?

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)

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!

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"