The choice of an STM32WL microcontroller precludes the use of internal EEPROM, requiring the use of either an external EEPROM or the internal Flash memory for storing persistent data. The latter option is often favored in many designs (and modems) for cost reasons, though it comes with certain implications.

Using networks like LoRaWAN and Sigfox involves regular persistent writes. In the case of LoRaWAN, using OTAA (Over-The-Air Activation) mode, the devNonce must be recorded during each join procedure to ensure its uniqueness over network connections. Here, the number of persistent memory writes will theoretically be low (except for the battery end-of-life scenario discussed later). For an ABP (Activation By Personalization) connection, the situation differs significantly; the frame counter (FCnt) must be recorded so that it does not reset to zero in the event of a reboot. The same applies to Sigfox and its SeqId, which must increment with each communication. Without specific logic, LoRaWAN ABP and Sigfox will write to persistent memory with each data transmission.

While an EEPROM memory area has a lifespan of about 100,000 to 1,000,000 cycles (still potentially lower than the number of messages sent during the object’s lifecycle), a Flash memory area lasts only 10,000 writes, a number quickly reached in IoT communications. Therefore, using Flash as persistent storage requires a different approach compared to EEPROM in this context.