search

Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
1.01k stars 238 forks source link

nRF5340 multicore debug #404

Closed christofferbrask closed 2 years ago

christofferbrask commented 3 years ago

I want to debug the network core but can't find enough information on how this is done.

Debugging the application core works but I'm only interested in debugging the network core.

The application core starts the network core before it suspends itself.

I don't find any way to specify two executables - one for the app core and another for the net core? I guess I also have to specify two jlink devices? nRF5340_xxAA_APP for the application core while nRF5340_xxAA_NET is used for the network core.

What about targetProcessor? Does 1 means secondary core = NETWORK core?

haneefdm commented 3 years ago

It is up to your chip vendor on how they configured the JTAG/SWD chain. It could be 0 or 1. But numberOfProcessors will be needed

  • You can now specify the numberOfProcessors and the targetProcessor to debug in launch.json when there are multiple cores/processors in the DAP chain. Cortex-Debug will allocate the required number of TCP ports and use the right one(s) for the processor. This has been tested with pyOCD and OpenOCD
christofferbrask commented 3 years ago

Thanks, it seems like targetProcessor = 0 is the app core.

Do you know what to do with the fields: device and executable? I have tried just to load the application image beforehand and then start a debug session with the network executable elf file and device: nRF5340_xxAA_APP but it doesn't allow me to hit run?

Marus commented 3 years ago

In general executable will be the path to the ELF formatted executable ( with debug symbols) that you are trying to debug.

If you use an “launch” request type the executable will be flashed to the target automatically at launch, while an “attach” request type assumes that executable is already flashed on the target device.

As for the device field, that should be the device identifier for J-Link - which from what I can see does appear to be either nRF5340_xxAA_APP or nRF5340_xxAA_NET as appropriate.

can you post the full configuration from your launch.json file that you are trying to use - might be able to see something that might indicate why you can’t try to run - although not sure how much I’ll be able to help as I don’t have any similar device to try against.

christofferbrask commented 3 years ago 

"configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "projects/bin/app.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "device": "nRF5340_xxAA_NET",
            "interface": "swd",
            "runToMain": true,
            "numberOfProcessors": 2,
            "targetProcessor": 0,
        }
    ]

Also tried with targetProcessor = 1. The executable is poiting to the elf for the network core which I would like to debug.

I'm able to start a debug session with attach to NET core if i flash both cores beforehand, but I would like the ability to start at main and restart the debug session.
haneefdm commented 3 years ago

JLink works a bit differently. For each core the vendor may have a unique name and numberOfProcessors and targetProcessor may not apply.

christofferbrask commented 3 years ago

I suspect the problem might be the following: Start debug session -> Reset device -> Debug session fails because app core has not yet started the net core. Are there any config which can be set to fix this?

haneefdm commented 3 years ago

Yes @christofferbrask , and there is more to that. One core may reset the other core once it itself is initialized and configured the other core. Vector tables can move, security issues, etc.

If your debug session works in Eclipse, you can see the commands being sent to gdb and you can duplicate those using the override*** entries in launch.json. This bypasses anything Cortex-Debug does for you automatically.

christofferbrask commented 3 years ago

Maybe you can help me with the override commands. I tried with a simple blinky example and was able to start a debug session on Visual Studio with help from VisualGDB.

C:\Program Files (x86)\SEGGER\JLink\JLinkGDBServerCL.exe -select USB -device nRF5340_XXAA_NET -speed auto -if SWD -port 63971 SEGGER J-Link GDB Server V6.94c Command Line Version

JLinkARM.dll V6.94c (DLL compiled Feb 5 2021 17:35:11)

Command line: -select USB -device nRF5340_XXAA_NET -speed auto -if SWD -port 63971 -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 63971 SWO raw output listening port: 2332 Terminal I/O port: 2333 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: nRF5340_XXAA_NET Target interface: SWD Target interface speed: auto Target endian: little

Connecting to J-Link... J-Link is connected. Firmware: J-Link OB-K22-NordicSemi compiled Feb 2 2021 16:48:58 Hardware: V1.00 S/N: 960114519 Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB Checking target voltage... Target voltage: 3.30 V Listening on TCP/IP port 63971 Connecting to target... Connected to target Waiting for GDB connection...Connected to 127.0.0.1 Reading all registers ...

GDB Session C:\Program Files (x86)\GNU Tools ARM Embedded\8 2019-q3-update\bin\arm-none-eabi-gdb.exe --interpreter mi "C:/Users/cgb/source/repos/BlinkNetCore/build/nrf5340dk_nrf5340_cpunet/Debug/zephyr/zephyr.elf"

Meanwhile with Cortex Debug plugin in VS code (Debug Console): Launching server: "JLinkGDBServerCL.exe" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "nRF5340_xxAA_NET" Launching GDB: "arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2"

(Output tab) SEGGER J-Link GDB Server V6.94c Command Line Version

JLinkARM.dll V6.94c (DLL compiled Feb 5 2021 17:35:11)

Command line: -if swd -port 50000 -swoport 50001 -telnetport 50002 -device nRF5340_xxAA_NET -----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: nRF5340_xxAA_NET 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 Feb 2 2021 16:48:58 Hardware: V1.00 S/N: 960114519 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

haneefdm commented 3 years ago

Did you make any progress? Sorry to get back to you so late.

What I see above is the output of the jlink gdb-server. What would help is the commands sent to gdb if you can get that from the setup you have working. What goes into the override*** is actually gdb commands. But if you can see the input to the gdb-server, we can work with that too...

trond-snekvik commented 3 years ago

I've been able to run parallel debugs for both nRF53 cores by setting up two separate debug sessions. JLink can use the device parameter to determine which core to connect to. If you first start a launch session for the application core (setting device to nRF5340_XXAA_APP), then a second attach session for the network core (setting device tonRF5340_XXAA_NET`), they'll be able to run in parallel, and both cores can be stepped through independently. VS Code has a "child session" concept in the debug API which could be used to do this automatically. I'm not sure what this would look like in launch.json though.

haneefdm commented 3 years ago

You may also be able to do it in a single VSCode instance. Worth a try if you have the time.

1) Have two launch configurations 2) Create a combined configuration. We do this with our debugging of the extension. The combined one looks like this https://github.com/Marus/cortex-debug/blob/6a262b544ca49baa728789da3225b11b368fa3be/.vscode/launch.json#L46 image

trond-snekvik commented 3 years ago

Sorry, my comment was a bit ambiguous. That's pretty much the way I did it as well. Single vscode instance, launching two debug sessions at the same time. I have some more stuff going on in the background, but the end result should be the same.

The only issue I had was the "unknown breakpoint" warning from the GDB server popping up whenever I added breakpoints in a file that only exists in one of the images. I'll make a PR to silence this when I pick this up again, it's information that's usually communicated through the breakpoint list anyway.

christofferbrask commented 3 years ago

I also run parallel debug sessions, but I still don’t think it is optimal not being able to launch the net core. Haven’t found a way to do that.

haneefdm commented 3 years ago

@christofferbrask Do you use two VSCode instances or one?

christofferbrask commented 3 years ago

One instance with both core settings in the debug json file. I have also tried combining them as your example code but it still not possible to launch net core as app core is responsible of starting net core.

torsdag den 29. juli 2021 skrev Haneef Mohammed @.***>:

@christofferbrask https://github.com/christofferbrask Do you use two VSCode instances or one?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/404#issuecomment-889305605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMN32QUXC75RXONZFN4OWLT2GBN5ANCNFSM4YMD4WXA .

haneefdm commented 3 years ago

@christofferbrask It would help me if you can attach your launch.json. Remove anything secret. Drag and drop it into the attachment area on github. Maybe I can help or maybe not.

christofferbrask commented 3 years ago

I’m on holiday, only with phone but it is almost the same as i attached earlier in our conversation. I try my best to have right syntax here.

"configurations": [ { "name": "App Debug", "cwd": "${workspaceRoot}", "executable": "projects/bin/app.elf", "request": "launch", "type": "cortex-debug", "servertype": "jlink", "device": "nRF5340_xxAA_APP", "interface": "swd", "runToMain": true, }, { "name": "Net Debug", "cwd": "${workspaceRoot}", "executable": "projects/bin/net.elf", "request": "attach", "type": "cortex-debug", "servertype": "jlink", "device": "nRF5340_xxAA_NET", "interface": "swd", "runToMain": false, } ]

haneefdm commented 3 years ago

@christofferbrask With a compound debug, I think what you were doing is right provided the two gdb-servers are not competing for access to the USB port.

One problem I see is that the NET program may be starting too soon before JLink has finished connecting/starting the NET core. It takes a few seconds. In the meantime, NET core is trying to attach. You could use a preLaunchTask to have a NET debug session delayed by a few seconds.

@trond-snekvik Perhaps you could share your bits of launch.json. I am working blind here.

haneefdm commented 2 years ago

See #529

I am closing this issue, as there is not much actionable here.