hexfile release for SDK 7.0.1+ for softdevice update testing?

Question

I have developed an bootloader operating with external flash for image storage. For the use case it is not acceptable to put the device into an inoperable (no-application) state while receiving an application over BLE, therefore during a softdevice update both the softdevice+bootloader and application are stored in external flash before the DFU procedure begins transferring data. 
 
 I ran into quite a few unexpected issues around the sd_req check, that I believe I have worked around. I now need to perform tests that demonstrate the softdevice/bootloader/application update without breaking. Since I built my code based on the latest SDK, my test is already starting with the latest version of the SDK. Is there someplace I can download an SDK with version greater than 7.0.1?

Karl Ylvisaker · Accepted Answer

Hello, Sorry for my late reply. 
 Anthony Ambuehl said: Regarding bricking the device, many end-users I have dealt with decided the device was bricked when it was sitting in bootloader waiting for DFU. 
 Yes, I agree that a device sitting in DFU mode is likely to be indistinguishable from a bricked device for an end user. However, I personally have not heard back about this from customers before. I will mention this to a colleague and see if she has heard anything about it. 
 Anthony Ambuehl said: This would usually require integrating a driver for a screen into the bootloader which would significantly increase the bootloader size. 
 I suppose any kind of feedback to the user might fulfill the same purpose here, for example a rapidly blinking/changing LED - to avoid having to include a screen driver. Of course, this is dependent on the application/device, and what peripherals it has available. 
 Anthony Ambuehl said: Furthermore as I explained, I don't see listing both the old and new softdevice in the sd_req as a safe approach. If the new bootloader or application are NOT compatible with the old softdevice then its important not to allow them to be updated without a softdevice update. In my situation where both images (softdevice+bootloader and application) are downloaded and saved before any update begins, I believe it is safest to disable the sd_req check for the softdevice+bootloader and add a pre-validation step to confirm the soft_device+bootloader matches the sd_req of the stored application. Please advice if you see any reason this would be problematic. 
 The only time you would need to include both the old and new SoftDevice is when both SoftDevice and Bootloader is updated in the same package, which makes it safe since they are being updated at the same time. Apart from limiting your options for the DFU as I mentioned earlier, I do not see any reason why your approach should be problematic. 
 Anthony Ambuehl said: Actually it would be really appreciated if in the future Nordic could provide an example bootloader with external storage capability. I have been adding it on to the existing bootloader as an additional dfu transport, but its not a perfect fit. Certain assumption like this sd_req checking should work differently in this use case. 
 I have noted your request for an example bootloader with external storage capabilities, and I have created an internal request with the SDK team to create such an example, thank you for your suggestion - we appreciate the feedback! As for the last part, it is of utmost importance to us to disable customers from bricking their devices when performing a bootloader DFU, while we still would like to offer a highly versatile DFU framework to develop with. This comes with some extra overhead, but with the benefit of making it virtually impossible to accidentally bricking the device. I will confer with some colleagues to hear their thoughts on this. Thank you for bringing up your concerns and thoughts on this! Best regards, Karl

hexfile release for SDK 7.0.1+ for softdevice update testing?

Top Replies