Details
Description
With the new GCI-based stack interfacing and the Generic AP task, we no longer load/store the remanent data ourselves, but let the AP task do it on our behalf. This mechanism is based on the two packets mentioned in the summary.
Recently, we decided that there shall be a taglist entry with which the firmware integrator can control that this indication/request is propagated beyond GenericAP towards the host to cover the use case "Host stores remanent data" in a generic fashion.
In such cases, the host generates a HIL_SET_REMANENT_DATA_REQ on startup to provide the remanent data to the stack, and afterwards, all changes of non-volatile attributes cause a HIL_STORE_REMANENT_DATA_IND to be generated in order for the host to store that changed remanent BLOB. The host no longer has to interpret the contents of that data. This mechanism is specific to built-in CIP object, application specific objects are still handled in host-specific fashion via the CL3_SERVICE_IND.
Recent discussion led us to the decision that we want to backport that behavior to the pre-netX90 stacks which lack GCI, GenAP and are rcX-based. Thus, we achieve a consistent look and feel and avoid any duplication in our demos and manuals to cover possible differences of the two stack variants.
Please backport the described mechanism to the rcX-based EIP firmwares.