Thingy91: pynrfjprog deadlocks at 100% cpu usage

[Triffid_Hunter]

I'm using the script from https://devzone.nordicsemi.com/f/nordic-q-a/53208/updating-nrf9160-modem-firmware-through-the-command-line/215357#215357

Under strace, it never forks any other process and doesn't create the file it's looking for, so I'm really not sure what it's expecting to happen.

Full strace at http://triffid-hunter.no-ip.info/pynrf-flash.strace since this forum thing keeps throwing errors when I try to attach it.

https://devzone.nordicsemi.com/f/nordic-q-a/62397/nrfjprog-bug-gets-stuck-due-to-temporary-directory-permissions seems related however my permissions are fine, and the directory tree in /tmp is recreated identically if I wipe it first.

Since this is apparently the only way to update the NRF91 modem firmware from a terminal, and all the examples seem to be complaining about out-of-date modem firmware, I'm once again stuck.

[Triffid_Hunter]

I made /opt/SEGGER/JLink a symlink to my JLink_V680a folder, and NRF Connect programmer is rather happier about it (I'm not even sure how it was finding the older version before, it never asked me where to look), but pynrfjprog doesn't seem to have improved.

I've tried with both a regular JLink (possibly a knockoff) as well as an official Nordic NRF9160-DK delivered by your FAE today.

I'm using Gentoo because it's the only distribution I've tried that doesn't fight me when I tell it what I want.

It certainly does seem like your software needs improvements in its error handling, a simple "The JLink library at <path> is too old, please update" or "The JLink library can't be found in <searchpath>" would have saved a ton of drama - with the specific path and the issue with them presented in this manner, it would take but a moment to drop a symlink there.

PS: why aren't you using environ[LD_LIBRARY_PATH] for this? It exists specifically for this exact purpose, and I already have my JLink library path listed in there so nrfjprog can find it.

[Triffid_Hunter]

I reinstalled pynrfjprog and it seems to be working now.

It seems like my problems were caused by your software totally ignoring LD_LIBRARY_PATH and instead trying to silently use a hard-coded path outside my home dir, coupled with a complete lack of usable error checking and reporting.

Now I'm finding that the modem won't talk to anything but I'll make a separate post about that.

[Håkon Alseth]

Hi,

 

I have to apologize for the bumpy ride wrt. running our tools in Linux. We are continuously trying to improve, and you have very good feedback for us. It is highly appreciated!

Triffid_Hunter said:

It certainly does seem like your software needs improvements in its error handling, a simple "The JLink library at <path> is too old, please update" or "The JLink library can't be found in <searchpath>" would have saved a ton of drama - with the specific path and the issue with them presented in this manner, it would take but a moment to drop a symlink there.

Yes, it is unfortunately restrictions in the current built binary, which I will bring up with the team as improvements in the future. 

 

Triffid_Hunter said:

PS: why aren't you using environ[LD_LIBRARY_PATH] for this? It exists specifically for this exact purpose, and I already have my JLink library path listed in there so nrfjprog can find it.

 I'll also discuss this with them.

 

Triffid_Hunter said:

but pynrfjprog doesn't seem to have improved.

Is the strace equal as before? ie. loads of "stat("/tmp/nrfjprogdll/highlevel/file12YHdh", 0x7ffd8bf8a230) = -1 ENOENT (No such file or directory)" ?

The file<rand> is a copy of the local /path/to/JLink/libjlinkarm.so, as shown here:

hkn /tmp/nrfjprogdll/highlevel 
$ file /opt/SEGGER/JLink/libjlinkarm.so.6.80.1 
/opt/SEGGER/JLink/libjlinkarm.so.6.80.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=329721bc307868771dcf0d4ee24af5790fc4b16d, stripped

hkn /tmp/nrfjprogdll/highlevel 
$ file filezT91qO
filezT91qO: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=329721bc307868771dcf0d4ee24af5790fc4b16d, stripped

If that is still not created, I suspect that pynrfjprog still isn't able to successfully find the segger installation.

As a quick workaround, can you try to copy the libjlinkarm.so to the tmp/nrfjprogdll/highlevel/file<rand-prefx> and see how it behaves?

I see we have a race-condition in updating the thread, as re-installing pynrfjprog seems to have helped on this scenario. 

Kind regards,

Håkon