Is it possible to store the Zigbee stack library with the bootloader (while still having access to it from the application) in order to decrease the application size for the dual-bank DFU purpose?

[AnnaR]

While working on the multiprotocol Zigbee+BLE application with dual-bank OTA DFU, we almost reached the size limit for the application. However, there are some functions still need to be added.

As the Zigbee stack library is far from the smallest part of the current application, the question arises, could it be stored one time (for example, with the bootloader, or somewhat like the softdevice storing) instead of storing it with the application, which requires the double-size flash due the dual-bank DFU?

If it is possible, some guidance on realization would be very helpful.

[Marjeris Romero]

Hi Anna,

I am looking this up with our Zigbee team.

Best regards,

Marjeris

[Marjeris Romero]

Unfortunately currently we do not support partial DFU (Zigbee stack only, application only).

The only way you may adjust the amount of flash memory used is adjusting the persistent storage / production configuration flash regions, see https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v3.1.0%2Fzigbee_mem_cfg_feature_flash.html&cp=5_3_3_4_1

Best regards,

Marjeris

[AnnaR]

Hi Marjeris,

Thank you for your reply.

We use the Secure BLE bootloader that supports the OTA DFU, so the DFU is possible in two ways: 1) through the Zigbee communication channel while the application firmware running; 2) through the BLE while running the bootloader firmware. What if we will just use the application firmware image without the ZigBee stack library, and will update the Zigbee stack with the bootloader update? How the DFU library knows, whether the Zigbee stack is present in the image? I mean, what if the checksum and other parameters will be generated by the nrfutil for the hex that doesn’t contain the Zigbee stack library?

As I guess, I need to define somehow in the Segger Embedded Studio project, where the libzboss.a functions should be located in flash but don't include this library in the application firmware build. While, for the bootloader project, I need somehow to include this library in the build. So, the Zigbee stack could be updated with the bootloader. Is it possible?

About the persistent storage you mentioned, thanks for the idea, we used the default values. Would it be safe enough to use the 8kB pages supposing the “typical” Zigbee router application? Also, we use the FDS library. As I noticed, if I will change the value of the ZIGBEE_NVRAM_PAGE_SIZE, the FDS_VIRTUAL_PAGES_RESERVED will be also changed, meaning the flash end address (as well as starting one) used by the FDS will be moved too?

Sincerely,

Anna

[Marjeris Romero]

Hi Anna,

Sorry for the late reply. I am consulting what you proposed with the Zigbee team to be sure I understand how our stack is build up. To my knowledge it's doesn't seem quite straigth forward to do what you are proposing because as far as I know it's not possible to separate the Zigbee stack from the application, as some components in the Zigbee stack are part of the application layer, this is also illustrated in here.

I will come back to you when I have more answers.

Best regards,

Marjeris

[Marjeris Romero]

Hi Anna,

Sorry for very late reply to this post. I got feedback from the Zigbee team and I thought I will update this post to give some closure. My assumptions in the last post are correct - it can't be done. The stack is linked with the application. What you describe would require dynamic (run-time) linking so the application knows where to jump where zigbee stack API is called.

Also to answer your other questions: using 8kB pages for a typical Zigbee router application should be OK and the FDS should move automatically not to overlap with NVRAM.

Let me know how this project going and if you have any more questions.

Best regards,

Marjeris