GZP (Gazell Pairing Library) causes application to reset into Bootloader

[Alex]

Hello there, thanks so much for taking the time to read. My problem is the following

I am trying to run GZP (Gazell Pairing Library). After successfully pairing with a Gazell Host, if I power cycle my Gazelle device (NRF52) after this point, it resets back into the Bootloader (invalidating the application due to bad CRC check).

Here's some basic information about my setup:

• Bootloader present
• Using Softdevice (S132, Version 3.0.0)
• NRF52 SDK12.0.0
• Running FreeRTOS
• Application starts at address 0x1F000, size=0x31000
• Bootloader starts at address 0x73000
• GZP database starts at address 0x50000

What I noticed is that GZP is writing directly into Flash starting at address 0x50000, and I believe that perhaps the Bootloader (since present) sees that part of Flash was modified. This would make the application CRC check fail after a power-cycle, which would cause the Bootloader to not boot properly into the application. Does this make sense?

My question is, if the above happens to be the case, how could I separate the GZP database into its own region of Flash (at address 0x50000), so that after modifying this memory space, the application would not be corrupted (as seen by the Bootloader)? Any ideas/suggestions are very much appreciated. If I missed something in my description, please let me know and I will add any other details that could help clarify the problem.

Thanks!

[Hung Bui]

Hi Alex,

How big is your actual application size after you compile it ?

It's maybe not a very good idea to write your data at address 0x50000 because it can be erased by the bootloader to get space for the swap bank to receive new image as shown here.

But it's still quite strange that the bootloader is started after you modify flash at address 0x50000. The bootloader only calculate CRC of the application code base on the size of the application not outside it. 0x50000 should be outside.

My suggestion is to debug function nrf_dfu_app_is_valid() in nrf_dfu_utils.c in the bootloader, either by printing log out or by adding a breakpoint and step into the code. You can find if the app valid function return true or not, and why. You can debug the bootloader as you do with a normal application.