Added parameter backup region on H7 with 32k FRAM

[tridge]

This expands the FRAM storage region for H7 boards to 32k, and adds the following:

• expands param storage by 1280 bytes (to help with new IMU temp cal param data)
• expands mission storage by 9842 bytes, giving 820 more waypoints
• adds a new ParamBak storage region as backup for primary param storeage

This fixes issue #13134

The backup param storage area is continuously updated along with the main param storage. On startup if the primary storage area has a corrupt header then the backup is used, copying it over the primary.

Confirmed OK on:

• CubeOrange
• Durandal
• CUAV-X7
• CUAV-Nora
• PixracerPro
• ControlZeroH7
• mRoNexus

I've also tested that setting FORMAT_VERSION=0 does reset properly, so no user visible behaviour change
I've confirmed with @pkocmoud that mRo use 32k FRAM

[peterbarker]

.... how did you manage to get this to conflict already? :-)

[proficnc]

Thanks Tridge!

[tridge]

.... how did you manage to get this to conflict already? :-)

yeah ... forgot to rebase first :)
fixed

[peterbarker]

This looks good in terms of what it is trying to accomplish.

IMO the extra space allocations for fence and mission do not belong in this PR. They might be good changes but they're unrelated and deserve discussion.

[tridge]

IMO the extra space allocations for fence and mission do not belong in this PR. They might be good changes but they're unrelated and deserve discussion.

happy to discuss, but I think given the structure of StorageManager that allocating some more space for params and mission is worthwhile now if we are going to start using the 2nd half of the FRAM

[tridge]

in the one example of a STRG_BAK that we have showing this issue, I've confirmed that the corruption is confined to the first 48 bytes of the parameter storage.
That makes it very likely that this PR will prevent loss of parameters

[pompecukor]

When can it be merged? Will be a life saver. Reset have been such a PITA.

[Mr-jh]

Is it valid for f7 based like cuav v5+

[timtuxworth]

IMO the extra space allocations for fence and mission do not belong in this PR. They might be good changes but they're unrelated and deserve discussion.

happy to discuss, but I think given the structure of StorageManager that allocating some more space for params and mission is worthwhile now if we are going to start using the 2nd half of the FRAM

You always need more. (it doesn't matter what you are talking about, whenever there is a hard limit - you always need more).