NvmCtxMgmtStore L073

[krispstack]

Hi

NvmCtxMgmtStore is called for every uplink, downlink and multicast. Does it impact the number of write cycles of EEPROM?

I am using NucleoL073 (Release 4.4.4)

Advice plz.

Thanks

[EduardoPfeifer]

Hi!
Maybe this can clarify your question:

/*!
 * Enables/Disables the context storage management storage at all. Must be enabled for LoRaWAN 1.1.x.
 * WARNING: Still under development and not tested yet.
 */
#define CONTEXT_MANAGEMENT_ENABLED         0

/*!
 * Enables/Disables maximum persistent context storage management. All module contexts will be saved on a non-volatile memory.
 * WARNING: Still under development and not tested yet.
 */
#define MAX_PERSISTENT_CTX_MGMT_ENABLED    0

[krispstack]

Hi @EduardoPfeifer

/*!
 * Enables/Disables the context storage management storage at all. Must be enabled for LoRaWAN 1.1.x.
 * WARNING: Still under development and not tested yet.
 */
#define CONTEXT_MANAGEMENT_ENABLED         1

/*!
 * Enables/Disables maximum persistent context storage management. All module contexts will be saved on a non-volatile memory.
 * WARNING: Still under development and not tested yet.
 */
#define MAX_PERSISTENT_CTX_MGMT_ENABLED    0

#if ( MAX_PERSISTENT_CTX_MGMT_ENABLED == 1 )
#define NVM_CTX_STORAGE_MASK               0xFF
#else
#define NVM_CTX_STORAGE_MASK               0x8C
#endif

In Above configuration only Multicast Downlink count is kept in eeprom, Activation details is not saved. Join Request is sent to server for every time module is restarted.

/*!
 * Enables/Disables the context storage management storage at all. Must be enabled for LoRaWAN 1.1.x.
 * WARNING: Still under development and not tested yet.
 */
#define CONTEXT_MANAGEMENT_ENABLED         1

/*!
 * Enables/Disables maximum persistent context storage management. All module contexts will be saved on a non-volatile memory.
 * WARNING: Still under development and not tested yet.
 */
#define MAX_PERSISTENT_CTX_MGMT_ENABLED    1

#if ( MAX_PERSISTENT_CTX_MGMT_ENABLED == 1 )
#define NVM_CTX_STORAGE_MASK               0xFF
#else
#define NVM_CTX_STORAGE_MASK               0x8C
#endif

With above configuration Activation and multicast count is kept in eeprom. And its good for our usecase. But we are worried about the EEPROM writes.

For our use case node send data every 15 mins, and there will be around 10 -15 down links every day, and 300 multicast downlinks every day . So on an average 500 EEPROM writes every day.

Is there any documentation to explain how below Macros works

#define MAX_PERSISTENT_CTX_MGMT_ENABLED    1

#if ( MAX_PERSISTENT_CTX_MGMT_ENABLED == 1 )
#define NVM_CTX_STORAGE_MASK               0xFF
#else
#define NVM_CTX_STORAGE_MASK               0x8C
#endif

[mluis1]

The number of FLASH/EEPROM writes will reduce the FLASH/EEPROM life time and yes, there is an impact on the write cycles.

The MAC layer just notifies the upper layer that a change has happened. It is then up to the application layer to decide if the NVM requires to be updated and when.

On the provided examples we decided to update the NVM every time the MAC layer sets a notification (easy solution but, reduces life time of the NVM memories).

Thus, in the end it is a question of compromise and some solutions are possible.

• Only update the NVM time to time (background process). The problem with this solution is that the MAC notifications done between NVM real updates may be lost in case the node resets or looses its power.
• Use for example FRAM device to store the NVM data. FRAM devices aren't impacted by the write cycles.
• Etc...

Please note that we think that current NVM management is way too complex and we are thinking on how we can reduce the amount of data to be stored as well as to simplify the current implementation. This is on our to do list and it may take quite some time before we come up with a proposition.

[krispstack]

Hi @mluis1

Have tried with MB85RC16V fram, But the context is not storing.

Thanks