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

[Einar Thorsrud]

Hi Seba,

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

The SoftDevice does not validate itself, no.

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.

I understand you have your own custom bootloader, but let me describe how this is done using the SDK bootloader. With that, the CRC is calculated for the application itself, not the entire application regions. The application in this case is everything between the application start address (first page after the SoftDevice) and the highest address in the application hex file. So, as long as the FDS regions are after the end of the application, that will not cause problems with the CRC calculation using the default SDK bootloader.

A few thoughts based on that:

• 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.
• 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.

Einar