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

RE: 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 — Fri, 03 May 2019 09:15:51 GMT

Yes, you should also apply the patch to dfu_sd_image_validate ().

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

fanoush — Fri, 03 May 2019 08:22:44 GMT

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.

RE: 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 — Fri, 03 May 2019 07:56:46 GMT

Ok, let me know if you run into any issues 🙂

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

fanoush — Tue, 30 Apr 2019 13:48:01 GMT

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.

RE: 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 — Tue, 30 Apr 2019 13:20:11 GMT

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.

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

fanoush — Tue, 30 Apr 2019 12:41:50 GMT

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(?)

RE: 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 — Mon, 23 Jul 2018 07:00:19 GMT

Does applying the dfu_sd_image_swap() fix to dfu_sd_image_validate() lead to correct behaviour, i.e. no SD corruption?

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

MattMBL — Fri, 13 Jul 2018 21:23:25 GMT

I have confirmed in test, that if the SD copy is interrupted by power loss, then dfu_sd_img_block_swap() is resumed via dfu_sd_image_validate() rather than dfu_sd_image_swap(). Validate still contains the non page aligned block calculation, leading to the same SD corruption as the unfixed code.

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

MattMBL — Fri, 13 Jul 2018 04:55:04 GMT

This is a very old issue, but we are now needing to update some in field devices containing this bootloader.

Could you comment on whether the same change is necessary further down the file in dfu_sd_image_validate()? This code appears to do nearly the same calculations followed by a dfu_sd_img_block_swap() using the blocksize.

A cursory look suggests that the validation may fail due to this block size issue. Any ideas under what conditions would this happen?

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

Erik — Tue, 06 Dec 2016 08:45:30 GMT

Thanks! I belive this is also needed for dfu_single_bank. At least I couldn't get single_bank to update to 3.0.0 without this fix. Best Regards, Erik

RE: 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 — Fri, 30 Sep 2016 10:39:49 GMT

We have just been made aware of this issue and we have discovered that there is a page alignment issue in the code that copies the SoftDevice from swap to the SoftDevice region.

The bootloader library for the nRF52 has been inherited from the nRF51 and was designed with a flash page size of 1kB (0x400) in mind. However, on the nRF52 the flash page size is 4kB(0x1000).

Since the new SoftDevice (S132 v3.0.0) is larger than the old(S132 v2.0.0), the new bootloader image is divided into blocks and copied to the SD region one by one. The bootloader verifies that each block is written correctly to the SoftDevice region before moving on to the next block. This way we ensure that new bootloader is correctly written to flash even though we have to overwrite the start of the firmware image.

The block size is determined the following way:

block_size = (boot_settings.sd_image_start –sd_start)/2;

which in our case will result in the following

block_size = (0x1C000 – 0x1000)/2 = 0xD800

The 0xD800 block would have been page aligned on the nRF51, but on the nRF52 it will be 13.5 flash pages. So when the next block is written to 0xE800, then the first half of the flash page from 0xE000 to 0xE800 is erased.

The fix is to set the block size so that the blocks are page aligned, which is done by adding the following line below line 715 in dfu_sd_image_swap() in dfu_dual_bank.c

block_size &= ~(uint32_t)(CODE_PAGE_SIZE - 1);

This sets the block size to 0xD000 which ensures that the blocks are page aligned. I have attached the modified dfu_dual_bank.c file.

Attachment:

dfu_dual_bank_with_fix.c

Best regards,

Bjørn