SD + BL + APP dfu serial update failed

[ManuelF]

Hi, I try to update a nRF52832 with SDK 14.2.0 to SDK 15.3. I created a package with SD + BL + APP with the following command:

nrfutil pkg generate --hw-version 52 --key-file private.key \
        --application-version 2 --application application.hex \
        --sd-req 0x9D,0x98,0xB7 --softdevice softdevice.hex --sd-id 0xB7 \
        --bootloader bootloader.hex --bootloader-version 2 \
        app_dfu_package.zip

I'm using nrfutil (v5.1.0) to download the update via serial (nrfutil dfu serial -pkg ... ). Now the first part (SD + BL) succeeded, but somehow the second part, updating application, failed.
Nrfutil gives the following error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nordicsemi/__main__.py", line 89, in do_main
    do_serial(package = args.package[0], port = args.port[0], dfuStart = args.dfuStart)
  File "/usr/lib/python2.7/site-packages/nordicsemi/__main__.py", line 69, in do_serial
    dfu.dfu_send_images()
  File "/usr/lib/python2.7/site-packages/nordicsemi/dfu/dfu.py", line 120, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "/usr/lib/python2.7/site-packages/nordicsemi/dfu/dfu.py", line 81, in _dfu_send_image
    self.dfu_transport.open()
  File "/usr/lib/python2.7/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 204, in open
    self.__get_mtu()
  File "/usr/lib/python2.7/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 306, in __get_mtu
    self.mtu = struct.unpack('<H', bytearray(response))[0]
TypeError: 'NoneType' object is not iterable

After updating the Bootloader and Softdevice, will still the old bootloader handle the application update or is already the new bootloader started? I read some threads about a problem with the softdevice size, but this should be fixed in SDK v15.3, correct? I also tried to do a package with SD + BL + APP from SDK 14.2.0 and the error is the same...

[ManuelF]

I now completly removed all files and reinstall nrfutil and it now run with python 3.7...
But now I again have the same issue as with the v 5.1.0 of nrfutil:

sudo nrfutil -v -v -v dfu serial -b 115200 -p /dev/ttyUSB0 -pkg app_dfu_package.zip
2019-10-21 16:46:41,364 Using board at serial port: /dev/ttyUSB0
2019-10-21 16:46:41,365 Sending SoftDevice+Bootloader image.
2019-10-21 16:46:44,379 Serial: Set Packet Receipt Notification 0
2019-10-21 16:46:44,411 Sending init packet...
2019-10-21 16:46:44,411 Serial: Selecting Object: type:1
2019-10-21 16:46:44,427 Serial: Object selected:  max_size:256 offset:0 crc:0
2019-10-21 16:46:44,443 Serial: Streaming Data: len:154 offset:0 crc:0x00000000
2019-10-21 16:46:44,635 Sending firmware file...
2019-10-21 16:46:44,636 Serial: Selecting Object: type:2
2019-10-21 16:46:44,651 Serial: Object selected:  max_size:4096 offset:0 crc:0
2019-10-21 16:46:44,667 Serial: Streaming Data: len:4096 offset:0 crc:0x00000000
2019-10-21 16:46:45,152 Serial: Streaming Data: len:4096 offset:4096 crc:0x086FE1F0
......
2019-10-21 16:47:04,451 Serial: Streaming Data: len:596 offset:167936 crc:0x9E5B00C2
2019-10-21 16:47:04,819 Image sent in 20.407888889312744s
2019-10-21 16:47:04,820 Sending Application image.
2019-10-21 16:47:08,824 Serial: No ping response
2019-10-21 16:47:09,826 Serial: No ping response
2019-10-21 16:47:10,827 Serial: No ping response
2019-10-21 16:47:11,829 Serial: No ping response

I noticed that the device after download the first image, the LED 3 shortly ligths up (1-2s).  How can I check, that the update of bootloader + softdevice is successfully? If I enable log, the image is too big (insufficient ressources)...

Edit:
I today checked, if I flash the device with programmer to SDK 15.3 and then try update with nrftool, every thing was successfully. So from my point of view something went wrong while exchange the bootloader. Or could it be that the softdevice or bootloader is at wrong place? If I use the wrong sd-req or sd-id, would I get an error from nrfutil?

[Einar Thorsrud]

Hi,

The printout now indicates that things are working from the nrfutil perspective, though there is an error with the image transfer.

The best way to debug the bootloader is using logging, but as you write you will get an error by enabling logging out of the box. Therefore, the SDK has a separate set of bootloader projects suffixes with _debug, which has RTT logging enabled, and a lower start address to make it fit. Using this when facing bootloader issues is highly recommended, as it most of the time helps to narrow down the issue significantly. I suggest you do this first.

The SoftDevice always needs to start at address 0. Your application should always start immediately after the bootloader. Regarding the SoftDevice ID, this is checked based on what you enter when you make the DFU image. So if you enter the wrong ID's (or include ID's that should not have been included), it will not prevent an incompatible update. The idea here is that it should protect the end customer since you test the upgrade image before you ship it, but you need to have control. If the bootloader is built to use the SoftDevice, it needs to be a compatible version.

Therefore, a bootloader upgrade should always be accompanied by a new SoftDevice if the versions change. For the application, it is the same, but you do not risk bricking the device if you have a way of putting it in DFU mode, so the requirement is relaxed. But if you set the sd-req wrong, the bootloader may accept the application even though it has an incompatible SoftDevice, and the application will start and crash. Can you list all versions you upgrade from and to?