How to Share Memory Blocks Between Application and Bootloader
You need one configuration of memory stack for the application and one configuration of memory stack for the bootloader. Both configurations must share the same physical dataflash sectors.
Recommendation: Start with the configuration of the application’s memory stack.
Option 1: Using MICROSAR Standard Fee
The application configuration must include all blocks (e.g. which are intended to be only accessed by application, blocks which shall be only accessed by bootloader and blocks which can be accessed by bootloader and application).
Set the parameter Fee Block Id Fixed to enabled for at least all blocks which shall be accessed by the bootloader only and all blocks which can be accessed by bootloader and application. But it is also advisable to enable this parameter for application blocks to assure that a non-voluntary change of Fee Block Id is not possible.
If you finished memory configuration of application save the configuration and store the same memory configuration for the bootloader as well. It saves time for configuration of the bootloader memory stack and can be used as a base configuration for the bootloader. To get a real memory stack bootloader configuration some changes in configuration are required:
- Delete all blocks which shall be only accessible in application context.
- All blocks which shall be only accessed by the bootloader and all blocks which can be accessed by the bootloader and application must stay in the bootloader configuration and the blocks must have the same Fee Block Ids as the corresponding blocks in the application configuration. (hint: enable parameter Fee Block Id Fixed already in the application configuration before you ensure that the Fee Block Id is not changed non-voluntaryly).
- Clarification: All bootloader projects which only use Fee and Fls and no NvM and MemIf cannot open the Memory Blocks Editor. Instead the basic editor must be used and blocks can be deleted in FeeBlockConfiguration. That also means, if you do not want to use NvM and MemIf in the bootloader then disable the components.
- Go to container FeeSpecificFeatures in BasicEditor and enable parameter Flash Bootloader Configuration. This gives the Fee the information that it shall work in a special (bootloader) mode and there will be additional blocks in dataflash which are not known by the configuration (all blocks accessible only in application) but the Fee must take care for these blocks during internal management operations.
- In case the Fee works in bootloader mode, no thresholds are configurable for the sector switch. The sector switch is always executed after one sector is full. The Fee works in the bootloader in single sector mode.
- If you do not use NvM in the bootloader and you use the NvM Job End Notification and NvM Job Error Notification in the application, go to FeeGeneral container in the basic editor and remove the parameter NvM Callback Include File and set NvM Job End Notification and NvM Job Error Notification to NULL_PTR.
Option 2: Using MICROSAR SmallSector Fee:
Compared to the MICROSAR Standard Fee, the MICROSAR SmallSector Fee works with static addresses for its blocks. This eases the handling of the blocks in the bootloader and the application. You can use the same block configuration for both application and bootloader. The SmallSectorFEE does not distinguish between Flash Bootloader and Application blocks in the configuration. It is reasonable to use different FEE partitions to logically separate Flash Bootloader blocks from user data blocks. The Flash Bootloader partition should be the first partition in dataflash.
- If you do not use NvM in bootloader and you used the NvM Job End Notification and NvM Job Error Notification in application, go to FeeGeneral container of SmallSector Fee in BasicEditor and remove the parameter NvM Callback Include File and set NvM Job End Notification and NvM Job Error Notification to NULL_PTR.
Option 3: Using MICROSAR Ea:
The MICROSAR Ea works like the MICROSAR SmallSector Fee with static addresses for its blocks. You can also use the same Block configuration for both, the application and the bootloader.
If you do not use NvM in the bootloader and you use the NvM Job End Notification and NvM Job Error Notification in the application, then remove the parameter NvM Callback Include File from the EaGeneral container in BasicEditor and set NvM Job End Notification and NvM Job Error Notification to NULL_PTR.