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

[sonja]

Hi,

Thanks for your fast reply!

Yes, I added the nrf_dfu_flash_store() myself.

Actually the dfu example uses nrf_dfu_flash module which uses fstorage instead of fds, so FDS_VIRTUAL_PAGES and APP_DATA_RESERVED is never defined. APP_DATA_RESERVED I couldn't find in the entire sdk.

I tried to initialise nrf_dfu_flash_init(true) (-> softdevice enabled) instead of nrf_dfu_flash_init(false) in the bootloader, but the first call to fstorage crashes the bootloader application.

I chose the two pages right before the bootloader for the data, so maybe that's the problem. When I tried other pages I didn't get any ble events anymore even though I didn't choose pages belonging to the softdevice.

Actually my plan is to write data into certain flash pages directly when flashing the device (not done yet) and update them from bootloader and read them from the main application when necessary during runtime. Is there another (easier) way than the way I am trying?

Or can you recommend free flashpages? At the moment my flash mapping is the following:

bootloader is at 0x6C000 - 0x7E000 (length 0x12000)

main app is at 0x1F000 -0x5F000 (length 0x40000)

my custom data is at 0x6A000 and 0x6B000 (chaning them to pages between 0x50000 and 0x69000 didn't work either)

Thank you!

Best regards,

Sonja

[Edvin]

Hello Sonja,

Sorry. The define is DFU_APP_DATA_RESERVED, and is used in the Bootloader project, in the nrf_dfu_types.h.

 

Can you try to do a flash dump of the chip when it fails? I think it is correct as you say, that the pages right after flash will be used by the Peer Manager. I would think that if you place your custom data in the pages "before" the 3 pages used by the peer manager, that you shouldn't get any events. Are you sure that the application is running then? Have you tried to do some debugging at that point, to see whether the application is running in the first place?

 

A memory dump of the area where you store your custom data and the pages below the bootloader would be interesting to see. Could you provide that?

 

Best regards,

Edvin

 

[sonja]

Hi Edvin,

I cleaned up my bootloader makefile which made the bootloader application small enough to fit into the flash region like the one in the dfu example application. This solved the problem, even though I don't really understand why. Maybe my flash was too full but I was not aware of it.

Thank you so much for your help anyway!