Bootloader and pstorage

[TheBarrelShifter]

Hi,

I'm in the process of transitioning my application and associated bootloader from SDK 7.2.0 to SDK 9.0.0.

I can compile both my application and bootloader now against SDK 9.0.0

One thing I have found is that dfu_dual_bank.c in SDK 7.2.0 used pstorage in 'raw' mode, for example, dfu_init function would call pstorage_raw_register() to register the storage, whereas in SDK 9.0.0 dfu_init calls pstorage_register() (rather than the 'raw' variant)

This causes a problem, because dfu_init does not set up all the members of pstorage_module_param_t passed to pstorage_register (namely block_size and block_count), and therefore the call fails when pstorage_register checks the passed parameters using the macros BLOCK_SIZE_CHECK and BLOCK_COUNT_CHECK. pstorage_raw_register does not check these, and so in SDK 7.2.0 this works just fine.

Please could you explain whether it is intentional in the bootloader_dfu for SDK 9.0.0 to no longer use 'raw' accesses to pstorage? I find it hard to believe because the comments in pstorage_platform.h suggest that RAW mode is exactly for functionality such as the bootloader.

I don't really understand how anybody can be using bootloader_dfu in its current form with SDK 9.0.0 because I can't see how it can work.

Any information you are able to offer will be welcomely received.

[TheBarrelShifter]

The transition appears to have happened between SDK 8.0.0 and SDK 8.1.0

Have a look at components/libraries/bootloader_dfu/dfu_dual_bank.c

In SDK 8.0.0 all calls to pstorage are the 'raw' variant, e.g. pstorage_raw_register In SDK 8.1.0 all calls to pstorage are the 'normal' variant, e.g. pstorage_register

I can't believe that this is intentional - The call to pstorage_register will definitely fail because of the aforementioned missing setup of the block_size and block_count members of pstorage_module_param_t.

Having changed the calls in SDK 9.0.0 to use the 'raw' variants of the pstorage functions I can get the bootloader to work. However, it does not fill me with faith that these issues are present in what should be a more mature version of the code.

What is the recommended STABLE and TESTED version of the SDK to be using please?

[tomchy]

I faced that problem about a week ago. The thing is bootloader still doesn't use 'regular' PStorage, but instead of using 'raw' calls - it uses different implementation which has regular function names. Just look into makefile or sources list - you will see file called 'pstorage_raw.c'. It has even less checks than 'raw' PStorage. The purpose of creating this file was to reduce code size for bootloaders.

[TheBarrelShifter]

Thanks for the pointer in the right direction.

Seems to solve some of the problems I was seeing - The first thing I notice is that it's much slower, and often times out during a transfer. Need to look into this some more.

Thanks again.

[TheBarrelShifter]

Hi,

I have a question maybe you are able to answer tomchy....

When performing an update of the bootloader itself, are you creating the zip file with a binary or hex? Also, what are you doing in relation to the bootloader_settings block, and also the NRF_UICR_BOOT_START_BLOCK?

I have created a linker script that strips this out, and am creating a binary of the bootloader code only (missing out the settings and START_BLOCK register) - However, I am unable to get the update to complete successfully. When the unit reboots it doesn't seem to be executing any code.

Please could you share your experiences in performing bootloader updates?

Positive news is that I now seem to be able to perform softdevice updates since your pointer in the right direction, whereas this was not working correctly before.

Many thanks.

[TheBarrelShifter]

All working now :-)

Thanks again