OTA Update with nrf52840DK rev. 3.0.1 vs. rev. 2.0.1

Hello Forum,

I have one working nrf52840DK rev. 2.0.1

I can use it to OTA-flash a BM833 (MAC:E419E134561C) in the following way (in Ubuntu Linux command line) with the prepared app_dfu_package.zip:

nrfjprog --recover

/usr/local/bin/nrfutil dfu ble -f -ic NRF52 -pkg /tmp/app_dfu_package.zip -p /dev/ttyACM1 -a E419E134561C

Now I'm using the same commands, the same app_dfu_package.zip BUT nrf52840DK rev. 3.0.1.

This renders in the program's output:

Flashing connectivity firmware...
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/ble_driver.py", line 3201, in call_cmd
    return subprocess.check_output(argstr, stderr=subprocess.STDOUT, shell=True)
  File "/usr/lib/python3.8/subprocess.py", line 415, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command 'nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/nrfutil", line 33, in <module>
    sys.exit(load_entry_point('nrfutil==6.1.3', 'console_scripts', 'nrfutil')())
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/nrfutil-6.1.3-py3.8.egg/nordicsemi/__main__.py", line 1172, in ble
    flasher.fw_flash()
  File "/usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/ble_driver.py", line 3166, in fw_flash
    self.program(hex_file)
  File "/usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/ble_driver.py", line 3194, in program
    self.call_cmd(args)
  File "/usr/lib/python3/dist-packages/wrapt/decorators.py", line 443, in _synchronized
    return wrapped(*args, **kwargs)
  File "/usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/ble_driver.py", line 3206, in call_cmd
    raise RuntimeError(f"{e.__str__()}\n{e.output}")
RuntimeError: Command 'nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.
b'Parsing image file.\nERROR: The file specified is not a valid hex file, has data outside valid areas\nERROR: or does not have data in valid areas.\n'

What needs to be done to get the process to work with nrf52840DK rev. 3.0.1?

Best regards,

Richard

Parents
  • Hi,

    Rev 3.0.x of the nRF52840DK has 2 comports, but only one of them is 'available to the user'. Could you try to list the available ports with nrfjprog --com and try with the other one? It should be TTYACM0 or TTYACM2 instead of TTYACM1 which you've tried.

    Here's how it looks on windows: The one on top is a rev. 3.0.0 version of the nRF52840DK, the bottom one is in this case a rev 1.0.0, but it should showcase the same as a rev. 2.0.0

    Kind regards,
    Andreas

  • Hello Andreas,

    Thank you for responding. The available ttys from DK are /dev/ttyACM1 and /dev/ttyACM2.

    I tried with /dev/ttyACM2, but the result remains the same.

    Also, I'm quite sure that I use the correct ttyACM1, because flashing the bootloader via nrfjprog and using /dev/ttyACM1 works.

    By the time, I also downloaded and installed the latest version of nrfutil and nrf5sdk-tools here:

    https://www.nordicsemi.com/Products/Development-tools/nrf-util

    But also this version renders the same problem (here the output with /dev/ttyACM2):

    Flashing connectivity firmware...
    Traceback (most recent call last):
      File "pc_ble_driver_py/ble_driver.py", line 3207, in call_cmd
      File "subprocess.py", line 420, in check_output
      File "subprocess.py", line 524, in run
    subprocess.CalledProcessError: Command 'nrfjprog --snr 1050239327 --program /tmp/_MEIwNqyRX/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "nordicsemi/__main__.py", line 1555, in <module>
      File "click/core.py", line 1137, in __call__
      File "click/core.py", line 1062, in main
      File "click/core.py", line 1668, in invoke
      File "click/core.py", line 1668, in invoke
      File "click/core.py", line 1404, in invoke
      File "click/core.py", line 763, in invoke
      File "nordicsemi/__main__.py", line 1182, in ble
      File "pc_ble_driver_py/ble_driver.py", line 3172, in fw_flash
      File "pc_ble_driver_py/ble_driver.py", line 3200, in program
      File "wrapt/decorators.py", line 470, in _synchronized
      File "pc_ble_driver_py/ble_driver.py", line 3212, in call_cmd
    RuntimeError: Command 'nrfjprog --snr 1050239327 --program /tmp/_MEIwNqyRX/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.
    b'Parsing image file.\nERROR: The file specified is not a valid hex file, has data outside valid areas\nERROR: or does not have data in valid areas.\n'
    [35374] Failed to execute script '__main__' due to unhandled exception!

    Best regards,

    Richard

  • Noted

    I also see that I might have misunderstood your inquiry after rereading it. I will revisit the case in some more depth and come back with a reply as soon as possible. No later than the end of this working week

    Kind regards,
    Andreas

  • Hello Andreas,

    I went further into investigation.

    The relevant failure was:
    RuntimeError: Command 'nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.
    b'Parsing image file.\nERROR: The file specified is not a valid hex file, has data outside valid areas\nERROR: or does not have data in valid areas.\n'

    Now I tried the following:

    1) Execute the line manually:

    nrfjprog --recover

    nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52

    This rendered the same error from command line.

    2) Perform the upload via nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8)

    -> Select file: /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex

    Erase&Write

    To my surprise, that upload to the new (3.0.1) nrf52840DK worked without complaints.

    When issuing the original command, the nrfutil reported back:

    >>Board already flashed with connectivity firmware.

    And the DFU proceeded with success.

    Now, I wouldn't care to add an extra scripted step, but of course, I cannot use the GUI from nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8)

    So, the remaining question is: How can the upload-steps performed by nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8) be emulated in Ubuntu command line? Or how can nrfjprog be parametrised not-to-parse the image file?

    Best regards,

    Richard

Reply
  • Hello Andreas,

    I went further into investigation.

    The relevant failure was:
    RuntimeError: Command 'nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52' returned non-zero exit status 52.
    b'Parsing image file.\nERROR: The file specified is not a valid hex file, has data outside valid areas\nERROR: or does not have data in valid areas.\n'

    Now I tried the following:

    1) Execute the line manually:

    nrfjprog --recover

    nrfjprog --snr 1050239327 --program /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex --family NRF52

    This rendered the same error from command line.

    2) Perform the upload via nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8)

    -> Select file: /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex

    Erase&Write

    To my surprise, that upload to the new (3.0.1) nrf52840DK worked without complaints.

    When issuing the original command, the nrfutil reported back:

    >>Board already flashed with connectivity firmware.

    And the DFU proceeded with success.

    Now, I wouldn't care to add an extra scripted step, but of course, I cannot use the GUI from nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8)

    So, the remaining question is: How can the upload-steps performed by nrfConnect (v. 4.1.1) --> Programmer (v. 3.0.8) be emulated in Ubuntu command line? Or how can nrfjprog be parametrised not-to-parse the image file?

    Best regards,

    Richard

Children
  • Hi everyone,

    following the given observations, the following workaround script is working for me:

    #!/bin/bash
    
    nrfjprog --recover
    nrfjprog --family nRF52 --eraseall
    
    cat << EOF | JLinkExe 
    BEGIN;
    
    device NRF52
    SelectInterface SWD 
    speed 4000
    Connect
    loadfile /usr/local/lib/python3.8/dist-packages/pc_ble_driver_py/hex/sd_api_v5/connectivity_4.1.4_1m_with_s132_5.1.0.hex
    exit
    
    END;
    EOF
    
    /usr/bin/sudo /usr/local/bin/nrfutil dfu ble -f -ic NRF52 -pkg /tmp/app_dfu_package.zip -p /dev/ttyACM1 -a F584C02766DD

    This clears the DK, then uses JLinkExe to flash on the required hex image.

    And, as detected before, the nrfutil then detects:

    >>Board already flashed with connectivity firmware.

    And after that continues flashing the firmware via DFU.

    Thank you, Andreas, for trying to assist.

    Best regards,

    Richard

  • Hi

    Hehe, yeah that was a bit far from my first suggestion when I initially looked through the case (just to clarify I misread "using DKs to update other devices" as "Update DKs", which is why I touched upon the usb ports)

    Nonetheless, I'm glad to hear that you solved the issue, and we're very thankful for you posting the solution in this thread! 

    As always, please feel free to create new tickets if new issues or questions comes up and we'll assign them to an application engineer and answer them as soon as we can

    Kind regards,
    Andreas

Related