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]

Hi Jeff, I'm sorry but my employer paid me to make these changes and I don't believe I'm free to share it. The good news is that you don't have to re-write things, just make the compiler directives and assembler input IAR friendly. Assembler functions generally need to be #ifdef'd out and placed in a separate .s file, IAR doesn't handle the block .asm directive.

In the IAR documentation see __no_init to bypass variable zero-init at startup. Also see #pragma required=xxx to keep the compiler from discarding apparently unused variable and constant data definitions, and look at the @ ADDR = VALUE construct to locate and initialize data.

Finally, ICC optimization seems to break bootloader DFU functionality. The unoptimized bootloader won't fit at 0x3C000, so allow a bit more code space in the .icf and make the corresponding change to dfu_types.h.

Hope this helps, Matt

[Matt Barr]

After thinking more about this and the SDK license agreement, I'm not sure what the legalities are here. The source code is property of Nordic, we've made changes, but I don't believe that means we own it. I am out of town this week, I will ask my employer how he feels and will talk to Nordic about my obligations here, I certainly want to do the right thing. I have a couple engineering degrees but no law degree...

[Jeff Wormsley]

Hopefully, considering how small this particular item is, and the fact it was derived from existing functionality, it will be ok to share. If not, I understand, maybe someone else will be able to help me out. I've got enough to actually compile the code, but I don't think things are being put into the right places. I used the GCC version as a start, since it had far less assembly, and used the ICF file to create the memory regions, but after reading your message it looks like you took a better approach.

[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]

Hi Jeff, I just added an "answer" that contains the dual bank BLE bootloader port to IAR, along with a ported application for testing. Hope this helps you and others, IAR support in the 7.x.x SDKs is sparse.