• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 11 replies
  • Subscribers 64 subscribers
  • Views 9132 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 116773
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Updating from S132 v2.0.x to S132 v3.0.0 with Dual Bank Bootloader from SDK v11.0.0 does not work.

bjorn-spockeli

Updating the SoftDevice on the nRF52832 from S132 v2.0.x to S132 v3.0 using the Dual Bank Bootloader from SDK v11.0.0 results in the application not starting up after the update is complete.

A readback of the flash after the update shows that a section of the SoftDevice 0x0E000-0x0E7FF (2k) is erased.

This issue does not occur when updating from S132 v2.0.0 to S132 v2.0.1. Why does the update from v2.0.x to v3.0.0 fail?

Parents
  • 0

    Hi, I just hit this issue with some old SDK11 based device I wanted to upgrade and wonder why the block size was computed in such relatively complex way? What was the original point of computing exactly (startXX-startYY)/2? which was then fixed by making it smaller anyway?

    I am both just curious why there was not simply some constant like 0x8000 from the start and also for practical reason -  patching broken bootloader binary with some constant now is easier than fitting additional masking code in and/or rebuilding from old source/SDK.

    I guess I can also patch it with 0xD000 value as below to be on the safe side since the expression is constant anyway as this buggy SDK11 bootloader is tied to SD v2.0.x so boot_settings.sd_image_start value is always 0x1C000 (?) so this is in fact build time constant no matter what new SD+bootloader package I flash(?)

  • 0 in reply to fanoush

    : I do not know the reasoning for calculating it as (boot_settings.sd_image_start –sd_start)/2; for the nRF51 SDK. Yes, with the S132 v2.0.x the new image will be placed in flash from 0x1c000 and upwards. 

  • 0 in reply to bjorn-spockeli

    Thanks, So I'll just try to patch the bootloader binary with direct 0xD000 register load, update it  and see if second update with newer SoftDevice/bootloader gets through.

    And BTW the device is cheap ($7.99 on gearbest) nrf52 based DS-D6 fitness tracker repurposed to run Espruino. So far I was stuck to building it with old SDK11 due to this bug as it wasn't possible to update it without opening and using SWD pins.

  • 0 in reply to bjorn-spockeli

    I patched succesfully the dfu_sd_image_swap() code with 0xd000 constant, created legacy DFU package with fixed bootloader and after update I managed  to succesfully upload another combined package of SDK12 based  bootloader with softdevice 3.0 and have DfuTarg device listening now. So overall it was a big success :-)

    I guess I need also patch dfu_sd_image_validate just to be on safe side if something goes wrong. 

Reply
  • 0 in reply to bjorn-spockeli

    I patched succesfully the dfu_sd_image_swap() code with 0xd000 constant, created legacy DFU package with fixed bootloader and after update I managed  to succesfully upload another combined package of SDK12 based  bootloader with softdevice 3.0 and have DfuTarg device listening now. So overall it was a big success :-)

    I guess I need also patch dfu_sd_image_validate just to be on safe side if something goes wrong. 

Children
Related