Determining required jlink version for nrf connect vscode extension

RE: Determining required jlink version for nrf connect vscode extension

Priyanka — Mon, 02 Oct 2023 08:23:58 GMT

Hi Nathan,

I am yet to hear back from the team and will keep you updated.

Regards,

Priyanka

RE: Determining required jlink version for nrf connect vscode extension

Nathan — Wed, 27 Sep 2023 18:50:44 GMT

Priyanka,

Ok, after some delay I've figured out that the reason my board wasn't starting up is because when trying to debug the issue by moving to the low frequency RC internal clock I was setting "CONFIG_SOC_ENABLE_LFXO=n" and "CONFIG_SOC_LFXO_CAP_EXTERNAL=n" in prj.conf, but didn't realize I also had to set "CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y" and "CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n" to make the new configuration work. But I think this will probably only work until I try to call bt_enable(), because I'm not sure whether the setting is also being applied to the network core or not. I found some old tickets on the forums describing setting these in the hci_rpmsg subimage on NCS 2.0.0 but I don't see that folder in my project, has this changed for 2.4.X? It's still weird that my project worked before the tools updated but at this point I think that's a moot point because I clearly had issues in my project settings that needed to be addressed.

So I guess the real question is how do I properly set the project up for rail to rail external oscillator for LFCLK input in the project settings, for both main application and network core, assuming that the oscillator will have to be started by the firmware at runtime? I clearly messed that up before, and would appreciate guidance on how to do it correctly.

Regards, Nathan

RE: Determining required jlink version for nrf connect vscode extension

Priyanka — Wed, 20 Sep 2023 12:24:21 GMT

Hi Nathan,

Thanks for the update and apologies for the delay. I have reported the findings too t the internal team and am awaiting a response. I will get back to you as soon as I hear from them.

Regards,

Priyanka

RE: Determining required jlink version for nrf connect vscode extension

Nathan — Mon, 18 Sep 2023 20:06:23 GMT

Ok, the plot thickens. I've confirmed that the segger debugger I'm using is OK because I hooked it up to the debug-in port of the nrf53 development kit, set the development kit to nRF only mode, and that board runs to the start of main as expected. So there's only a problem when I try to debug on my custom board.

My custom board uses the same rail voltage as the development kit (3.3V), and it seems to erase/program/verify just fine, but it just won't run to the start of main like the development kit does. I've also confirmed it has the exact same processor type loaded (production rev1 silicon) and that it's being powered sufficiently. Side note, the latest version of nRF Connect Programmer misreports the chip as Engineering D silicon, I manually checked the chip markings to confirm it really is rev1 silicon.

The only other possibility I've been able to think of so far is if something in the workspace no longer likes my low frequency clock setup. Unlike the devkit, I'm using a rail to rail oscillator for my 32K LFCLK input (which I turn on at runtime). I set it up like that because this board has an external backup calendar chip with a 32,768 oscillator output, so it saves cost and board space for me not to use an external crystal but instead hook up P0.00 to the external oscillator that's already available (and leave P0.01 disconnected per the datasheet). But I suppose it's possible that after updating my workspace, zephyr is no longer happy with my configuration settings regarding the LFCLK source and is getting stuck before it reaches the main function of my app.

I tried turning off the LFXO in the kconfig settings but that didn't help, so what should I put into my prj.conf file to make certain that the low frequency clock source is fully switched over to internal RC temporarily for testing? And it it doesn't turn out to be the crystal, what other hardware difference could possibly cause this kind of behavior, considering that erase/flash/verify does still work?

RE: Determining required jlink version for nrf connect vscode extension

Nathan — Mon, 18 Sep 2023 15:47:27 GMT

Priyanka,

I've done some more testing and determined that the everything works if I'm running and debugging on an nRF devkit, but using a segger j-link base compact debugger with my custom board is not working anymore. Which is weird because you'd think that if I can get as far as erasing and programming the chip successfully, then it would hit the breakpoint at the start of main normally. I'll do some more testing and if I can't figure it out, I'll at least be able get you much more specific information about what specifically triggers the issue.

Nathan

Edit: Here's the debug console output when I run the debugger on the devkit for the exact same program, which does reach the breakpoint at the start of main:

JLinkGDBServerCL: SEGGER J-Link GDB Server V7.80c Command Line Version
JLinkGDBServerCL:
JLinkGDBServerCL: JLinkARM.dll V7.80c (DLL compiled Sep 27 2022 16:06:20)
JLinkGDBServerCL:
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file: none
JLinkGDBServerCL: GDB Server Listening port: 54069
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port: 2333
JLinkGDBServerCL: Accept remote connection: localhost only
JLinkGDBServerCL: Generate logfile: off
JLinkGDBServerCL: Verify download: off
JLinkGDBServerCL: Init regs on start: off
JLinkGDBServerCL: Silent mode: on
JLinkGDBServerCL: Single run mode: on
JLinkGDBServerCL: Target connection timeout: 0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface: USB
JLinkGDBServerCL: J-Link script: none
JLinkGDBServerCL: J-Link settings file: none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device: nRF5340_xxAA_APP
JLinkGDBServerCL: Target device parameters: none
JLinkGDBServerCL: Target interface: SWD
JLinkGDBServerCL: Target interface speed: 12000kHz
JLinkGDBServerCL: Target endian: little
JLinkGDBServerCL:
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
0x0001b4f4 in _skip_0 () at D:/Jobs/*redacted*/zephyr/arch/arm/core/aarch32\cpu_idle.S:129
129 _sleep_if_allowed wfi
[New Thread 536915128]
[New Thread 536912832]
[New Thread 536913064]
[New Thread 536915528]
[New Thread 536914864]
[New Thread 536909784]
[New Thread 536910784]
[New Thread 536909984]
[New Thread 536910184]
[New Thread 536910584]
[New Thread 536910384]
[New Thread 536911240]
[New Thread 536911040]
[New Thread 536911440]
[New Thread 536915328]
[Switching to Thread 536915328]

Thread 16 hit Breakpoint 1, main () at ../src/main.c:556
556 {
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)

RE: Determining required jlink version for nrf connect vscode extension

Priyanka — Fri, 15 Sep 2023 12:17:19 GMT

Hi Nathan,

I will check this internally with the team and get back to you.

Regards,

Priyanka

RE: Determining required jlink version for nrf connect vscode extension

Nathan — Wed, 13 Sep 2023 12:20:33 GMT

My nRF Connect for Desktop version is 4.2.0, latest applet versions associated. J-link version is the one that got installed with that update to Connect for Desktop, V7.80c. The nrf connect extension for VS Code is the September release, 2023.9.169. I have version 2.4.0 of the SDK still installed alongside 2.4.1, both of which were installed using a previous version of the nRF Connect for Desktop using the toolchain manager there.

The "program" is the executable that is produced by my project, which is flashed and runs on the nRF53. Before my IDE, j-link and nrf connect applications were updated I would tell the extension to run the debugger, and it would flash the board and stop at the breakpoint at the start of main. Then I would be able to debug normally from there. But now after my software has updated I'm not hitting the breakpoint at the start of main anymore. Specifically I get this in the debug console:

JLinkGDBServerCL: SEGGER J-Link GDB Server V7.80c Command Line Version
JLinkGDBServerCL:
JLinkGDBServerCL: JLinkARM.dll V7.80c (DLL compiled Sep 27 2022 16:06:20)
JLinkGDBServerCL:
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file: none
JLinkGDBServerCL: GDB Server Listening port: 50204
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port: 2333
JLinkGDBServerCL: Accept remote connection: localhost only
JLinkGDBServerCL: Generate logfile: off
JLinkGDBServerCL: Verify download: off
JLinkGDBServerCL: Init regs on start: off
JLinkGDBServerCL: Silent mode: on
JLinkGDBServerCL: Single run mode: on
JLinkGDBServerCL: Target connection timeout: 0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface: USB
JLinkGDBServerCL: J-Link script: none
JLinkGDBServerCL: J-Link settings file: none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device: nRF5340_xxAA_APP
JLinkGDBServerCL: Target device parameters: none
JLinkGDBServerCL: Target interface: SWD
JLinkGDBServerCL: Target interface speed: 12000kHz
JLinkGDBServerCL: Target endian: little
JLinkGDBServerCL:
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
0x000196e4 in _skip_1 () at D:/Jobs/*redacted*/zephyr/arch/arm/core/aarch32\cpu_idle.S:186
186 _sleep_if_allowed wfe
[New Remote target]

RE: Determining required jlink version for nrf connect vscode extension

Priyanka — Wed, 13 Sep 2023 11:51:08 GMT

HI Nathan,

Could you provide me with the following details:

1. nRF Connect for Desktop version

2. Do you have any other SDK versions also installed?

3. What is your j-link version now?

[quote user=""]Specifically the program just seems to jump to the "sleep if able" function block before reaching main. [/quote]

Which program are you mentioning here abut Is it your 5340 project that is mentioned here?

Best Regards,

Priyanka