Custom Bootloader CRC check failed because of pair manag

RE: Custom Bootloader CRC check failed because of pair manag

Sebastijan — Fri, 03 Sep 2021 10:26:16 GMT

Hi Eniar,

Thank you very much. I solve everything with your suggestions.

Regards.

Seba

RE: Custom Bootloader CRC check failed because of pair manag

Einar Thorsrud — Fri, 03 Sep 2021 09:16:53 GMT

Hi Seba,

The sdk_config.h configuration does not have any impact on the linker configuration of the application, if that is what you ask? It makes sense to take this into account yes, so that the configured application start address + size ends below the start of the FDS pages. This way you will get a build error if the application grows so large that it overlaps the FDS pages.

einar

RE: Custom Bootloader CRC check failed because of pair manag

Sebastijan — Fri, 03 Sep 2021 07:35:52 GMT

Hi Einar,

Thank you for detailed explanation.

We tried to exclude FDS area and it worked. :) Thanks!

One more question regarding app flash size. Probably i have to exclude area in main application also?

Or does this parameter "FDS_VIRTUAL_PAGES = 3" already do that?

Regards.

Seba

RE: Custom Bootloader CRC check failed because of pair manag

Einar Thorsrud — Wed, 01 Sep 2021 12:25:03 GMT

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.

RE: Custom Bootloader CRC check failed because of pair manag

Sebastijan — Wed, 01 Sep 2021 11:14:30 GMT

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

RE: Custom Bootloader CRC check failed because of pair manag

Einar Thorsrud — Mon, 30 Aug 2021 11:49:25 GMT

Hi Seba,

[quote user=""]Soft device probably does not handle its own CRC mechanism on start-up right?[/quote]

The SoftDevice does not validate itself, no.

[quote user=""]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.[/quote]

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