Question about path to hex file when using nrfjprog utility

RE: Question about path to hex file when using nrfjprog utility

tesc — Wed, 10 Feb 2021 11:52:19 GMT

Hi,

[quote user="Gudni"]I can only guess the Windows version of nrfjprog is not designed to handle something like /mnt/c/[/quote]

Correct. The Windows version of nrjprog expects paths to work as they normally do on Windows.

Note that when running the command from a WSL terminal, the first path (to nrfjprog.exe, the executable) is interpreted by the shell. The path sent as argument, however, is interpreted by nrfjprog.exe.

We have this now in our internal issue tracker, but it is a bit unclear how it should be handled and what is the expected behaviour for this kind of program invocation. Mixing native Windows command line tools with GNU/Linux tools is an area where conventions, assumptions, etc. quickly can become very messy...

Maybe not intuitive at first glance, but the more I think about it, passing "Windows style" paths to a Windows command line application does sound reasonable, maybe even totally expected, even if invoked from a WSL command line.

Regards,
Terje

RE: Question about path to hex file when using nrfjprog utility

Gudni — Wed, 10 Feb 2021 11:06:33 GMT

tesc

I am sorry for the delay.

No worries friend, I'm in no hurry and am just here to learn and have fun. 🤓

What version of nrfjprog is this? Have you tried with the latest version?

I am using the newest version of nrfjprog (10.12.1) 64-bit Windows version. You can see the version number in the top of the log.log file. This is why I needed to add the ".exe" to the command call, but I've seen people use something called a Linux Symbolic Link to make the system recognise only nrfjprog instead of nrfjprog.exe, but I haven't learned to use that just yet.

I am basically still a beginner when it comes to WSL2... and it seems to me WSL2 doesn't support USB though I'm not 100% sure but that is what my quick Google searches seem to show :)

Have you tried the Linux version of nRF Command Line Tools, when you run it from WSL?

I've tried and installed nrfjprog directly inside my WSL /opt/ directory and had difficulties using J-link to flash, it's not connecting to the debugger. It seems I must use the Windows version of nrfjprog to use Windows version of J-link. Then the debugger connects as normal.

After spending more time on this.... this worked:

nrfjprog.exe --family NRF52 --log --program C:/NordicSemiconductor/nRF5SDK/nRF5_SDK_17.0.2_d674dde/components/softdevice/s132/hex/s132_nrf52_7.2.0_softdevice.hex --snr 682436173

added a C:/ before the hex file path instead of /mnt/c/ I can only guess the Windows version of nrfjprog is not designed to handle something like /mnt/c/

RE: Question about path to hex file when using nrfjprog utility

tesc — Tue, 09 Feb 2021 14:43:13 GMT

Hi,

I am sorry for the delay.

It looks like the difference then is whether you use a relative or an absolute path. I suspect that this may be an issue with using Windows Subsystem for Linux in combination with the Windows version of nrfjprog (.exe). Have you tried the Linux version of nRF Command Line Tools, when you run it from WSL?

Also what version of nrfjprog is this? Have you tried with the latest version?

Regards,
Terje

RE: Question about path to hex file when using nrfjprog utility

Gudni — Thu, 04 Feb 2021 14:57:40 GMT

Here it is:

I have tried:

1. Removing space from file path. It does not resolve the issue

2. Moved the .hex file to the top directory on my machine. "/mnt/c/hexfile.hex". It does not resolve the issue.

3. Executing the nrfjprog command directly in the terminal. It does not resolve the issue so I doubt if this issue can be traced back to my CMake setup.

When I look at the log.log below and compare it to a log where the command works I see the first discrepancy is this line: [debug] [ nRF0x0] - is_bprot_enabled does not appear for the failing command and instead I see [debug] [ nRF0x0] - close_dll

devzone.nordicsemi.com/.../1614.log.log

RE: Question about path to hex file when using nrfjprog utility

tesc — Thu, 04 Feb 2021 13:03:42 GMT

Hi,

Something is obviously wrong, and although you have found a workaround it is not fully clear what and where the issue lies. It can be nrfjprog or it can be the system, and it can be the path length, or the space in the file name, or the use of absolute path, or something else.

Can you run the (failing) nrfjprog command with the --log flag added, and provide the resulting log.log file?

Regards,
Terje