What are the raw JLink.exe commands sent by nrfjprog.exe?

[cirlam]

My devices require calibration and self test to be carried out after programming. To implement this, my device checks the JLink reset pin (configured as a GPIO on my NRF52 device) if it has been pulled low on startup - if it has, it performs calibration and self test.

In order to automate this process, I have implemented a script which takes the JLink reset pin high (using Jlink.exe command), performs a chip recovery by NRFJPROG, programs the chip by NRFJPROG, takes reset pin low (using JLink.exe) and then finally power cycles the board with a Python script written to interface with the Nordic PPK (at which point it performs self test and calibration).

Currently the calls to Jlink.exe, followed by nrfjprog and Jlink.exe result in establishing a new jlink connection with each call. This slows the script down. As I'd like to use this script in production, this script needs to be as fast as possible.

I was hoping to combine all the JLink commands (namely those in the nrfjprog program) into a single JLink script, so I only need to establish one connection to this JLink.

Is there a way to find out what jlink.exe commands are being sent by the nrfjprog.exe? I am particulary interested in the recover and programming commands.

[cirlam]

Bumping this, as a while back a Nordic engineer was assigned, but haven't received a response yet.

[Håkon Alseth]

Hi,

 

I see one improvement, as you are focusing on speed. The "FLASH DEVICE HERE" sequence does not need to write directly to the NVMC peripheral. You can just call "loadfile <myhex>".

This should also verify the content, as shown here when I load a test.hex file:

J-Link>loadfile c:\test_s140.hex
Downloading file [c:\test_s140.hex]...
J-Link: Flash download: Bank 0 @ 0x00000000: 1 range affected (208896 bytes)
J-Link: Flash download: Total time needed: 3.058s (Prepare: 0.058s, Compare: 0.023s, Erase: 0.000s, Program: 2.960s, Verify: 0.005s, Restore: 0.010s)

 

Kind regards,

Håkon

[cirlam]

Thank you for the advice Håkon! Will implement your recommendation.

So the rest of the script, including using delays instead of polling the ready register, should be ok? Is this how the nrfjprog.exe script works?

[Håkon Alseth]

nrfjprog interfaces the jlink.dll directly, so that works in a bit of a different way.

JLink Commander is limited in terms of scripting, as you mention; you cannot continuously poll a register to wait for an operation to be finished, which makes it hard for you to optimize your delays.

 

Best regards,

Håkon