pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x05: The firmware version is too low.

[BTtester]

Using  nfutil to dfu a package to nrf52832 using dongle nrf52840 on windows 10 and python 3.8.10

Able to access nrf52832 with nrconnect desktop (but can't get dfu to work with nrfdesktop.Case ID: 290417 ) I am able to get dfu to work with nrfConnect for android.

I am running the following command

nrfutil.exe dfu ble -pkg dfu_pkg_w_bl.2.5.8.release.zip -a D27F2A70D5BE -ic NRF52 -p COM4

Result:

[------------------------------------] 0%
Traceback (most recent call last):
File "nordicsemi\__main__.py", line 1545, 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 1205, in ble
File "nordicsemi\dfu\dfu.py", line 115, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 95, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_ble.py", line 526, in send_init_packet
File "nordicsemi\dfu\dfu_transport_ble.py", line 607, in __execute
File "nordicsemi\dfu\dfu_transport_ble.py", line 682, in __get_response
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x05: The firmware version is too low. For an application, the version must be greater than or equal to the current application. For a bootloader, it must be greater than the current version. This requirement prevents downgrade attacks.
[3372] Failed to execute script '__main__' due to unhandled exception!

The firmware revision string for the application on nrf52832 is 2.5.7

The firmware in the zip file is 2.5.8  

I don't understand the error "firmware revision is to low.

Note:   The dongle is programmed with: Connectivity firmware version: ble-connectivity 4.1.4+Mar-11-2021-08-36-04. SoftDevice API version: 5. Baud rate: 1000000.

Please advise.  

[BTtester]

With Android nrfconnect, the dfu download works with out errors.  

[Vidar Berg]

I'm afraid I can't think of any possible explanations for this. Is it possible to attach a debugger to the board and check why the version check fails?

[BTtester]

Hi Vidar,  

My goal is to automate  the dfu download for use in manufacturing and I believe nrfutil should be  good method to do this.  I do not have to use windows 10 and I am flexible on python version.  . Given a choice, what os do you recommend running nrfutil?   Can I run it on an Android tablet and use the blue tooth built into the tablet just like nrfConnect for Android does?  Are there special instructions for doing that?  

Regards,

Scott

[Vidar Berg]

Hi Scott,

If programming over the SWD interface is not an option, then I would recommend nrfutil in a over the nRF connect for desktop app because it is scriptable.

While we are only distributing and testing nrfutil for x86/x64 architectures, it is possible to build for other CPU architectures as well. Here is one example with the Raspberry PI:  https://devzone.nordicsemi.com/f/nordic-q-a/88841/how-to-use-nrfutil-for-ble-dfu-on-raspberry-pi

Regards,

Vidar

[BTtester]

I determined that the firmware I am downloading includes the bootloader and the bootloader is the same version as the bootloader on the target board.  If I download the firmware without the  the bootloader, it downloads successfully.    

Question:  Is it feasible to shut off the check in python?

[mrono]

BTtester said:

Question:  Is it feasible to shut off the check in python?

The check is in the bootloader, so the only way to remove it would be to modify the bootloader.

What would be possible, but not implemented, is that nRF Connect for Desktop would continue and send the application even if the bootloader is rejected. I believe the iOS and Android versions do this, but the desktop version does not.

[Vidar Berg]

Thanks mrono. You are right with regards to the difference between the desktop app and the mobile apps.

[BTtester]

I am using nrfutil to do the download. 

1) Can I modify the python code of nrfutil to mimic the behavior of the Android nrfConnect and "to continue and send the application even if the bootloader is rejected".  Possibly adding a command line variable to nrfutil to do this. 

2) Do you think this would have general interest to the developer community?

[Vidar Berg]

1) Yes, you can modify the script to mimic the behavior of the mobile apps. However, I think the easier solution is to simply run nrfutil twice, first with the bootloader package, then with the app. From the bootloader's perspective, a bootloader + Application update has to be performed in two stages anyway: Dual-bank updates.

e.g.

nrfutil.exe dfu ble -pkg <bootloader only>.zip -a D27F2A70D5BE -ic NRF52 -p COM4

nrfutil.exe dfu ble -pkg <application>.zip -a D27F2A70D5BE -ic NRF52 -p COM4

2) Possibly, but I don't recall seeing any requests for this.

[BTtester]

Thank you Vidar.

  1)I would like to make sure I understand the solution of running nrfutil two times.   The idea is that if the bootloader version is the same as the existing version, it can be rejected.  Then the second execution of nrfutil containing the  application download could proceed without error.  Do I understand your idea correctionly?

2) I have a related issue that I need to mention.  We modify  bootloader code to also   transfer  firmware from the nordic chip to another chip that lacks bluetooth.  Sometimes we modify our code and in our version control system, the bootloader has a new version.    However, when I run nrfutil with this "updated bootloader",  the bootloader rejects it. Can you provide info on what needs to modified in the bootloader code so that the bootloader detects it as a new verision.

[Vidar Berg]

1) Yes, your understanding is correct.

2) Does the bootloader return any error codes? It could be that the new bootloader is to large to fit into the existing bootloader region (Memory layout). An important thing to note about bootloader updates is that you cannot change the start address through DFU, effectively limiting the size of future updates to the size initially allocated to your bootloader region.

Does the new bootloader have the same start address in FLASH?