about Sequence Number

[Hiroaki_Iwata2]

I'm developing with the NRF52840 using IAR Embedded Workbench, and implementing wireless communication based on the IEEE802.15.4 Zigbee protocol.

In the MAC frame layer of IEEE802.15.4, there is a field called Sequence Number, which is used to identify the continuity and uniqueness of transmitted packets. I'm currently struggling with how to implement this.

In this development, the device uses the Deep Sleep feature, which means the Sequence Number needs to be retained even when the device is stopped. I have the following ideas for software and hardware design:

1. Store the Sequence Number in the flash memory of the NRF52840. However, due to concerns about the limited number of write cycles, this approach may be difficult unless the write location is carefully managed.
2. Add an external EEPROM to store the Sequence Number. But from a power-saving perspective, I would prefer to minimize the use of external devices.

What would be the most reasonable way to store the Sequence Number on the NRF52840?

[tesc]

Hi,

implementing wireless communication based on the IEEE802.15.4 Zigbee protocol.

Our main recommendation is to not build the full stack yourself, but to build on top of our nRF Connect SDK with the appropriate Zigbee add-on. See Zigbee CIDs for compatibility between SDK, Zigbee addons and CSA certifications.

In the MAC frame layer of IEEE802.15.4, there is a field called Sequence Number, which is used to identify the continuity and uniqueness of transmitted packets. I'm currently struggling with how to implement this.

As you indicate, an implementation must consider flash usage carefully, and is not entirely straight-forward. If you really want to implement this yourself, then there are a couple of techniques which could be useful:

The first is to keep the sequence number in RAM whenever you can do so, including using RAM retention as appropriate.

The second is to not store the number at a fixed location in flash. Rather, write a new entry in flash, at a later address, each time the number must be updated. You can use an existing storage system for this, such as Non-Volatile Storage (NVS).

Combining the two, you will minimize the number of Flash write/erase cycles. The most important Flash constraints on the nRF52840 are a minimum 10 000 write/erase cycles per Flash page, and that each 32-bit word can be written to a maximum of two times before erase. Write and erase times matter as well, if you have limited time for writing at power-off. For details, see the electrical specification section of the NVMC chapter of the nRF52840 Product Specifications.

But again, the main recommendation is to build your application on top of our SDK with the Zigbee addon, such that you do not have to implement this yourself.

Regards,
Terje

[Hiroaki_Iwata2]

Thank you for your reply. I am designing a battery-powered device. It is designed to enable "DEEP SLEEP" and wake with a "HIGH" GPIO signal.

Therefore, it will be reset when waking, and the SEQUENSE No. will not be retained. I believe RAM retention will not work because "DEEPSLEEP" is used.
Does this mean that the program itself can write data to the flash memory? Should I refer to section 4.3 NVMC in the datasheet "NRF52840 Product Specification"?

[tesc]

Hi,

RAM retention can be used in system off, if the SoC is still connected to power while in that state, but it looks like RAM contents may be corrupted on pin reset, yes, so then it cannot be used for your use case.

If you are using either nRF5 SDK or nRF Connect SDK, then there are flash handling libraries in the SDK that you can use. (FDS in nRF5 SDK; NVM in nRF Connect SDK.) Otherwise, Flash handling is documented in the NVMC section of the product specification (datasheet), yes. Please note that for new projects we recommend using nRF Connect SDK (see nRF Connect SDK and nRF5 SDK statement for details on SDKs.)

Regards,
Terje

[Hiroaki_Iwata2]

Hello, thank you for your response.
I am not using the nRF Connect SDK. I have reviewed the sample code and referred to the following example:
nRF5_SDK_17.1.0_ddde560\examples\802_15_4\wireless_uart

In this example, the SEQUENCE NO (static sequence_number_t tx_sequence_number = 0; declared in fsm.c) is defined as a static variable, so it resets to "0" after a CPU reset.
This contradicts the requirement to retain the value even after a reset.

In practice, writing to FLASH seems difficult. If RAM retention is also not possible, then it appears to be unfeasible.

Fundamentally, do CPUs that operate with a kinetic harvester have a special physical layer (such as a structure that enables non-volatile memory) to retain the SEQUENCE NO?

For example, I have seen products using Silicon Labs' MGM13S series that operate with a kinetic harvester and retain the SEQUENCE NO.
However, from what I could see in the datasheet, there didn’t appear to be any special circuitry for that purpose.

[Hiroaki_Iwata2]

Similar modules using kinetic generators from other manufacturers write the SEQ No. to the EEPROM. Thank you.

[tesc]

Hi,

Looking at that wireless UART sample, it looks like that sequence number is mainly for keeping track of the data sent? (I.e. bookkeeping for segmenting and reassembling the stream of UART data.) That would be separate from how sequence numbers are handled inside of the 802.15.4 library, which is where the sequence numbers mandated by the 802.15.4 specification would be. It doesn't look like that stack requires any external components. I need to check this more in-depth before we have a clear answer.

Regards,
Terje

[Hiroaki_Iwata2]

Hello. I understand that if the system is always in "system on mode", the sequence number is maintained and does not need to be prepared by the user. The problem is how to memorize the sequence number when returning from "system off mode". For devices driven by kinetic harvesters, non-volatile memory such as EEPROM or FERAM must be prepared to memorize the sequence number. Thank you.