nrf5340 memory gets erased after readback in J-Flash

[vojtech265]

Target: nrf5340

debugger j-link base (or ultra+, same result)

SW: J-Flash, J-Flash Lite, versions tested v7.80, v7.86, .7.88 - same result

Hi,

I am having trouble with programming nrf5340. 

1. Manual programming with J-Flash Lite:

I flash the net core, then the app core. If I want to read out the data in the J-Flash I get the following message in log:

Any ideas why is this happening? I need to debug this first, because then I want to create the python script to automate the flashing. Thank you!

[Einar Thorsrud]

Hi,

The nRF5340 (as well as the latest revisions of most of the nRF52 series devices) have an improved access port protection mechanism, that blocks debugger access by default. Debugger access is only enabled after a full chip erase, or if the UICR contains a magic word and the CPU writes to a specific register to unlock the debug interface. See CTRL-AP - Control access port for details. This means that after programming and resetting, you will not be able to read back the content or use the debugger in other ways, unless the access port is unlocked. 

J-Flash Lite is a generic porgramming tool that does not handle this specifically. Another option is to recover the device using "nrfjprog --recover --coprocessor CP_NETWORK" and then "nrfjprog --recover --coprocessor". This will write to the UICR register for both the app and net core, and also write a small dummy application that unlocks the debug interface. If you afterwards program an image after doing a full chip erase (so the UICR) is not deleted, and that firmware enables the debug interface (which is the default behavior in the nRF Connect SDK), you will be able to debug and read back the flash content. 

[vojtech265]

Hi Einar,

thank you for reply.

Only way I succesfully flashed the chip was using the merged image and the Programmer v3.0.8.

When I use the nrfjprog for flashing the image for net core, I get following errors:

steps executed:

nrfjprog --recover --coprocessor CP_NETWORK

nrfjprog --program

The idea is to automate flashing. When I use the example file for blinking diode program_hex.py and do following modification:

def run(snr=None):
    """
    Run example script.

    @param (optional) int snr: Specify serial number of DK to run example on.
    """

    api = LowLevel.API(LowLevel.DeviceFamily.UNKNOWN)
    
    # Open the loaded DLL and connect to an emulator probe. If several are connected a pop up will appear.
    api.open()

    try:
        if snr is not None:
            api.connect_to_emu_with_snr(snr)
        else:
            api.connect_to_emu_without_snr()

        device_family = api.read_device_family()

        api.select_family(device_family)

        hex_file_path_net = 'C:/nRF5340/net_file.hex'

        api.recover()
        api.enable_coprocessor(coprocessor=Parameters.CoProcessor.CP_NETWORK)

        api.program_file(hex_file_path_net)

        api.sys_reset()
        api.close()

    except LowLevel.APIError:
        api.close()
        raise
    
 
if __name__ == '__main__':
    run()

I get this message:

pynrfjprog.APIError.APIError: An error was reported by NRFJPROG DLL: -173 UNKNOWN_MEMORY_ERROR.

Any ideas why it is not working or what I do wrong? 

Thanks!

[Einar Thorsrud]

Hi,

Are you trying to program the net core or the app core? Here you are recovering the net core, but attempting to program the app core (which is the default when no coprocessor is specified). Also, note that you can recover and program in one go.

vojtech265 said:

steps executed:

nrfjprog --recover --coprocessor CP_NETWORK

nrfjprog --program

Regarding the error you got from your script, I wonder if this is because of a mismatch between the address range in the hex and the core you are connected to. If the hex is for the network core, you need to select it, typically with a sequence like you see in this script (where the app core is explicitly used, but you can use the same approach for the net core by replacing CP_APPLICATION with CP_NETWORK.

[vojtech265]

Hi Einar,

perfect explanation, thank you! Now I am able to flash both cores with the script one after the other using this:

api.enable_coprocessor(coprocessor=Parameters.CoProcessor.CP_NETWORK)
api.select_coprocessor(coprocessor=Parameters.CoProcessor.CP_NETWORK)
api.recover()

api.erase_file(file_path=hex_file_path_net)
api.program_file(hex_file_path_net)

api.enable_coprocessor(coprocessor=Parameters.CoProcessor.CP_APPLICATION)
api.select_coprocessor(coprocessor=Parameters.CoProcessor.CP_APPLICATION)
api.recover()

api.erase_file(file_path=hex_file_path_app)
api.program_file(hex_file_path_app)

However, the problem with connecting to the device still occures in J-Flash:

1. I succesfully flashed the chip with the script above

2. I choose nrf5340_xxaa_net, connect to the device and still getting this message:

But readback with the nrf Connect Programmer works perfectly fine.

The problem is gone, when I manually flash merged image via nrf Connect Programmer:

1. I manually flash the chip with the nrf Connect Programmer

2. In J-Flash I choose nrf5340_xxaa_net, connect to the device succesfully connect and can readback

Is there anything in my script missing? Where could be that problem?

[Einar Thorsrud]

Hi,

There is one fundamental difference when doing a recover from the python API and the command line, and that is that when doing recover from the command line, a special hex file is written that enables debugger access in the UICR and also runtime (see CTRL-AP - Control access port for details on how the mechanism works in the SoC).

As that does not happen automatically, you now need to write to the APPROTECT register in UICR from your script in order to keep debugger access alive. This needs to be done both for the app and net core, and you need to write the magic word 0x50FA50FA. The firmware you program must also enable debugger access, but that is the default in the nRF Connect SDK, and as this works when you program from the command line, that should be in order.

[vojtech265]

Thank you for reply.

Is this special hexfile available? What I tried after flash FW:
- write 0x50fa50fa to the 0xff8000 for the app core

- write 0x50fa50fa to the 0x1ff8000 for the net core

- power on reset

then if I connect to the device it is protected. Is something what I am missing? Thanks!

[Einar Thorsrud]

Hi,

vojtech265 said:

Is this special hexfile available?

No, it is part of the nrfjprog binary. But you can build a nRF Connect SDK project yourself and flash it and it would do the same by default, which is to enable debugger access.

vojtech265 said:

then if I connect to the device it is protected. Is something what I am missing?

Yes, that is expected. In order to access the debugger interface either an erase all operation has to be performed in that debug session (which is how you can recover a device and program and empty device), or what is relevant in this case: Both have the magic word in APPROTECT register in UICR and the running firmware must write to APPROTECT.DISABLE. If you have not flashed any firmware, that does not happen, and therefor debugger access is blocked.

Summing up: To unlock the debug port, you you must both have the magic word in UICR.APPROTECT and firmware must write the magic word to APPROTECT.DISABLE on every boot. Both this happens automatically with nrfjprog --recover from the command line. If you use other tools, you need to handle it yourself, which means writing to UICR and programming your firmware).

PS: To build a firmware that does not open the debugger, you need to enable  NRF_APPROTECT_LOCK and CONFIG_NRF_SECURE_APPROTECT_LOCK if you want that at a later stage.