softdevice update

[Matt Barr]

First, many thanks for the great DFU recipe in the latest SDK!

I've ported OTA DFU to the IAR tool chain for both s110 and s310. I can flip back and forth between the two softdevices by updating from a .zip file with softdevice, bootloader and init files specific to the target softdevice. This would seem to be safe with v7.1.0 s110 and v2.0.1 s310 since the MBRs are identical.

I notice one small issue when I read back the programmed softdevice images after DFU. When initially programmed after erase the 16 bytes at 0x0800 are 1-filled, and they remain erased after a normal application-only update. This makes sense because these locations are undefined in the softdevice hex file and should remain erased.

However, after softdevice and bootloader DFU for the s110 I find:

:10080000000000000C120300E6180000FF63000067

and for the s310 I find:

:1008000000000000E0100300E6180000FF63000095

I believe this is an unused portion of the MBR and this is a non-issue. Can anyone confirm this, and also confirm that it is generally safe to update softdevice+bootloader between S110 and S310?

Thanks and Best Regards, Matt

[Matt Barr]

Here is an IAR port of the dual bank BLE bootloader. It is based on the 7.2.0 SDK. Don't let the name fool you, it is NOT a complete SDK! It is a zip file that contains just the new and modified files for the bootloader IAR port, a related IAR project, and an IAR project for the experimental ble_app_hrs application with DFU support. You'll find:

• components/libraries/bootloader_dfu/
• examples/dfu/bootloader/pca10028/dual_bank_ble_s110/iar/
• examples/ble_peripheral/ble_app_hrs/pca10028/experimental_s110_with_dfu/iar/

Also included is examples/iar_hexfiles/ which contains hex file output from the IAR builds along with other relevant hex files (app_valid_setting_apply.hex, 7.1.0 S110 softdevice, and merged bootloader/softdevice.)

The original versions of modified SDK files are renamed by adding a .orig suffix. The bootloader and application DFU have been tested as described in examples/iar_hexfiles/README. The bootloader_dfu sources are tweaked so that you can eliminate bsp.c and the related definitions BSP_DEFINES_ONLY and BOARD_PCA10028 from the project, removing hardware platform dependence.

The IAR build is slightly larger than the Keil build, the bootloader is located at 0x3A000. It fits at 0x3C000 if higher optimizations are enabled, but my experience (using IAR EWARM 7.2.0) is that something is optimized away that breaks DFU. I have not yet taken the time to track this down, and am living with extra 8k code space for now.

There are no real changes to the bootloader code, modifications are primarily related to compiler directives and assembly code inclusion for the IAR platform. This works to the best of my knowledge, use at your own risk!

[Matt Barr]

Many thanks to colton for this insight. These IAR projects (bootloader and app) both work if you change the optimization level to high (balanced) and disable static clustering. The code shrinks and the bootloader can be located at 0x3C000, changed from 0x3A000 in the .icf and in dfu_types.h. Very nice.