• State Verified Answer
  • Replies 12 replies
  • Subscribers 73 subscribers
  • Views 5318 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 105674
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

Reply
  • 0

    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

Children
No Data
Related
Terms of service