The blockset library provides a series of blocks which allow the modeller to adjust scalars, 1-d and 2-d maps while the model is being iterated.
The blockset library provides access to non-volatile storage: storage retained when the power is removed from the module by either connecting a low power source to the Keep alive power pin to retain the contents of RAM storage, or by committing the data to Flash storage (see the technical specification for details on which storage type is supported by each target).
On start-up, the blockset library attempts to retrieve adaptive data prior to running the model application. While the application is running, the time at which the adaptive data is stored back to non-volatile memory is determined by the application itself.
The adaptive data is check-summed using a 16-bit CRC. Failure to match the check-sum against the adaptive data during library initialisation means that the data cannot be recovered. In this case, adaptive data is reverted to the default for each adaptive element (the defaults can be specified by the application).
There are two types of non-volatile memory dedicated to adaptive data:
Storage that requires an external power source when the ECU is powered down (not available on all target ECUs),
Storage that requires no external power supply when the ECU is powered down (not available on all target ECUs).
See Section 1.1, “ECU hardware reference documentation” for details of what non-volatile memory stores are available for each target ECU.
The application starts a commit of adaptive data to non-volatile store through the pnv_AdaptiveChecksum block.
If the non-volatile memory store is Flash, then the library will halt the application while committing adaptive data to non-volatile memory. This is to prevent any higher-rate tasks interrupting and attempting to access the Flash device (which will generally be unavailable at that time).
The worst case scenario is for the application to be stopped for about 1.8 seconds. It is the responsibility of the application to ensure that there will be no detrimental side effects to stopping the application for this length of time, e.g., the application should ensure all coil and injector outputs are turned off if applicable for that ECU.
It should also be noted that, once started, it is not possible to interrupt the Flash commit process. So if, for example, a user of the ECU requests that the ECU start-up before the process has completed, the ECU will not try to start until control is passed back to the application.
The application can determine if the adaptive data requires a commit to non-volatile memory through the pnv_Status block. When the ECU decides to power down, if this block shows the data as unmodified there will be no need to store the data to non-volatile memory again; this is important for a Flash-based solution as this means there is no need to write the data to Flash, thus minimising shutdown time and reducing the number of Flash write cycles.