Changing flash location of bootloader causes bonding problems

[sonja]

We are using SDK_13.0.0_04a0bfd and want to change the location and size of the bootloader in flash. But when we do this, the bonding process in the main application doesn't work any more. We get PM_EVT_ERROR_UNEXPECTED with 0x3 (which seems to be NRF_ERROR_MUTEX_UNLOCK_FAILED).

We went through the code and the problem might be the BOOTLOADER_START_ADDRESS in the UICR register (0x10001014) which we didn't adapt.
But it seems nowhere to be set, which is no difference to the state before.
We found one file ant_dfu_constraints.h where it is set for an example, but the given address 0x79000 for nrf52 doesn't match the old 0x75000 or the new address 0x6C000.

What do we have to set and where?

We use gcc by the way.

Thanks!

[Edvin]

Hello,

Please see this post on how to change the BOOTLOADER_START_ADDRESS:

https://devzone.nordicsemi.com/f/nordic-q-a/26300/how-to-use-nrfjprog-to-write-uicr-bootloaderaddr

 

Best regards,

Edvin

[sonja]

Hi Edvin!

Thanks for your hint. I checked now and the BOOTLOADER_START_ADDRESS is set correctly in the UICR register so the problem has to be something else.

Could it be an issue that the bootloader doesn't use the BLE stack but the main application does?

Thanks!

[Edvin]

Ok. Have you tried to read out the BOOTLOADER_START_ADDRESS after it is written to check that it is written correctly?

You can use "nrfjprog --memrd 0x10001014" to check.

 

Can you please describe what you mean with: "the bonding process in the main application doesn't work any more"?

Have you tried to debug your application after the DFU? does the application crash? 

 

Best regards,

Edvin

[sonja]

Yes I checked with nrfjprog --memrd 0x10001014 and also read the value in BOOTLOADER_START_ADDRESS, both match the value in the linker script.

The bonding error is PM_EVT_ERROR_UNEXPECTED with 0x3 (which seems to be NRF_ERROR_MUTEX_UNLOCK_FAILED), the app doesn't crash, only bonding isn't successful.

I commented out all code that is not part of the original dfu bootloader and then it worked, so I will search for the line causing this now step by step...

[sonja]

I found the cause for the error: storing something from the bootloader into flash memory with nrf_dfu_flash_store() is causing the bonding error in the main application.

Why is that a problem and how can I avoid this?

[Edvin]

Hello,

The calls to nrf_dfu_flash_store() that you mention, did you add these yourself?

 

I suspect that there are some collision here, where you store data in the area of your application's FDS.

 

If you look at the figure on this page, you can see how the memory is used. You can't change the areas that the bootloader use by default, only the start address. The rest is fixed (relative to the start address).

 

When you initialize FDS, it will use the flash area right next to the bootloader. If you write to this, it will be overwritten by the bootloader, or the FDS will overwrite the bootloader.

 

What you can do is to increase APP_DATA_RESERVED by 1 page, and leave the FDS_VIRTUAL_PAGES as it is, and store your custom bootloader data on the last page. In an unmodified example FDS_VIRTUAL_PAGES is 3, and the APP_DATA_RESERVED is 3 (in the bootloader project).

Increase APP_DATA_RESERVED to 4, and leave FDS_VIRTUAL_PAGES 3. Then use the last page to nrf_dfu_flash_store(). This way, the last page will not be touched by the peer manager, and it will not be erased in a DFU operation.

 

Best regards,

Edvin