Faster Modem Programming with J-Link and pynrfjprog

[jbax92]

Hey All,

I am working on optimizing a manufacturing script for a product that uses the nRF9160, this script is written in python and uses the pynrfjprog library to interface with a jlink connected to the 9160 over SWD. The production station that this script runs on is the bottle neck in our production line, and we only have a limited number of fixtures that can perform this function.

After conducting an analysis of how long each step in the programming / m-test process took, it looks like modem firmware update is the standout by an order of magnitude. This step takes approximately 35 seconds to complete, where as each other step takes between 5 -10 seconds. There are a total of 10 steps, and I have parallelized the modem firmware step as much as I can, but everything else has to happen sequentially.

I have determined that the only way I can speed up this any further is to speed up the modem firmware update process itself. I have this function running in a separate thread from the main script to program modem firmware.

from pynrfjprog import HighLevel

def program_modem(jlink_snr: int, modem_fw_path: str):

    """Programs modem with specified firmware using provided J-Link snr.

    Args:

        jlink_snr (int): Serial number of the J-Link that will program the modem. (Located on the bottom of the J-Link)

        modem_fw_path (str): Absolute path to the modem firmware zip file.

    """

    with HighLevel.API() as api:

        with HighLevel.IPCDFUProbe(

            api, jlink_snr, HighLevel.CoProcessor.CP_MODEM, clock_speed=14000

        ) as probe:

            probe.program(

                modem_fw_path,

                HighLevel.ProgramOptions(verify=HighLevel.VerifyAction.VERIFY_HASH),

            )

The documentation for the DLLs claims that if the given clock speed is above the maximum allowable for the device, then it will default to the maximum. This has proven untrue, and instead spits out a DLL error (RC = -102) it seems that 14000 is the highest multiple of 1000 allowable.

A request I would have is to update the documentation to match behavior or visa versa.

But a question would be to ask if anyone has found a faster way to program the modems. Be it calling the DLL's directly, or some other method I haven't thought of.

Setup:

Computer is BeeLink U55 Running Linux Mint Cinnamon

J-Link is Base Compact

Thanks for the help!

[Albrecht Markus Schellenberger]

Hello Jordan,

The documentation for the DLLs claims that if the given clock speed is above the maximum allowable for the device, then it will default to the maximum. This has proven untrue, and instead spits out a DLL error (RC = -102) it seems that 14000 is the highest multiple of 1000 allowable.

A request I would have is to update the documentation to match behavior or visa versa.

Where in the documentation is that mentioned? Can you point me to it?

But a question would be to ask if anyone has found a faster way to program the modems. Be it calling the DLL's directly, or some other method I haven't thought of.

What is the size of the application images you are flashing? Please note that the modem firmware image size is >2 MB for mfw 1.3.x.

Regards,

Markus

[jbax92]

Hey Marcus,

It looks like I was reading the wrong function brief when I saw the maximum speed quote, the brief is for the following function.

nrfjprogdll_err_t NRFJPROG_connect_to_emu_with_snr_inst(nrfjprog_inst_t instance,

                                                        uint32_t serial_number,

                                                        uint32_t clock_speed_in_khz);

so I think that one is not needed.

The application firmware image is 742KB. We are using modem firmware version 1.2.3  which is 3 MB.