• State Verified Answer
  • Replies 3 replies
  • Subscribers 92 subscribers
  • Views 72 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 360722
Options

Migrating from SDK11 TO SDK17

YuvalShavit

Hi, 

I migrated my software from SDK11 TO SDK17

(Changed the BL + SD + APP)

Now i want to upgrade to (SDK17) old units (with SDK11) in the field.

Do you have any advise how to do that ?!

(i Tried many hours asking the AI but failed so far....

The AI said to migrate it in 2 phases - the BL and SD toghther and declare them as APP (because of size problems) , but i didn't sucseed doing that)

Hope there is a way to do that.....

Parents
  • 0

    No idea what AI was hallucinating here.

    The memory layout - especially the bootloader location and reserved sector count - need to match exactly to you old application. Don't remember whether that is possible in the first place and will likely need manual configuration.

    The other condition is that new SD+new BL must fit in the slot space for the app. Could be rather tight in the NRF52832 depending on which SD you intended to use.

  • 0 in reply to Turbo J

    The SDK11 BL is about 16K, The SDK17 BL is about 20K (Mybe Becasue of the encryption part), also - the SD size in the new SDK17 is bigger. I will wait for a Nordic engineer to answer this question - if there is a way to replace all of this (BL+SD+APP) from air when the SDK is so old....

  • +1 in reply to YuvalShavit

    Hi,

    There is no safe way to accomodate a larger bootloader and move from the legacy bootloader to the secure bootloader. It is however possible, as described in this old post. This will happen in two phases, first a temporary legacy bootlaoder modified to update the bootloader start address, and then a secon update to the new bootloader. But doing this will be at your own risk, and even if everything is done right, a reset at the wrong time in the update procedure will brick the device (making it only revoverable with a debugger). This describe going from SDK 11 to 12, and not all the way up to 17.1, but that is more details, as this addresses the fundamental problem that makes this difficult.

    I would condier if it would be better to make a break and let the older existing devices be based on the old SDK and not do thid update in the field. Instead, maintain two separate variants, one new based on a updated SDK, and the older based on SDK 11. But there are several tradeoffs here that you have to make and find what fits best for your product.

Reply
  • +1 in reply to YuvalShavit

    Hi,

    There is no safe way to accomodate a larger bootloader and move from the legacy bootloader to the secure bootloader. It is however possible, as described in this old post. This will happen in two phases, first a temporary legacy bootlaoder modified to update the bootloader start address, and then a secon update to the new bootloader. But doing this will be at your own risk, and even if everything is done right, a reset at the wrong time in the update procedure will brick the device (making it only revoverable with a debugger). This describe going from SDK 11 to 12, and not all the way up to 17.1, but that is more details, as this addresses the fundamental problem that makes this difficult.

    I would condier if it would be better to make a break and let the older existing devices be based on the old SDK and not do thid update in the field. Instead, maintain two separate variants, one new based on a updated SDK, and the older based on SDK 11. But there are several tradeoffs here that you have to make and find what fits best for your product.

Children
No Data
Related
Terms of service