NRFJPROG DLL: -11 CANNOT_CONNECT

[enjeru15]

Hi,

I'm currently diving into embedded programming and I'm working on creating a Python source code to establish a connection between J-Link and nRF5340. Specifically, I'm using the nRF5340-DK (PCA10095 2.0.2) for my project.

Initially, I expected connecting to be straightforward using the pynrfjprog package. I incorporated some of the LowLevel.py commands, but I encountered an issue: NRFJPROG DLL: -11 CANNOT_CONNECT.

Additionally, I experimented with the following functions to see their return:

• select_coprocessor(Parameters.CoProcessor.CP_APPLICATION) → None
• select_family(Parameters.DeviceFamily.NRF53) → None
• is_eraseprotect_enabled() → False
• enable_coprocessor(Parameters.CoProcessor.CP_APPLICATION) → None
• is_coprocessor_enabled(Parameters.CoProcessor.CP_APPLICATION) → True

Furthermore, I attempted to use erase_all() before the connect_to_device() function, but unfortunately, this didn't resolve the issue. Instead, a new error surfaced: "NRFJPROG DLL: -90 NOT_AVAILABLE_BECAUSE_PROTECTION." I also tried placing erase_uicr() before connect_to_device(), but this led to yet another error: "NRFJPROG DLL: -4 INVALID_DEVICE_FOR_OPERATION."

Here's a snippet of my code:

from pynrfjprog import LowLevel

from pynrfjprog import JLink

from pynrfjprog import Parameters

SNR = 1050028130

with LowLevel.API() as api:

        if SNR is not None:

            api.connect_to_emu_with_snr(SNR, 4000)

        else:

            api.connect_to_emu_without_snr()

        jlink_connected = api.is_connected_to_emu()

        print(f"Jlink connected: {jlink_connected}")

        select_coprocessor = api.select_coprocessor(Parameters.CoProcessor.CP_APPLICATION)

        print(f"Selected coprocessor: {select_coprocessor}")

        select_device_family = api.select_family(Parameters.DeviceFamily.NRF53)

        print(f"Device family: {select_device_family}")

       

    #    reg=api.read_cpu_register(0x00FF8000)

    #    print(f"Approtect: {reg}")

        erase_status = api.is_eraseprotect_enabled()

        print(f"Erase protect enabled: {erase_status}")

        cpu = api.read_cpu_architecture()

        print(f"CPU: {hex(cpu)}")

        enable_coprocessor = api.enable_coprocessor(Parameters.CoProcessor.CP_APPLICATION)

        print(f"Coprocessor: {enable_coprocessor}")

        coprocessor = api.is_coprocessor_enabled(Parameters.CoProcessor.CP_APPLICATION)

        print(f"Coprocessor is enabled: {coprocessor}")

    #    api.erase_all()

    #    api.erase_uicr()

        target_device_connect = api.connect_to_device()

        target_device_is_connected = api.is_connected_to_device()

        print(f"Target device connected: {target_device_is_connected}")

[Bendik Heiskel]

Hi,

When using erase all the board the access port protection will be enabled. To disable it you need to use recover(). This will erase and disable the protection, allowing you to connect to the device.

 

Best regards,

Bendik

[enjeru15]

Hi,

New error occurred after placing recover() before connect_to_device(): NRFJPROG DLL: -2 INVALID_OPERATION

Also, I'd like to know if I'm implementing the select_coprocessor() and enable_coprocessor() correctly. I'm just wondering why there are returning None. Does my code not selecting the coprocessor properly?

[Bendik Heiskel]

Hi,

connect_to_device() will return NRFJPROG DLL:-2 INVALID_OPERATION when either the debugger haven't been connected or when NRFJPROG_connect_to_device() already have been called.

https://github.com/NordicSemiconductor/pynrfjprog/blob/67e1a1eeaf77566214ea055aed4fd130401ae5a2/pynrfjprog/docs/nrfjprogdll.h#L821C1-L849C65

Erasing or recovering the device will connect to the device, so you should do a check if the device is connected before trying to connect to it using connect_to_device().

enjeru15 said:

Also, I'd like to know if I'm implementing the select_coprocessor() and enable_coprocessor() correctly. I'm just wondering why there are returning None. Does my code not selecting the coprocessor properly?

The methods for selecting and enabling the co processors does not return anything/returns None:

https://github.com/NordicSemiconductor/pynrfjprog/blob/67e1a1eeaf77566214ea055aed4fd130401ae5a2/pynrfjprog/LowLevel.py#L663
https://github.com/NordicSemiconductor/pynrfjprog/blob/67e1a1eeaf77566214ea055aed4fd130401ae5a2/pynrfjprog/LowLevel.py#L629

 

Best regards,

Bendik

[enjeru15]

Thank you, the recover() worked! I checked it using is_connected_to_device() to see if nRF5340 is already connected to JLink.

I have few more inquiries, though.

・Regarding the usage of enable_coprocessor() and select_coprocessor() after invoking recover() to establish the connection with the target device, would it be acceptable to follow this approach instead of directly calling connect_to_device() as outlined in LowLevel.py?

・In the event that the selection of the coprocessor needs to be determined by the user, would it be more logical to first call select_coprocessor() followed by enable_coprocessor(), or is it equally effective the other way around? I experimented with both sequences and didn't encounter any issues, but now I'm uncertain if I'm correctly selecting the coprocessor.

・If I want to select CP_NETWORK as my coprocessor, do I need to configure something first as stated here in nRF5340 Production Programming nAN42:

Before connecting to the network core, check if it is in Force-OFF mode and not held in
reset. To check if the network core is powered up, do an AHB read of AHB-AP 0 by targeting
RESET.NETWORK.FORCEOFF (0x50005614) in the application core. If the readout is 0, the
network core is not in Force-OFF mode. If the readout is 1, write 0 to it to exit Force-OFF mode.

Is there available API/command for this?

・If I intend to program my code using a custom hex file, could you guide me on the correct syntax for the 'file_path' parameter in the program_file() function? I'd prefer not to rely on, and am uncertain about how to use, the find_blinky_hex() and find_device_hex() functions.

[Bendik Heiskel]

Hi,

Apologies for not getting back to you sooner.

enjeru15 said:

・Regarding the usage of enable_coprocessor() and select_coprocessor() after invoking recover() to establish the connection with the target device, would it be acceptable to follow this approach instead of directly calling connect_to_device() as outlined in LowLevel.py?

This should be fine.
If you look in the program_hex.py example you can see that connect_to_device() isn't used at all.

enjeru15 said:

・In the event that the selection of the coprocessor needs to be determined by the user, would it be more logical to first call select_coprocessor() followed by enable_coprocessor(), or is it equally effective the other way around? I experimented with both sequences and didn't encounter any issues, but now I'm uncertain if I'm correctly selecting the coprocessor.

I have tested both ways and can't see any difference. You will get an error if you try to flash a network core file to the application core and vice versa, as the addresses will not be within the correct range. So if you aren't getting any errors it should be correct.

enjeru15 said:

・If I want to select CP_NETWORK as my coprocessor, do I need to configure something first as stated here in nRF5340 Production Programming nAN42:

Before connecting to the network core, check if it is in Force-OFF mode and not held in
reset. To check if the network core is powered up, do an AHB read of AHB-AP 0 by targeting
RESET.NETWORK.FORCEOFF (0x50005614) in the application core. If the readout is 0, the
network core is not in Force-OFF mode. If the readout is 1, write 0 to it to exit Force-OFF mode.

Is there available API/command for this?

This should be handled by select_coprocessor

enjeru15 said:

・If I intend to program my code using a custom hex file, could you guide me on the correct syntax for the 'file_path' parameter in the program_file() function? I'd prefer not to rely on, and am uncertain about how to use, the find_blinky_hex() and find_device_hex() functions.

file_path is just a string containing the path to the file, it can either be relative or absolute. I recommend using the os.path library to help with formatting the correct file path, this is especially help full if you intend the program to be usable on both Linux and Windows.

 

Best regards,

Bendik