[Bug] only partial fix for known SDK11 bootloader bug when updating soft device

[fanoush]

There is known bug in bootloader code when updating SoftDevice which is larger than previous one https://devzone.nordicsemi.com/f/nordic-q-a/16774/updating-from-s132-v2-0-x-to-s132-v3-0-0-with-dual-bank-bootloader-from-sdk-v11-0-0-does-not-work

You actually do have fix for this here
https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/lib/sdk11/components/libraries/bootloader_dfu/dfu_single_bank.c#L686

however same block alignment fix should be also here
https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/lib/sdk11/components/libraries/bootloader_dfu/dfu_single_bank.c#L792
this code is called only when recovering from power failure or reset so the chance of triggering this is low

And same fix should be in dual bank code.

[hathach]

thanks @fanoush for bringing this up, I remembered reading the same topic on devzone as well. But my memory fades and is currently busy with other work. It would help immensely If you could do a PR for this, if you are busy, I will do it as well later.

[fanoush]

So I created pull request #71 I hope it would be somehow referenced here when mentioning issue number in PR name.

BTW thanks for keeping legacy unsigned DFU update alive. I used this bootloader to port micropython to DS-D6 nrf52 based fitness tracker and the dual serial/BLE DFU is awesome.

I made some other changes like support for only 1 button but I guess you are not interested in that.

However I have one question - why pstorage is configured to use 4 blocks here https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/src/pstorage_platform.h#L72 and there is this assert https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/src/main.c#L125 and setting here https://github.com/adafruit/Adafruit_nRF52_Bootloader/blob/master/Makefile#L247 which both expects 7 blocks starting on specific 0x6D000 location? Are those two related (pstorage vs DFU_APP_DATA_RESERVED)? Then why the difference? Is this 0x6D000 also hardcoded elsewhere in other projects?

I guess I can remove this area from my bootloader fork and it will continue to work?

[hathach]

our arduino nrf52 repo use 7 pages for storing bonding information which is reserved when uploading new sketch/firmware. If you don't plan to use our arduino repo, you could safely remove/change it. For PSTORAGE_NUM_OF_PAGES, it is just number of app that register with pstorage raw. It should affect the current code either 3, or 4 is fine I guess

[hathach]

thanks to PR #71

[fanoush]

Thanks for the information, however I do not understand it very much, can you comment a bit more?

why pstorage is configured to use 4 blocks ... Are those two related (pstorage vs DFU_APP_DATA_RESERVED)?

your answer to this was "it is just number of app that register with pstorage raw. It should affect the current code either 3, or 4 is fine I guess"

So I guess this has no relation to running arduino or whatever app at all? It is just a (semi-random) setting for the bootloader build itself because it also uses/links to pstorage SDK code? And it is not related at all to those 7 pages used for bonding information?

Is this 0x6D000 also hardcoded elsewhere in other projects?

Your answer was "our arduino nrf52 repo use 7 pages for storing bonding information which is reserved when uploading new sketch/firmware"

So that means yes this address 0x6D000 is hardcoded in arduino nrf52 repo and must match to share the bonding information written there by apps(?) with bootloader(?). Or maybe it is just hard limit so the bootloader would not flash larger app and overwrite the area but otherwise the data there is not used by bootloader at all? I.e. the bootloader does not use bonding data from there when doing OTA update with previously bonded device?

BTW, I just wonder why so much space, is the bonding information so large? Do you support many bonded devices concurrently? It doesn't matter much, just asking.

In my case with DS-D6 one reason to use this bootlader is to indeed support your arduiho nrf52 core to run seamlessly because there are people who do use it and are quite happy how easy it is now to code in Arduino with DS-D6 and this bootloader.

The second use case is micropython which incidentally supports only latest SoftDevice S132 6.1 so your bootlader is perfect match. For that I guess I can skip that (11 pages for me, see below) area to give more space to micropython.

BTW, I also needed to have booloader at 0x78000, not 0x74000 as is it tricky/impossible to relocate bootloader via OTA update, 0x78000 is original value stored in UICR. Fortunately the build for nrf52832 is quite small due to missing usb support so it fits just fine when starting from 0x78000.

[hathach]

Thanks for the information, however I do not understand it very much, can you comment a bit more?

why pstorage is configured to use 4 blocks ... Are those two related (pstorage vs DFU_APP_DATA_RESERVED)?

your answer to this was "it is just number of app that register with pstorage raw. It should affect the current code either 3, or 4 is fine I guess"

So I guess this has no relation to running arduino or whatever app at all? It is just a (semi-random) setting for the bootloader build itself because it also uses/links to pstorage SDK code? And it is not related at all to those 7 pages used for bonding information?

Yes, in fact I dont remember if I actually change that value.

Is this 0x6D000 also hardcoded elsewhere in other projects?

Your answer was "our arduino nrf52 repo use 7 pages for storing bonding information which is reserved when uploading new sketch/firmware"

So that means yes this address 0x6D000 is hardcoded in arduino nrf52 repo and must match to share the bonding information written there by apps(?) with bootloader(?). Or maybe it is just hard limit so the bootloader would not flash larger app and overwrite the area but otherwise the data there is not used by bootloader at all? I.e. the bootloader does not use bonding data from there when doing OTA update with previously bonded device?

DFU_APP_DATA_RESERVED is 7 pages (28 KB) app preserved and will never got erased from bootloader, Assert is there to make sure I don't miscalculate flash size by mistake.

BTW, I just wonder why so much space, is the bonding information so large? Do you support many bonded devices concurrently? It doesn't matter much, just asking.

In my case with DS-D6 one reason to use this bootlader is to indeed support your arduiho nrf52 core to run seamlessly because there are people who do use it and are quite happy how easy it is now to code in Arduino with DS-D6 and this bootloader.

The second use case is micropython which incidentally supports only latest SoftDevice S132 6.1 so your bootlader is perfect match. For that I guess I can skip that (11 pages for me, see below) area to give more space to micropython.

If our configure doesn't work for you, you could change it on your folk. Though make sure you test it carefully, since flash layout difference can easily cause device bricked

BTW, I also needed to have booloader at 0x78000, not 0x74000 as is it tricky/impossible to relocate bootloader via OTA update, 0x78000 is original value stored in UICR. Fortunately the build for nrf52832 is quite small due to missing usb support so it fits just fine when starting from 0x78000.

You can enable nvmc to erase and rewrite UICR in your code, Though be careful since that it is easy to brick device too.