softdevice update

RE: softdevice update

Matt Barr — Tue, 03 Mar 2015 22:07:55 GMT

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.

RE: softdevice update

Jeff Wormsley — Tue, 03 Mar 2015 17:40:43 GMT

Thank you Matt!

RE: softdevice update

Matt Barr — Tue, 03 Mar 2015 17:13:30 GMT

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.

RE: softdevice update

Matt Barr — Tue, 03 Mar 2015 16:53:41 GMT

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!

RE: softdevice update

Jeff Wormsley — Fri, 27 Feb 2015 16:27:28 GMT

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.

RE: softdevice update

Matt Barr — Fri, 27 Feb 2015 16:23:40 GMT

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...

RE: softdevice update

Matt Barr — Fri, 27 Feb 2015 14:37:24 GMT

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

RE: softdevice update

Jeff Wormsley — Thu, 26 Feb 2015 21:02:08 GMT

Could you post your port for other IAR users? I've looked at the bootloader_util_arm.c and bootloader_util_gcc.c files, but am not up to porting that to IAR. Thanks!

RE: softdevice update

Matt Barr — Mon, 23 Feb 2015 15:38:52 GMT

Thanks very much for the confirmation.

RE: softdevice update

Hung Bui — Mon, 23 Feb 2015 12:31:52 GMT

Yes, we are aware of that, and it's a bigger issue with S130 and S120 where there is not enough room for bootloader+softdevice update. We will try to find a solution for that.

RE: softdevice update

Hung Bui — Mon, 23 Feb 2015 12:29:54 GMT

@Matt: Correct. Address 0x800 is the flash page where the MBR uses to store some information when doing softdevice&bootloader swapping. It's fine to have something there when you do a bootloader/softdevice update.

RE: softdevice update

Matt Barr — Fri, 20 Feb 2015 16:43:16 GMT

It is probably worth noting that with the s310 there are 0x1f000 bytes available between softdevice and bootloader located at 0x38000. This is sufficient to support a combined bootloader+softdevice update with the s310, but there is not much room for bootloader expansion.