Custom Bootloader CRC check failed because of pair manag

[Sebastijan]

Hello Nordic team!

We are developing system on nrf52832 chip. Let me describe our system a little bit.

It is constructed out of the soft device 332, main application and custom bootloader. We are preforming update over CAN in custom bootloader.

Everything was working perfectly, until client asked us if we can add passcode secure connection. We are checking CRC every time application starts. If we preform full erase and put new software it goes through CRC with no problem. But "then pair" manager preform write on internal flash and there is problem.

There are some suggestions that we think trough.

• we leave out a specific area during crc calculation that might be manipulated by the sd
  • but this would also mean that we would need that flash area to remain constant over the life-time of the SD and it's updates
  • we could leave out the complete SD for CRC checking (does the SD has its own mechanisms for ensuring it is valid?)
  • this also means we are not backward compatible and need to replace the bootloader
• you re-calculate the crc once the flash has been manipulated
  • that would include erasing of the flash area the crc sits in. So we would need to make sure that no other code is deleted with that (f.e. reserving a flash page for the crc)
  • also if there is a power loss or anything goes wrong before you recalculate the BL will also be stuck not starting the app
  • we would not need to replace the bootloader in this scenario
• for the before mentioned solution we could switch to store the crc in one of the non volatile backup registers
  • but we then needed to replace the bootloader again

Soft device probably does not handle its own CRC mechanism on start-up right?

Can you help us what will be best approach, we do not want to dig inside SD and "pair manager"  and changing passcode destination write because we do not want to mess something in SD.

Regards.

Seba

Seba

[Sebastijan]

Hi Einar,

Thanks for the lightning quick response!

• Could it be that your application has some data (perhaps a constant or something else) in flash *after* the FDS pages? FDS pages are normally located immediately below the bootloader, which is typically at the end of the flash, so that is not typical, but I do not know which changes you have made.

I have to check this.

• Alternatively, have you adapted your custom bootloader so that the region the CRC is calculated for includes the FDS pages? If so, I would think the most sensible would be to change that so that the FDS pages are no longer part of the CRC region. After all, FDS is typically used for dynamic data.

I also like this idea.

One question can you help me find where this "FDS" area is defined? I know you said below bootloader bot i meant exact location?

Thank you.

Regards.

Seba

[Einar Thorsrud]

Hi Seba,

I will first describe how this works in the SDK when you use the SDK bootloader (though I understand you do not).

You configure the size of the FDS region by macros in sdk_config.h. The FDS_VIRTUAL_PAGE_SIZE is normally 1024. This is in 4 byte words, so this is one page of 4 kB. The number of pages is specified with FDS_VIRTUAL_PAGES. Most SDK examples has this set to 3, but you need to check your application configuration.

The end address of the FDS pages is calculated by the internal flash_end_addr() in fds.c. This looks for a bootloader by checking a specific word in the end of the MBR params page (0xFF8). If this is set (not 0xFFFFFFFF) this holds the start address of the bootloader, and the FDS pages will be located immediately below this point. If there is no bootloader, the FDS pages will be located in the end of the flash.

You can see a graphical representation of this in the memory layout in the bootloader documentation. Here FDS data is what is called "Application data". So for instance, if you have a bootloader that starts at 0x00078000 and use 3 pages for FDS, this means that the first FDS page will start at 0x00075000.

The above will also be valid for your custom bootloader if it is similar to the nRF5 SDK bootloader, and use a MBR etc. If your bootloader scheme is completely different then you need to have an overview of your memory layout and adapt the FDS implementation (specifically flash_end_addr()) so that the FDS pages are located where you want them. And in any case you must adapt your bootloader so that this region is not included in the region you calculate CRC of to ensure that the application is valid.